Dynamic Routing Protocol Scaling

Back

Welcome, to Routing Protocol Design.

I know this title feels a little misleading; as we just already covered design considerations for the major routing protocols out there, what could this possibly cover? Well, first layer 3 redistribution is an exam topic and I wanted to make sure we covered that, but also summarization and filtering are concepts that apply to all of the routing protocols and are something that should be considered during a routing domain design or expansion. We’ve gone over the importance of summarization in just about each of the routing protocol sections here but I just want to bring it up one last time to really drive home the overall purpose of summarization and its importance. Filtering and redistribution really go hand in hand as often you’ll use both at the same place and time, as you always should if you’re bringing in or expanding to a separate routing domain not under your direct control.

I really find when it comes to route summarization, there’s a pretty big gap between the theory of what we all learn and the actuality of what’s out there in practice. Most of the time you’ll go into an environment and do a little ‘show ip route’ and get back hundreds of routes! Now, I’m not saying people generally try to roll out a suboptimal network from the getgo, but we might not plan well for growth! Once you start getting requests from the company to add a guest network, or unexpectedly you need to support BYOD, or you start having way more than 100 sites in one region, then your plan might fall apart, right?

I wanted to make the point here because a lot of times it doesn’t quite come out right, that we’re not summarizing because our routers can’t handle it. Of course they can, especially modern routers, a few hundred routes is nothing! What you’re really doing is setting up a shield, a barrier where routing changes in that portion of the network end. We remember that summarization points act as a barrier for query messages from EIGRP, and for LSAs from OSPF. So we have protection in the event a route is flapping in some more remote area of your network that it won’t have any effect on the core or other parts of the network. This is really what summarization is for.

As far as sending summary routes, default routing is the ultimate in summaries and is a no brainer if you only have a single point to exit a network. Why does that branch need to know about all the routes in your campus? It doesn’t since everything needs to go out that MPLS anyway, just send a default route. A good point is that you should ‘send’ a default route, so that if you have changes to me made later, it’ll end up being more automatic and you’ll encounter fewer problems than you having to manually go around and adjust static routes at your branch offices.

Route filtering can be done in a few ways, with a route map, distribute list, etc. Cisco is clear on best practice, and really so is everyone else. If you’re redistributing routes from another routing domain, always set a filter so you only receive the routes you expect. The first time the other party decides to add a new subnet that conflicts with yours, you’ll be kicking yourself that you didn’t filter. It only takes a few minutes, and worst case they add something new and call you up or send you an e-mail and let you know it doesn’t seem to be working. So you let them know you put a filter and you’ll add the subnet in, easy as pie. Even worse though is if you cause them an outage window because you add a subnet that conflicts with theirs. So best practice for redistribution is to place a filter on both sides; even if you control both sides, just to prevent accidents from happening and potentially causing significant trouble in your network. The key takeaway here is to trust no one, not even yourself. These safety mechanisms are there for a reason and there’s no reason not to use them when they only take a few minutes to implement.

While we’re on the topic of redistribution, I wanted to go over Cisco’s recommendations. Well, their recommendation is to not do it, at all costs. If you can avoid redistributing, you should, because it adds significant complexity to your network and allows for things like routing loops to happen. The number one reason why people redistribute routes in their own networks is because they’re migrating from one routing protocol to another. In that case though, there’s no need to redistribute at all, and it’ll only be wildly confusing if you do. What you can do, as soon as you spin up OSPF, just enter the ‘distance ospf’ command and tweak the administrative distance, or ‘distance eigrp’ command. Make the administrative distance higher so that those routes never see the light of day. Then when cutover time comes and you’ve confirmed all the routes are being learned successfully, you go back through and do a ‘no router rip’ or just lower the administrative distance and you’ll be using your newly learned routes and you’ll be golden.

Now, for the exam, I’ve seen an administrative distance question on there before, so I’d certainly make sure you know the administrative distances for the major protocols. This isn’t the CCNP ROUTE exam, so you don’t need to know the summary and external ADs of the protocols, but certainly be aware.

Now, if you do have to redistribute, the best way to do it is to tag your routes. Tagging just feels really good. You get to give each route their own little label and then on the other redistribution points, you can say that all routes with that label are no allowed in. This prevents the dreaded layer 3 loop. Otherwise, just looking at this image here, you can see right away what would happen, you’d get a loop with routes referencing in a circle and you’d be hosed. Now, this only comes into play really when you have multiple points of redistribution. If RD2 didn’t exist, you wouldn’t really have a need to tag your routes because you’re likely not going to cause a 1 router routing loop. I do just really want to drive this point home though, even if you’re tagging your routes, filter them too. Make sure you don’t cost them an outage and make sure they don’t cost you an outage. Thanks for coming to the end of Section 3 with me everyone, now let’s finish up with a few practice questions.

© Ben Jacobson.RSS