Question

RTRA and RTRB can become EIGRP neighbors RTRB (config) #router eigop 1 RTRB (config-router) #network x.x.x.x RTRB (config-router) #metric weights 0 1 1 1 1 0 RTRA (config) #router eigrp 1 RTRA (config-router) #network X.X.X.X RTRA (config-router) #metric weights 0 1 1 1 1 1 True False

Answer 1

This statement is True by showing RTRA and RTRB neighbours

Neighbors Show IP EIGRP Neighbors RtrA#show ip eigrp neighbors IP-EIGRP neighbors for process 1 H Address Interface Hold Uptime SRTT RTO Q Seq (sec) (ms) Cnt Num 2 10.1.1.1 Eto 12 6d16h 20 200 0 233 1 10.1.4.3 13 2w2d 87 522 0452 0 10.1.4.2 Et1 10 2w2d 85 510 0 3 Et1 Seconds Remaining Before Declaring Neighbor Down How Long Since the Last Time Neighbor Was Discovered How Long It Takes for This Neighbor to Respond to Reliable Packets How Long We'll Wait Before Retransmitting if No Acknowledgement

Unidirectional Links RtrB#show ip eigrp neighbors IP-EIGRP neighbors for process 1 H Address Interface Hold Cnt 1 10.1.102.2 Eto 14 Seg Num A 4 0 Hello Update %DUAL-5-NBRCHANGE: IP-EIGRP 1: Neighbor 10.1.5.4 (Seriall) is down: retry limit exceeded B RtrA#show ip eigrp neighbors IP-EIGRP neighbors for process 1 RtrA#

Unidirectional Links In this example, we see what happens when a link is only working in one direction; unidirectional links can occur because of a duplicate IP address, a wedged input queue, link errors, or any other reason you can think of that would allow packets to be delivered only in one direction on a link RtrB doesn't even realize that RtrA exists—RtrA is sending out his hellos, waiting for a neighbor to show up on the network; what it doesn't realize is that the RtrB is already out there and trying to bring up the neighbor relationship RtrB, on the other hand, sees the hellos from RtrA, sends his own hellos and then sends an update to RtrA to try to get their topology tables/routing tables populated-unfortunately, since the updates are also not being received by Rtra, it of course isn't sending acknowledgements; Rtr B tries it 16 times and then resets his relationship with RtrA and starts over . You'll spot this symptom by the retry limit exceeded messages on RtrB, Rtr B having RtrA in his neighbor table with a continual Q count, and RtrA not seeing Rtro, at all CSCdy45118 has been implemented to create a reliable neighbor establishment process (three-way handshake) and reliable neighbor maintenance (neighbor taken down more quickly when unidirectional link encountered). 12.2T, 12.3 and up