EIGRP on CE link causes backbone OSPF to drop

Unanswered Question
Jan 18th, 2009
User Badges:

I have an interesting problem in which enabling EIGRP on the PE for connecting to the CE router, causes OSPF in the MPLS routers to drop their neighbour and establish the session again.

I have attached a diagram showing the MPLS environment with the attached CE routers. Also attached are the appropriate configuration extracts from PE2 and PE4. Note that the configuration uses port-channel 61 on each PE for connecting to the CE routers and currently under the address family in EIGRP the port channel is in passive state until I can find an answer.


*Jan 19 13:43:51: %DUAL-5-NBRCHANGE: EIGRP-IPv4:(21) 1: Neighbor 10.248.1.46 (Port-channel61) is up: new adjacency

*Jan 19 13:44:02: %OSPF-5-ADJCHG: Process 1, Nbr 10.248.255.225 on Port-channel91 from FULL to DOWN, Neighbor Down: Dead timer expired

*Jan 19 13:44:02: %OSPF-5-ADJCHG: Process 1, Nbr 10.248.255.225 on Port-channel91 from LOADING to FULL, Loading Done

*Jan 19 13:44:04: %OSPF-5-ADJCHG: Process 1, Nbr 10.248.255.230 on Port-channel93 from FULL to DOWN, Neighbor Down: Dead timer expired

*Jan 19 13:44:05: %OSPF-5-ADJCHG: Process 1, Nbr 10.248.255.230 on Port-channel93 from LOADING to FULL, Loading Done

*Jan 19 13:44:50: %DUAL-5-NBRCHANGE: EIGRP-IPv4:(21) 1: Neighbor 10.248.1.46 (Port-channel61) is down: interface passive

*Jan 19 13:44:52: %OSPF-5-ADJCHG: Process 1, Nbr 10.248.255.225 on Port-channel91 from LOADING to FULL, Loading Done

*Jan 19 13:44:51: %OSPF-5-ADJCHG: Process 1, Nbr 10.248.255.230 on Port-channel93 from LOADING to FULL, Loading Done


Appreciate any assistance.


Steve



  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Giuseppe Larosa Mon, 01/19/2009 - 13:33
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

Hello Steve,

it is quite a strange issue.


the port-channels are L3 interfaces and the port-channel towards CE2 is in VRF.


However, we had some strange issue with passive-interface default with IS-IS:

a routing leakage in which the VRF access link was advertised in the global routing table !


So my suggestion is to try to use a different approach without using passive interface default.

in eigrp you can use specific network commands with the mask and so also in OSPF.

and you can passive the interfaces that are needed


Hope to help

Giuseppe


obrien.steve Tue, 01/20/2009 - 01:27
User Badges:

Hello Giuseppe,


What seems to fix the problem is removing from OSPF the fast hello packets feature. It would appear that applying EIGRP causes an interrupt to the routing process which they results in the OSPF dead timer expiring.

Not sure why this is the case, but without BFD supporting SSO what other choice is there but too enable fast hellos for OSPF?


Any ideas


Thanks

Steve

Giuseppe Larosa Tue, 01/20/2009 - 02:19
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

Hello Steve,

the only two options are:

built-in ospf fast hellos

or

BFD


if I understood correctly you had fast hellos and you cannot use BFD for questions of compatibility with SSO.


I would try to use single numbered links with the CE instead of the etherchannel bundle to see if in this case the issue is solved


this because EIGRP and also OSPF can manage multiple parallel L3 links


of course fast convergence in the backbone is very important.



Hope to help

Giuseppe


obrien.steve Tue, 01/20/2009 - 14:09
User Badges:

Hi Giuseppe,


Removing the configuration for the etherchannel between the CE and PE made no difference to the outcome, OSPF still drops out because of the dead timer expiring.


You're understanding is correct on my choice of fast hello's as BFD doesn't support SSO as we have dual supervisors. Without fast hellos and the failure of a supervisor, convergence time is very excessive.


Is it common if BFD isn't support that fast hello's should be an option? Considering the links between the PE's is a DWDM network totally 30G, it isn't a throughput issue but must be related to a process issue with the local supervisor.


Thanks

Steve

Giuseppe Larosa Thu, 01/22/2009 - 13:47
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

Hello Steve,

if you haven't already done I suggest you to open a Service Request for this issue


I may be wrong is this your first customer requesting EIGRP as PE-CE protocol ?

I mean you haven't in another device/pop a working scenario like this ?


Hope to help

Giuseppe


obrien.steve Thu, 01/22/2009 - 23:29
User Badges:

Giuseppe Hi,


We have a request into the TAC at the present but the response I received back was that the OSPF fast hello implementation doesn't provide enough room for error. After hours of testing, the only configuration that proved successfully was setting the OPSF hello interval to 1 second and the dead interval to 4 seconds, anything less the end result was the same.

To answer your question on the number of VRFs running EIGRP, we currently have two, the problem one with about 4000 routing entries and the other one with about a dozen or so.

The conclusion I have come to is that the supervisor (sup720-10G-3C) is unable to handle the import of the 4000 entry routing table (the smaller one is fine.

Not an ideal situation having a convergence time of 4 seconds so may need to look into what happens if I get the EIGRP routes redistributed in OSPF at the CE.


Many Thanks

Steve



Actions

This Discussion