Dynamic GRE Tunnels Part 2

Hello to all of our followers,

It’s time to continue with the mGRE topic.

The last time we saw how the spokes were able to send traffic dynamically from spoke to spoke through the hub but now we will see how to make the Spokes talk to each other without having to go through the hub.

Here is the link to the previous post:

http://i-networks.us/dynamic-gre-tunnels-part-1

Let’s get started by sharing the topology we will be using today in our lab:

Screen Shot 2015-07-24 at 2.27.07 PM

 

It’s the same topology we use last time, the hub configuration it’s almost the same with only one change in mind.

I will share the config of the Hub first:

Hub (R1) Config

interface Tunnel1

ip address 10.10.10.1 255.255.255.0

no ip redirects

no ip next-hop-self eigrp 100

ip nhrp map multicast dynamic

ip nhrp network-id 1

no ip split-horizon eigrp 100

tunnel source FastEthernet0/0

tunnel mode gre multipoint

The only thing that should be new to you here is the no ip-next-hop-self command!

Remember that the whole purpose of this lab is to make the spokes to be able to talk to each other without going through the hub.

With EIGRP we have a problem for this scenarios as when you send an update outside one of your interfaces, that update will have the IP address on your interfaces as the NEXT-HOP IP and that would force the packets to be send trough you! We do not want that in our LAB so we need to add that command. We want the Spokes to learn the Updated from the other Spokes by having their own IP’s.

Let’s now move to the Spoke’s config:

R3 Config:

interface Tunnel1

ip address 10.10.10.3 255.255.255.0

no ip redirects

ip nhrp map 10.10.10.1 1.1.1.1

ip nhrp map multicast 1.1.1.1

ip nhrp network-id 1

ip nhrp nhs 10.10.10.1

tunnel source FastEthernet0/0

tunnel mode gre multipoint

R4 Config:

interface Tunnel1

ip address 10.10.10.4 255.255.255.0

no ip redirects

ip nhrp map 10.10.10.1 1.1.1.1

ip nhrp map multicast 1.1.1.1

ip nhrp network-id 1

ip nhrp nhs 10.10.10.1

tunnel source FastEthernet0/0

tunnel mode gre multipoint

Do you see the differences here?

Pretty simple, we just change the tunnel mode from a regular GRE mode to a mGRE and we removed the tunnel destination as we don’t need it to be statically defined as the hub anymore.

Now I will show the Routing Protocol Config on each router and then you will see how each Spoke learns the IP Networks

R1 (Hub)

router eigrp 100

network 10.0.0.0

network 192.168.10.0

no auto-summary

R3 (Spoke1)

router eigrp 100

network 10.0.0.0

network 192.168.20.0

no auto-summary

R4(Spoke2)

router eigrp 100

network 10.0.0.0

network 192.168.30.0

no auto-summary

Verfication Stage

Let’s go directly to the Spoke Routers and check the routing table

R3#sh ip route eigrp 100

D    192.168.30.0/24 [90/310172416] via 10.10.10.4, 00:07:22, Tunnel1

D    192.168.10.0/24 [90/297372416] via 10.10.10.1, 00:07:22, Tunnel1

R4#sh ip route eigrp 100

D    192.168.10.0/24 [90/297372416] via 10.10.10.1, 00:10:13, Tunnel1

D    192.168.20.0/24 [90/310172416] via 10.10.10.3, 00:07:28, Tunnel1

Awesome!! As you can see they can see each other routes with their own IP address.

Let’s send a ping packet and see the result

R3#ping 192.168.30.1 source 192.168.20.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.30.1, timeout is 2 seconds:

Packet sent with a source address of 192.168.20.1

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 72/93/120 ms

If we go further on this lab we can check the NHRP Mapping Cache on each router:

R3#sh ip nhrp tunnel 1 brief            

   Target                     Via                   NBMA           Mode   Intfc   Claimed

10.10.10.1/32      10.10.10.1      1.1.1.1         static   Tu1     <   >

10.10.10.4/32      10.10.10.4      1.1.1.9         dynamic  Tu1     <   >

I bet you are asking how did R3 and R4 learn each other NBMA IP. In order to show you that I ran a debug NHRP cache in the Hub Router to obtain the NHRP Resolution request and Reply when R3 first tried to ping R4. All of this cause at the beginning R3 only knew the tunnel destination IP was 10.10.10.4 but who owns that tunnel IP?????

Here is the debug output:

R1#

“Here R3 send the ping and it’s trying to learn the NBMA IP address of 10.10.10.4″

*Mar  1 00:18:10.039: NHRP: Receive Resolution Request via Tunnel1 vrf 0, packet size: 68

*Mar  1 00:18:10.039:  (F) afn: IPv4(1), type: IP(800), hop: 255, ver: 1

*Mar  1 00:18:10.043:      shtl: 4(NSAP), sstl: 0(NSAP)

*Mar  1 00:18:10.043:  (M) flags: “router auth src-stable”, reqid: 7

*Mar  1 00:18:10.043:      src NBMA: 1.1.1.5

*Mar  1 00:18:10.043:      src protocol: 10.10.10.3, dst protocol: 10.10.10.4

*Mar  1 00:18:10.043:  (C-1) code: no error(0)

*Mar  1 00:18:10.047:        prefix: 0, mtu: 1514, hd_time: 7200

*Mar  1 00:18:10.047:        addr_len: 0(NSAP), subaddr_len: 0(NSAP), proto_len: 0, pref: 0

*Mar  1 00:18:10.047: NHRP: Send Resolution Reply via Tunnel1 vrf 0, packet size: 96

*Mar  1 00:18:10.051:  src: 10.10.10.1, dst: 10.10.10.3

*Mar  1 00:18:10.051:  (F) afn: IPv4(1), type: IP(800), hop: 255, ver: 1

*Mar  1 00:18:10.051:      shtl: 4(NSAP), sstl: 0(NSAP)

*Mar  1 00:18:10.051:  (M) flags: “router auth dst-stable unique src-stable”, reqid: 7

*Mar  1 00:18:10.051:      src NBMA: 1.1.1.5

*Mar  1 00:18:10.055:      src protocol: 10.10.10.3, dst protocol: 10.10.10.4

*Mar  1 00:18:10.055:  (C-1) code: no error(0)

*Mar  1 00:18:10.055:        prefix: 32, mtu: 1514, hd_time: 6981

*Mar  1 00:18:10.055:        addr_len: 4(NSAP), subaddr_len: 0(NSAP), proto_len: 4, pref: 0

*Mar  1 00:18:10.055:        client NBMA: 1.1.1.9

*Mar  1 00:18:10.059:        client protocol: 10.10.10.4

“Here we can see R4 doing the same thing but for R3s NBMA IP”

*Mar  1 00:18:10.175: NHRP: Receive Resolution Request via Tunnel1 vrf 0, packet size: 68

*Mar  1 00:18:10.175:  (F) afn: IPv4(1), type: IP(800), hop: 255, ver: 1

*Mar  1 00:18:10.175:      shtl: 4(NSAP), sstl: 0(NSAP)

*Mar  1 00:18:10.175:  (M) flags: “router auth src-stable”, reqid: 5

*Mar  1 00:18:10.175:      src NBMA: 1.1.1.9

*Mar  1 00:18:10.179:      src protocol: 10.10.10.4, dst protocol: 10.10.10.3

*Mar  1 00:18:10.179:  (C-1) code: no error(0)

*Mar  1 00:18:10.179:        prefix: 0, mtu: 1514, hd_time: 7200

*Mar  1 00:18:10.179:        addr_len: 0(NSAP), subaddr_len: 0(NSAP), proto_len: 0, pref: 0

*Mar  1 00:18:10.183: NHRP: Send Resolution Reply via Tunnel1 vrf 0, packet size: 96

*Mar  1 00:18:10.183:  src: 10.10.10.1, dst: 10.10.10.4

*Mar  1 00:18:10.183:  (F) afn: IPv4(1), type: IP(800), hop: 255, ver: 1

*Mar  1 00:18:10.187:      shtl: 4(NSAP), sstl: 0(NSAP)

*Mar  1 00:18:10.187:  (M) flags: “router auth dst-stable unique src-stable”, reqid: 5

*Mar  1 00:18:10.187:      src NBMA: 1.1.1.9

*Mar  1 00:18:10.187:      src protocol: 10.10.10.4, dst protocol: 10.10.10.3

*Mar  1 00:18:10.187:  (C-1) code: no error(0)

*Mar  1 00:18:10.191:        prefix: 32, mtu: 1514, hd_time: 7147

*Mar  1 00:18:10.191:        addr_len: 4(NSAP), subaddr_len: 0(NSAP), proto_len: 4, pref: 0

*Mar  1 00:18:10.191:        client NBMA: 1.1.1.5

*Mar  1 00:18:10.191:        client protocol: 10.10.10.3

And that’s how mGRE Tunnels work! I hope you enjoyed this post.

Regards,

Jcarvaja