Versions Compared
Key
- This line was added.
- This line was removed.
- Formatting was changed.
Each INX peering LAN has a BGP route collector. A BGP session with the collector is pre-configured for each peer. Peering sessions to BGP peering sessions on the route-collectors are done in advance of port turn-up, and set to passive, so we will automatically respond to, and activate peering sessions from active participantspeers. BGP prefix information gathered via this service, is made available via the our integrated Looking Glass as , as a diagnostics diagnostic tool for the Internet community. We heartily encourage all peers to peer with the route-collector at each of the INXes that they are present at.
title | No advertised prefixes |
---|
We use distinctly separately ASNs for the route-collector and the BGP route servers, as we expect that for their own purposes, not all peers will want to peer with the BGP route servers. While we would prefer to use a completely separate ASN for this, AfriNIC would not allocate us a third ASN explicitly for this purpose, so we are re-using the AS number that we use for each of the INX management networks.
Location | ASN | Hostname | IPv4 | IPv6 |
---|---|---|---|---|
JINX | 37474 | routecollector.jinx.net.za | 196.22360.1496.3 | 2001:43f8:1f0::3 |
CINX | 37663 | routecollector.cinx.net.za | 196.223.22.3 | 2001:43f8:1f1::3 |
DINX | 37668 | routecollector.dinx.net.za | 196.223.30.3 | 2001:43f8:1f2::3 |
NMBINX |
title | ASN Uniqueness |
---|
We use distinctly separately ASNs for the route-collector and the BGP route servers, as we expect that for their own purposes, not all peers will want to peer with the BGP route servers. While we would prefer to use a completely separate ASN for this, AfriNIC would not allocate us a third ASN explicitly for this purpose, so we are re-using the AS number that we use for each of the INX management networks.
329234 | routecollector.nmbinx.net.za | 196.60.120.3 | 2001:43f8:690::3 |
The BGP route collector is a list of potential routes that are available at
thateach specific IX. It
'sis important to note that not all of these might be available to you, depending on the peers that you have, and the particular policy that is in place between
you.
Note | ||
---|---|---|
| ||
The route-servers do not perform any filtering of sort of prefix filtering for prefixes that we receive from peers. This makes it an excellent tool to spot configuration issues from a neutral, 3rd party perspective. |
the peers.
Info |
---|
The BGP-RC does not advertise any prefixes to peers! |
Why should I peer with the BGP Route Collector Service?
We've collected some FAQs about this, and posted them below.
Q: What is the advantage of peering with the BGP-RC?
A: The route collector provides a neutral, unfiltered view of your network, and is an excellent way of answering the question: Are my route advertisements, as I advertise them to others, actually what I intend to be advertising? The convenient looking glass, also provides future potential peers a view of potential prefixes that may be available to them at the IX.
Q: But I peer with the BGP-RS. Surely this is the same thing?
A: No, the BGP-RS service is filtered, very strictly. Whilst this is great for peers that rely on BGP-RS peering alone, we encourage, promote, and expect, that you have bilateral sessions as well. The BGP-RC is unfiltered, and is thus is one way of ensuring that your advertisements match, what you think they should be (without relying on the IX BGP-RS service for filtering).
Not all networks peer with the BGP-RS. And some networks advertise more prefixes across their bilateral sessions, than they do to the BGP-RS. The collector is therefore a single neutral (unfiltered) point to get accurate route information about what you should expect to see from a peer.
We have used the BGP-RC many times, to highlight and identify to networks that they are leaking full routing tables, more specifics (eg. loopbacks), transit-free networks, etc.
Q: What prefixes will the BGP-RC advertise to me? Is it safe?
A: The route collector was built with a belt-and-braces approach to ensure that zero prefixes are advertised to peers, and thus this can not affect any flow of traffic in/out of your network. This is a "collect-routes only" service, and it is very safe!
Q: Why is this data public?
A: Specifically, because we want to be able to provide a neutral viewpoint for any clueful networker to use, to debug problems. Peering with the route collector does not expose sensitive information about your network; more so, it allows you to ascertain from a completely neutral perspective that your network is performing in the manner that you expect.
Table of Contents |
---|