Re: [j-nsp] set MED only on empty

[Alexander Arseniev via juniper-nsp]

--- Begin Message ---

Hello,
Last time I tested it, "from metric 0" works only if MED is present and 
equals 0.
Back then (around JUNOS 17) I developed a policy to detect missing MED 
which exploits metric2 rollover (basically, subtracting 1 from missing 
MED results in MED==4294967295)

Example below:
regress@R1# show policy-statement CHECK_MED_IMPORT
term CHECK_IF_MED_EXISTS_AND_0 {
from {
metric 0; {## accept if MED present && 0
}
then accept;
}
term MED_DECREMENT {
then {
metric {
expression {
metric multiplier 1 offset -1; ## turns absent MED into 
2^32-1

}
}
next term;
}}
term CHECK_IF_MED_ROLLED_OVER {
from metric 4294967295;
then accept; ## sets missing MED to 4294967295 but You can set it to 
smthg else

}
term RESTORE_ORIGINAL_MED {
then {
metric add 1;
}
}

Thanks
Alex

-- Original Message --
From: "Baldur Norddahl" 
To: "Juniper List" 
Sent: 19/09/2020 22:49:07
Subject: Re: [j-nsp] set MED only on empty


Hello

Metric zero should work, I do not know why I did not think of that.

Thanks,

Baldur

Den lør. 19. sep. 2020 kl. 21.13 skrev Eduardo Schoedler 
:



 Hi Baldur,

 Try match metric, with some tests you can define empty (maybe zero?).


https://www.juniper.net/documentation/en_US/junos/topics/usage-guidelines/policy-configuring-match-conditions-in-routing-policy-terms.html



 Regards.


 Em sáb., 19 de set. de 2020 às 12:59, Baldur Norddahl 
 escreveu:


 Hello



 I want to set MED (metric) only when the peer did not specify a MED value.

 The idea being that peers that set MED have a reason for their choice, but

 if no MED value is set, I am going to set it to MED=(latency_to_peer_in_ms

 + 1000). That way we will prefer the route with lowest latency.



 But I can not figure out how to match on no MED value in a policy. There

 must be a way to do this?



 Thanks,



 Baldur

 ___

 juniper-nsp mailing list juniper-nsp@puck.nether.net

https://puck.nether.net/mailman/listinfo/juniper-nsp

 --

 Eduardo Schoedler


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


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

Re: [j-nsp] DDOS_PROTOCOL_VIOLATION on DHCP - and it's not configured?

[Alexander Arseniev via juniper-nsp]

--- Begin Message ---

Hello,
2 possibilities:
1/ Your MX240 loopback filter does not block udp/67
2/ You have DHCP traceoptions configured  - it starts jdhcpd process 
even if there is no other DHCP config:


set system processes dhcp-service traceoptions blah-blah

Thanks
Alex

-- Original Message --
From: "Mike" 
To: juniper-nsp@puck.nether.net
Sent: 05/05/2020 19:31:49
Subject: [j-nsp] DDOS_PROTOCOL_VIOLATION on DHCP - and it's not 
configured?



Hello,

On my MX240, I occasionally get log messages of this type:

May  4 20:47:38  jmx240-fmt2 jddosd[3549]: DDOS_PROTOCOL_VIOLATION_SET:
Warning: Host-bound traffic for protocol/exception  DHCPv4:bad-packets
exceeded its allowed bandwidth at fpc 1 for 417 times, started at
2020-05-04 20:47:37 PDT
May  4 20:52:55  jmx240-fmt2 jddosd[3549]:
DDOS_PROTOCOL_VIOLATION_CLEAR: INFO: Host-bound traffic for
protocol/exception DHCPv4:bad-packets has returned to normal. Its
allowed bandwith was exceeded at fpc 1 for 417 times, from 2020-05-04
20:47:37 PDT to 2020-05-04 20:47:50 PDT

I have looked at my config, and I am positively not providing dhcp
service of any kind, have no dhcp relay service on the router
configured, and simply fail to see how or why these messages are being
triggered. I do have some virtual hosts that are acting as dhcp servers
for relayed dhcp traffic, but at the point my router sees this traffic
its only udp port 67 traffic being forwarded to these servers from my
far away dhcp clients.

I almost want to say that, despite config, the router is in fact
keying into relayed dhcp traffic for some reason. Wondering how I would
go about more properly diagnosing this problem?


Thank you.



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


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

Re: [j-nsp] Slow RE path 20 x faster then PFE path

[Alexander Arseniev via juniper-nsp]

--- Begin Message ---

Hello,
Well, my first advice - don't use interface-style service-sets until You 
100% understand what You are actually doing. Just don't.
Second - don't try to mimic SRX' NAPT-to-interface-address translation 
feature on MX with inline NAT, it is not supported, albeit technically 
possible and very complex. Just don't.
Third - don't tinker with static routes to next-table and similar stuff 
in conjunction with inline services.
Fourth - use nexthop-style service-sets with both ends of SI- IFL pair 
in different routing-instances. It is the most straightforward inline 
NAT config possible.
Hopefully that's enough to get You started , and without Your config I 
have no other ideas to share, perhaps others can chime in.

Thanks
Alex

-- Original Message --
From: "Robert Raszuk" 
To: "Alexander Arseniev" 
Cc: "Juniper List" 
Sent: 24/03/2020 08:24:36
Subject: Re: Re[2]: [j-nsp] Slow RE path 20 x faster then PFE path



Yes NAT is configured there as I indicated via presence of si- phantom 
load ... Having NAT there is not my idea though :). But sorry can not 
share the config.


If you could shed some more light on your comment how to properly 
configure it and what to avoid I think it may be very useful for many 
folks on this list.


Many thx,
R.



On Tue, Mar 24, 2020 at 5:00 AM Alexander Arseniev 
 wrote:

Hello,




Another interesting observation is that show command indicated 
services
inline input traffic over 33 Mpps zero output while total coming to 
the box

was at that time 1 Mpps 


Do You have inline NAT configured on this box? Is it possible to share 
the config please?
It is quite easy to loop traffic with NAT (inline or not) and while 
looped inside same box,
TTL does not get decremented so You end up with eternal PFE 
saturation.


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

Re: [j-nsp] Slow RE path 20 x faster then PFE path

[Alexander Arseniev via juniper-nsp]

--- Begin Message ---

Hello,




Another interesting observation is that show command indicated services
inline input traffic over 33 Mpps zero output while total coming to the box
was at  that time 1 Mpps 


Do You have inline NAT configured on this box? Is it possible to share 
the config please?
It is quite easy to loop traffic with NAT (inline or not) and while 
looped inside same box,

TTL does not get decremented so You end up with eternal PFE saturation.

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

Re: [j-nsp] MX960 vs MX10K

[Alexander Arseniev via juniper-nsp]

--- Begin Message ---

Hello,
Ok , when saying "not stateful in any meaningful way" I believe You 
meant data plane encryption/decryption only - barebone IPSec without IKE 
exchange and without anti-replay, or do You?
And JUNOS BFD variant (c) requires "anchor PFE" - actually not the PFE 
as "forwarding chip" but "PFE" as short way of saying "linecard CPU that 
runs PPMD" which processes BFD packets from all linecards.

Thanks
Alex


-- Original Message --
From: "Saku Ytti" 
To: "Alexander Arseniev" 
Cc: "Juniper List" 
Sent: 05/03/2020 16:29:57
Subject: Re: Re[2]: [j-nsp] MX960 vs MX10K


On Thu, 5 Mar 2020 at 18:05, Alexander Arseniev  wrote:



 I would expect the "IPSEC anchor PFE", just like it is done with BFD et
 al a.t.m.
 That anchor PFE maintains IKE exchange sequences/anti-replay etc and any
 IKE/IPSec packet arriving on a different PFE would be redirected there.
 Same thing really what currently happens on a Services card.


I'm not sure what you mean by BFD here. BFD can be done in various ways

a) RPD
b) PPMd on RE CPU
c) PPMd on LC CPU
d) Inline on NPU

If you do it on d) it's done the NPU where the neighbour is, entirely
on the NPU.

And sure there is signalling in IPSEC, just like there is in BGP,
which is not done in hardware. But actual bit pushing is done in
hardware.


--
  ++ytti


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

Re: [j-nsp] MX960 vs MX10K

[Alexander Arseniev via juniper-nsp]

--- Begin Message ---


-- Original Message --
From: "Saku Ytti" 


IPSEC isn't stateful in any meaningful way If you can implement MACSec
it shouldn't take much more transistors to do IPSEC.


I always thought maintaining anti-replay counters/IKEv exchange 
sequences etc is a stateful job, just like TCP handshake/SEQ numbers, 
no?





Indeed current gen (post EA, i.e. ZT and YT) Trio does IPSEC in every port.

I would expect the "IPSEC anchor PFE", just like it is done with BFD et 
al a.t.m.
That anchor PFE maintains IKE exchange sequences/anti-replay etc and any 
IKE/IPSec packet arriving on a different PFE would be redirected there.

Same thing really what currently happens on a Services card.
Thanks
Alex




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

Re: [j-nsp] static arp with unnumbered-address

[Alexander Arseniev via juniper-nsp]

