Archives for posts with tag: routing

This feature is similar to Cisco IPSLA, in that it tracks the reachability of a destination and can remove static routes based on the ping response.

Simple topology with Palo-Alto connected to the internet and using path monitor on the default route. Internal interface peering OSPF with the core router and redistributing the static route but only when the ping responds.











First create the static route
Network -> Virtual Routers -> (router) -> Static Routes -> Add+

Virtual Router - Static Routes

In this scenario the path monitor will ping the opposite side of the link and Google DNS, both must fail for the condition to be met. Interval and count are default (5 pings 3 seconds apart). Once the pings fail, the route will be removed from the routing table. When the router is able to ping the destination after a failure it waits 2 minutes before re-installing the route, this is default preemptive behaviour and can be changed.

Next create a redistribution profile that redistributes your routes, what I found was that if you redistribute ‘’ that means all routes, if you have other routes you don’t want to redistribute just match them with a lower priority and choose ‘No redist

Network -> Virtual Routers -> (router) -> Redistribution Profile -> Add+

Redistribution Profile

Configure OSPF as you normally would with any other device no difference here the usual attributes must match. Area 0 is the same as Area

Next apply the redistribution profile to OSPF and check ‘Allow Redistribute Default Route‘. You have the option to set external type, metric and tag.

Network -> Virtual Routers -> (router) -> OSPF -> Export Rules -> Add+

Export Rules

The Palo-Alto should have formed neighbors with the core router and be redistributing the default route. This can be seen here. Network -> Virtual Routers -> More Runtime Stats. You can also view the routing table here and the forwarding table along with OSPF neighbors etc.

Run Time Stats

Currently the core router receives the route from the Palo-Alto


Next fail the routing on the internet router to see the impact on the path monitoring. The outcome is, the route is withdrawn (debug ip routing)

Route withdrawn

Path Monitor (down)

On the core device you may have a floating static or default route with a higher metric from a different IGP, waiting to take over in the event of a failure to the Palo-Alto.

When routing is restored you can view the preempted route counting down. After the 2 minutes the route is re-instated.

Preempt hold

That’s it, works great.



Dynamic Virtual Tunnel Interface.

It’s a similar concept to DMVPN but with a few differences

  • dVTI requires a smaller packet header only 4 bytes compared to DMVPN which is an additional 28 bytes
  • dVTI does not  use NHRP
  • dVTI has backwards compatibility with IPsec direct encapsulation
  • dVTI requires IP unumbered
  • dVTI requires the use of a dynamic routing protocol instead of keepalives
  • dVTI must be initiated by the remote branch to the head-end

I personally like the fact that the interface is unnumbered as it reduces the amount of IP address space that you need to manage. Each virtual template can be configured with different characteristics on the head-end device so that common branch offices share the same settings. This type of solution is ideal for a hub and spoke design.

I’m not saying dVTI is better or worse than DMVPN it’s just different.

The spoke forms an EIGRP neighbor with the HUB, you can then advertise a default route to the spoke. If you want to apply policies like QoS you can do this directly on the template interface.  The spoke will advertise the LAN network to the Hub and you can then summarise at the Hub into the data centre for multiple spokes.

Here is the configuration with a front VRF, this was tested in the lab on live equipment.

Hub Configuration

vrf definition internet
 rd 1:1
 address-family ipv4
 crypto keyring KEYRING vrf internet 
  pre-shared-key address [IP ADDRESS of SPOKE or match all] key cisco
 crypto isakmp policy 10
  encr aes
  hash sha256
  authentication pre-share
  group 14

crypto isakmp profile ISAKMPPROFILE
  keyring KEYRING
  match identity address [IP ADDRESS of SPOKE or match all] internet
  virtual-template 1

crypto ipsec transform-set TSET_SECURE esp-aes esp-sha256-hmac

interface Loopback0
  ip address
 interface gig0/0
  vrf forwarding internet
  description outside_interface
  ip address [WAN Interface IP and Subnet Mask] 
  no ip redirects
  no ip unreachables
  no ip proxy-arp

interface gig0/1
  description inside_interface
  ip address

interface Virtual-Template1 type tunnel
  ip unnumbered Loopback0
  ip mtu 1408
  ip summary-address eigrp 1
  tunnel mode ipsec ipv4
  tunnel vrf internet
  tunnel protection ipsec profile IPSECPROFILE_SECURE

router eigrp 1

ip route vrf internet [next-hop to internet]

Spoke Configuration

vrf definition internet
 rd 1:1
  address-family ipv4

crypto keyring 1 vrf internet 
  pre-shared-key address [IP address of HUB] cisco

