Saturday, January 31, 2009

EIGRP: Say Hello to your Neighbors before Updating

I ran across this issue in my CCNA Frame Relay configuration lab studies. After creating a full mesh network in one IP subnet between R1 (Mayberry), R2 (Mount Pilot) and R3 (Raleigh) (see CCNA-ICND2 Exam Cert. Guide, Odom, page 489), and having that work (no big deal, all defaults work just fine), I moved on to testing the requirement of having R3 simulate a non-Cisco router which used ietf encapsulation between the LAPF headers and payload (RFC 1490/2474). No big deal. The encapsulation works just fine. The crux of this issue lies elsewhere.

The exercise, on page 491, states that R1 (a Cisco router) must accommodate R3 by using ietf encapsulation on a frame relay map command. Here is the tricky part. The specific command of interest in Example 14-4 is replaced by a correction in the errata. The errata states the line should be "frame-relay map ip 199.1.1.3 53 ietf". Therein lies the problem. The "authoritative" errata needs an errata!!!

Here are the full configs:

R1:
interface serial0/0/0
encapsulation frame-relay
frame-relay lmi-type ansi
frame-relay interface-dlci 53 ietf !!!!! <--- watch out
ip address 199.1.1.1 255.255.255.0

interface fastethernet 0/0
ip address 199.1.10.1 255.255.255.0
!
router eigrp 1
network 199.1.1.0
network 199.1.10.0


R3:
interface serial0/0/0
encapsulation frame-relay ietf
ip address 199.1.1.3 255.255.255.0

interface fastethernet 0/0
ip address 199.1.12.3 255.255.255.0
!
router eigrp 1
network 199.1.1.0
network 199.1.12.0

Both routers are configured for EIGRP on the their networks. As soon as both links come up, both routers send EIGRP Hellos to each other. R1 quickly creates an adjacency with R3 and immediately sends Update packets. R3 does not do the same.

Hmmm. Inspecting "show ip eigrp neighbors" on R1 displays R3 but a "1" is showing up under the Q column. This means it has sent a message and is awaiting an acknowledgement (I surmise this is a function of RTP - Reliable Transport Protocol). After a time, R1 gives up due to too many retransmissions of it original update. R3's serial interface can be ping'd but that is it.

Meanwhile, on R3, it is receiving updates but not forming neighbors with R1. Why? Because it never hears a Hello from R1. Inspecting "debug eigrp packets", an Update is received from R1 but EIGRP indicates "Neighbor (199.1.1.1) not yet found". What!? Can't you hear it talking to you?

Turns out R1 is not forwarding broadcast (or multicast) over the PVC to R3. EIGRP Hellos are multicast on 224.0.0.10. And the authoritative frame-relay map command was not set with the broadcast option.

So here is the correct config for R1:

R1:
interface serial0/0/0
encapsulation frame-relay
frame-relay lmi-type ansi
frame-relay interface-dlci 53 ietf broadcast !!!!! <--- Aha!!!
ip address 199.1.1.1 255.255.255.0

Neighbor relations form, updates are exchanged, routing tables filled. Ahhh! Life is good! Also, all of this was confirmed via Wireshark for good measure.

Interesting... a router in OSPF will not even start sending updates unless it receives back a Hello with it's IP address in it. But that a different story for

Moral: Say Hello to your neighbors! And make sure they have heard you before giving them the latest news update.

1 comment:

Unknown said...

I ran into the same exact thing using the exorcise in the book. After hours of trying to figure out what was going on I decided to use the "broadcast" key word and all worked fine afterwards.

Real pain in the neck when trying to study for CCNA and the book gives bad information. Doesn't anyone proof read anymore??