The blog includes a vivid coverage of the concepts of CCNA, CCNP (Routing & Switching) , Basic Linux and Linux servers. Projects have also been simulated to give a practical exposure.

Friday, 16 May 2014

%DUAL-5-NBRCHANGE: IP-EIGRP(0)

No comments

I searched everywhere on internet about this error. I faced this error yesterday, on internet i found that this error is due to MTU packet size. It is quite surprising for me that MTU is creating problem, because I have learned that router perform fragmentation, segmentation if packet is large. But I found that these processes does not occur in this case. Because all EIGRP packets are trasported as IP protocol type 88 using Reliable Transport Protocol (RTP), not TCP or UDP, while Fragmentation is the mechanism in TCP transport.

EIGRP has a problem of flapping (up/down) in some topologies. It makes the network unstable, which creates problem in communication. This problem shows errors like this :-
 
%DUAL-5-NBRCHANGE: IPv6-EIGRP(0) 1: Neighbor FE80::2 (Tunnel0) is up: new adjacency

%DUAL-5-NBRCHANGE: IPv6-EIGRP(0) 1: Neighbor FE80::2 (Tunnel0) is down: holding time expired

It is the case of IPv6 tunneling.

Same error is also given in IPv4 likewise :- 

%DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 192.168.1.1 (Tunnel3) is up: new adjacency

Basically this error is due to the EIGRP, By default, MTU size is 1500 in each router, this MTU size creates the problem in communication. So it can be solved by reducing the MTU size.  

So in last I got this explanation for this error :-

Two routers peer with MTU of 1500, but in the path between them there is a L2 hop that has a smaller MTU.  1492 for example.  The two routers will hello and establish neighbor with smaller than 1492 packets and have no problem.  The first time one of the routers tries to send routes to the other router the packet will likely exceed the 1492 MTU and be dropped along the way.  The router will retransmit several times and never get the ack, then it will dump the neighbor relationship and re-learn the neighbor - <repeat until someone figures the problem out>.  In a topology with multiple paths this type of problem can be delayed in manifesting itself because EIGRP doesn't share routes with neighbors unless they ask for them.  I had this problem occur three days after deploying a new L2 WAN circuit because there was no significant EIGRP convergence event until 3 days later.  Lesson learned -> always "ping size 1500 df-bit x.x.x.x" new WAN paths. 


By :- Vishal Sharma

No comments :

Post a Comment