EIGRP - NBMA

[Mohammad Nasim]

hello everyone,

I am studying my first lessons on CCNP. I started with EIGRP and now configuring it over a Frame-Relay network.

• Platform: three c3660 routers in GNS3 environment
• Topology: Hub-and-Spoke
• Strategy: Multipoint with sub-interface s1/0.1 configured
• psudo broadcasts have been configured via frame-relay map ip A.B.C.D xyz broadcast command.
• split-horizon has been disabled over sub-interface s1/0.1 on all routers
• each router's routing table is complete showing all other routers' networks (loopback and physical)
• IP addresing scheme have been revised many times.

The problem is that, Hub router can ping any other router's interface, but spokes cannot ping each others.

what could be the problem, if i can see all necesary info in the routing table in each spoke ?!!

Mohammad Nasim.

CCNA instructor.

[Peter Paluch · Accepted solution]

Hello Mohammad,

The most probable reason is the lack of DLCI mappings on your spoke routers that map the other's spoke IP to the DLCI towards the hub router. You have to add them manually - this is one of the most common issues in hub-and-spoke FR topology.

The lack of reachability between spoke routers does not influence the ability of all routers to have complete routing tables. That is one of the confusing aspects here. However, always keep in mind that pairwise, the communication still works, i.e. WEST can talk to HQ and HQ can talk to EAST, and vice versa. Hence, the routing tables will get complete, but that still does not mean that EAST and WEST can talk to each other directly.

Best regards,

Peter

[Mohammad Nasim]

Thank you Peter.

It works.

I thought that EIGRP is responsible for doing forwarding. yes it seems confusing, but i think that i should think th right way.

EIGRP forwards at layer 3, while DLCIs are Layer 2 aspects.

i thought router would think in this manner

West# ping 10.2.1.1

    10.2.1.1 is through 172.16.124.1 (HQ)

    172.16.124.1 has DLCI of 301

    frame headers are filled with the correct DLCI, and hen forwarded

    HQ receives frame, and forwards it to 172.16.124.2 (EAST)

   HQ knows that 172.16.124.2 has DLCI of 102

    and hence every thing is complete... (EAST should reply in the same trip .. reversed)

seems i was wrong

thank you Peter.

Mohammad

[Peter Paluch]

Hello Mohammad,

Thank you!

One thing to consider here: note that all three routers are connected with the same IP network 172.16.124.0/29. The HQ is .1, the EAST is .2 and the WEST is .3. From the pure IP's viewpoint, all three routers are in the same network. Therefore IP assumes - quite correctly in most cases - that it is possible to talk to each member of this network directly. This is also the assumption made by EAST and WEST: that because they are interconnected by the same IP network, they are also capable of talking to each other directly.

Now, for IP, to talk to a neighbor directly means that no routing is involved, just an ability to resolve the neighbor's IP address to the corresponding Layer2 address. With Ethernet, we would do an ARP table lookup and have the corresponding neighbor's MAC. With Frame Relay, however, there is no such thing. Without static IP/DLCI mappings, you can only discover your truly directly reachable neighbors (via existing VCs), and all other are unreachable even if they are located in the same IP network - because you are unable to resolve their IP to the appropriate DLCI. If you did a debug ip packet you would see errors stating "encapsulation failed" when pinging EAST from WEST or vice versa. If there is no full mesh of VCs, only partial direct connectivity is available, and the remaining mappings must be added manually.

This is the peculiarity of VC-based technologies like Frame Relay or ATM, and is a favourite topic on many exams

Now, OSPF has a network type of point-to-multipoint that tries to work around this deficiency, and help to obtain a full connectivity between spokes without the need of static IP/DLCI mappings. However, as you are already in the ROUTE course, you will find for yourself Good luck with your studies, and please feel welcome to visit us again with any questions or observations you may have!

Best regards,

Peter

[Mohammad Nasim]

Hello Peter,

First of all, i am so so sorry for my late response, although your response was immediate.

your analysis of pure IP point of view is very appreciated. However, i didn't ping 172.16.124.1/2/3 at all. Instead i was pinging 10.2.2.1 (East's loopback 2) from West router, and this definitly requires routing. I was thinking in the concept of Proxy ARP.

When you ask for a mapping of an IP outside of your network to a Physical address (MAC) a router (default gateway) may respond with a fake answer (his own MAC). Inverse ARP (Frame-Realy ARP) was not intruduced in depth in my CCNA books and hence i don't have a wide knowledge about it.

Here is my analysis:

Ethernet Case

• PC1 pings PC2 in another subnet
• PC1 fires an ARP request asking for the MAC of PC2
• R1 responds with a fake answer (Proxy ARP)
• PC1 is very happy with this answer, and will fill frame header with the received MAC

note that PC1 thinks that he have the MAC of PC2, he knows nothing about fake response. (I have my own doubts)

Frame-Relay Case

• West Pings East
• West would fire an Inverse ARP request
• my assumption is that there is no Proxy Inverse-ARP
• no DLCI would be retrieved

here is why Encapsulaion-Error happened

End of analysis

aside from our topic, let me explain why i said (I have my own doubts)

Andrew Tanenboum In his valuable book (Computer Networks) has mentioned two general ways to handle encapsulating packets into frames given that the destination host is in another subnet:

• host1 sends data to his default gateway directly
• host1 should fire an ARP request and waits for a response, and default gateway may forge facts.

Either ways host1 may follow, he definitly knows about the fake MAC.

I have a very bad experience with this topic in my lectures ..

one of my students asks about Host1 behavior in this case, and I proudly gave him the two cases which are not in Cisco books. He smiled and told me that the two answers are available in a CCNA exam, so which answer should he choose b or c ? I smiled and i said I don't know .

For you, i am introducing all types of thanks. I have learnt alot from this discussion.

Thank you Peter,

Mohammad