crypto isakmp policy 10
  encr aes
  hash sha256
  authentication pre-share
  group 14

crypto ipsec transform-set TSET_SECURE esp-aes esp-sha256-hmac

crypto ipsec profile IPSECPROFILE_SECURE
  set transform-set TSET_SECURE

interface Loopback0
 ip address
 interface Tunnel0
  ip unnumbered Loopback0
  ip mtu 1408
  tunnel source gig0/1
  tunnel mode ipsec ipv4
  tunnel destination [IP address of HUB]
  tunnel vrf internet
  tunnel protection ipsec profile IPSECPROFILE_SECURE

interface gig0/1
  description outside_interface
  vrf forwarding internet
  ip address [WAN Interface IP and Subnet Mask or DHCP]

interface vlan 1 
  description inside_interface
  ip address
  no shut

router eigrp 1
  eigrp stub connected summary

To verify you can use commands like below.

“show ip int brief”
“show ip interface virtual-access1”
“show ip eigrp neighbors”
“show crypto isakmp sa”
“show crypto engine connections active”

Update: You might notice I have used classic EIGRP instead of EIGRP named mode, the reason was due to the fact that under the af-interface virtua- template I wasn’t able to set the summary route, the command was accepted but wasn’t being sent to the neighbor. Perhaps this is a bug in the version I was running.


One of the most interesting features i’ve noticed about LISP is the ability to encapsulate IPv6 packets and transport them between IPv4 only RLOC’s. This can be used for a transition strategy.

The best parts are you don’t have to configure tunnel endpoints, it works in a multi-homed environment and supports communications between LISP and non-LISP sites (with a PxTR). The document describes this as ‘IPv6 islands over an IPv4 core’.

I read about LISP online and watched the Cisco Live presentation from Berlin 2017 (BRKRST-3045). I wanted to see this for myself.

The lab is direct from If you want to lab this, go grab the PDF. The lab is pretty good and gives you the chance to see LISP in action, all the configs and step by step guides are provided.



Look at the packet from wireshark. This is a ping between R111 host and R117 Host. This was captured at the exit of  core R113 (before decapsulation). It has the IP header from R112 (ETR) to R116 (ITR), next is UDP dst.port 4341 (LISP), next LISP Data, then the IPv6 header and ICMP message. So its easy to see how this works.

packet Capture

For traceroute , the only hops that are visible are IPv6.


Before I could connect to anything in Site2, the ETR (R112) had to request mapping information from the MS/MR, once it was returned R112 then knew how to forward traffic towards 2001:DB8:B:1::3. From R112 perspective it now has a map for the prefix 2001:DB8:B::/48 and the RLOC is


If you want to know what LISP can be described as read this article by Ethan Banks


Ran into this at the weekend when I was working on some Data Centre switches, within the fabric the switches use jumbo MTU. So when I tried to peer a device that was not part of the fabric, I got stuck in EXSTART.

run “debug ip ospf adj” you will get a message similar to this.

OSPF-1 ADJ Gi0/0: Nbr has smaller interface MTU

Answer: match the MTU on both sides.
I had a read through TCP/IP Volume 1, It doesn’t mention MTU size anywhere. RFC 2328 does mention it.

If the Interface MTU field in the Database Description packet
indicates an IP datagram size that is larger than the router can
accept on the receiving interface without fragmentation, the
Database Description packet is rejected.

This is where wireshark comes in handy.

The MTU isnt sent in the Hello packet its sent in the type 2 DBD packet, this is after the neighbors acknowledge each other (2WAY). See below.



I was asked question about MPLS labels within a VRF. Well the question was ” when I type the command ‘show mpls ldp bindings vrf xxx‘ ” I don’t see any labels for my remote site prefixes.

In this case these labels aren’t assigned by LDP they are assigned by BGP.

The command he was looking for was “show ip bgp vpnv4 vrf xxx labels” I think a light went on in his head when i explained this to him!

If your still confused , imagine the LSP (unidirectional) R1 -> R4 is basically a virtual connection if you like , where R4 is the egress LSR for the packet. The packet will travel via R1 -> R2 -> R3 -> R4. The next hop actually is listed as R4 even though it has to pass through R2 and R3. Which by the way has it own labels to add on top of bottom of stack label for R4.


R1 pushes on the label 1234 for R4 and another label on top for R2 which is 22, next R2 removes its own label (22) and adds the label for R3 which is 33, R3 removes its own label (33) and forwards the packet with the label 1234 to R4. Bottom of stack bit is set to 1, R4 removes the label and forwards.


