Teach Me How to Route

Beer me that Route!

I’ve actually been meaning to write this post for 2 months now, but I keep procrastinating and bingewatching Netflix instead.
I found myself in a precarious situation a while ago, something that we’ve since resolved through changes in our network architecture, but prior to the changes, I learned a thing or two thanks to it.
The issue we were having was an issue where the router which terminated VPN connections sat behind a separate router, usually this would not be an issue as we would have enabled EIGRP on them to exchange the routes. The issue however was that we were utilizing VRF-lite on the VPN terminating router to separate the underlay and overlay networks. Due to this, there was no way to get the border router to properly communicate with the VRF.
Now, a preface to this is that generally speaking, all VPN connections would usually have been over a terrestrial transmission piece (we have our DMVPN clouds separated for full-mesh support on the TDMA), however, we were testing out new campus fiber connections which terminated on our border router. The idea was, due to concerns about wire tapping, that we needed to terminate these connections to our IPSEC DMVPN cloud.
Me being me, I didn’t want to create a separate cloud on the border router to terminate these connections, so I ventured out on a journey to learn how to get them to communicate.
It turns out, it’s actually pretty simple.


  1. Import campus fiber /24 into the VRF on the internal router.
  2. Export DMVPN loopback /32 to the global RIB on the internal router, and advertise this network to the border router.
  3. Verify Phase-1 DMVPN connectivity on campus fiber sourced spokes.

Here is a representation of what we’re working with so you better understand. Understand the  “Loopback10” is in the “DMVPN-TERR” VRF.


Step 1:

First, we’re just going to verify that as we have everything setup in our lab, that the following should happen:

  1. From the inner router, A “show ip route vrf DMVPN-TERR” will return 0 entries in the routing table.
  2. From both the inner router and outer routers global RIB, a “show ip route” will return 0 entries.
  3. The spoke should not be able to ping the “” address.

Additionally, at first the /27 for the DMVPN tunnel will be routed to the outer router, this is undesirable.
We need to set in place a route filter, going back to some of our older skills we learned, to prevent recursive routing, which would end up in the looped chain, attempting to stack error.
As expected, all of the following tests responded how we expected!

Changes Needed:

  1. Create a VRF definition for what we’re going to use as our shared routing table.
  2. Place all interfaces which currently reside in the Global RIB on the inner router into our shared VRF.
  3. Create route distinquishers for DMVPN-TERR and our shared VRF.
  4. Configure EIGRP for our VRF.

To create a VRF
Router(config)#vrf definition <vrf-name>
Router(config-vrf)#address-family ipv4
To place an interface in the VRF
Router(config-if)# vrf forwarding <vrf-name>
Once you place the interface in the VRF, re-assign it’s IP address. You will need to do this for anything that currently resides in the default RIB.
After you do that, you must create the EIGRP instance for the VRF, to do this:

Router(config)#router eigrp <asn>

Router(config-router)#address-family ipv4 vrf <vrf-name> autonomous-system <asn>

Router(config-router-af)#network <network> <wildcard>

Since I’ve started working with EIGRP on multiple VRFs, as well as with IPv6, I’ve taken to EIGRP named mode. 
The benefit to named mode is that it’s modular configuration of all EIGRP configurations from within the EIGRP router configuration mode. No longer do I need to enable authentication on a per-interface level. 
To read more about EIGRP named mode:
You can also upgrade your current configuration to named mode with the “eigrp upgrade-cli” command.
Next, to assign route distinquishers to a VRF:

Router(config-vrf)# rd [rd:rd]

  1. Our RD for our DMVPN-TERR will be 9001:900
  2. Our RD for our SHARED-GLOBAL will be 9001:999

Now, to verify that the SHARED-GLOBAL looked like before, do a “show ip route vrf SHARED-GLOBAL”

Leaking Routes:

Now that we have setup our shared tables, we’re going to use route-maps to select which networks we are going to leak into the shared routing and into the DMVPN-TERR routing table.

  1. We need to leak the into DMVPN-TERR
  2. We need to leak the into the SHARED-GLOBAL

To do this, use ip prefix-lists:

Router(config)#ip prefix-list <prefix-list> seq <#> permit <network/mask>

Once you have done that, create a route-map that matches that prefix-list.
Here is what we are going to do:

Router(config)# ip prefix-list PL-FIBER-TO-DMVPN seq 5 permit

Router(config)# route-map RM-SHARED-TO-DMVPN

Router(config-route-map)# match ip address prefix-list PL-FIBER-TO-DMVPN

Router(config)# ip prefix-list PL-DMVPN-TO-FIBER seq 5 permit

Router(config)# route-map RM-DMVPN-TO-SHARED

Router(config-route-map)#match ip address prefix-list PL-DMVPN-TO-FIBER

After we do that, we need to configure the import and export maps on our VRFs, to do this:

Router(config)# vrf definition <vrf-name>

Router(config-vrf)# address-family ipv4

Router(config-vrf-af)# import map <map-name>

Additionally, you have to specify which topology you want to target for import and export.
For our use case, the export will be the self RD, and the import will be the opposite RD.

Router(config-vrf)#route-target import [rd]

Router(config-vrf)#route-target export [rd]

Next, we’re going to enable a BGP instance whose sole purpose is to import/export these routes between the routing tables. I’ve come to call this my “ghost” BGP instance, although I’m not sure if that’s proper whatsoever.
To enable the instance to work with multiple VRFs, use the address family command.
Because the routes we are wishing to share are connected, or learned through a routing protocol, we must utilize the “redistribute” command.

Router(config)#router bgp <asn>

