In this blog post we are going to discuss some OSPF features related to convergence and scalability. Specifically, we are going to discuss Incremental SPF (iSPF), LSA group pacing, and LSA generation/SPF throttling. Before we begin, let’s define convergence as the process of restoring the stable view of network after a change, and scalability as the property of the routing protocol to remain stable and well-behaving as the network grows. In general, these two properties are reciprocal, i.e. faster convergence generally means less stable and scalable network and vice versa. The reason for that is that faster convergence means that the routing protocol is “more sensitive” to oscillating or “noisy” processes, which in turn makes it less stable.

Incremental SPF

The classic Dijkstra SPF algorithm complexity (or roughly saying, the process run-time) depends on the particular network topology, but it is said to be proportional to N*log(N) in a non-densely connected topology, where N is the number of nodes in the area, see [RFC1245]. The computation complexity used to be a limiting factor for old, slow routers of the 90’s, where a single SPF run could hog the CPU dramatically. Modern routers take an order of tens, max hundreds of milliseconds for single full SPF runs even for the largest topologies. The runtime could be further reduced using the SPF algorithm optimization know as incremental SPF, which has been developed quite some time ago see [ARPOPT] (notice the year 1980 on the paper and the  name of the main author – it’s no other than Eric Rosen!).
The implementation might look a bit sophisticated, but the main idea of iSPF is keeping the SPT structure after the first SPF calculation and using it for further computation optimizations. As you remember, the goal of SPF is building an SPT (shortest-path tree) on the network topology graph, rooted at the node that runs the computations. Look at the sample topology (taken from [JDOYLE]) and the SPT for router R1 below:

If R1 would retain the SPT after SPF calculations (at the expense of extra memory) the following three properties could be used for SPF calculation optimization:
Property 1 If a node added or removed to or from the topology appears to be a leaf node to the saved SPT, there needs to be a very simple computation performed to add new routes. Essentially, the existing tree is simply “extended” by one node and distance-vector like computations can be performed:

The same optimization property might be utilized when a stub link is added or removed to or from any node in the network.
Property 2 There is a link failure, and the link is NOT part of the saved SPT. For example, consider the link between R4 and R5 fails. This link is not part of the saved SPT, and therefore, there is no need to perform any SPF calculation at all!

Even though there is great benefit in not making any SPF calculations, it’s hard to predict how many link failures would cause such effect. Besides, different routers would have different SPTs and a link failure that does not affect one SPT, might affect the others.
Notice that in the case of transit link addition or link cost change, i.e. in the case when graph “connectivity” increases, this property would not work and the new tree should be built.
Property 3: The last property is more generic. Assume there is a transit link failure in the topology and it affects a part of the saved SPT, which means properties (1) and (2) do not apply. For example, imagine there is a link fault between R2 and R4. Still, we only need to re-calculate the paths for the nodes downstream of the failure, based on our existing SPT. So the router would initiate SPT calculations from R1 to R4 only, not ever bothering with other nodes. However, if there is a link failure between R1 and R5, then the router would have to recalculate the paths to R5, R6 and R7 – the nodes on the downstream tree under the failed link.

One effect is that the father away from the root node the failure is, the less computations potentially have to be done. Even though remote link failures take more time to propagate to the local node via LSA flooding, they result in shorter iSPF run-time, as the amount of downstream affected nodes is smaller. Once again, since different routers have different SPTs for the topology, the same failure may have different effects on iSPF efficiency for different routers.
Another important fact is that this feature performs better in sparsely connected networks. In the asymptotic case of a fully-meshed topology, a single transit-link failure would cause re-running the SPF for all nodes, resulting in the same performance as classic SPF.

iSPF and PRC

Among all the iSPF properties, property (1) is probably the most important and effective in practice. This property puts OSPF on par with the Partial Route Computation (PRC) feature found in IS-IS. The PRC feature made ISIS very effective in situations when new stub links were added, as ISIS propagates network reachability information separately from topological information, thanks to LSP’s TLV-based structure. Different TLVs are used for IS-node reachability information and network prefixes associated with the node. When an ISIS router receives an LSP that only lists network prefix change, it performs partial SPF recalculation, based on distance-vector logic, by adding the new prefix in the routing table with the cost of reaching the originating router, similar to property (1). Only a change in the transit link status would trigger full SPF computation in ISIS.
In the past, the PRC feature made ISIS more scalable for a single area design when compared to OSPF. The problem with OSPF was that topological information and network reachability information for router links were conveyed in a single type-1 LSA. Whether there was a transit link failure or simply a stub link going up or down, OSPFv2 had to perform complete SPF calculation as this was reflected using the same event that would report a network prefix or metric. Only type-3 and type-5 LSAs would have triggered PRC in OSPFv2. There was a trick to make better use of PRC with OSPFv2 – advertise all connected interfaces via redistribution, which resulted in type-5 LSAs being flooded. However, the tradeoff was that type-5 LSA’s flooding scope was the whole routing domain, plus type-5 LSAs have the largest size among other LSA types, not to mention slightly added configuration complexity.
The introduction of  iSPF made OSPF as effective as ISIS as far as SPF computation goes. To be fair though, we should mention that iSPF was also added to ISIS, so now both protocols are equally effective for SPF computations. By default, iSPF is disabled and could be enabled using the command ispf under the routing process configuration mode. By enabling iSPF you will make OSPF use slightly more memory than by default, propotional to the 2*N where N is the number of nodes in the area. This due to the fact that a spanning tree for N nodes has exactly N-1 edges.

LSA Group Pacing

As you remember, OSPF LSAs have two important attributes – age and checksum. The age field is needed to guarantee wiping of the outdated information and the checksum is needed to maintain the information integrity. By default, the maximum LSA age is one hour, and the originating router is supposed to re-flood the LSAs every 30 minutes. In addition to that, the router needs to run periodic check-summing on all LSAs.
The way Cisco routers originally did that was by running a refresh procedure every 30 minutes and refreshing every self-originated LSA in the database, no matter how old it was. This would result in sudden CPU spikes every 30 minutes in case of large databases in addition to bursty LSA flooding. Every router in the routing domain in turn would have to receive and process a large amount of LSA information. This is a good example of a “synchronization” problem. In addition to this refreshing, every 10 minutes a router would run periodic check-summing and an aging procedure, and flush any aged non-self-originated or corrupted LSAs.
In order to alleviate the 30-minute refreshing problem, Cisco IOS implemented an independent aging procedure for every LSA in the LSDB. A short period scheduler would scan the database and decrement every LSA’s age individually. Only LSAs that were close to their “half-life” of 30 minutes would be re-flooded. This is the opposite of doing a “complete” refresh every 30 minutes. However, this process would result in many quick floods during the 30-minutes interval, as a result of independent aging. This might be viewed as a “fragmentation” problem.
The “balanced” solution is known as “group pacing”. Instead of refreshing an LSA instantly as soon as it reaches its half-life age, the router would wait a “pacing interval” amount of time to group various LSAs with similar age. The pacing interval is normally shorter than the 30 minute “grand interval” and defaults to 240 seconds. Thus, a router would attempt to group LSAs with similar lifetime and refresh them simultaneously.

Look at the diagram above for the illustration of the concept. Original refreshing procedure would produce large bursts of LSA flooding every 30 minutes. The individual aging would result in fragmentary re-flooding. The group pacing feature would introduce controlled bursting – the shorter the interval, the smaller are the “bursts”.
The same pacing concept could be applied to check-summing and aging. Specifically, if we run individual timers for ever LSA, and aim at check-summing and aging every 10 minutes, we would get the same fragmentary “CPU-spiking” patterns. Instead of running the process individually for every LSA, grouping based on the same group pacing interval could be used for the purpose of check-summing and aging, so a small batch of LSAs that are close to being aged out or check-summed are processed together.
The IOS commands to control the various group pacing intervals are:

timers pacing ?
  flood           OSPF flood pacing timer
  lsa-group       OSPF LSA group pacing timer
  retransmission  OSPF retransmission pacing timer

The LSA group interval is used for the refreshing/aging/checksumming grouping discussion above. The “retransmission” keyword is a bit more interesting. Every time the router needs to retransmit an un-acknowledged LSA over an adjacency, it might wait some time to group it with other un-acknowledged LSAs. This is the same grouping principle, which allows for better packing of LSA information in IP packets. Of course, the “retransmission” grouping interval is much shorten than LSA grouping and measured in milliseconds.
The “flood” keyword serves a similar purpose, but controls the interface LSA flood list. For every interface the OSPF process keeps the “flood list”, which contains the LSAs that have been generated or received and are destined to be flooded out of this interface. Instead of flooding every LSA as soon as it hits the list, the OSPF process would wait the “pacing interval” for more potential LSAs and pack them in a single update packet. This process optimizes bandwidth and CPU usage on both sides of the adjacency. Of course, the resolution for this timer is set in milliseconds, due to the real-time nature of the process.
So what are the optimal group pacing timer values? Probably the defaults, which could be found as follows:

Rack1R5#show ip ospf | inc transmission|pacing
 LSA group pacing timer 240 secs
 Interface flood pacing timer 33 msecs
 Retransmission pacing timer 66 msecs

For very large LSDBs, you generally want to set the LSA group pacing timer to be inversely proportional to the size of database. This ensures less “surges” when flooding large LSA batches. Keep in mind that tuning LSA group pacing improves OSPF performance and thus protocol scalability, but does not affect convergence speed.

SPF and LSA Generation Throttling

Throttling is the general process of slowing down responses to the frequently oscillating events such as link flaps. The general idea is to reduce resource wastage in unstable situations and wait till the situations calm down. If you have a link that flaps up and down frequently, you may want to suppress the links state information flooding until it becomes stable (either stable down or up). Throttling is critical for ensuring network stability and thus protocol scalability. This procedure is also very similar to event dampening, though they differ a little bit – dampening would suppress events while throttling simply increases the response times, hoping that oscillations would stop or at least the responses do not follow the same oscillating pattern but filter the high-frequency noisy events.
The general idea is as follows. When an event occurs, e.g. a link goes down or new LSA arrives, do not respond to it immediately, e.g. by generating an LSA or running SPF, but wait some time, hoping to accumulate more similar events, e.g. waiting for the link to go back up, or more LSAs arriving. This could potentially save a lot of resources, by reducing the number of SPF runs or amount of LSAs flooded. The question is – how long should we hold or throttle the responses? Ideally, it would be nice to adapt this interval according to the network conditions – i.e. make it longer when the network is unstable and shorter under stable conditions. Cisco implements an exponential back-off timer to implement this idea. Here is how it works.
The exponential back-off is defined using three parameters – start interval, increment, and max_wait time specified using the command timers throttle spf start increment max_wait.Suppose the network was stable for a relatively long time, and then an event such as LSA arrival has occurred. The router delays SPF computations for the start amount if milliseconds and sets the next hold-time to increment milliseconds. Next, if an event occurs after the start wait window expired, the event would be held for processing until the increment milliseconds window expire, but the next hold-time would be doubled, i.e. set to 2*increment. Effectly, every time an event occurs during the current hold-time window, the processing is delayed until the current hold-time expires and the next hold-time interval is doubled. The hold-time grows exponentially until it reaches the max_wait value. After this, every event received during current hold-time window would result in the next interval being equal to the constant max_wait. This ensures that exponential growth is limited by a ceiling value. If there are no events for the duration of 2*max_wait milliseconds, the hold-time window is reset back to the start value, assuming the network returned to stable condition.
Look at the figure below.

The first event schedules SPF run in start milliseconds. At the same time, the next interval is set to increment milliseconds. Since there is an event during the second hold interval, the third hold interval is set to 2xincrement. There is another event during the third window, and this sets the forth window to 4xincrement. However, in our case this exceeds the max_wait value, and thus the forth hold-time interval equals max_wait milliseconds. There are more events during the forth interval, but since the maximum hold-time value has been reached, the fifth interval is set to max_wait milliseconds. Since there are no events during the firth and sixth intervals, the hold-time is reset to start milliseconds again.
Although SPF response to LSA arrivals has been used in the above examples, the same idea applies to new LSA generation as response to local link events. This could be controlled using the LSA generation throttling command timers throttle lsa start increment max_wait. Both SPF and LSA generation throttling are on by default and you may probably want to reduce their values only if you really need to speed up your network convergence. However, keep in mind that improving response time automatically results in less stable routing protocol behavior.

Summary and Further Reading

We briefly discussed three extensions to OSPFv2 protocol: iSPF, LSA group pacing and event throttling. The first two features improve OSPF performance, while the last one allows for better scalability and dynamic adaptation to unstable network topologies. Even though these and other OSPFv2 enhancements significantly increase its scalability, the more general design features such as area partitioning, network summarization and event dampening should not be neglected. Lastly, if you haven’t done so yet, I would strongly suggest you to read the following publications:
[RFC1245] “OSPF Protocol Analysis”, J. Moy
[JDOYLE] “OSPF and IS-IS: Choosing an IGP for Large-Scale Networks”, J. Doyle
[LSAP] ”OSPF LSA Group Pacing”
[THROT] “OSPF Shortest Path First Throttling”
[ARPOPT] “ARPANET Routing Algorithm Improvements” E. Rose et al

This post is dedicated to one “esoteric” OSPF external route filtering method based on hiding OSPF Forwarding Address. Recall the meaning of OSPF FA. This is a special field used on OSPF type 5 and 7 LSAs to convey the information of the “external route source”. The purpose of FA is to optimize forwarding in situations where the external route source is connected to a shared segment. Here is an example:


In this scenario, R2 is the ASBR redistributing RIP into OSPF. At the same time, R1 does not perform redistribution. Per normal OSPF rules, the external prefixes appear “attached” to R2 and thus both R1 and R4 should route across R2 to get to the networks behind R3. In order to avoid this suboptimal routing, OSPF may insert a non-zero FA field into type-5 LSAs, containing the IP address of R3: 155.1.123.3. This will instruct R1 and R4 to route to R3 directly, instead of going across R2.
Now an important thing here – the FA address must be accessible via the normal routing tables of R1 and R4. This requires the external link to be advertised into OSPF by some means, e.g. by enabling OSPF on the external link between R1, R2 and R3. Redistribution cannot be used for this purpose, as there are some restrictions. Here is a complete list of the requirements for enabling the OSPF FA in type 5 LSAs:

• OSPF is enabled on the ASBR’s next hop interface AND
• ASBR’s next hop interface is non-passive under OSPF AND
• ASBR’s next hop interface is not point-to-point AND
• ASBR’s next hop interface is not point-to-multipoint AND
• ASBR’s next hop interface address falls under the network range specified in the router ospf command.

(You may find more information by reading the article on Cisco’s website named Common Routing Problems with OSPF Forwarding Address.
Notice the requirement for having the network type of “broadcast” or “non-broadcast” – this makes sense if you think that in real life you need to have a shared link with multiple “exit points”. However, you may forcefully configure a physically point-to-point link for the mentioned OSPF network types to enforce the effect of FA assignment.

Application to Filtering

Based on the requirement that FA needs to be reachable for the respective external routes to be considered, we may devise a filtering scheme for external routing information. More specifically, if there is a way to filter out the prefix corresponding to the FA, this will stop all routers that lost this information from using the external prefixes. There are two cases here.

1. The FA prefix is filtered at the ASBR. Since OSPF must be enabled on the external link, the only option left is configuring a different area on the external link and using the inter-area route filter (area x filter-list) to block the prefix from propagating further.
2. The FA prefix is filtered at the ABR(s) of the area containing the ASBR. You may use any of the methods described in the post OSPF Route Filtering Demystified to prevent type-3 LSA generation, e.g. use the inter-area route filtering.

Let’s see how this could be done in a practical scenario. Below is a diagram of a single-area OSPF implementation. R1 redistributes RIP routes into OSPF.

We enable OSPF area 0 on R1’s Frame-Relay interface (which uses the default non-broadcast OSPF network type) and apply inter-area route filtering:

R1:
router ospf 1
 area 168 filter-list prefix TO_AREA168 in
 redistribute rip subnets
 network 148.1.0.1 0.0.0.0 area 0
 network 148.1.18.1 0.0.0.0 area 168
!
ip prefix-list TO_AREA168 seq 5 deny 148.1.0.0/24
ip prefix-list TO_AREA168 seq 10 permit 0.0.0.0/0 le 32
 

Now look at the OSPF database in SW2:

Rack1SW2#sh ip ospf database external 

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

                Type-5 AS External Link States

  LS age: 505
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 148.1.1.0 (External Network Number )
  Advertising Router: 150.1.1.1
  LS Seq Number: 8000005B
  Checksum: 0xC8B4
  Length: 36
  Network Mask: /24
        Metric Type: 2 (Larger than any link state path)
        TOS: 0
        Metric: 20
        Forward Address: 148.1.0.3
        External Route Tag: 0

Now check if this route is present in the routing table. Also make sure the FA address is not in the routing table too:

Rack1SW2#sh ip route 148.1.1.0
% Subnet not in table

Rack1SW2#sh ip route 148.1.0.3
% Subnet not in table

Rack1SW2#show ip ospf database summary 148.1.0.0

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

Now, remove the inter-are route filter in R1 and check SW2’s routing table once again.

Rack1R1(config-router)#no area 168 filter-list prefix TO_AREA168 in

Rack1SW2#sh ip route 148.1.0.3
Routing entry for 148.1.0.0/24
  Known via "ospf 1", distance 110, metric 65, type inter area
  Last update from 148.1.18.1 on Vlan18, 00:00:16 ago
  Routing Descriptor Blocks:
  * 148.1.18.1, from 150.1.1.1, 00:00:16 ago, via Vlan18
      Route metric is 65, traffic share count is 1

Rack1SW2#sh ip route 148.1.1.0
Routing entry for 148.1.1.0/24
  Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 65
  Last update from 148.1.18.1 on Vlan18, 00:00:16 ago
  Routing Descriptor Blocks:
  * 148.1.18.1, from 150.1.1.1, 00:00:16 ago, via Vlan18
      Route metric is 20, traffic share count is 1

Finally, a few words on type-7 LSAs. Per the NSSA area RFC, the use of FA is mandatory with these LSAs. The reason is that there is only one 7-to-5 translating ABR and this might result in suboptimal routing without the use of FA. This makes the use of the special conditions mentioned previously unnecessary. You may always use FA-based prefix filtering with the external information conveyed in type-5 LSAs translated from type-7 LSAs.

Summary

OSPF is a complicated protocol, which combines many features of distance-vector protocols with link-state behavior. Brought together, some of the features allow for sophisticated filtering techniques, not possible normally with pure link-state behavior. Using FA filtering is a good example of this phenomenon.

The feature we are going to talk about today may look a bit convoluted, but it demonstrates core OSPF behavior: combining link-state and distance-vector behaviors. The command capability transit was introduced in IOS 12.3T and is on by default. However, the description is rather confusing and does not explain the underlying mechanics. We are going to give an in-depth look at this feature now.

What is Transit Capability?

In short, this is a special property of a non-backbone area that allows this area to transport traffic for other areas (either zero or non-zero). Per the OSPF definition, a transit area is the area that has a virtual-link connecting two or more ABRs attached to this area. Thus, having a virtual-link provisioned across the area is the necessary thing to make the area transit. In fact, it’s just an alternate definition of a transit area. So the first thing we want to find out is what kind of mechanism is a virtual-link?

What are Virtual-links?

The idea of a virtual link is to extend area 0 across non-backbone areas. There are two main situations when you may want to do this:
1) Due to design considerations, where you have an area not directly connected to the backbone area. This could be a result of two networks merging together. An example is when you have to connect two previously disconnected backbone areas. The purpose, of course, is allowing two OSPF topologies to exchange routing information dynamically.
2) Using a non-backbone area to reach destinations in other areas. The main idea of OSPF inter-area routing is that all areas should be communicating across the backbone, area 0. The backbone area is used to exchange the routing information in a distance-vector manner, requiring the star-topology to avoid routing loops. Per the RFC, the router is only considered an ABR if it has an interface in Area 0 and ignores summary LSAs delivered across the non-backbone areas. This ensures the simple loop free star topology. Look at the diagram below. Here the paths between R4 and R5, and R2 and R5, are “slow” and OSPF metrics reflect this. The fastest way for R4 to reach the subnet 163.X.12.0/24 is to go over the FR cloud to R3 and then to R1.

However, in reality, in order for R4 to reach the subnet 163.X.12.0/24, it needs to traverse across the “slow” Serial link to R5 as this is where Area 0 is located. Even though Area 1 provides a shorter path, R3 will never advertise it as it does not have an interface in area zero, and R5′s summary sent into area 1 will be ignored in favor of the summary received via area 0! The way to avoid this is by providing a virtual link between R4 and R5, or R4 and R3, or both of these links. Let’s see how this allows for lifting the restriction of ignoring the inter-area routes received via non-backbone area.

How Virtual-links Work

Virtual links are seen as point-to-point links in the topology graph, belonging to area 0. When you configure the virtual link you specify the transit area and the endpoint router-ids. Based on the router-ids and the intra-area shortest-path tree, the path for the virtual link is calculated and the hello packets (unicast!) are exchanged. After this, OSPF follows the regular adjacency establishment process. This adjacency is treated at P2P like we mentioned above and used to exchange OSPF LSAs.
However, virtual-links are only used to flood specific LSAs: the router, network, and summary LSAs found in area 0. Type 5 LSAs are not flooded across the virtual links. Here is the reason why. As you know, Type 1,2,3, and 4 LSAs have the flooding scope of a single area. Thus, if you have a virtual link connecting two ABRs, you cannot flood LSAs across the transit area, since this area is different from Area 0. However, external LSAs have the flooding scope of OSPF autonomous system, and thus they are flooded across the area anyways (unless it’s stub), so there is no need to duplicate information across the virtual link. Obviously, a stub area cannot be transit due to this reason.
After LSAs have been loaded across the virtual link, they could be used to run SPF and populate the routing table. Initially, all prefixes learned across a virtual link are assigned the next hop value of “virtual-link”. This value should be resolved to something physical. Here is where it becomes a little trickier. As the LSAs have been received over a P2P link connecting two ABRs, it makes sense to avoid SPF calculations and simply put the prefixes in the routing table using the metric X+Y, where X is the cost of reaching the other ABR, across the virtual link and Y is the cost the other ABR advertises for this prefix. This is precisely what OSPFv1 did and what Cisco IOS was doing prior to supporting “transit capability” documented in OSPFv2 standard.
Therefore, in the case of OSPFv1 (or OSPFv2 + no capability transit) deployed in the topology documented on the diagram above, if you provision a virtual-link between R4 and R5, R4 will be able to reach the prefixes across Area 1 following the same path that the virtual link takes. What if we want to use the PVC R4-R3 that has more bandwidth compared to the PVC used to reach R5? You will have to provision a virtual-link R4 to R3 then. Could you use a daisy-chained virtual-link as follows: R4-R5-R3? You could, but then R4 will choose to reach the 163.X.12.0/24 subnet across R5, as it has to follow the virtual-link path! Even though R3 will inject a summary LSA for 163.X.12.0/24 into Area 1 as an ABR, R4 will learn this prefix via the virtual-link to R5 and use the path via this ABR. Here is an example: R3, R4, and R5 are configured for OSPFv2 but all have “capability transit” disabled. There is a daisy chain of virtual links R4->R5->R3 configured on these routers. R4 will prefer the path across R5, even though the shortest path would be across R3, and R3 advertises the corresponding summary into Area 1!
Virtual links are provisioned between R3-R5 and R4-R5:

R5#show ip ospf virtual-links
Virtual Link OSPF_VL1 to router 150.1.3.3 is up
  Run as demand circuit
  DoNotAge LSA allowed.
  Transit area 1, via interface Serial0/0/0, Cost of using 64
  Transmit Delay is 1 sec, State POINT_TO_POINT,
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    Hello due in 00:00:01
    Adjacency State FULL (Hello suppressed)
    Index 3/6, retransmission queue length 0, number of retransmission 0
    First 0x0(0)/0x0(0) Next 0x0(0)/0x0(0)
    Last retransmission scan length is 0, maximum is 0
    Last retransmission scan time is 0 msec, maximum is 0 msec
Virtual Link OSPF_VL0 to router 150.1.4.4 is up
  Run as demand circuit
  DoNotAge LSA allowed.
  Transit area 1, via interface Serial0/0/0, Cost of using 64
  Transmit Delay is 1 sec, State POINT_TO_POINT,
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    Hello due in 00:00:06
    Adjacency State FULL (Hello suppressed)
    Index 2/5, retransmission queue length 0, number of retransmission 0
    First 0x0(0)/0x0(0) Next 0x0(0)/0x0(0)
    Last retransmission scan length is 0, maximum is 0
    Last retransmission scan time is 0 msec, maximum is 0 msec

The preferred path is across R5:

R4#show ip route
...

     163.1.0.0/16 is variably subnetted, 7 subnets, 2 masks
C       163.1.45.0/24 is directly connected, Serial0/1/0
O       163.1.0.3/32 [110/64] via 163.1.0.3, 05:27:57, Serial0/0/0
C       163.1.0.0/24 is directly connected, Serial0/0/0
O       163.1.0.5/32 [110/64] via 163.1.0.5, 05:27:57, Serial0/0/0
O IA    163.1.12.0/24 [110/193] via 163.1.0.5, 00:00:46, Serial0/0/0
...

In the above output, 163.X.12.0/24 is seen as an inter-area route via R5. However, we can see that R3 advertises the same summary with a better cost!

R4#sh ip ospf database summary 163.1.12.0

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

  Summary Net Link States (Area 1)

  Routing Bit Set on this LSA
  LS age: 2 (DoNotAge)
  Options: (No TOS-capability, DC, Upward)
  LS Type: Summary Links(Network)
  Link State ID: 163.1.12.0 (summary Network Number)
  Advertising Router: 150.1.3.3
  LS Seq Number: 80000001
  Checksum: 0xBBF1
  Length: 28
  Network Mask: /24
 TOS: 0  Metric: 65

But R4 ignores it due to the fact that it’s not received via Area 0! So how does OSPFv2 improve upon this described behavior? It uses the inter-area routes received via the non-backbone area as a source of better information!

How Does OSPFv2 Perform Transit Path Calculations

OSPFv2 implements some improvements over the simple procedure of next-hop resolution for virtual-link connection. Specifically, it relies on the fact that the inter-area routes flooded into the transit area are “congruent” to the virtual-link and thus may not result in a routing loop – they are advertised following the loopless “tree” topology. Thus, if those inter-area prefixes provide a better cost than the virtual-link path (X+Y as in the previous description) they could be used in place of the same prefixes learned via the virtual-link! However, this is optimization hold true only for inter-area prefixes injected from non-backbone areas, and the intra-area routes found in Area 0 itself. We are going to review the case of the inter-area routes first.
Prior to that, we will quickly outline how OSPFv2 detects if an area has the “Transit Capability”. This is done in a pretty straighforward manner. If an ABR detects that it has a fully adjacent virtual link coming from Area A, it floods all of its router LSAs into this area with the special “V” bit set. All routers in Area A will see that bit set, and learn that the area is effectively supporting the transit feature (“V” stands for virtual-link).

OSPF Transit Capability for Inter-area Routes

Back to our diagram above. If there is a virtual-link terminating on R3, this router is an ABR (per the RFC), and generates summary LSAs for the prefixes learned from Area 2. These summaries are flooded across Area 1 and R4 learns them. Next, R4 will receive the summary LSAs for the SAME prefixes over the virtual link from R5. When the OSPF process in R4 computes the best routes, it takes into account the fact that Area 1 is transit. Based on this, it attempts to find a BETTER path for the prefixes found in the summary-LSAs learned over the virtual link by looking at the inter-area routes received from Area 1. If it finds a match with a better metric, it simply uses that route over the one received across the virtual link! Look at the routing table of R4 when all the routers (R3, R4, and R5) have the capability transit enabled: The prefix 163.X.12.0/24 is now reachable via R3, even though the virtual link from R4 links us to R5!

R4#show ip route ospf
     163.1.0.0/16 is variably subnetted, 7 subnets, 2 masks
O       163.1.0.3/32 [110/64] via 163.1.0.3, 05:44:22, Serial0/0/0
O       163.1.0.5/32 [110/64] via 163.1.0.5, 05:44:22, Serial0/0/0
O IA    163.1.12.0/24 [110/129] via 163.1.0.3, 00:00:02, Serial0/0/0
...

Effectively, even though R4 has the same prefix received via Area 0, it now prefers path via R3 due to the transit capability feature. Check the summary LSA advertised by R3:

R4#show ip ospf database summary 163.1.12.0

...

  LS age: 1115
  Options: (No TOS-capability, DC, Upward)
  LS Type: Summary Links(Network)
  Link State ID: 163.1.12.0 (summary Network Number)
  Advertising Router: 150.1.5.5
  LS Seq Number: 80000001
  Checksum: 0x8EE5
  Length: 28
  Network Mask: /24
 TOS: 0  Metric: 10063 

  Summary Net Link States (Area 1)

  LS age: 1122
  Options: (No TOS-capability, DC, Upward)
  LS Type: Summary Links(Network)
  Link State ID: 163.1.12.0 (summary Network Number)
  Advertising Router: 150.1.3.3
  LS Seq Number: 80000001
  Checksum: 0xBBF1
  Length: 28
  Network Mask: /24
        TOS: 0  Metric: 65 

  LS age: 1127
  Options: (No TOS-capability, DC, Upward)
  LS Type: Summary Links(Network)
  Link State ID: 163.1.12.0 (summary Network Number)
  Advertising Router: 150.1.5.5
  LS Seq Number: 80000002
  Checksum: 0x8CE6
  Length: 28
  Network Mask: /24
 TOS: 0  Metric: 10063

However, this procedure will NOT work if you summarize the prefixes from Area 2 into Area 1 on R3. This is because there are no longer an exact match between prefixes, and OSPF cannot use them for path optimization.

