Peering Exchange Configurations

Thu Apr 8 16:42:16 UTC 2010

Re JOe,

jabley at hopcount.ca (Joe Abley) wrote:

> > 1) Is a private AS typically used for the exchange side of the session?
> No. Also many exchange points do not run route servers at all, and expect participants to build bilateral BGP sessions directly between each other.

...which is a shame. Routeservers in place gives you a nice benefit
upon hooking up to the exchange and before you have even found out
who is on the grid (anyone have a list for NOTA?).

Basically, the bigger exchange points (as in "european" mostly) all
have routeservers ready, but not everybody chooses to use them.

> > 2) Are RFC1918 IPs typically used for the p2p links into the exchange?
> No. Participants in an exchange typically number their exchange-facing interfaces out of a larger (non-p2p) subnet, e.g. an IPv4 /24 or /23, or an IPv6 /48 (or both).

Using RFC1918 for oft-traversed addresses is also not a good idea ;)

> > 3) Do peering exchanges typically remove their AS from the path advertised to exchange participants?
> Some do, I hear. See above regarding route servers.

None of the routeservers I am peering with does insert their ASN.
On direct peering sessions, there is of course nobody in between.

> > 4) Do exchanges typically support the following address families?
> >      IPv4 Multicast
> >      IPv6 Unicast
> >      IPv6 Multicast
> 
> I'm quite ignorant of multicast. IPv6 unicast peering is common.

Multicast is still seen as something special, sometimes even on
dedicated hardware, or on different VLANs. It's certainly possible,
but usually there are not so many participants...

> > 5) I see that Bird, OpenBDGd, and Quagga are all options for route server software. Does one of those packages stand out as the clear current choice for production peering exchanges?
> 
> BIRD seems to be the choice du jour based on idle hallway chatter, but I have not compared them.

I was thinking "plat du jour"...and well, it's "du jour", so it can change
in an instant.

Cheers,
	Elmar.