Router(config-router)#address-family ipv4 vrf <vrf-name>

Router(config-router-af)#redistribute <method>

  1. On the DMVPN-TERR, we will be redistributing connected.
  2. On the SHARED-GLOBAL, we will be redistributed EIGRP instance 100

Next, verify this by doing a “show ip route vrf SHARED-GLOBAL” and “show ip route vrf DMVPN-TERR”

Next up, redistribute BGP into EIGRP and you should be able to ping from the spoke to the DMVPN loopback interface.

Now, just to verify our adjacency so I can say my job here is done!


Posted in RoutingTagged , , , , , Leave a Comment on Beer me that Route!

Essential Constructs: Path Manipulation

One of the things that I think is key from separating a good network engineer from a great network enginner is their ability to control the paths which data travels.
As we all know, each routing protocol has built-in best path algorithms, but sometimes, these just aren’t enough. There may be many reasons for an administrator to need to override these routing protocols, in order to do this, you must understand the best path calculation for each routing protocol.

Understanding Best-Path Selection

Key to understanding which route will be installed in the routing table, is understanding how each routing protocol will select it’s candidate to be presented to the routing table.
Once routes are presented from the routing process, to the routing table, the router will select the route with the lowest administrative distance to be installed into the routing table.
[table id=2 /]
Once a route is installed into the routing table, the router will evaluate whether there are any routing policies installed. If a policy based route (PBR) is installed, the router will forward traffic based on that policy. If there is no PBR, the router will forward traffic out the route which has the most specific prefix.
We have two considerations for path manipulation:

  1. How our router will forward packets.
  2. How adjacent routers will forward packets.

The easiest part is manipulating how our router will forward packets, the two simplest ways to do this are via PBR and route-maps. After we configure our path manipulation, we have to consider how we want other routers in the topology to forward our traffic. The easiest way to do this is to place route-maps on our outbound routes. In the future, I may start begin referring to routes as NLRI (network layer reach ability information), but mostly just when talking about BGP.
Before we go any further, and delve into actually configuring a solution, we need to understand how each routing protocol selects candidate routes for the routing table. This is extremely important since we need to know what to change to manipulate administrative distances and metrics.

  • RIP has a default administrative distance of 120.
  • RIP utilizes hop-count to determine its metric, with 1 being the lowest, and 15 being the highest.
  • RIP will not present a route to the routing table with a hop-count of higher than 15.
  • By default, RIP will only route on classful boundaries, it is important that you enable ip classless at the global configuration level and no auto-summary on the router configuration level. This will ensure that RIP includes the complete prefix, instead of just the classful boundary in its routing update.
  • When redistributing routes into RIP, Cisco recommends using a low hop-count (such as 1).


  • EIGRP Internal Routes have an administrative distance of 90; external, or redistributed routes have an administrative distance of 170.
  • EIGRP Utilizes K-Values for Calculation, by default, the only two used for metric calculation are bandwidth and delay. Cisco recommends not changing this. Note: changing K-values on one EIGRP neighbor will cause neighbor-relationship issues with neighboring routers.
    • K1 – Bandwidth (Enabled by Default)
    • K2 – Load (Disabled by Default)
    • K3 – Delay (Enabled by Default)
    • K4 – Reliability (Disabled by Default)
    • K5 – MTU (Disabled by Default)
  • The bandwidth used for the metric calculation is the lowest bandwidth on any interface in the path.
  • The delay is the total time (in tens of microseconds) a packet takes to travel across an interface.
  • The full metric formula is:
    • metric = ([K1 * bandwidth + (K2 * bandwidth) / (256 – load) + K3 * delay] * [K5 / (reliability + K4)]) * 256
  • The simplified metric formula, when using the default K-Values is:
    • metric = bandwidth + delay
  • When redistributing routes into EIGRP, you must specify the bandwidth, delay, reliability, load and MTU for EIGRP to calculate a metric for these routes.


  • OSPF has a default administrative distance of 110.
  • OSPF utilizes bandwidth in its metric calculation.
  • By default, the reference bandwidth is 100MBps, meaning that any interface with a speed above that, will be seen the same as a 100MBps interface in the eyes of OSPF. It is important to change the reference bandwidth to the highest speed interface installed on your router.
  • Reference bandwidth should also be changed on all routers within the same OSPF area.
  • All redistributed routes will receive a metric of 20, except for BGP routes, which receive a metric of 1

BGP has the most robust best-path selection process out of all of the routing protocols. BGP will utilize what is referred to as Path Attributes. BGP has about 13 different attributes it evaluates before selecting a best route. BGP will run through this process until there is a definitive winner. This means that if a path wins and evaluation anywhere along the process, it is selected as the best path.

  1. First and foremost is the Weight, this is generally proprietary to Cisco’s implementation of BGP, the weight attribute is configured by the administrator and is only locally significant.
  2. The path with the highest LOCAL_PREF attribute. BGP assumes a default value of 100 when no LOCAL_PREF has been specified by the administrator.
  3. Path Type; BGP will prefer routes learned through the network or aggregate command, before routes learned through redistribution.
  4. AS_PATH; the AS_PATH defines which autonomous systems the route has past through before it got to us, the route with which traverses the least amount of autonomous systems is preferred.
  5. Origin Type; this informs BGP whether the route was originated from an IGP, EGP or INCOMPLETE. IGP has the lowest origin code, EGP follows, followed by INCOMPLETE. BGP will prefer the route with the lowest origin code.
  6. Multi-Exit Discriminator (MED) – BGP will prefer the path with the lowest MED, the MED is used when routes are received from neighbors with the same ASN. If the router received matching routes from neighbors that are not in the same ASN, this will be ignored.
  7. BGP Neighbor Type; prefer eBGP over iBGP
  8. Lowest IGP metric; self-explanatory
  9. Determine whether we need to present two candidates to the routing table (is BGP multi-path enabled?)
  10. Prefer the path which was received first (oldest path)
  11. Prefer the path which was received from the neighbor with the lowest BGP router-ID.
  12. We’ll skip this; not used unless you are in a BGP RR environment. (I’m also not too sure what the hell it means)
  13. Prefer the path with the lowest neighbor IP address.

The best part about BGP is that it gives us, administrators, the most robust solution to manipulate and engineer traffic in the way we desire. It’s also somewhat confusing, and hard to remember, but don’t be too intimidated, (other than if you’re taking your tests) you can always reference the Cisco support page.

Why Manipulate Paths?

  1. Despite routing protocols having their respective best-path selection algorithms, there may be instances where the router does not take the actual best path.
  2. There may be instances where we need to separate network traffic, and route traffic differently based off of it’s source/destination address.

Methods of Manipulation

  1. Offset Lists; specific to RIP, these will change the outgoing (or incoming) hop-count on a route(I mean, technically you could use them for EIGRP).
  2. Route-Maps; these are powerful, using these we can change the administrative distance, metric, or other attributes to a route.
  3. Policy-Based Routing; policy based routing is essentially static routing, however, we can get extremely granular and specify where we are going to forward traffic based off of the traffic type, source/destination IP address, etc.
  4. IP-SLAs; these are often not considered a method for path manipulation, but can definitely be used as such. IP-SLAs allow us to configure tracked objects and make decisions based off the reach ability, reliability or response time of a path.
  5. Route Filtering; this will be key in manipulating how we want other routers which we are not directly in control of, to forward traffic.

Example #1: RIP Offset List

This example is going to be extremely simple, given the network topology, we’re going to create an access-control list and apply an offset list to our routes going outbound on a specific interface.

Our objective for this lab is extremely simple, we are going to make sure that R1 utilizes path 1 to forward traffic to the network. As we all know, RIP only utilizes hop-count for it’s metric, so although Path 1 has a higher bandwidth, both paths would be seen equally from R1. Due to the fact that both paths would be seen equally, R1 would load balance. This is not a desired action whatsoever, as the traffic share ratio would be 1:1, and RIP would not do what EIGRP does where it will calculate the percentage of packets to be routed out each interface (this is more specific to EIGRPs ability of unequal cost load balancing).
We are not going to make any changes on R1, all changes will be made from R2.
This lab will be utilizing 4 Cisco IOSv 15.6(2)T routers in GNS3. I have posted all the lab files (including diagrams) on the “Lab Files” page, which can be found in the menu bar at the top.
First, verify that the hop-count for the “” network on R1 is 2, also verify that your routing table has two entries for this network:

The first step; creating the access list. For this, we can simply use a standard ACL which matches the network for interface “Loopback 1”.
Router(config)#access-list 1 permit
After creating the access list, you need to go into router configuration mode for the RIP process on R2; the lab already should have RIP enabled and all the interfaces configured. (I’ll post the initial configs in case GNS3 didn’t export them for some reason). For this network, we’re going to offset the hop-count by 3, going out interface G0/0, which leads to path 2.
Router(config)#router rip
Router(config-router)#offset-list 1 out 3 GigabitEthernet0/0

Once completed, do a “show ip protocols”; you will see something along the lines of “Outgoing routes in GigabitEthernet0/0 will have 3 added to metric if on list 1”
If you know somebody at Cisco that could please fix the English on that statement, that would be great. That just perturbs me.

This simply means that if the network is in the access-list 1, and being sent out interface GigabitEthernet0/0 we will report the hop-count as 3 to R3; thus ensuring that path 1 is the preferred path to this network. To verify this, console into R1 and do a traceroute to the network, you should see it traverse through R4.

That was pretty simply, though when using RIP, remember to keep in mind that RIP will not present a route to the routing table if it has a hop-count of higher than 15. This means you can’t offset the route too much, especially if your network has alot more hops than this lab does.
The syntax for the offset list is as follows:
offset-list [acl-name] [in | out] [0-16] [interface-name]
The 4th argument is the hop count which you want to offset, and the final argument is optional (though pretty pointless if you don’t do it, for RIP anyway.)

Example #2: EIGRP Policy-Based Routing and Offset Lists

In this example, we’re going to go with pairing a few things together to get granular control over the path traffic takes. As we all know, EIGRP utilizes bandwidth and delay in it’s calculations, important to know here is that it will use the default interface bandwidth and delay, unless otherwise specified. Sure, it’s absolutely easy to change that, but that’s not the point of this lab. The point of this lab is to show you different ways in which you could manipulate the path for which you want data to travel.
For this lab, we are going to a 6 router topology. All links will be connected via gigabit ethernet, so EIGRP will calculate the same metric for all paths. Given the topology, ensure that voice traffic will always flow over the most desirable path. You will need to do so without configuring interface bandwidth or delay, and you do not have control over any router other than R2. (Well, you can console into all the other routers just to verify, but you cannot configure anything on them).

The first thing we will need to do is create access-lists for the voice and user networks, we will reference these throughout multiple parts of our lab.

ip access-list standard User-Network
ip access-list standard Voice-Network

The first part we’re going to do is create multiple IP SLAs and tracked object. These will give us the ability to monitor the reachability of a network over a certain path. Our first tracked object will monitor the interface on R1 over path 3, the second will monitor the interface on R1 over path 1.
ip sla 1
icmp-echo source-interface GigabitEthernet0/0
timeout 6000
ip sla schedule 1 life forever start-time now
ip sla 2
icmp-echo source-interface GigabitEthernet0/1
timeout 6000
ip sla schedule 2 life forever start-time now

After defining the IP-SLAs, next create the tracked objects which are linked to these SLAs, these will allow us to define specific actions based on the state of the tracked object.
track 1 ip sla 1
track 2 ip sla 2

We have set our IP-SLAs to change their state to failure if they are not able to ping the destination within a 6000 millisecond timeframe.
To view the statistics of your IP SLAs:
show ip sla summary
show ip sla statistics

To view the state of our tracked objects:
show track
For our route-map, we are going to utilize sequence numbers. Sequence numbers are used in access-lists, but also route-maps. Think of route-maps as ACLs for how we want to manipulate routing. If a packet does not match anything defined in the match claw within a sequence, then the router will proceed to the next entry in the route map. If nothing is matched, it will route based off of the routing table.
For our route-map, we’re simply going to match the source IP, and set the next-hop (there are plenty of other things we could do as well, but just trying to show you examples). For our “set ip next-hop” clause, we are going to utilize the “verify-reachability” argument. This will allow us to link the action to a tracked object, the route map will only set this as the next-hop if the tracked object state is “UP”. We will use multiple set entries to set the backup next-hop to R5.
route-map RM-EIGRP-PBR permit 5
match ip address Voice-Network
set ip next-hop verify-availability 1 track 1
set ip next-hop
route-map RM-EIGRP-PBR permit 10
match ip address User-Network
set ip next-hop verify-availability 1 track 2
set ip next-hop

Something to note about route-maps is that multiple match clauses, on the same line are viewed as logical OR statements.
Match statements on different lines are viewed as logical AND statements
After you define the route-map, you must apply it to the interface on which we are going to match the inbound traffic, this would be GigabitEthernet0/2. Do this with the command (from interface configuration level):
ip policy route-map RM-EIGRP-PBR
At this point, if you were to ping R1 with traffic sourced from the User network, it would take Path 1, and voice would take path 3. If you want to see R2 forwarding this traffic, enable the below command and send traffic from R3 to R1 sourced from one of our loopback interfaces.
debug ip policy

For manipulating our metrics, we’re simply going to do what we did earlier with  RIP, and use offset lists. These offset lists will reference the ACLs we already created earlier.
This is extremely simple. On G0/3, we’re going to offset the voice and user networks by +1000, on G0/0 we’re going to offset the User network by +2000 and on G0/1, we’re going to offset the voice network by +2000. Note that for outbound updates on G0/3, we will have to create a new ACL which contains both the User and Voice networks.
ip access-list standard User-and-Voice-Network

Next, hammer down into the router subconfiguration mode for the EIGRP proccess and apply those offset lists:
offset-list User-Network out 2000 GigabitEthernet0/0
offset-list User-and-Voice-Network out 1000 GigabitEthernet0/3
offset-list Voice-Network out 2000 GigabitEthernet0/1

Please note that as part of my initial configuration, I emplaced a route-filter on R1 to ensure that the transport routers (R4,R5,R6) do not receive routes for the User or Voice network from R1.
Now that that is done, you can console into R1 and do a show ip route, you will notice that there is no longer 3 entries in the routing table. You will notice that the user network is seen best out of G0/0, and that the voice network is seen best out of G0/1.

Next, let’s verify our PBR by shutting down G0/0 on R6. Once complete, just wait a few seconds and do a “show track”, you should see a changed state for the tracked object. This should also come up as a syslog message. 
Just verify that our PBR is working by pinging from Lo2 on R3 to anything on R1. Keep the “debug ip policy” running on R2. This is what your output should look like. On R2, you should see the router setting the gateway, or next-hop to

I hope you liked these two examples, and the discussion on path manipulation. Even if this example doesn’t exactly make the most sense, I think it still shows the variety of possibilities we have when configuring path control. There’s alot you could do with path manipulation and it isn’t limited to outbound routes either. We could easily manipulate inbound routes based on a number of properties.
One cool thing that I want you guys to see real quick is that you can tag routing updates with a a value in either decimal format, or dotted decimal format. This is great for EIGRP because by doing this, on the origin router, I can basically tell any other routers within the topology who originated these routes and then filter or modify metrics based off of that.
Hint: I really like the AS_PATH attribute in BGP, because it just makes sense that I want to see who originated these routes.

Posted in RoutingTagged , , , , , , , , , , , , Leave a Comment on Essential Constructs: Path Manipulation

The Ten Commandments: #1 Route Filtering

This is something I want to touch on as it’s a very important subject in my eyes.
Our jobs as network engineers and administrators is to provide seamless communications to clients and servers alike, an often overlooked component of which is (in my opinion) route filtering.
For those who aren’t aware, route filtering is the process of filtering routes, either inbound or outbound, based on a certain criteria. The following is a basic list of criteria we can filter based off of, but is not a complete list (when using BGP you have a ton of different options using route-maps and Path Attributes, that’s something I’ll leave for another post).

  1. The prefix itself (the network we don’t want to be routed)
  2. The source of the routing update
  3. Route Tags (this is a little more advanced, but each routing protocol allows for you to tag updates with a route-tag to give the administrator more granularity)

Now that we know what criteria we can filter off of, we’re going to discuss the methods which we could use

  1. Prefix-Lists, prefix lists are similar to ACLs, they permit (or deny) a network based off of it’s CIDR notation. Prefix-Lists can be used independently, but are most often paired with route-maps.
  2. ACLs, ACLs are simple. We have two options here, if we want to filter based off of the source of these routes, we can do an extended ACL, but if we just want to filter the route which we don’t want to be installed in our routing table, we can simply use a standard ACL.
  3. Route-Maps; this is where we can match off of specific Path Attributes, metrics, and manipulate the routes that are coming in (or going out). Route maps are used for a variety of different things, notably policy based routing, which is a topic I’ll cover in the future.

EIGRP Reaction

EIGRP will act very predictably with route filtering. When the router receives an update, it processes it to make sure that it is allowed to be entered into the EIGRP topology table, if it is not, that network is ignored an not installed in the topology table. We should all understand how routing protocols work in the sense that each routing protocol will use it’s methods to determine the best path, and then forward this to the best-path decision matrix within the router (there’s a specific name for this, but I can’t remember it). It forwards the candidate that it wants the router to consider installing into the routing table. Due to the fact that the network was never entered into the EIGRP topology table, EIGRP never performed metric calculations and will never send this route as a candidate to be installed in the routing table.

OSPF Reaction

As we all know, all routers within an OSPF area must have a matching link-state database, because of this, OSPF reacts a little differently. When you route filter in OSPF, it does not suppress the LSAs (link-state advertisements). I’ll put a post up in the future about dumbing down the LSA types within OSPF. Simply put, if you are attempting to filter a network in OSPF,  you will see the respective LSA in the LSD, however, OSPF will not provide the route with a candidate to install into the routing table. I’m not the best with OSPF so I’m going to stop before I say something terribly wrong. Here’s a good link from INE on the details of OSPF route filtering.

BGP Reaction

BGP filtering is pretty simply, when the router receives an update from a peer, it runs it against any route filtering which has been instated. If a network is not to be accepted, it simply does not transfer the route into the BGP database. There is something important to know here, BGP will not filter updates until you have manually reset the peer. This can be an issue when you have multiple peers or don’t want to lose complete connectivity for a short period of time. The solution to this is the soft-reconfiguration inbound command on your peer statement. This essentially create a segregated BGP cache in memory for that specific peer, in which it would be able to filter after doing a soft reset on the peer (it would not remove any of the routes from the RIB, routes will be in place until BGP finishes it’s calculations and sends the updated route information to the BGP database).
Why Filter?

  1.  Security – we don’t want networks which we aren’t aware about to be able to traverse our network.
  2. Compliance – more specific to BGP and ISPs, but we definitely can’t route for networks we don’t actually own.
  3. Availability/Path Control – filtering updates is important to availability, because we can prevent a route learned from an unintended location from hijacking a legitimate route sourced from some other location on our network (happens a lot with EIGRP and tunnels….BANDWIDTH)

Prefix Lists

Prefix Lists are extremely similar to an ACL. When filtering with prefix-lists alone (not paired with a route-map), you will only be able to filter the actual network which you either want to permit or deny. Prefix Lists use the CIDR notation of the network and can match based off of how many bits of the subnet you want to match up to (le or ge ). If you do not specify the minimum/maximum length to match, the prefix list will only match the specific prefix which you have defined.
What the keywords mean:
le – minimum prefix length to be matched
ge – maximum prefix length to be matched
Similar to an ACL, prefix-lists use sequence numbers and permit or deny statements, here is how you would configure a prefix-list:
Router(config)#ip prefix-list [name] seq [#] [permit | deny] [network/length] [le | ge #]
The below would match any network from
ip prefix-list PL-EXAMPLE seq 5 deny ge 32
The below would the default route, exactly, and nothing else
ip prefix-list PL-DR seq 5 permit
To view configured prefix-lists, utilize the command
Router#show ip prefix-list

Standard ACLs

Filtering using standard ACLs is very simple. If you wanted to deny a route update, you’d simply configure an ACL denying the network. Standard ACLs will only filter based off of the destination included in the update (the network we are receiving an update for).
Router(config)#access-list [#] [seq#] [permit | deny] network wildcard-mask
To view configured ACLs:
Router#show ip access-list

Extended ACLS

This ones pretty useful, using extended ACLs we can filter based off of the source of the routing updates, as well as the network we which to filter. When you think about the structure of the extend access-list, think of the source field as who we are going to filter addresses from, and the destination as the specific networks we are going to filter.
Confused? Don’t be, it’s pretty simple. Here’s what the syntax should look like
Router(config)#ip access-list extended [name] [permit | deny] ip [peer] [mask] [net] [mask]
The following would deny updates from the peer with a network of
ip access-list extended 101 deny host


Route-maps are awesome! Okay, going to curb my enthusiasm here, but their ability to provide a network administrator with complete control is unmatched. Route maps allow you to do everything from manipulating route metrics and route selection, all the way up to (and not limited to) importing and exporting routes between VRFs.
Route maps work off of match and set commands, think of it as a program or script where match is your if statement, and set is the action which would included within that code block.
I won’t go to far into these, I’m trying to keep this a relatively quick post.
The basic syntax for a route-map would be like:
Router(config)#route-map [name] [permit | deny]
Router(config-route-map)#match ip address [prefix-list | acl]

To view configured route-maps
Router#show route-map

Applying them to EIGRP

I’m going to keep this simple and only provide instruction for applying these to EIGRP, I’ll link you to the guides for OSPF and BGP. EIGRP supports filtering via ACLs, Prefix-Lists and Route-Maps.
In every network I’ve been a part of administering, I’ve made it a point that we need to define every back-end network that is going to connect to us, and white-list them from the start. Another use-case  is denying these networks from being routed to the WAN, when they have yet to be scanned by our beloved IA (I know, it’s cyber security now…), but still allowing them access to LAN resources and ability to add machines to workstations, verify CLO and pull updates from our WSUS server.
First, enter the EIGRP sub configuration mode. The in and out keywords do exactly what they sound like, the in command will filter updates incoming, and the out command will filter outbound updates. Lastly, you can actually specify a specific interface which you want that route-filter to apply to, instead of applying it to the entire EIGRP instance.
To configure route filtering using a prefix-list:
distribute-list prefix [prefix-list-name] [in | out]
To configure route filtering using an ACL:
distribute-list [acl-name] [in | out]
To configure route filtering using a route-map:
distribute-list route-map [route-map-name] [in | out]
To view applied filters to EIGRP:
Router#show ip protocols

Posted in Routing, The Ten CommandmentsTagged , , , , , , Leave a Comment on The Ten Commandments: #1 Route Filtering

Uncloaking DMVPN

Many of you may have heard about the wonders of Dynamic Multi point Virtual Private Network (DMVPN), or seen it work somewhere on a Marine Corps networks.
Well today, I’m going to try to demystify the cloud of mystery surrounding DMVPN.
Obviously, we need to start out with that we would like to accomplish

  1. Simplify Hub configuration, by providing a single tunnel interface which multiple spokes are terminated on.
  2. Provide Direct Spoke-to-Spoke communication, with minimal interaction to the hub (we’ll talk about this…)

Let’s get on to how our lab is going to be setup, for this lab I am using GNS3 and using IOSv version 15.6.2T:

  1. 1 Hub Router
  2. 1 Router, emulating TDMA Cloud (imagine this as Linkway modems running RIP, not trying to get too fancy here, just trying to visualize this for you guys)
  3. 3 Spoke routers
  4. All routers source interface will have dedicated VRF-Lite

Here’s a rough diagram:

During this discussion, we’re going to talk about the following protocols and technologies:

  1. Next-Hop Resolution Protocol (NHRP)
  2. Virtual Route/Forwarding Instance (VRF, specifically VRF-Lite/FVRF)
  3. Generic Routing Encapsulation (GRE)
  4. Enhanced Interior Gateway Routing Protocol (EIGRP)


GRE, or generic routing encapsulation is the simplest form of tunneling we can utilize. We should all already be relatively familiar with it, however, if you’re not, we’ll talk about it real quick.
GRE is a form of encapsulation, it will take an original IPv4 packet, and encapsulate it within a new packet. This new packet will have 2 additional header fields, while still maintaining the original IP Header, as well as the payload.
The new fields we will see are the IP Header (outside) and the GRE Header. The IP Header outside includes the source and destination IP address, not to be confused though. This field is specific to the underlay, or publicly routable address, whereas your inner IP header is going to consist of those source and destination private addresses. You might often hear this specific outside IP header referred to as the “Delivery Header”. After this, you have the GRE header, which will include information about the specific protocols being used by the original packet.
I won’t go too much further into depth with that, quite frankly because it’s not needed at all for this discussion, just know that GRE will be adding an additional 24 Bytes to every packet transmitted. If you’re interested in getting into the nitty gritty of GRE, here’s a good link from the Cisco Learning Network:


NHRP, or next-hop resolution protocol is the technology used by DMVPN. NHRPs sole purpose in life is to associate public (referred to as NBMA, or non-broadcast multi-access) addresses, to the associated private address of the tunnel.
NHRP will consist of a Next-Hop Server (NHS), which maintains the copy of the NHRP cache database, and Next Hop Clients (NHC), which will dynamically register with the NHS.

Phases of DMVPN

Phase 1:
During phase 1 of DMVPN, the only member of the DMVPN cloud with a multi-point tunnel will be the hub. The downside to this is that there is no ability for direct spoke-to-spoke communication, however, the simplicity of adding new spokes to the cloud is a plus. Realistically, adding a new spoke to phase requires two additional commands, we would just need to specify our NHRP network ID and NHS. The rest would look like a normal GRE tunnel (with source and destination).
Phase 2:
During phase 2 of DMVPN, all members are multi-point tunnels. This allows for direct spoke-to-spoke communication, there are some catches with this:

  1. We cannot summarize, from the hub, to spokes.
  2. We cannot propagate a default route.

For those two reasons, I’m not going to touch on Phase 2, because it’s just not a feasible (or Cisco recommended) solution. If you were to summarize, or propagate a default route where the specific subnets for each spokes next-hop are not in each spokes routing table, then this would generate Phase 1 behavior.
Phase 3:
Phase 3 DMVPN is most recent, and Cisco recommended implementation. During phase 3, there is spoke-to-spoke connectivity, and you are able to summarize and propagate default routes. The key to this is the NHRP redirect message.
As traffic comes from one spoke, destined for another, the hub router will notice that the destination is in it’s NHRP cache (or if backend network, will notice that the next-hop is in NHRP cache) and generate an NHRP redirect message. This NHRP redirect message will contain all the information the spoke needs to generate a dynamic (and temporary) tunnel to the other spoke. Once this happens, with NHRP shortcuts enabled, the spoke router will re-write the CEF for all routes where the spoke is the next-hop, allowing traffic for backend network to flow directly to the spoke, without the hub being involved whatsoever.
Phase 3 is the implementation of DMVPN that we will be focusing on.
Here is a diagram of what phase 3 DMVPN would look like. The solid lines define the tunnels which would always persist, and the dashed lines define the tunnels which would be created, dynamically, as needed.

