Which would most likely cause this problem?

Two routers are connected by a serial link, and are configured to run EIGRP on all interfaces. You examine the EIGRP neighbor table on both routers (using the show ip eigrp neighbor command) and see that the router connected over the serial link is listed as a neighbor for a certain amount of time, but is periodically removed from the neighbor table. None of the routes from the neighbor ever seem to be learned, and the neighbor transmission statistics (SRTT, RTO, and Q Count) seem to indicate that no packets are being transmitted between the neighbors. Which would most likely cause this problem?

Two routers are connected by a serial link, and are configured to run EIGRP on all interfaces. You examine the EIGRP neighbor table on both routers (using the show ip eigrp neighbor command) and see that the router connected over the serial link is listed as a neighbor for a certain amount of time, but is periodically removed from the neighbor table. None of the routes from the neighbor ever seem to be learned, and the neighbor transmission statistics (SRTT, RTO, and Q Count) seem to indicate that no packets are being transmitted between the neighbors. Which would most likely cause this problem?

A.
While multicast packets are being successfully sent over the link, unicast packets are not

B.
There is a bug in the EIGRP code that needs to be fixed.

C.
This is correct behavior for the first few minutes of EIGRP neighbor formation. After four or five cycles, it should straighten itself out and the neighbor

D.
The hello or hold intervals are set differently on the two routers.



Leave a Reply 1

Your email address will not be published. Required fields are marked *


greenhorn

greenhorn

I was in doubt – A or D, so I have made a test.
Changing helo/hold to 1/4 does not influence neighbourhood.
Setting ACL in passing multicast only does the thing – neighbourhood flapping.
So A is correct indeed.