Home > OSPF, Routing Protocols > Basic OSPFv2 in depth

Basic OSPFv2 in depth

OSPF is one of the core topics of the CCIE R&S lab exam and therefore one should be an expert at it before attending the lab exam.

 In this post I would like to explore OSPFv2 and especially how OSPF uses its algorithm to find the best path to a destination. I will try to cover most of the general OSFP topics such as basic configuration, types of LSAs, Path selection, External path selection with LSA Type 5, Default routing, Conditional Default Routing, the different types of Stub areas, Virtual-links, LSA Type 3 filtering and Prefix filtering with route-maps. I have to admit that this post is quite long 🙂

 For this post I will use the following topology:

IGP: OSPF

Platform/IOS: Cisco 2691/12.4(15)T11 Adv IP services

Introduction

 OSPF was developed by the Internet Engineering Task Force (IETF) as a replacement for the problematic RIP. Version 2 which is still the current version for IPv4 is defined in RFC.2328 (RFC 2328). OSPF is categorized as a link-state routing protocol. The basic concept of link-state routing is that every node constructs a map of the connectivity to the network, in the form of a graph showing which nodes are connected to which other nodes. Each node then independently calculates the next best logical path from it to every possible destination in the network. The collection of best paths will then form the node’s routing table.

 In OSPF the routers use the OSPF Link State Database (LSDB) as an input to Dijkstra´s Shortest Path First (SPF) algorithm in order to find the shortest path to a destination network. That implies that all routers in the same OSPF area have a unique LSDB in order to make correct calculation. In the other category of routing protocol which is Distance Vector protocol like EIGRP, The routing is done “by rumors”. That is to say, the nodes don´t have a full picture of the network like in OSPF and base their routing on which routing information they have learned from their neighbors. So OSPF does not advertise routes but topology information.

 One of the advantages of OSPF is that it uses areas, which reduces the protocol´s impact on CPU and memory, contains the flow of routing protocol traffic, and makes possible the construction of hierarchical network topologies.

 OSPF packets are encapsulated in IP with protocol number 89.

 In order to build the LSDB every router must first have a Router ID (RID) and each router must have a unique RID in the OSPF domain as this value is used to uniquely identify each router in the LSDB. Once we start the process we have to make sure that at least one interface is running IPv4 and it is up/up state and this is the interface which is used to generate the RID. By default the OSPF RID will prefer to use the highest loopback IP address but if there are no loopbacks in the up/up state OSPF process will take whatever the highest IP is on another interface. The RIB should be set manually to avoid depending on a loopback so if the previously used loopback for RIB is shut down it doesn´t alter the OSPF process.

Like in EIGRP, OSPF forms active adjacency with its neighbors and the following parameters must match in order for two OSPF neighbors to form adjacency:

 Authentication, same subnet, same area, no duplicate RIB, Hello and dead timer equal, MTU, STUB flag. In EIGRP for example, the timer are not required to match for forming adjacency.

 OSPF adjacency is going through the following steps before is fully formed between two neighbors:

  •  send Hello(init)
  • send and rcv (2 way)
  • DR election (Exstart)
  • DD excahnge (exchange)
  • LSR/LSU/LSAck (Loading full)

The LSDB is made of LSAs (Link State Advertisements). The LSAs described all of the router´s links, interfaces, the router´s neighbors and the state of the links. There are different types of LSAs because of the varying types of link-state information. When two routers are in the exchange phase they synchronize their LSAs which result in exact LSDB on all routers in the same area so each router can individually run the SPF algorithm on the LSDB to find the shortest path to each destination.

 OSPF process will behaved differently based on the network type it is configured on:

 For example on broadcast network OSPF uses the concept of DR (Designated Router), BDR (Backup Designated Router), and DROTHER (Not DR/BDR). The formation of an adjacency between every router on a broadcast medium will create many unnecessary LSAs so flooding on the network itself would be chaotic and excessive. A router would flood an LSA to all its adjacent neighbors, which in turn would flood to all their adjacent neighbors creating many copies of the same LSA on the same network.

To alleviate this problem a DR is elected on multi-access networks and represents the multi-access network and its attached routers to the rest of the OSPF area and also manage the flooding process on the multi-access network.

All OSFP routers send Hello to 224.0.0.5 to discover eventually neighbors on a multi-access network and form full adjacency only with the DR and BDR while staying in 2 way state between each other. So the exchange of the LSDB is only occurring with the DR and the BDR. DROTHER are sending LSAs information to 224.0.0.6 and only the DR and BDR are listening to this multicast address as well as 224.0.0.5 while the DROTHER are listening to 224.0.0.5.

 I will cover the rest of the OSPF theory during the configuration examples. So let´s start with the configuration of OSPF!

Basic OSPF Configuration

Please refer to the topology located at the beginning of the post from now on. I will start by configuring each router in its respective area as illustrated on the topology. IP address and loopback addresses are already configured. Please not that for now, areas, 6,8,9,7 are not STUB or NSSA as we will talk about that later on.

 Each router-ID will be configured manually under the routing process in the format X.X.X.X where X is the route number.

 So let´s see what is happening as soon as we configured OSPF on R2:

From the Wireshark output above we can see that R2 is sending OSPF hello packets to the multicast address 224.0.0.5 (all OSPF routers) with a frequency of 10 sec. R2 is also identifying itself in the Hello packet with the RID 2.2.2.2 (the one we manually configured). The Authentication is NULL (OSPF uses 3 type of authentication (0,1,2) were type 0 is null, basically it means that packets are not authenticated, type 1 is clear text and type 2 is MD5). You can notice that there is no DR or BDR yet on this segment (connecting to R8) as the OSPF process on R8 has not been started yet. Finally we can see that the AREA number (area 8) is also advertised in the hello packet.

To see how the DR/BDR election process works as well as how the LSDB is exchanged between two routers let´s take the case of R2 and R8 when they start discovering each other through Hello packets:

From the debug output above we can see the different phases we talked about before when OSPF neighbor discover each other through OSPF hello multicasted to 224.0.0.5. After the 2 way state the routers on the multi-access broadcast segment elect a DR and a BDR. The election is based on the DR priority (configured with: (config-if)#ip ospf priority). By default the priority is 1 so if the priority is not configured the DR will be the router with the highest RID. In the output above R2 is elected the DR although R8 has the highest RID. That is because the DR election is not preemptive that is to say that as R2´s OSPF process has been started first, R2 has elected itself as the DR and R8 cannot preempt it. No matter who is elected the DR on Ethernet link as long as devices have full connectivity to each other. But on partial mesh topology like Frame Relay it can be a problem if the DR does not have full reachability to all the nodes.

 Side note: Changing the OSPF priority to 0 on a router prevent it from participating in the DR/BDR election process.

 Once the DR/BDR is elected, database exchange occurs. When routers exchange the LSDB, they just send a summary of all the LSAs they know about which is known as Database Description (DD). OSPF uses the concept of Master/slave for the database exchange which is determined in the exstart phase. The master is the one with highest RIB and the one initiating DD exchange as we can see in the debug output (R8 is the Master).

After the database exchange, routers compare their current LSA with the received LSA using sequence nbr. New LSAs start with 0x80000001 and end with 0x7FFFFFFF. Any change in LSA increase the sequence number. Routers request missing LSA or newer with LSR packet and are being updated with LSU packets (Loading stage). LSR use reliability with 2 options:  receiver of LSU acknowledge by sending same LSU back or send LSA acknowledge packet with list of acknowledged LSA headers. We can see that is what is happening between R2 and R8 in the debug output as they are requesting LSAs to each other and then updating each other LSA´s database (LSDB). Finally we can see at line 30.903 that R2 and R8 are fully synchronized which means that they have an identical LSDB.

We can see the same result in the following Wireshark capture during database exchange between R2 and R8:

R2 is advertising its OSPF database description (DD) composed of various LSAs types. We can see the following LSAs in the Wireshark output:

  •  LSA type 1 which are router LSA that uniquely identify each router in the same area. LSA type 1 informs of number of links and which subnet are connected to the different links. One per router.
  • LSA type 3 which are summary LSA. LSA type 3 are send by ABR or Area Border Router (in this case R2 as it is connected to area 0) to other areas as LSA 1 and 2 are not propagated from one area to another. LSA type 3 represent each subnet/mask+ ABR cost to reach each one in one area.

 Of course there are other types of LSAs which we will talk about later on.

 Alright! Now that all routers have been configured for OSPF based on the topology (see beginning of the post. Also note that Stub areas have not been configured yet) let´s check what the OSPF status of R1 is and which neighbors it can see:

So R1 is only seeing R7 as its neighbor. It should also see R2, R3 and R4 which are the spokes of the Frame Relay network. Note that R1 is the DR for the Ethernet segment as its OSPF process has been started before R7´s OSPF process. Let´s troubleshoot this issue:

So the Frame Relay interface of R1 is configured for OSPF and it is in area 0, good! R1 can also ping R2,R3,R4 through the Frame Relay network, good!

From the debug output above, we can see that R1 is receiving OSPF hello packets from the spokes.

Let´s see if spoke R2 receive OSPF hello packet from R1, the hub:

So R2 is not receiving any OSPF hello from R1. What can be the issue.? Let´s have a look at the OSPF Wan interface of R1:

We can see that the OSPF interface type is NON_BRODCAST on R1 which is the default for Non Broadcast multi-access network (NBMA) like Frame Relay and the default on multipoint Frame Relay interface. With this type of network type OSPF is unicasting hello packet and not multicasting them like on broadcast multi-access segment. So we need to add each spoke neighbor IP address on R1 in order to tell the OSPF process to start sending Unicast Hello packets out each DLCIs. Let´s configure that on R1:

After the above configuration the adjacency is still not coming up. Let´s do some more debug on R1:

As you may remember from the introduction paragraph, Timers must math in OSFP in order for two routers to form adjacency. Let´s check the OSPF network type on one of the spoke, R2, for example:

So the network type differs on the spoke from the one configured on R1 which gives us the issue with the OSPF adjacency as the timers do not match between the HUB and the spokes.

 One way to solve this will be to configure the same OSPF network type on all the routers in the Frame Relay network. So in this case we just change the network OSPF type to NBMA on all spokes. We could also configured network type point to multipoint on the routers in the Frame Relay network which is the best practice with NBMA as the next-hop is changed to be the HUB so you don´t need Frame Relay mapping for all the spokes. Ok, let´s go ahead and configure the following on all the spokes:

Side note: We make sure that the spokes will not participate in the DR/BDR election by setting the OSPF priority to 0.

Once the OSPF network type is configured we can assume that R1 will form adjacency with R2,R3,R4:

This is the case. R2, R3 and R4 are considered DROTHER as they are not participating in the DR/BDR election.

Perfect! Now all routers in area 0 have formed adjacency, let´s check area 1 and 6:

From the output above we can conclude that all the routers in area 1 have formed adjacency and that R3 is the DR for area 1 and 6. Also in area 1 R5 is a DROTHER while R4 is the BDR that means that R5 will form full adjacency with R3 and R4 (The DR and BDR for area 1).

 Let´s quickly check the neighbors of R2:

Good! So all the areas are synchronized as the routers have formed adjacency in their respective areas.

OSPF LSA Types

Let´s have a look at the OSPF database on R2 for area 0:

Based on the LSA type 1 which I explained before, we can see that there are 4 routers in area 0 which are R1, R2,R3,R4. Let´s look at the LSA type 1 for R1:

This LSA type 1 from R1 informs us about R1 connected interface into area 0 which are its Frame relay interface and its loopback interface. Also the cost associated which interface is given which will be used by the SPF algorithm to calculate the end-to-end metric. We can also see that R1 is an ABR as it has some interfaces participating in area 0. One of the Link of R1 is connected to a transit network that is to say that there should be a DR on this transit network which is R1. Also note that the loopback is considered a stub network by default and will always be advertised as /32.

Let´s check the LSA type 2 which is representing a transit network. In this case R1 is the DR and represent the transit network 10.0.0.0/24:

LSA type 2 are sent only on transit network by the DR which informs of attached router connected to himself. Only one DR per transit network. OSPF consider the DR as a “pseudonode” which it must consult first before computing SPF. LSA type 2 are only used for intra-area calculation whereas inter-area calculation use LSA types 3.

 In this case the DR is directly attached to all spokes as R1 is the Hub of the Frame Relay network.

Let´s check LSA type 3 for area 0 LSA type 3 are only sent by an ABR. An ABR is a router connected to area 0 and one or more areas. So in our case we have 4 ABRs in area 0 which are the following:

  • R1 connected to area 0 and 7
  • R2 connected to area 0, 8 and 9
  • R3 connected to area 0, 1 and 6
  • R4 connected to area 0 and 1

The LSDB is identical per area and smaller if several areas are used which implies faster SPF calculation. LSA 1 and 2 are not passed between areas instead LSA 3 are used so the LSDB shrink. LSA 1 and 2 contain detailed topology info and therefore are SPF intensive

 As there are many LSAs type 3 in the OSPF domain we will just take the example of one LSA 3. That is because all the ABRs in area 0 generate LSA type 3 for every network they know about in other areas. Let´s take the example of LSA type 3 for 66.66.66.66 in R2´s LSDB in area 0:

We can see that this LSA 3 is advertised by R3 which is an ABR connected to area 6 where the network 66.66.66.66 is located (R6 loopback IP). As R3 has a connection to both area 0 and area 6 is advertising the networks it knows in area 6 to area 0 and vice versa. Also note that R3 is advertising the metric to reach the loopback of R6 from its point of view (in this case it is 11).

In turns R2 will advertise a LSA type 3 to area 8 and area 9 for the network 66.66.66.66:

The same LSA type 3 will be advertised to area 9. Here the metric is the cost for R2 to reach 66.66.66.66. Let´s check know how the path selection process is working from the perspective of R2 in order to reach 66.66.66.66.

OSPF Path Selection Process

Let´s have a look at the routing table of R2 for the entry 66.66.66.66:

So the total metric is 75 and the route has been advertised by R3 as an LSA type 3 denoted by the type inter area. But how this metric has been calculated? Let´s demonstrate it.

As we saw before the metric from R3 to 66.66.66.66 is 11 and that has been advertised in the LSA type 3 for this network from R3. So now R2 must run SPF on the router advertising this network which is R3 (3.3.3.3 àR3´s RID).

 Side note: This is why OSPF is considered partially distance vector and partially link-state. R2 does not know the detailed information about the path selection that is occurring behind R3 for 66.66.66.66. R2 trusts R3’s calculation for the prefix, which is typically a distance vector behavior, and then calculates the shortest Intra-Area path to reach R3, which is a link-state behavior. The advantage of this design inherent to OSPF is that R2 does not need to run SPF on the entire OSPF topology, which immensely increases scalability.

 Now let’s find out how R2 routes to get to R3:

 OSPF’s Intra-Area SPF determines this by finding out who R2 is directly adjacent with, and what the cost values to these neighbors are. Once this is determined, R2 asks these neighbors who they are adjacent with, and what their costs are to their adjacent neighbors. The process continues over and over until R2 finds the shortest path to the ABR 3.3.3.3. This Intra-Area metric is then added to the LSA 3 metric that R3 is advertising, and results in the end-to-end metric value that is actually installed in the routing table. We can verify this by first finding out who R2 is adjacent with in area 0 by viewing its Router LSA (LSA 1):

R2 sees that it is adjacent with the DR 10.0.0.1 (R1) and that the cost is 64. Therefore R2 must ask the DR who it is adjacent with and what its cost calculation to its adjacent neighbor is:

Since the DR is directly adjacent with R3, R2 infers the total cost to 3.3.3.3 as 64. Since R3 is advertising the metric 11 in its LSA 3 for 66.66.66.66 and the metric from R2 to R3 is 64 we can conclude that the total cost to 66.66.66.66 from R2 perspective is: 64+11= 75 which is the metric we saw before when looking at the routing table of R2 for 66.66.66.66.

 Side note: This calculation process will be the same for all inter-area routes. The SPF is always runs against the ABR (advertising router) and not the final destination. In the same area SPF is runs against the final destination using LSA type 1 and LSA type 2 (if transit network) to find out the shortest path tree to the destination network. Inter-area routing can only occur through area 0 or through a non-backbone area (capability transit).

 Side note 2: We could wonder why R4 is not injecting a LSA type 3 for 66.66.66.66 in area 0 as it learns this LSA from R3 connected to area 6. Well, that is due to OSPF loop prevention mechanism that states that: “An ABR must not reinject a summary LSA learn inside non-backbone from other ABR into same area back into area 0”.

 Alright so now we have seen how the OSPF process is working to calculate the shortest path selection for both intra-area routes (O) and inter-area routes (IA). But how we could change the path that a packet is taking to a destination by changing the OSPF cost? Let´s check that.

 OSPF traffic engineering with cost

 Let´s take the case of R5 loopback IP 55.55.55.55 from a perspective of R2:

From the output above we can observe that R2 as 2 equal paths to 55.55.55.55, one through R3 and the other one through R4. That is because R3 and R4 are both ABR and advertise the same cost (11) to R5 loopback IP located in area 1. Then R2 has the same cost of 64 to both R3 and R4 all connected directly to the DR, R1. The total metric is 75. So how can we change the path to 55.55.55.55 and prefer R3 as the exit point of area 0 to reach area 1. Well let´s look first at the cost of R4 to reach R5´s loopback IP:

We know that R5 is advertising the loopback 55.55.55.55 so from a LSA 1 lookup for 5.5.5.5 we can see that R5 is directly connected to the DR for area 1 which is R3. Let´s do a LSA 2 lookup now on the DR:

So R4 is directly connected to the DR 3.3.3.3 which is directly connected to R5. So let´s make a LSA 1 lookup for R4:

So R4 metric to the DR R3 is 10. So the total metric from R4 to 55.55.55.55 is 10+1=11. So if we increase the cost of R4 connection to the DR to be higher than 10, R2 will choose the path to R3 instead of load sharing between R3 and R4 for the destination 55.55.55.55. Ok, let´s increase the metric of R4 Ethernet interface connected to area 1 to 20 and check the result in the routing table of R2:

Sure enough we now have a preferred path through R3 to reach 55.55.55.55. Just for fun and for information, as soon as we change the metric on R4, R4 sends a unicast update to its connected OSPF neighbor in area 0 (R1) about the change. In the output bellow we can see the new metric from R4 perspective to reach 55.55.55.55 and it is 21:

If we were capturing the next packet from R1 we will that that R1 is acknowledging the update by sending the same packet to R4.

 Side note: The packets are unicast because the network OSPF type is NBMA. If it was in area 1 the LS update will be multicasted.

 OSPF network change reaction time

 Let´s check how fast OSPF is able to react in regards to network changes.  For this example we will shut down the loopback of R5 and see what is happening on R2:

So basically, some milliseconds after we shut the loopback of R5 down R2 received an LS update from R1 saying that the path to 55.55.55.55 via R3 doesn´t exist anymore. The OSPF process of R2 translates this change by setting the metric to 55.55.55.55 to infinite (16777215) for the LSA 3 as we can see in the Wireshark output bellow. Setting the metric to 16777215 will force the OSPF process to remove the LSA from the LSDB.

Alright, that was interesting to see exactly how OSPF behaves in this kind of situation. It is also nice to use Wireshark to see the format of the packets and so on. In the next section we talk about LSA Type 5.

OSPF LSA Type 5 (Autonomous System External LSA)

 Ok, let´s review quickly what a LSA type 5 is. This type of LSAs is created by an ASBR (Autonomous System Border router). An ASBR is a router originating a route into OSPF which is external to the OSPF domain. For example a route from another routing protocol domain or a default route to external destinations. LSA types 5 are the only LSA types in the OSPF database that are not associated with a particular area and they are flooded into all nonstub areas throughout the autonomous system.

There are 2 types of LSA type 5: E1(external + internal metric) and E2(only external metric). E2 are the default.

 Let´s generate a LSA type 5 on R4 by redistributing its loopback into the OSFP domain. From the debug output of R2 we can see the following:

 

So from the output above we can see that the LSA type 5 is received by R2 from R1. The advertising router is R4. We can also see that R2 is forwarding this update to area 8 and area 9 (no shown in the debug output). If we look at a Wireshark capture at the same moment we can see that the LSA type 5 as an external type of 2 and that it is announced by an ASBR which is R4. The metric is 20.

If we look further down in the OSPF domain , for example R8 in area 8 we can see the following debug output at the same instant:

So R8 is receiving the LSA type 5 update from R2 and run the SPF algorithm on the LSA in order to find the shortest path to 44.44.44.44. There is an important point here. Notice the forward address field there equal to 0.0.0.0. That means that the next-hop to reach the network 44.44.44.44 should be the advertising router which is in this case R4 (RID:4.4.4.4). But does R8 know about R4. Let´see:

R8 doesn´t know about router R3 as there are not in the same area. So how can R8 forward packet to the loopback of R4 located in area 1 when it has no knowledge on how to reach R4?

 Side note: With LSA type 3 the Advertising router is always the ABR so routers in other area knows that to reach a LSA type 3 network they should run SPF algorithm on the ABR not on the originating router. But in the case of LSA type 5 propagation, the advertising RID stays the same and it is not “proxyed” by an ABR.

 Let´s find how R8 can calculate the path to reach R4 from R8 perspective.

 When an ABR receives a LSA Type 5 from a device in its own area, and passes it into a different area, a Type 4 ASBR Summary LSA is generated. The Type 4 LSA tells devices in the new area how to forward towards the ASBR which in turn tells devices in the new area how to forward towards the external route.

 So in our case, R2 the ABR informs router in area 8 on how to reach the ASBR R4 when flooding the LSA type 5 from area 0 to area 8. The LSA Type 4 area can be inspected in the LSDB with then following command:

As we saw before, R8 doesn´t know how to reach R4 and R4 is not in the same area as R8. So R8 now knows that it has to make a ASBR LSA Type 4 lookup in order to calculate the path to the loopback of R4 (44.44.44.44). With the LSA Type 4, R8 knows that it can reach R4 through R2 the ABR which is the same recursive lookup that R8 will use to calculate a path to a LSA Type 3. The metric of 64 is the metric that R2 has calculated to reach the ASBR R4.

 So let´s see check the routing table of R8 for 44.44.44.44:

 

The forward metric is the total metric from R8 to the ASBR R4. R8 already knows from the LSA Type 4 that the metric to reach the ASBR R4 is 64 from R2 point of view. So now R8 just need to do a SPF calculation on R2, the ABR to find the total metric to R4 from its point of view:

So R8 adds 10 to 64 which result in a forwarding metric of 74, which is the total metric to reach R4.

 Side note: E2 routes by default don´t take into account path to ASBR, but technically they do by calculating the forward metric. As the default metric for an external type 2 route is 20, the forward metric only matters if there are multiple ASBR originating the same external route so the router will take the path with the best forward metric (the one closest to the ASBR).

 Now let´s redistribute the loopback of R4 as a E1 route (External type 1 route) and see the difference in the routing table of R8:

So now the external route is considered a Type 1 external and there is no forward metric anymore. The total metric is the metric we saw before (74) to reach the ASBR added to the metric of the route itself which is 20. So the total is 94.

 Side note: when several identical routes exist for one destination OSPF don´t use cost when deciding which route to install in the routing table but instead: 1) IA, 2) Inter-area, 3) E1, 4) E2, 5) NSSA type 1(N1), 6) NSSA type 2 (N2). So in our case above E1 will be preferred over E2 routes for same destination.

