Re: [j-nsp] Policy-statement to match on metrics less than, greater than, or within a range

2015-08-27 Thread Phil Rosenthal 

> On Aug 27, 2015, at 7:15 AM, Alexander Arseniev  
> wrote:
> 
> There is a floor for MED and it is 0.
> What You could do is :
> 
> term 1 then { metric subtract 1000; next term }
> term 2 from metric 0; then { local-preference 100; accept } 
> 
> You won't be able to keep the original MED though :-(
> HTH
> Thanks
> Alex

Thanks!

This is obviously much less elegant than Cisco's solution (which is honestly 
pretty stunning to me to ever say such a thing), but is still usable.

Hopefully someone from Juniper is reading this and decides to fix this by 
adding a proper solution.

-Phil

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] punting base address packets to RE

2015-08-27 Thread Michael Hare 
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-boun...@puck.nether.net] On Behalf Of
> Saku Ytti
> Sent: Wednesday, August 26, 2015 10:11 AM
> To: juniper-nsp@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@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Policy-statement to match on metrics less than, greater than, or within a range

2015-08-27 Thread Alexander Arseniev 

There is a floor for MED and it is 0.
What You could do is :

term 1 then { metric subtract 1000; next term }
term 2 from metric 0; then { local-preference 100; accept }

You won't be able to keep the original MED though :-(
HTH
Thanks
Alex

On 27/08/2015 05:40, Mark Tinka wrote:


On 27/Aug/15 01:55, Phil Rosenthal wrote:


Hello all,

On Cisco, it is possible to write a route policy as such:

route-policy test
 if med le 1000 then
 set local-preference 100
   endif
   end-policy

Is there any way to do the same thing with Juniper? It seems that the “from metric” 
statement only accepts a static value (comparable to "if med eq 1000”).

I've never used metric as a match condition in anything, but from what I
can see in Junos, the value needs to be absolute.

Of course, you can have as many terms as you want matching various
metric values, but this is not as elegant as the IOS XR one, I suppose.

Mark.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp