static route basic - directly connected interface

[SJ K]

Dear all,

I have 3 routers connected to one another

R1 <-> R2 <-> R10

R1 fa0/0 (192.168.3.1)  -- R2 fa0/0 (192.168.3.2)  (192.168.3.0/24 network)
R2 fa0/1 (192.168.5.1) - R10 fa0/0 (192.168.5.2)   (192.168.5.0/30 network)
I do not have gateway of last resort set across all the routers.

on R1, i created a static route
ip route 192.168.5.0 255.255.255.252 fa0/0

on R3, i created a static route
ip route 192.168.3.0 255.255.255.0 fa0/0


R1#ping 192.168.5.2

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

Voila, success.

Q1) But i am starting to think of when R1 is creating the packet to be send out, how does R1 know what to input for the [DST MAC] address ?

e.g. R1 packet -> [Src IP = 192.168.3.1] [Dst IP = 192.168.5.2] [Src mac = R1faf0/0 mac] [Dst mac = ???]

I do not have any default gateway set on R1 and on my static route to 192.168.5.0/30 network, I have only specify the exit interface which is R1 fa0/0.


How does R1 know to specify the R2 Fa0/0 as the mac address for the [Dst Mac] portion ?

Q2) How does R1 know of R2 mac address ?  Is it that for directly connected interface, the interface on the other end (e.g R2 Fa0/0) is automatically set as the destination gateway for that particular network and its mac address automatically discover ?

Regards,

Noob

[devils_advocate]

As soon as you connect R1 and R2 via an ethernet cable they will begin to talk and therefore build their ARP Caches with the corresponding MAC addresses to reach each other. 

[SJ K]

Hi Devil,

Thanks for reverting, but what i meant is

- how does R1 know that it has to put R2 fe0/0 mac address as the destination mac in the packet to 192.168.5.2 ?

R1 knows that 192.168.5.0/30 must exit via R1 fe0/0 though, but i did not set any next hop address in the static route, how does R1 know it must input R2 fe0/0 mac address as the destination mac ?

Regards,
Noob

[Krishnendu AR]

CEF works the magic here. The CEF table for that static route will show it as recursive adjacency route.

Router#sh ip cef  10.40.250.66
10.40.250.66/32, version 2003972, epoch 0, cached adjacency 10.40.248.245
0 packets, 0 bytes
  Flow: Origin AS 0, Peer AS 0, mask 32
  via 10.40.248.245, 0 dependencies, recursive
    next hop 10.40.248.245, GigabitEthernet0/1.1 via 10.40.248.245/32
    valid cached adjacency

So the CEF will automatically prefetch all the information to send packet via that interface including the MAC address of the neighbor through that interface.

You can verify with this 'show adjacency' command.

Router#sh adjacency GigabitEthernet0/1.1
Protocol Interface                 Address
IP       GigabitEthernet0/1.1      10.40.248.245(65)
Router#

Router#sh adjacency GigabitEthernet0/1.1 detail
Protocol Interface                 Address
IP       GigabitEthernet0/1.1      10.40.248.245(65)
                                   72506425 packets, 33332157461 bytes
                                   0021A116E9F4C0626BFE
                                   341B810000490800
                                   ARP        never
                                   Epoch: 0
Router#

Krishna

[Jon Marshall]

Hi Krishna

Purely for my own information can you explain what you mean by "prefetch".

My understanding of CEF is that it uses optimised tables ie. the FIB and adjacency table and that it does indeed resolve recursive routes.

It may be the way I am reading it but I wasn't aware it automatically resolved next hops ie. if the FIB points to a next hop that has not been resolved by arp then CEF will punt the packet to the main CPU for address resolution and only after that has been done will there be an entry in the adjacency table.

But CEF doesn't automatically arp for all next hops in the FIB before any packets have been sent to those destinations.

Like I say this is purely for my own learning and I may well have misunderstood a basic behaviour of CEF but can you clarify ?

Jon

[Krishnendu AR]

Jon,

As per my understanding the CEF always resolve the L2 information(MAC address) even before it really needs to send a packet to that specific neighbor. 

The L2 header rewrite information is already prepared even before it really needs. So once its needs send a packet to that neighbor, CEF copies the L2 header from CEF adjacency table and send the packet without any further delay.

Router#sh adjacency GigabitEthernet0/1.1 detail
Protocol Interface                 Address
IP       GigabitEthernet0/1.1      10.40.248.245(65)
                                   72506425 packets, 33332157461 bytes
                                   0021A116E9F4C0626BFE
                                   341B810000490800
                                   ARP        never
                                   Epoch: 0
Router#

Here you can see from the highlighted that L2 header is ready with the destination MAC address, source MAC address and even the Ether type value. 0800 at the last is Ethertype for IP.

