Aaron’s Worthless Words

If you’re running iBGP, you may have run across this. What if you had three routers — R0, R1, R2 — that were running BGP under the same ASN, but R1 and R2 weren’t peered? Any routes coming from R1 would not show up on R2 and vice versa. iBGP, by standard, does not pass on routes it learned via the same ASN. That is, if a router learns a route from another router in the same autonomous system, the route does not get forwarded. I guess it just assumes that all iBGP routers are fully meshed…I don’t really know.

That sucks, right? One of several fixes for this is the route-reflector-client directive under the BGP neighbor configuration. A route-reflector literally reflects the routes from one client to the others just as if you’ve got a fully meshed network. Here’s a sample config for the reflector, R0.

router bgp 65000
neighbor 10.0.0.11 remote-as 65000
neighbor 10.0.0.11 route-reflector-client
neighbor 10.0.0.12 remote-as 65000
neighbor 10.0.0.12 route-reflector-client

There’s actually no additional config on R1 and R2 at all; the router reflection is transparent to them. They actually see the route just as though they got the update directly from the originating router, so any routes received from the reflector appear as though they came from the originator. In that same breath, you have to realize that R1 and R2 must have routes to each other since the untouched BGP routes will have a next-hop address as the originating router.

Edit: Here’s a crayon drawing I did to show an example of where you would use route-reflectors. R0 is connected to R1 and R2 via different WANs, but R1 and R2 aren’t connected at all.

• Leave a comment... (0)

It looks like there was another bad BGP announcement over the weekend.  This time, a 24-bit network belonging to the country of Kenya was being advertised by Above.net.  The heart of the problem is the same as it was with the YouTube problem a few weeks ago:  someone who wasn’t authoritative for a network began advertising routes to that network.

While this issue didn’t have nearly the impact that the YouTube incident had, just ask the people in Kenya who were offline for several hours while things were broken.  It’s just another item to add to your list of reasons that BGP needs to be fixed.

• Leave a comment... (0)

BGP has issues; the main one being transitive [tag]trust[/tag]. [tag]BGP[/tag] works by having networks (companies, providers, etc.) advertise [tag]routes[/tag] that it owns to its peers. These peers pass those routes on to their peers, ad nauseum, until everyone knows what networks everyone has. The big assumption here is that you are advertising only networks for which you are responsible. The word “assumption” should be emphasized.

The Pakistani government decided that a video on [tag]YouTube[/tag] was bashing Islam, so they ordered the Pakistani Internet services to block it. Instead of filtering from their network out, they decided to advertise via BGP that they were YouTube. To make things worse, they used a more-specific, 24-bit route; since YouTube advertises a 22-bit route, the new Pakistani route is preferred since its more specific. The transitive trust of the BGP cloud allowed them to tell the world that YouTube was on their network, effectively taking YouTube completely off the Internet for few hours. YouTube finally changed their advertising to a bunch of 25-bit networks, which restored connectivity, and, eventually, the Pakistani ASN withdrew the route. Here’s a timetable from Martin Brown of [tag]Renesys[/tag].

Obviously something needs to be done about this. This is not the first time time that someone has (un)intentionally advertised someone else’s routes and took stuff down (The Yahoo! outage from July 2007 comes to mind). I have no solution, but TPTB might want to prioritize finding a more-secure method for controlling an IP space advertisements. Certificate-based peering? More filtering on the transit networks? There’s no good solution, really.

• Leave a comment... (1)