Building a DMVPN topology, has quite a few bits of configuration on quite some devices. It can all seem a bit daunting, especially since most examples just give you the different configurations for the hubs and the spokes in one go. Iin reality, there are only a few lines that differ among the devices. There is some configuration that has to be unique on each device, some that differentiates between a hub and a spoke and the rest is the same across the board. The differences all have to do with these answering these questions:

Scope Questions
Unique per device: How do I source my packets?
Hubs only: What should I do with incoming NHRP registrations?
Spokes only: Where should I send my NHRP registrations?
All devices: How do I identify a tunnel and how should I handle my packets?

I will handle each seperately. All configuration here is done under interface tunnel NUM.

Unique per device

To answer the question how to source the packets, you need two pieces of information: A source address outside of the tunnel and a source address inside of the tunnel, so there are only two lines unique per device:

Hub config

The difference between hubs and spokes is that the hub listens for incoming tunnels. You don’t actually have to configure anything, but since we want multicast to work for routing protocols to work properly, we will tell the Hub to register multicast traffic in NHRP:

Spoke config

The spokes are the ones actually actively setting up the tunnels. So, they need to know where to send their NHRP registrations. For this, they need to know two addresses. The NBMA (hubs public IP) and the Tunnel IP of the hub. You can repeat this line to create a multi-hub topology:

Shared config

The shared config is all about identifying the tunnel, and specifying common parameters, such as ipsec profiles, MTU and timers. All parameters should match between the devices.

First, we set the type of tunnel, which is mGRE

The MTU needs to be lowered, in order to be able to fit all the tunnel overhead in the packets. mGRE costs 28 bytes. If you add IPsec in tunnel mode, this could balloon fast. The biggest I could find in the IPsec overhead calculator was a total of 152 bytes, including GRE.

Next, we have the NHRP id and password in combination with the tunnel key to identify the set of tunnels. These are just identifiers, and can be set to anything you like. The password is set plaintext, if you don’t use any encryption on IPsec.

Optionally, we can set a holdtimer for NHRP routes. Cisco recommends a value between 300 – 600.

Last, but most certainly not least, we can set the IPsec profile. Without this, the tunnels will come up, but your data will be unencrypted. The configuration of the IPsec profile is out of scope of this post, but should also be the same on all DMVPN devices.


There you have it. The only difference between the spokes and the hubs is the NHRP mapping, the only difference between all devices is the source information. At least, for a phase 2 DMVPN, which we built here. The differences between the phases will be explained in a different post.

While trying my hand at an INE question, I was triggered to figure out how EIGRP summary addresses work. What happens if we summarise a network to the exact same prefix? How can we play with the results?

To try this out, I built a small topology. R1 represents the provider, who advertises only a default route through BGP. R2 and R3 will advertise the EIGRP networks to R1 and redistribute BGP into EIGRP. Later, R2 and R3 will summarise this default network. R1’s loopback ( will represent the outside networks.

EIGRP Summary

The setup on R3:

Everything works, both R4 and R5 will take the shortest path out:

Now, let’s see what happens when we summarise the default network to the same prefix. Only on R3 first:

So, both R4 and R5 still have a default route. Howerver, R4 now wants to go through R5 and R3. At first I thought this was because I am redistributing the BGP route with a BW of 1Gbit and the summary is being advertised with a BW of 10Gbit. Later I figured out the real reason: The summarised route is advertised as EIGRP internal and the redistributed route is advertised as EIGRP external. EIGRP defaults to preferring internal routes, so the summarised route wins:

A trace should still work, right? R3 gets the default route from BGP. R4 and R5 know a default route towards R3. Let’s try this out:

Wait! We are getting unreachables. Why? Let’s check R3, because it is the router generating the unreachables:

The EIGRP summary route wins from the BGP route, because it has an AD of 5, which is better than eBGP’s 20. The router doesn’t care if the route points to Null0, or not. A route is a route. Let’s fix this, and let’s do all the same summarisation at R2 as well (not shown):

That is better. But, to be honest, we are not getting the summary route, we are getting the redistributed BGP route, as you can see from the D*EX. Does this even summarise any networks? Let’s have R1 advertise it’s loopback address and see what happens:

So, the summary does not get advertised, but it does suppress all other advertisements. Now, how can we break this further? Let’s kill the BGP connecting between R3 and R1, and see what happens:

We have the same problem as before, R3 is installing the Null0 route. R5 will not be able to connect to R1. Even worse, R4 will prefer the R3 route, because it is EIGRP internal instead of EIGRP external, and so is preferred:

Can we fix this? Yes, we can! Through the magic of an unreachable AD.

Now even R3 has a backup route and everyone can ping happily ever after.

So, in short, this is what I learned:

  • EIGRP summary routes will overwrite existing routes of inferior AD,
  • EIGRP will prefer internal routes over external routes, regardless of metric,
  • You can use an infinite AD on a summary to filter out more specific routes,

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.

Hello world,

My name is Jelmer Siljee and I am working towards my CCIE. I have been working on this for the last 2 years, at times more intensely than others. But, now I have set a date for the Lab exam: April 1st, 2016.

The purpose of this blog will be to help me keep focussed on my progress and a place to keep my notes. And of course, to keep myself accountable.
I have recently built a progress-o-meter in excel, to track where I need to focus. This gave me the drive to study PPP, a subject I could not interest myself in before. I also tried my hand at my first diagnostics problems from the INE workbooks. I only got half the points, which show that I still have some work ahead of me, but also that this should be achievable. If the actual lab questions are anything like this, I think they are a fair assessment of peoples theoretical knowledge. the questions did drive home the point that I should dust of my flash cards and review the theories again.

Until next week, when I will be taking a look at OSPFv3