Krishna

Krishna

[Jon Marshall]

Krishna

Then perhaps I have misunderstood CEF but from your output you can see that a lot of packets have already been sent on that interface.

The reason I am confused is that if you connect two routers together with no routing protocol etc. so no packets are sent between them if you ping from one router to the other you usually see the first packet does not succeed and then the rest do.

This is obviously because the router needs to arp for the destination IP address.

If CEF prepared this information then all ICMP packets should succeed because there would already be an entry in the adjacency table.

So I'm not sure how that is explained.

Jon

[Krishnendu AR]

Jon,

I am not sure I am fully correct. But this is what my understanding is.

When you ping from the router to another router, its never CEF switched. It always process switched using CPU. So it can't check the CEF table. For the self originated packets it will always look at the ARP table. If there is no ARP entry there it will do ARP and then the first packet will be dropped.

CEF table will be used only for the data plane traffic. So any data traffic that pass through the router will NOT suffer the first packet drop problem. 

Krishna

[Jon Marshall]

Krishna

I am not sure I am fully correct

Thanks for being honest because I'm really not sure I understand it properly either :-)

It's not something that has ever occurred to me before but I understand what you are saying about process switching ie. the path has to be setup by the main CPU and cannot use CEF.

My confusion comes from the fact that if a router is connected to a subnet with multiple hosts CEF cannot possibly send arps for all those hosts to prepopulate the table or at least I don't think it does.

Perhaps I am wrong about that but I may do a quick test to see.

I thought that when a packet comes into the router for a destination IP of a host on a subnet connected to the the router and there has been traffic to or from that host so far there would be no adjacency entry and therefore the packet would be punted to CPU.

I'm not disagreeing with you, more thinking aloud.

It's one of the reasons I participate on these forums because I learn something new everyday !

Jon

[Krishnendu AR]

Jon,

Even I would like to do some test to see further results. But unfortunately I don't have access to any device now.

Can you please test if a router is learning multiple adjacencies on the same interface for the multiple hosts connected to it.

Krishna 

[Jon Marshall]

Krishna

I am just about to go on a WebEx but will when I get a chance.

Basically I only have access to a lab in CTE but I will setup a router and multiple end devices (routers with no ip routing etc)  and a switch to create a subnet and see what the router is showing in terms of CEF.

I'll also add in a few end devices on other subnets to test the forwarding plane etc.

It may not be definitive because it's isn't real kit but I'll let you know what I find out.

Sure between us we can find the answer :-)

Jon

[Jon Marshall · Accepted solution]

q1) arp and the routing table are two different things.

R1 looks in it's routing table to find where to send the packet. Then it needs to resolve the next hop to mac address.

If you use an interface as the next hop then the router  sends an arp out of that interface asking for the mac address for the IP address 192.168.5.2

R2 receives the arp and because it has a directly connected interface on the 192.168.5.0/30 network it replies with the mac address of it's fa0/0 interface.

q2) pretty much answered above. It knows about the mac address because R2 told it.

Jon

[SJ K]

Hi Jon,

If R1 send an arp out of that interface fe0/0 asking for the mac address of 192.168.5.2, R2 receives it but 192.168.5.2 isn't set on any interfaces on R2, it will still response with its fe0/0 mac address ? because 192.168.5.0 is directly connected on its fe0/1 interface ?

That is identified by the "C" character below ?

R2>show ip route

192.168.5.0/30 is subnetted, 1 subnets
C       192.168.5.0 is directly connected, FastEthernet0/1

Because on R1 i see the "directly connected" wording also, but it isn't really directly connected and is identified by an "S"

R1#show ip route

     192.168.5.0/30 is subnetted, 1 subnets
S       192.168.5.0 is directly connected, FastEthernet0/0

Regards,

Noob

[Jon Marshall]

If you use a static routing that uses a next hop of a directly connected interface then it shows as directly connected in your routing table but it is still a static route.

Jon 

[Richard Burts · Accepted solution]

John is quite correct that with a static route that specifies the outbound interface and not a next hop address on an Ethernet interface then R1 will send an ARP request for every packet that it is trying to forward. R2 receives the ARP request for 192.168.5.2 and (assuming that proxy arp is enabled) will respond to the ARP request with its own MAC address. A good way to check this out would be to turn on debug for ARP on either R1 or R2, make sure that 192.168.5.2 is not already in the ARP table, and do the ping. The debug will show that R1 sends the ARP request and that R2 responds to the ARP using its own MAC address.

While it does work in this case, a static route with just the outbound interface on Ethernet is generally a sub-optimal choice. When you do this the router works harder, consumes more memory (for the larger ARP table) and is dependent on the neighbor router enabling proxy arp.

HTH

Rick