Each member must be assigned an IP address (IPv4/IPv6) in the peering subnet. ISPs will configure their router interfaces with those address, and set up BGP peerings. It is commonly seen as useful that the peering IP addresses are public (i.e. not RFC1918 addresses), and configured with forward and reverse DNS resolution. This eases ISP network debugging, as traceroutes will clearly show which IXP a packet passes through.
The IXP should hence ask for public IP addresses from a RIR. Most IXPs, though, are not themselves LIRs; they use the help of one of their member ISPs (it is uncommon for an IXP to have no LIR among all its members). The IXPs often ask for PI addresses, since most IXPs are PI ("Provider Independent") themselves. Since the pools of unassigned IPv4 addresses are nowadays empty or near to empty, RIRs have reserved special ressources for critical infrastructure like IXPs. Therefore IXPs should ask explicitely for IXP address-space (IPv4 and IPv6).
It is useful for an IXP to have its own AS and a small "service subnet", mainly for monitoring and troubleshooting. From its AS, the IXP will announce its network, where it can host a website, an email server and possibly other services for the members. By peering with all the members, this AS may provide useful routing information for the members, such as a looking glass.
With its own AS, the IXP would also be able to advertise its peering subnet to the Internet, although there is not a general agreement on the necessity of doing it. Some IXPs prefer not to advertise their peering subnets, because they see it as a potential security issue; however, not advertising peering subnets may have the consequence of breaking Path MTU Discovery, and this is why some other IXPs prefer to advertise them.
Another topic where different practices exist is the reverse DNS resolution of peering subnet addresses: some IXPs prefer to keep the reverse resolution under their own domain (with a form such as isprouter.ixp.net for each ISP address), while other IXPs see the router interface of the member as belonging to the ISP domain, and configure the reverse DNS with names such as ixp-switch.isp.com. It is obvious that in the latter case, the ISP would have to be involved for forward DNS resolution.
If an IXP has an appreciable number of members having open peering policies, it can be useful to host a route server at the Exchange. Members with an open peering policy will then only have to peer with the route server in order to peer with each other. Route servers, though, are "single points of failure": failure of a route server would bring all peerings down. Redundancy can be achieved by running more than one route server – sometimes even with different routing daemons to have software-redundancy as well. Routeservers are also a great improvement with regard to scalability. The number of necessary BGPsessions in a full-mesh increases with the square of members. Having route-servers in service brings this to a far more scalable linear function.
It is generally seen as very useful to monitor the traffic statistics of the Exchange Point. Typically IXPs monitor the traffic stats (incoming and outgoing bits) of each port, and sum all those up to create an aggregated statistic. This is helpful to see the trends and patterns of Internet traffic at the IXP, and sometimes to detect problems (traffic drops, or a relevant difference between incoming and outgoing traffic are often signs of problems). The most widely used tools for traffic monitoring are MRTG and the related RRDTool.
Apart from traffic stats, there are several other things that can be monitored in an Exchange Point. It may be of interest for example to ping router interfaces to see if they are alive and to check their round-trip time (RTT); to configure SNMP traps in order to get an early warning if a port goes down; to analyze ARP queries in the peering LAN; or to monitor broadcast packets to detect undesired traffic, dead peerings, and such.
All IXPs have different sets of software to monitor the exchange. Some commonly used publicly available tools are Nagios, Smokeping, ARPWatch. LINX, the London Internet Exchange, has developed a tool specifically to monitor the broadcast packets of IXP peering LANs, called IXP-Watch.
Several exchanges have also custom tools in use, to monitor particular things such as proxy ARP or SNMP traps, or to send an alarm SMS to NOC phones. All these tools may be integrated in some common framework; most IXPs have different frameworks, depending on their particular needs. Many IXPs provide statistics to theirs members that show the amount of traffic exchanged per peering. This statistics can be provided if the peering plattform exports statistical/sampled flow data. This data based on source-, destination mac-address and number of bytes is the basis to calculate and show live peering information.
If you're looking for a tool to manage your IXP, have a look at IXP Manager.