--- Begin Message ---

Hello,
So. this whole setup is built for saving 2 IP from each /26, correct?
If You reconsider and decide You can afford to waste 2/64 = 3% of Your 
IPv4 address estate, then on the face of it, looks like perfect use case 
for EVPN with its /32 routes auto-created from ARP.
You can assign multiple 1st IPs from multitude of /26 to each EVPN IRB 
interface with proper /26 netmask instead of tinkering with 
unnumbered-address.
And if You export these /32 into Your iBGP, the /32 will be routed to 
according to usual iBGP rules (local pref|metric etc).

Thanks
Alex

-- Original Message --
From: "Baldur Norddahl" 
To: "Juniper List" 
Sent: 13/02/2020 09:50:34
Subject: Re: [j-nsp] static arp with unnumbered-address


Hi Alex

Thanks for the reply. Ok I managed to make a bad example. This is actually
from our running configuration and all the routes are /32 routes. The issue
is that the customers have all been assigned IPv4 addresses from random
subnets. The subnets are usually sized /26 and the first address is
configured on the router loopback interface, such that customers can use it
as the default gateway using proxy arp.

The problem is that arp is not working correctly. When selecting the source
address for ARP requests, the router is picking a random IP address from
the loopback interface instead of the IP address from the subnet that
matches what the customer expects. This can be fixed by using:

family inet {
unnumbered-address lo0.1 preferred-source-address a.b.c.1;
}

However this does not fix the issue for customers having multiple IP
addresses assigned from different subnets. And they are usually using a
switch to connect multiple devices, so just routing IP address #2 to IP #1
is no good.

We come from another platform where this was not a problem. The other
platform (ZTE) would do the right thing and do ARP using the correct source
address without us needing to do anything. The IP addresses have been
assigned and used by the customers for years, so we can not just simply
change the allocation scheme. It seems Juniper is not truly into a world
where wasting addresses with old school /30 to a customer that only needs a
/32 is not working for us poor sods that were not born into plenty of IPv4.

Since I do not have any hopes for getting a fix for IP source selection for
ARP, I was thinking about ways to work around the problem. I believe I
could argue to the customers, that they need to register their MAC address
with us for each assigned IP. That way the router would not need to do ARP.
But apparently it is impossible to manually set static arp for interfaces
that use unnumbered-address.

Regards,

Baldur



