[c-nsp] Strange ARP behaviour

[Rodney Dunn]

On Sat, Aug 06, 2005 at 05:56:20PM -0400, David Coulson wrote:
> Rodney,
> 
> 	Thanks for the feedback. A quick overview of what I see.
> 
> > sh ip cef <dst ip> from RouterA where the subnet
> > is connected to.
> 
> core2#sh ip cef 207.166.219.199
> 207.166.219.192/28, version 17, epoch 0, attached, connected
> 0 packets, 0 bytes
>    via BVI100, 0 dependencies
>      valid glean adjacency
> 
> Looks right to me.

Yep.

> 
> > Get it both on the RSP and the ingress VIP the
> > traffic is coming in on from Router B.
> 
> core1.cleveland#sh ip cef  207.166.219.199
> 207.166.219.192/28
>    nexthop 207.166.192.3 FastEthernet0/0
> 
> Looks right also - That is the correct next hop IP address. How do I get 
> the CEF information of the VIP?

execute-on slot <X> sh ip cef 207.166.219.199
or if your code doesn't have the 'execute-on' functionality
if-con <slot>
en
sh ip cef 27.166.219.199
if-quit

> 
> > A directly attached subnet should match a glean
> > adjacency and when a packet comes in you drop
> > and punt so the process level code can arp for it
> > to build the CEF adjacency. When the arp address is
> > populated (sh arp) then there will be a /32 FIB entry
> > installed (sh ip cef dstip) that points to the new adjacency
> > (mac header rewrite) for that ip address.
> 
> Correct. If I ping the IP for >5secs, it will construct the CEF 
> adjacency and everything will work right. Is there something I can do 
> which may reduce this delay?

That's not right. It shouldn't take 5 sec it should take
msec. The first packet should be punted and the arp should
be resulved right away.

> 
> > It sounds like the ingress packet isn't being punted to
> > the RSP for the ARP to be sent which is a bug.
> 
> Okay - A bug it is. I'm currently running  Version 12.2(18)S9 on router 
> A, so is there 12.2S which isn't broken in this way? I tried 12.2(25)S5, 
> which was used for my prior testing, which seems to be MORE broken, 
> since it never builds the CEF adjacency, even after a short amount of time.
> 
> Recommendations or suggestions would be useful - I've had no success 
> running 12.0 on the hardware, as it seems to fail during the boot stage 
> of the slave RSP.

Well, a couple things I see.
a) I currently don't recommend customers run 12.2S on their 75xx's
   because of some scalability issues we had after we did some
   rework to the CEF code. Wait for SB to come out in the next
   few months.

b) I see that egress interface is a BVI. What you need to do
   is to determine if the packet does get punted and the arp
   is sent out but there is a delay there somehow. Try this.
   Build an ACL to match on packets just to that destip.
   access-list 101 permit ip any host <dstip>

   Turn on the debug against it: debug ip packet 101 detail
   Turn on debug arp

Then run the ping and what you should see if the packet get
punted to the RSP for the very first packet and the others
get dropped due to a stalled adjacency (because it hasn't
been built yet). It's done that way to protect the RSP punt
path.


c) What hardware do you have and what features doe you need?
   Bridging definitely is not SSO aware so it's not going to
   do you much good there.
   12.3 mainline has been pretty solid on the 75xx and
   12.4 has RPR+ for HA.

I'm hoping 12.2SB will start to bridge the gap of feature
parity even more moving forward.

Rodney


> David