I will follow-up my notes with some labs over the coming weeks.

Enabled on the router with “ip multicast-routing
reserved range for IPv4, FF00::/8 for IPv6

If multiple PIM routers on the same LAN only one can forward the join and prune messages to the RP, so there is an election on the Designated Router (DR) uses the highest IP.

PIM Dense-Mode – uses a push method to all routers and if no hosts need the stream the router prunes off, this repeats every 3 minutes so not ideal for a large deployments.

Bi Directional PIM – uses shared trees (*, G) , this is useful for large scale deployment saves the RP building multiple source tree entries. The emphasis on location of the RP is critical in this mode, to ensure loop free path there is a designated forwarder (DF) role, this is worked out by the lowest cost unicast path to the RP.

PIM Sparse-Mode – uses on demand mechanism, clients will send a join message. Requires a Rendezvous Point (RP) Initially the multicast source will send traffic and the RP will build the source tree (S,G), once a client requests the stream the RP builds the shared tree (*,G) and source receives the traffic, if there is a better unicast path to the source the router (RP)will build the source tree (show ip mroute) and begin using that path.

PIM Sparse Mode Message Process.

Uses 7 messages , Hello, Bootstrap, Candidate RP-advertisement, Join/Prune, Assert, Register, Register-Stop, Neighbour discovery uses hello messages on PIMv2

Source sends traffic to destination multicast address, first router will see this and send a PIM register to the RP, RP acknowledges with register-stop, the RP now has the (S,G) entry in mroute table

Receivers send an IGMP join to the LAN the Designated Router (DR) will send the PIM join message to the RP, each router adds the OIL (outgoing interface list)back towards the receiver for (*, G)

Once the receiver knows about the RP and the source knows about the receiver, they will look to then build the source tree (S,G) entry.

RPF- Reverse path forwarding.

Loop prevention method for multicast, checks the multicast source address against the unicast routing table to see if it should be coming from there if not it will drop the packets.

Rendezvous Point

Statically assign this on each router with command “ip pim rp-address x.x.x.x”, this must be done on each router participating in multicast.

Auto-RP – we use commands to assign the mapping-agent and the candidate RP, we could have redundant RP’s or limit each RP to a certain Multicast address with filtering using ACL’s
we use “ip pim send-rp-announce [interface] scope [0-255]” , the scope is the number of hops we allow this to travel or TTL. Once configured it will begin to send RP-Announce message to the every 60 seconds

Next the mapping agent listens for RP-Announce messages from the C-RP’s and selects the RP’s. It then advertises the RP’s t the rest of the PIM domain RP-Discovery messages to every 60 seconds. “ip pim send-rp-discovery [interface] scope [0-255] interval [seconds]”

We can change the intervals at which RP announce and discovery messages are sent out by using the interval command at the end of the command. Shown above.

Cisco use the “ip pim auto rp listener” command to overcome the sparse mode problem with routers adding the RP. Use this on non RP routers. This is known as the chicken and the egg scenario. You need multicast to run multicast.
This enables the sparse-mode interface to dense flood only the rp-annoucne and rp-discovery messages on , enabling the RP to be elected on a sparse-mode network.

PIM BSR – Boot Strap Protocol – open standard compared to auto-rp , uses the all PIM routers address of and TTL of 1. So we select the BSR using the command “ip pim bsr-candidate [interface]” next we can set the candidate rp using “ip pim rp-candidate [interface]”

When router is configured as candidate BSR it sets timer to 130secs then listens for other BSR candidate messages, it advertises its priority 0-255 and IP address, highest priority wins, and then begins sending out BSR messages every 60 secs. When a PIM router receives a BSR message it floods out all interfaces except the one it received it on, this ensures the rest of the multicast routers know who is the BSR.

Once the BSR is know the C-RP begins sending candidate-RP-advertisement messages to the BSR (unicast) they contain the priority 0-255, RP IP address and the Multicast group address for which the RP is an originator for.

Hash function is useful for large multicast deployments where lots of sources are used, when we use the hash feature the RP’s can be load-balanced, the BSR advertises advertise a hash mask in its messages and the receiving routers run the algorithm that can assign a consecutive number of group addresses to one C-RP then it will assign the next group to the next C-RP, much like a standard subnet mask would work. This is specified in the “ip pim bsr-candidate” command.

RPF with Tunnel – This is implemented when need to load-balance traffic over to equal-cost path’s but with the RPF this prevents load balancing over physical links. So for example we would build a tunnel between the two routers that pass traffic through the two links, using per-destination or per packet balancing. (no ip route-cache) on the interfaces. This used along with the ip mroute command should see it work

