Category: Network

  • Why EIGRP is the only IGP that does unequal-cost load balancing

    (This is a REALLY old post that never got finished because for the most part the research never was complete. I finish it now because I feel that the answers are, for the most part, readily available and the topic is not complete speculation.)

    -ORIGINAL POST IDEA-

    I’d always kind of wondered about a few things about EIGRP:

    1. First, if EIGRP is so good (let’s not debate), then why doesn’t Cisco just make it available so that other people can implement it?
    2. Why is it that EIGRP is the *ONLY* IGP that does unequal-cost load balancing?

    So, for number #1: since my original interest in this issue, Cisco actually has opened up EIGRP. See also http://blogs.cisco.com/getyourbuildon/cisco-opens-up-eigrp/

    My speculation about #2, and why I think that it will work on Cisco and not others “out of the box” is that it is integrated into the fowarding engine.

    -NOWADAYS-

    Here is my after-the-fact breakdown:

    In early 2009 I had a load of time on my hands as I was unemployed, and didn’t want to go outside until it was warm again. I had the money to do so, so it wasn’t a problem. In the meantime, I was studying a bunch of Cisco stuff so that I would be all set to get a job when Chicago thawed. During this study, I noodled around with all of the protocols in the CCNP book I had on hand in order to be ready for any interview question someone threw at me. In labbing things up in GNS3, however, something occurred to me. OSPF and IS-IS were amazing protocols that EVERYONE used. EIGRP was also really amazing, but no one could use it because it was Cisco only. What a downer if you’re an all Cisco network running EIGRP and all of a sudden you want to introduce a really cool device that isn’t made by Cisco! So I started digging in to what made EIGRP so special. There were a bunch of oddities that I more or less sorted out with packet sniffing. One was the fact that the header described in most books depicts a 24 bit field for the subnet. Sounds fishy, right? What if I have a /29? Well… packet capture revealed that it actually changes that header field dynamically based on need. Neat. I guess. Anyway, the big thing was STILL the fact that EIGRP was the only protocol that could do unequal-cost load balancing. How odd. Though it is kind of a dumb idea in most circumstances, I can see that there are some edge cases that maybe you want to do something like this. Though… really, if it comes down to that, it is probably still not a good idea. It is a neat academic idea, though not a good (in any way) production one.

    New shit has come to light, man. http://www.cisco.com/c/en/us/support/docs/ip/enhanced-interior-gateway-routing-protocol-eigrp/13677-19.html

    So it appears that I was right about CEF being key in the whole thing. Maybe that is a no brainer, but I give myself at least a little bit of credit for thinking through that part.

    Anyway, hopefully we can see some quality EIGRP implementations elsewhere, but with the advent of SDN, I’m not 100% certain who will care about a non-programmable routing protocol at this point. We’ll see.

  • The Relationship Between LSA Types and Special Areas

    As interesting as it may be, the details of OSPF can be a bit daunting. A big part of that is that there are types of this and types of that all over the place. Two important types that you’ll use a lot and should know pretty well are area types and LSA types. I’ve come up with a pretty good way to learn both and to correctly associate the two.

    To save you some time if you are already familiar with OSPF and just want to get the skinny, here it is (we’ll recap at the end too):

    1. Type 1 and 2 LSAs don’t cross ABRs, ever.
    2. “stub” means type 5 LSAs go away.
    3. If you see the word “totally” then type 3 and 4 are out too.
    4. If you see the words “not so” then type 7 are in use and you are dealing with an ASBR somewhere in the stub area.

    OSPF Special Area Types

    OSPF has a few extra types of areas aside from your standard, run-of-the-mill area. All of the special area types revolve around the term “stub”. A stub area is an area that only has 1 way in and out (as far as the OSPF process is concerned). Their purpose typically has to do with minimizing the utilization of memory, CPU, and bandwidth by limiting/filtering certain types of link-state announcements the areas send and receive. The flexibility required to make this possible is actually where the link-state announcement (LSA) types come into play.

    Aside from a regular OSPF area, Cisco routers support the following area types:

    • stub areas
    • not-so-stubby areas (NSSA)
    • totally stub
    • totally stubby not-so-stubby areas

    OSPF LSA Types

    I’ll keep this part as short as possible, but keep in mind that one could go on for pages discussing LSA type specifics. There are 11 types of LSAs in OSPFv2. For our discussion, I’m going to just tell you what a hand full (plus 1) of the LSA types are and what they are for, then we’ll get down to associating them to the various area types.

    Type 1 LSAs are your standard intra-area link-state announcement. There is nothing special about them, they just do their job, punch the clock, and head home. These are the bread and butter of intra-area routing.

    Type 2 LSAs only, only, only come from a DR (designated router). Remember those? They are the elected (by priority or by router-id) official of the broadcast network. Type 2 LSAs come from the DR to tell the rest of the world who is attached to the broadcast link.

    Type 1 and 2 never cross area borders, and by virtue that the protocol is link-state, you can’t keep them from moving about the area.

    Type 3 LSAs are summaries of routes that are sent inter-area.

    Type 4 LSAs are also summary routes, but they specifically deal with ASBR (autonmous system boundry routers). In fact, the only thing that they do is provide information about the ASBR.

    Type 5 LSAs are used to deliver external information. This is the information that is learned from outside of OSPF and was introduced by redistribution at some point.

    Type 7 LSAs are the same as type 5 LSAs. Redundant? Kinda, but hang in there, there is a reason for it. As stated above:

    1. Type 1 and 2 LSAs don’t cross ABRs, ever.
    2. “stub” means type 5 LSAs go away.
    3. If you see the word “totally” then type 3 and 4 are out too.
    4. If you see the words “not so” then type 7 are in use and you are dealing with an ASBR somewhere in the stub area.

    Now that you know what the LSAs are, what the area types are, and these rules, let’s try to figure out what kind of LSAs are allowed to cross the ABR for the following special area types:

    1. stub
    2. not-so-stubby
    3. totally stubby
    4. totally stubby not-so-stubby area

    All of these are valid area types on Cisco routers.

    So with the 4 rules in mind, starting with example #1. We won’t have type 1 or 2 for sure – they never cross an ABR anyway. “stub” means that we won’t have type 5. As it looks, we’ll be permitting type 3 and 4 (summaries), blocking 5 (info from outside of OSPF), and letting everything else through.

    Example 2 is the same as above, only it has our key words of “not-so”. That means that even though we’re not letting type 5 through, we’re allowing type 7. When the type 7 hit the ABR, they get translated into type 5 to go out to the rest of the network. This may seem stupid on the surface, but digging deeper reveals the point. The key is that we’re saving our area from processing all of the type 5 LSAs from all of the other areas. Let’s say we have enough power (processor/memory, etc) to process our own area’s information, but we’re not able to handle dealing with everyone else’s.

    Example #3 is the most efficient of any of these. Looking at the rules we see that stub filters type 5, and “totally” filters 3 and 4. Since we know that ABRs don’t transit type 1 and 2, we’re pretty much done. So how does it work? Well, the point of a stub, if you recall, is that there is only 1 exit point for the network. So…. OSPF just sends a default route and that is it. Intra-area routes within the stub area are still going to make their way into the LSDB and the routing table, but the only way out to the rest of the world is via the default route.

    Example #4 is like #3, but type 7 LSAs get through for the same reason as example #2. Did you get all that? =) We filter everything, but we have an ASBR somewhere within our totally stubby area. As such, we need routes that are being introduced to us from that avenue to be sent out to the rest of the network. We send type 7 LSAs to the ABR, it changes them to type 5 on the way out, and everyone is happy.

  • Manipulation of Administrative Distance

    For a variety of reasons you may want to keep routes that have been learned by a routing protocol from reaching the forwarding table or for a less “believable” protocol to take precedence over a more “believable” protocol. In this post we’ll explore some of those options. We do this to the end that knowing about these options gives you the flexibility to use them, in addition to being aware that someone else may have used them and that is why routes that you are expecting to see in the routing table are not there.

    While you may know that administrative distance is there and know what it is for, you should also be aware that it is very configurable. You may not have known, but…

    • You can change the administrative distance for an entire routing protocol.
    • You can change the administrative distance for a type of route within a routing protocol (OSPF: internal, E1, E2, ISIS: L1, L2).
    • You can change the administrative distance for a specific subnet.

    Pretty neat, huh?

    To change the AD for an entire routing protocol, the method depends on the protocol, but they are all really similar. No matter which routing protocol you’re using, the AD always gets changed under the routing process. In this example we’ll use OSPF.

    First lets check out what OSPF’s contribution to the routing table looks like before we start noodling.

    P1R1#sh ip route ospf
         10.0.0.0/24 is subnetted, 4 subnets
    O IA    10.1.2.0 [110/65] via 10.1.0.2, 00:01:39, Serial1/1
    O       10.1.4.0 [110/2] via 10.1.1.3, 00:01:39, FastEthernet0/0
    P1R1#

    There we are, good old standard OSPF all around. We have an inter-area route and an intra-area route. Let’s make some adjustments.

    P1R1#conf t
    Enter configuration commands, one per line.  End with CNTL/Z.
    P1R1(config)#router ospf 1
    P1R1(config-router)#distance ?
      <1-255>  Administrative distance
      ospf     OSPF distance
    
    P1R1(config-router)#distance 120
    P1R1(config-router)#

    That’s it. Now when we back out of the routing process and go to an exec prompt, we can see the fruits of our labor:

    P1R1#sh ip route ospf
         10.0.0.0/24 is subnetted, 4 subnets
    O IA    10.1.2.0 [120/65] via 10.1.0.2, 00:00:01, Serial1/1
    O       10.1.4.0 [120/2] via 10.1.1.3, 00:00:01, FastEthernet0/0
    P1R1#

    Notice that the OSPF routes have an administrative distance of 120; mission accomplished. Next let’s talk about just altering the administrative distance for just one route type.

    P1R1#conf t
    Enter configuration commands, one per line.  End with CNTL/Z.
    P1R1(config)#router ospf 1
    P1R1(config-router)#distance ospf ?
      external    External type 5 and type 7 routes
      inter-area  Inter-area routes
      intra-area  Intra-area routes
    
    P1R1(config-router)#distance ospf intra-area 130
    P1R1(config-router)#end
    P1R1#sh ip route ospf
         10.0.0.0/24 is subnetted, 4 subnets
    O IA    10.1.2.0 [120/65] via 10.1.0.2, 00:00:05, Serial1/1
    O       10.1.4.0 [130/2] via 10.1.1.3, 00:00:05, FastEthernet0/0

    Now, for routes that are intra-area, that is, routes within our current area of area 1, we have an AD of 130 while every other route learned via OSPF should be still at 120 (from before).

    We can remove the statements, and we’re back to scratch.

    P1R1#conf t
    Enter configuration commands, one per line.  End with CNTL/Z.
    P1R1(config)#router ospf 1
    P1R1(config-router)#no distance 120
    P1R1(config-router)#no distance ospf intra-area 130
    P1R1(config-router)#end
    P1R1#sh ip
    *Feb  4 19:13:56.863: %SYS-5-CONFIG_I: Configured from console by console
    P1R1#sh ip route ospf
         10.0.0.0/24 is subnetted, 4 subnets
    O IA    10.1.2.0 [110/65] via 10.1.0.2, 00:01:39, Serial1/1
    O       10.1.4.0 [110/2] via 10.1.1.3, 00:01:39, FastEthernet0/0

    From here, let’s look at changing the AD for just a specific route. Maybe we want to leave everything intact with an AD of 110, but for a single subnet. In this example we’ll change 10.1.4.0 to an AD of 155. This is a bit more complicated than the other options because we are adding the extra step of creating an access-list to match our networks. Next, the syntax is a bit different than what we have been working with so far. We start off with “distance 155″ much like the first part of this exercise, but then we quantify the routing source before we reference our access list. This allows us the opportunity to be even more granular with our matching. While I won’t go too much further into this here, let’s just say that you could keep  your normal AD set except for when you get the route from a certain router. Here I am going to say that 0.0.0.0 (any IP) and wildcard mask 255.255.255.255 (all “I don’t care” bits) so that any route source (any router) that sends us routes matching access-list 10 (10.1.4.0/24) matches and will set the AD to 155.

    P1R1(config)#access-list 10 permit 10.1.4.0 0.0.0.255
    P1R1(config)#router ospf 1
    P1R1(config-router)#distance 155 0.0.0.0 255.255.255.255 10
    P1R1(config-router)#end
    P1R1#
    *Feb  5 00:09:25.134: %SYS-5-CONFIG_I: Configured from console by console

    With the configuration complete, we’re ready to check out how we did. Fingers crossed…

    P1R1#sh ip route ospf
         10.0.0.0/24 is subnetted, 4 subnets
    O IA    10.1.2.0 [110/65] via 10.1.0.2, 00:02:30, Serial1/1
    O       10.1.4.0 [155/2] via 10.1.1.3, 00:02:30, FastEthernet0/0
    P1R1#

    There you go!

    For a final note on our Administrative distance portion I want to remind you that the higher the value of the administrative distance, the less believable it is considered by the router. Also, be aware that if you set an AD to 255, it will NEVER get into the routing table. Take a look…

    P1R1(config)#router ospf 1
    P1R1(config-router)#distance 255 0.0.0.0 255.255.255.255 10
    P1R1(config-router)#end
    *Feb  5 00:51:55.398: %SYS-5-CONFIG_I: Configured from console by console
    P1R1#sh ip route ospf
         10.0.0.0/24 is subnetted, 3 subnets
    O IA    10.1.2.0 [110/65] via 10.1.0.2, 00:00:05, Serial1/1
    P1R1#

    Not there. But what’s this? It *IS* in the link-state database! Check it…

    P1R1#sh ip ospf database

    OSPF Router with ID (10.1.1.1) (Process ID 1)

    Router Link States (Area 0)

    Link ID ADV Router Age Seq# Checksum Link count
    10.1.1.1 10.1.1.1 1110 0x8000000D 0x00ED69 2
    10.1.2.2 10.1.2.2 1018 0x8000000B 0x00CA8B 2

    Summary Net Link States (Area 0)

    Link ID ADV Router Age Seq# Checksum
    10.1.1.0 10.1.1.1 1110 0x8000000B 0x0076A2
    10.1.2.0 10.1.2.2 1018 0x8000000B 0x005EB7
    10.1.4.0 10.1.1.1 847 0x8000000B 0x005FB5

    Router Link States (Area 1)

    Link ID ADV Router Age Seq# Checksum Link count
    10.1.1.1 10.1.1.1 1110 0x8000000C 0x00BC36 1
    10.200.200.13 10.200.200.13 863 0x8000000C 0x00B2E7 2

    Net Link States (Area 1)

    Link ID ADV Router Age Seq# Checksum
    10.1.1.1 10.1.1.1 1110 0x8000000B 0x009AC5

    Summary Net Link States (Area 1)

    Link ID ADV Router Age Seq# Checksum
    10.1.0.0 10.1.1.1 1129 0x8000000B 0x00F9E0
    10.1.2.0 10.1.1.1 1129 0x8000000B 0x00EDE9
    P1R1#

    There you have it. The AD of 255 killed the 10.1.4.0/24 route.

    That pretty much wraps up this post. I hope you enjoyed our little adventure in manipulating administrative distances – I know that I’ll have a hard time sleeping tonight =). Please email if you have any questions or comments, or if you feel that something was not clearly explained or if you feel that something is in error.