Den tor. 13. feb. 2020 kl. 08.30 skrev Alexander Arseniev <
arsen...@btinternet.com>:


 Hello,
 Firstly, Your example configuration with static /24 routes and
 qualified-NH to IFL does not commit - even after fixing the host portion -
 with error message "subnet routes are not allowed with MAC NH".
 Secondly, You could have second static  198.51.100.0/24 resolve via 1st
 /32:
 set routing-instances internet routing-options static route 192.0.2.11/32
 qualified-next-hop et-0/0/0.2766
 set routing-instances internet routing-options static route
 198.51.100.0/24 next-hop 192.0.2.11 resolve
 Thanks
 Alex

 -- Original Message --
 From: "Baldur Norddahl" 
 To: "Juniper List" 
 Sent: 12/02/2020 23:04:37
 Subject: [j-nsp] static arp with unnumbered-address

 Hello

 How do you program in a static arp entry on an interface that is using
 family inet unnumbered-address ?

 Eg.:

 interface ps1 {
 unit 2766 {
 proxy-arp restricted;
 vlan-tags outer 402 inner 1016;
 family inet {
 unnumbered-address lo0.1;
 }
 }
 }
 routing instance internet routing-options {
 interface et-0/0/0.2766;
 static {
 route 192.0.2.11/24 {
 qualified-next-hop et-0/0/0.2766;
 }
 route 198.51.100.22/24 {
 qualified-next-hop et-0/0/0.2766;
 }

 It is not possible to have the juniper router do correct arp in this case.
 You can have the 192.0.2.0/24 range working or you can have the
 198.51.100.0/24 working using preferred source address but not both. So I
 figured I could get away with simply hard coding the arp entry. However
 static arp is in the family inet address subtree so can not be specified
 here. Seriously ?

 Regards,

 Baldur
 ___
 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


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

Re: [j-nsp] static arp with unnumbered-address

[Alexander Arseniev via juniper-nsp]

--- Begin Message ---

Hello,
Firstly, Your example configuration with static /24 routes and 
qualified-NH to IFL does not commit - even after fixing the host portion 
- with error message "subnet routes are not allowed with MAC NH".
Secondly, You could have second static  198.51.100.0/24 resolve via 1st 
/32:
set routing-instances internet routing-options static route 
192.0.2.11/32 qualified-next-hop et-0/0/0.2766
set routing-instances internet routing-options static route 
198.51.100.0/24 next-hop 192.0.2.11 resolve

Thanks
Alex

-- Original Message --
From: "Baldur Norddahl" 
To: "Juniper List" 
Sent: 12/02/2020 23:04:37
Subject: [j-nsp] static arp with unnumbered-address


Hello

How do you program in a static arp entry on an interface that is using
family inet unnumbered-address ?

Eg.:

interface ps1 {
unit 2766 {
proxy-arp restricted;
vlan-tags outer 402 inner 1016;
family inet {
unnumbered-address lo0.1;
}
}
}
routing instance internet routing-options {
interface et-0/0/0.2766;
static {
route 192.0.2.11/24 {
qualified-next-hop et-0/0/0.2766;
}
  route  198.51.100.22/24 {
qualified-next-hop et-0/0/0.2766;
}

It is not possible to have the juniper router do correct arp in this case.
You can have the 192.0.2.0/24 range working or you can have the
198.51.100.0/24 working using preferred source address but not both. So I
figured I could get away with simply hard coding the arp entry. However
static arp is in the family inet address subtree so can not be specified
here. Seriously ?

Regards,

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

Re: [j-nsp] Help with BGP as-path regex

[Alexander Arseniev via juniper-nsp]

--- Begin Message ---

Hello,

Does this help?

https://www.juniper.net/documentation/en_US/junos/information-products/topic-collections/release-notes/16.1/m-mx-t-series-toc.html 



Support for unique AS path count ( MX Series)—Starting with Junos OS 
Release 16.1R4, you can configure a routing policy to determine the 
number of unique autonomous systems (ASs) present in the AS path. The 
unique AS path count helps determine whether a given AS is present in 
the AS path multiple times, typically as prepended ASs. In earlier Junos 
releases it was not possible to implement this counting behavior using 
theas-pathregular expression policy. This feature permits the user to 
configure a policy based on the number of AS hops between the route 
originator and receiver. This feature ignores ASs in theas-paththat are 
confederation ASs, such asconfed_seqandconfed_set.


To configure AS path count, include theas-path-unique-countcount(equal | 
orhigher | orlower)configuration statement at the[edit policy-options 
policy-statementpolicy_namefrom]hierarchy level.



Thanks

Alex


On 13/09/2019 00:18, Andy Litzinger wrote:

Hi All,
   I thought this would be in a cookbook somewhere but I can't find it.  Is
there a way to write an as-path regex so it will match a providers ASN
(e.g. 1234) one or more times and then 1 or 2 more ASNs zero or more
times?  I'm hoping to be able to account for AS prepending.

I'm an Enterprise network and one of my upstream ISPs is sending me full
routes + default.  I want to filter the routes down to networks that are
directly connected or at most 2 hops away from my ISP, but also allow for
AS prepending.  It's the prepending that is tripping me up or else I think
this would suffice:  "^1234+ .{0,2}"

I think with cisco you can do this with backreferences, but Junos doesn't
seem to support those.

TIA,
  -andy
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
--- End Message ---
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] EVPN - BGP attribute propagation on MXes

[Alexander Arseniev via juniper-nsp]

Hello,

On 01/07/2019 15:38, Guillermo Fernando Cotone wrote:

Our use-case is to connect BGP islands through an EVPN backbone, and we
expect BGP attributes, such as communities, to be propagated over the
backbone. Pretty much standard IP-VPN behavior. Also referenced here:
https://tools.ietf.org/html/draft-rabadan-sajassi-bess-evpn-ipvpn-interworking-02#section-4.2

I'm not sure if this is actually supported on Juniper. We're
running 17.3R3-S2.2.


Are You terminating PE-CE BGP on IRB interface on PE side? This is 
supported from  19.2R1


https://www.juniper.net/documentation/en_US/junos/information-products/topic-collections/release-notes/19.2/jd0e4828.html#jd0e4903 



Thanks

Alex

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

Re: [j-nsp] Avoid transit LSPs

[Alexander Arseniev via juniper-nsp]

Hello,

On 25/01/2019 16:50, Luis Balbinot wrote:

Please let me know if you find some other approach.

The overload bit helps but in the absence of another path the RSVP FRR
mechanism will setup a bypass LSP through a node with the overload bit
set. And link coloring does not help, at least in my case.

Luis
This observation of Yours coupled with Your earlier statement about link 
metric being 65535 when You configure "overload" speaks of OSPF 
"overload" JUNOS feature/knob being used, not ISIS "Overload"/OL bit.


OSPF "overload" feature is drastically different from ISIS "Overload"/OL 
: OSPF "overload" is not actually a bit. It is a mock-up of what ISIS 
SPF does when it encounters an LSP with true OL bit set.


And this OSPF mock-up is very dissimilar and should not be called 
"overload" in 1st place.


Thanks

Alex


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

Re: [j-nsp] Junos Arp Expiration Timer Behavior & Active Flows

[Alexander Arseniev via juniper-nsp]

Hello,

Few more ARP tidbits for You:

1/ JUNOS learns ARP not only from responses but from requests as well - 
this is according to RFC 826 "Packet reception" chapter (ARP opcode is 
examined AFTER the xlation table is updated).  Therefore, You may see 
that ARP entry for the remote node is regularly refreshed on local node 
without any ARP requests being sent out from that local node. This could 
happen if the ARP randomized aging timers or clocks are different - and 
they normally are if only by a small amount.


2/ changing ARP aging-time does not take effect immediately, You need to 
wait until current entry ages out or clear it with CLI command.


3/ if You configure a static /32 route to with destination == nexthop - 
like set routing-options static route 203.0.113.1/32 next-hop 
203.0.113.1, which is a valid route in JUNOS and 203.0.113.1 must be 
directly connected - then the ARP entry for 203.0.113.1 is maintained by 
JUNOS in accordance with configured (or default) ARP aging timers 
without any traffic going to 203.0.113.1 as opposed to normal ARP 
behaviour where ARP is only resolved where there is a packet going to 
203.0.113.1.


HTH

Thx
Alex

On 11/01/2019 16:50, Clarke Morledge wrote:
According to KB19396, "the Address Resolution Protocol (ARP) 
expiration timer does not refresh even if there is an active traffic 
flow in the router. This is the default behavior of all routers 
running Junos OS." The default timer is 20 minutes. I have confirmed 
this behavior on the MX platform.


This does not seem very intuitive, as it suggests that a Junos device 
at L3 would stop in the middle of an active flow, to send an ARP 
request to try to refresh its ARP cache, potentially causing some 
unnecessary queuing of traffic, while the Junos device waits for ARP 
resolution. For an active flow, the ARP response should come back 
quick, but still it seems unnecessary.


I would have thought that the ARP cache would only start to decrement 
the expiration timer, when the device was not seeing any traffic 
to/from ARP entry host.


KB19396 goes onto say, "When the ARP timer reaches 20 (+/- 25%) 
minutes, the router will initiate an ARP request for that entry to 
check that the host is still alive." I can see that when the ARP timer 
is started initially, that it starts the expiration countdown, at this 
(+/- 25%) value, and not exactly at, say, 20 minutes, which is the 
default timer value.


A couple of questions:

(a) Is this default behavior across all Junos platforms, including MX, 
SRX, and EX?


(b) Is there any other caveat as to when the Junos device will send 
out the ARP request, at the end of expiration period?


Clarke Morledge
College of William and Mary
Information Technology - Network Engineering
Jones Hall (Room 18)
200 Ukrop Way
Williamsburg VA 23187
___
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] rate limiting per-user prefix lists

[Alexander Arseniev via juniper-nsp]

Hello,

Well, the prefix-action policers would likely relieve congestion on Your 
backhaul MW links but the 100Mbps "last mile" will still be congested, 
with a mix of good and bad packets.


And I would say more bad than good because good traffic (mainly HTTPS 
nowadays) will do TCP backoff at the early stage of congestion and bad 
packets (i.e. UDP flood) will fill the void in the 100Mbps policer buckets.


Have a look at the latest Juniper-Correro DDOS solution that detects the 
attack, finds the packet "fingerprint" & then drops only bad packets, 
and it's all automated


https://www.corero.com/resources/data-sheets/juniper-networks-solution-brief/ 



HTH

Thx
Alex

On 08/01/2019 18:58, mike+j...@willitsonline.com wrote:

Hi,

     My platform is Juniper mx240 running 15.1R6.7 and I'm interested in
using prefix-action to establish rate limits per user in my network.

     DDOS attacks targeting single users on my network can frequently
affect many users who happen to share the same backhaul connectivity
such as to rural communities served by microwave backhaul. We do a
certain amount of ddos filtering already, but we would like to tighten
this up some more and one idea was the use of prefix-action so that no
single user can be forwarded traffic which clearly they cannot handle.
In one case, I have a group of users that will not get over 100mbps of
service individually for example, perhaps it's 4 /24 subnets total in a
prefix-list called 'my100mbps-endusers'. It would be jim-dandy to guard
against traffic floods exceeding this 100mbps limit to any specific /32
in the group. So, I worked out this possible config:


[edit firewall]

family inet {

     prefix-action per-user-100mbps {
     policer ratelimit-100mbps;
     destination-prefix-length 32;
         subnet-prefix-length 24;

    }
}
filter per-user {
     term max-per-user {
     from {
     source-address {
     0.0.0.0/0;
     }
     destination-prefix-list {
     my100mbps-endusers;
     }
     }
     then prefix-action per-user-100mbps;
     }

}

What I am wondering is, a) is this stupid (and would you like some of
what I am smoking?) b) will I melt my router (along with my brain?) c)
is there a better strategy (and will judith marry anthony?) d) how
extensible would this be and could I consider scaling up to 10,000 users
this way?