And lastly, for those of you (like me) who like to get into the weeds of things, checkout RFC 2332, which defines NHRP:


VRFs, or Virtual Route/Forward Instance (sometimes referred to as VPN Route/Forward Instance), are similar to VLANs. As we know, VLANs can segregate a physical switch into multiple different broadcast domains. VRFs may not seperate things into their own broadcast domain, but they do seperate them into their own routing domain.
Using a VRF is essentially having a separate routing table. (key concept)
On top of having it’s own routing table, each VRF will have it’s own RIB (routing information base), and when CEF is utilized, it’s own CEF table.
Because VRFs are essentially a router within a router, you can have multiple interfaces with the same IP addresses and routing processes which would otherwise interfere. Inter-VRF communication can be configured, but is not a default whatsoever.
For our purpose, we will use a simple Front-Door VRF which will provide a default static route pointing towards what would (in real life anyway) be our Linkway modem. In real life we would need to ensure that we create full-mesh PVCs on our MRT, as well as enable RIP on all the sites.

For those interested in learning more, here is a link to Cisco’s VRF Design guide.


We all know this one, and we all know exactly why I’m covering it. For that reason, I won’t go to into it. Just know that for DMVPN, we must disable split-horizon for EIGRP to work properly.

Step 1 – Interface Addressing, and VRF Routing

First and foremost we must define our VRF. We will do this before we assign our source interface  an IP address. This is because once you remove an interface from the global routing table,  and assign it to a VRF, the router will remove the IP address from the interface. To create a VRF, follow the steps below
Router(config)#ip vrf [name]
Router(config-vrf)#description [string]

Now that you have created the VRF, you can assign your source interface to the VRF, to do this, enter interface configuration mode and type the following
Router(config-if)#ip vrf forwarding [vrf-name]
After doing this, you can now procede to configure your IP address.
Once you have your interface configured, and assigned to the VRF you created, you can now create a static default route using the following command.
ip route vrf [vrf-name] [next-hop-ip] name [name-this-route]
Note: if you were on a multi-access network (not point-to-point) it would be essential that you specify the next-hop IP address, instead of the exit-interface. I follow this standard altogether, and when I’m feeling frisky I’ll even fully specify it!
Pro-tip: Name your routes so when the other guy, who doesn’t know what you did, does a show run, he might be able to figure out what that route is for, and not delete it!
Now that you’ve created the route, you can verify it by viewing that VRF’s routing table
Router#show ip route name [vrf-name]

Note: anytime you need to ping, or traceroute something which utilizes this VRF, you must use the VRF keyword in your command.

Router#ping vrf [vrf-name] [destination]
Router#traceroute vrf [vrf-name] [destination]

Here’s what my Hub config looks like at this point in time (anything that is default has been redacted) this is what your config should look like for every router in the topology so far:
ip vrf TDMA
description FVRF for TDMA Cloud (All TDMA Modems)
interface GigabitEthernet0/0
ip vrf forwarding TDMA
ip address
duplex auto
speed auto
media-type rj45
ip route vrf TDMA name TDMA-Modem-Default-Route

Here’s the output of both my global and VRF routing table, so far:


Step 2: Creating the Tunnel (Hub)

Before we continue, we should probably discuss our network ID, for all intensive purposes, we’re going to use 1775 as our network ID… To be completely transparent, the NHRP network-ID is locally significant, and you could definitely have every router in the topology with a different network ID, it would still process the NHRP associations.
Something that is significant to all, and must match on all is the tunnel key, this is optional and used for multiplexing multiple DMVPN clouds over the same source interface (there are some instances where you might want to separate DMVPN clouds).
For our tunnel key, you guessed it, 1775.
Our tunnel network is going to be the network, our NHS (the hub) will be
Something to note is that since we are utilizing the VRF, we will have to do something just a little different when we create our tunnel
The first thing you should do is create the tunnel (quite obvious here), but once you do this, before you do anything else, be sure to inform the tunnel that it will be using a VRF to route all destination traffic (not to route actual payload traffic).
Router(config-if)#tunnel vrf [vrf-name]
Next up, let’s define our tunnel mode as “gre multipoint”
Router(config-if)#tunnel mode gre multipoint
Now that you have done that, define your source, and assign your IP address, the interface at this point will show Up/Up (or atleast should…)
Next, we need to specify our NHRP commands, there’s only a few we need to enter:
ip nhrp network-id [id]

ip nhrp map multicast dynamic

ip nhrp redirect

The first command defines our NHRP domain, locally significant, similar to a process ID for OSPF.
Next, we tell the tunnel that it will listen for registration messages and dynamically map that “ip nhrp map multicast dynamic”
Lastly, we input the redirects command. This will tell the router that when it receives traffic from one spoke, destined for another spoke, that it needs to generate that NHRP redirect message and inform the spoke that it can create a spoke-to-spoke tunnel and leave the hub out of the communication.
Something you could do, and is extremely easy to implement, is NHRP authentication. Note that NHRP authentication is sent in clear-text and really just utilized to prevent unauthorized devices from entering your DMVPN cloud
ip nhrp authentication [string]
At this point, you should be done configuring the hub tunnel, there are obviously some more important things we would need to get into, such as timers, but since we’re just labbing it out, I’ll let you do the research for all that, as everyone will need different registration timers based on situation.
Now I’m going to enable routing, my EIGRP ASN is going to be 1775, and I’m going to propagate a summary default route to all of my spokes. This is generally what the start of my EIGRP configuration looks like.
Router(config)#router eigrp [asn]
Router(config-rtr)#network [network] [wildcard]
Router(config-rtr)#no auto-summary
Router(config-rtr)#passive-interface default
Router(config-rtr)#no passive-interface [interface-name]

