cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
5520
Views
11
Helpful
16
Replies

BW and Delay for Ethernet Subinterfaces

ronbuchalski
Level 1
Level 1

We connect to our Metro Ethernet provider via multiple Gigabit Ethernet connections. On each connection we have configured 802.1Q as an encapsulation, and have created multiple subinterfaces, defined by 802.1Q tags, and having /30 IP subnets assigned to them. (Essentially, it's the Ethernet equivalent of a channel bank!)

My question: Each subinterface has been configured with a bandwidth statement that corresponds to the bandwidth provided by the ME provider (mostly 10M, but there are some 5M, 20M, one 30M and one 100M).

However, the delay parameter remains the default for the interface (10usec), and is the same for all subinterfaces.

Should the delay be set, per interface, to a lower value, corresponding with the lower speed of the actual bandwidth available per subinterface?

By the way, I have searched extensively and have yet to find how IOS determines the value of delay for an interface. Does anyone know?

16 Replies 16

Florin,

Thank you for your input. I agree that the bandwidth parameter on an interface is really only used by EIGRP and QoS to do their job, and it does not determine how quickly data is sent out of the interface.

Where we have run into issues is in the case of having a remote location with a 20Mb/s ATM connection and a 100Mb/s MetroE connection. EIGRP naturally prefers the faster connection based on the calculated metric. However, the 100Mb/s connection has a round-trip delay of 20ms, whereas the 20Mb/s ATM connection has a round-trip delay of 10ms. As a result, the throghput across the 100Mb/s path is actually worse than across the 20Mb/s path (Long Fat Pipe syndrome). Therefore, I need to adjust EIGRP metrics to prefer the slower path, and then set up Policy Based Routing to force specific devices to use the 100Mb/s in order to keep their excessive bandwidth needs from clogging the 20Mb/s path.

I guess the bottom line of this discussion is that the delay parameter in EIGRP does not need to reflect the real delay of a path, but merely needs to be factored in if the default EIGRP metric calculations do not provide a primary path that we consider the best path.

Thank you,

Ron Buchalski

Yep, I agree with you. A well prepared network engineer will "engineer" those values accordingly to the network requirements.

Best regards,

Florin.

Review Cisco Networking products for a $25 gift card