How EIGRP works in Ether- Channel in CIsco 6500 SW with neighbor as VLAN interface

[shanfrancis]

Hi Folks,

I am looking for an answer for the given scenario.

"How EIGRP works in Ether- Channel in Cisco 6500 SW with neighbor as VLAN interface"

We got two 300 Mb NLDs links between branches enabled with Ether-channel and see whenever one ISP fails there is flap in EIGRP but similarly other branches which has the same topology/connectivity has no issues or flaps.

Tried searching in web to see how it works and why there is a different behavior for two similar scenarios we have, but in vain we did not get a right explanation. Request you experts to provide me with simple and valid explanation so that I could understand.

[Jon Marshall]

EIGRP works fine using SVIs as the L3 interface.

So you have an etherchannel between the switches and when one link fails it affects EIGRP ?

What do the logs show ?

Jon

[shanfrancis]

Hey Philip/Jon,

Thanks for the response !!

I will clarify few things here.

As I mentioned we got two links between Sw1 and Sw2 , say Link A and Link B are ether channeled and act as portchannel-1

Link A is a problematic ISP and Link B is stable one. When Link A flaps or goes down we see the EIGRP neighbor ship reestablish and this is causing all the traffic to interrupt until EIGRP converges. But we did a admin shut of Link B interface and see there are no drops or concerns and see the EIGRP never flaps. This shows that EIGRP is always trying to leverage Link A (Problematic one) for its adjacency. My ask is how do I tune EIGRP to leverage Link B.

[Philip D'Ath]

Are you using a channel negotiation protocol like PAgP or LACP, or have you got channelling just set to "on".  It sounds like you might have it hard coded to on.

Could you post your port channel config?

[shanfrancis]

Its between two Cisco switches and is enabled with PagP

description <<PO-xxxx>>
switchport
switchport access vlan xxx
switchport mode access
bandwidth 200000
mls qos trust cos

interface GigabitEthernet4/18
description <<xxxxxx>>
switchport
switchport access vlan xxx
switchport mode access
bandwidth 100000
speed 1000
duplex full
mls qos trust cos
flowcontrol send off
channel-group 20 mode desirable
hold-queue 4096 in
hold-queue 4096 out

[Philip D'Ath]

Hmm.  So you are using PAgP.  This does not support (to the best of my knowledge) changing the timer values, and we are facing a convergence issue.

I think you should try using LACP instead (channel-group 20 mode active) on all ends, and enable "lacp rate fast".

http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/interface/command/ir-cr-book/ir-l1.html#wp2006781800

interface GigabitEthernet4/18
  channel-group 20 mode active
  lacp rate fast

[shanfrancis]

Thank You Philip !!

I will have this tried and let you know.

[Giuseppe Larosa]

Hello Shanfrancis,

I think Philip is on spot suggesting LACP with fast timers (1 second).

An explanation why your EIGRP neighborship flaps over the bundle is given by the fact that EIGRP hello packets as every other traffic flow are subject to the load balancing algorithm of the bundle, so you may be so little lucky that at least in one direction the EIGRP hello message travels over the more troubled link.

BFD is not helpful in your scenario because only high end platforms like CRS support BFD per bundle member link.

Standard BFD is a lightweight protocol but it is still a single message that is sent out a single member link of the bundle per direction.

Hope to help

Giuseppe

[Philip D'Ath]

The nastiest problem I can think of is when both ends of one link stay up, and the traffic is black holed in the middle.  In fact it would probably be worse if one end stayed up while the other end went down.

One switch would be trying to balance between two circuits, getting half its traffic biffed away while the other uses the single link.  It could EIGRP all sorts of upset.

Make sure you configure BFD.  Then the switches can much more actively detect failures and resolve them.

http://www.cisco.com/c/en/us/td/docs/ios/12_0s/feature/guide/fs_bfd.html

Also try and use a protocol like LACP or PAGP so that they try and negotiate the link, rather than just forcing the channel "on".  But on the whole, BFD is the best option.