Peering Exchange Configurations

Joe Abley jabley at hopcount.ca
Thu Apr 8 11:29:57 CDT 2010


On 2010-04-08, at 12:02, Brad Fleming 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.

> 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).

> 3) Do peering exchanges typically remove their AS from the path advertised to exchange participants?

Some do, I hear. See above regarding route servers.

>    3a) If no: Do participants typically preference exchange-learned routes over other sources?

Many people apply a higher LOCAL_PREF to routes learnt over an exchange in order to prefer cheap peering routes over more expensive transit routes. This is not universal, however. I know of networks who deliberately flatten LOCAL_PREF across peering and transit sessions in order to use different discriminators for exit selection (e.g. AS_PATH length).

> 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.

> In exchanges where a route server is employed:
> 4) Do participants have a p2p link into a simple routing environment then multi-hop to a route server?

In all exchange points I have seen where a route server was available, the route server appears on the shared fabric numbered just as any other participant would be.

> 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.


Joe





More information about the NANOG mailing list