OSPF Default Routing

 Default routing for non-stub areas in OSPF is accomplished through the origination of LSA Type 5 via the “default-information originate” command. If no default route is present in the routing table, OSPF will not originate a default route which is a desirable behavior in designs with multiple exit points out of the OSPF domain. This behavior can be changed by using the key word “always” after “default-information originate” which skips the checking of the presence of a default route in the table.

If using a route-map added to the command “default-information originate” the origination of a default route doesn´t depend anymore on the presence of default route in the routing table but whether if the return code is true from the route-map. Even if the “always” keyword is used as long as the route-map returns a false, the default route won´t be redistributed. So the important thing here is that when using a route-map the “always” keyword is ignored if used.

 So in our example, if we use the following command on R6, R6 will generate a default route coded as LSA Type 5 E2 with a metric of 1:

Right after the configuration R6 is originating the default route:

So this LSA should have been propagated through the entire domain in all areas apart from stub areas (Prevent entrance of LSA Type 5). Let´s check if R2 has received the default-route:

Sure enough, R2 has received the default route which is an E2 OSPF route with a metric of 1. As we saw before regarding the recursion process with the forward address, here it is the same. As R6 is not in the same area as R2, R2 will do a LSA Type 4 lookup on R6 the ASBR and find out that it should route traffic for the default route towards R3 (ABR) in this case in order to reach 6.6.6.6:

We could also have used the following command on R2:

So to reach 6.6.6.6, R2 should do a LSA 1 lookup on the ABR R3.

OSPF Reliable Conditional Default Routing

 If you look at the topology you will see that R6 is connected to an ISP router. So we could design a case where as long as R6 as connectivity to the ISP, it advertises a default route in the OSPF domain. But if R6 loses connectivity to the ISP the default route should not be advertised into the OSPF domain. To realize this scenario we can use Enhanced Object tracking in combination with a route-map. So let´s configure the following on R6:

Basically we create a place holder route which existence in the routing table depends on the reachability of the ISP router (40.0.0.1) monitored by the IP SLA. Then the route-map tracks the presence of the static route in the routing table. AS long the route-map returns true, the OSPF process will originate a default route in the OSPF domain. So if R6 loses connection to the ISP the IP SLA will return a false code which in turn will trigger the tracking process to remove the route from the routing table which in turn will trigger the route-map to return a false which will trigger the OSPF process to remove the default route from its LSDB.

 Ok let´s verify and shut down the interface connected to the ISP and see what happen in the debug on R6:

So as soon as R6 loses the connectivity to the ISP the OSPF process originate a default route with a metric of 16777215 which basically means that all routers in the OSPF domain should remove this route from their LSDB which will in turn remove the route from their routing table.

OSPF Stub Areas

Alright let´s generate some more external networks on R5 in the range of 50.0.0.0/8 and let´s look at the OSPF database on R8 for LSA Type 5:

As we can see R8 is learning all these external networks from R5 and R4 via R2 the ABR. But R8 as only one exit path out area 8 which is via R2 so recursion for both R4 and R5 points to R2. In a design such as this, stub areas can be used to optimize the OSPF database by replacing the redundant Type-5 External and Type-4 ASBR routing information with default information.

 Stubby areas are designed to increase OSPF performance and to limit type of LSAs allowed to enter an area. There are different types of stub areas, all stopping LSA 5 and 4 to enter. Here are the four stub types that IOS supports:

  •  Stub Areas  -> Suppress LSA Type 5 and LSA Type 4 and replace them with LSA 3 default route
  • Totally Stubby Areas -> Suppress LSA 4,5,3 and replace them with a LSA 3 default route
  • Not So Stubby Areas (NSSA) -> Suppress LSA 4,5 and allow LSA 7
  • Not So Totally Subby Areas -> Suppress LSA 4,5,3 and replace them a LSA Type 3 default route. Allow LSA 7

                Stub Areas

So let´s start by configuring Area 8 as a Stub area:

 Side note: Both R8 and R2 must be configured with the stub keyword for area 8 as the stub flag must match for 2 routers in same area to form adjacency. Otherwise the following log will appear in the debug:

 

Let´s check the OSPF database of R8 now for LSA Type 5 and 4:

So R8 is not receiving LSA Type 5 and 4 longer. Let´s check the routing table:

So all the LSAs Type 5 have been replaced by a default route, announced through a LSA Type 3 by R2. That means that R8 will forward traffic destined to external networks through R2. Moreover the LSA Type 4 announced earlier by R2 is not present anymore in the LSDB of R8 as this LSA was related to the presence of LSAs Type 5.

               Totally Stubby Areas

 The next logical step in further optimizing the database is to summarize the redundant Type 3 Summary LSAs that represent the inter-area routes.

Where a stub area optimizes the database by removing external routes and replacing them with a default route, a totally stubby area will optimize the database further by removing the inter-area and external routes, replacing them both with a default route. This is accomplished by telling the area border router not to inject Type-3 Summary Network LSAs from area 0, hence the no-summary argument used in conjunction with the stub command.

 So let´s configure area 9 as a Totally Stubby Area. First we can check that R9 has LSA 4,5,and 3 in its database:

So R9 has LSA 3,4,5 in its OSPF database. Let ´s configure R2 and R9 as Totally Stubby Area for area 9:

Side note: Note that only the ABR(s) connecting the stub area to area 0 need the no-summary argument on the stub command, since they are the only devices that are allowed to originate Type 3 LSAs. While it won’t “break” the OSPF design to add the command to other routers inside the totally stubby area, it is technically incorrect to configure the option this way. As long as all devices in the area agree on the stub flag in the first place, it is the ABR(s) duty to determine if the area is totally stubby or not.

 Let´s check now the routing table of R9:

R9 has only a default route now and only LSA 1 and 2 are now allowed into area 9. So inter-area traffic will always be routed towards R2.

              Not-So-Stubby-Area (NSSA)

Since all Type 5 LSAs are suppressed from area 9, R9 will not be able to do redistribution into area 9.

The OSPF NSSA option changes this behavior by allowing redistribution to occur within the stub area while still blocking external routes from entering the area through the ABR. This is implemented through a new type of LSA which is Type-7 NSSA External LSA.

Routes that are directly redistributes in a NSSA area are generated as LSA Type 7. Like with LSA Type 5, two types of LSA Type 7 exist, type 1 (N1) and type 2 (N2). N1 similar to E1, considers the metric to reach the ASBR. N2, similar to E2, only consider the metric that the ASBR is advertising for the external route and the value needed to reach the ASBR is known as the forward metric as we saw before.

 Let ´s configure area 6 as a NSSA area:

So R6 is inside a NSSA area now and doesn´t receive LSA Type 5 routes anymore:

In one of the previous paragraph on OSPF Conditional Default Routing, R6 was conditionally originating a default route based on the reachability of the ISP (router ISP on the topology). As LSA Type 5 are not permitted in the area 6 now, the default route is not advertised anymore as LSA Type 5.

 Is the conditional advertised default route being advertised as LSA Type 7?

 

Side note: Actually some LSA Type 7 should be present in the LSDB of R6 and specifically the networks from R5 (50.0.0.0/8 prefix range) because R5 is in an NSSA and it is also an ASBR and by default external routes from a NSSA connected ASBR will automatically be redistributed in the NSSA area as LSA Type 7. This behavior can be prevented by configuring: “area 6 nssa no-redistribution” on R5 in order to avoid unnecessary overhead.

 There are no LSA Type 5 which is the expected behavior but what about the default route? It should be redistributed as LSA Type 7. Well previously R6 was configured as follow in order to redistribute the default route:

This command injects a default route only in regular OSPF areas (backbone area and other regular areas). To inject a default route into an NSSA area, you have to use the area number nssa default-information-originate router configuration command. This command will only advertise a default route if the OSPF router has a default route in its routing table or it if it is an ABR (having at least one OSPF interface in the backbone area).

R6 is not an ABR so a default route must be present in the routing table in order to be propagated through OSPF. As we are using conditional advertisement based on Enhanced object tracking we simply replace the place holder route used in the previous example (see section OSPF Reliable Conditional Default Routing) by a default route tracked by the same tracking number:

The presence of the default route will still be based on the reachability of the ISP monitored by the IP SLA configured earlier.

As soon as we make the change R6 generate a LSA Type 7 for the default route and the metric type is N2 by default.

Let´s see if the route is present in the LSDB of R6:

Alright! That also explain why R3 and R5 did not generate any LSA Type 3 default route in area 6 as it would have been the case if the area was a stub, totally stubby or Not-So-Totally-Stubby area (we will see an example later on).

Because if R3 or R5 will have originated a LSA Type 3 default route into area 6 the LSA Type 3 default route will always been preferred over the LSA Type 7 default route due to OSPF route selection. O IA are preferred over O N2 routes because OSPF don´t use cost for equal routes selection but instead OSPF route type with O routes being the preferred routes over any types (E1,E2,N1, etc).

 Ok let´s check how R1 sees this default route:

R1 sees the route as LSA Type 5 E2 although the route was originated by R6 as LSA Type 7 N2. Well, that is because when a LSA Type 7 is received by the ABR and moved into area 0, the information contained in the LSA Type 7 is translated to a normal LSA Type 5. If multiple ABRs are connected to the NSSA area only one is performing the translation (based on the highest RID). In this fashion OSPF devices outside of the NSSA do not know that the NSSA exists, which is analogous to how confederation works in BGP.

 That means that R3 is the translating device as it is the only ABR in the NSSA area.

 If you look at the LSA in depth on R1 for the default route we get the following output:

As we may have noticed just before the Forward address is not 0.0.0.0 as with stub and totally stubby area. Recall that a forward address of 0.0.0.0 means that the traffic to the destination network should be forwarded to the advertising router IP address and a router outside of the area will use a LSA Type 4 pointing to the ABR in order to route to the destination.

 But with NSSA area the forward address is equal to the originating router IP. This then means whatever our forwarding path is to reach router 6, that’s the path that the traffic towards the external route is going to forward. There could be potential cases where the ABR that is doing the advertisement of the route is not actually the one that is receiving the traffic for the destination. So, with the Type-7 to Type- 5 translation, we’re decoupling the control plane advertisement of the actual prefix from the data plane forwarding to the actual destination. So, in other words, it means that we could be learning the route from router 3, but then, we’re actually sending the traffic towards router 5 (if it had a connection into area 0 like a virtual link for example).

No LSA Types 4 are necessary anymore as forward address lookup replaces the need for the ASBR lookup. Since the forward address is preserved only one router needs to do the translation while the calculation of the final forwarding path stays independent

 Side Note: The forward address is first chosen on the highest loopback that is on the ASBR (R6 in this case) and that is also being advertised into the area. If there is no loopback, the highest interface that is running OSPF and also advertised into the NSSA will be chosen.

 So in this case, when R1 route traffic for the default route it will route towards the IP of R6 loopback (forwarding address) which recurse to R3:

Let´s now see how the forward metric for the default route is then calculated from a perspective of R1:

The metric is the one announced by R6 for the default route which is 1 by default. Recall that this route is originally a N2 route translated into E2 route by R3. The forward metric is the metric to the ASBR in this case R6 and it is only used to make path selection if there were several equals E2 default routes. R1 first calculate its metric to R3 which is 64 ( LSA 1 lookup on R1):

Then to find out what is metric from R3 to R6, R1 does a LSA 3 lookup on 66.66.66.66:

So the total metric from R1 to R6 is: 64+11=75 which is the forward metric we saw in the output above.

                 Not-So-Totally-Stubby-Area

 The Last Stub OSPF area type is the Not-So-Totally-Stubby-Area which uses also the stub flag NSSA.

 Side note: There are 3 types of area: Normal area, a stub area (flag stub) and a NSSA area (flag NSSA).

 Like in Totally stub area LSA type 3,4,5 are suppressed which means that the ABR of this area will originate a LSA Type 3 default route. That also means that it is not possible to originate a default route is this type of area as we saw before with NSSA, because the LSA Type 3 I OA route will always be preferred over N1 or N2 default route.

 With that being said let´s configure area 7 as Not-So-Totally-Stubby-Area:

Let´s check the routing table of R7 now:

Only one OSPF route is now present in the routing table an LSA Type 3, 4 and 5 have been suppressed. However is it still possible for R7 to do redistribution in this area unlike with stub and totally stubby areas. Let´s redistribute the loopback of R7 into area 7 as a N1 route.

 Let´s check on R1 now if the N1 route is present:

 N1 route behaves the same as E1 route in terms of metric calculation. Let´s check how R5 sees this route:

 So the total metric is 104 which is calculated as follows:

 LSA 1 lookup on R3:

LSA 5 lookup on final destination to find the forward address IP:

LSA 3 lookup on the forward address:

LSA 5 lookup on the final destination to find the original metric of the route redistributed:

So the total metric is: 10+74+20=104.

Virtual Links

 If R6 loose its connection to R3 it will also loose connectivity to the rest of theOSPF domain as R3 is the only ABR for area 6 which means that inter-area LSA Type 3 routes can only be advertised by R3. Ok, Let´s try to shut down the link on R3 connecting to area 6.

 As soon as R6 detects that R3 is down (after dead timer expires, 40 sec) SPF will run and check all the LSA Type 3 routes reachability:

Since the ABR, R3 is down all the LSA Type 3 routes are removed from the routing table of R6.

If we check the routing table of R6, there are no OSPF routes anymore:

The ABR, R3 is listed as not reachable in the debug because the LSA 1 for R3 has been flagged as unreachable in the LSDB:

So in order to add some redundancy to this design we could make R5 to act also as an ABR. As R5 has no directly connected link to area 0 we could add a new link to area 0 from R5, create a Tunnel or configure an OSPF Virtual-Link. In this case we will create a Virtual-Link.

 An OSPF Virtual-link allows the creation of indirect area 0 adjacency. This adjacency can be used to repair breaks in the OSPF domain or to solve traffic engineering requirements. In this particular case R5 can virtual link to R3 or R4 who are in area 1 and are both ABR. In this example we will create a VL (Virtual-Link) between R5 and R3:

Side note: The first important point to note about the virtual-link is that the neighbor value specified in the virtual-link syntax is the router-id of the neighbor in the transit area. This means that if for some reason the router-id changes, i.e. a new higher Loopback interface is added, or the router-id command is changed, the virtual-link will fail. The VL neighbors don´t have to be directly connected as long as they can recurse to each other LSA 1

 So Now R5 has a connection to area 0 via the VL:

Which means that R5 is an ABR and that R6 will receive (I OA) route (LSA Type 3) via R5 as the link to R3 is shut down:

Let´s look at the VL on R3:

The cost value is based on the R5´s cost to reach R3 which can be calculated via LSA 1 recursion.

 From the perspective of R1 who is in area 0 we can see that R5 has generated a LSA Type 1 as it is considered to be in area 0 now thanks to the VL:

Ok, let´s turn back on R3 interface connecting to area 6 and see what is the preferred path to reach 88.88.88.88 from a R6 perspective:

Ok it is via R3 and not R5. Let´s find out why?

R6 does a LSA Type 3 lookup on 88.88.88.88:

So R3 advertises a metric of 75 to 88.88.88.88 while R5 advertises a metric of 85 and this due to the fact that R5 to R3 VL metric is 10 so R5 add 10 the metric advertised by R2 for 88.88.88.88+the metric to reach R2:

So R6 is choosing the path via R3.

