EIGRP Bandwidth Configuration

aravind r v · ‎08-24-2015

Dear Team,

We are trying to establish two DMVPN tunnel to one Hub router. We need to publish same subnet from both routers and we need to achieve redundancy with that. We are using EIGRP as routing protocol between the tunnel.

I believe we can achieve EIGRP routing redundancy with changing bandwidth and delay values in one tunnel interface. We tried to do that but in Hub side Router still both router Bandwidth/Delay didn't changed.

please find the attached EIGRP config in both spoke routers.

===================
PRIMARY ROUTER
===================
interface Tunnel1
description ++++ Primary DMVPN Cloud 1 ++++
bandwidth 10000
ip address 192.168.250.16 255.255.255.0
no ip redirects
no ip unreachables
no ip proxy-arp
ip mtu 1400
no ip next-hop-self eigrp 100
no ip split-horizon eigrp 100
ip nhrp authentication mykey
ip nhrp map multicast 1.1.1.1
ip nhrp map 192.168.250.1 1.1.1.1
ip nhrp network-id 11
ip nhrp holdtime 180
ip nhrp nhs 192.168.250.1
ip tcp adjust-mss 1360
tunnel source GigabitEthernet0/1
tunnel mode gre multipoint
tunnel key 11
tunnel protection ipsec profile dmvpn
end

router eigrp 100
network 172.16.111.80 0.0.0.15
network 192.168.250.0
redistribute static
passive-interface default
no passive-interface Tunnel1

===================
SECONDARY ROUTER
===================

interface Tunnel1
description ++++ Primary DMVPN Cloud 2 ++++
bandwidth 20000
ip address 192.168.250.17 255.255.255.0
no ip redirects
no ip unreachables
no ip proxy-arp
ip mtu 1400
no ip next-hop-self eigrp 100
no ip split-horizon eigrp 100
ip nhrp authentication mykey
ip nhrp map multicast 1.1.1.1
ip nhrp map 192.168.250.1 1.1.1.1
ip nhrp network-id 11
ip nhrp holdtime 180
ip nhrp nhs 192.168.250.1
ip tcp adjust-mss 1360
delay 5000
tunnel source GigabitEthernet0/1
tunnel mode gre multipoint
tunnel key 11
tunnel protection ipsec profile dmvpn
end

router eigrp 100
network 172.16.111.80 0.0.0.15
network 192.168.250.0
redistribute static
passive-interface default
no passive-interface Tunnel1

Kindly Advise

Thanks & Regards,

ARV

Luis Jimenez · ‎08-24-2015

you can try with offset-list, please read this

Use an offset-list on R4 to Modify the Composite Metric at R2

The Composite Metric on R2 can be modified using an offset-list on router R4. An offset-list value of 20 on R4 increases the Composite Metric for the path R2-R4 by 20 on R2. Therefore, the path R2-R4 becomes a backup path to R2-R3. An offset-list is the preferred method if:

You only want to influence a particular path being advertised.
Additional routers are connected to the 10.1.3.0/24 subnet and you do not want to influence paths originated by the routers.

Configure an offset-list on R4 that increases (by 20) the delay for any route starting with 10.1.3.x.

R4# configure terminal

Enter configuration commands, one per line.  End with CNTL/Z.

R4(config)# access-list 99 permit 10.1.3.0 0.0.0.255

R4(config)# router eigrp 1

R4(config-router)# offset-list 99 out 20 e0/0

R4(config-router)# end

R4#

You can in this output that the offset-list does not change anything in the EIGRP topology table on R4.

The metric changes only when the route is advertised.

R4# show ip eigrp topology 10.1.3.0 255.255.255.0

IP-EIGRP (AS 1): topology entry for 10.1.3.0/24
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 281600
  Routing Descriptor Blocks:
  0.0.0.0 (Ethernet0/1), from Connected, Send flag is 0x0
      Composite metric is (281600/0), Route is Internal
      Vector metric:
        Minimum bandwidth is 10000 Kbit
        Total delay is 1000 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 0
  10.1.2.3 (Ethernet0/0), from 10.1.2.3, Send flag is 0x0
      Composite metric is (307200/281600), Route is Internal
      Vector metric:
        Minimum bandwidth is 10000 Kbit
        Total delay is 2000 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 1

On R2, confirm that the route through R3 (10.1.2.3) is once again the only best path.

R2# show ip route

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - ISIS, L1 - ISIS level-1, L2 - ISIS level-2, * - candidate default
       U - per-user static route, o - ODR

Gateway of last resort is not set

     10.0.0.0/24 is subnetted, 3 subnets
D       10.1.3.0 [90/307200] via 10.1.2.3, 00:00:20, Ethernet0
C       10.1.2.0 is directly connected, Ethernet0
C       10.1.1.0 is directly connected, Serial0.101

The EIGRP topology table reflects the increase in delay from R4 (10.1.2.4).

R4 feasible distance (281600) + R4 offset-list (20) = R4 reported distance (281620).

Note: A cosmetic defect in Cisco IOS Software Release 12.0(7) prevents the increased delay from being accurately reflected in the Total Delay section of the output shown here.

DDTS	Description
CSCdp36097 (registeredcustomers only)	EIGRP: offset-list adds incorrect delay value

R2# show ip eigrp topology 10.1.3.0 255.255.255.0

IP-EIGRP (AS 1): topology entry for 10.1.3.0/24
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 307200
  Routing Descriptor Blocks:
  10.1.2.3 (Ethernet0), from 10.1.2.3, Send flag is 0x0
      Composite metric is (307200/281600), Route is Internal
      Vector metric:
        Minimum bandwidth is 10000 Kbit
        Total delay is 2000 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 1
  10.1.2.4 (Ethernet0), from 10.1.2.4, Send flag is 0x0
      Composite metric is (307220/281620), Route is Internal
      Vector metric:
        Minimum bandwidth is 10000 Kbit
        Total delay is 2000 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 1

aravind r v · ‎08-25-2015

Luis Thanks for the reply.

So you mean to say changing the bandwidth and delay in tunnel interface will not change the bandwidth ad delay in Hubside???

Thanks,

ARV

Luis Jimenez · ‎08-25-2015

it´s no that simple remenber that If you change the bandwidth this could be worse because the bandwidth is used for QOS and other decisions on the routing process