R3:
router ospf 1
area 2 range 163.1.0.0 255.255.240.0

R4#show ip route ospf
     163.1.0.0/16 is variably subnetted, 8 subnets, 3 masks
O       163.1.0.3/32 [110/64] via 163.1.0.3, 05:48:51, Serial0/0/0
 O IA    163.1.0.0/20 [110/65] via 163.1.0.3, 00:00:05, Serial0/0/0
O       163.1.0.5/32 [110/64] via 163.1.0.5, 05:48:51, Serial0/0/0
O IA    163.1.12.0/24 [110/10127] via 163.1.0.5, 00:00:00, Serial0/0/0

However take notice that you CAN summarize the inter-area prefixes in this case, even though it is undesirable for optimization. It is possible to summarize prefixes from non-backbone area into a transit area, but we will see that you cannot summarize prefixes from backbone area into a transit area.

What If the Area on the Other Side is Area 0?

Now, what if instead of Area 2 we have Area 0? That’s an interesting scenario, because in this case, R4 will be receiving the information about 163.X.12.0/24 via type-1 LSAs from R5 and should prefer intra-area routes over inter-area at all times. However, the above described transit-area optimization works in this case as well! That is, R4 will look for a better path to reach the prefixes learned in router-LSAs via the inter-area LSAs in the transit area! The procedure only works for Area 0 intra-area prefixes, and not for any other intra-area routes.
Here is what it looks like in a live scenario. Consider the diagram below, which is the same as the previous one, just having Area 2 changed to Area 0. All ABRs have the capability transit turned on.

Look at R4′s routing table and notice that it has an intra-area route (via area 0) with the next hop pointing to R3:

R4#show ip route ospf
     163.1.0.0/16 is variably subnetted, 7 subnets, 2 masks
O       163.1.0.3/32 [110/64] via 163.1.0.3, 05:55:13, Serial0/0/0
O       163.1.0.5/32 [110/64] via 163.1.0.5, 05:55:13, Serial0/0/0
O       163.1.12.0/24 [110/129] via 163.1.0.3, 00:00:07, Serial0/0/0
O       163.1.13.0/24 [110/65] via 163.1.0.3, 00:00:50, Serial0/0/0
O       163.1.25.0/24 [110/10063] via 163.1.0.5, 00:00:30, Serial0/0/0

If we check the summary LSAs advertised by R3, we will find the same prefix for 163.X.12.0/24 that should appear in R4′s routing table as an inter-area route, but INSTEAD is used as an “corrector” for the inter-area path learned via Area 0!

R4#sh ip ospf database summary 163.1.12.0

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

  Summary Net Link States (Area 1)

  LS age: 137
  Options: (No TOS-capability, DC, Upward)
  LS Type: Summary Links(Network)
  Link State ID: 163.1.12.0 (summary Network Number)
  Advertising Router: 150.1.3.3
  LS Seq Number: 80000001
  Checksum: 0xBBF1
  Length: 28
  Network Mask: /24
 TOS: 0  Metric: 65

What’s really interesting, is that an intra-area route actually takes the INTER-area path! The transit capability essentially allows the use of non-backbone inter-area routes to optimize inter-area paths and area 0 intra-area paths IF the area in question is transit!

Virtual Links and Summarization

We remember that this optimization could be broken by using summarization (area ranges) at the ABRs (R3 in our case). However, in the case of source Area 0, summarization will not work! R3 will IGNORE the range statements if they cover to the prefixes in area 0 and there is an active virtual-link across any area. What’s the problem with that? The reason is that area 0 is the core transit area, and the prefixes learned via it could be used to reach the other inter-area routes. Summarizing area 0 information, while injecting it in a transit area, might result in routing loops in reaching those prefixes, as the same information will flow unsummarized down the chain of virtual links. Thus, OSPF will never summarize backbone-area prefixes when injecting them into a TRANSIT area. You may validate this by configuring area range statements:

R3:
router ospf 1
 area 0 range 163.1.12.0 255.255.240.0
!
R4#sh ip ospf database summary 163.1.0.0

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

R4#sh ip ospf database summary 163.1.12.0

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

  Summary Net Link States (Area 1)

  LS age: 766
  Options: (No TOS-capability, DC, Upward)
  LS Type: Summary Links(Network)
  Link State ID: 163.1.12.0 (summary Network Number)
  Advertising Router: 150.1.3.3
  LS Seq Number: 80000001
  Checksum: 0xBBF1
  Length: 28
  Network Mask: /24
 TOS: 0  Metric: 65

This is the side-effect of the virtual-link configuration with area 0 ranges. What if we disable the transit capability? In that case, optimization breaks down, but the summarization works!

R3, R4, R5:
router ospf 1
 no capability transit

R4#sh ip ospf database summary 163.1.0.0 

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

  Summary Net Link States (Area 1)

  LS age: 29
  Options: (No TOS-capability, DC, Upward)
  LS Type: Summary Links(Network)
  Link State ID: 163.1.0.0 (summary Network Number)
  Advertising Router: 150.1.3.3
  LS Seq Number: 80000001
  Checksum: 0x7296
  Length: 28
  Network Mask: /20
 TOS: 0  Metric: 1

R4#sh ip route ospf 
     163.1.0.0/16 is variably subnetted, 7 subnets, 2 masks
O       163.1.0.3/32 [110/64] via 163.1.0.3, 06:10:26, Serial0/0/0
O       163.1.0.5/32 [110/64] via 163.1.0.5, 06:10:26, Serial0/0/0
O       163.1.12.0/24 [110/193] via 163.1.0.5, 00:01:21, Serial0/0/0

Summary

We outlined the idea of the Transit Capability found in OSPFv2 and not present in OSPFv1. The key idea is that the inter-area routes found in a transit area could be used to optimize the routing paths instead of simply following the paths carved by the virtual links (OSPFv1). We found that:
1) This procedure optimizes the paths for inter-area routes and backbone intra-area routes.
2) This procedure blocks Area 0 prefix summarization to prevent routing loops.
3) This behavior is different from the one used in OSPFv1, which was transiting across the virtual-link paths.

As a former English Major at the University of Massachusetts, Amherst, I really loved the oxymoron. You remember those…”sharply dull” or “cruel kindness”. Well, the OSPF protocol has one whopper of an oxymoron in its special areas – The Totally, Not-So-Stubby area!
When we last left our Area 11 in Part 4 of this blog series, it was a Not-So-Stubby Area, with the default-information-originate command used on the Area Border Router (ABR) in order to ensure a default route existed in the area. Here is the topology, and a look at the existing routing table on R3:

R3#show ip route

Gateway of last resort is 192.168.1.2 to network 0.0.0.0

 33.0.0.0/24 is subnetted, 1 subnets
C       33.33.33.0 is directly connected, Loopback33
 172.16.0.0/24 is subnetted, 1 subnets
O IA    172.16.10.0 [110/21] via 192.168.1.2, 00:00:14, FastEthernet0/0
 10.0.0.0/24 is subnetted, 1 subnets
O IA    10.10.10.0 [110/20] via 192.168.1.2, 00:00:14, FastEthernet0/0
C    192.168.1.0/24 is directly connected, FastEthernet0/0
 44.0.0.0/24 is subnetted, 1 subnets
C       44.44.44.0 is directly connected, Loopback44
O*N2 0.0.0.0/0 [110/1] via 192.168.1.2, 00:00:09, FastEthernet0/0
R3#

Notice I have highlighted some Type 3 LSAs that exist on this router. These, of course, are Inter-Area routes that are permitted into the Not-So-Stubby area. If we want to eliminate them, we need to make the area Totally Not-So-Stubby.
Let me go to the Area Border Router (R2) and remove the command area 11 nssa default-information-originate and replace it with the command area 11 nssa no-summary. Now, with that accomplished, let us examine the OSPF database and the routing table on R3:

R3#show ip ospf database

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

 Router Link States (Area 11)

Link ID         ADV Router      Age         Seq#       Checksum Link count
2.2.2.2         2.2.2.2         6           0x80000003 0x00A194 1
3.3.3.3         3.3.3.3         181         0x80000003 0x0060CD 1

 Net Link States (Area 11)

Link ID         ADV Router      Age         Seq#       Checksum
192.168.1.2     2.2.2.2         6           0x80000002 0x001199

 Summary Net Link States (Area 11)

Link ID         ADV Router      Age         Seq#       Checksum
0.0.0.0         2.2.2.2         12          0x80000001 0x00FC31

 Type-7 AS External Link States (Area 11)

Link ID         ADV Router      Age         Seq#       Checksum Tag
33.33.33.0      3.3.3.3         180         0x80000001 0x00F06E 0
44.44.44.0      3.3.3.3         180         0x80000001 0x0063DA 0

R3#show ip route

Gateway of last resort is 192.168.1.2 to network 0.0.0.0

 33.0.0.0/24 is subnetted, 1 subnets
C       33.33.33.0 is directly connected, Loopback33
C    192.168.1.0/24 is directly connected, FastEthernet0/0
 44.0.0.0/24 is subnetted, 1 subnets
C       44.44.44.0 is directly connected, Loopback44
O*IA 0.0.0.0/0 [110/11] via 192.168.1.2, 00:00:17, FastEthernet0/0
R3#

Notice that the Type 3 LSAs do indeed disappear from the area. Also, notice that we do not need to instruct the Area Border Router to send the default route any more. It happens “automagically” once again like in a Totally Stubby area. Of course the Type 7 LSAs still exist in the area as a method to transport the redistributed routes in to the Area Border Router for the Type 5 LSA conversion process.
I sincerely hope you enjoyed this blog series on OSPF areas. As always, thanks for choosing INE to assist you in your Cisco certification needs.
Keep following the blog of course…I want to do a post soon for one of our awesome CCIE 2.0 customers, Terry Vinson. Terry wants me to take on the powerful VLAN Access Control Lists (VACLs) feature of Catalayst switches.

Intro

There was a lot of blogging related to OSPF topics recently. In this post, I would like to clarify some common misunderstandings that many people have about OSPF route filtering. I have seen so many folks wrongfully understanding the underlying behavior so it’s about time to make the things clear.

OSPF Data Structures

To begin with, avoid using the term “LSA filtering” with OSPF. You cannot really filter LSAs – with the exception of one special case – you filter the network reachability information. To understand this in depth, start by recalling that OSPF deals with the following data structures:
1) Topological information. Outlines the connections in the graph describing the routers and the links in the network. This is what OSPF LSAs are about – they contain information about attached links. Think of LSAs as the objects that correspond to the “edges” of the graph. LSAs are stored in the LSBD – link state database. No real “routes” are stored in the LSDB, since this is the database for topological objects. However, routing or network reachability information is attached to the LSAs.
2) Network Reachability information. Contains the actual IP subnets. This information is “associated” with the network graph “edges” and you may think of it as “leaves” connected to the edges. Routing information does NOT describe any connectivity, just the prefix associated with the link. This information is contained in the LSAs, but as an “attribute”, and is used to populate the routing table – i.e. the RIB.
3) Main routing table. This is the router’s RIB, as OSPF does not have a RIB of its own, unlike BGP. This structure is used when OSPF generates new summary or external LSAs as we see later.
4) Routers routing table. This structure is unique to OSPF, and contains the IP addresses to reach the “border” routers – ASBRs and ABRs. It is used when calculating the respective inter-area routes, by adding the router path cost to the respective prefix advertised by this router. You may display the contents of this data structure by using the command show ip ospf border-routers.

OSPF route calculation overview

1) Routers establish adjacencies to flood topological information. The flooding process in OSPF is pretty complicated, and ensures the LSAs are delivered to all routers in a single area. As mentioned, topological information is carried in the form of LSAs and cannot be filtered, which it is essential to the OSPF algorithm. The only thing that limits LSA propagation is the flooding domain associated with the particular LSA type. Using the topological information learned, all routers within an area build the consistent graph of the network connections.
2) After all routers have a consistent topology view, they may calculate intra-area paths using the SPF algorithm and finally associate the network reachability information with the paths. This is where the “secondary”, leaf-level information comes in play. The leaves are attached to the paths and the routing table entries are calculated. So keep this in mind – first LSA flooding, then LSDB population, then SPF computations, and finally the RIB population.
3) After the intra-area paths have been calculated, inter-area routes are computed based on type-3/4 LSAs contents for other area information summarization. This process uses a quick and simple distance-vector computation algorithm, without the need for SPF computations. The router’s routing table is used extensively during this process.

When you can REALLY filter LSAs

Now, back to the case of LSA filtering. Some may recall the commands ip ospf database-filter all out or neighbor <IP> database-filter all out. Good point, but what it does is prevent the OSPF process from sending any LSAs out of the particular adjacencies. This could be done only if you’re sure that the LSAs will be flooded to all routers in the area by some other means. This is the special case I’ve been talking about previously. The purpose of this feature is to compensate for the absence of “mesh-groups” and limit the amount of flooding on NBMA subnets shared by many routers.

Overview of OSPF route-filtering

All right, so if you cannot really filter LSAs, how do you perform “route filtering” with OSPF? Using the term “route filtering” is the correct way of saying “LSA filtering”. You may apply route filtering to OSPF using the following two general methods:
1) Preventing optimal paths generated by OSPF from entering the RIB. This is what you can do by applying the command distribute-list in under the OSPF process. This affects routes installed in the RIB. There is one special extension of this method to filtering the FA (forwarding address) to block external OSPF routes.
2) Affecting the LSA generation process, by changing the “source” information used to generate the LSAs. There is a bunch of ways to do this, each specific to a particular LSA type. To understand this completely, we need to recall all the basic LSA types and their flooding scopes.

How OSPF generates different LSA types

LSA type 1. Describes an attached circuit, different link types. This is the fundamental building block of the topology graph. This LSA is flooded within the single area and never gets past the ABRs. The sources of information for LSA type-1 are the directly connected links. If you want to remove the network reachability information, just remove the link
LSA type 2. Generated only on the “shared” networks (BROADCAST/NON-BROADCAST network types) to minimize the amount of topological information generated. Imagine that you have 10 routers on a shared Ethernet segment. Normally, to fully describe the topology, every router would need to generate an LSA describing its connection to all other 9 routers. This would result in 90 LSAs. Using LSA type-2 and the Designated Router concept, every router needs to declare a connection to the DR, and the DR will generate a Type 2 LSA describing all routers on the segment (the “bunch”). In our example, this will result in 11 LSAs total. This LSA does not carry any real “network reachability” information with the exception of the netmask and the list of routers on the segment. It is used along with information from type 1 LSAs to describe the shared network. I like to think of it as a “glue” LSA. The flooding domain is one area as flooding stops at ABRs.
LSA type 3. Now this type is a bit tricky and brings in a lot of confusion. It is generated by an ABR to tell the routers in one area about the network in another area. Essentially, the router “pretends” like all the “foreign” networks are attached to it. From a topological perspective, this is true, because areas never know anything about another area’s topology – this information is lost when crossing the area boundaries. How are Type 3 LSAs generated? First of all, keep in mind that OSPF generates those by walking the main routing table, not the LSDB. This is per RFC 2328 clause 12.4.3 and in full accordance with distance-vector protocol behavior. Every route in the table has additional OSPF information associated with it, such as area number, route-type (intra-area, inter-area, external) next hop, and so on.
1) The ABR goes over the network reachability information in the RIB associated with intra-are routes for the particular area X and summarizes them honoring the area X range command settings. This results in Type-3 LSAs being generated and advertised into all other areas. Pay attention to the following important things:
1.1) Only intra-area routes are summarized. You cannot summarize inter-ara routes installed by processing type-3 LSAs learned from Area 0. Those will generate new type-3 LSAs in the ABR and will propagated them into non-backbone areas unmodified.
1.2) The intra-area routes are summarized PRIOR to applying the distribute-list filter and blocking the routes from entering the RIB. This is needed to allow for generation of a summary route, even if you don’t want the specific prefixes in the local RIB and calculate the correct metric if needed. Thus, even though OSPF walks over the RIB to gather the intra-area prefixes for summarization, it does so BEFORE applying the filter. The ultimate goal is making summarization the highest priority task, in order to increase network stability.
1.3) The OSPF metric for the summarized route is taken as the minimal among all intra-area routes. To ensure better routing stability, it is usually recommended setting the metric manually, to prevent LSA re-flooding in case some component route flaps and affects the summary metric.
2) Now, for dealing with the inter-area routes learned by the ARB, first of all, keep in mind that an ABR ONLY accepts and processes type-3 LSAs received from the backbone area. This is the well-know loop prevention mechanism built into OSPF, since OSPF behaves as a distance-vector protocol when dealing with inter-area routing information. This is a short description of how an ABR processes type-3 LSAs:
2.1) Ignore the type-3 LSA if it is NOT from the backbone area (prevents routing loops).
2.2) Walk over the inter-area routes learned via Area 0 in the RIB and generate respective type-3 LSAs which are flooded into the attached non-backbone areas. Thus, LSAs are effectively being re-generated based on the RIB contents.
Next, consider an important aspect of this process. The re-generated summary LSAs are generated AFTER applying the OSPF filter associated with the routing-process via the distribute-list in command. Thus, if you filter some of the inter-area routes from entering the RIB, the respective new summary LSAs will NOT get generated. This will stop routing information propagation into the attached non-backbone areas.
This quickly summarizes the type-3 LSA generation process. Notice that filtering the routing information is not based on some “LSA” filtering procedure, but rather on the routes contained in the RIB. At this moment, some people may recall the command area X filter-list prefix {in|out}. Good news here – this command applies after all summarization has been done and filters the routing information from being used for type-3 LSA generation. It applies to all three type of prefixes: intra-area routes, inter-area routes, and summaries generated as a result of the area X range command. All information is being learned from the router’s RIB.
Oh, almost forgot – LSA type-3 flooding scope is one area, it never crosses ABR boundaries – it just gets re-generated when needed! Now, here is a summary of inter-area router filtering commands (applicable only at an ABR):

Method 1: Filter the inter-area routes generated at ABR
router ospf 1
 area 10 filter-list prefix in NAME

Method 2: Filter out intra-area routes
router ospf 1
 area 10 range 1.1.1.0 255.255.255.0 no-advertise

Method 3: Filter inter-area routes learned by ABR from Area 0
router ospf 1
 distribute-list 1 in

LSA type 4
This type has always been confusing to many people. This LSA describes the metric that the ABR uses to reach the respective ASBR. This LSA contains the router-ID of the ASBR and the metric to reach it. ABRs generate type-4 LSAs based on the special “router routing” table which is visible when you issue the command show ip ospf border-routers. This command is the essense of the distance-vector OSPF behavior. During the inter-area path calculations, the ABR populates this table with “host” routing entries for every ABR and ASBR detected with the respective metrics. This table is never transferred to the main router routing table, but rather used for inter-area path computations and type-4 LSA generation. Effectively, the metrics in this table are used as metric offsets for the paths learned from ABRs and ASBRs.
The ABR generates type-4 summary LSAs into every normal attached area, to make sure the routers in there can reach the prefixes from the ASBR. You cannot really filter the contents of this LSA, as they are taken from the router routing table. The information from this LSA is used to populate the non-ABR routers “special” router routing table. The flooding domain is one area as it stops at the ABR.
LSA type 5
This LSA is originated by an ASBR (router redistributing external routes) and flooded through the whole OSPF autonomous system. You cannot limit the way this LSA is generated except to controlling the routes redistributed into OSPF. When a type-5 LSA is being generated, it uses the RIB contents and honors the summary-address commands in the ABR. You may filter the redistributed routes by using the command distribute-list out configured under the protocol, which is the source of redistribution or simply applying filtering with your redistribution.

Method 1:
router ospf 1
 distribute-list 10 out rip
!
access-list 1 deny 1.1.1.0
access-list 1 permit any

Method 2:
router ospf
 redistribute rip route-map RIP_TO_OSPF
!
route-map RIP_TO_OSPF
 match ip address 1

Method 3:
router ospf
 summary-address 10.0.0.0 255.255.25.0 no advertise

There is yet one more way to filter the routing information found in type-5 LSAs. If the LSA contains non-zero “FA” (forwarding address) field, OSPF process will check for this address to be accessible via RIB (RFC specifies that only OSPF routes should be considered, but it seems IOS satisfies with any route) before installing the actual prefix into the RIB. If the FA is not accessible, the corresponding external prefix is not installed into the global routing table. We will discuss this type of filtering a bit later, when we’ll be looking into type-7 LSAs. However, keep in mind that FA is non mandatory for type-5 LSA and is only assigned to a type-5 LSA under special conditions, outlined in the following document Common Routing Problem with OSPF Forwarding Address. Here is the list of the conditions:

• OSPF is enabled on the ASBR’s next hop interface AND
• ASBR’s next hop interface is non-passive under OSPF AND
• ASBR’s next hop interface is not point-to-point AND
• ASBR’s next hop interface is not point-to-multipoint AND
• ASBR’s next hop interface address falls under the network range specified in the router ospf command.

Please refer to the URL provided for more epxplanations.
There is only one more type of OSPF LSAs to discuss.
Type 7 LSA
These only exist at NSSA areas and have the flooding scope of a single area, as opposed to the whole domain for type-5 LSAs. The type-7 LSAs reaching ABRs are used to populate the local routing table and re-generate the new type-5 LSAs, originated now by the ABR. This is important – since the ABR becomes an ASBR and re-originates the routes, you may use the command summary-address ADDR MASK no-advertise to block the type-5 LSA generation. There is another, less obvious way to do things:
When an ABR generates type-5 LSAs, it adds the forwarding-address (FA) based on the information learned in the type-7 LSA. This information is originally inserted by the ASBR to help in optimal exit point selection. The use of forwarding-address with the type-7 LSAs is mandatory per the RFC, since there is just one translator, and it may lie on the sub-optimal path to the ASBR. Thus all routers in the OSPF autonomous system are supposed to rely on the FA for optimal routing to the translated prefixes. And here is the trick: if you filter the forward-address IP from the routing table in the ABR, using the command distribute-list in the type-5 LSA will not be generated!. Look at the following output, where R2 is an ABR for NSSA area 27:

Rack1R2#show ip ospf database nssa-external 

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

  Type-7 AS External Link States (Area 27)

  Routing Bit Set on this LSA
  LS age: 11
  Options: (No TOS-capability, Type 7/5 translation, DC)
  LS Type: AS External Link
  Link State ID: 162.1.7.0 (External Network Number )
 Advertising Router: 162.1.7.7
  LS Seq Number: 80000001
  Checksum: 0xDEB5
  Length: 36
  Network Mask: /24
 Metric Type: 2 (Larger than any link state path)
 TOS: 0
 Metric: 20
 Forward Address: 150.1.7.7
 External Route Tag: 0

  Routing Bit Set on this LSA
  LS age: 11
  Options: (No TOS-capability, Type 7/5 translation, DC)
  LS Type: AS External Link
  Link State ID: 162.1.10.0 (External Network Number )
 Advertising Router: 162.1.7.7
  LS Seq Number: 80000001
  Checksum: 0xBDD3
  Length: 36
  Network Mask: /24
 Metric Type: 2 (Larger than any link state path)
 TOS: 0
 Metric: 20
 Forward Address: 150.1.7.7
 External Route Tag: 0

Rack1R2#show ip ospf database external 

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

  Type-5 AS External Link States

 ...
  LS age: 26
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 162.1.7.0 (External Network Number )
  Advertising Router: 150.1.2.2
  LS Seq Number: 80000001
  Checksum: 0x2193
  Length: 36
  Network Mask: /24
 Metric Type: 2 (Larger than any link state path)
 TOS: 0
 Metric: 20
 Forward Address: 150.1.7.7
 External Route Tag: 0

  LS age: 26
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 162.1.10.0 (External Network Number )
  Advertising Router: 150.1.2.2
  LS Seq Number: 80000001
  Checksum: 0xFFB1
  Length: 36
  Network Mask: /24
 Metric Type: 2 (Larger than any link state path)
 TOS: 0
 Metric: 20
 Forward Address: 150.1.7.7
 External Route Tag: 0

As you can see, R2 generates type-5 LSA with the same forwarding address found in type-7 LSA – “150.1.7.7”. Now we filter this IP address from entering R2′s routing table:

R2:
access-list 1 deny   150.1.7.7
access-list 1 permit any
!
router ospf 1
 distribute-list 1 in

And apply our verification once again:

Rack1R2#show ip ospf database nssa-external 

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

  Type-7 AS External Link States (Area 27)

  LS age: 222
  Options: (No TOS-capability, Type 7/5 translation, DC)
  LS Type: AS External Link
  Link State ID: 162.1.7.0 (External Network Number )
  Advertising Router: 162.1.7.7
  LS Seq Number: 80000001
  Checksum: 0xDEB5
  Length: 36
  Network Mask: /24
 Metric Type: 2 (Larger than any link state path)
 TOS: 0
 Metric: 20
 Forward Address: 150.1.7.7
 External Route Tag: 0

  LS age: 222
  Options: (No TOS-capability, Type 7/5 translation, DC)
  LS Type: AS External Link
  Link State ID: 162.1.10.0 (External Network Number )
  Advertising Router: 162.1.7.7
  LS Seq Number: 80000001
  Checksum: 0xBDD3
  Length: 36
  Network Mask: /24
 Metric Type: 2 (Larger than any link state path)
 TOS: 0
 Metric: 20
 Forward Address: 150.1.7.7
 External Route Tag: 0

Rack1R2#show ip ospf database external 

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

  Type-5 AS External Link States

And we can see that Type-7 to Type-5 translation is not working anymore, as the forwarding address is no longer reachable in the RIB. Notice that forwarding address should be accessible via the main RIB, not the routers routing table of OSPF. This special behavior is unique to the routes learned by processing the type-7 LSAs. Now what if you have to following topology:

And R3 is filtering the forwarding address for the type-5 LSAs originated at R4 using say area X range no-advertise or area X filer-list prefix {in|out} commands, so that R1 has no FA IP in its RIB. In this situation, R3 will have the route to the redistributed prefixes installed (it sees the FA!), but all other routers in the domain with the exception of the NSSA area internal routers will not. Even though they will receive the type-5 LSA, they will not be able to process them and use the information for routing – the forwarding address will be unreachable. One way to overcome this issue is by using the command area X nssa suppress-fa to instruct R3 on setting the FA to itself.

Summary of the post

We went over almost all of the important route-filtering scenarios for OSPF. The key thing you should remember is that non-local route filtering for OSPF is only available at ABRs and ASBRs, the points where OSPF behaves as a distance-vector protocol with respect to inter-area routing information. Here is the list of points you need to remember:
1) You cannot filter LSAs directly, you can only manipulate the routing information used to generate LSAs.
2) The above routing information is taken from local router’s RIB directly.
2.1) In the case of intra-area routes, RIB filters are applied after the type-3 LSAs are generated (intra-area routes are summarizable).
2.2) In the case of inter-area routes, RIB filters are applied prior to type-3 LSA generation (inter-area routes are not summarizable).
3) External AS routes can only be filtered at the ASBR.
4) NSSA routes can be filtered at an ASBR and the ABR performing the translation.
5) If the FA for an external prefix is NOT reachable, the router will NOT install it into the route table nor will it translate type-7 LSAs to type-5.

Futher Reading

1) RFC 2328. Dont skip this if you are serious about understanding OSPF
2) OSPF Design Guide by Sam Halabi. Excellent introductory reading on OSPF.
3) Cisco IP Routing by Alex Zinin. A must read to anyone who wants in-depth understanding of IP Routing internals.

Thanks to one of our brilliant CCIE R/S Written students, Nish, for his request of this series of INE blog posts. Nish is still struggling a bit with the different OSPF area types and how exactly they impact Link State Advertisements (LSAs). In this series, we will tackle each of the different OSPF areas in great detail, confirming our Level 1 knowledge at the command line as we progress.
Here is the network we will use in this first post. Notice this simple network can be constructed easily in Dynamips, or with three pretty basic Cisco routers capable of OSPF version 2.


To prepare for this blog post, we have configured all of the underlying layer 2 and 3 connectivity. We have also configured  OSPF per the diagram. Note the OSPF router IDs were set using the OSPF router-mode router-id command. These addresses do not exist on the devices,  and therefore they are not advertised in the protocol, and obviously, they are not reachable.
So let us examine the first device, R1. This is an internal, backbone router. What do we expect to see in the OSPF database? Well, since there is  broadcast media at work in that area, I expect to see an LSA Type 2, and we have another area, Area 11, so we should also see an LSA Type 3. Here is the actual OSPF database on the device:

R1#show ip ospf database

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

  Router Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum Link count
1.1.1.1         1.1.1.1         99          0x80000002 0x001FEB 2
2.2.2.2         2.2.2.2         95          0x80000002 0x007761 1

  Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
10.10.10.1      1.1.1.1         99          0x80000001 0x009476

  Summary Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
192.168.1.0     2.2.2.2         98          0x80000001 0x00F4CB
R1#

Interesting, OK, as an internal, backbone router, the first thing I notice is the fact that we only have one link state database here – it is for Area 0 of course. OK, very interesting, we have LSA 1 types (Router Link States) for the Router IDs of R1 and R2 in that area. Wow, these are not even valid (reachable) IP addresses in the scenario. I guess this is how we can use these Router IDs when we create a virtual link. These Router IDs are tracked and shared by the OSPF speakers.
The next entry is the LSA Type 2 (Net Link State) we expected. The advertising router is the local router (R1, RID: 1.1.1.1). We must be the Designated Router (DR), and that is indeed true. Finally, we have our LSA Type 3 (Summary Net Link State) that we expected from Area 11. Awesome. This is a fun and rewarding exercise. Predicting show command output based on our Core Knowledge (Level 1).
Now, close your eyes and think about the show command output for the OSPF database we will see in R2. This is an Area Border Router (ABR), and also a backbone router. We immediately realize we should see LSA entries for Area 0 and Area 11. This poor router has to maintain two databases:

R2#show ip ospf database

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

  Router Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum Link count
