Using FHRP for GRE redundancy

Using the following topology:

In this lab I’m going to configure GRE tunnel between R5 to R1-R2 HSRP VIP for redundancy purposes, if R1, which is the active router, fails R2 will establish the tunnel with R5. 

Also I will use OSPF as a dynamic routing protocol between R1-R2-R5.

First let’s start with the FHRP configuration, here is the relevant configuration of R1:

interface FastEthernet0/0  ip address 10.1.123.2 255.255.255.0  duplex auto  speed auto ! interface FastEthernet0/1  ip address 10.1.124.1 255.255.255.0  standby version 2  standby 1 ip 10.1.124.254  standby 1 priority 150  standby 1 preempt  duplex auto  speed auto

And R2:

interface FastEthernet0/0  ip address 10.1.123.2 255.255.255.0  duplex auto  speed auto ! interface FastEthernet0/1  ip address 10.1.124.2 255.255.255.0  standby version 2  standby 1 ip 10.1.124.254  standby 1 priority 110  standby 1 preempt  duplex auto  speed auto

A GRE tunnel is configured between R1 and R2 to R5, here is R1 configuration:

interface Tunnel1  ip address 172.16.0.1 255.255.255.0  ip mtu 1476  ip ospf network point-to-multipoint  ip ospf dead-interval 6  ip ospf hello-interval 2  keepalive 2 4  tunnel source 10.1.124.254  tunnel destination 10.1.45.5  tunnel path-mtu-discovery

And R2:

interface Tunnel1  ip address 172.16.0.2 255.255.255.0  ip mtu 1476  ip ospf network point-to-multipoint  ip ospf dead-interval 6  ip ospf hello-interval 2  keepalive 2 4  tunnel source 10.1.124.254  tunnel destination 10.1.45.5  tunnel path-mtu-discovery

Note that both routers are using the HSRP VIP as tunnel source for the GRE tunnel.

R5 configuration:

interface Tunnel1  ip address 172.16.0.5 255.255.255.0  ip mtu 1476  ip ospf network point-to-multipoint  ip ospf dead-interval 6  ip ospf hello-interval 2  keepalive 2 4  tunnel source FastEthernet0/1  tunnel destination 10.1.124.254  tunnel path-mtu-discovery

Tunnel destination on R5 is pointing R1-R2 HSRP VIP.

Now few more notes regarding the tunnels configuration, first all tunnel interfaces are using 1476 bytes as the correct MTU value (1500-24 (GRE+IP)), then I have configured keepalive for tunnel failure detection, I also changed OSPF hello and dead-interval values for fast re-convergence.

Now let’s configure the routing protocol - OSPF is configured on the tunnel interfaces using point-to-multipoint network mode, R5 advertise network 192.168.51.0/24 while R3 advertise network 192.168.31.0/24, this is the OSPF configuration:

R1:

router ospf 1  router-id 1.1.1.1  network 10.1.123.1 0.0.0.0 area 0  network 172.16.0.1 0.0.0.0 area 0

R2:

router ospf 1  router-id 2.2.2.2  network 10.1.123.2 0.0.0.0 area 0  network 172.16.0.2 0.0.0.0 area 0

R3:

router ospf 1  router-id 3.3.3.3  network 10.1.123.3 0.0.0.0 area 0  network 192.168.31.1 0.0.0.0 area 0

R5:

router ospf 1  router-id 5.5.5.5  network 192.168.51.1 0.0.0.0 area 0  network 172.16.0.5 0.0.0.0 area 0

R5 establish OSPF adjacency with R1 but not with R2 due to tunnel keepalive which prevents R2 to respond to the keepalive hellos:

R5#show ip ospf neighbor Neighbor ID     Pri   State           Dead Time   Address         Interface 1.1.1.1           0   FULL/  -        00:00:04    172.16.0.1      Tunnel1

R1 establish adjacency with R5 through the tunnel interface and with R2 and R3 through the internal network:

R1#show ip ospf neighbor Neighbor ID     Pri   State           Dead Time   Address         Interface 5.5.5.5           0   FULL/  -        00:00:05    172.16.0.5      Tunnel1 2.2.2.2           1   FULL/DROTHER    00:00:39    10.1.123.2      FastEthernet0/0 192.168.31.1      1   FULL/DR         00:00:39    10.1.123.3      FastEthernet0/0

Now let’s start continues ping from R5 loopback 1 to R3 loopback 1 while disconnecting R1 Fa0/1 in the middle:

R5#ping 192.168.31.1 source lo1 repeat 1000 Type escape sequence to abort. Sending 1000, 100-byte ICMP Echos to 192.168.31.1, timeout is 2 seconds: Packet sent with a source address of 192.168.51.1 !!!!!!!!!!!!!!!!!!!!!!!!!!... *Dec  3 12:28:57.311: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.1 on Tunnel1 from FULL to DOWN, Neighbor Down: Dead timer expired.. *Dec  3 12:29:00.355: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to down... *Dec  3 12:29:06.371: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to up *Dec  3 12:29:07.143: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on Tunnel1 from LOADING to FULL, Loading Done........!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!. Success rate is 80 percent (68/85), round-trip min/avg/max = 88/200/368 ms

As we can see R5 has lost some packets but then re-establish OSPF adjacency with R2 and continue to ping R3 loopback 1. We can fine tune HSRP and OSPF timers to sub-second and to make the switchover much quicker.

EIGRP metric calculation direction

EIGRP metric formula:

Metric = 256 * ((10^7 / slowest-bandwidth) + cumulative-delay)

As we all know EIGRP calculate his metric based on least bandwidth and cumulative delay.

The least bandwidth is based on the interface with the lowest bandwidth value in Kbps units, the cumulative delay is the sum of all delay in the path in tens of microsecond units. Both parameters are calculated on a per-link basis.

Delay or bandwidth can be configured differently on both sides of the same link, so which value is chosen for the metric calculation?  How does the router calculate the cumulative delay? Which end bandwidth value counts?

In this post I will try to figure it out…

This is the topology I used for the following example:

I started with delay so I had to change the K values to count only delay when calculating the metric, on all routers:

Rx(config)#router eigrp 100 Rx(config-router)#metric weights 0 0 0 1 0 0

Show R2 loopback:

R2#show interfaces lo1 Loopback1 is up, line protocol is up   Hardware is Loopback   Internet address is 192.168.21.1/24   MTU 1514 bytes, BW 8000000 Kbit/sec, DLY 5000 usec,      reliability 255/255, txload 1/255, rxload 1/255   Encapsulation LOOPBACK, loopback not set   Keepalive set (10 sec)   Last input never, output never, output hang never   Last clearing of "show interface" counters never <OUTPUT_OMMITED>

The current delay is 5000 microseconds (usec), now let’s look on network 192.168.21.0/24 on R2 EIGRP topology table:

R2#sh ip eigrp topology 192.168.21.0/24 EIGRP-IPv4 Topology Entry for AS(100)/ID(2.2.2.2) for 192.168.21.0/24   State is Passive, Query origin flag is 1, 1 Successor(s), FD is 128000   Descriptor Blocks:   0.0.0.0 (Loopback1), from Connected, Send flag is 0x0       Composite metric is (128000/0), route is Internal       Vector metric:         Minimum bandwidth is 8000000 Kbit         Total delay is 5000 microseconds         Reliability is 255/255         Load is 1/255         Minimum MTU is 1514         Hop count is 0         Originating router is 2.2.2.2

Loopback 1 has delay of 5000usec which is 500 tens of microseconds (remember the delay value is calculated as tens of microseconds!) so the composite metric is 500*256 = 128000

Now the process starts as follow:

R2 sends update message to R4 advertising network 192.168.21.0/24 with delay 5000usec

R4 will add his link delay (toward this network – Fa0/1) to this update message and advertise it to R3 with 5100usec

R3 will add his link delay to this update message and advertise it to R1 with delay of 5200

R1 will add his link delay and install this network in his topology table with delay of 5300usec

R1#show ip eigrp topology 192.168.21.0 EIGRP-IPv4 Topology Entry for AS(100)/ID(1.1.1.1) for 192.168.21.0/24   State is Passive, Query origin flag is 1, 1 Successor(s), FD is 135680   Descriptor Blocks:   10.1.13.3 (FastEthernet0/1), from 10.1.13.3, Send flag is 0x0       Composite metric is (135680/133120), route is Internal       Vector metric:         Minimum bandwidth is 100000 Kbit         Total delay is 5300 microseconds         Reliability is 255/255         Load is 1/255         Minimum MTU is 1500         Hop count is 3         Originating router is 2.2.2.2

All routers will also runs DUAL on this update message and install this network in their EIGRP topology and routing tables.

 In the following process every router adds his link delay toward network 192.168.21.0/24, so if we would like to change the delay of the path, between R1 this network, we will have to change it on the downstream interfaces, hence on R1 Fa0/1, R3 Fa0/0, R4 Fa0/1 or R2 Loopback 1.

Changing the interface delay on the upstream interfaces (R3 Fa0/1, R4 Fa0/0 or R2 Fa0/1) won’t change nothing in the perspective of R1 to reach network 192.168.21.0/24.

Now let’s test this issue with bandwidth parameter, first change the K values for matching only bandwidth:

Rx(config)#router eigrp 100 Rx(config-router)#metric weights 0 1 0 0 0 0

And this is the current topology:

All FastEthernet has bandwidth of 100000 (Kbps) while loopback 1 on R2 has 8000000 (Kbps).

First let’s see R1 EIGRP topology table for network 192.168.21.0/24:

R1#sh ip eigrp topology 192.168.21.0/24 EIGRP-IPv4 Topology Entry for AS(100)/ID(1.1.1.1) for 192.168.21.0/24   State is Passive, Query origin flag is 1, 2 Successor(s), FD is 25600   Descriptor Blocks:   10.1.12.2 (FastEthernet0/0), from 10.1.12.2, Send flag is 0x0       Composite metric is (25600/256), route is Internal       Vector metric:         Minimum bandwidth is 100000 Kbit         Total delay is 5100 microseconds         Reliability is 255/255         Load is 1/255         Minimum MTU is 1500         Hop count is 1         Originating router is 2.2.2.2   10.1.13.3 (FastEthernet0/1), from 10.1.13.3, Send flag is 0x0       Composite metric is (25600/25600), route is Internal       Vector metric:         Minimum bandwidth is 100000 Kbit         Total delay is 5300 microseconds         Reliability is 255/255         Load is 1/255         Minimum MTU is 1500         Hop count is 3         Originating router is 2.2.2.2

As we can see R1 learns this network from both R2 and R3 with the same equal cost, although the path through R3 is much longer (R1->R3->R4).

Changing the interface bandwidth on R3 Fa0/1 (toward R1) won’t change nothing, R1 will still learns network 192.168.21.0/24 from both R3 and R2 in the same manner:

R1 EIGRP table:

R1#sh ip eigrp topology 192.168.21.0/24 EIGRP-IPv4 Topology Entry for AS(100)/ID(1.1.1.1) for 192.168.21.0/24   State is Passive, Query origin flag is 1, 2 Successor(s), FD is 25600   Descriptor Blocks:   10.1.12.2 (FastEthernet0/0), from 10.1.12.2, Send flag is 0x0       Composite metric is (25600/256), route is Internal       Vector metric:         Minimum bandwidth is 100000 Kbit         Total delay is 5100 microseconds         Reliability is 255/255         Load is 1/255         Minimum MTU is 1500         Hop count is 1         Originating router is 2.2.2.2   10.1.13.3 (FastEthernet0/1), from 10.1.13.3, Send flag is 0x0       Composite metric is (25600/25600), route is Internal       Vector metric:         Minimum bandwidth is 100000 Kbit         Total delay is 5300 microseconds         Reliability is 255/255         Load is 1/255         Minimum MTU is 1500         Hop count is 3         Originating router is 2.2.2.2

In order to change the way R1 learns this network, and to prefer the path through R2, we will have to change the upstream interfaces to influence the path, changing R3 Fa0/0 or R4 Fa0/1

 

Configure bandwidth 10000 on R4 Fa0/1, and look again at R1 EIGRP table:

R1#sh ip eigrp topology 192.168.21.0/24 EIGRP-IPv4 Topology Entry for AS(100)/ID(1.1.1.1) for 192.168.21.0/24   State is Passive, Query origin flag is 1, 2 Successor(s), FD is 25600   Descriptor Blocks:   10.1.12.2 (FastEthernet0/0), from 10.1.12.2, Send flag is 0x0       Composite metric is (25600/256), route is Internal       Vector metric:         Minimum bandwidth is 100000 Kbit         Total delay is 5100 microseconds         Reliability is 255/255         Load is 1/255         Minimum MTU is 1500         Hop count is 1         Originating router is 2.2.2.2

And now the path is changed to R2 only.

So to summarize this issue - metric calculation in EIGRP is always from the local router toward the destination.

The cumulative delay is counted on the upstream interfaces only while the least bandwidth is chosen based the least upstream interface, both from the local router to the destination.

Note that when dealing with tunnels and SVI’s (VLAN’s) the calculation is made by using the virtual interface (tunnel or SVI) parameters and not physical one.