This topic is to discuss the following lesson:
1 Like
Hi !
I am thinking to lab it up to try it to work. Anything that i should think of when a start with the nbma ? do you just have a switch between the interfaces ?
Hi Oskar,
I just used a switch to connect the routers to each other. It doesn’t matter much as long as they can reach each others NBMA addresses then you will be fine.
Rene
Hi !
I work out the lab and it work. Great lab, now i want to put on some ipsec . I will try this for my CCNP security…
Â
/Thanks Oskar
Hi,
If the tunnel interfaces are in same network why did you advertised again in EIGRP?
Thanks
Sims,
The network statement for the tunnel interface is telling EIGRP to use that interface to send and accept EIGRP packets. This is necessary in order to form EIGRP neighbor relationships between the hub and spokes.
Hi Rene,
First thanks a lot for all that great work you are doing :-).
I have a drama going on right now and I could not isolate the root cause of the problem.
Symptoms:
on my Hub the GRE Tunnel interface stat UP/Down - I am using cisco appliances running Version 12.2(8r).
Can you please help ?
-----
Router_1#show ip inter br
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 unassigned YES TFTP up down
Serial0/0 unassigned YES NVRAM administratively down down
FastEthernet0/1 192.168.123.1 YES manual up up
Serial0/1 unassigned YES NVRAM administratively down down
Loopback0 1.1.1.1 YES NVRAM up up
Tunnel0 172.16.123.1 YES manual up down
-
Router_1#show run inter tu0
Building configuration...
Current configuration : 223 bytes
!
interface Tunnel0
ip address 172.16.123.1 255.255.255.0
no ip redirects
ip nhrp authentication DMVPN
ip nhrp map multicast dynamic
ip nhrp network-id 1
tunnel source FastEthernet0/1
tunnel mode gre multipoint
end
-
Router_1#show run inter fa0/1
Building configuration...
Current configuration : 135 bytes
!
interface FastEthernet0/1
description Conection to ISP Switch
ip address 192.168.123.1 255.255.255.0
duplex auto
speed auto
end
-
Router_1#show inter tu0
Tunnel0 is up, line protocol is down
Hardware is Tunnel
Internet address is 172.16.123.1/24
MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation TUNNEL, loopback not set
Keepalive not set
Tunnel source 192.168.123.1 (FastEthernet0/1), destination UNKNOWN
Tunnel protocol/transport multi-GRE/IP, key disabled, sequencing disabled
Checksumming of packets disabled, fast tunneling enabled
Last input 00:55:03, output never, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/0 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
2 packets input, 210 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
0 packets output, 0 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 output buffer failures, 0 output buffers swapped out
Thank you in advance.
Hi Wandjlaye,
If you are using 12.2, I can highly recommend to try this on IOS 15.
12.2 is quite old and there have been quite some changes to DMVPN.
Rene
Hi Rene,
I am a bit confused with the packet flow, could you please explain the flow, if we ping from spoke 1 loopback address to spoke 2 loopback address, what will be the exact packet flow from the beginning.
Hi Mohammad,
With DMVPN phase 1, it is straight-forward. All traffic (including spoke-to-spoke traffic) always goes through the hub.
Rene
Hi Rene,
Could you please check the exact cause of this error. getting following error in spoke router.
*Dec 14 11:56:50.720: %DUAL-5-NBRCHANGE: EIGRP-IPv4 45678: Neighbor 123.20.1.25 (Tunnel0) is down: Peer Termination received
*Dec 14 11:56:54.320: %DUAL-5-NBRCHANGE: EIGRP-IPv4 45678: Neighbor 123.20.1.25 (Tunnel0) is up: new adjacency
*Dec 14 11:56:54.364: %ADJ-5-PARENT: Midchain parent maintenance for IP midchain out of Tunnel0, addr 123.20.1.25 - looped chain attempting to stack”
Topology:
Hub-----------------------ISP(AS20003)------------------------Spoke
Requirement is Spoke should use eigrp default route learned from hub not the ISP(BGP) default route. So i used distance for bgp default route. Actually bgp and eigrp configured first then tunnel configured. As soon as i configured the tunnel eigrp neig starts flapping and getting the error. The weird thing is if i delete the distance command from bgp configuration then eigrp neighborship gets stable and then if i put the distance command again it does not cause any issue even if i clear bgp and eigrp neighborship. I am using IOU. is it bug of IOU ?? Please advise.
HUB:
==================================================
interface Tunnel0
ip address 123.20.1.25 255.255.255.248
tunnel source Ethernet0/0
tunnel mode gre multipoint
ip nhrp map multicast dynamic
ip nhrp network-id 45678
ip nhrp redirect
bandwidth 1000
ip nhrp holdtime 300
ip nhrp authentication 45678key
ip mtu 1400
ip tcp adjust-mss 1380
delay 1000
no ip next-hop-self eigrp 45678
no ip split-horizon eigrp 45678
ip pim sparse-mode
access-list 1 permit 0.0.0.0
router bgp 45678
bgp router-id 123.17.17.17
bgp log-neighbor-changes
neighbor 203.3.17.1 remote-as 20003
!
address-family ipv4
neighbor 203.3.17.1 activate
distance 171 203.3.17.1 0.0.0.0 1
exit-address-family
router eigrp CCIE
!
address-family ipv4 unicast autonomous-system 45678
af-interface Tunnel0
authentication mode hmac-sha-256 cisco
authentication key-chain CCIE
exit-af-interface
network 123.17.17.17 0.0.0.0
network 123.20.1.10 0.0.0.0
network 123.20.1.18 0.0.0.0
network 123.20.1.25 0.0.0.0
exit-address-family
R17(config)#do sir
D*EX 0.0.0.0/0 [170/1075200] via 123.20.1.9, 01:51:22, Ethernet0/2
1.0.0.0/32 is subnetted, 1 subnets
B 1.2.3.4 [20/0] via 203.3.17.1, 01:50:56
R17(config)#do sh ip bg
r> 0.0.0.0 203.3.17.1 0 20003 30000 i
*> 1.2.3.4/32 203.3.17.1 0 20003 30000 i
Spoke:
===========================================
interface Tunnel0
bandwidth 1000
ip address 123.20.1.26 255.255.255.248
no ip redirects
ip mtu 1400
ip pim sparse-mode
ip nhrp authentication 45678key
ip nhrp map multicast 203.3.17.2
ip nhrp map 123.20.1.25 203.3.17.2
ip nhrp network-id 45678
ip nhrp holdtime 300
ip nhrp nhs 123.20.1.25
ip nhrp shortcut
ip tcp adjust-mss 1380
delay 1000
tunnel source Serial1/0
tunnel mode gre multipoint
end
router bgp 65222
bgp router-id 123.19.19.19
bgp log-neighbor-changes
neighbor 203.3.19.1 remote-as 20003
!
address-family ipv4
neighbor 203.3.19.1 activate
distance 171 203.3.19.1 0.0.0.0 1
exit-address-family
router eigrp CCIE
!
address-family ipv4 unicast autonomous-system 45678
!
af-interface Tunnel0
authentication mode hmac-sha-256 cisco
authentication key-chain CCIE
exit-af-interface
!
topology base
exit-af-topology
network 10.1.19.1 0.0.0.0
network 123.19.19.19 0.0.0.0
network 123.20.1.27 0.0.0.0
eigrp stub connected summary
exit-address-family
R19#sir
D*EX 0.0.0.0/0 [170/10803200] via 123.20.1.25, 00:33:42, Tunnel0
1.0.0.0/32 is subnetted, 1 subnets
B 1.2.3.4 [20/0] via 203.3.19.1, 00:33:50
R19#sh ip bg
Network Next Hop Metric LocPrf Weight Path
r> 0.0.0.0 203.3.19.1 0 20003 30000 iHi Abdus,
This message:
%ADJ-5-PARENT: Midchain parent maintenance for IP midchain out of Tunnel0
Is usually a recursive routing issue. Your router is probably learning the NBMA address through the tunnel interface, which is why it collapses.
i have a Quotation here why metric showing high .2.2.2 [90/27008000] via 172.16.123.2, 00:01:16, Tunnel0
Hello Mohammed
In this lab EIGRP is being used as the routing protocol. EIGRP uses a composite metric that is represented by a 32 bit number, which means the metric can range up to 2^32 which is somewhere beyond 4.2 billion. So a metric of 27008000 is not at all unusual.
To see a more comprehensive explanation of the EIGRP metric and how it is calculated, take a look at this lesson.
I hope this has been helpful!
Laz
1 Like
Thanks i got it, lagapides 
1 Like
Hi Rene
Thank you for your great work !
could you please explain this "*
One mental note to make is that EIGRP changes the next hop IP address, RIP doesn’t do this.
*"
Hello Hosam
When you configure EIGRP to function in DMVPN Phase 2, the neighbor relationships that are formed are between the Hub and Spoke1 and between the Hub and Spoke2. Spoke1 and Spoke2 will not become neighbors.
This means that routes advertised by Spoke1 to the Hub are then readvertised to Spoke2. But when that happens, the Hub replaces the next hop address of Spoke1 with its own. That’s what the “EIGRP changes the next hop IP address” means. This results in all traffic going through the Hub rather than directly from Spoke1 to Spoke2.
In order to avoid this, you have to configure IEGRP not to change the next hop IP address.
You can find out more detailed information of this operation, including examples, at the following lesson:
I hope this has been helpful!
Laz
Hi Laz,
Please clear me out, why are we using default summary on hub when everything was OK with eigrp even we are getting same output and same result then what is the need to do this?
Hello Pradyumna
In this example, whether you use the default route summary command on the hub or not will not make a difference, you are correct. However, imagine you have a topology with 50 spoke routers. On each spoke router you will have a routing table that will look something like this:
Spoke1#show ip route eigrp | include 3.3.3.3
D 3.3.3.3 [90/28288000] via 172.16.123.1, 00:00:27, Tunnel0
D 3.3.4.3 [90/28288000] via 172.16.123.1, 00:00:27, Tunnel0
D 3.3.5.3 [90/28288000] via 172.16.123.1, 00:00:27, Tunnel0
D 3.3.6.3 [90/28288000] via 172.16.123.1, 00:00:27, Tunnel0
D 3.3.7.3 [90/28288000] via 172.16.123.1, 00:00:27, Tunnel0
D 3.3.8.3 [90/28288000] via 172.16.123.1, 00:00:27, Tunnel0
D 3.3.9.3 [90/28288000] via 172.16.123.1, 00:00:27, Tunnel0
D 3.3.10.3 [90/28288000] via 172.16.123.1, 00:00:27, Tunnel0
D 3.3.11.3 [90/28288000] via 172.16.123.1, 00:00:27, Tunnel0
....
....
D 3.3.51.3 [90/28288000] via 172.16.123.1, 00:00:27, Tunnel0
D 3.3.52.3 [90/28288000] via 172.16.123.1, 00:00:27, Tunnel0
Each subnet behind each spoke would appear as a separate entry in the routing table. If you have multiple prefixes behind each spoke, those would appear as well! But see that all next-hop IP addresses are the same, specifically the HUB IP address.
Now this wastes memory, CPU speed, and bandwidth for the propagation of the routes between routers. By putting in the default route summary in the HUB, all of these routes are replaced with a single entry with the next-hop IP of the HUB, providing a much more efficient configuration.
I hope this has been helpful!
Laz
Hi Laz,
But Instead of advertising summary route in routing protocol, we can configure default route on each spoke in a topology where we have less spokes and routing protocol on hub.