Any comments, operational humor, or stack tracebacks concerning same are
appreciated. ;-)


Mike-


___
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] DDoS Protection on MX204

[Alexander Arseniev via juniper-nsp]

Hello,

Trio DDOS employs a hierarchy/chain of policers. Assuming flow detection 
is at default (and default==not configured), the first policer in a 
chain would be the FPC aggregate one, and it is 20Kpps by default.


Your 188K offered BGP traffic is therefore rate-limited OUT OF FPC to 
20Kpps.


And then RE aggregate policer kicks in, also at 20Kpps. Therefore, Your 
already-rate-limited BGP traffic is rate-limited second time with 
another 20Kpps policer and because of imperfect rate-limit by first FPC 
policer (instead of strictly 20Kpps it passed 22100 pps) the RE agg 
policer detected short-lived 1 sec violation.


As Saku mentioned, with default config the Trio DDOS is not doing much, 
You'd need to enable flow detection and then tune every single protocol 
policer in a chain because the default policers are either too generous 
or too strict.


Hope this makes sense

Thanks

Alex

On 04/01/2019 21:45, Jason Lixfeld wrote:



On Jan 4, 2019, at 3:06 PM, Jason Lixfeld  wrote:

Hi,

Before I go too far down the rabbit hole of looking into the DDoS Protection 
parent feature on MX, does anyone know if it’s supported on MX204?

