Features of modern route servers
at IXPs

Agenda●Recap last session●

Bilateral peering●

Multilateral peering with route servers– What happens– What you can doDisclaimers●Interrupt me●

Let’s be interactive●

Very happy to get feedbackLast session●

Efficiency when peering at multiple IXPs●

Questions?

Last session●

Efficiency when peering at multiple IXPs●

Questions?
– There are different environments.

Motivation
●

●

●

●

When peering at an IXP, or more IXPs, one has
to control traffic flows
Outgoing traffic flows everyone can directthemselves, by prioritising routes within theirnetwork
Incoming flows are controlled by managing
advertisements
BGP route servers offer some mechanismsBefore route servers
●●●

●

●

We are connected to IXPs
We don’t have to pull 20 cables to talk to 20other networks :-)At the IXP we can talk BGP with them over theswitch, exchange routing info, forward traffic
That is not an exception, that is normal!
Bilateral peering
Don’t need a TIX Manager for that! :-)Bilateral peering●In principle, it should be done
– Or is configuring one neighbor too much work…?

●This serves as a backup when IXP routeservers don’t work
– Or can be considered the primary choice, with RSas backup

Now we also have the RS
IXP BGP route servers●not to be confused with DNS root servers
BGP speaker●Software, daemon●
Setup not optimised to forward a lot of traffic●
Can and should have additional features– That’s why we’re here●

https://learn.nsrc.org/bgp/route_servers

IXP RS features – 1
It does not add itself to the AS_PATH●●●

Peers get the same AS_PATH as if peeringbilaterally
Routes will be preferred in the same way. On
other routers in receiving peer’s AS.
In BGP decision algorithm, when comparing
AS_PATH length there’s no difference

IXP RS features – 1 cont.
But some BGP implementations check that thefirst AS in the AS_PATH is the same as theneighbors. In normal eBGP that makes sense.
For sessions with IXP RS that would reject them.
Cisco:

Huawei:router bgp < asn >no bgp enforce-first-as

bgp < asn >undo check-first-as

https://sthix.net/about/route-servers

IXP RS features – 2●●●●

It keeps the next-hop
It tells advert recipient
how to send traffic toother peer directly
Traffic flows from peer
via switch to peerNot via the RS!

IXP RS features – 3 – FilteringFiltering●●

RS are configured to filter incoming
advertisements from peers
RS should not accept unwanted advertisements– default route: 0.0.0.0/0 and ::/0
– too specifics, like /28●

RS should check advertisements per IRR●

RS should do ROV using RPKI
Can show examples, later.

IXP RS features – 4 – Controlling
Controlling advertisements●Seacom and Liquid don’t peer with the route server●If we tell them that they MUST, they will leave

●

●

●
●

This is because RS would normally advertise what
they get from a peer to all the others.
It is a good thing for the operator of the IXP, theoperator of the RS, to give peers more options tocontrol this.
The BGP software can be configured to do this.
BGP communities can be used by peers to signal theintend to the RS.

IXP RS features – 4 – Controlling
Controlling advertisements●●Normal BGP communities are 32-bit
One can’t communicate what to do and 32bit info ofthe ASN concerned inside 32bit

1. With BGP community 0:37027 you can tell the RS to notadvertise this to peer AS 37027
2. With community 0:33791 you can tell the TIX RS (usingitself 33791) to not advertise to any other peer
3. But with community 33791:15399 you can tell the RS toadvertise to peer AS 15399 , despite #2●

Above is talking about other peers with 16-bit ASNsIXP RS features – 4 – Controlling
Controlling advertisements●What if we want to talk about peers with 32-bit ASNs
(above 65535)●

We can use “Large Communities” – RFC 8092

●From RFC 8195 section 4.4:+-------------------+-----------------------------------------------+| BGP Large| Description|| Community||+-------------------+-----------------------------------------------+| 64511:0:peer-as| Explicitly prevent announcement of route to||| peer-as|| 64511:1:peer-as| Explicitly announce route to peer-as|| 64511:0:0| Do not announce route to any peers by default || 64511:1:0| Announce route to all peers by default|+-------------------+-----------------------------------------------+IXP RS features – Conclusion●●

Peers should know this behaviour
It is a feature by the IXP to support requirements bysome peers

Show in config file

Other issues●

Peers should be better filtering what is advertised tothe RS.
– We see routes that peers are getting from their

upstreams – these should not get advertised to the RS●

Some peer is not advertising all they could

Not optimal...
●Traffic from TZ to TZ via Kenya :-(The EndThanks!
Any questions?

More meetings like this?
●What should we be talking about?
– DNS resolvers?
– Policies?
– Internet routing registries?
– RPKI?
– VAS / AS112