EIGRP - bandwidith

EIGRP will use unequal cost load sharing, which is actually quite attractive because other routing protocols do not do this. You can tune this a bit with the variance command, but I don't think there is a way to disable it.

Ahhhh.

I guess thats good and bad. (mostly good)/

So i use the variance command to make it go a certain direction?

EIGRP will always use the LOWEST BW on the path between the two points (from this router to the destination network). If you change the BW but it's not the lowest it won't change the metric. You are better off changing the delay on the interfaces (tho output interface from this router to the destinations) to modify the metrics.

You can probably set variance to 1 to get the results you are looking for. I'm ashamed to say I never thought to try this.

The default variance is 1, I don't know that mattsthe2 changed it from the default.

DT your right i did not modify the default.

But i guess i could change one interface to 1 and the other to 2.

That or take your oringal advice and modify the delay.

Can you give us a show ip route and show ip eigrp topology?

mattsthe2 wrote:

DT your right i did not modify the default.

But i guess i could change one interface to 1 and the other to 2.

That or take your oringal advice and modify the delay.

The variance command is defined under the routing process, and not at the interface level, so this is not possible.

I'm inclined to think these two routes still have the same metric if they are still load-balancing and you have not changed the variance from the default of 1....

cisco_trooper wrote:

mattsthe2 wrote:

DT your right i did not modify the default.

But i guess i could change one interface to 1 and the other to 2.

That or take your oringal advice and modify the delay.

The variance command is defined under the routing process, and not at the interface level, so this is not possible.

He's referring to changing the delay on the interface.

The default delay on a serial interface is 20,000 microseconds (oddly enough when you enter the delay command it is in 10's of microseconds so the default would be "delay 2000")

Anyway, if you want EIGRP to use only one path you can set maximum-paths 1 under the routing process.

Your wish is my command....

D 10.1.0.0 [90/2809856] via 192.168.93.1, 00:01:05, Serial1/1
[90/2809856] via 192.168.92.3, 00:01:05, Serial1/0

P 10.1.0.0/16, 2 successors, FD is 2809856
via 192.168.92.3 (2809856/2297856), Serial1/0
via 192.168.93.1 (2809856/2297856), Serial1/1

remember that ser1/1 has the bandwidith 3000 command and the other interface has default settings.

mattsthe2 wrote:

Your wish is my command....

D 10.1.0.0 [90/2809856] via 192.168.93.1, 00:01:05, Serial1/1
[90/2809856] via 192.168.92.3, 00:01:05, Serial1/0

P 10.1.0.0/16, 2 successors, FD is 2809856
via 192.168.92.3 (2809856/2297856), Serial1/0
via 192.168.93.1 (2809856/2297856), Serial1/1

remember that ser1/1 has the bandwidith 3000 command and the other interface has default settings.

These metrics are the same, which is why you have load balancing occuring with a variance of 1.
Do a sho int s0/1 and sho int s1/1 to confirm the bandwidth on the two interfaces. Please post the results so we can look at them.

R44#sh int s1/1
Serial1/1 is up, line protocol is up
Hardware is M4T
Description: ToRouter11
Internet address is 192.168.93.4/24
MTU 1500 bytes, BW 3000 Kbit, DLY 20000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation HDLC, crc 16, loopback not set
Keepalive set (10 sec)
Restart-Delay is 0 secs
Last input 00:00:01, output 00:00:04, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: weighted fair
Output queue: 0/1000/64/0 (size/max total/threshold/drops)
Conversations 0/1/256 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated)
Available Bandwidth 2250 kilobits/sec
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
100 packets input, 7349 bytes, 0 no buffer
Received 34 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
97 packets output, 7168 bytes, 0 underruns
0 output errors, 0 collisions, 1 interface resets
0 output buffer failures, 0 output buffers swapped out
2 carrier transitions DCD=up DSR=up DTR=up RTS=up CTS=up

R44#sh int s1/0
Serial1/0 is up, line protocol is up
Hardware is M4T
Description: ToRouter33
Internet address is 192.168.92.4/24
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation HDLC, crc 16, loopback not set
Keepalive set (10 sec)
Restart-Delay is 0 secs
Last input 00:00:00, output 00:00:03, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: weighted fair
Output queue: 0/1000/64/0 (size/max total/threshold/drops)
Conversations 0/1/256 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated)
Available Bandwidth 1158 kilobits/sec
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
114 packets input, 8322 bytes, 0 no buffer
Received 40 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
114 packets output, 8376 bytes, 0 underruns
0 output errors, 0 collisions, 1 interface resets
0 output buffer failures, 0 output buffers swapped out
2 carrier transitions DCD=up DSR=up DTR=up RTS=up CTS=up

mattsthe2 wrote:

R44#sh int s1/1
Serial1/1 is up, line protocol is up
Hardware is M4T
Description: ToRouter11
Internet address is 192.168.93.4/24
MTU 1500 bytes, BW 3000 Kbit, DLY 20000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation HDLC, crc 16, loopback not set
Keepalive set (10 sec)
Restart-Delay is 0 secs
Last input 00:00:01, output 00:00:04, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: weighted fair
Output queue: 0/1000/64/0 (size/max total/threshold/drops)
Conversations 0/1/256 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated)
Available Bandwidth 2250 kilobits/sec
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
100 packets input, 7349 bytes, 0 no buffer
Received 34 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
97 packets output, 7168 bytes, 0 underruns
0 output errors, 0 collisions, 1 interface resets
0 output buffer failures, 0 output buffers swapped out
2 carrier transitions DCD=up DSR=up DTR=up RTS=up CTS=up

R44#sh int s1/0
Serial1/0 is up, line protocol is up
Hardware is M4T
Description: ToRouter33
Internet address is 192.168.92.4/24
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation HDLC, crc 16, loopback not set
Keepalive set (10 sec)
Restart-Delay is 0 secs
Last input 00:00:00, output 00:00:03, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: weighted fair
Output queue: 0/1000/64/0 (size/max total/threshold/drops)
Conversations 0/1/256 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated)
Available Bandwidth 1158 kilobits/sec
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
114 packets input, 8322 bytes, 0 no buffer
Received 40 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
114 packets output, 8376 bytes, 0 underruns
0 output errors, 0 collisions, 1 interface resets
0 output buffer failures, 0 output buffers swapped out
2 carrier transitions DCD=up DSR=up DTR=up RTS=up CTS=up

GRRR!!! Someone care to explain why the metrics on these are the same? Stumped!!

I'm assuming you have only changed the bandwidth on the one link, from its default of 1544 to 3000. Since EIGRP uses the CHOKEPOINT bandwidth (the lowest bandwidth of the links along the path) it is still using a bandwidth of 1544 to calculate the metric. If you use a lower bandwidth on s1/1, say 512, you will probably see different results, because 512 should become the chokepoint bandwidth used in the calculation of the EIGRP metric. Give it a try and then show us: show ip eigrp topology again.

cisco_trooper wrote:

I'm assuming you have only changed the bandwidth on the one link, from its default of 1544 to 3000. Since EIGRP uses the CHOKEPOINT bandwidth (the lowest bandwidth of the links along the path) it is still using a bandwidth of 1544 to calculate the metric. If you use a lower bandwidth on s1/1, say 512, you will probably see different results, because 512 should become the chokepoint bandwidth used in the calculation of the EIGRP metric. Give it a try and then show us: show ip eigrp topology again.

I already stated only the lowest BW is used and that is why I suggested chaning the delay since it's additive. mattsthe2 stated it is already load balancing and he wants it to use one of them.

Take a look at the "show ip route x.x.x.x" and it will show the k-values for the route.

R4#sh ip route 174.1.13.0
Routing entry for 174.1.13.0/24
  Known via "eigrp 1024", distance 90, metric 3705856, type internal
  Redistributing via eigrp 1024
  Last update from 174.1.45.5 on Ethernet0/1, 05:52:25 ago
  Routing Descriptor Blocks:
  * 174.1.145.1, from 174.1.145.1, 05:52:25 ago, via Serial1/0
      Route metric is 8930560, traffic share count is 5
      Total delay is 284090 microseconds, minimum bandwidth is 1544 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 1
    174.1.45.5, from 174.1.45.5, 05:52:25 ago, via Ethernet0/1
      Route metric is 3705856, traffic share count is 12
      Total delay is 80000 microseconds, minimum bandwidth is 1544 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 2

R4#

This is where the BW value would need to be different

Well that clears that one up....

so what is the point then of multilinking interfaces together.

For example we have 3 T1's grouped in a Multilink interfaces. Under the Multilink interface we have set the "bandwidith 4500" command.

Why should we even bother setting that command?

Side note: We run BGP out of that interface to our provider.

APA

Available bandwidth stated is different because you have stated a higher bandwidth on one of your interfaces......

Bandwidth command combined with QoS calculations gives you your 'Available Bandwidth' output.......

For QoS purposes the bandwidth command allows the queuing mechanism to calculate how much maximum bandwidth is reserved for priority traffic........ The default for max-reserved-bandwidth is 75% of the available bandwidth..........

3000 * 75/100 = 2250
1544 * 75/100 = 1158

Now look at your sh int outputs....... The answers match!!!! All that available bandwidth is stating is how much maximum bandwidth is reserved on that interface for your QoS queues.........

EIGRP will not be calculating path costs via this output........ EIGRP still knows that both interfaces are actually running at 1544 so hence why you are coming up with the equal metrics via the show ip route output as EIGRP is load balancing across the two equal cost paths!!!........

and as for your last post...... from what I am led to believe- Correct me if I'm wrong as I too am studying for my CCNP at the moment.... Multilinking interfaces together allows the links to act as one....... even though they are different flows.....

The bandwidth command may have been configured for the exact reason I stated above about max-reserved -bandwidth???? Is there a service policy tacked onto your multilinked T1's???

When you use Multilink PPP to bond the 3 T-1's together the packets will typically be fragmented and sent across all 3 links to increase the available bandwidth and to reduce serialization delay. Typically fragmentation isn't needed on anything that is 768kb/s or better so they are probably just bonded to use a single IP address. The ip address should be applied to the virtual template interface as well as the bandwidth command.

If you're not using fragmentation and just multilinking them together it is basically the same as using Etherchannel between switches, all it is doing is increasing the total amount of available bandwidth.

Depending on the configuration the use of a bandwidth command on an interface facing the provider will have no effect on EIGRP but as A.P.A said it may be due to a service policy attached to the interface.

Gentlemen you would both be correct.
We have a service policy on that interface for VoIP.

So in this instance the bandwidth command is used for calculating QoS metrics and not for EIGRP or BGP routing.