Challenge Question - For those studying Routing!

NetworkVeteranNetworkVeteran Member Posts: 2,338 ■■■■■■■■□□
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?

Comments

  • dead_p00ldead_p00l Member Posts: 136
    Is there no debug eigrp output from R2?
    This is our world now... the world of the electron and the switch, the
    beauty of the baud.
  • NetworkVeteranNetworkVeteran Member Posts: 2,338 ■■■■■■■■□□
    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#
  • MickQMickQ Member Posts: 628 ■■■■□□□□□□
    I'm in the middle of IPv6, but I'll bite ;)

    The broadcast keyword was left off the FR mapping.
  • dead_p00ldead_p00l Member Posts: 136
    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?
    This is our world now... the world of the electron and the switch, the
    beauty of the baud.
  • dead_p00ldead_p00l Member Posts: 136
    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.
    This is our world now... the world of the electron and the switch, the
    beauty of the baud.
  • NetworkVeteranNetworkVeteran Member Posts: 2,338 ■■■■■■■■□□
    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_p00ldead_p00l Member Posts: 136
    Makes perfect sense. I'll definitely have to play around with that when i get to it in my studies.
    This is our world now... the world of the electron and the switch, the
    beauty of the baud.
  • MickQMickQ Member Posts: 628 ■■■■□□□□□□
    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
  • reloadedreloaded Member Posts: 235
    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).
    Reloaded~4~Ever
  • NetworkVeteranNetworkVeteran Member Posts: 2,338 ■■■■■■■■□□
    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
  • ZartanasaurusZartanasaurus Member Posts: 2,008 ■■■■■■■■■□
    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.
    Currently reading:
    IPSec VPN Design 44%
    Mastering VMWare vSphere 5​ 42.8%
  • reloadedreloaded Member Posts: 235
    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.
    Reloaded~4~Ever
  • Danielh22185Danielh22185 Member Posts: 1,195 ■■■■□□□□□□
    Good stuff! Keep the challenge questions coming!
    Currently Studying: IE Stuff...kinda...for now...
    My ultimate career goal: To climb to the top of the computer network industry food chain.
    "Winning means you're willing to go longer, work harder, and give more than anyone else." - Vince Lombardi
Sign In or Register to comment.