So it’s a shallow rabbit hole; it’s enabled by default and after poking around 
with it a bit, it seems to be supported.

But, I’m seeing behaviour that doesn’t quite compute.

No RE filter configured, just the default DDoS protection.  Sending about 22k 
pps of bogus BGP packets.

FPC is in violation, but RE isn’t.  Remaining BGP sessions are still up.

jlixfeld@r# run show ddos-protection protocols bgp statistics
Packet types: 1, Received traffic: 1, Currently violated: 1
Protocol Group: BGP

   Packet type: aggregate
 System-wide information:
   Aggregate bandwidth is being violated!
No. of FPCs currently receiving excess traffic: 1
No. of FPCs that have received excess traffic:  1
Violation first detected at: 2019-01-04 16:13:28 EST
Violation last seen at:  2019-01-04 16:32:51 EST
Duration of violation: 00:19:23 Number of violations: 5
   Received:  67923912Arrival rate: 22925 pps
   Dropped:   46234805Max arrival rate: 190065 pps
 Routing Engine information:
   Aggregate policer is no longer being violated
Last violation started at: 2019-01-04 16:13:33 EST
Last violation ended at:   2019-01-04 16:13:34 EST
Duration of last violation: 00:00:01 Number of violations: 1
   Received:  21663099Arrival rate: 19952 pps
   Dropped:   0   Max arrival rate: 8 pps
Dropped by individual policers: 0
Dropped by aggregate policer:   0
 FPC slot 0 information:
   Aggregate policer is currently being violated!
Violation first detected at: 2019-01-04 16:13:29 EST
Violation last seen at:  2019-01-04 16:32:51 EST
Duration of violation: 00:19:22 Number of violations: 4
   Received:  67923912Arrival rate: 22925 pps
   Dropped:   46234805Max arrival rate: 190065 pps
Dropped by individual policers: 0
Dropped by aggregate policer:   46234805
Dropped by flow suppression:0
   Flow counts:
 Aggregation level Current   Total detected   State
 Subscriber0 0Active

[edit]
jlixfeld@r#

If I send 188k pps, RE is still not in violation, but BGP sessions die.

jlixfeld@r# run show ddos-protection protocols bgp statistics
Packet types: 1, Received traffic: 1, Currently violated: 1
Protocol Group: BGP

   Packet type: aggregate
 System-wide information:
   Aggregate bandwidth is being violated!
No. of FPCs currently receiving excess traffic: 1
No. of FPCs that have received excess traffic:  1
Violation first detected at: 2019-01-04 16:13:28 EST
Violation last seen at:  2019-01-04 16:24:13 EST
Duration of violation: 00:10:45 Number of violations: 5
   Received:  30565770Arrival rate: 188433 pps
   Dropped:   19208137Max arrival rate: 189414 pps
 Routing Engine information:
   Aggregate policer is no longer being violated