One way we could change the path to go via R5 instead is to configure R4 serial connection with a lower metric than R1 serial connection. The default OSPF metric on these serial connections is 64. Ok, let´s configure R4 metric on interface s0/0.1 to 1 instead of 64 and check what the status of the LSDB is for the LSA Type 3 summary 88.88.88.88:

So now R6 is installing both paths for 88.88.88.88 in its routing table as the “Routing Bit set on this LSA” is set. That is because now R3 and R5 are reporting the same metric to 88.88.88.88 and this because they both route for 88.88.88.88 via R4 instead via R3 which was the shorter path before. Let´s check:

OSPF loop prevention rule says that: Inter-area routing can only occur through area 0.

 Per RFC 2328, non-backbone area (transit area) can be used for inter-area routing if a better path can be found through them. In Cisco IOS implementation, this feature is controlled by the “capability transit” command configured under the routing process and this feature is on by default which means that in our case inter-area routing will occur through area 1 as the metric is better via R4 than via R3.

Capability transit will only take effect when there a virtual link in an area. If you disable capability transit on R5 and R3 the path to reach 88.88.88.88 will be through area 0 only and not area 1.

 In order to make the path to 88.88.88.88 goes via R5 instead of R3 we can increase the metric on R3 LAN interface in area 1.

LSAs Type 3 Filtering

 We have seen so far that it is possible to filter LSAs by configuring special OSPF areas known as stub, Totally Stubby,Not-So-Stubby and Not-So-Totally-Stubby. But it is also possible to filter LSAs Type 3 on ABR routers.

So for this example let´s consider that we want to filter some LSA3 Type 3 from entering Area 6 to achieve some traffic engineering. Right now R6 prefers to route out area 6 via R5. So by filtering some routes from entering area 6 on R5, R6 will prefer to route through R3 for these specific routes. First let´s check the RIB of R6:

s87

Alright! So let´s say that we wanted to route through R3 for the prefix 88.88.88.88/32 which is the loopback of R8. So let´s configure the following on R5:

s88

Side note: The “in” keyword means: prefix going to this area where “out” would have meant, prefix going out of this area.

 Let´s verify on R6 if the preferred path for 88.88.88.88/32 is via R3 now instead of R5:

s89

Side note: Note that the “from” in the output above is the originator ID of the LSA which is in this case R3 as we have filtered the LSA Type 3 advertised by R5:

s90

OSPF filtering with Route-Maps

As we have seen until know, with OSPF all the routers in the same area must have the same OSPF database which is why you can only do database filtering on the ABRs. However you can filter prefixes that are elected by OSPF to be injected in the global RIB per individual router. So let´s say that we want to prevent the prefix 22.22.22.22/32 from entering the global RIB on R6, but only the one advertised by R5 in order to make sure that we can route through R3 only for this prefix. Before we go ahead we have to make sure that the OSPF SPF algorithm of R6 select both path in the OSPF routing database. We can check that by looking at the routing bit:

s91

So only the path through R5 is elected as the metric advertised by R5 is better than the one advertised by R3. So how can we make the advertised metric equal? Both R5 and R3 are connected to area 0. By looking at the topology we know that 22.22.22.22/32 is the loopback of R2 which is in area 0. So the metric reported by R3 and R5 to R6 is their own metric to reach R2 + the metric of the loopback interface of R2. So let´s look at R3 to find out how it calculates its metric to R2:

s92

So R3 knows that is connected to the DR and it has a cost of 64. Now R3 do a LSA Type lookup to see who the DR is connected to:

s93

The DR is directly connected to R2. So the total cost that R3 will advertise to R6 is 64 +1 (loopback OSPF cost of R2).  But if you remember from the “sh ip ospf 1 database summary 22.22.22.22” above on R6, the metric advertised by R3 is 21 and not 65. The reason of that is that R3 is routing through area 1 (R4) to reach 22.22.22.22 because area 1 is a transit area (due to the presence of the VL) and as we saw before, a transit area can be used for inter-area routing if a shorter path is found through this area. This behavior is enabled by default and can be turned off with the “no capability transit” command under the routing process. Let´s leave it on for this example. So actually R3 and R5 OSPF SPF algorithm is selecting the LSA Type 3 advertised by R4 located in area 1 and that is due the capability feature:

s94

R3 and R5 will only run partial SPF on this LSA as it is a Type 3. . Let´s compare the Ethernet interface OSPF cost on R5 and on R3:

s95

Ok, so to get an advertised equal cost for LSA Type 3 22.22.22.22/32 from R3/R5 to R6, we just change the cost on R3 to be 1 instead of 10. Let´s check the OSPF database on R6 again:

s96

Perfect! So now we can be sure that R6 is load sharing between R5 and R3 for the destination prefix 22.22.22.22 /32:

s97

And it does! So now we can apply route-map filtering to achieve our result by configuring the following on R6:

s98

Alright, let´s check know on R6:

s99

Perfect! The route has been filtered from the RIB but not from the OSPF database:

s100

Side note: In the route-map when you match the route-source, you have to match the originator-ID of the LSA which can be found in the OSPF database or in the “sh ip route” output looking at the “from” filed.

Thanks for reading.

/Laurent

 GNS3 configs

  1. viral
    March 27, 2013 at 13:18

    Excellent Post
    Could you post the GNS3 *.net file.
    Sincerely
    V Patel

    • May 4, 2013 at 16:04

      Sorry for the late reply. I have attached the GNS3 .net file + configs at the end of the post.

      Regards,
      Laurent

      • viral
        May 4, 2013 at 20:37

        thank you Laurent

  2. Dilshad
    May 12, 2014 at 12:46

    Outstanding explanation…Truly beneficial

  3. February 5, 2015 at 02:52

    Wonderful post, it is so comprehensive! Took me a day to digest it!

  4. March 19, 2015 at 09:32

    thank you

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: