Accepted Solutions
Hi Sairam,
With that said, if I have a Metro Ethernet Link connected to one of the GE Routed Port (GE0/1), how does the router reaches the other end peer router. I thought the router will learn the MAC Address of the remote end router and populate that in the MAC address table.
The gi0/1 interface on your router is a routed interface. That means that whatever is going to be sent out that interface is primarily determined by routing, not by switching. The routing table is the key answer here - it is exactly the routing table that will say: "With this packet, you need to send it out the gi0/1 interface". Then, and only then, the router will try to forward the packet out the gi0/1 interface. If the routing table does not point out the gi0/1 interface, no packets are going to be sent out that interface.
Keep in mind that our gi0/1 interface is assigned an IP address in some IP subnet. When your router needs to send a packet to someone else in the same subnet, it will first do a lookup in the ARP table to see if the IP/MAC mapping is already there. If it is, it will just use it. If it isn't, it will broadcast an ARP request and wait for the reply.
The same process would happen if the destination was reachable via an IP next hop address that belongs to the IP subnet of gi0/1 - that next hop address would be looked up in the ARP table, and if it is not there, the router would need to send an ARP request.
But I am able to ping the Remote end Router connected to GE0/1, though there is no MAC address entry in the MAC address table (of course the MAC address of the remote router is in the ARP table)
Yes. That is because when you ping the other end, you ping a host that is in the same IP network as your gi0/1 interface. That is the impulse for your router to send the packet out gi0/1, populating the ARP table in the process.
How to troubleshoot in Layer 2 perspective if the Remote end router is not reachable?
On a routed interface, your options are extremely limited. Neither the routing table nor the ARP table is populated based solely on an IP packet received from the other end. To populate an ARP table, you absolutely need to have an ARP conversation with the other router, and if the other router does not respond to ARP, there is no way of you learning its IP/MAC mapping automatically.
Usually, when I cannot ping the other end router, I at least have a look into the ARP table whether the remote router's MAC address has been discovered via ARP. If not, the IP communication principially cannot work, so I do not even try using IP-based troubleshooting tools. In that case, I need to find out if the remote router is attached, up and running. CDP can be very helpful here.
If the ARP table is populated but the router does not respond to, say, pings then it is often a matter of ACLs or routing. Sometimes I have seen situations when the netmask of the local and remote router was mismatched, one of them was more specific, and the routing protocol advertised both the less and the more specific routes, and the path toward the more specific route went around the entire topology, possibly hitting some stateful firewalls. That was quite nasty to debug 
Please feel welcome to ask further!
Best regards,
Peter
Hi Sairam,
With that said, if I have a Metro Ethernet Link connected to one of the GE Routed Port (GE0/1), how does the router reaches the other end peer router. I thought the router will learn the MAC Address of the remote end router and populate that in the MAC address table.
The gi0/1 interface on your router is a routed interface. That means that whatever is going to be sent out that interface is primarily determined by routing, not by switching. The routing table is the key answer here - it is exactly the routing table that will say: "With this packet, you need to send it out the gi0/1 interface". Then, and only then, the router will try to forward the packet out the gi0/1 interface. If the routing table does not point out the gi0/1 interface, no packets are going to be sent out that interface.
Keep in mind that our gi0/1 interface is assigned an IP address in some IP subnet. When your router needs to send a packet to someone else in the same subnet, it will first do a lookup in the ARP table to see if the IP/MAC mapping is already there. If it is, it will just use it. If it isn't, it will broadcast an ARP request and wait for the reply.
The same process would happen if the destination was reachable via an IP next hop address that belongs to the IP subnet of gi0/1 - that next hop address would be looked up in the ARP table, and if it is not there, the router would need to send an ARP request.
But I am able to ping the Remote end Router connected to GE0/1, though there is no MAC address entry in the MAC address table (of course the MAC address of the remote router is in the ARP table)
Yes. That is because when you ping the other end, you ping a host that is in the same IP network as your gi0/1 interface. That is the impulse for your router to send the packet out gi0/1, populating the ARP table in the process.
How to troubleshoot in Layer 2 perspective if the Remote end router is not reachable?
On a routed interface, your options are extremely limited. Neither the routing table nor the ARP table is populated based solely on an IP packet received from the other end. To populate an ARP table, you absolutely need to have an ARP conversation with the other router, and if the other router does not respond to ARP, there is no way of you learning its IP/MAC mapping automatically.
Usually, when I cannot ping the other end router, I at least have a look into the ARP table whether the remote router's MAC address has been discovered via ARP. If not, the IP communication principially cannot work, so I do not even try using IP-based troubleshooting tools. In that case, I need to find out if the remote router is attached, up and running. CDP can be very helpful here.
If the ARP table is populated but the router does not respond to, say, pings then it is often a matter of ACLs or routing. Sometimes I have seen situations when the netmask of the local and remote router was mismatched, one of them was more specific, and the routing protocol advertised both the less and the more specific routes, and the path toward the more specific route went around the entire topology, possibly hitting some stateful firewalls. That was quite nasty to debug
Please feel welcome to ask further!
Best regards,
Peter
