Troubleshooting a discrepancy between convergence time of different VRFs with identical settings, running over the same topology, I got the chance delve deeper into OSPF timers. Since it took a while to wrap my head around all the moving parts and I only fully grokked it after drawing everything on a whiteboard for a colleague, I decided to explain this thoroughly here.

This will be a bit of a long read. In short: If you don’t set your LSA accept timers lower than your LSA send timers, you will have to wait for your retransmission time-out get

Continue reading

While helping a friend, I recently stumbled upon an interesting issue with Administrative distances that confused me for a bit. But, when I took a step back and started going through the route selection processes step by step, it started making sense. The issue? With the default Cisco Administrative Distances, OSPF was winning from eBGP on a specific prefix.

First, let’s explain Administrative Distances (AD) a bit:
When adding a route to the Routing Information Base and there are multiple routes of the same length from different protocols, the router needs to decide which route to use. It can not compare based on the protocol’s metrics, because the protocols metrics all mean something else. So, routers use an Administrative Distance to break the tie. Cisco uses the following defaults:

  • 20 for eBGP
  • 110 for OSPF
  • 200 for iBGP.

Lower is better, so you would think that having a valid route in eBGP and in OSPF would always result in eBGP winning and installing it’s route. However, this is not always the case.
Here is the setup:

CE1 and CE2 redistribute BGP into OSPF and advertise a default to the Satellite

The satelites loopback address will function as the network we want to reach. This is In this scenario, CE1 has routing information for the Satelite from three sources: eBGP via WAN, iBGP directly from the Satelite, and OSPF from the C router. Which way will the traffic go?

It seems OSPF has won, even though we have a route with a better Admin Distance from eBGP:

The line begins with an r, which means there is a RIB failure. Other prefixes recieved from this eBGP neighbor get installed correctly:

Did you notice what was missing from the The > indicating best. Let’s see what the BGP on CE1 knows about does the next-hop mismatch mean? A debug ip bgp internal on CE2 shows the following, but I don’t know exactly what it means:

So, here we see iBGP winning the path selection within the BGP process. It will then install the route into the routing table, where we get a collision. AD’s are compared and OSPF wins with its 110 AD vs iBGP’s 200. BGP will never go back and compare the eBGP path to the current installed route, because it already did its own checks. Let’s see this in action with a debug ip routing on CE2, while we reload the Satelite
2) Now, this was even more fun, when reloading the satellite, I got into an update loop: both CE1 and CE2 recieved the iBGP route at the same time, and redistribute it into OSPF. After this, they both prefer the OSPF route from eachother and flush their own LSA 5. After which they both uninstall the OSPF route at the same time and prefer the iBGP route again, ad infinitum. :

The solution here? Since iBGP is basically used as an external route processor, you can adjust the AD for iBGP, so it will win from OSPF:

References   [ + ]

1. What does the next-hop mismatch mean? A debug ip bgp internal on CE2 shows the following, but I don’t know exactly what it means:

2. Now, this was even more fun, when reloading the satellite, I got into an update loop: both CE1 and CE2 recieved the iBGP route at the same time, and redistribute it into OSPF. After this, they both prefer the OSPF route from eachother and flush their own LSA 5. After which they both uninstall the OSPF route at the same time and prefer the iBGP route again, ad infinitum.

OSPFv3 introduces the concept of LSA flooding scopes. There are three scopes, Link-Local, Area-Local and AS. What do these scopes mean? How are they different from OSPFv2?

The scope dictates how far an LSA is forwarded unaltered. Most LSAs are forwarded as is throughout the area they originated in. The AS-External LSA is forwarded throughout the OSPF domain, except into stubby areas. Link-Local scope LSAs are flooded over the directly attached link and no further.

The first two bits of the LSA type identifier also identify the scope, making anything starting with 0x0 link local, anything with 0x2 area-local and anything starting with 0x4 AS scoped. Here are the LSAs per scope:

Link-Local (0x0*) Area-Local (0x2*) AS (0x4*)
Link-LSA (0x0008) Router LSA ((0x2001) AS-External LSA (0x4005)
Network LSA (0x2002)
Inter Area Prefix LSA (0x2003)
Inter Area Router LSA (0x2004)
Type-7 LSA (0x2007)
Intra Area Prefix LSA (0x2009)

Now, this may seem as a weird new thing in OSPFv3, but it works the same as in OSPFv2. First, a quick look at the OSPFv3 LSA types and their v2 equivalents:

LSA type Name LSA Type Name
0x2001 Router LSA 1 Router LSA
0x2002 Network LSA 2 Network LSA
0x2003 Inter-Area Prefix LSA 3 Network Summary LSA
0x2004 Inter-area Router LSA 4 ASBR Summary LSA
0x4005 AS-External LSA 5 AS-External LSA
0x2006 Group Membership LSA 6 Group Membership LSA
0x2007 Type-7 LSA 7 NSSA External LSA
0x0008 Link LSA
0x2009 Intra-area Prefix LSA

I will leave the Group Membership LSA out of this overview, since Cisco has not implemented this. The other LSAs can be grouped in four types of data: neighbor data, intra-area, inter-area and external. Let’s take a detailed look at these groups.

Neighbor data

There is only one LSA in this group, the OSPFv3-unique Link LSA (0x0008). It contains data that is specific to the neighborship on that link, such as the link-local address and router priorities. This information is only necessary for any directly connected neighbor, so is not advertised beyond that. Small detail: Virtual links do no use Link LSAs, so they truly are Link Local.

Intra area LSAs

There are three intra-area LSAs, of which one is unique to OSPFv3. These are the Router, Network and Intra-Area Prefix LSA.

OSPF routers calculate graphs only to nodes within it’s own area. The actual calculation is simple and needs two sorts of information: nodes and edges. Edges should only have two nodes as endpoints, to make the calculation work. With point to point connections, this is simple: all nodes only have one neighbor node connected to any network. These are the point-to-point networks in the Router LSA. But Router-LSAs also contain transit network, which are multiaccess.
With a multiaccess network, you need to simplify the representation of the edges, to get a simple graph again. A full mesh between all routers would quickly balloon to a lot of edges, making the SP calculation a lot harder. A more elegant solution is to represent the multiaccess network itself as a node to the graph. This is called a Pseudo-Node and is exactly what the Network LSA represents.
Because the tree is only calculated within the area, it is logical that the Network and Router LSAs are only flooded within the local area, hence the scope.

OSPFv3 introduces a third LSA that is intra-area: The intra-area Prefix LSA (0x2009). To calculate the tree, you only need to know which node is connected to which other (pseudo)node. You don’t care about the actual IP information attached to the nodes or the edges. So OSPF decoupled this information from the Router and Network LSAs. Since this LSA is basically Metadata about those LSA’s, the flooding scope should be exactly the same.

Inter Area LSAs

There are two inter-area LSAs as well: Inter-Area Prefix (Network summary) LSA (0x200)3 and the Inter Area Router LSA (ASBR Summary) (0x200)4.

To simplify the shortest path tree calculations, OSPF uses areas. The idea about areas is that you calculate the shortest path tree within your area and attach any routes external to the area to an area border router (ABR). So, all you need to know, is a list of prefixes available and information about which ABRs can relay the packets for you. You can throw away all the other information about nodes and edges. An ABR will take the prefixes from all LSA type 3’s from different areas plus all prefixes from Router and Network LSAs in OSPFv2, or from all Intra-Area Prefix LSAs in OSPFv3 from one area and advertise this information as LSA type 3 into another area. Remember, this information will only be advertised into, or out of Area 0. If it goes from one area into area 0 and then out into a third area, the LSA is recreated by the ABR. This means the necessary scope for this LSA is Local-Area

But now we have a small problem. The AS-External LSA (see next section) wil advertise routes external to the OSPF domain. It does this by advertising prefixes attached to an exit node (The Autonomous System Border Router, or ASBR). If we have a simple LSA type 5 from another Area, we don’t know how to reach that node, since we just threw away all node information. Enter LSA type 4, the ASBR Summary LSA (called Inter-Area Router LSA). This LSA is created whenever an LSA type 5 is sent into an area by an ABR. Since this information is also created by the ABR, this LSA has Local-Area scope.

External LSAs

There are two external LSAs: the AS-External LSA (0x400)5 and the NSSA external LSA (0x200)7. Both basically serve the same purpose: to insert routing information from outside the OSPF domain.

The AS-External LSA will contains the prefixes that are advertised into the domain and the node to which these prefixes are “attached”. Depending on area type, you want this information to be available throughout the OSPF domain, so the AS-External LSA has a flooding scope of the entire autonomous system. But wait, if you want this information known throughout the AS, why does LSA type 7 have a flooding scope of Area-Local? This is because LSA type 7 are a patch to make insertion of routes possible in a stub route, transforming it into a not-so-stubby area. This LSA type is only used here, and is translated to a type 5 when advertised into Area 0. So, with LSA type 7 as Area-Local and type 5 as entire AS, you still get all the information everywhere.

So there we have it. We have two reasons for LSA’s to belong to the Local-Area scope: The information is only needed in the local area, or the information is summarized/translated into another area. For AS scope, we have the LSA with information about external routes. For Link-Local scope, we have information about the neighborship only.
All LSAs that exist in OSPFv2 are flooded exactly the same as in OSPFv3, it is just mad explicit in the type identifier.