Last violation started at: 2019-01-04 16:13:33 EST
Last violation ended at:   2019-01-04 16:13:34 EST
Duration of last violation: 00:00:01 Number of violations: 1
   Received:  11423775Arrival rate: 19857 pps
   Dropped:   0   Max arrival rate: 22100 pps
Dropped by individual policers: 0
Dropped by aggregate policer:   0
 FPC slot 0 information:
   Aggregate policer is currently being violated!
Violation first detected at: 2019-01-04 16:13:28 EST
Violation last seen at:  2019-01-04 16:24:13 EST
Duration of violation: 00:10:45 Number of violations: 4
   Received:  30565770Arrival rate: 188433 pps
   Dropped:   19208137   

Re: [j-nsp] MX80 Input Scheduling/Shaping

[Alexander Arseniev via juniper-nsp]

Hello,
Egress scheduling/shaping on MIC ports - correct, that's why I said 
"roughly" equal.
Ingress scheduling/shaping  requires Q or EQ MPC which is not supported 
on MX80.

Thanks
Alex

-- Original Message --
From: sth...@nethelp.no
To: arsen...@btinternet.com; juniper-nsp@puck.nether.net
Sent: 05/10/2018 20:20:06
Subject: Re: [j-nsp] MX80 Input Scheduling/Shaping


Ingress scheduling is supported only on Q and EQ MPCs - Juniper MX
series book, 2nd ed, page 598.

MX80 COS capabilities are roughly equal to MPC1, without Q.


Disagree. MX80 does per-VLAN queuing/scheduling/shaping just fine for
ports on MICs. *Not* for the builtin 10G ports.

Steinar Haug, Nethelp consulting, sth...@nethelp.no


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

Re: [j-nsp] MX80 Input Scheduling/Shaping

[Alexander Arseniev via juniper-nsp]

Hello,

Ingress scheduling is supported only on Q and EQ MPCs - Juniper MX 
series book, 2nd ed, page 598.


MX80 COS capabilities are roughly equal to MPC1, without Q.

HTH

Thx

Alex


On 05/10/2018 11:21, Eric Van Tol wrote:

Hi all,
I've looked at the docs and can't find this, so maybe someone can point me in 
the right direction here. What are the limitations/restrictions on using input 
scheduling and shaping on the MX80 MICs? I have the 'traffic-manager mode 
ingress-and-egress' configured for the PIC and the following configured as a 
test in the CoS interfaces stanza:

 ge-1/2/4 {
 scheduler-map eth-egress;
 input-scheduler-map eth-egress;
 shaping-rate 50m;
 input-shaping-rate 50m;

While this commits fine sometimes, it seems that whenever I make certain 
changes to other parts of the config, completely unrelated to ge-1/2/4, I get a 
commit error:

admin@mx80# show | compare
[edit interfaces]
+   ge-1/2/5 { /* OMITTED */ };
[edit bridge-domains bd1]
  interface ge-1/2/4.1 { ... }
+interface ge-1/2/5.1;

[edit]
admin@mx80# commit check
[edit class-of-service interfaces ge-1/2/4 input-scheduler-map]
   'input-scheduler-map eth-egress'
 input scheduler map not allowed on interface ge-1/2/4
error: configuration check-out failed

[edit]
admin@mx80# rollback
load complete

[edit]
admin@mx80# commit check
configuration check succeeds

Sometimes I'll make a change, delete it, and the commit still won't work until 
I do a full rollback:

[edit]
admin@mx80# commit check
[edit class-of-service interfaces ge-1/2/4 input-scheduler-map]
   'input-scheduler-map eth-egress'
 input scheduler map not allowed on interface ge-1/2/4
error: configuration check-out failed

[edit]
admin@mx80# show | compare

[edit]
admin@mx80# rollback
load complete

[edit]
admin@mx80# commit check
configuration check succeeds

This particular MX80 is on 17.1R1.8, but production will likely just use 
whatever the recommended version is. What gives here? Are certain aspects of 
ingress CoS not supported by the MX80?

Thanks,
evt
___
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] PE-CE issue with OSPF routes not getting into routing table

[Alexander Arseniev via juniper-nsp]

Hello,

LSA  172.16.64.0   has DN-bit set : "Opt 0xa2" xlates to 1010 0010

https://tools.ietf.org/html/rfc4576#page-4

As to whether You want DN bit cleared (which is possible) to fix Your 
problem - please carefully review Your design and make an informed 
decision afterwards, not before.


HTH

Thx

Alex


On 26/08/2018 03:18, Raymond, Adam via juniper-nsp wrote:

Hi,

 Complex one, so I will try to describe this carefully.

 I have a IPv4 layer 3 MP-BGP VPN. There are two PEs that have an OSPF 
adjacency to CEs inside the VPN. The VPN only has a single OSPF area: 0.0.0.0. 
An external route, 172.16.64.0/20, is inserted into the VPN (called 
IP_ASC_VPN_1) via redistribution from iBGP and into OPSF.
 The slightly odd thing about this setup compared to a traditional VPN 
is that the PEs have devices connected to them that don't support dynamic 
routing - they are just node with a IP address and default gateway configured 
on them:

   PE3 -- CE5
   |
   P --P
   |   |
   P -- PE1 --OSPF-- CE1 --OSPF-- CE2 --OPSF-- CE3 --OSPF-- PE2 -- P
 |   |
NodeNode

All of this works when all of the network is up and operational, but when the 
link from the P routers to the PEs breaks:
   PE3 -- CE5
   |
   P --P
   |   |
   P -X- PE1 --OSPF-- CE1 --OSPF-- CE2 --OPSF-- CE3 --OSPF-- PE2 -- P
  |   |
 NodeNode

Then the Node closest to the break becomes unreachable from CE5. CE5 is also 
the router that inserts 172.16.64.0/20 into the VPN. I can log into PE1 by 
jumping from CE1 and see what is happening on that router. PE1 is still 
learning the 172.16.64.0/20 route via OSPF as you can see it in the OSFP 
database:
araymond@PE1> show ospf database external extensive lsa-id 172.16.64.0 instance 
IP_ASC_VPN_1
 OSPF AS SCOPE link state database
  Type   ID   Adv Rtr   Seq  Age  Opt  Cksum  Len
Extern   172.16.64.0  172.16.49.68 0x8001   192  0xa2 0xf2f1  36
   mask 255.255.240.0
   Topology default (ID 0)
 Type: 2, Metric: 3000, Fwd addr: 0.0.0.0, Tag: 208.0.255.152
   Aging timer 00:56:47
   Installed 00:03:06 ago, expires in 00:56:48
   Last changed 00:03:06 ago, Change count: 1

where 172.16.49.68 is the router-id of PE2.

The problem is that this route doesn't get added to the IP_ASC_VPN_1.inet.0 
routing table. There seems to be something that makes this route ineligible, 
but I cannot figure out what it is. Can anyone help me with that?

Regards,

Adam Raymond | IP Platform Engineering Team Lead

M: 0410 347 012   D: 03 8623 3638 | ext   E: 
adam.raym...@vocus.com.au
P: +61 3 8613   W: vocus.com.au
A: 333 Collins Street, Melbourne, VIC 3000, Australia  |  Follow us:



___
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] L3VPN/RR/PE on Same router

[Alexander Arseniev via juniper-nsp]

Hello,

Yes there is

https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/advertise-from-main-vpn-table-edit-protocols-bgp.html

Also, either don't configure "family route-target" on this combined 
PE/RR at all, or configure "family route-target advertise-default" in 
order to be able to receive routes from all VRFs in Your network.


HTH

Thanks

Alex


On 16/08/2018 15:39, tim tiriche wrote:

Hello,

I have a MPLS PE (L3VPN) router that is acting as full mesh iBGP within the
US.  The other routers in the US are not RR and regular iBGP.  This router
also acts as RR for Europe and takes in full BGP table.  Is there some
caveats to watch out for?
___
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] VRF export/import of eBGP learned route

[Alexander Arseniev via juniper-nsp]

Hello,

Does "no-prepend-global-as" help?

https://www.juniper.net/documentation/en_US/junos/topics/concept/bgp-local-as-introduction.html

HTH

Thx

Alex


On 29/06/2018 04:58, Aaron Gould wrote:

Use with caution in live environment as I'm going off of some testing I was
recently doing in my lab and I'm pretty sure I saw this same issue.

Sounds like something I saw with my internet boundary pe's, would add my AS
on routes were learned from internet and send as vpnv4 routes into my
internal ibgp environment and internal pe's were seeing their own AS and
routes were being hidden as looped...

Try this on PE1 

If pe1 ebgp group is called "ebgp-to-ix"...
If IX ip that you neighbor with is 1.2.3.4...
If vrf on PE1 and PE2 is called "my-vrf"...

...do this on PE1...
set routing-instances my-vrf protocols bgp group ebgp-to-ix neighbor 1.2.3.4
local-as private

...now see if PE2 is still seeing its own AS as looped

- Aaron


___
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