dmvpn_2

This was a misleading Topology in the way that, this describes a Phase 1 DMVPN.

There are 3 phases of DMVPN, which are like different series, which has progressively gotten better over time and included more features. This is a list of the 3, and what features they included / lacked:

  • Phase 1 – Hub and Spoke Topology only as mGRE is only configured on Hub, Spokes use point-to-point configuration so no spoke-to-spoke communication, Hub can become bottleneck from CPU or Bandwidth utilization of handling all communication
  • Phase 2 – !!NO summarizaton allowed!!, Spoke-to-Spoke communications, No default route originate from Hub, mGRE configured on Spokes and Hub router
  • No idea, haven’t watched the hours of INE video yet, but it’s much more technical

Highlighted a few important parts in there, like I said the DMVPN INE section is 8-9 hours and I cannot derail from my warpath of Chris Bryants series right now, but I did want to touch a bit more on DMVPN.

Especially NHRP, cause I couldn’t find it in the INE or Chris Bryants CCNA or CCNP R/S courses and literally said out loud are you friggin kidding me? Apparently you are supposed to get your knowledge of it via DMVPN then kind of find your own resources, so wanted to have it’s own section here for just a moment.

NHRP and some details about it:

  • NHRP was really created to fill the gap of mapping tunnels to their physical or logical addresses used to build those tunnels
  • Upon configuring an NHC, when the router boots up it creates an “NHRP registration” that is sent to the NHS
  • The NHS puts it in what is called its “Binding table” or its “Database”

I thought I had more than that, but I guess that is it for now.

(Also, for the below config, I’d like to credit the Cisco web forum post https://supportforums.cisco.com/document/124431/dmvpn-configuration-example for their example configuration, cause I am totally stealing it for my rack and seeing if it works and turning off my brain for the night!)

Ok, onto configuration of a Phase 2 DMVPN:

I have no idea really where to start, you need to confirm connectivity between all spokes, which I confirmed by pinging from R2 – R1 – R3:

R2#ping 172.12.123.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.12.123.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 128/132/140 ms
R2#

So I am going to go for the gold and start configs on the Hub R1, and I will explain some of the values after the output:

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#int tu0
R1(config-if)#ip a
*Mar  1 17:39:30.031: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down
R1(config-if)#ip address 10.0.0.1 255.255.255.0
R1(config-if)#ip nhrp map multicast dynamic
R1(config-if)#ip nhrp network-id 1
R1(config-if)#tunnel source 172.12.123.1
R1(config-if)#tunnel mode gre multipoint
R1(config-if)#
*Mar  1 17:41:20.035: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up
R1(config-if)#ip mtu 1416
R1(config-if)#

Starting off with the pretty pink, you want to assign your tunnel interface the “Overlay” address of your tunnel end point, next I wanted to point out the network-id # is locally significant only but comes into play in DMVPN Phase 3 and can be used across multiple interfaces / tunnels on the same router (above my study pay grade), and to make it a point to point out the tunnel source will be the physical interface IP address that is orchestrating all this DMVPN madness, then finally the IP MTU being slightly lowered as the I believe it’s GRE that has a little extra baggage that adds to packet size so we need to adjust that payload size down a bit.

That was kind of fun, I should type in color more often.

Couple things to note was the tunnel went straight to a “Down” state upon configuring it unlike a loopback logical interface, however it came right back “Up” as soon as we issued a tunnel mode command (gre multipoint in this case).

So on R2:

R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#int tu0
R2(config-if)#ip add 10
*Mar  1 18:00:20.802: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down
R2(config-if)#ip add 10.0.0.2 255.255.255.0
R2(config-if)#ip nhrp map 10.0.0.1 172.12.123.1
R2(config-if)#ip nhrp map multicast 172.12.123.1
R2(config-if)#ip nhrp network-id 1
R2(config-if)#ip nhrp nhs 172.12.123.1
R2(config-if)#tunnel source 172.12.123.2
R2(config-if)#tunnel mode gre multipoint
R2(config-if)#
*Mar  1 18:03:10.808: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up
R2(config-if)#ip mtu 1416
R2(config-if)#

That seemed like a LOT of configuration for a spoke, I was beginning to think it was a Phase 1 example, however it does have the GRE Multipoint configured so I’ll go with it. The reason being it seems too hefty, it needs 3 references back to the Hub / NHS? What??

So I’ll play along and do it all over again on R3:

R3#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R3(config)#int tu0
R3(config-if)#
*Mar  2 03:21:45.649: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down
R3(config-if)#ip add 10.0.0.3 255.255.255.0
R3(config-if)#ip nhrp map 10.0.0.1 172.12.123.1
R3(config-if)#ip nhrp map multicast 172.12.123.1
R3(config-if)#ip nhrp network-id 1
R3(config-if)#ip nhrp nhs 10.0.0.1
R3(config-if)#tunnel source 172.12.123.3
R3(config-if)#tunnel mode gre multipoint
R3(config-if)#ip mt
*Mar  2 03:23:05.648: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up
R3(config-if)#ip mtu 1416
R3(config-if)#

Alrighty… Now what? Ahhh yes, this time we are adding the following IPSec crypto map policy to make sure our DMVPN traffic is secure, I will only post the configuration from R1 as it will be an exact copy on R2 and R3:

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#crypto isakmp policy 10
R1(config-isakmp)#hash md5
R1(config-isakmp)#encryption 3des
R1(config-isakmp)#authentication pre-share
R1(config-isakmp)#exit
R1(config)#crypto isakmp key cisco123 address 0.0.0.0 0.0.0.0
R1(config)#crypto ipsec transform TRANS esp-3des
R1(cfg-crypto-trans)#exit
R1(config)#crypto ipsec profile DMVPN
R1(ipsec-profile)#set transform-set TRANS
R1(ipsec-profile)#exit
R1(config)#int tu0
R1(config-if)#tunnel protection ipsec profile DMVPN
R1(config-if)#
*Mar  1 18:07:23.742: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ON
R1(config-if)#

So to begin the blue section is setting the crypto isakmp policy to be used, next comes us defining the PSK (Pre-Shared Key) for our tunnels with an address of 0.0.0.0 0.0.0.0 (anyone), then we define a transform set to be used and exit out of its configuration (not going to define tunnel / transport mode for this), then a crypto ipsec profile named DMVPN is created and defined in its own config to use the transform-set we defined, and finally in the pretty purple we apply it to our tunnel interface and get a message showing us ISAKMP is ON and ready to rock and roll.

I really didn’t take any LSD before posting this, I just found with all this configuration color coding it is going to make it a lot easy to read later. So now I apply it to the spokes quick, and we’ll see if those kick out any odd messages.

No new messages from them, all showed ISAKMP turning on, I love universal configs for my lab from time to time! So lets see whats going on with the Hub R1:

R1#sh ip nhrp
10.0.0.3/32 via 10.0.0.3, Tunnel0 created 00:20:01, expire 01:58:16
  Type: dynamic, Flags: unique nat registered
  NBMA address: 172.12.123.3
R1#sh dmvpn
Legend: Attrb –> S – Static, D – Dynamic, I – Incompletea
        N – NATed, L – Local, X – No Socket
        # Ent –> Number of NHRP entries with same NBMA peer

Tunnel0, Type:Hub, NHRP Peers:1,
 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
 —– ————— ————— —– ——– —–
     1    172.12.123.3        10.0.0.3    UP 00:20:24 D

R1#

I am for some reason missing R2, I reviewed the config and it is exactly the same as R3, so I am going to wr / reload all 3 routers to see if that makes any difference:

R1#sh ip nhrp
10.0.0.3/32 via 10.0.0.3, Tunnel0 created 00:00:07, expire 01:59:52
Type: dynamic, Flags: unique nat registered used
NBMA address: 172.12.123.3
R1#sh dmvpn
Legend: Attrb –> S – Static, D – Dynamic, I – Incompletea
N – NATed, L – Local, X – No Socket
# Ent –> Number of NHRP entries with same NBMA peer

Tunnel0, Type:Hub, NHRP Peers:1,
# Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
—– ————— ————— —– ——– —–
1    172.12.123.3        10.0.0.3    UP 00:01:17 D

R1#
ASR#2
[Resuming connection 2 to r2 … ]

R2#ping 172.12.123.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.12.123.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 128/132/140 ms
R2#

So it’s still the same in only seeing R3 for some reason, and I have no idea why. I wanted to see if I could hold out, but it is time to put a layer 3 dynamic routing protocol or some static routes around to see if that does anything. Some of the videos on INE eluded that EIGRP was the best protocol for DMVPN deployments, so I will give that a try:

R1(config)#router eigrp 100
R1(config-router)#no auto
R1(config-router)#network 172.12.123.0 0.0.0.255
R1(config-router)#network 10.0.0.0 0.0.0.255
R1(config-router)#network 1.1.1.1 0.0.0.0
R1(config-router)#exit
R1(config)#int tu0
R1(config-if)#no ip next-hop-self eigrp 100
R1(config-if)#no ip split eigrp 100
R1(config-if)#
ASR#2
[Resuming connection 2 to r2 … ]

R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#router eigrp 100
R2(config-router)#no auto
R2(config-router)#network 172.12.123.0 0.0.0.255
R2(config-router)#ne
*Mar  1 18:43:16.179: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 172.12.123.1 (Serial0/0) is up: new adjacency
R2(config-router)#network 10.0.0.0 0.0.0.255
R2(config-router)#network 2.2.2.2 0.0.0.0
R2(config-router)#int tu0
R2(config-if)#no ip next-hop-self eigrp 100
R2(config-if)#no ip split eigrp 100
R2(config-if)#
ASR#3
[Resuming connection 3 to r3 … ]

R3#
R3#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R3(config)#router eigrp 100
R3(config-router)#network 172.12.123.0 0.0.0.255
R3(config-router)#networ
*Mar  2 04:00:22.906: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 172.12.123.1 (Serial0/2) is up: new adjacency
R3(config-router)#network 10.0.0.0 0.0.0.255
*Mar  2 04:00:47.022: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.0.0.1 (Tunnel0) is up: new adjacency <- What??? ARGHH
R3(config-router)#network 3.3.3.3 0.0.0.0
R3(config-router)#no auto
R3(config-router)#
*Mar  2 04:01:01.073: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.0.0.1 (Tunnel0) is resync: summary configured
*Mar  2 04:01:01.073: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 172.12.123.1 (Serial0/2) is resync: summary configured
R3(config-router)#

What is R1’s problemo with R2’s Tunnel interface??? I hope to see it now despite not seeing that tunnel coming in the mf#R@*Eing output in router config:

R1#sh ip nhrp
10.0.0.2/32, Tunnel0 created 00:01:39, expire 00:01:25
  Type: incomplete, Flags: negative
  Cache hits: 7
10.0.0.3/32 via 10.0.0.3, Tunnel0 created 00:15:18, expire 01:44:41
  Type: dynamic, Flags: unique nat registered
  NBMA address: 172.12.123.3
R1#sh dmvpn
Legend: Attrb –> S – Static, D – Dynamic, I – Incompletea
        N – NATed, L – Local, X – No Socket
        # Ent –> Number of NHRP entries with same NBMA peer

Tunnel0, Type:Hub, NHRP Peers:2,
 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
 —– ————— ————— —– ——– —–
     1         0.0.0.0        10.0.0.2  NHRP    never IX
     1    172.12.123.3        10.0.0.3    UP 00:15:25 D

R1#
*Mar  1 18:40:44.615: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.0.0.2 (Tunnel0) is down: retry limit exceeded
R1#
*Mar  1 18:40:48.826: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.0.0.2 (Tunnel0) is up: new adjacency
R1#

Success!! And then…. flapping. Well at least we know a dynamic protocol got it working again. Now I believe the output seen has something to do with EIGRP giving itself a next hop of 0.0.0.0 0.0.0.0 (itself) so I will investigate whats up on R2 but first I want to reserve this timing on the drops for later review when I’m all smarter at this:

R1#
*Mar  1 18:40:44.615: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.0.0.2 (Tunnel0) is down: retry limit exceeded
R1#
*Mar  1 18:40:48.826: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.0.0.2 (Tunnel0) is up: new adjacency
R1#
*Mar  1 18:42:08.349: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.0.0.2 (Tunnel0) is down: retry limit exceeded
R1#
*Mar  1 18:42:12.503: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.0.0.2 (Tunnel0) is up: new adjacency
R1#
*Mar  1 18:43:32.030: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.0.0.2 (Tunnel0) is down: retry limit exceeded
R1#
*Mar  1 18:43:33.296: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.0.0.2 (Tunnel0) is up: new adjacency
R1#

It goes down for about 4 seconds, then remains up for about 20 seconds, which is really goofy in terms of an EIGRP timer over a Serial link.

So the really odd thing doing a stare and compare of R2 to R3’s show run, I found that on R3, I did not put in any of tunnel interface “no eigrp …” commands because it came up right away, so I’m going to remove them from R2 to see what happens first:

R2(config)#no int tu0
R2(config)#
*Mar  1 19:01:13.846: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is OFF
R2(config)#interface Tunnel0
R2(config-if)# ip address 10.0.0.2 255.255.255.0
R2(config-if)# no ip redirects
R2(config-if)# ip mtu 1416
R2(config-if)# ip nhrp map 10.0.0.1 172.12.123.1
R2(config-if)# ip nhrp map multicast 172.12.123.1
R2(config-if)# ip nhrp network-id 1
R2(config-if)# ip nhrp nhs 172.12.123.1
R2(config-if)# tunnel source 172.12.123.2
R2(config-if)# tunnel mode gre multipoint
R2(config-if)# tunnel protection ipsec profile DMVPN
R2(config-if)#
*Mar  1 19:01:47.276: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ON
R2(config-if)#
ASR#1
[Resuming connection 1 to r1 … ]

R1#
R1#sh ip nhrp
10.0.0.2/32, Tunnel0 created 00:03:03, expire 00:00:01
  Type: incomplete, Flags: negative
  Cache hits: 7
10.0.0.3/32 via 10.0.0.3, Tunnel0 created 00:29:14, expire 01:30:45
  Type: dynamic, Flags: unique nat registered
  NBMA address: 172.12.123.3
R1#sh dmvpn
Legend: Attrb –> S – Static, D – Dynamic, I – Incompletea
        N – NATed, L – Local, X – No Socket
        # Ent –> Number of NHRP entries with same NBMA peer

Tunnel0, Type:Hub, NHRP Peers:2,
 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
 —– ————— ————— —– ——– —–
     1         0.0.0.0        10.0.0.2  NHRP    never IX
     1    172.12.123.3        10.0.0.3    UP 00:29:22 D

R1#

Didn’t make a bit of difference, this is a bit baffling to me, so I am going to apply it to both tunnel interfaces and see what happens:
R2(config)#int tu0
R2(config-if)#ip hold-time eigrp 100 35
R2(config-if)#no ip next-hop-self eigrp 100
R2(config-if)#no ip split eigrp 100
R2(config-if)#
ASR#3
[Resuming connection 3 to r3 … ]

R3#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R3(config)#int tu0
R3(config-if)#ip hold-time eigrp 100 34
R3(config-if)#no ip hold-time eigrp 100 34
R3(config-if)#ip hold-time eigrp 100 35
R3(config-if)#no ip next-hop-self eigrp 100
*Mar  2 04:21:43.750: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.0.0.1 (Tunnel0) is down: next_hop_self value changed
*Mar  2 04:21:44.687: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.0.0.1 (Tunnel0) is down: Interface Goodbye received
R3(config-if)#no ip
*Mar  2 04:21:48.061: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.0.0.1 (Tunnel0) is up: new adjacency
R3(config-if)#no ip split eigrp 100
R3(config-if)#
*Mar  2 04:21:57.176: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.0.0.1 (Tunnel0) is resync: split horizon changed
R3(config-if)#

So from looking at the output, of course I run into another bug:

R2(config)#no crypto isakmp key cisco123 address 0.0.0.0 0.0.0.0
R2(config)#crypto isakmp key cisco123
% Incomplete command.

R2(config)#crypto isakmp key cisco123 ?
% Unrecognized command
R2(config)#crypto isakmp key cisco123

So here is a dump of R1’s “debug ip pack” for later dissection, I will be doing a “wr er” on these routers and try not to let this weird behavior drive me nuts 🙂 And on the next lab, we shall have a BRAND NEW TOPOLOGY (I know, I’m excited too) that looks like it would be a ROAS (Router On A Stick) setup which it very well could be, but we will be configuring VRF!

(I will circle back around to DMVPN when I can dedicate more time to studying the materials for it, but this will be the end of DMVPN for now).

See you on the next one, and this debug dump is for my future inspection, so feel free not to look at unless you are curious:

R1#debug ip pack
IP packet debugging is on
R1#
*Mar  1 19:00:25.227: IP: s=10.0.0.1 (local), d=224.0.0.10 (Tunnel0), len 60, sending broad/multicast
*Mar  1 19:00:25.227: IP: tableid=0, s=172.12.123.1 (local), d=172.12.123.3 (Serial0/0), routed via FIB
*Mar  1 19:00:25.227: IP: s=172.12.123.1 (local), d=172.12.123.3 (Serial0/0), len 84, sending
*Mar  1 19:00:25.423: IP: tableid=0, s=172.12.123.3 (Serial0/0), d=172.12.123.1 (Serial0/0), routed via RIB
*Mar  1 19:00:25.423: IP: s=172.12.123.3 (Serial0/0), d=172.12.123.1 (Serial0/0), len 84, rcvd 3
*Mar  1 19:00:25.423: IP: s=10.0.0.3 (Tunnel0), d=224.0.0.10, len 60, rcvd 0
*Mar  1 19:00:26.332: IP: s=10.0.0.1 (local), d=224.0.0.10 (Tunnel0), len 69, sending broad/multicast
*Mar  1 19:00:26.332: IP: tableid=0, s=172.12.123.1 (local), d=172.12.123.3 (Serial0/0), routed via FIB
*Mar  1 19:00:26.332: IP: s=172.12.123.1 (local), d=172.12.123.3 (Serial0/0), len 93, sending
*Mar  1 19:00:26.336: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.0.0.2 (Tunnel0) is down: retry limit
R1# exceeded
*Mar  1 19:00:26.461: IP: tableid=0, s=172.12.123.2 (Serial0/0), d=172.12.123.1 (Serial0/0), routed via RIB
*Mar  1 19:00:26.461: IP: s=172.12.123.2 (Serial0/0), d=172.12.123.1 (Serial0/0), len 84, rcvd 3
*Mar  1 19:00:26.461: IP: s=10.0.0.2 (Tunnel0), d=224.0.0.10, len 60, rcvd 0
*Mar  1 19:00:26.465: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.0.0.2 (Tunnel0) is up: new adjacency
*Mar  1 19:00:26.469: IP: s=10.0.0.1 (local), d=224.0.0.10 (Tunnel0), len 60, sending broad/multicast
*Mar  1 19:00:26.469: IP: tableid=0, s=172.12.123.1 (local), d=172.12.123.3 (Serial0/0), routed via FIB
*Mar  1 19:00:26.469: IP: s=172.12.123.1 (local), d=172.12.123.3 (Serial0/0), len 84, sending
*Mar  1 19:00:26.477: IP: s=10.0.0.1 (local), d=10.0.0.2 (Tunnel0), len 40, sending
*Mar  1 19:00:26.477: IP: s=10.0.0.1 (local), d=10.0.0.2 (Tunnel0), len 40, encapsulation failed
*Mar  1 19:00:27.374: IP: s=1.1.1.1 (local), d=224.0.0.10 (Loopback1), len 60, sending broad/multicast
*Mar  1 19:00:27.374: IP: s=1.1.1.1 (Loopback1), d=224.0.0.10, len 60, rcvd 2
R1#
R1#
*Mar  1 19:00:28.476: IP: s=10.0.0.1 (local), d=10.0.0.2 (Tunnel0), len 40, sending
*Mar  1 19:00:28.476: IP: s=10.0.0.1 (local), d=10.0.0.2 (Tunnel0), len 40, encapsulation failed
R1#
*Mar  1 19:00:29.986: IP: tableid=0, s=172.12.123.3 (Serial0/0), d=172.12.123.1 (Serial0/0), routed via RIB
*Mar  1 19:00:29.986: IP: s=172.12.123.3 (Serial0/0), d=172.12.123.1 (Serial0/0), len 84, rcvd 3
*Mar  1 19:00:29.986: IP: s=10.0.0.3 (Tunnel0), d=224.0.0.10, len 60, rcvd 0
R1#
*Mar  1 19:00:31.040: IP: s=10.0.0.1 (local), d=224.0.0.10 (Tunnel0), len 60, sending broad/multicast
*Mar  1 19:00:31.040: IP: tableid=0, s=172.12.123.1 (local), d=172.12.123.3 (Serial0/0), routed via FIB
*Mar  1 19:00:31.040: IP: s=172.12.123.1 (local), d=172.12.123.3 (Serial0/0), len 84, sending
*Mar  1 19:00:31.112: IP: tableid=0, s=172.12.123.2 (Serial0/0), d=172.12.123.1 (Serial0/0), routed via RIB
*Mar  1 19:00:31.112: IP: s=172.12.123.2 (Serial0/0), d=172.12.123.1 (Serial0/0), len 84, rcvd 3
*Mar  1 19:00:31.112: IP: s=10.0.0.2 (Tunnel0), d=224.0.0.10, len 60, rcvd 0
*Mar  1 19:00:31.477: IP: s=10.0.0.1 (local), d=10.0.0.2 (Tunnel0), len 40, sending
R1#
*Mar  1 19:00:31.477: IP: s=10.0.0.1 (local), d=10.0.0.2 (Tunnel0), len 40, encapsulation failed
*Mar  1 19:00:31.781: IP: s=1.1.1.1 (local), d=224.0.0.10 (Loopback1), len 60, sending broad/multicast
*Mar  1 19:00:31.781: IP: s=1.1.1.1 (Loopback1), d=224.0.0.10, len 60, rcvd 2
*Mar  1 19:00:32.082: IP: s=0.0.0.0 (FastEthernet0/1), d=255.255.255.255, len 339, rcvd 2
*Mar  1 19:00:32.362: IP: s=172.12.123.1 (local), d=224.0.0.10 (Serial0/0), len 60, sending broad/multicast
R1#
*Mar  1 19:00:34.943: IP: tableid=0, s=172.12.123.3 (Serial0/0), d=172.12.123.1 (Serial0/0), routed via RIB
*Mar  1 19:00:34.943: IP: s=172.12.123.3 (Serial0/0), d=172.12.123.1 (Serial0/0), len 84, rcvd 3
*Mar  1 19:00:34.943: IP: s=10.0.0.3 (Tunnel0), d=224.0.0.10, len 60, rcvd 0
*Mar  1 19:00:35.507: IP: tableid=0, s=172.12.123.2 (Serial0/0), d=172.12.123.1 (Serial0/0), routed via RIB
*Mar  1 19:00:35.507: IP: s=172.12.123.2 (Serial0/0), d=172.12.123.1 (Serial0/0), len 84, rcvd 3
*Mar  1 19:00:35.507: IP: s=10.0.0.2 (Tunnel0), d=224.0.0.10, len 60, rcvd 0
R1#
*Mar  1 19:00:35.956: IP: s=10.0.0.1 (local), d=224.0.0.10 (Tunnel0), len 60, sending broad/multicast
*Mar  1 19:00:35.956: IP: tableid=0, s=172.12.123.1 (local), d=172.12.123.3 (Serial0/0), routed via FIB
*Mar  1 19:00:35.956: IP: s=172.12.123.1 (local), d=172.12.123.3 (Serial0/0), len 84, sending
*Mar  1 19:00:35.976: IP: s=10.0.0.1 (local), d=10.0.0.2 (Tunnel0), len 40, sending
*Mar  1 19:00:35.976: IP: s=10.0.0.1 (local), d=10.0.0.2 (Tunnel0), len 40, encapsulation failed
*Mar  1 19:00:36.080: IP: s=0.0.0.0 (FastEthernet0/1), d=255.255.255.255, len 339, rcvd 2
*Mar  1 19:00:36.685: IP: s=1.1.1.1 (local), d=224.0.0.10 (Loopback1), len 60, sending broad/multicast
R1#
*Mar  1 19:00:36.685: IP: s=1.1.1.1 (Loopback1), d=224.0.0.10, len 60, rcvd 2
R1#
*Mar  1 19:00:39.666: IP: tableid=0, s=172.12.123.3 (Serial0/0), d=172.12.123.1 (Serial0/0), routed via RIB
*Mar  1 19:00:39.666: IP: s=172.12.123.3 (Serial0/0), d=172.12.123.1 (Serial0/0), len 84, rcvd 3
*Mar  1 19:00:39.666: IP: s=10.0.0.3 (Tunnel0), d=224.0.0.10, len 60, rcvd 0
*Mar  1 19:00:39.939: IP: tableid=0, s=172.12.123.2 (Serial0/0), d=172.12.123.1 (Serial0/0), routed via RIB
*Mar  1 19:00:39.939: IP: s=172.12.123.2 (Serial0/0), d=172.12.123.1 (Serial0/0), len 84, rcvd 3
*Mar  1 19:00:39.939: IP: s=10.0.0.2 (Tunnel0), d=224.0.0.10, len 60, rcvd 0
*Mar  1 19:00:40.079: IP: s=0.0.0.0 (FastEthernet0/1), d=255.255.255.255, len 339, rcvd 2
R1#
*Mar  1 19:00:40.660: IP: s=10.0.0.1 (local), d=224.0.0.10 (Tunnel0), len 60, sending broad/multicast
*Mar  1 19:00:40.660: IP: tableid=0, s=172.12.123.1 (local), d=172.12.123.3 (Serial0/0), routed via FIB
*Mar  1 19:00:40.660: IP: s=172.12.123.1 (local), d=172.12.123.3 (Serial0/0), len 84, sending
*Mar  1 19:00:40.976: IP: s=10.0.0.1 (local), d=10.0.0.2 (Tunnel0), len 40, sending
*Mar  1 19:00:40.976: IP: s=10.0.0.1 (local), d=10.0.0.2 (Tunnel0), len 40, encapsulation failed
*Mar  1 19:00:41.361: IP: s=1.1.1.1 (local), d=224.0.0.10 (Loopback1), len 60, sending broad/multicast
*Mar  1 19:00:41.361: IP: s=1.1.1.1 (Loopback1), d=224.0.0.10, len 60, rcvd 2
R1#
*Mar  1 19:00:44.214: IP: tableid=0, s=172.12.123.2 (Serial0/0), d=172.12.123.1 (Serial0/0), routed via RIB
*Mar  1 19:00:44.214: IP: s=172.12.123.2 (Serial0/0), d=172.12.123.1 (Serial0/0), len 84, rcvd 3
*Mar  1 19:00:44.214: IP: s=10.0.0.2 (Tunnel0), d=224.0.0.10, len 60, rcvd 0
*Mar  1 19:00:44.498: IP: tableid=0, s=172.12.123.3 (Serial0/0), d=172.12.123.1 (Serial0/0), routed via RIB
*Mar  1 19:00:44.498: IP: s=172.12.123.3 (Serial0/0), d=172.12.123.1 (Serial0/0), len 84, rcvd 3
*Mar  1 19:00:44.498: IP: s=10.0.0.3 (Tunnel0), d=224.0.0.10, len 60, rcvd 0
*Mar  1 19:00:45.123: IP: s=10.0.0.1 (local), d=224.0.0.10 (Tunnel0), len 60, sending broad/multicast
R1#
*Mar  1 19:00:45.123: IP: tableid=0, s=172.12.123.1 (local), d=172.12.123.3 (Serial0/0), routed via FIB
*Mar  1 19:00:45.123: IP: s=172.12.123.1 (local), d=172.12.123.3 (Serial0/0), len 84, sending
*Mar  1 19:00:45.780: IP: s=1.1.1.1 (local), d=224.0.0.10 (Loopback1), len 60, sending broad/multicast
*Mar  1 19:00:45.780: IP: s=1.1.1.1 (Loopback1), d=224.0.0.10, len 60, rcvd 2
*Mar  1 19:00:45.977: IP: s=10.0.0.1 (local), d=10.0.0.2 (Tunnel0), len 40, sending
*Mar  1 19:00:45.977: IP: s=10.0.0.1 (local), d=10.0.0.2 (Tunnel0), len 40, encapsulation failed
R1#
*Mar  1 19:00:48.725: IP: tableid=0, s=172.12.123.2 (Serial0/0), d=172.12.123.1 (Serial0/0), routed via RIB
*Mar  1 19:00:48.725: IP: s=172.12.123.2 (Serial0/0), d=172.12.123.1 (Serial0/0), len 84, rcvd 3
*Mar  1 19:00:48.725: IP: s=10.0.0.2 (Tunnel0), d=224.0.0.10, len 60, rcvd 0
*Mar  1 19:00:49.154: IP: tableid=0, s=172.12.123.3 (Serial0/0), d=172.12.123.1 (Serial0/0), routed via RIB
*Mar  1 19:00:49.154: IP: s=172.12.123.3 (Serial0/0), d=172.12.123.1 (Serial0/0), len 84, rcvd 3
*Mar  1 19:00:49.154: IP: s=10.0.0.3 (Tunnel0), d=224.0.0.10, len 60, rcvd 0
R1#
*Mar  1 19:00:49.731: IP: s=10.0.0.1 (local), d=224.0.0.10 (Tunnel0), len 60, sending broad/multicast
*Mar  1 19:00:49.731: IP: tableid=0, s=172.12.123.1 (local), d=172.12.123.3 (Serial0/0), routed via FIB
*Mar  1 19:00:49.731: IP: s=172.12.123.1 (local), d=172.12.123.3 (Serial0/0), len 84, sending
*Mar  1 19:00:50.079: IP: s=0.0.0.0 (FastEthernet0/1), d=255.255.255.255, len 339, rcvd 2
R1#
*Mar  1 19:00:50.756: IP: s=1.1.1.1 (local), d=224.0.0.10 (Loopback1), len 60, sending broad/multicast
*Mar  1 19:00:50.756: IP: s=1.1.1.1 (Loopback1), d=224.0.0.10, len 60, rcvd 2
*Mar  1 19:00:50.977: IP: s=10.0.0.1 (local), d=10.0.0.2 (Tunnel0), len 40, sending
*Mar  1 19:00:50.977: IP: s=10.0.0.1 (local), d=10.0.0.2 (Tunnel0), len 40, encapsulation failed