06-19-2012 04:26 PM - last edited on 03-25-2019 03:36 PM by ciscomoderator
hello everyone,
I am studying my first lessons on CCNP. I started with EIGRP and now configuring it over a Frame-Relay network.
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.
Solved! Go to Solution.
06-19-2012 08:12 PM
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
06-19-2012 08:12 PM
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
06-19-2012 11:11 PM
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
06-19-2012 11:25 PM
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
06-22-2012 03:44 PM
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
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
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:
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide