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!

Juniper Exams vs Cisco Exams

Juniper exams are interesting.  I’ve written before that they expect you to understand a lot of the underlying concepts before you take the exam.

The exams are entirely written.  They’re multiple choice, single answer and multiple choice, multiple answer.  This format works well, and even with this format they’re extremely difficult questions.  I, for one, am glad there are no labs or drag and drop questions.  Why?

I took a Cisco exam, the ICND1 or CCENT exam.  On this exam was a simulator.  In this simulator a question was asked inquiring about a connectivity issue.  Using the show interface <if-name> command revealed that the interface was up and up.  The problem is that this wasn’t an option in the answers.  And none of the other options were valid, either.  I was at an impasse.  Four options, none of them valid answers.  In desperation, I issued the show ip interface brief command.  I was shocked and amazed to discover that this command showed a different status for the interfaces than the show interface command.  I had my answer, but I almost missed a question because show interface and show ip interface brief showed two completely different statuses for an interface.  They should have had the same output, regardless of what Cisco was looking for.  This question was extremely unfair and very poorly designed and executed.

Because Juniper doesn’t use simulators, it doesn’t suffer from this problem.  Whether these potential bugs or “features” are the reasons for them not using simulators or not, I applaud them.  I cannot praise the simplicity of the Juniper Networks certification exams enough.  Without the complexities, there are fewer potential bugs or issues.  Yet their exams are still difficult enough to ensure their own validity and to validate the knowledge and skills of their candidates.

Juniper, please learn from this post and keep these points in mind.  I fully believe that simulators and the like can, will, and have prevented otherwise successful candidates from passing their exams.  I am even more displeased with Cisco after taking their exams.  And I’m more impressed by Juniper for avoiding the pitfalls that Cisco suffers from.

JNCIS-ENT Flashcards Now Available!

Sorry for the lack of updates. I’ve been spending some time with the Proteus Networks (twitter, website) Proteus Elite service and studying for the JNCIS very hard. I’ve also been very ill the past two weeks.

However, today, I bring you excellent news! I have created JNCIS-ENT flashcards! All questions and answers come directly from me–no other sources were used other than the Juniper FastTrack Routing and Switching guides for JNCIS-ENT.

Currently, the flashcards are available only in Microsoft Office format. I encourage you strongly to use only Microsoft Office to open this file if you wish to print them out and use them. There are some formatting discrepencies when you try to use Google Docs or Open Office/Libre Office to view this file. Later this week, I will be adding more cards, and at that time I will also make available versions that will format and print correctly when opened with Google Docs and Open Office/Libre Office.

JNCIS-ENT Flashcards

For the Love of Networking or How I Learned to Stop Worrying and Love the Bomb

People usually tell you to do what you love. What they may not tell you is that you probably shouldn’t do something unless you love it.

There are obviously exceptions to this. If you need the work and can’t get anything else, you have to do what you have to do. However, with IT, the rule of “do what you love” seems particularly harsh.

I realize more and more that, with IT in general, if you don’t love what you do, you won’t get very far. You’ll probably work at a Tier I help desk for the rest of your life. While someone has to do it (and while it can be an art itself), I think most people aspire for more. Unfortunately, if you don’t love it, you won’t get any further.

As I study for my JNCIS, I have realized more and more that if I didn’t really want this, there’s no way I could pass it honestly. Sure, I could use a brain dump (read here for why not to) and pass, but that wouldn’t get me very far. I would either bomb every interview or get lucky, get hired, and then get fired within 30 days as my employer realizes I cheated on the test.

This stuff isn’t extremely simple. It’s not overly difficult, but you’re going to hate it if you don’t crave it. And if you hate it, how far do you realistically expect to get?

If you love it, don’t worry. It will all come with perseverance and dedication. Just study, ask questions, and delve deeper and deeper.

JNCIS-ENT Question of the Week #1 –


Aggregate Routes and Generated Routes are very similar. What is one of the biggest differences between the two?


Generated routes have a next-hop value of the first contributing route, whereas aggregate routes have a next-hop value of reject. Chris has it.