6500 reporting wrong delay on 100mb interface?

liquid6

Hey guys - I am wondering if anybody else has ran across this before? I was diagnosing some strange routing issues at work the other day and I was looking into the eigrp calculations from each switch trying to determine what was going on. So I ran across this...I have a cat6500 with sup720s in it, with a gigabit interface that is plugged into a 100mb leased line to another site, negotiated at 100mb/full duplex. The interface reports the DLY (delay) as 10 usec, instead of 100 usec...now when i messed around with this on our 6500 in the lab I got different results aka the 100 usec, but that was on a later IOS version. So I rolled the lab 6500 back to the same IOS ver (12.2(1SXF13. I have a call in with Cisco to determine what I'm seeing is correct, just wanted to float it out there to see if anyone has any ideas?

ps I don't think the bandwidth command has an effect, I tried both 100000 and 1000000.

Thanks,
liquid

software version: s72033_rp-IPSERVICESK9_WAN-M), Version 12.2(1SXF13

interface GigabitEthernet1/24
description
mtu 9216
bandwidth 1000000
ip address 10.228.254.5 255.255.255.252
ip flow ingress
mls qos trust dscp

LAB_SSG_SW1#sh int g1/24
GigabitEthernet1/24 is up, line protocol is up (connected)
Hardware is C6k 1000Mb 802.3, address is 0013.6061.9ac0 (bia 0013.6061.9ac0)
Description:
Internet address is 10.228.254.5/30
MTU 9216 bytes, BW 1000000 Kbit, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 100Mb/s

s72033_rp-IPSERVICESK9_WAN-M), Version 12.2(33)SXH5

interface GigabitEthernet1/24
description
mtu 9216
bandwidth 1000000
ip address 10.228.254.5 255.255.255.252
ip flow ingress
mls qos trust dscp


LAB_SSG_SW1(config-if)#do sh int g1/24
GigabitEthernet1/24 is up, line protocol is up (connected)
Hardware is C6k 1000Mb 802.3, address is 0013.6061.9ac0 (bia 0013.6061.9ac0)
Description:
Internet address is 10.228.254.5/30
MTU 9216 bytes, BW 1000000 Kbit, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 100Mb/s, media type is 10/100/1000BaseT

dtlokee

why not try the delay command to modify the delay on the interface?

I thought the 1Gb/s interfaces were 10us and the 100mb/s and 10mb/s showed up as 100us but I can't say that I have looked at it that close.

Ahriakin

dtlokee wrote: »

why not try the delay command to modify the delay on the interface?

I thought the 1Gb/s interfaces were 10us and the 100mb/s and 10mb/s showed up as 100us but I can't say that I have looked at it that close.

Ditto on setting it manually. (And what happens if you turn off auto and force 100/full both sides...just curious)

liquid6

well I was going to set it manually, but i couldn't understand why it was setting it that way...so I started to question my understanding of the EIGRP calculation(after much digging in google and cisco.com) I came to the conclusion that the setting must've changed...it could be when they rejigged for 10gbE. So before I change anything I just wanted to understand why...also we are upgrading the IOS soon enough and just wanted to confirm what would happen in the new IOS.

I'll let you know what cisco say.

Thanks,
liquid

Ahriakin- In production they are set manually on both sides with the same result.

dtlokee

Using the bandwidth value is not the recommended way to change the metric for EIGRP because the algorithm only uses the lowest bandwidth along the path to the remote destination. Use delay instead.

liquid6

Well still no official word from Cisco on the delay on the interface and what IOS version it changed. The guess is that when they introduced 10gb interfaces is when it changed. BT doesn't want to raise an official TAC case, i heard a rumor that big partners are charged if they use too many TAC cases, which I think is a stupid way to run things.

So bottomline, i'm going to manually adjusting the delay on the interface...which is what I had planned from the beginning...oh well

liquid