- Created by Graham Beneke, last modified by Nishal Goburdhan on 01 Apr, 2020
You are viewing an old version of this page. View the current version.
Compare with Current View Page History
« Previous Version 32 Next »
Each INX peering LAN has a BGP route collector. A BGP session with the collector is pre-configured for every peer. Peering sessions to 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 peers. BGP prefix information gathered via this service, is made available via our integrated Looking Glass, as a diagnostics 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.
Location | ASN | Hostname | IPv4 | IPv6 |
---|---|---|---|---|
JINX | 37474 | routecollector.jinx.net.za | 196.223.14.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 |
The BGP route collector is a list of potential routes that are available at that specific IX. It's 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.
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.
Filter free
The route-collectors 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.
No advertised prefixes
The route-server 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: This 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 combined 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 your 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: 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 for not expose sensitive information about your network; more so, it allows you to ascertain from a completely neutral perspective that you are, indeed, not leaking anything that you should not be
- No labels