Dynamic GRE Tunnels Part 1

Hello to all of our followers,

Today’s post involves GRE Tunnels but this time  we will focus on the scenarios where we can run a dynamic GRE tunnel.

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

 

Scenario 1. All traffic going through the Hub

 

In this scenario we have 3 sites separated by a Service Provider, one of this sites (R1) is the Headquarters of our business and it will be running as a Hub.

All traffic from Spokes (R3-R4) will need to go through the Hub for security reasons.

Due to the fact we will be adding a lot of spokes in the future we want to avoid the creation of multiple GRE Tunnel interfaces and instead just use one Dynamic GRE tunnel Interface.

Here is how we get this working.

Note: Only the relevant information will be shown

R1 (Hub) Configuration:

interface Tunnel1

ip address 10.10.10.1 255.255.255.0

no ip redirects

ip nhrp map multicast dynamic

ip nhrp network-id 1

no ip split-horizon eigrp 100

tunnel source FastEthernet0/0

tunnel mode gre multipoint

This configuration in the tunnel interface will allow us to have more than one spoke registered to this specific tunnel interface (no additional IPv4 addresses will be waisted).

Let’s now talk about the commands inside the interface

The first thing you need to understand is that when we talk about the NBMA address we are talking about the tunnel source IP address on the tunnel interface of a router.

It’s important to recall that we need to enter the tunnel mode of GRE multipoint as the default it’s simple GRE (Point-To-Point)

The command ip nhrp map multicast dynamic  allow the router to send Broadcast or Multicast traffic to the NBMA address over the tunnel network.

You can also check there is no tunnel destination address, this happens because we will have multiple destinations that will register dynamically to it.

Before talking about the no ip split-horizon eigrp 100 we need to think about how the traffic will flow through this network.

Traffic from Spoke R3 LAN to Spoke R4 LAN or backwards needs to go through the Hub (as per the Scenario Requirements).

So let’s imagine a PC behind R3 LAN sends ICMP packets to a Server behind R4 LAN. That traffic will enter R1’s Multipoint GRE tunnel interface and do a U-Turn to go out the same Multipoint GRE Tunnel interface heading to R4’s Server.

There is a concept known as Split-Horizon that says that ” in order to prevent routing loops if I receive a network update on interface “X” that network update cannot go out the same interface”.

In this scenario we are going to hit this loop prevention engine so we need to make sure split-horizont is disabled on that interface for the EIGRP AS  we are running.

Here is R1’s EIGRP Config

router eigrp 100

network 10.0.0.0

network 192.168.10.0

no auto-summary

It’s time to move to the Spokes Config:

R3 (Spoke1) Config 

interface Tunnel1

ip address 10.10.10.3 255.255.255.0

ip nhrp map multicast 1.1.1.1

ip nhrp map 10.10.10.1 1.1.1.1

ip nhrp network-id 1

ip nhrp nhs 10.10.10.1

tunnel source FastEthernet0/0

tunnel destination 1.1.1.1

 Let’s try to decode this interface configuration:

We have the tunnel destination command as we know all traffic will flow through the hub.

We are mapping all multicast/broadcast traffic to the NBMA IP address in the hub router (ip nhrp map multicast 1.1.1.1)

We also map the Tunnel Interface IP address to the NBMA IP address in the hub router (ip nhrp map 10.10.10.1 1.1.1.1)

Finally we also set manually the next hop server IP to the Tunnel interface of the hub (ip nhrp nhs 10.10.10.1)

Note: Remember that the ip nhrp network-id it’s just an identifier.

The same config it’s gonna be used in R4’s except for the IP address in the tunnel interface.

R4 (Spoke2) Config

interface Tunnel1

ip address 10.10.10.4 255.255.255.0

ip nhrp map multicast 1.1.1.1

ip nhrp map 10.10.10.1 1.1.1.1

ip nhrp network-id 1

ip nhrp nhs 10.10.10.1

tunnel source FastEthernet0/0

tunnel destination 1.1.1.1

The Routing Protocol config it’s pretty simple on both sides, just advertise the Tunnel Interface subnet and the LAN subnet.

Verification Stage

Now that we have configured our lab it’s time to make sure everything works in our network.

Let’s go to our hub router and check the EIGRP Neighbor relationships, the routing table and the NHRP mappings.

R1#sh ip nhrp brief

   Target             Via            NBMA           Mode   Intfc   Claimed

10.10.10.3/32      10.10.10.3      1.1.1.5         dynamic  Tu1     <   >

10.10.10.4/32      10.10.10.4      1.1.1.9         dynamic  Tu1     <   >

R1#sh ip eigrp neighbor

IP-EIGRP neighbors for process 100

H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq

                                            (sec)         (ms)       Cnt Num

1   10.10.10.4              Tu1               14 00:43:14 1129  5000  0  14

0   10.10.10.3              Tu1               11 00:43:15   41  5000  0  12

IP-EIGRP neighbors for process 10

R1#sh ip route eigrp 100

D    192.168.30.0/24 [90/297372416] via 10.10.10.4, 00:43:27, Tunnel1

D    192.168.20.0/24 [90/297372416] via 10.10.10.3, 00:43:27, Tunnel1

Excellent! At the Hub level everything seems perfect so it’s time to test connectivity from Spoke 3 LAN to Spoke 4 LAN.

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 = 96/149/188 ms

AWESOME!!! Now let’s do the same but while we run a debug IP Packet Detail in the hub router! I mean the traffic it’s supposed to go through it so we should see it, right?

Well, let’s confirm it:

R1#debug ip packet detail 100

note: the IP access-list 100 makes reference to all ICMP traffic.

We run the same ping from R3 LAN to R4 LAN and we get the following output at R1

*Mar  1 01:13:11.835: IP: tableid=0, s=192.168.20.1 (Tunnel1), d=192.168.30.1 (Tunnel1), routed via FIB

*Mar  1 01:13:11.835: IP: s=192.168.20.1 (Tunnel1), d=192.168.30.1 (Tunnel1), g=10.10.10.4, len 100, forward

*Mar  1 01:13:11.839:     ICMP type=8, code=0

*Mar  1 01:13:11.935: IP: tableid=0, s=192.168.30.1 (Tunnel1), d=192.168.20.1 (Tunnel1), routed via FIB

*Mar  1 01:13:11.935: IP: s=192.168.30.1 (Tunnel1), d=192.168.20.1 (Tunnel1), g=10.10.10.3, len 100, forward

*Mar  1 01:13:11.939:     ICMP type=0, code=0

The ICMP Echo and Echo-Reply are flowing through the Hub’s Tunnel 1 interface.

Mystery solved and our customer scenario us up and running.

Stay tuned for our second part of Multipoint GRE Tunnels where we will talk about how to send traffic from Spoke 1 to Spoke 2 without going through the hub.

Regards,

Julio Carvajal

CCIE #42930, 2xCCNP, JNCIS-SEC