And now, to disable split-horizon, and add that summary default route.
Router(config-if)#no ip split-horizon eigrp [asn]

Router(config-if)#ip summary-address eigrp [asn]

Here’s what my hub configuration looks like at the moment:
router eigrp 1775
passive-interface default
no passive-interface Tunnel1
interface Tunnel1
ip address
no ip redirects
no ip split-horizon eigrp 1775
ip nhrp map multicast dynamic
ip nhrp network-id 1775
ip nhrp redirect
ip mtu 1400
ip mtu 1368
ip summary-address eigrp 1775
tunnel source GigabitEthernet0/0
tunnel mode gre multipoint
tunnel vrf TDMA

Something I didn’t touch here is MTU and MSS, but since we know we’re adding 20 Bytes to the packet, we know that we need to adjust, I put it at 1400 on mine, because I do intend to show you guys (at the very end) how to implement IPSEC.

Step 3: The Spokes!

Configuring the spokes is relatively easy, knowing what we know, and given that we already created the VRF and assigned the source interface to it, we should be all set to start seeing some associations pop-up.
First, I want to start by stating that there are two additional commands we will need to enter. This is something that I’ve had to do only when the spokes are utilizing an FVRF, if you don’t do it, the hub will never form an adjacency with the spoke (the spoke will form an adjacency, because it received the hellos, but the hub has not received any hellos, although they are being sent, bizarre, I’ll have to post some PCAPs sometime…Update: interestingly enough, running “debug nhrp”, the router is having an issue with resolving the NBMA address, because it cant find it in the global RIB, sort of what I figured to begin with).
Router(config-if)#ip nhrp map mutlicast [hub-nbma-address]
Router(config-if)#ip nhrp map multicast dynamic
Router(config-if)#ip nhrp map [hub-nbma-ip] [hub-tunnel-ip]
Router(config-if)#ip nhrp nhs [nhs-ip]
Router(config-if)#ip nhrp network-id [network-id]
Router(config-if)#ip nhrp shortcut

The first command will tell the router where to send multicast packets to (important for EIGRP).
The second command will inform the router that it can dynamically associate itself with other routers.
The third will create a static NHRP associate with the hub, something that when using an FVRF, I found necessary, although it could be a bug in the IOS I’m using.
The fouth command will tell the router who the NHS is, the NHS is the next-hop server and is the router which maintains the NHRP cache database (the hub).
The fifth command, we already know.
The size command informs the router that it can expect NHRP redirect messages, this is what truly makes your configuration phase 3. This will allow the router to accept those NHRP redirect messages and generate a spoke-to-spoke tunnel, as needed.
After you configure all that, make sure that we configured it similar (obviously not identical) to the hub. Here is the output of my Spoke 1 Router configuration:


interface Tunnel1

ip address

no ip redirects

ip mtu 1400

no ip split-horizon eigrp 1775

ip nhrp map multicast dynamic

ip nhrp map

ip nhrp map multicast

ip nhrp network-id 1775

ip nhrp nhs

ip nhrp shortcut

ip tcp adjust-mss 1360

tunnel source GigabitEthernet0/1

tunnel mode gre multipoint

tunnel vrf TDMA


After completing the first spoke, go to the hub and just verify real quick that the spoke is registered, you can do this with the following commands:
Router#show ip nhrp
Router#show dmvpn

Here is the output of the hub:

An important note is that we should not rely on the spoke output for the “show ip nhrp” command, as we have statically created that association to the hub, and even when it’s not working correctly, the association will still show. You should also verify your EIGRP neighbor table, and topology table (important to make sure routes are actually being exchanged, if not you might have the situation I talked about earlier).

Step 4: Let’s Generate those Spoke-Spoke tunnels

This part is extremely simple; all I’m going to do is show you how that tunnel gets created. For this I’m just going to ping spoke 2’s tunnel interface from spoke 1, capture the traffic in Wireshark, and do some traceroutes…
As you can see from the traceroute, traffic originally traveled through the hub, but after a few packets (after the hub sent the NHRP redirect message) traffic was sent directly to the spoke. You can also see that the router has the other spoke in it’s NHRP cache. Please take note that this tunnel states “Dynamic”, this means that the information was retrieved from the NHS.

How bout that PCAP, here’s what that NHRP redirect looks like when running wireshark! Although Wireshark does not refer to it as an “NHRP Redirect”, it does refer to it as an “NHRP Traffic Indication”.

Verification and troubleshooting commands

Router#show ip nhrp
Router#show dmvpn
Router#show ip cef
Router#show adjacency
Router#show ip route [vrf vrf-name]
Router#show ip eigrp neighbors
Router#show ip eigrp topology
Router#show ip protocols
Router#debug ip eigrp
Router#debug nhrp

Something I failed to mention earlier in the post is the actual underlying difference between Phase 2 and Phase 3 DMVPN. During phase 2, when a spoke would communicate to a spoke, it would generate an NHRP Resolution Request, directly to the spoke, the spokes would initiate their tunnels. During phase 3, however, the spoke is not yet aware that there is another spoke, he only knows of the hub. When traffic is sent destined for another spoke, the hub recognizes this and sends and NHRP redirect message, which contains the NBMA and private addresses required for those spokes to communicate. Phase 3, the hub would initiate the spoke-to-spoke tunnels.

Posted in RoutingTagged , , , , , , , Leave a Comment on Uncloaking DMVPN