1.1.1.1         1.1.1.1         905         0x80000002 0x001FEB 2
2.2.2.2         2.2.2.2         899         0x80000002 0x007761 1

  Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
10.10.10.1      1.1.1.1         905         0x80000001 0x009476

  Summary Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
192.168.1.0     2.2.2.2         902         0x80000001 0x00F4CB

  Router Link States (Area 11)

Link ID         ADV Router      Age         Seq#       Checksum Link count
2.2.2.2         2.2.2.2         856         0x80000002 0x00F747 1
3.3.3.3         3.3.3.3         858         0x80000002 0x00B680 1

  Net Link States (Area 11)

Link ID         ADV Router      Age         Seq#       Checksum
192.168.1.2     2.2.2.2         859         0x80000001 0x006D44

  Summary Net Link States (Area 11)

Link ID         ADV Router      Age         Seq#       Checksum
10.10.10.0      2.2.2.2         904         0x80000001 0x0048C4
172.16.10.0     2.2.2.2         894         0x80000001 0x00C79B
R2#

Examine the above output line for line. There should be no surprises, and it should all fall right into place from your Core Knowledge about OSPF LSA Types now. Here is a look at the IP Routing table on this device, R2. Correlate the entries to those you see in the OSPF Database:

R2#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     172.16.0.0/24 is subnetted, 1 subnets
O       172.16.10.0 [110/11] via 10.10.10.1, 00:17:59, FastEthernet0/0
     10.0.0.0/24 is subnetted, 1 subnets
C       10.10.10.0 is directly connected, FastEthernet0/0
C    192.168.1.0/24 is directly connected, FastEthernet0/1
R2#

Welcome back to our series on OSPF areas. Click here for Part 1 of the series. It is time to focus on normal areas and stub areas in this post. Recall our topology:


We have gone to R1 and created a prefix (11.11.11.0/24) using a loopback interface. We run RIP version 2 on this interface and redistribute this into OSPF Area 0. What should this create on R3 in Area 11 (a normal OSPF area)? That’s right  – a Type 5 LSA for an External prefix. Let us examine the OSPF database on R3 now and the accompanying IP routing table:

R3#show ip ospf database

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

  Router Link States (Area 11)

Link ID         ADV Router      Age         Seq#       Checksum Link count
2.2.2.2         2.2.2.2         1216        0x80000002 0x00023C 1
3.3.3.3         3.3.3.3         1215        0x80000002 0x00C075 1

  Net Link States (Area 11)

Link ID         ADV Router      Age         Seq#       Checksum
192.168.1.3     3.3.3.3         1215        0x80000001 0x003577

  Summary Net Link States (Area 11)

Link ID         ADV Router      Age         Seq#       Checksum
10.10.10.0      2.2.2.2         1281        0x80000001 0x0048C4
172.16.10.0     2.2.2.2         1241        0x80000001 0x00C79B

  Summary ASB Link States (Area 11)

Link ID         ADV Router      Age         Seq#       Checksum
1.1.1.1         2.2.2.2         449         0x80000001 0x0075B0

  Type-5 AS External Link States

Link ID         ADV Router      Age         Seq#       Checksum Tag
11.11.11.0      1.1.1.1         456         0x80000001 0x0075AB 0
R3#

R3#show ip route

Gateway of last resort is not set

     172.16.0.0/24 is subnetted, 1 subnets
O IA    172.16.10.0 [110/21] via 192.168.1.2, 00:24:41, FastEthernet0/0
     10.0.0.0/24 is subnetted, 1 subnets
O IA    10.10.10.0 [110/20] via 192.168.1.2, 00:24:41, FastEthernet0/0
     11.0.0.0/24 is subnetted, 1 subnets
O E2    11.11.11.0 [110/20000] via 192.168.1.2, 00:11:53, FastEthernet0/0
C    192.168.1.0/24 is directly connected, FastEthernet0/0
R3#

Sure enough, there is the Type 5 prefix in the normal area. And we cannot forget about the LSA Type 4 (Summary ASB Link State). This informs the OSPF domain of the location of the Autonomous System Boundary Router (ASBR). I am sure you have been noticing how some of the LSAs in the database do not translate directly into routing table entries. For example, the LSA Type 4. This is reminiscent of the EIGRP topology table. That protocol sure tries to act link state as well!
OK, well let us see what happens when we convert Area 11 into a STUB AREA. Remember, this is a simple configuration. All we need to do is go to ALL of the routers in the stub area (there can be many), and issue the router configuration command area 11 stub. Now that we have done that, let us examine the databases on R3.

R3#show ip ospf database

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

  Router Link States (Area 11)

Link ID         ADV Router      Age         Seq#       Checksum Link count
2.2.2.2         2.2.2.2         7           0x80000005 0x001A23 1
3.3.3.3         3.3.3.3         6           0x80000005 0x00D85C 1

  Net Link States (Area 11)

Link ID         ADV Router      Age         Seq#       Checksum
192.168.1.3     3.3.3.3         6           0x80000004 0x004D5E

  Summary Net Link States (Area 11)

Link ID         ADV Router      Age         Seq#       Checksum
0.0.0.0         2.2.2.2         33          0x80000001 0x0075C0
10.10.10.0      2.2.2.2         33          0x80000003 0x0062AA
172.16.10.0     2.2.2.2         33          0x80000003 0x00E181
R3#

R3#show ip route

Gateway of last resort is 192.168.1.2 to network 0.0.0.0

     172.16.0.0/24 is subnetted, 1 subnets
O IA    172.16.10.0 [110/21] via 192.168.1.2, 00:01:23, FastEthernet0/0
     10.0.0.0/24 is subnetted, 1 subnets
O IA    10.10.10.0 [110/20] via 192.168.1.2, 00:01:23, FastEthernet0/0
C    192.168.1.0/24 is directly connected, FastEthernet0/0
O*IA 0.0.0.0/0 [110/11] via 192.168.1.2, 00:01:23, FastEthernet0/0
R3#

Wow, things really changed here. Notice the Stub Area effect worked just as advertised in our Core Knowledge studies. The Type 4 and 5 LSAs were removed from the OSPF database! They were replaced with a “special” LSA Type 3. It is special because it is an automatically generated default route by the Area Border Router (ABR).
Join us in the next part of this blog series where we examine the next OSPF area type, the Totally Stubby Area.

Click here for Part 1. Click here for Part 2.
In this part of our blog series on OSPF area types, our Area 11 is going to undergo a major flashback! The area is going to be reintroduced to an early 1980′s American stereotype called Valley Girls and their Valspeak. The area is no longer going to be Stubby, but it is going to be like. . .like Totally Stubby! Lets review how we left Area 11 and how things looked when it was just a Stub area:

R3#show ip ospf database

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

  Router Link States (Area 11)

Link ID         ADV Router      Age         Seq#       Checksum Link count
2.2.2.2         2.2.2.2         7           0x80000005 0x001A23 1
3.3.3.3         3.3.3.3         6           0x80000005 0x00D85C 1

  Net Link States (Area 11)

Link ID         ADV Router      Age         Seq#       Checksum
192.168.1.3     3.3.3.3         6           0x80000004 0x004D5E

  Summary Net Link States (Area 11)

Link ID         ADV Router      Age         Seq#       Checksum
0.0.0.0         2.2.2.2         33          0x80000001 0x0075C0
10.10.10.0      2.2.2.2         33          0x80000003 0x0062AA
172.16.10.0     2.2.2.2         33          0x80000003 0x00E181
R3#

R3#show ip route

Gateway of last resort is 192.168.1.2 to network 0.0.0.0

     172.16.0.0/24 is subnetted, 1 subnets
O IA    172.16.10.0 [110/21] via 192.168.1.2, 00:01:23, FastEthernet0/0
     10.0.0.0/24 is subnetted, 1 subnets
O IA    10.10.10.0 [110/20] via 192.168.1.2, 00:01:23, FastEthernet0/0
C    192.168.1.0/24 is directly connected, FastEthernet0/0
O*IA 0.0.0.0/0 [110/11] via 192.168.1.2, 00:01:23, FastEthernet0/0
R3#

The Stub area configuration wiped out any Type 4 and Type 5 LSAs in Area 11 and gave us the default route to the Area Border Router (ABR) in order to reach those prefixes. Like way cool, man! OK, now I sound like Scott Morris.
Now lets make that Area 11 Totally Stubby and see what happens. All we need to do is go to the Area Border Router (ABR; R2), and add the no-summary keyword to the previous area 11 stub command. Notice this keyword only needs to be on the ABR. While you could add it to each and every area stub command in Area 11, it would have no effect and the proctor would question your abilities.
OK. Now that we have made the Totally Stubby configuration, lets examine the OSPF Database and IP Routing table on R3:

R3#show ip ospf database

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

        Router Link States (Area 11)

Link ID         ADV Router      Age         Seq#       Checksum Link count
2.2.2.2         2.2.2.2         216         0x80000002 0x002020 1
3.3.3.3         3.3.3.3         215         0x80000002 0x00DE59 1

        Net Link States (Area 11)

Link ID         ADV Router      Age         Seq#       Checksum
192.168.1.3     3.3.3.3         215         0x80000001 0x00535B

        Summary Net Link States (Area 11)

Link ID         ADV Router      Age         Seq#       Checksum
0.0.0.0         2.2.2.2         24          0x80000002 0x0073C1

R3#show ip route

Gateway of last resort is 192.168.1.2 to network 0.0.0.0

C    192.168.1.0/24 is directly connected, FastEthernet0/0
O*IA 0.0.0.0/0 [110/11] via 192.168.1.2, 00:11:07, FastEthernet0/0
R3#

Now I am reminded of a famous episode of the American television hit, Seinfeld. We have major shrinkage! Notice the Totally Stubby configuration has gone a step further than the Stub Area config. It not only wiped out the LSA Type 4s and 5s, but it also removed the LSA Type 3s. Those were the Summary LSAs about prefixes within our OSPF domain, but in other areas. In fact, the only LSA Type 3 we have left is the special, default route generated by the ABR. Boy is that route important now. It is the only hope of this router reaching any prefixes outside of the area.
Please join us in the next part of this series where we examine the equally, cleverly-named, Not-So-Stubby Area.

Click here for Part 1 of the series or click here for Part 3 of the series.
Now it is time for us to examine yet another OSPF special area type – the Not-So-Stubby Area. I am sure you recall out topology from the previous parts, but here it is again:

When we left Area 11 in the last post, it was a Totally Stubby Area. This prevented LSA Types 3, 4, and 5 from entering the area, with the exception of the special default route (Type 3) generated by the Area Border Router.
The Not-So-Stubby Area (NSSA) allows us to bring in some redistributed routes into the stub area! Wow. I guess the area really isn’t that stubby at all. These redistributed routes propagate through the NSSA as Type 7, and are then converted on the ABR to Type 5. At least that is what we read in the RFCs. Let us see it in action at the command line!
I have removed the previous Totally Stubby configuration and I have placed the following command on all routers in Area 11 – area 11 nssa. After doing this, let us take a look at the OSPF database and routing table on R3:

R3#show ip ospf database

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

  Router Link States (Area 11)

Link ID         ADV Router      Age         Seq#       Checksum Link count
2.2.2.2         2.2.2.2         29          0x80000005 0x00A78B 1
3.3.3.3         3.3.3.3         28          0x80000004 0x0062CB 1

  Net Link States (Area 11)

Link ID         ADV Router      Age         Seq#       Checksum
192.168.1.3     3.3.3.3         28          0x80000001 0x00DACB

  Summary Net Link States (Area 11)

Link ID         ADV Router      Age         Seq#       Checksum
10.10.10.0      2.2.2.2         58          0x80000003 0x00E91B
172.16.10.0     2.2.2.2         58          0x80000003 0x0069F1

R3#show ip route

Gateway of last resort is not set

     172.16.0.0/24 is subnetted, 1 subnets
O IA    172.16.10.0 [110/21] via 192.168.1.2, 00:00:33, FastEthernet0/0
     10.0.0.0/24 is subnetted, 1 subnets
O IA    10.10.10.0 [110/20] via 192.168.1.2, 00:00:33, FastEthernet0/0
C    192.168.1.0/24 is directly connected, FastEthernet0/0
R3#

Notice how at this point,it looks just like a stub area. Type 4 and 5 LSAs have been filtered. Now, I will configure some loopbacks on R3, run RIP on them, and redistribute them into OSPF. Let us examine the OSPF database on R3 now:

R3#show ip ospf database

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

  Router Link States (Area 11)

Link ID         ADV Router      Age         Seq#       Checksum Link count
2.2.2.2         2.2.2.2         765         0x80000005 0x00A78B 1
3.3.3.3         3.3.3.3         10          0x80000005 0x0066C4 1

  Net Link States (Area 11)

Link ID         ADV Router      Age         Seq#       Checksum
192.168.1.3     3.3.3.3         764         0x80000001 0x00DACB

  Summary Net Link States (Area 11)

Link ID         ADV Router      Age         Seq#       Checksum
10.10.10.0      2.2.2.2         794         0x80000003 0x00E91B
172.16.10.0     2.2.2.2         794         0x80000003 0x0069F1

  Type-7 AS External Link States (Area 11)

Link ID         ADV Router      Age         Seq#       Checksum Tag
33.33.33.0      3.3.3.3         9           0x80000001 0x00F06E 0
44.44.44.0      3.3.3.3         11          0x80000001 0x0063DA 0
R3#

I guess the RFC did not lie to us! There they are – the Type 7 LSAs! Let us examine the OSPF database and IP routing table on R2 (the ABR):

R2#show ip ospf database

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

  Router Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum Link count
1.1.1.1         1.1.1.1         1120        0x80000002 0x0025E3 2
2.2.2.2         2.2.2.2         1023        0x80000003 0x007B5A 1

  Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
10.10.10.1      1.1.1.1         1120        0x80000001 0x009476

  Summary Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
192.168.1.0     2.2.2.2         1119        0x80000001 0x00F4CB

  Router Link States (Area 11)

Link ID         ADV Router      Age         Seq#       Checksum Link count
2.2.2.2         2.2.2.2         994         0x80000005 0x00A78B 1
3.3.3.3         3.3.3.3         241         0x80000005 0x0066C4 1

  Net Link States (Area 11)

Link ID         ADV Router      Age         Seq#       Checksum
192.168.1.3     3.3.3.3         996         0x80000001 0x00DACB

  Summary Net Link States (Area 11)

Link ID         ADV Router      Age         Seq#       Checksum
10.10.10.0      2.2.2.2         1025        0x80000003 0x00E91B
172.16.10.0     2.2.2.2         1025        0x80000003 0x0069F1

  Type-7 AS External Link States (Area 11)

Link ID         ADV Router      Age         Seq#       Checksum Tag
33.33.33.0      3.3.3.3         242         0x80000001 0x00F06E 0
44.44.44.0      3.3.3.3         242         0x80000001 0x0063DA 0

  Type-5 AS External Link States

Link ID         ADV Router      Age         Seq#       Checksum Tag
11.11.11.0      1.1.1.1         1171        0x80000001 0x0075AB 0
33.33.33.0      2.2.2.2         235         0x80000001 0x00A3C9 0
44.44.44.0      2.2.2.2         239         0x80000001 0x001636 0

R2#show ip route

Gateway of last resort is not set

     33.0.0.0/24 is subnetted, 1 subnets
O N2    33.33.33.0 [110/20000] via 192.168.1.3, 00:04:12, FastEthernet0/1
     172.16.0.0/24 is subnetted, 1 subnets
O       172.16.10.0 [110/11] via 10.10.10.1, 00:17:16, FastEthernet0/0
     10.0.0.0/24 is subnetted, 1 subnets
C       10.10.10.0 is directly connected, FastEthernet0/0
     11.0.0.0/24 is subnetted, 1 subnets
O E2    11.11.11.0 [110/20000] via 10.10.10.1, 00:04:12, FastEthernet0/0
C    192.168.1.0/24 is directly connected, FastEthernet0/1
     44.0.0.0/24 is subnetted, 1 subnets
O N2    44.44.44.0 [110/20000] via 192.168.1.3, 00:04:12, FastEthernet0/1
R2#

Holy LSAs Batman! This router has indeed converted the Type 7s to Type 5s and installed them in the routing table. Notice the N2 designations for NSSA area prefixes. Now let us examine R1 – an internal backbone router:

R1#show ip ospf database

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

  Router Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum Link count
1.1.1.1         1.1.1.1         1704        0x80000002 0x0025E3 2
2.2.2.2         2.2.2.2         1609        0x80000003 0x007B5A 1

  Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
10.10.10.1      1.1.1.1         1704        0x80000001 0x009476

  Summary Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
192.168.1.0     2.2.2.2         1705        0x80000001 0x00F4CB

  Type-5 AS External Link States

Link ID         ADV Router      Age         Seq#       Checksum Tag
11.11.11.0      1.1.1.1         1755        0x80000001 0x0075AB 0
33.33.33.0      2.2.2.2         819         0x80000001 0x00A3C9 0
44.44.44.0      2.2.2.2         820         0x80000001 0x001636 0

R1#show ip route

Gateway of last resort is not set

     33.0.0.0/24 is subnetted, 1 subnets
O E2    33.33.33.0 [110/20000] via 10.10.10.2, 00:13:45, FastEthernet0/0
     172.16.0.0/24 is subnetted, 1 subnets
C       172.16.10.0 is directly connected, Loopback1
     10.0.0.0/24 is subnetted, 1 subnets
C       10.10.10.0 is directly connected, FastEthernet0/0
     11.0.0.0/24 is subnetted, 1 subnets
C       11.11.11.0 is directly connected, Loopback11
O IA 192.168.1.0/24 [110/20] via 10.10.10.2, 00:26:50, FastEthernet0/0
     44.0.0.0/24 is subnetted, 1 subnets
O E2    44.44.44.0 [110/20000] via 10.10.10.2, 00:13:45, FastEthernet0/0
R1#

This is what we would expect as well! This device just sees these prefixes as good, old-fashioned, Type 5 LSAs.
But wait, I think we have an issue now in this OSPF domain. Let us examine the routing table on R3:

R3#show ip route

Gateway of last resort is not set

     33.0.0.0/24 is subnetted, 1 subnets
C       33.33.33.0 is directly connected, Loopback33
     172.16.0.0/24 is subnetted, 1 subnets
O IA    172.16.10.0 [110/21] via 192.168.1.2, 00:18:43, FastEthernet0/0
     10.0.0.0/24 is subnetted, 1 subnets
O IA    10.10.10.0 [110/20] via 192.168.1.2, 00:18:43, FastEthernet0/0
C    192.168.1.0/24 is directly connected, FastEthernet0/0
     44.0.0.0/24 is subnetted, 1 subnets
C       44.44.44.0 is directly connected, Loopback44
R3#

We are not getting the Type 5 being generated on R1 as expected. But we are also not getting a default route from the ABR anymore. The default route is not automatic with the NSSA. All we need to do is modify the area 11 nssa command on R2 to area 11 nssa default-information-originate. Now everyone is happy, happy. Check out the routing table now on R3:

R3#show ip route
Gateway of last resort is 192.168.1.2 to network 0.0.0.0

     33.0.0.0/24 is subnetted, 1 subnets
C       33.33.33.0 is directly connected, Loopback33
     172.16.0.0/24 is subnetted, 1 subnets
O IA    172.16.10.0 [110/21] via 192.168.1.2, 00:21:51, FastEthernet0/0
     10.0.0.0/24 is subnetted, 1 subnets
O IA    10.10.10.0 [110/20] via 192.168.1.2, 00:21:51, FastEthernet0/0
C    192.168.1.0/24 is directly connected, FastEthernet0/0
     44.0.0.0/24 is subnetted, 1 subnets
C       44.44.44.0 is directly connected, Loopback44
O*N2 0.0.0.0/0 [110/1] via 192.168.1.2, 00:00:12, FastEthernet0/0
R3#

I hope you will join me for the next part of this blog series where we examine the Jumbo Shrimp of OSPF areas, the Totally Not-So-Stubby area!