cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1143
Views
18
Helpful
12
Replies

EIGRP Weird Issue !

guruprasadr
Level 7
Level 7

Hello Experts,

We are experiecing serious issue with the EIGRP Protocol.

We are running a LAST MILE Routing protocol as EIGRP between the PE - CE Router.

The EIGRP resets every 60 / 120 seconds for all locations and in the DEBUG the message that i receive is, Goodbye Message / Notification received from Neighbor.

As per Cisco Documents, EIGRP sends Reliable & Un-reliable Packets.

a) Hello's & ACKs are unreliable

b) Updates, Queries and Replies are reliable

Reliable packets are sequenced and require an acknowledgement. Reliable packets are retransmitted upto 16 times if not acknowleged.

Is the cause is due to the below reason:

"RETRY LIMIT EXCEEDED" ie., if the reliable packets is not acknowledged before 16 retransmissions and the HOLD TIMER duration has passed, re-initiate the neighbor.

Request your help / advices in advance.

Thanks & Regards,

Guru Prasad R

12 Replies 12

rajivrajan1
Level 3
Level 3

can u post some configuration/debug msgs from both sides( PE/CE)

what is ur last mile ?

is hcl still using BSNL links as last mile? - if so is that a MLLN link?

csco10716389
Level 1
Level 1

Please share your config , this issue seems to be break in the Eigrp session betweeen your PE-CE.The goodbye message is a feature designed to improve EIGRP network convergence. The goodbye message is broadcast when an EIGRP routing process is shutdown to inform adjacent peers about the impending topology change. This feature allows supporting EIGRP peers to synchronize and recalculate neighbor relationships more efficiently than would occur if the peers discovered the topology change after the hold timer expired.Please find out the session time check any fluctuation.

HI,

Please find the configuration below:

CE Router Configuration:

router eigrp 10

network 192.168.13.176 0.0.0.3

no auto-summary

eigrp stub connected summary

PE Router Configuration:

router eigrp 10

no auto-summary

!

address-family ipv4 vrf 1111-Customer-Mesh

redistribute bgp metric 1 1 1 1 1

network 192.168.13.176 0.0.0.3

default-metric 1 1 1 1 1

no auto-summary

autonomous-system 10

eigrp stub connected summary redistributed

exit-address-family

Best Regards,

Guru Prasad R

Hello Guru,

verify if there is a mismatch on K parameters this can cause the sending of the goodbye message.

May you see the neighbors in the output of

show ip eigrp 10 neigh

or a variation with the vrf vrf-name option ?

Verify the IOS version of CE routers if it is very old it could be a problem for the changes in EIGRP implementation.

note:

I would use different values for the seed metric reflecting the nature of the various parameters for example an MTU of 1 is meaningless but this shouldn't be related to what you see.

Hope to help

Giuseppe

CE stub config makes sense .I think the stub configuration in The PE router is creating the issue.Try removing the stub config in PE router and see.

Ullas

HI Giuseppe / Ullas,

The IOS Version of CE Router:

c1841-ipbase-mz.124-4.T2.bin

In-spite of configuring the STUB at the PE side also the same situation continues.

Can you advice me more in detail about the K value mismatch and what could be exact combination that will work-out.

Thanks in Advance for the HELP

Best Regards,

Guru Prasad R

Hello Guru,

the k-values should match.

However, to understand what is happening I would suggest to use

debug ip eigrp hello

debug ip eigrp adj

debug eigrp hello verbose

However no one of these provide the K-values used on the other side (there was a thread about this some time ago)

you need to understand why the neighorship is restarted, take in account that with EIGRP a mismatch in the timers is not a problem.

you can have a problem with K values for the metric or it is an authentication issue.

The stub config has to be removed at the PE as Ullas has correctly pointed out I'm afraid it can prevent the EIGRP neighborship to stay up.

when you enable stub routing you are saying the router that is a leaf without any router behind it.

try also to delete the address-family and to configure it again without the stub option it may help to clear it.

Hope to help

Giuseppe

HI Giuseppe / All,

Here i would like to share the latest News on the reported issue:

We have taken-up the matter with the Cisco and have acheived the feedback:

ISP Side:

=========

interface GigabitEthernet0/2

"mtu 1526"

no ip address

no ip proxy-arp

ip route-cache flow

duplex full

speed 1000

media-type gbic

no negotiation auto

no cdp enable

end

The main Gigi interface connected to Metro Network are enabled with MTU of 1526 to support the MPLS Customers.

Customer Side:

==============

interface FastEthernet0/2

---output suppressed---

The default MTU of the FaEth Inteface is 1500 only.

In the EIGRP Regular updates, the size of the packet is calculated is as below:

Normal EIGRP Update Packet + added the Routes Update (topology table update).

Cisco Observed, the EIGRP Regular Update packet is more than the normal size it means, consider if the EIGRP packet is 1506 (from PE - CE). Whereas my CE Supports MTU of 1500 only, in this situation, the regular updates are sent 16 times (as retransmissions), Since the Updates are not synchronized / accepted the Neighbor is re-set after the Hold-timer Expires.

Case, if the EIGRP updated packet is 1492 (from PE - CE). CE Supports MTU of 1500, in this situation, the regular update is accepted and the Neighbor is stable.

The details are received during on-call with Cisco, i will update the Technical Reasoning shared by Cisco on the TAC shortly.

Hope I am Informative.

Best Regards,

Guru Prasad R

Hi Guru,

The last post by you was good and very informative. I would be obliged if you could paste more details on this issue and how it was solved.

Thank you.

-/ Kiran

Hello Guru,

we usually think of MTU with OSPF during DB loading phase.

It is coming out the need for a command to specify a max prefixes for single routing update in EIGRP that could help in these scenarios.

very interesting feedback rated as deserved

Hope to help

Giuseppe

Hello All / Giuseppe,

I am glad to share the update given by CISCO for the EIGRP weird issue raised. This will help eveyone to be on alert about the EIGRP behaviour.

I beleive this platform is being a great Knowledge base for everyone. The Updates as follows:

1. EIGRP update packet consists of IP Header (20), EIGRP header (20) and list of TLVs.

2. Each TLV represents one prefix. The TLV is 48 or 52 bytes long, depending on network mask length.

3. For /25 - /32 - it is 52 bytes and for /0 - /24 - 48 bytes.

4. So the resulting packet length depends on the combination of 48 or 52 bytes TLVs.

5. E.g. if you have only /24 of less specific prefixes, all TLVs would be 48 bytes long,

6. so the maximum packet length would be 20 (IP header) + 20 (EIGRP header) + 30 x 48 (TLV) = 1480 - which is ok for both routers (<1500 on CE).

7. PE could not put 31 TLV into the packet, since the resulting length would be 1528 (more than 1526 - PE MTU).

8. But if there are say, 10 TLV each 52 bytes and 20 x 48 bytes TLV, the resulting length would be 1520, which is ok for PE, but unacceptable for CE.

So this is the explanation:

- when sending 10.x.x.x prefixes, the PE happens to combine them in such way, that resulting packet length is always under 1500;

- when 192.168.x.x are added, there appears a combination of TLVs, which results in length less than 1526, but more than 1500 thus jamming the update transmission.

Hope I am Informative.

Best Regards,

Guru Prasad R

Hello Guru,

very kind of you to share the TAC feedback on this issue.

I just checked on Jeff Doyle volume I

The TLV for internal IPv4 routes has type 0x0102.

there is one byte of prefix length followed by a destination field that contain the subnet ip address if only three bytes are needed to identify the base address a 3byte field is used if instead 4 bytes are needed other 3 bytes of 00 of padding are added to make the TLV size a multiple of 4.

However, the possible effects of this variable size of EIGRP routes data on update structures on update packets length is not immediate at all.

This can be helpful.

Best Regards

Giuseppe

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: