ip-routing: static routes to an interface instead of next-hop-addresses

Hi!
Today I will have a look to a phenomenon that some people of you might already have experienced but werent able to explain it why it works. Its the feature proxy arp that comes into play when you have a router running a static route not to an next-hop ip address but to an interface only.

Lets check out what I mean with that :).

So first of all a small topology. Quite simple with two routers and R2 also has a loopback interface.

Goal:
– ping the loopback from R2 by using a static route to an interface

Sounds easy but we will see that under some circumstances this isnt easy at all. Lets configure the interfaces.


R1(config)#int fa0/0
R1(config-if)#no shut
R1(config-if)#ip address 172.16.21.1 255.255.255.0

R2(config)#int fa0/0
R2(config-if)#no shut
R2(config-if)#ip address 172.16.21.2 255.255.255.0
R2(config-if)#int lo0
R2(config-if)#ip address 2.2.2.2 255.255.255.255


So first of all we will try to ping the loopback from the interface fa0/0 of R1 which should not work.


R1#ping 2.2.2.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:

*Mar 1 00:05:55.027: IP: s=172.16.21.1 (local), d=2.2.2.2, len 100, unroutable.
*Mar 1 00:05:57.027: IP: s=172.16.21.1 (local), d=2.2.2.2, len 100, unroutable.
*Mar 1 00:05:59.027: IP: s=172.16.21.1 (local), d=2.2.2.2, len 100, unroutable.
*Mar 1 00:06:01.027: IP: s=172.16.21.1 (local), d=2.2.2.2, len 100, unroutable.
*Mar 1 00:06:03.027: IP: s=172.16.21.1 (local), d=2.2.2.2, len 100, unroutable.
Success rate is 0 percent (0/5)


There we go…as expected. There is no route to the destination in our FIB so the router doesnt know where to send the packet out.


R1#sh ip route 2.2.2.2
% Network not in table


Lets use a static route to tell R1 where to route the packets.


R1(config)#ip route 2.2.2.2 255.255.255.255 172.16.21.2

R1#ping 2.2.2.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 16/61/100 ms


Works. The first packet gets lost due to the arp-request the router sends out. ARP…lets check the ARP table there should be an entry carrying the mac-address that belongs to 172.16.21.2.


R1#sh arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 172.16.21.1 - c200.0c38.0000 ARPA FastEthernet0/0
Internet 172.16.21.2 1 c201.0c38.0000 ARPA FastEthernet0/0


Looks good. Lets now try the same ping but not with a next-hop ip address in the static route but with an interface. Before we do that we check the routing entry for that network.


R1#sh ip route 2.2.2.2
Routing entry for 2.2.2.2/32
Known via "static", distance 1, metric 0
Routing Descriptor Blocks:
* 172.16.21.2
Route metric is 0, traffic share count is 1


Now we change the static route.


R1(config)#no ip route 2.2.2.2 255.255.255.255 172.16.21.2
R1(config)#ip route 2.2.2.2 255.255.255.255 fa0/0


For fairness we clear the arp-table of both routers and see what happens when we try to ping.


R1#clear arp int fa0/0

R2#clear arp int fa0/0


So lets check the routing entry on R1.


R1#sh ip route 2.2.2.2
Routing entry for 2.2.2.2/32
Known via "static", distance 1, metric 0 (connected)
Routing Descriptor Blocks:
* directly connected, via FastEthernet0/0
Route metric is 0, traffic share count is 1


Looks a little different but thats ok because we changed the static route and our ping should succeed anyways.


R1#ping 2.2.2.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 12/53/120 ms


Same result as before, but lets check the ARP-table.


R1#sh arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 2.2.2.2 1 c201.0c38.0000 ARPA FastEthernet0/0
Internet 172.16.21.1 - c200.0c38.0000 ARPA FastEthernet0/0
Internet 172.16.21.2 2 c201.0c38.0000 ARPA FastEthernet0/0


What the hell is this??? The ip address of R2s loopback is in the arp table? Strange because usually in the arp cache there are only ip addresses of subnets that are directly connected. For all other ip addresses usually routing is used.

Well here is what happens: R1 only knows that it shall route the packets out Fa0/0. So far so good, but Ethernet is an multi-access network and there could be a lot of hosts in that /24 network who could receive that packets which would be a major security problem. Sounds strange but the router sends an ARP-request for 2.2.2.2 out the network to the L2 address FF:FF:FF:FF:FF:FF. On Cisco routers there is a feature called “proxy-arp” which is on per default on L3 interfaces. Proxy-ARP takes that ARP-request and does a lookup in its FIB. R2 has a route to 2.2.2.2 as it is directly connected. Then R2 responds to that ARP-request with a reply that says “2.2.2.2 is at c201.0c38.0000 at Layer 2. R1 puts this into its routing table and R1 is satisfied because he has a L3 to L2 mapping.

Lets disable this feature on R2 to see if we are right.


R2(config)#int fa0/0
R2(config-if)#no ip proxy-arp
R2(config-if)#do clear arp int fa0/0

R1#clear arp int fa0/0

R1#debug ip packet
IP packet debugging is on
R1#ping 2.2.2.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:

*Mar 1 00:21:45.963: IP: tableid=0, s=172.16.21.1 (local), d=2.2.2.2 (FastEthernet0/0), routed via RIB
*Mar 1 00:21:45.963: IP: s=172.16.21.1 (local), d=2.2.2.2 (FastEthernet0/0), len 100, sending
*Mar 1 00:21:45.967: IP: s=172.16.21.1 (local), d=2.2.2.2 (FastEthernet0/0), len 100, encapsulation failed.
*Mar 1 00:21:47.963: IP: tableid=0, s=172.16.21.1 (local), d=2.2.2.2 (FastEthernet0/0), routed via RIB
*Mar 1 00:21:47.963: IP: s=172.16.21.1 (local), d=2.2.2.2 (FastEthernet0/0), len 100, sending
*Mar 1 00:21:47.967: IP: s=172.16.21.1 (local), d=2.2.2.2 (FastEthernet0/0), len 100, encapsulation failed.
*Mar 1 00:21:49.963: IP: tableid=0, s=172.16.21.1 (local), d=2.2.2.2 (FastEthernet0/0), routed via RIB
*Mar 1 00:21:49.963: IP: s=172.16.21.1 (local), d=2.2.2.2 (FastEthernet0/0), len 100, sending
*Mar 1 00:21:49.967: IP: s=172.16.21.1 (local), d=2.2.2.2 (FastEthernet0/0), len 100, encapsulation failed.
*Mar 1 00:21:51.963: IP: tableid=0, s=172.16.21.1 (local), d=2.2.2.2 (FastEthernet0/0), routed via RIB
*Mar 1 00:21:51.963: IP: s=172.16.21.1 (local), d=2.2.2.2 (FastEthernet0/0), len 100, sending
*Mar 1 00:21:51.967: IP: s=172.16.21.1 (local), d=2.2.2.2 (FastEthernet0/0), len 100, encapsulation failed.
*Mar 1 00:21:53.963: IP: tableid=0, s=172.16.21.1 (local), d=2.2.2.2 (FastEthernet0/0), routed via RIB
*Mar 1 00:21:53.963: IP: s=172.16.21.1 (local), d=2.2.2.2 (FastEthernet0/0), len 100, sending
*Mar 1 00:21:53.967: IP: s=172.16.21.1 (local), d=2.2.2.2 (FastEthernet0/0), len 100, encapsulation failed.
Success rate is 0 percent (0/5)


Beautiful. The debug ip packet shows us that R1 can route it as there is a static route for the 2.2.2.2/32 but we get an error “encapsultation failed”. This means that R1 does not know how to encapsulate the L3 packet into an L2 frame. Well the L2 frame itself is not the problem but he does not know which L2 destination mac-address he should use and instead of usinf FF:FF:FF:FF:FF:FF he does not encapsulate the packet.

Well what can we do about that…manipulate the arp-table :).


R1(config)#arp 2.2.2.2 c201.0c38.0000 arpa

Protocol Address Age (min) Hardware Addr Type Interface
Internet 2.2.2.2 - c201.0c38.0000 ARPA
Internet 172.16.21.1 - c200.0c38.0000 ARPA FastEthernet0/0
Internet 172.16.21.2 4 c201.0c38.0000 ARPA FastEthernet0/0

R1#ping 2.2.2.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/68/152 ms


There we go.

One final question then….why is there a command to specify the interface. Well there are also other access-technologies like HDLC connections via serial interfaces. Those conections are physically always (if not frame-relay) point-to-point connections so the packets are just sent via the link.

I removed the ethernet link and used a serial interface for the interconnection between the two routers.


R1(config)#int s0/0
R1(config-if)#no shut
R1(config-if)#ip address 172.16.21.1 255.255.255.0


R2(config)#int s0/0
R2(config-if)#no shut
R2(config-if)#ip address 172.16.21.2 255.255.255.0
R2(config-if)#no ip proxy-arp
!
R2(config-if)#int lo0
R2(config-if)#ip address 2.2.2.2 255.255.255.255


Not to forget the static route.


R1(config)#ip route 2.2.2.2 255.255.255.255 s0/0

R1#ping 2.2.2.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/41/116 ms


And look at it exactly…even the first packet got transferred. So obviously the arp request was faster than with ethernet…no it wasnt :). There wasnt an arp request as an ARP-request would be useless. R2 receives ALL packets of R1. We can verify that by looking at the arp tables of the routers.


R1#sh ip arp

R2#sh ip arp


Empty :).
I hope you enjoyed it a little. Feel free to comment.

Regards!