Looking a technical background info on EIGRP bandwidth on out interface

[Deepak Kumar]

We (me and my friends) are opened a discussion during the lab and we all are understanding that the router is doing right but we want to challenge self technical background (deep drive). Details are here:

The LAB has been configured as explained above and let's check the routing table on both routers:

R1#sho ip route

   1.0.0.0/32 is subnetted, 1 subnets

C    1.1.1.1 is directly connected, Loopback0

   2.0.0.0/24 is subnetted, 1 subnets

D    2.2.2.0 [90/10880] via 192.168.2.2, 00:00:06, GigabitEthernet2/0

         [90/10880] via 192.168.1.2, 00:00:06, GigabitEthernet1/0

   192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks

C    192.168.1.0/24 is directly connected, GigabitEthernet1/0

L    192.168.1.1/32 is directly connected, GigabitEthernet1/0

   192.168.2.0/24 is variably subnetted, 2 subnets, 2 masks

C    192.168.2.0/24 is directly connected, GigabitEthernet2/0

L    192.168.2.1/32 is directly connected, GigabitEthernet2/0

R1#

------

R2#sho ip route

   1.0.0.0/32 is subnetted, 1 subnets

D    1.1.1.1 [90/10880] via 192.168.2.1, 00:58:06, GigabitEthernet2/0

          [90/10880] via 192.168.1.1, 00:58:06, GigabitEthernet1/0

   2.0.0.0/8 is variably subnetted, 2 subnets, 2 masks

C    2.2.2.0/24 is directly connected, Loopback0

L    2.2.2.2/32 is directly connected, Loopback0

   192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks

C    192.168.1.0/24 is directly connected, GigabitEthernet1/0

L    192.168.1.2/32 is directly connected, GigabitEthernet1/0

   192.168.2.0/24 is variably subnetted, 2 subnets, 2 masks

C    192.168.2.0/24 is directly connected, GigabitEthernet2/0

L    192.168.2.2/32 is directly connected, GigabitEthernet2/0

R2#

I found that both links are in load lancing as expected:

But what will happen if I changed a bandwidth on Gi1/0 on the router R1? Do you know?

interface GigabitEthernet1/0

 bandwidth 666666

 ip address 192.168.1.1 255.255.255.0

 negotiation auto

end

Let's check the routing table on both routers again:

R1#sho ip route

   1.0.0.0/32 is subnetted, 1 subnets

C    1.1.1.1 is directly connected, Loopback0

   2.0.0.0/24 is subnetted, 1 subnets

D    2.2.2.0 [90/10880] via 192.168.2.2, 00:01:43, GigabitEthernet2/0

   192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks

C    192.168.1.0/24 is directly connected, GigabitEthernet1/0

L    192.168.1.1/32 is directly connected, GigabitEthernet1/0

   192.168.2.0/24 is variably subnetted, 2 subnets, 2 masks

C    192.168.2.0/24 is directly connected, GigabitEthernet2/0

L    192.168.2.1/32 is directly connected, GigabitEthernet2/0

Now the route for 2.2.2.0 via Gi1/0 has been uninstalled from the routing table due to higher metrics

-----------

R2#sho ip route

   1.0.0.0/32 is subnetted, 1 subnets

D    1.1.1.1 [90/10880] via 192.168.2.1, 01:11:05, GigabitEthernet2/0

          [90/10880] via 192.168.1.1, 01:11:05, GigabitEthernet1/0

   2.0.0.0/8 is variably subnetted, 2 subnets, 2 masks

C    2.2.2.0/24 is directly connected, Loopback0

L    2.2.2.2/32 is directly connected, Loopback0

   192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks

C    192.168.1.0/24 is directly connected, GigabitEthernet1/0

L    192.168.1.2/32 is directly connected, GigabitEthernet1/0

   192.168.2.0/24 is variably subnetted, 2 subnets, 2 masks

C    192.168.2.0/24 is directly connected, GigabitEthernet2/0

L    192.168.2.2/32 is directly connected, GigabitEthernet2/0

R2#

What? There is no impact on R2. Why? It should meet the condition as the minimum bandwidth of the path. As we changed the bandwidth on the R1, port Gi0/1 and it must be minimum bandwidth now

Let's check topology table:

R1#sho ip eigrp topology 2.2.2.0/24

EIGRP-IPv4 VR(testlab) Topology Entry for AS(10)/ID(192.168.2.1) for 2.2.2.0/24

 State is Passive, Query origin flag is 1, 1 Successor(s), FD is 1392640, RIB is 10880

 Descriptor Blocks:

 192.168.2.2 (GigabitEthernet2/0), from 192.168.2.2, Send flag is 0x0

   Composite metric is (1392640/163840), route is Internal

   Vector metric:

    Minimum bandwidth is 1000000 Kbit

    Total delay is 11250000 picoseconds

    Reliability is 255/255

    Load is 1/255

    Minimum MTU is 1500

    Hop count is 1

    Originating router is 192.168.2.2

 192.168.1.2 (GigabitEthernet1/0), from 192.168.1.2, Send flag is 0x0

   Composite metric is (1720320/163840), route is Internal

   Vector metric:

    Minimum bandwidth is 666666 Kbit

    Total delay is 11250000 picoseconds

    Reliability is 255/255

    Load is 1/255

    Minimum MTU is 1500

    Hop count is 1

    Originating router is 192.168.2.2

R1#

--------------

R2# sho ip eigrp topology 1.1.1.1/32

EIGRP-IPv4 VR(testlab) Topology Entry for AS(10)/ID(192.168.2.2) for 1.1.1.1/32

 State is Passive, Query origin flag is 1, 2 Successor(s), FD is 1392640, RIB is 10880

 Descriptor Blocks:

 192.168.1.1 (GigabitEthernet1/0), from 192.168.1.1, Send flag is 0x0

   Composite metric is (1392640/163840), route is Internal

   Vector metric:

    Minimum bandwidth is 1000000 Kbit

    Total delay is 11250000 picoseconds

    Reliability is 255/255

    Load is 1/255

    Minimum MTU is 1500

    Hop count is 1

    Originating router is 192.168.2.1

 192.168.2.1 (GigabitEthernet2/0), from 192.168.2.1, Send flag is 0x0

   Composite metric is (1392640/163840), route is Internal

   Vector metric:

    Minimum bandwidth is 1000000 Kbit

    Total delay is 11250000 picoseconds

    Reliability is 255/255

    Load is 1/255

    Minimum MTU is 1500

    Hop count is 1

    Originating router is 192.168.2.1

R2#

Why the bandwidth for route 1.1.1.1 is not set to the minimum available on the path?

My Answers are:

1.  This bandwidth is a local router interface value. It will not share with a neighbor for any type of negotiation. It is used by higher protocol and TCP protocol. It is not an interface speed value.
2. EIGRP is not sharing it's out interface values such as Bandwidth & Delay with its a neighbor router. The router only sharing the details as How much is the value itself used to calculate metrics. (minimum bandwidth and maximum delay).  If it received lower bandwidth information compare to self incoming interface value in EIGRP update packet information then it used in the metric calculation and same forwarded to a neighbor. the delay is totally added for the complete path. 

Am I right? Waiting for your comment:

[ngkin2010]

Hello,

1. Yes, changing bandwidth on local interface does not affect the bandwidth setting on the other end.

2. Yes, as you have noted. The feasible distance is based on the reported distance & the metric values on the incoming interface of EIGRP update. Changing bandwidth on R1's outgoing interface of EIGRP update have nothing to do with the metric calculation for that route.

[Deepak Kumar]

Yes, I agree and I know the same. But Do you think here that we missed the guaranteed best path?

[ngkin2010]

Hi,

Not quite sure what do you mean by guaranteed best path.

[paul driver]

Hello
Changing the interface BW on R2 gi1/0 link will initiate a local calculation of metric on that link router towards R1 1.1.1.1/32, however this wont effect the advertised metric coming from R1 on that interface nor will the routes go into an active state due to both rtrs being valid successors to each other.

Now because of local recalculation of the new distance towards 1.1.1.1/32 on that interface became lower (higher Bw) the computed distance on R2 changed which resulted in it selecting G1/0 as the successor path however the reported distance from R1 didnt change.

From R1's perspective its own local metric (computed distance towards R2 2.2.2.2/32 never changed nor did the reported distances from R2 so R1 still has the same composite metrics for both interfaces with 2 successors.

[Deepak Kumar]

@paul driver 

Thanks and I agree with you. This is the right approach but my friend has opened an out of way discussion which seems not ideal or technical possible with EIGRP. He says

"Deepak, As EIGRP is ensuring that your packet will travel on loop-free and best path as higher bandwidth and lower delay path. As you changed the bandwidth on the R1 on Gi1/0 then it converts a lower bandwidth link for the R1 but why is it become for R2 as well because how any application running behind the R2 also effected with command. So why a packet from R2 to R1 choose this lower bandwidth link?"

I know this is an out of box question and I do not fully agree with as some of the things will not sync or negotiable between two routers such as delay and this bandwidth. If he will speed and duplex then definitely he will get desire result but not with bandwidth command. Hence, I am also looking that he wants something that he is not possible else he must go with any other protocol or own developed plugin or protocol. 

[paul driver]

Hello

---

@Deepak Kumar wrote:
Deepak, As EIGRP is ensuring that your packet will travel on loop-free and best path as higher bandwidth and lower delay path. As you changed the bandwidth on the R1 on Gi1/0 then it converts a lower bandwidth link for the R1 but why is it become for R2

---

Not sure i understand the question, are you still relating to the above topology and the initial interface change you made on R2 or now are you saying after the R2 change you now make another change on R1?

Each eigrp rtr will have a current known valid successor for each route, (Feasible Distance) which is the lowest computed distance for a route its aware of since the last time an eigrp dual computation took place (active-passive state),This will be the successor which is rtr that will provide this loop-free path you mention and meets the feasibility condition of eigrp.

Now in this case the eigrp feasibility condition on R2 was met when its Gi1/0 BW was changed, So R1 via (G1/0) was named the successor for this destination because R2’s new computed distance for this route was calculated to be lower than the two current known valid successors (R1 via gig1/0 and G0/0) .

As far as Rtr1 was concerned nothing changed, Its own calculated distances to 2.2.2.2/32 and the reported distances from R2 were the same thus its two current known valid successors never change either, However if you were to change the interface BW/delay on either interface of R1 then obviously a recalculation will initiate on this rtr also.

[ngkin2010]

"Deepak, As EIGRP is ensuring that your packet will travel on loop-free and best path as higher bandwidth and lower delay path. As you changed the bandwidth on the R1 on Gi1/0 then it converts a lower bandwidth link for the R1 but why is it become for R2 as well because how any application running behind the R2 also effected with command. So why a packet from R2 to R1 choose this lower bandwidth link?"

---

So your friend were 'complaining' EIGRP have no awareness of bandwidth changed on the other side.

It's true, but generally, this is not the purpose / goal for any dynamic routing protocol. 

OSPF will have the exactly same behavior if you just configured OSPF cost at one side, but not the other side.