Challenge Question - For those studying Routing!

We have a point-to-point Frame Relay WAN topology--

R1

R2

R1 and R2 are not learning any routes from each other. This is a new connection, and you have not configured any form of route or packet filtering. You do some troubleshooting--

R2#ping 172.16.124.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.124.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/13/24 ms

R2#sh ip eigrp ne
IP-EIGRP neighbors for process 25
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 172.16.124.1 Se0/0 132 00:02:36 1 5000 2 0

You go to R1, enable "debug eigrp packet", and reset the link. You see this--

R1#
*Mar 1 22:58:33.158: EIGRP: Sending HELLO on Serial0/0
*Mar 1 22:58:33.158: AS 25, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0
*Mar 1 22:58:33.234: EIGRP: Received UPDATE on Serial0/0 nbr 172.16.124.2
*Mar 1 22:58:33.234: AS 25, Flags 0x1, Seq 28/0 idbQ 0/0
*Mar 1 22:58:33.234: EIGRP: Neighbor(172.16.124.2) not yet found

1. What lines in the output above indicate trouble?
2. Can you draw any conclusions about what is going wrong based on those?
3. Do you have a guess as to the solution?

Find more posts tagged with

Comments

dead_p00l

Is there no debug eigrp output from R2?

NetworkVeteran

It's been up for an hour, so sure, another clue! The first post is enough to narrow the issue down significantly, but here's more output if you want another hint.

I reset the link again and see this--

*Mar 1 23:48:08.398: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0, changed state to up
R2#
*Mar 1 23:48:38.650: EIGRP: Received HELLO on Serial0/0 nbr 172.16.124.1
*Mar 1 23:48:38.650: AS 25, Flags 0x0, Seq 0/0 idbQ 0/0
*Mar 1 23:48:38.650: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 25: Neighbor 172.16.124.1 (Serial0/0) is up: new adjacency
*Mar 1 23:48:38.654: EIGRP: Enqueueing UPDATE on Serial0/0 nbr 172.16.124.1 iidbQ un/rely 0/1 peerQ un/rely 0/0
*Mar 1 23:48:38.658: EIGRP: Sending HELLO on Serial0/0
*Mar 1 23:48:38.662: AS 25, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/1
*Mar 1 23:48:38.662: EIGRP: Requeued unicast on Serial0/0
*Mar 1 23:48:38.666: EIGRP: Forcing multicast xmit on Serial0/0
*Mar 1 23:48:38.666: EIGRP: Sending UPDATE on Serial0/0 nbr 172.16.124.1
*Mar 1 23:48:38.666: AS 25, Flags 0x1, Seq 56/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1
*Mar 1 23:48:38.670: EIGRP: Enqueueing UPDATE on Serial0/0 iidbQ un/rely 0/1 serno 5-33
R2#
*Mar 1 23:48:38.674: EIGRP: Enqueueing UPDATE on Serial0/0 nbr 172.16.124.1 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 5-33
R2#

MickQ

I'm in the middle of IPv6, but I'll bite

The broadcast keyword was left off the FR mapping.

dead_p00l

I really dont know eigrp but it looks like R2 is forming an adjacency with R1. R1 is sending HELLO packets but not receiving HELLO or UPDATE packets. Since R2 seems to be in an adjacent state i would think the issue lies with R1 not receiving eigrp HELLO or UPDATE packets. Am i even close?

dead_p00l

MickQ wrote: »

I'm in the middle of IPv6, but I'll bite

The broadcast keyword was left off the FR mapping.

I also dont know frame relay very well at all. Haven't gotten to that in my sutdying yet.

NetworkVeteran

MickQ wrote: »

The broadcast keyword was left off the FR mapping.

Ding Ding Ding!

dead_p00l wrote:

the issue lies with R1 not receiving eigrp HELLO or UPDATE packets.

R1 receives unicast UPDATEs (as well as pings) per the original post--
*Mar 1 22:58:33.234: EIGRP: Received UPDATE on Serial0/0 nbr 172.16.124.2

R1 does not receive multicast HELLOs.
*Mar 1 22:58:33.234: EIGRP: Neighbor(172.16.124.2) not yet found

This is what led me (and presumably Mick!) to suspect a lower-layer issue, and specifically in this case a frame-relay map statement was indeed missing the 'broadcast' keyword. The broadcast keyword is crucial for broadcast (and multicast!) updates to reach the other device.

The "Q CNT" and "RTO" fields were also helpful indicators. You normally want to see a "Q CNT" of zero and do not want to see an RTO of 5000.

Good troubleshooting, Mick!

dead_p00l

Makes perfect sense. I'll definitely have to play around with that when i get to it in my studies.

MickQ

TBH, I didn't look at the counters (I hate non tabbed/lineated table outputs). It was actually remembering that some EIGRP packets are sent by unicast, and some by multicast.
Since FR is NBMA (non broadcast ma), you need to include the "broadcast" in your FR mappings in order to use the pseudoBroadcast feature. This allows broadcasts and multicasts to be unicasted (yep, you read me right) out your FR mappings.

Remember kids, labs are for learning before and during your work in the field :P

reloaded

MickQ wrote: »

TBH, I didn't look at the counters (I hate non tabbed/lineated table outputs). It was actually remembering that some EIGRP packets are sent by unicast, and some by multicast.
Since FR is NBMA (non broadcast ma), you need to include the "broadcast" in your FR mappings in order to use the pseudoBroadcast feature. This allows broadcasts and multicasts to be unicasted (yep, you read me right) out your FR mappings.

Remember kids, labs are for learning before and during your work in the field :P

I've got a question regarding FR mappings....I understand the nature of FR being NBMA, but what is the condition in which inverse-arp does not work and the mapping is required? It seems most examples of FR config I've seen only use the DLCI mapping w/broadcast when configuring the physical interface (no subs).

NetworkVeteran

reloaded wrote: »

I've got a question regarding FR mappings....I understand the nature of FR being NBMA, but what is the condition in which inverse-arp does not work and the mapping is required?

A common case where they're required is when you want the spokes in a hub-and-spoke topology to be able to ping each other's WAN interfaces. Explained in detail here:

For example--
http://www.techexams.net/forums/ccnp/63847-frame-relay-eigrp.html#post670278

Zartanasaurus

reloaded wrote: »

I've got a question regarding FR mappings....I understand the nature of FR being NBMA, but what is the condition in which inverse-arp does not work and the mapping is required? It seems most examples of FR config I've seen only use the DLCI mapping w/broadcast when configuring the physical interface (no subs).

InARPs aren't forwarded off of their DLCI. So if you have a hub and spoke, a spoke's InARP won't be seen by the other spokes, since the DLCI terminates at the hub. Net result is spokes can't dynamically learn the IPs of the other spokes. So you need a static mapping to the spokes. And a static mapping disables InARP for that protocol/DLCI pair. So if you make a static mapping to a spoke using the same DLCI to reach the hub, you need a static mapping to the hub also.

reloaded

Zartanasaurus wrote: »

InARPs aren't forwarded off of their DLCI. So if you have a hub and spoke, a spoke's InARP won't be seen by the other spokes, since the DLCI terminates at the hub. Net result is spokes can't dynamically learn the IPs of the other spokes. So you need a static mapping to the spokes. And a static mapping disables InARP for that protocol/DLCI pair. So if you make a static mapping to a spoke using the same DLCI to reach the hub, you need a static mapping to the hub also.

Awesome, thanks. That totally makes sense.

Danielh22185

Good stuff! Keep the challenge questions coming!