Archive for August, 2012

BGP: Routed or Routing Protocol? Or…NONE LIKE IT HOT!

I think we need to cover something very basic before we get into this discussion:

BGP sucks.

Let’s face it.  BGP is probably the dumbest routing protocol currently deployed.  Even RIPv2 is smarter than BGP.  The other protocols out there (IS-IS [my staff manager fondly calls this Protocol Zero, by the way], OSPF, RIP, EIGRP [this isn’t a real protocol]) do everything auto-magically.  Seriously, it’s like magic sometimes.  Yeah, you have to come up with fancy things like stub areas, NSSA, and all of that jazz from time to time, but really, these protocols largely do everything on their own.  You just tell them the type of area you want them to be in, or that you want the router to be a stub router, or whatever, and they know exactly what you mean.

BGP, on the other hand?  Yeah, good luck.  First, you have to explicitly tell it what devices to peer with.  Then you have to specify the local-address (update-source if you’re a Cisco weirdo).  Then type internal or type external.  And being even remotely intelligent about what advertisements it sends where?  Not happening.


So now that you’re probably thinking I’m uneducated and just don’t understand BGP, let me ease those concerns.

BGP’s inability to function even remotely well on its own is also its greatest strength.  It gives the administrator absolute and total control over precisely how traffic enters and exits his administrative domain.  I’m not going to get into ‘how’ or ‘why.’  Everything I’ve written so far has just been a prelude to what has come before it.  And that is…


As we’ve discussed, BGP is not capable of making intelligent decisions on its own.  It needs direction!  You can’t (realistically) use BGP as your IGP.  While technically possibly, it would be a very, very bad idea.  OSPF and IS-IS (zero protocol!) have a full topology of the entire IGP (at least the backbone does).  On top of that, they have areas that subdivide the network to conserve hardware resources and reduce the size of routing tables.  BGP really can’t do that.  For BGP to even be used as an IGP, you would have to create iBGP peerings based on interfaces and loopbacks, redistribute connected networks, and tune timers because BGP convergence is terrible.  Even then you would run into problems.  An iBGP-learned route does not get advertised to other iBGP peers, right? So you would have to be extra careful to make sure you are peering to everything in known existence in your network (that’s a little overkill, I know).

This all makes BGP incredibly pathetic as an IGP.  Why?  Because it’s stupid.  Very unintelligent.

What does this have to do with anything?

iBGP relies on the underlying IGP to form its iBGP peerings–if they’re based on loopback IPs (which they always should be).  This is because BGP, all by itself, without excessive and hideous configuration, can’t route traffic.  Check out the NEXT_HOP attribute for more information on that.

To make things short and sweet, the next-hop is not changed by default and requires recursive lookups–which are going to depend on the IGP.  And if it’s an externally learned route, well, you’re screwed (without setting next-hop self).

So what happens when packets travel between autonomous systems?  BGP contains an AS_PATH attribute that details the autonomous system path.  But that isn’t really relevant except as a primitive ‘shortest path’ indicator and loop-prevention mechanism.  There’s another attribute, the NEXT_HOP attribute, that does the ‘real work.’  And it doesn’t really do much work.  The router performs recursive lookups and relies on the IGP to get the traffic to whatever it knows the NEXT_HOP is.  And then the process repeats.  The first router in the next autonomous system does the same thing.

So BGP messages are actually routed.  They use the well-known TCP port 179.  This means IP connectivity must be established before messages can be sent and received–ultimately resulting in the establishment of a peering.  This is why, in the absence of an IGP, you would need to manually configure a full mesh of BGP peerings across every link in your network.  BGP has to have that IP connectivity.  These messages get routed across the IGP network to their destination.  TCP sessions are established by making use of the IGP.  In this manner, BGP is actually an application of TCP.

BGP’s Intent

With the above being said, however, what is the intent of BGP?  Why does it exist?  To establish inter-AS communication.  And how does it accomplish this?  By providing update messages containing routes.  Yes, the information contained in these messages is primitive at best, but it does contain the reachability information necessary to traverse multiple autonomous systems.  And that information is a prefix and a NEXT_HOP.  Oh, and that NEXT_HOP thing?  It’s going to rely on an IGP for recursive lookups to that NEXT_HOP in a lot of scenarios.  Because strictly speaking, BGP doesn’t need the AS_PATH to convey this information.  That information does not persist in a given IP packet from point A to point Z (unless that packet happens to be a BGP packet).  The AS_PATH attribute is there to give us finer control over inter-domain routing.  The AS_PATH attribute exists to prevent loops.  It exists to provide some measure of ‘shortest path‘ indication.

Wrapping Up

BGP is an amazing protocol. Extremely flexible, but incredibly stupid. It relies on everything else in the network to be right in order to function properly–more than most things. You can leave out a neighbor configuration for your IGP, but if you leave out a router out of the iBGP configuration, it could be detrimental. It is both a routed and a routing protocol.

I hope this has been informative. This was a concept that I truly did not grasp when I started my new job a few months ago. It has only been since working with BGP on a daily basis and read a few books on the matter (check my bookshelf) that I began to grasp this extremely important–and simple–concept.

As a final note, please find me and smack me across the head if I am wrong on any of the above points. I am still learning (always will be), but I feel pretty confident about the information presented here.

And the ‘Or…NONE LIKE IT HOT!’ thing was just because I was watching Futurama. It has no relevance to this article.

Cisco Exams Are Bad – Again

Some of you may or may not know that I recently had the joys of experiencing another Cisco exam – the CCNP ROUTE exam. I have some pretty negative views on Cisco exams; see my post here for a comparison of Juniper to Cisco exams.

I don’t want to break the NDA that every agrees to when they take the exam, so I will attempt to speak in the most general terms possible.

If someone specifies that the most specific mask should be used when specifying the ‘network’ command under any given ‘router’ hierarchy (and I use ‘hierarchy loosely–see Juniper’s JUNOS for a true hierarchy!), then that mask should be ‘’. How can the mask be anything else? Please note I’m talking about wildcard masks and not subnet masks.

Second, if you are expected to use a simulated environment to answer questions or configure anything, then that simulated environment should actually work. If it doesn’t, then you’re intentionally setting a candidate up for failure–and for absolutely no good reason.

If a simulation does not allow something to happen, then I expect 100% that the average or below-average candidate would definitely fail that question. Only a highly experienced analyst or engineer would know for certain that they were right and that the simulation was wrong. My only concern is this: what if the simulation relies on the success of a given command–whether the failure of that command is the result of misconfiguration or a faulty simulation?

If anyone from Cisco is reading this, please take note. If your simulation software indicates that my verification method is to ping a given IP address and that does not work–even though I have verified the route through the network–this is probably not a good thing. My personal experience has allowed me to confidently continue, knowing I was right. But this could cause the average candidate to second guess his or her work. To be honest, it could even cause an experienced individual to fail if he or she is not a ‘good test taker.’

Perhaps Juniper will elect to progress to a test environment which includes simulations. I hope not, because their current ‘paper’-only methodology works and works well. I would like to think that they don’t use simulations because of the pitfalls of Cisco simulations. Regardless, I once again commend Juniper and look forward to the JNCIS-SP exam in October.

Yes, my BGP post is still coming, but this was quick and easy! 🙂

New Post Coming Soon: BGP

I’ve been gone a while.  Here’s what’s been up.


I am now a Network Analyst I in the Data NOC IP group.
I passed the ICND2 exam and now have my CCNA.
I have taken the ROUTE exam.
I am getting ready for the SWITCH exam.
I will be taking the JNCIS-SP exam in October.

I am working on a post regarding BGP.  Look forward to it!