[c-nsp] ARP and less specific interface entries

[Rodney Dunn]

What we do is this. For any ip address on a connected interface we point
to what we call a "glean adjacency" from the FIB->adj table.

R400_#sh ip cef 1.1.1.3
1.1.1.0/24, version 6, epoch 0, attached, connected
0 packets, 0 bytes
  via Ethernet0/0, 0 dependencies
    valid glean adjacency

1.1.1.3 is an ip on a /24 connected interface for which there is no
matching arp entry. ie: host doesn't exist.

Now, when we get an arp response for an ip address what we do
is build out the FIB MTRIE and to do that we insert it as a /32
FIB entry for the ip address the arp is for.

ie:


R400_#sh run int e0/0
Building configuration...

Current configuration : 63 bytes
!
interface Ethernet0/0
 ip address 1.1.1.1 255.255.255.0
end

R400_#sh ip arp
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  1.1.1.1                 -   aabb.cc01.9000  ARPA   Ethernet0/0
Internet  1.1.1.2                78   0019.aadc.9e06  ARPA   Ethernet0/0

Notice the arp entry for 1.1.1.2.

Now looking at the CEF fib entry:

R400_#sh ip cef 1.1.1.2
1.1.1.2/32, version 1, epoch 0, cached adjacency 1.1.1.2
0 packets, 0 bytes
  via 1.1.1.2, Ethernet0/0, 1 dependency
    next hop 1.1.1.2, Ethernet0/0
    valid cached adjacency

Notice how it shows "/32" even though it hangs off a /24 prefix connected
route.

That mapping is interface specific and linked to the adj rewrite for the
ARP we learned.

R400_#sh adj det
Protocol Interface                 Address
IP       Ethernet0/0               1.1.1.2(7)
                                   0 packets, 0 bytes
                                   0019AADC9E06AABBCC0190000800
                                   ARP        02:41:01  
                                   Epoch: 0


We have no way to map the /32 prefix for the same ip address out multiple interfaces.

Rodney



Thu, Mar 20, 2008 at 07:03:28AM -0500, Frank Bulk wrote:
> I'm not sure I fully understand what you said, but it appears plausible. =)
> 
> Thanks,
> 
> Frank
> 
> -----Original Message-----
> From: Rodney Dunn [mailto:rodunn at cisco.com] 
> Sent: Wednesday, March 19, 2008 10:50 PM
> To: Frank Bulk
> Cc: 'Peter Hicks'; cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] ARP and less specific interface entries
> 
> Frank,
> 
> CEF isn't architected to handle overlapping directly connected
> subnets. We block most of those configurations from even being allowed.
> I know we've missed some permutations before.
> 
> It has to do with how the /32 adjfib entries are programmed for the
> /32 that maps from the FIB to the arp entry for the ip address.
> 
> Rodney
> 
> On Tue, Mar 18, 2008 at 11:03:08AM -0500, Frank Bulk wrote:
> > I did do that at the time, and the debug said that it was creating an
> > "Incomplete" for those IP addresses.
> >
> > 41w1d: IP ARP: creating incomplete entry for IP address: 10.1.4.208
> > interface FastEthernet0.5
> > 41w1d: IP ARP: sent req src 10.1.0.1 0009.4309.3632,
> >                  dst 10.1.4.208 0000.0000.0000 FastEthernet0.5
> > 41w1d: IP ARP throttled out the ARP Request for 10.1.4.208
> > 41w1d: IP ARP: creating incomplete entry for IP address: 10.1.50.201
> > interface FastEthernet0.5
> > 41w1d: IP ARP: sent req src 10.1.0.1 0009.4309.3632,
> >                  dst 10.1.50.201 0000.0000.0000 FastEthernet0.5
> > 41w1d: IP ARP: sent req src 10.1.0.1 0009.4309.3632,
> >                  dst 10.1.0.51 0000.0000.0000 FastEthernet0.5
> >
> > Frank
> >
> > -----Original Message-----
> > From: Peter Hicks [mailto:peter.hicks at poggs.co.uk]
> > Sent: Tuesday, March 18, 2008 2:14 AM
> > To: frnkblk at iname.com
> > Cc: cisco-nsp at puck.nether.net
> > Subject: Re: [c-nsp] ARP and less specific interface entries
> >
> >
> > Frank Bulk wrote:
> >
> > > Why won't overlapping subnets work on an interface? What does that have
> to
> > > do with the router's ability to ARP for an unknown MAC address? It's the
> > > clients that are key, right? If they have the right mask and point to
> the
> > > right gateway, the packets should be accepted by the router. And as for
> > the
> > > router forwarding traffic to the clients, if they're locally connected,
> > > whether they are more broadly or narrowly defined as being locally
> > > connected, it just needs to ARP?
> >
> > Do a "debug arp" - are ARP who-has packets being broadcast for the
> addresses
> > on
> > one of the secondary subnets that is causing you a problem?
> >
> > Do you see replies coming back?  Are they being rejected?
> >
> >
> > Peter
> >
> > --
> > Peter Hicks | e: my.name at poggs.co.uk | g: 0xE7C839F4 | w: www.poggs.com
> >
> >    A: Because it destroys the flow of the conversation
> >    Q: Why is top-posting bad?
> >
> > _______________________________________________
> > cisco-nsp mailing list  cisco-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/