Source Specific Multicast – Defined in RFC 4607, enables you to identify a set of multicast sources not only by group address but the sources as well, the SSM group is called a channel this is identified using the (S,G) the reserved group address’s for SSM and the IPv6 range FF3x::/32.
SSM channel is defined by a source and a group address so multiple sources can be assigned to the same group for examples. ( , then ( , this is a unique channel for each multicast group. Hosts will only receive traffic from the requested sources. Can help to protect against DOS attacks.

No RP is needed in this mode as Source Trees are built directly towards the source, because the source is already known. This uses the unicast routing table for forwarding decisions, The multicast source must be manually inputted in advance.

Enabled with “ip pim ssm default” also relies on IGMPv3 so “ip igmp version 3” this command is used at interface level

IGMP – Internet Group Management Protocol

IGMP is the protocol that functions between the hosts, it allows the router to know that a host is interested in the receiving the multicast stream for specific group.

Routers acts as a querier checking to see if host are still interested in a stream, on a LAN segment when more than one router exists.

IGMP is enabled when PIM is enabled has a TTL of 1 and are restricted to the LAN

IGMP 1 – RFC 1112, sends IGMP queries to (all-hosts multicast address) has no election as the IGMP querier, only one host per multicast address replies to the query all other suppress, no mechanism to leave the group. could take up to 3 minutes after the client has stopped listening before the traffic flow will stop.

IGMP 2- RFC 2236, querier election mechanism based on IP address ensures one router per segment sends IGMP.leave group message host send message to leave group when no longer requires the traffic. Leave latency reduced when compared to V1, when a host wants to leave the multicast stream is sends the leave message to (all routers multicast)

IGMP 3 – This version added support for SSM (source specific multicast) which allows for the client to not only specify the group they want to subscribe to but also the source of that traffic (useful if there are many sources in the same group).


Well Known Multicast Address

————————————————————- All host group which contains all devices on the same network All multicast routers group which contains all routers on the same network PIMv1 All OSPF All OSPF DR EIGRP PIM v2 all PIM routers multicast address. IGMP Version 3 Cisco Auto-RP-Announce address Cisco Auto-RP-Discovery address

MSDP – Multicast Source Discovery Protocol

Purpose is to discover multicast sources in other PIM domains, what happens is your own RP’s exchange information with RP’s in other domains. Just like BGP each peer must be explicitly configured. When a PIM DR registers a source with the RP, the RP sends out a SA (Source Active) message to all its MSDP peers.

SA message contains.
Address of the source
group address to which the source is sending
Originating IP

Uses TCP port 639 for peering connections

Every MSDP peer that receives a Source Active message floods those downstream to its own peers from the originator. If the RP receives more than one copy of a SA, the RP will consult the BGP next hop database to determine the next hop towards the SA originator. If AS is non-transit or stub the consult of BGP next hop database still applies to override this we use the command “ip msdp default-peer” so RPF checks are not necessary. One path – no possible loops.

MSDP Mesh Groups are used effectively when multiple RP’s are present in a single domain sources always register to certain RP’s but members must find any source. Every RP has a peering to all other RP’s in the domain. Mesh groups are configured with the command “ip msdp mesh-group [WORD] [IP address]”


Inbound – here is an example of an inbound SA from msdp, only allows SA messages for group from the source
access-list 101 permit ip host host
ip msdp sa-filter in list 101

Outbound – here is an example of an outbound SA filter which only sends SA messages to peer from specific group from source
access-list 102 permit ip host host
ip msdp sa-filter out list 102

Locally originated sources can be filtered with the command same idea as above.
ip msdp redistribute list xxx


A simple explanation of anycast is packets can be sent to a single IP and any number of devices can respond. When PIM-SM is brought into the mix what this means is we can map a single group to multiple RP’s all with the same “virtual IP” we cannot achieve this without MSDP.



This command might save you from a whole world of trouble!

For example you’ve got a scheduled change coming up on your WAN router that’s a little risky, you might just cut yourself off from the router half way through the change…….. what do you do to mitigate this risk?

Well if you don’t have OOB (out-of-band) access to the router you would use the following command

#reload in 20

What this does is reload the router in 20 minutes reverting back to the last saved config. So if you’ve been cut off just wait the time you’ve specified and the router will reload with the old config.

To confirm how much time you have before a reload use the command

#show reload

Once you’ve completed your changes and they are successful just issue the command

#reload cancel

Also used to schedule a reload is the command

#reload at 09:45

This reloads your router and the time you specify but obviously relies your NTP settings to be correct so check this first.

Plan ahead!!