[j-nsp] packet drop without ARP adjacency (fwd)

[Josef Buchsteiner]

Thursday, October 6, 2005, 8:04:22 AM, you wrote:

PS>    
PS>    
PS> By the way,
PS>  
PS>  How does Juniper (specifically, non-J-series) handle the case when
PS>  ARP/ND is required to be resolved when you get a packet?  Are the
PS>  packets discarded until the ARP succeed, or something else?  If
PS>  discarded, is there a counter to how much of this occurs?

     the discard counter under the pfe is a regular one and not
     specific due to arp-timeout only.

     In the very begin each segment has a resolve next-hop. Once a
     notification is coming into the lookup complex they first point to
     the resolve next-hop. Then the notification is cached for 2
     seconds at max. and a copy is sent up to the RE to get a final
     next-hop. The next-hop in the PFE is now moving into a hold
     next-hop. In the mean-time the RE send out an arp request and
     once the arp-reply comes back it installed a host route and
     triggers a next-hop change to the PFE which converts this
     next-hop in a unicast next-hop.

     Of  course  those  are  all  throttled  in  the PFE otherwise all
     unresolved  next-hops  would  point  to the RE. This is done with
     default  values  of  66  packet/second  per segment with an upper
     merit  of  500  per PFE. In case you get to much you will see the
     following entry in the syslog.
     
       "NH: resolutions from iif 90 throttled"

     The interface index 90 is not the outgoing interface but the
     incoming interface of the traffic which triggers heavily the
     resolver. This a simplified version how the process works.


PS>  
PS>  (If I'd have to guess, I'd say Next-Hop and/or Discard under 'show pfe
PS>  statistics notification' might be a more general counter on this.)


     your guess is right. the pfe statistics counter with 'normal
     discard' will be incremented.


PS>  
PS>  ---------- Forwarded message ----------
PS>  Date: Wed, 5 Oct 2005 10:07:09 +0300 (EEST)
PS>  From: Pekka Savola <pekkas at netcore.fi>
PS>  To: David Coulson <david at davidcoulson.net>
PS>  Cc: Gert Doering <gert at greenie.muc.de>, cisco-nsp at puck.nether.net
PS>  Subject: packet drop without ARP adjacency [Re: [c-nsp] IOS 12.2S Train]
PS>  
PS>  On Tue, 4 Oct 2005, David Coulson wrote:
 >>> Normally, the SYN packet should cause an ARP entry to spring into
 >>> existance, and the second SYN sent by the machine on the other end will
 >>> then go through to the receiver.
 >>
 >> Wow, you're right - I can't believe I never noticed that. I just ran
 >> some packets across 12.2(29) and the first SYN gets dumped.
PS>  
PS>  Speaking of which, is there a counter or a command to check how many
PS>  packets have been dropped waiting for ARP adjacency to come up ?
PS>  
PS>  Is it 'RP PAS No Adjacency' and 'RP PAS Incomplete Adjacency' in "show
PS>  ip cef switching statistics" ?
PS>  
PS>  --
PS>  Pekka Savola                 "You each name yourselves king, yet the
PS>  Netcore Oy                    kingdom bleeds."
PS>  Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
PS>  _______________________________________________
PS>  cisco-nsp mailing list  cisco-nsp at puck.nether.net
PS>  https://puck.nether.net/mailman/listinfo/cisco-nsp
PS>  archive at http://puck.nether.net/pipermail/cisco-nsp/
PS>  _______________________________________________
PS>  juniper-nsp mailing list juniper-nsp at puck.nether.net
PS>  http://puck.nether.net/mailman/listinfo/juniper-nsp
PS>   
PS>   
PS>