[j-nsp] punting base address packets to RE

Michael Hare michael.hare at wisc.edu
Thu Aug 27 09:04:35 EDT 2015


All-

I realize I may have made some mistakes in my claim based on a misunderstanding of output.

My normal final term in my lo0.0 input filter is 'then count $X; then discard'.  I added a 'then log' while doing a root cause analysis of why I was seeing a large increase in counter $X.  I made the assumption packets were actually hitting the RE because of the log, but this is likely false.  

I have since found KB9262 [http://kb.juniper.net/InfoCenter/index?page=content&id=KB9262], and from the router in question I derived the following statistics..
[...]
$-re0> show pfe statistics traffic 
[...]
Packet Forwarding Engine hardware discard statistics:
    Timeout                    :                    0
    Truncated key              :                    0   
    Bits to test               :                    0        
    Data error                 :                    0
    Stack underflow            :                    0
    Stack overflow             :                    0
    Normal discard             :            674569675 <------
    Extended discard           :                    0 <------
    Invalid interface          :                    0
    Info cell drops            :                    0
    Fabric drops               :                    0

>From the KB:

" The normal discard counter, in the show pfe statistics traffic output, reports the number of packets (notifications) that are silently discarded at packet forwarding engine level, without being further processed by the host (CPU on the System Board or on the Routing Engine) ... The extended discard counter, in the show pfe statistics traffic output, reports the number of packets (notifications) that are silently discarded but that also need to be sent to the host  (Routing Engine) in order to be further processed. "

So trying again, I would expect a non zero 'extended discard' counter if these base address packets were actually being punted.  Also recall I noted I didn't see these in my time series ddos-protection collections, which should have been a red flag I was making the wrong assumption.

I'll verify in the lab at some point by blasting several Ks of base packets at the RE.

Saku, thanks for your second set of eyes,

-Michael

> -----Original Message-----
> From: juniper-nsp [mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of
> Saku Ytti
> Sent: Wednesday, August 26, 2015 10:11 AM
> To: juniper-nsp at puck.nether.net
> Subject: Re: [j-nsp] punting base address packets to RE
> 
> On (2015-08-25 08:46 -0400), Frank Sweetser wrote:
> 
> Hey,
> 
> >
> > If I recall correctly, the base address of a subnet was originally used as
> > an alternative broadcast address by some ancient equipment.  While it's not
> > a behavior I'd expect to see actively used in modern equipment, seeing it
> > handled as a special case as a receiver doesn't surprise me.
> >
> > Based on this, it looks like it's handled as a directed broadcast:
> >
> > https://www.juniper.net/techpubs/en_US/junose10.3/information-
> products/topic-collections/swconfig-ip-ipv6/id-25742.html
> 
> OP said they were punted, not forwarded to LAN. If they behaved by default as
> if 'directed-broadcast' is enabled, it would be rather serious amplification
> problem.
> 
> Directed-broadcast toggle permits the behaviour of flooding WAN arriving
> packet as L2 bcast to LAN.
> Typical use case is sending WOL packets over routed internet to LAN.
> 
> --
>   ++ytti
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp


More information about the juniper-nsp mailing list