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!

Advertisements

About markus.wirth

Living near Limburg in Germany, working as a Network Engineer around Frankfurt am Main.
This entry was posted in CCIE, Routing and tagged , , , , , , , , , , , . Bookmark the permalink.

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

  1. sheno says:

    great topic markus

  2. Pingback: Static Routing « Routed Hues

  3. Thanks Markus.
    Very easy for understanding.

  4. Umesh says:

    Markus !

    Thanks a lot for sharing this . Just clarify with serial P2P , only HDLC or PPP are possible which doesn’t require arp resolution as their header includes either 0x0f00 for unicast or 0x8000 for broadcast. Am i right ?

  5. realdreams says:

    Thank you very much. I was working on a BGP multi-link lab and got encapsulation failed. Figured out that I used FE instead of serial in the example thus caused reachability issue with the neighbor’s loopback

  6. azin says:

    Thank youuuuuuuuuuuuuuuuuuuuu 🙂

  7. Azin joje says:

    جوجه خر است گاو من است

  8. Mohamed says:

    good work man!

  9. Hello, Neat post. There is an issue with your
    website in internet explorer, could check this? IE nonetheless is
    the marketplace leader and a large section of other people will omit your great writing due to this problem.

  10. I’m not sսrе why bսt thius weblog is loading very slow for me.

    ӏs anyone else having this problpem or is it a
    ρroblem onn my еnd? I’ll check Ьack later on andd seе iif tɦe problem
    still exists.

  11. Oh my goodness! Awesome article dude! Thanks, However I am having
    difficulties with your RSS. I don’t know why I am unable to subscribe to it.

    Is there anyone else having identical RSS
    problems? Anyone that knows the answer can you kindly respond?
    Thanks!!

  12. My family alwaygs say that I am killing my time here at net,
    however I kjow I am getting familiarity all the
    time by reading thes fastfidious content.

  13. WOW just what I was looking for. Came here by searching for menage

  14. Mlodszywyglad.Wordpress.Com says:

    I really like what you guys are up too. This kind of clever
    work and reporting! Keep up the fantastic works guys I’ve included you
    guys to blogroll.

  15. I was suggested this web site by my cousin. I am not sure whether this post is written by him as nobody else know such detailed about my difficulty.
    You’re wonderful! Thanks!

  16. hacks says:

    A fascinating discussion is worth comment. I
    think that you ought to publish more about
    this subject matter, it may not be a taboo subject but typically people
    do not discuss these topics. To the next! All the best!!

  17. Alisia says:

    Write more, thats all I have to say. Literally, it seems as
    though you relied on the video to make your point.
    You clearly know what youre taljing about, why throw away
    your intelligence on just posting videos to your weblog when yyou could be giving us something enlihtening
    tto read?

  18. I think the admin of this website is really working hard
    in favor of his webb page, since here everyy material iis quality based material.

  19. Leslee says:

    Thanks for your personal marvelous posting! I definitely
    enjoyed reading it, you willl be a great author.I wilkl make sure to bookmark your blog annd will eventually come back in the future.
    I want to encourage one to continue your great writing, have
    a nice morning!

  20. Rozella says:

    LexiVixi MyFreeCams Webcam Video Collection 03.10.2014

  21. Undeniably believe that which you said. Your favorite reason seemed to be
    on the web the easiest thing to be aware of. I say to you, I certainly
    get annoyed while people consider worries that they just don’t know about.
    You managed to hit the nail upon the top and defined out the whole
    thing without having side-effects , people could take a signal.
    Will probably be back to get more. Thanks

  22. Russell says:

    My brother suggested I mitht like this web site.

    He was entirely right. This ost actually made my day. Youu cann’t imagine simply how
    much time I hadd spent for this information! Thanks!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s