"no synchronization" in Cisco configurations

▼ This text used to be on the BGPexpert.com home page, but Cisco now includes "no syncronization" in the default configuration, so it's unlikely anyone is still going to run into trouble because of this, so I've moved this to a separate page out of the way.

When you run BGP on two or more routers, you need to configure internal BGP (iBGP) between all of them. If those routers are Cisco routers, they won't work very well unless you configure them with no synchronization.

The no synchronization configuration command tells the routers that you don't want them to "synchronize" iBGP and the internal routing protocol such as OSPF. The idea behind synchronizing is that when you have two iBGP speaking routers with another router in between that doesn't speak BGP, the non-BGP router in the middle needs to have the same routing information as the BGP routers, or there could be routing loops. The way to make sure that the non-BGP router is aware of the routing information in BGP, is to redistribute the BGP routing information into the internal routing protocol.

By default, Cisco routers expect you to do this, and wait for the BGP routing information to show up in an internal routing protocol before they'll use any routes learned through iBGP. However, these days redistributing full BGP routing into another protocol isn't really done any more, because it's easier to simply run BGP on any routers in the middle.

But if you don't redistribute BGP into internal routing, the router will still wait for the BGP routes to show up in an internal routing protocol, which will never happen, so the iBGP routes are never used.

The "no synchronization" configuration command tells the routers they shouldn't wait for this synchronization, but just go ahead and use the iBGP routes.

Permalink - posted 2015-02-04

Comparing open source routing platforms

▼ Over the weekend, I wrote posts about trying out OpenBGPD and BIRD.

Here's a bunch more information about these two and other open source routing software:

• Moving Away From OpenBGPd To BIRD? (PDF), by Jimmy Halim (Equinix)
• Route server implementations performance (PDF)
• Open Source Roundtable (PDF), by Ondřej Filip, Martin Winter and David Lamparter

Basically, OpenBGPD's filtering system has scalability issues, and it uses a lot of CPU in large deployments. And it concerns me that these mention OpenBGPD 4.8 and 5.0, while the website only has 4.6.

And I guess I have some homework: install Xorp, a Juniper-like open source routing platform.

Permalink - posted 2015-02-02

The BIRD Internet Routing Daemon

▼ Yesterday, I talked about my first experience with OpenBGPD. Which of course raised the question: why not use BIRD instead? It's a lot more mature. So I gave it a try.

The BIRD Internet Routing Daemon supports RIP, OSPF, BGP and BFD. Unlike Zebra/Quagga, all the protocols are combined in a single daemon with a single configuration file. I once again made good use of the FreeBSD ports, although BIRD has so many dependencies that the 2 GB drive that I had configured for my VM wasn't big enough...

I edited the included example bird.conf file and got a BGP session working. However, I had somewhat of a hard time: BIRD's configuration system isn't like anything I've used before. But worse, the birdc tool that lets you interact with the daemon is very non-obvious. And although BIRD's documentation is pretty decent for an open source project, it doesn't discuss the operational aspects of BGP. To add insult to injury, birdc doesn't have any built-in knowledge of BGP. Rather, BGP is handled as a generic protocol instance. This means that the built-in tab-to-complete and ?-to-show-options don't show you what you can do. The wiki has a few examples but is still not very helpful.

As such, BIRD is definitely not recommended for casual experimentation with BGP. For that, Quagga or even Zebra (which I can run on my Mac!) are much better, as the way they are configured is more Cisco-like, which means the skills gained are relatively easy to transfer to Cisco or Brocade routers. Or, if that's not important, try OpenBGPD.

On the other hand, BIRD does indeed seem to be much more mature and well-supported than OpenBGPD or Quagga (while Zebra has been dead for a decade): BIRD is currently being used as a route server at several internet exchanges. So for production use, BIRD is probably a good choice. However, expect a shallow learning curve.

(Pet peeve: a steep learning curve implies that you improve a lot in a short amount of time. So something that's hard has a shallow learning curve, not a steep one.)

Permalink - posted 2015-02-01

OpenBGPD

▼ As part of my BGP training course, I explain to the participants that they can get BGP either by buying a router from the likes of Cisco or Juniper, or by running routing software such as Zebra, Quagga or OpenBGPD on a Unix (-like) operating system. Then I always mention that I haven't tried OpenBGPD yet, but I really should.

There's no time like the present, so I decided to take the plunge today.

OpenBGPD is a daemon implementing the BGP protocol that was developed for OpenBSD. So I first tried installing an OpenBSD 5.6 VM, which was pretty painless. Unfortunately, I couldn't get the OpenBSD package manager to install OpenBGPD for me. So I went to www.openbgpd.org (where I borrowed the image above). The latest version of OpenBGPD is 4.6, which is five years old—and it wouldn't compile. I never know whether it's my mediocre Unix skills or an actual show stopping issue in these cases. Update: the mediocre skills. As @tvlooy points out: OpenBGPD is included in the OpenBSD base install.

I then installed a FreeBSD 10 VM, which is also relatively painless but requires a bit more configuration during the installation process. However, FreeBSD has OpenBGPD in its ports system, and it installed from there without issue.

So now for the interesting part: configuring OpenBGPD.

It's really interesting to see a more Unix-like take on running BGP. The de facto standard way to configure and run BGP is the one invented by Cisco: you type configuration commands which are immediately applied to the active configuration. Zebra/Quagga uses the same model, even letting you interact with the daemon using telnet. Juniper, on the other hand, uses a very different model, where you use commands to modify the configuration and then "commit" that configuration (or roll back if necessary, very old school DBMS style).

With OpenBGPD, you simply edit the /usr/local/etc/bgpd.conf file after reading the man page. When you're done, you tell the bgpd to reload the configuration. I like this a lot. Monitoring the state of BGP sessions and the BGP table is done using the bgpctl utility, which lets you run clear and show commands that aren't entirely unfamiliar.

I plan on doing the BGP training course exercises using OpenBGPD myself next week, and see how well everything works in practice. The filtering/policy system seems to be inspired by the PF firewall with its insane "the last match is the one that counts" system, and the link between a filter rule and a neighbor is much less direct than with other systems. But I'm trying to keep an open mind.

OpenBGPD looks fairly mature from what I've seen so far, with one small but annoying omission: although you can configure 32-bit AS numbers in both ASDOT and ASPLAIN formats in the configuration file, bgpctl only shows them in ASDOT format. That means that if you have a BGP session with DE-CIX which has AS 196610, bgpctl will show that session as being towards AS 3.2. I.e., ASDOT notation is two 16-bit numbers separated by a dot (3.2) while ASPLAIN is simply a 32-bit number in decimal (196610). ASDOT was in vogue for a while when 32-bit AS numbers were introduced, but quickly fell out of favor as people realized that making regular expressions that match AS numbers with a dot in them would be very annoying. There's even a three-page RFC explaining all of this.

Permalink - posted 2015-01-31