Question about Bandwidth command on tunnel interface

[crazyman143]

Hi All,

Let's say I have a hub router and multiple spokes via VPN tunnel.  

At a remote site I have two spoke routers- R1 and R2. Each has a tunnel connected to the hub. They run HSRP and connect the remote LAN. 

Both spokes use EIGRP to advertise the remote LAN to the hub. We want the hub sending traffic destined for the LAN network to R1 primarily, and R2 as backup. We set "Bandwidth" commands on Tun0 for R1 and R2 to influence EIGRP. 

My question: Will the hub router be aware of the bandwidth commands? Wouldn't the bandwidth commands have to be on the GIG interfaces of R1 and R2, in order to affect the distance they calculate and then advertise to the HUB via their tunnel? 

I ask because at work we use distance commands on the tunnels, and it seems to work. But in one case it didn't, and I had to manipulate the gig interfaces, and it got me wondering. Seems to me that the bandwidth command is locally significant meaning it shouldn't work like this at all.

[p.kellett · Accepted solution]

Hi crazyman143,

EIGRP looks at outbound interfaces to calculate the metric for the route. There are 3 ways to influence the metric in EIGRP.

1- Modifying the Bandwidth Of the Interface.

2- Modifying the Delay Value of the Interface.

3- Configuring Offset-list.

It's never recommended to modify the bandwidth as it's used for many other things that just EIGRP metric calculation e.g. QOS.

In your situation, you can't adjust the outbound interface of Tunnel 1 because that affects both routes at the same time. You can change the Gig0/1 outbound interfaces whereby you could set the delay higher for the Gig0/1 interface on R1. This would resolve your issue.

The second, and probably better method, is to use an offset list to change the EIGRP metric for the LAN network when it is sent to the HUB from R1.

Let's say the LAN network in 1.1.1.0/24

Under the eigrp process you would configure:

offset-list 1 out 50 tunnel 0

Here the "1" refers to an access-list that you'll need to identify the network you wish to have the metric changed for. i.e.

access-list 1 permit 1.1.1.0

The value "50" is the amount that you want to add on to the metric, and tunnel 0 indicates the interface out of which you wish to advertise this new metric.

To make a perfect job of this, you need to ensure that the new metric for the route through R1 is still a feasible successor for EIGRP. Therefore care must be taken to ensure the correct value is used in either the offset list, or if you decide to change the delay instead. 

A gig interface will normally default to 10 microseconds of delay for EIGRP. You can change the delay, but only in "tens of microseconds". If you change the value from the default of 1 to the value of 2, then this may cause the route via R1 to cease being a feasible successor.

Using the offset-list as described is likely to be your best option as it gives you much closer control of the EIGRP metric.

Thanks,

Paul Kellett

[crazyman143]

Thanks for a thorough response, it was worth the wait. 

So if I understand, you've confirmed what I originally suspected, which is that the bandwidth commands on the Tun0 interfaces shouldn't affect routing decisions made by the Hub. 

I can use the offset list, or the delay command, to modify the cost of the gig interfaces to influence the hub's decisions.

But if I modify the values too much, I risk causing my backup route to have a higher cost than the feasible distance to 1.1.1.0 from the hub's perspective. This would cause the backup route to no longer be considered a feasible successor, because of the feasibility condition. 

thanks for your help.

[p.kellett]

Yes, that's exactly right.

[Philip D'Ath]

Modifying the bandwidth is a perfectly legitimate method of influencing EIGRP - and is a recommended method.

QoS does not use the bandwidth command configured on an interface for anything.

I do agree that using an offset list if another good way of achieving the outcome.