[c-nsp] Strange ARP behaviour

[David Coulson]

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.

> 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?

> 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?

> 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.

David