Re: [j-nsp] ACL for lo0 template/example comprehensive list of 'things to think about'?

[Michael Hare via juniper-nsp]

Martin-

Yes, we use the source-prefix-list autogenerated with external scripting based 
on config parsing of eBGP peers with ttl 255 set.  Below is what our BGP RE 
rules look like on a PE; it probably has its own problems deserving feedback.  
I show v4 but we have corresponding for v6.  

You can also see below I take shortcuts to reuse a single filter for deployment 
in global vs VPN vs LS, as always, "we could do better here".   In my example 
the source-prefix-lists starting with "^BGP-Peers" are JunOS apply-paths.  I 
think previously Saku [or others] made a case for treating RRs differently 
since it is known with an RR both ends of the BGP peer are under the same admin 
domain [ie, RR doesn't need to allow inbound initiation].  So the rules for an 
RR could be tighter than below.

-Michael

===/===

term BGP-ttl-security-allow-1 {
from {
source-prefix-list {
bgp_ttl_security-v4;
}
protocol tcp;
ttl 255;
source-port bgp;
destination-port 1024-65535;
}
then {
count :accept:tcp:bgp-ttl;
accept;
}
}
term BGP-ttl-security-reject-1 {
from {
source-prefix-list {
bgp_ttl_security-v4;
}
protocol tcp;
source-port bgp;
destination-port 1024-65535;
}
then {
count :discard:tcp:bgp-ttl;
discard;
}
}
term BGP-ttl-security-allow-2 {
from {
source-prefix-list {
bgp_ttl_security-v4;
}
protocol tcp;
ttl 255;
source-port 1024-65535;
destination-port bgp;
}
then {
count :accept:tcp:bgp-ttl;
accept;
}
}
term BGP-ttl-security-reject-2 {
from {
source-prefix-list {
bgp_ttl_security-v4;
}
protocol tcp;
source-port 1024-65535;
destination-port bgp;
}
then {
count :discard:tcp:bgp-ttl;
discard;
}
}
term BGP-Allow-1 {
from {
source-prefix-list {
BGP-Peers-v4;
BGP-Peers-v4-VPN;
BGP-Peers-v4-LS;
}
protocol tcp;
source-port bgp;
destination-port 1024-65535;
}
then {
count :accept:tcp:BGP;
accept;
}
}
term BGP-Allow-2 {
from {
source-prefix-list {
BGP-Peers-v4;
BGP-Peers-v4-VPN;
BGP-Peers-v4-LS;
}
protocol tcp;
source-port 1024-65535;
destination-port bgp;
}
then {
count :accept:tcp:BGP;
accept;
}
}


> -Original Message-
> From: juniper-nsp  On Behalf Of Martin
> Tonusoo via juniper-nsp
> Sent: Thursday, May 2, 2024 9:32 AM
> To: juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] ACL for lo0 template/example comprehensive list of 
> 'things to
> think about'?
> 
> Hi.
> 
> Thanks for the feedback and remarks. I have updated the RE filters:
> https://urldefense.com/v3/__https://gist.github.com/tonusoo/efd9ab4fcf2bb5a4
> 5d34d5af5e3f3e0c__;!!Mak6IKo!N5k2EhZxDwIf5W9ZpqDjz_jriaKLPB2zu5Q4Uv8F
> A80q0_LrJSqI5m95HP0NSSUcqOD1H-xllqhzwfvGwr1ZBq3Tw2I$
> 
> Few comments:
> 
> * I used the ephemeral range of 49160 - 65535 based on "sysctl
> net.inet.ip.portrange.first" and "sysctl net.inet.ip.portrange.last"
> on FreeBSD shell
> 
> * the "router-v4" was carried over from inet6 filters as I wanted to
> keep the v4 and v6 rules as identical as possible. It also helps to
> filter malformed packets addressed
> to multicast. For example TCP SYN packets addressed to dport 179 with
> destination IP set to 224.0.0.6
> 
> 
> Michael,
> 
> regarding the GTSM for BGP and related filters. Do you group the BGP
> neighbors into different prefix lists based on the expected TTL?
> Something like this:
> 
> root@vmx1> show configuration firewall family inet filter accept-bgp-v4
> term accept-bgp-ttl-255-v4 {
> from {
> source-prefix-list {
> /* adjacent BGP neighbors with TTL set to 255 */
> bgp-neighbors-ttl-255-v4;
> }
> destination-prefix-list {
> router-v4;
> }
> protocol tcp;
> ttl 255;
> destination-port bgp;
> }
> then {
> count accept-bgp-ttl-255-v4;
> accept;
> }
> }
> term accept-bgp-v4 {
> from {
> source-prefix-list {
> /* rest of the BGP neighbors */
> bgp-neighbors-v4;
> }
> destination-prefix-list {
> router-v4;
> }
> protocol tcp;
> destination-port bgp;
> }
> then {
> count accept-bgp-v4;
> accept;
> }
> }
> 
> root@vmx1>
> 
> 
> Martin
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://urldefense.com/v3/__https://puck.nether.net/mailman/listinfo/juniper-
> nsp__;!!Mak6IKo!N5k2EhZxDwIf5W9ZpqDjz_jriaKLPB2zu5Q4Uv8FA80q0_LrJSqI5
> m95HP0NSSUcqOD1H-xllqhzwfvGwr1ZPj6yIMU$

Re: [j-nsp] ACL for lo0 template/example comprehensive list of 'things to think about'?

[Michael Hare via juniper-nsp]

Martin,

Saku is illuminating how difficult it can be to effectively protected the 
control plane.   If I were to post our production RE filter I would likely be 
humbled with what I've overlooked as well.  Thanks for sharing for commentary 
and discussion.

Saku's comment about using router-ipv4 in combo with destination address seems 
obvious to me in hindsight, although I have it configured as well in some 
terms.  I think there is still use for that for things like VRRP, OSPF, LDP, 
BFD, IGMP and RSVP when matching source-prefix-list however?  I guess I should 
think more.

Another comment I would make is that you do not appear to have made provisions 
for support of GSTM for BGP.  For my IPv4 [and IPv6] filters I have six terms 
dedicated explicitly to trying to deal with BGP.  GTSM accept/reject near 
initiated vs far initiated + same for non GTSM.

You have the most important component; the end term is discard.  I chose to 
give up on 'log' on that long ago; too much noise, and only use it when I'm 
having troubles.  I do have a term that looks like this before my final discard 
however.  When these counters are non zero, my curiosity definitely gets piqued.

term interesting {
 from {
 source-prefix-list {
 sync_lists_p2p-v4
 sync_lists-all-loopbacks-v4;
 }
 destination-prefix-list {
 sync_lists-p2p-v4
 sync_lists-all-loopbacks-v4;
 }
 }
 then {
 count :count:interesting;
 inactive: log;
 }
 }

-Michael

> -Original Message-
> From: juniper-nsp  On Behalf Of Saku Ytti
> via juniper-nsp
> Sent: Sunday, April 28, 2024 11:15 AM
> To: Martin Tonusoo 
> Cc: adamv0...@netconsultings.com; juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] ACL for lo0 template/example comprehensive list of 
> 'things to
> think about'?
> 
> Some comments from quick read of just IPv4.
> 
> - I don't like the level of abstraction, seems it just ensures no one
> will bother reading it up and reuse of the filters and terms wont
> happen anyhow. It feels like first time learning OO language, and
> making everything modular, while adding overhead and abstraction for
> no value. Instead of having flat list, you have multiple filters in a
> list (which is internally concatenate in SW anyhow, into single fat
> list, so no HW benefit), not just that, but filters themselves refer
> to other filters.
> 
> 1) You should have two rules for TCP services, like BGP, inbound and
> outbound, instead just allowing far end to connect, and self-connect
> is handled by flags  This will allow far-end to hit any port they
> want, while it will not have SYN bit, it's still not safe. You could
> improve it, by defining DPORT in the connected check as ephemeral
> range the NOS uses
> 
> 2) OSPF can be TTL==1, not very important for security, tho
> 
> 3) traceroute and ping won't work, if router is the target DADDR and TTL > 1
> 
> 4) useless use of 'router-v4', if it hit lo0, it was for us. You'd
> need something like this in the edge filter, not lo0 filter. And in
> the edge filter it's still broken, because this is all LANs, not
> host/32.
> 
> 5) use of 'port' in NTP and other, this allows the far end to hit any
> port, by setting SPORT port to ntp
> 
> 6) no dport in DNS, every term should have DPORT, if we are
> connecting, it'll be ephemeral range, otherwise far end can hit any
> dport, by setting sport
> 
> 
> 
> 
> Some of these mistakes are straight from the book, like the useless
> level of abstraction without actual reuse and the insecure use of
> 'port'. But unlike the book, at least you have ultimate permit and
> then ultimate deny, which is important.
> 
> 
> On Sun, 28 Apr 2024 at 12:21, Martin Tonusoo  wrote:
> >
> > Hi.
> >
> > > In practical life IOS-XR control-plane is better protected than JunOS,
> > > as configuring JunOS securely is very involved, considering that MX
> > > book gets it wrong, offering horrible lo0 filter as does Cymru, what
> > > chance the rest of us have?
> >
> > I recently worked on a RE protection filter based on the examples
> > given in the "Juniper MX Series" book:
> >
> https://urldefense.com/v3/__https://gist.github.com/tonusoo/efd9ab4fcf2bb5a4
> 5d34d5af5e3f3e0c__;!!Mak6IKo!MQRlf-
> 9wNP2iWHZzeeyA7KIambMGev79eux2sjNd7RBXhagscC_PLFWLcG1x7grSrCvJGx
> QBrMo03dL_sIehI34dkQE$
> >
> > It's a tight filter for a simple network, e.g MPLS is not in use and
> > thus there are no filters for signaling protocols or MPLS LSP
> > ping/traceroute, routing instances are not in use, authentication for
> > VRRPv3 or OSPF is not in use, etc.
> >
> > Few differences compared to filters in the MX book:
> >
> > * "ttl-except 1" in "accept-icmp" filter was avoided by simply moving
> > the traceroute related filters in front of "accept-icmp" filter
> >
> > * "discard-extension-headers" filter in the book discards certain Next
> > Header values and allows the rest. I changed it in a way that only
> > 

Re: [j-nsp] L3VPNs and on-prem DDoS scrubbing architecture

[Michael Hare via juniper-nsp]

Alexandre,

Thanks for your emails.  I finally got around to trying it myself; it 
definitely works!  I first "broke" my A.B.C.D destination and =then= added a 
static.  When I reproduced this, instead of putting the static route into 
inet.0 I chose to install in my cleanVRF, which gets around the admin distance 
issues.  Any reason you install the routes in global instead of cleanVRF that 
I'm overlooking?

I'm curious to know how safe it is to rely on working in the future.  How long 
have you been using this trick?  I'll probably follow up with our Juniper 
support channels, as Saku suggests, maybe something even better can come out of 
this.

Thanks again,
-Michael

=/

@# run show route A.B.C.D 

inet.0: 933009 destinations, 2744517 routes (932998 active, 0 holddown, 360 
hidden)
+ = Active Route, - = Last Active, * = Both

A.B.C.D/32   *[BGP/170] 00:24:03, localpref 100, from 2.3.4.5
  AS path: I, validation-state: unverified
>  to 5.6.7.8 via et-0/1/10.3099

cleanVRF.inet.0: 319 destinations, 1179 routes (318 active, 0 holddown, 1 
hidden)
Limit/Threshold: 5000/4000 destinations
+ = Active Route, - = Last Active, * = Both 



A.B.C.D/32   *[Static/5] 00:07:36
>  to A.B.C.D via ae17.3347

@# run show route forwarding-table destination A.B.C.D 
Routing table: default.inet
Internet:
DestinationType RtRef Next hop   Type IndexNhRef Netif
A.B.C.D/32   user 0indr  1048588 3
  5.6.7.8  ucst  981 5 et-0/1/10.3099
A.B.C.D/32   dest 0 0:50:56:b3:4f:fe   ucst 1420 3 ae17.3347

Routing table: cleanVRF.inet

  
Internet:
DestinationType RtRef Next hop   Type IndexNhRef Netif
A.B.C.D/32   user 0 0:50:56:b3:4f:fe   ucst 1420 3 ae17.3347

> -Original Message-
> From: Alexandre Snarskii 
> Sent: Tuesday, April 2, 2024 12:20 PM
> To: Michael Hare 
> Cc: juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] L3VPNs and on-prem DDoS scrubbing architecture
> 
> On Tue, Apr 02, 2024 at 07:43:01PM +0300, Alexandre Snarskii via juniper-
> nsp wrote:
> > On Tue, Apr 02, 2024 at 03:25:21PM +, Michael Hare via juniper-nsp
> wrote:
> >
> > Hi!
> >
> > Workaround that we're using (not elegant, but working): setup a
> > "self-pointing" routes to directly connected destinations:
> >
> > set routing-options static route A.B.C.D/32 next-hop A.B.C.D
> 
> Forgot to note one thing: these self-pointing routes shall have
> preference of 200 (or anytning more than BGP's 170):
> 
> set routing-options static route A.B.C.D/32 next-hop A.B.C.D
> set routing-options static route A.B.C.D/32 preference 200
> 
> so, in case when traffic shall be diverted to scrubbing, bgp route
> will be active in inet.0 and static route will be active in cleanL3VPN:
> 
> s...@rt1.ov.spb> show route A.B.C.D/32
> inet.0: ...
> + = Active Route, - = Last Active, * = Both
> 
> A.B.C.D/32 *[BGP/170] 00:06:33, localpref 100
>   AS path: 65532 I, validation-state: unverified
> >  to Scrubbing via ae3.232
> [Static/200] 00:02:22
> >  to A.B.C.D via ae3.200
> 
> cleanL3VPN.inet.0: 
> + = Active Route, - = Last Active, * = Both
> 
> A.B.C.D/32 *[Static/200] 00:02:22
> >  to A.B.C.D via ae3.200
> 
> 
> and the corresponding forwarding entry:
> 
> Routing table: default.inet [Index 0]
> Internet:
> 
> Destination:  A.B.C.D/32
>   Route type: user
>   Route reference: 0   Route interface-index: 0
>   Multicast RPF nh index: 0
>   P2mpidx: 0
>   Flags: sent to PFE, rt nh decoupled
>   Nexthop: Scrubbing
>   Next-hop type: unicast   Index: 2971 Reference: 6
>   Next-hop interface: ae3.232
>   RPF interface: ae3.200
>   RPF interface: ae3.232
> 
> Destination:  A.B.C.D/32
>   Route type: destination
>   Route reference: 0   Route interface-index: 431
>   Multicast RPF nh index: 0
>   P2mpidx: 0
>   Flags: none
>   Nexthop: 0:15:17:b0:e6:f8
>   Next-hop type: unicast   Index: 2930 Reference: 3
>   Next-hop interface: ae3.200
>   RPF interface: ae3.200
> 
> [...]
> Routing table: cleanL3VPN.inet [Index 6]
> Internet:
> 
> Destination:  A.B.C.D/32
>   

Re: [j-nsp] L3VPNs and on-prem DDoS scrubbing architecture

[Michael Hare via juniper-nsp]

Saku, Mark-

Thanks for the responses.  Unless I'm mistaken, short of specifying a selective 
import policy, I think I'm already doing what Saku suggests, see relevant 
config snippet below.  Our clean VRF is L3VPN-4205.  But after I saw the lack 
of mac based next hops I started searching to see if there was a protocol other 
than direct that I wasn't aware of.  I intend to take a look at Alexandre's 
workaround to understand/test, just haven't gotten there yet.

I was able to get FBF via dirtyVRF working quickly in the meantime while I 
figure out how to salvage the longest-prefix approach.

-Michael

==/==

@ # show routing-options | display inheritance no-comments
...
interface-routes {
rib-group {
inet rib-interface-routes-v4;
inet6 rib-interface-routes-v6;
}
}
rib-groups {
rib-interface-routes-v4 {
import-rib [ inet.0 L3VPN-4205.inet.0 ];
}
...
rib-interface-routes-v6 {
import-rib [ inet6.0 L3VPN-4205.inet6.0 ];
}
...
}

> -Original Message-
> From: juniper-nsp  On Behalf Of
> Saku Ytti via juniper-nsp
> Sent: Wednesday, April 3, 2024 1:58 AM
> To: Mark Tinka 
> Cc: juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] L3VPNs and on-prem DDoS scrubbing architecture
> 
> On Wed, 3 Apr 2024 at 09:45, Saku Ytti  wrote:
> 
> > Actually I think I'm confused. I think it will just work. Because even
> > as the EgressPE does IP lookup due to table-label, the IP lookup still
> > points to egressMAC, instead looping back, because it's doing it in
> > the CleanVRF.
> > So I think it just works.
> 
> > routing-options {
> >   interface-routes {
> > rib-groups {
> >   cleanVRF {
> > import-rib [ inet.0 cleanVRF.inet.0 ];
> > import-policy cleanVRF:EXPORT;
> >  
> 
> This isn't exactly correct. You need to put the cleanVRF in
> interfacer-quotes and close it.
> 
> Anyhow I'm 90% sure this will just work and pretty sure I've done it.
> The confusion I had was about the scrubbing route that on the
> clean-side is already host/32. For this, I can't figure out a cleanVRF
> solution, but a BGP-LU solution exists even for this problem.
> 
> 
> --
>   ++ytti
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://urldefense.com/v3/__https://puck.nether.net/mailman/listinfo/junip
> er-nsp__;!!Mak6IKo!JQJvgDK7yNf4-
> 3MbfcDkWHvNajBUNxt3ZAC3DefzEkRkebYhpy3c7RX5em7pvvTJZrdrNKw79P
> QweWqGaJdIwLpkAng$
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] (No subject)

[Michael Hare via juniper-nsp]

Barry,

Thanks for the link.  I had to laugh at this: 'you are tired of arguing with 
your network architecture team (“we are here to transport packets” vs “the 
Internet firewall” ;-)'.   20 years later, that still rings awfully true for me.

This diagram accurately displays how I've built a dirtyVRF that can use either 
FBF or, these days, Flowspec to vrf redirection.  For example I have 5 ASBR and 
the inspection POC is only attached to a single POP.  FBF indeed works great 
and scales “good enough” if well designed.

-Michael

From: Barry Raveendran Greene 
Sent: Tuesday, April 2, 2024 11:30 AM
To: Michael Hare 
Cc: juniper-nsp@puck.nether.net
Subject: Re: (No subject)


Have you reviewed the MPLS Shunt work from the mid-2000s? David Smith figured 
this out with AT

[note: attachment removed by michael.hare, my outlook helpful tried to inline 
it.  See Barry’s original message]


On Apr 2, 2024, at 10:25, Michael Hare via juniper-nsp 
mailto:juniper-nsp@puck.nether.net>> wrote:
Hi there,

We're a US research and education ISP and we've been tasked for coming up with 
an architecture to allow on premise DDoS scrubbing with an appliance.   As a 
first pass I've created an cleanL3VPN routing-instance to function as a clean 
VRF that uses rib-groups to mirror the relevant parts of inet.0.   It is in 
production and is working great for customer learned BGP routes.  It falls 
apart when I try to protect a directly attached destination that has a mac 
address in inet.0.  I think I understand why and the purpose of this message is 
to see if anyone has been in a similar situation and has 
thoughts/advice/warnings about alternative designs.

To explain what I see, I noticed that mac address based nexthops don't seem to 
be copied from inet.0 into cleanL3VPN.inet.0.  I assume this means that 
mac-address based forwarding must be referencing inet.0 [see far below].   This 
obviously creates a loop once the best path in inet.0 becomes a BGP /32.  For 
example when I'm announcing a /32 for 1.2.3.4 out of a locally attached 
1.2.3.0/26, traceroute implies the packet enters inet.0, is sent to 5.6.7.8 as 
the nexthop correctly, arrives in cleanL3VPN which decides to forward to 
5.6.7.8 in a loop, even though the BGP /32 isn't part of cleanL3VPN [see 
below], cleanL3VPN Is dependent on inet.0 for resolution.  Even if I could copy 
inet.0 mac addresses into cleanL3VPN, eventually the mac address would age out 
of inet.0 because the /32 would no longer be directly connected.  If I want to 
be able to protect locally attached destinations so I think my design is 
unworkable, I think my solutions are

= use flowspec redirection to dirty VRF, keep inet.0 as clean and use flowspec 
interface filter-group appropriately on backbone interfaces [routing-options 
flow interface-group exclude, which I already have deployed correctly].  This 
seems easy but is less performant.
= put my customers into a customerVRF and deal with route leaking between 
global and customerVRF.  This is a well-known tactic but more complicated to 
approach and disruptive to deploy as I have to airlift basically all the 
customers to into a VRF to have full coverage.

For redirection, to date I've been looking at longest prefix match solutions 
due to the presumed scalability vs using flowspec.  I have an unknown amount of 
"always on" redirects I might be asked to entertain.  10?  100? 1000?  I'm 
trying to come up with a solution that doesn't rely on touching the routers 
themselves.  I did think about creating a normal [non flowspec] input firewall 
term on untrusted interfaces that redirects to dirty VRF based in a single 
destination prefix-list and just relying on flowspec for on demand stuff with 
the assumption one firewall term with let's say 1000 prefixes is more 
performant than 1000 standalone flowspec rules.   I think my solution is 
fundamentally workable but I don't think the purchased turnkey ddos 
orchestration is going to natively interact with our Junipers, so that is 
looked down upon, since it would require " a router guy " or writing custom 
automation when adding/removing always-on protection.  Seems technically very 
viable to me, I jus
t bring up these details because I feel like without a ton of effort VRF 
redirection can be made to be nearly as performant as longest prefix match.

While we run MPLS, currently all of our customers/transit are in the global 
table.  I'm trying to avoid solutions for now that puts the 1M+ RIB DFZ zone 
into an L3VPN; it's awfully big change I don't want to rush into especially for 
this proof of concept but I'd like to hear opinions if that's the best solution 
to this specific problem.  I'm not sure it's fundamentally different than 
creating a customerVRF, seems like I just need to separate the customers from 
the internet ingress.

My gut says "the best" thing to do is to create a customerVRF but it feels a 
bit complicated as I have to worry

[j-nsp] L3VPNs and on-prem DDoS scrubbing architecture

[Michael Hare via juniper-nsp]

Hi there,

We're a US research and education ISP and we've been tasked for coming up with 
an architecture to allow on premise DDoS scrubbing with an appliance.   As a 
first pass I've created an cleanL3VPN routing-instance to function as a clean 
VRF that uses rib-groups to mirror the relevant parts of inet.0.   It is in 
production and is working great for customer learned BGP routes.  It falls 
apart when I try to protect a directly attached destination that has a mac 
address in inet.0.  I think I understand why and the purpose of this message is 
to see if anyone has been in a similar situation and has 
thoughts/advice/warnings about alternative designs.

To explain what I see, I noticed that mac address based nexthops don't seem to 
be copied from inet.0 into cleanL3VPN.inet.0.  I assume this means that 
mac-address based forwarding must be referencing inet.0 [see far below].   This 
obviously creates a loop once the best path in inet.0 becomes a BGP /32.  For 
example when I'm announcing a /32 for 1.2.3.4 out of a locally attached 
1.2.3.0/26, traceroute implies the packet enters inet.0, is sent to 5.6.7.8 as 
the nexthop correctly, arrives in cleanL3VPN which decides to forward to 
5.6.7.8 in a loop, even though the BGP /32 isn't part of cleanL3VPN [see 
below], cleanL3VPN Is dependent on inet.0 for resolution.  Even if I could copy 
inet.0 mac addresses into cleanL3VPN, eventually the mac address would age out 
of inet.0 because the /32 would no longer be directly connected.  If I want to 
be able to protect locally attached destinations so I think my design is 
unworkable, I think my solutions are 

= use flowspec redirection to dirty VRF, keep inet.0 as clean and use flowspec 
interface filter-group appropriately on backbone interfaces [routing-options 
flow interface-group exclude, which I already have deployed correctly].  This 
seems easy but is less performant.
= put my customers into a customerVRF and deal with route leaking between 
global and customerVRF.  This is a well-known tactic but more complicated to 
approach and disruptive to deploy as I have to airlift basically all the 
customers to into a VRF to have full coverage.

For redirection, to date I've been looking at longest prefix match solutions 
due to the presumed scalability vs using flowspec.  I have an unknown amount of 
"always on" redirects I might be asked to entertain.  10?  100? 1000?  I'm 
trying to come up with a solution that doesn't rely on touching the routers 
themselves.  I did think about creating a normal [non flowspec] input firewall 
term on untrusted interfaces that redirects to dirty VRF based in a single 
destination prefix-list and just relying on flowspec for on demand stuff with 
the assumption one firewall term with let's say 1000 prefixes is more 
performant than 1000 standalone flowspec rules.   I think my solution is 
fundamentally workable but I don't think the purchased turnkey ddos 
orchestration is going to natively interact with our Junipers, so that is 
looked down upon, since it would require " a router guy " or writing custom 
automation when adding/removing always-on protection.  Seems technically very 
viable to me, I jus
 t bring up these details because I feel like without a ton of effort VRF 
redirection can be made to be nearly as performant as longest prefix match.

While we run MPLS, currently all of our customers/transit are in the global 
table.  I'm trying to avoid solutions for now that puts the 1M+ RIB DFZ zone 
into an L3VPN; it's awfully big change I don't want to rush into especially for 
this proof of concept but I'd like to hear opinions if that's the best solution 
to this specific problem.  I'm not sure it's fundamentally different than 
creating a customerVRF, seems like I just need to separate the customers from 
the internet ingress.

My gut says "the best" thing to do is to create a customerVRF but it feels a 
bit complicated as I have to worry about things like BGP/static/direct and will 
lose addPath [I recently discovered add-path and route-target are mutually 
exclusive in JunOS].  

My gut says "the quickest" and least disruptive thing to do is to go the 
flowspec/filter route and frankly I'm beginning to lean that way since I'm 
already partially in production and needed to have a solution 5 days ago to 
this problem :>

I've done all of these things before [flowspec, rib leaking] I think it's just 
a matter of trying to figure out the next best step and was looking to see if 
anyone has been in a similar situation and has thoughts/advice/warnings.

I'm talking about IPv4 below but I ack IPv6 is a thing and I would just do the 
same solution.

-Michael

===/===

@$myrouter> show route forwarding-table destination 1.2.3.4 extensive 
Apr 02 08:39:10
Routing table: default.inet [Index 0] 
Internet:

Destination:  1.2.3.4/32
  Route type: user  
  Route reference: 0   Route interface-index: 0   
  Multicast RPF nh index: 0 

Re: [j-nsp] Juniper publishes Release notes as pdf

[Michael Hare via juniper-nsp]

TLDR: Juniper: please keep the PDFs.  I like control-F.

I may need a lesson in remedial use of browsers, but I find the PDFs useful and 
I don't print them.  Do people really have the time to navigate/click on all of 
these hyperlinks, or am I missing an obvious way to control-F the entire 
release notes in the web?
Example:
https://www.juniper.net/documentation/us/en/software/junos/release-notes/22.4/junos-release-notes-22.4r1/index.html
 

-Michael

> -Original Message-
> From: juniper-nsp  On Behalf Of
> Andrey Kostin via juniper-nsp
> Sent: Monday, March 18, 2024 7:37 AM
> To: Joe Horton 
> Cc: Juniper Nsp 
> Subject: Re: [j-nsp] Juniper publishes Release notes as pdf
> 
> Thanks, Joe.
> 
> Right, pdf only for SR releases has been a while, but not very long, the
> change happened just few months ago. My personal preference would be to
> read html that can adapt to screen size, etc. Imo the value of pdf is to
> be able to print a paper copy, but it's hard to imagine that somebody
> would print release notes in the present time.
> 
> Kind regards,
> Andrey
> 
> Joe Horton via juniper-nsp писал(а) 2024-03-15 21:36:
> > Correct.
> >
> > SR releases – PDF only, and I think it has been that way a while.
> > R release – html/web based + PDF
> >
> > And understand, I’ll pass along the feedback to the docs team.
> >
> > Joe
> >
> >
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://urldefense.com/v3/__https://puck.nether.net/mailman/listinfo/junip
> er-
> nsp__;!!Mak6IKo!KwspzhVpA4H07DE07WwOX7O2Mcz02FfnRg1MEuPyGll8k
> uhy28xOFgROPz-6ojKOiKfVJ4bNsRh3o85dwy4jnaE8Nzc$
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Difference in "MX204" and "MX204-HW-BASE"?

[Michael Hare via juniper-nsp]

Richard just reports the news, and at risk of keeping this thread a live, I 
thought I'd give our real word experiences.

I've upgraded both newer "licensed based" mx204s and perpetual pre-sku-change 
mx204's to 22.4.  I can attest regardless I had no problems with BGP or 
anything else.  All of my chassis, licensed or not, claim to be missing 
licenses based on the output of 'show system license'.   For all of my chassis, 
there are/were  no chassis alarm indicating a problem, nor did I receive any 
syslogs indicating a missing license.

So calling the enforcement soft seems to be an understatement; I had to go out 
of my way to find out JunOS things I'm breaking the rules.  

We had purchased the activation codes for the licensed based mx204s that I sat 
on until 22.4, so I went through the Agile licensing portal hoops and applied a 
license to the ones that "I know" require a license per their new model

The whole process makes me wonder if I made a mistake and we're one step away 
from being locked out of our network.  Not a great experience.  I will probably 
follow Richard's advice and ask our SE what's supposed to happen "show system 
license" wise to my legacy mx204s.

-Michael

> -Original Message-
> From: juniper-nsp  On Behalf Of
> Richard McGovern via juniper-nsp
> Sent: Wednesday, January 10, 2024 4:03 PM
> To: EXT - giuli...@wztech.com.br ; Gert Doering
> 
> Cc: juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] Difference in "MX204" and "MX204-HW-BASE"?
> 
> Agree sort of. The SW should know if model was MX204 or MX204-P-BASE/
> MX204-HW-BASE. So it should know if need to enforce a license or not. The
> problem is that some MX204-P-BASE were sold as -IR or -R, etc. and some
> sold with Flex - Transition period.
> 
> There is no way for SW to know by which method a MX204-P-BASE was sold.
> So no way to know to enforce or not. That is one reason for "soft"
> enforcement. Customer (and Juniper Sales) can then determine which method
> was used, and get the customer a valid perpetual license at $0 so customer is
> good to go forever.
> 
> Now whether this approach is actually occurring, I don't know. I service my
> customer base like above on an as needed basis.
> 
> FYI only, Rich
> 
> Richard McGovern
> Sr Sales Engineer, Juniper Networks
> 978-618-3342
> 
> I'd rather be lucky than good, as I know I am not good
> I don't make the news, I just report it
> 
> 
> 
> 
> Juniper Business Use Only
> From: Giuliano C. Medalha 
> Date: Wednesday, January 10, 2024 at 4:49 PM
> To: Gert Doering , Richard McGovern
> 
> Cc: juniper-nsp@puck.nether.net 
> Subject: RE: [j-nsp] Difference in "MX204" and "MX204-HW-BASE"?
> [External Email. Be cautious of content]
> 
> 
> Good evening guys, how are you ?
> 
> If I can contribute a little.
> 
> Looking from a timeline standpoint... the MX204 passed:
> 
> - MX204 with -IR and R licenses ( which were perpetual )
> 
> - MX204-P-BASE ( Which was the transition box from -IR and -R to Flex License
> )
> 
> - MX204-HW-BASE ( Advanced and Premium Flex Licenses with 3 years or
> Perpetual )
> 
> Now on the JUNOS 22, Juniper starts requesting that the licenses hashes be
> installed in the box. However, from my point of view, the portal for 
> generating
> router licenses is not yet prepared to take an -IR or -R license and generate 
> it in
> the way that version 22 understands.
> 
> For example. If you bought an MX480/MPC7 ago with -IR and -R ... the
> JUNOS 22 will ask you to install the hash of a license to enforce the table's
> software (bgp, gre, etc). However, we still haven't figured out how to 
> generate
> an old MX480 or MX204 license for the new standard that JUNIPER is
> requiring in the JUNOS 22...
> 
> I think they forgot about that... somehow... and it will need to be resolved.
> 
> At.te
> 
> Giuliano
> 
> -Original Message-
> From: juniper-nsp  On Behalf Of Gert
> Doering via juniper-nsp
> Sent: Wednesday, January 10, 2024 6:46 PM
> To: Richard McGovern 
> Cc: juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] Difference in "MX204" and "MX204-HW-BASE"?
> 
> Hi,
> 
> On Wed, Jan 10, 2024 at 09:41:41PM +, Richard McGovern via juniper-
> nsp wrote:
> > Now, unknown to me (they don?t tell SEs any of this info either) there
> > could have been ?hard? enforcement added in some newer SW release ? RN
> > should point this out (stop laughing please!!!). Juniper internal have
> > discussed implementing ?hard? enforcement over the years, and with
> > potential change in product management (just happens) that view may
> > change. Can?t tell you yah or nah on hard enforcement.
> 
> If you do not have enough magenta coloured ink, no BGP for you...
> 
> gert
> --
> Gert Doering - Munich, Germany g...@greenie.muc.de
> 
> WZTECH is registered trademark of WZTECH NETWORKS.
> Copyright © 2023 WZTECH NETWORKS. All Rights Reserved.
> 
> IMPORTANTE:
> As informações deste e-mail e o conteúdo dos eventuais documentos anexos
> 

Re: [j-nsp] RSVP hidden routes in inet.0

[Michael Hare via juniper-nsp]

Hi Misak,

I think what you're seeing is normal for protection LSPs, "dirty hack on the 
control plane side", but I'm looking forward to be humbled on this list that my 
conclusion is incorrect.

We use "ldp interface link-protection dynamic-rsvp-lsp" and for all my bypass 
LSPs, 'show route hidden table inet.3 detail' tells me

Label-switched-path et-0/1/0.3402:BypassLSP->143.235.32.2
  ...
State: 
Inactive reason: Unusable path

I agree this is disconcerting if you are trying to get hidden routes to be 
zero, but there are other normal reasons for routes to be hidden such as 
rejection by bgp import policy.  Better IMHO to focus instead [or additionally] 
on " show route resolution unresolved "

-Michael

> -Original Message-
> From: juniper-nsp  On Behalf Of
> Misak Khachatryan via juniper-nsp
> Sent: Monday, December 11, 2023 7:03 AM
> To: juniper-nsp@puck.nether.net
> Subject: [j-nsp] RSVP hidden routes in inet.0
> 
> Hello,
> 
> Recently I implemented RSVP in my network, nothing so fancy - automesh and
> autobandwidth with node-link protection.
> 
> By doing final review i saw output of show route summary:
> 
> inet.0: 296 destinations, 298 routes (275 active, 0 holddown, 21 hidden)
>   Direct:  6 routes,  5 active
>Local:  5 routes,  5 active
> OSPF:265 routes,264 active
> RSVP: 21 routes,  0 active
>  LDP:  1 routes,  1 active
> 
> It is very curious for me why I see hidden RSVP routes in inet.0. It seems
> somehow related to bypass LSP's and how Juniper organises it. Here they are:
> 
> > show route protocol rsvp table inet.0 hidden
> 
> inet.0: 296 destinations, 298 routes (275 active, 0 holddown, 21 hidden)
> @ = Routing Use Only, # = Forwarding Use Only
> + = Active Route, - = Last Active, * = Both
> 
> 10.255.0.21/32  [RSVP] 01:11:54, metric 1
> >  to 10.255.0.226 via ae1.7, label-switched-path Bypass-
> >10.255.0.222->10.255.0.21
> 10.255.0.29/32  [RSVP] 1d 10:26:25, metric 1
> >  to 10.255.0.226 via ae1.7, label-switched-path Bypass-
> >10.255.0.230->10.255.0.29
> 10.255.0.33/32  [RSVP] 1d 10:26:25, metric 1
> >  to 10.255.0.226 via ae1.7, label-switched-path Bypass-
> >10.255.0.230->10.255.0.33
> 10.255.0.38/32  [RSVP] 1d 09:32:03, metric 1
> >  to 10.255.0.230 via ae4.7, label-switched-path Bypass-
> >10.255.0.222->10.255.0.38
> 10.255.0.70/32  [RSVP] 04:53:42, metric 1
> >  to 10.255.0.230 via ae4.7, label-switched-path Bypass-
> >10.255.0.226->10.255.0.70
> 10.255.0.73/32  [RSVP] 1d 10:26:21, metric 1
> >  to 10.255.0.226 via ae1.7, label-switched-path Bypass-
> >10.255.0.230->10.255.0.73
> 10.255.0.122/32 [RSVP] 1d 10:26:21, metric 1
> >  to 10.255.0.226 via ae1.7, label-switched-path Bypass-
> >10.255.0.230->10.255.0.122
> 10.255.0.126/32 [RSVP] 1d 10:26:41, metric 1
> >  to 10.255.0.226 via ae1.7, label-switched-path Bypass-
> >10.255.0.230->10.255.0.126
> 10.255.0.134/32 [RSVP] 1d 05:27:20, metric 1
> >  to 10.255.0.230 via ae4.7, label-switched-path Bypass-
> >10.255.0.222->10.255.0.134
> 10.255.0.174/32 [RSVP] 1d 07:19:25, metric 1
> >  to 10.255.0.230 via ae4.7, label-switched-path Bypass-
> >10.255.0.222->10.255.0.174
> 10.255.0.181/32 [RSVP] 1d 10:26:19, metric 1
> >  to 10.255.0.226 via ae1.7, label-switched-path Bypass-
> >10.255.0.230->10.255.0.181
> 10.255.0.185/32 [RSVP] 1d 10:26:19, metric 1
> >  to 10.255.0.226 via ae1.7, label-switched-path Bypass-
> >10.255.0.230->10.255.0.185
> 10.255.0.201/32 [RSVP] 1d 10:17:37, metric 1
> >  to 10.255.0.226 via ae1.7, label-switched-path Bypass-
> >10.255.0.222->10.255.0.201
> 10.255.0.214/32 [RSVP] 03:16:59, metric 1
> >  to 10.255.0.222 via ae0.7, label-switched-path Bypass-
> >10.255.0.226->10.255.0.214
> 10.255.0.222/32 [RSVP] 1d 10:17:34, metric 1
> >  to 10.255.0.230 via ae4.7, label-switched-path Bypass-
> >10.255.0.222
> 10.255.0.226/32 [RSVP] 02:45:52, metric 1
> >  to 10.255.0.222 via ae0.7, label-switched-path Bypass-
> >10.255.0.226
> 10.255.0.230/32 [RSVP] 1d 10:26:17, metric 1
> >  to 10.255.0.226 via ae1.7, label-switched-path Bypass-
> 

Re: [j-nsp] Hardware configuration for cRPD as RR

[Michael Hare via juniper-nsp]

I recognize Saku's recommendation of rib sharding is a practical one at 20M 
routes, I'm curious if anyone is willing to admit to using it in production and 
on what version of JunOS.  I admit to have not played with this in the lab yet, 
we are much smaller [3.5M RIB] worst case at this point.

-Michael

> -Original Message-
> From: juniper-nsp  On Behalf Of
> Saku Ytti via juniper-nsp
> Sent: Thursday, December 7, 2023 12:24 AM
> To: Thomas Scott 
> Cc: Vincent Bernat ; juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] Hardware configuration for cRPD as RR
> 
> From a RPD, not cRPD perspective.
> 
> - 64GB is certainly fine, you might be able to do with 32GB
> - Unless RRs are physically next to clients, you want to bump default
> 16kB TCP window to maximum 64kB window, and probably ask account team
> for window scaling support (unsure if this is true for cRPD, or if
> cRPD lets underlying kernel do this right, but you need to do same in
> client end anyhow)
> - You absolutely need sharding to put work on more than 1 core.
> 
> Sharding goes up-to 31, but very likely 31 is too much, and the
> overhead of sharding will make it slower than running lower counts
> like 4-8. Your core count likely shouldn't be higher than shards+1.
> 
> The sharding count and DRAM count are not specifically answerable, as
> it depends on what the contents of the RIB is. Do a binary search for
> both and measure convergence time, to find a good-enough number, I
> think 64/32GB and 4-8 cores are likely good picks.
> 
> On Wed, 6 Dec 2023 at 22:30, Thomas Scott via juniper-nsp
>  wrote:
> >
> > Also very curious in this regard.
> >
> > Best Regards,
> > -Thomas Scott
> >
> >
> > On Wed, Dec 6, 2023 at 12:58 PM Vincent Bernat via juniper-nsp <
> > juniper-nsp@puck.nether.net> wrote:
> >
> > > Hey!
> > >
> > > cRPD documentation is quite terse about resource requirements:
> > >
> > > https://www.juniper.net/documentation/us/en/software/crpd/crpd-
> deployment/topics/concept/crpd-hardware-requirements.html
> > >
> > > When used as a route reflector with about 20 million routes, what kind
> > > of hardware should we use? Documentation says about 64 GB of memory,
> but
> > > for everything else? Notably, should we have many cores but lower boost
> > > frequency, or not too many cores but higher boost frequency?
> > >
> > > There is a Day One book about cRPD, but they show a very outdated
> > > processor (Sandy Lake, 10 years old).
> > >
> > > Is anyone using cRPD as RR with a similar scale and can share the
> > > hardware configuration they use? Did you also optimize the underlying OS
> > > in some way or just use a stock configuration?
> > >
> > > Thanks.
> > > ___
> > > 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
> 
> 
> 
> --
>   ++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] MX304 - Edge Router

[Michael Hare via juniper-nsp]

Richard-

Sorry if this is off topic, but what's the use case for Base license on an MX?  
 Is it just to align the name of the licensing with EX and the ilk?  Are there 
significant customers using hardware as whitebox?  We've been Juniper customer 
since the m40 days and always routed with them.  Thoughts and feelings aside 
about price and licensing management aside, I always found it curious that 
someone would purchase an MX and not need even static routing.  Our ASNs ended 
up in the "Advanced" bucket, which was essentially equivalent for us to the old 
"base".

-Michael

> -Original Message-
> From: juniper-nsp  On Behalf Of
> Richard McGovern via juniper-nsp
> Sent: Wednesday, October 25, 2023 7:51 AM
> To: Saku Ytti ; Aaron Gould 
> Cc: Karl Gerhard ; juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] MX304 - Edge Router
> 
> Aaron, what version of Junos are you using on your MX304? This should NOT
> happen and if it did/is, then I suggest you open a Case with JTAC. Minimally
> your account team should be able to get you a temp license to work-around
> this until resolved.
> 
> The introduction of newer (well now like 2 years old) Flex licensing all newly
> purchased MX (which would include ALL MX304s) support only L2 in the base
> (free) license. For any L3 (even static) you require some additional level of
> license. For MX those levels are Base/Advanced/Premium -
> https://www.juniper.net/documentation/us/en/software/license/flex/flex-
> license-for-mx-series-routers-and-mpc-service-cards.pdf. Your local Partner or
> Juniper Sales team should be able to help with any questions in this area.
> 
> Flex License can be purchased on a Subscription (yearly) basis or Perpetual
> (matches older style) – this is similar/same for almost all vendors in current
> times.
> 
> Most (but not ALL!) Juniper license are currently “honor” based. This means
> features that require a license will NOT be turned off if the license is not
> present. Instead warning/error messages will be shown, which will [obviously]
> fill up your logs quickly  MACSec maybe one of those licenses which are
> NOT “honor” based; there are others as well. Of course, Perpetual licenses
> never expire  Subscription licenses have a built-in ‘safety zone’ of
> approximately 30 days after the subscription date expires. This is to provide
> time for renewal of the subscription for those that “forget” 
> 
> If you have an older subscription license which is no longer valid under newer
> Flex license structure, at renewal the license will automatically be 
> converted by
> Juniper internal renewals team to the new Flex license SKU, at same price as
> the older SKU, if there is a price [increase] difference.
> 
> One big advantage of the new Flex license structure is that these licenses are
> transferable. That is, these licenses are not permanently tied to a single 
> device
> SN. This also includes Perpetual Flex Licenses. In the Juniper Agile License 
> Portal
> (https://license.juniper.net/licensemanage/) where one turns a License SKU
> [Entitlement] into a Activation [code] which then is used to create the actual
> loadable license. Here one MUST associate the License with a SN, but that
> License can then be re-called (changed from Activation back to Entitlement)
> and then that Entitlement can be associated with a new SN. The license on the
> old SN is no longer valid.
> 
> As for current checks, Juniper is covered by EULA – End User License
> Agreement. In the future Juniper can (and is likely to) add additional
> enforcement checks into their SW – Just an FYI.
> 
> FYI only, Rich
> 
> 
> Richard McGovern
> Sr Sales Engineer, Juniper Networks
> 978-618-3342
> 
> I’d rather be lucky than good, as I know I am not good
> I don’t make the news, I just report it
> 
> 
> 
> 
> Juniper Business Use Only
> 
> On 10/25/23, 2:01 AM, "Saku Ytti"  wrote:
> On Tue, 24 Oct 2023 at 22:21, Aaron Gould via juniper-nsp
> mailto:juniper-nsp@puck.nether.net>>
> wrote:
> 
> > My MX304 trial license expired last night, after rebooting the MX304,
> > various protocols no longer work.  This seems more than just
> > honor-based... ospf, ldp, etc, no longer function.  This is new to me;
> > that Juniper is making protocols and technologies tied to license.  I
> > need to understand more about this, as I'm considering buying MX304's.
> 
> Juniper had assured me multiple times that they strategically have
> decided to NEVER do this. That it's an actual decision they've
> considered at the highest level, that they will not downgrade devices
> in operation. I guess 'reboot' is not in-operation?
> 
> Notion that operators are able to keep licenses up-to-date and valid
> is naive, we can't keep SSL certificates valid and we've had decades
> of time to learn, it won't happen. You will learn about the problem,
> when shit breaks.
> 
> The right solution would be a phone-home, and a vendor sales rep
> calling you 'hey you have expired licenses, let's solve 

Re: [j-nsp] MX304 - Edge Router

[Michael Hare via juniper-nsp]

Re: "In your specific case, the ports never worked, you had to procure a 
license, and the license never dies."

Here's a cool story.  At some point I migrated the perpetual 10G FPC2 SFP+ port 
license on our MX104s from the "request system license add" mantra to "set 
system license" so it was more easily manageable in the config.  The migration 
worked fine in the lab.  I was making the change in production batch using 
automation, using the model of "commit confirmed" followed in a bit with a 
"commit check".  I pushed a set of "commit confirmed" out and got distracted 
by.. something.  I missed the commit check.  The config rolled back, but guess 
what didn't roll back?  The "request system license add".  The SFP+ shut off.  
No truck rolls were needed but it did create a needless outage for some.  Going 
back to Saku's comment about SSL certs; never underestimate a human's ability 
to fail.

-Michael

> -Original Message-
> From: juniper-nsp  On Behalf Of
> Saku Ytti via juniper-nsp
> Sent: Wednesday, October 25, 2023 7:43 AM
> To: Aaron1 
> Cc: juniper-nsp 
> Subject: Re: [j-nsp] MX304 - Edge Router
> 
> On Wed, 25 Oct 2023 at 15:26, Aaron1 via juniper-nsp
>  wrote:
> 
> > Years ago I had to get a license to make my 10g interfaces work on my
> MX104
> 
> I think we need to be careful in what we are saying.
> 
> We can't reject licences out right, that's not a fair ask and it won't happen.
> 
> But we can reject licenses that expire in operation and cause an
> outage. That I think is a very reasonable ask.  I know that IOS XE for
> example will do this, you run out of license and your box breaks. I
> swapped out from CRS1k to ASR1k because I knew the organisation would
> eventually fail to fix the license ahead of expiry.
> 
> I'm happy if the device calls homes via https proxy, and reports my
> license use, and the sales droid tells me I'm not compliant with
> terms. Making it a commercial problem is fine, making it an acute
> technical problem is not.
> 
> 
> In your specific case, the ports never worked, you had to procure a
> license, and the license never dies. So from my POV, this is fine. And
> being absolutist here will not help, as then you can't even achieve
> reasonable compromise.
> 
> --
>   ++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] Q. Is anyone deploying TCP Authentication Option (TCP-AO) on their BGP peering Sessions?

[Michael Hare via juniper-nsp]

FWIW, I deployed it for iBGP on MX gear in 20.4 with no concerns for an ASN I 
manage.  No issues in our lab with a mix of 20.4, 21.2 and 22.4, all classic 
JunOS.  I haven't tried it any other scenario.

-Michael

> -Original Message-
> From: juniper-nsp  On Behalf Of Barry
> Greene via juniper-nsp
> Sent: Tuesday, September 26, 2023 7:50 PM
> To: juniper-nsp@puck.nether.net
> Subject: [j-nsp] Q. Is anyone deploying TCP Authentication Option (TCP-AO) on
> their BGP peering Sessions?
> 
> Hi Team,
> 
> Q. Is anyone deploying TCP Authentication Option (TCP-AO) on their BGP
> peering Sessions?
> 
> I’m not touching routers right now. I’m wondering if anyone has deployed,
> your experiences, and thoughts?
> 
> This is suppose to be the “replacement” for BGP MD5, ‘but’ I’m hearing …..
> 
> 1. The Vendors are not supporting yet. Which means a lot of older systems
> would not be able to support a BGP session with TCP-AO.
> 2. People have to tried is operationally.
> 
> Sharing you thoughts would be helpful …...
> 
> Thanks,
> 
> Barry
> ___
> 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

[j-nsp] experiences with MX ipfix active and inactive flow timeouts at 15s or lower?

[Michael Hare via juniper-nsp]

Anyone running with less than 30s ipfix active and inactive flow timeouts 
willing to share positive or negative experiences?  Our target platform is 
mx10003.

We've been running active 60 inactive 30 for quite some time and are looking to 
move closer to the known configuration floor of 10 for quicker flow based 
anomaly detection.  I've recently moved to a 30/30 stance.  I plot 
jnxOperatingCPU at 60s and couldn't see a change in the FPC graphs, which is 
where I think I'd expect to see a change if any?

Has anyone tried 10s or 15s and regretted it?  I'm not worried about the 
collector impacts; those are easy to mitigate by adding more resources.  I'm 
already pushing into TSDB output of commands like "show services accounting 
flow inline-jflow fpc-slot X" and "show services accounting errors inline-jflow 
fpc-slot X" to observe general effects of my changes such as flow table size, 
failed exports etc.

-Michael

=/==

example config:

services {
flow-monitoring {
version-ipfix {
template ipv4-ipfix {
flow-active-timeout 30;
flow-inactive-timeout 30;
template-refresh-rate {
packets 12;
seconds 60;
}
option-refresh-rate {
packets 12;
seconds 60;
}
ipv4-template;
}
template ipv6-ipfix {
flow-active-timeout 30;
flow-inactive-timeout 30;
template-refresh-rate {
packets 12;
seconds 60;
}
option-refresh-rate {
packets 12;
seconds 60;
}
ipv6-template;
}
}
}
}
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] port-mirror with source inside routing-instance type vrf

[Michael Hare via juniper-nsp]

Circling around on this, the solution was simple.  My ingress interface was on 
fpc1, my egress interface was on fpc0.  I attached the port-mirror-instance to 
fpc0.  The fix was to attach to fpc1.  The ingress and egress interfaces are 
both in the "instance-type vrf" RI.

Thanks to all who chimed in,
-Michael

> -Original Message-
> From: juniper-nsp  On Behalf Of
> Michael Hare via juniper-nsp
> Sent: Tuesday, October 11, 2022 11:04 AM
> To: Chuck Anderson ; juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] port-mirror with source inside routing-instance type vrf
> 
> Chuck,
> 
> Thanks for the suggestion.  I have tried it at least four ways; both with and
> without the static-arp entry and with egress interface in global and egress
> interface in VRF.  When I tried without static-arp, I forced mirror up with a
> ping from our mirroring device.  My fw counters imply > 100pps hitting the
> relevant firewall "then" clause.
> 
> @re0# run show forwarding-options port-mirroring
> Oct 11 11:00:33
> Instance Name: uwwhitewater
>   Instance Id: 3
>   Input parameters:
> Rate  : 1
> Run-length: 0
> Maximum-packet-length : 0
>   Output parameters:
> Family  State Destination  Next-hop
> inetupxe-0/0/4:2.3124  10.235.43.1
> 
> -Michael
> 
> > -Original Message-
> > From: juniper-nsp  On Behalf Of
> > Chuck Anderson via juniper-nsp
> > Sent: Tuesday, October 11, 2022 10:59 AM
> > To: juniper-nsp@puck.nether.net
> > Subject: Re: [j-nsp] port-mirror with source inside routing-instance type 
> > vrf
> >
> > Did you try creating a static ARP entry for the port mirroring destination?
> >
> > interfaces {
> > xe-0/0/4:2 {
> > vlan-tagging;
> > mtu 9192;
> > encapsulation flexible-ethernet-services;
> > unit 3124 {
> > description "mirror test";
> > vlan-id 3124;
> > family inet {
> > no-redirects;
> > no-neighbor-learn;
> > address 10.235.43.0/31 {
> > arp 10.235.43.1 mac 02:02:02:02:02:02;
> > }
> > }
> > }
> > }
> > }
> >
> > On Tue, Oct 11, 2022 at 02:37:47PM +, Michael Hare via juniper-nsp
> > wrote:
> > > show interfaces xe-0/0/4:2 | no-more
> > > enable;
> > > vlan-tagging;
> > > mtu 9192;
> > > encapsulation flexible-ethernet-services;
> > > ...
> > > ...
> > > unit 3124 {
> > > description "mirror test";
> > > vlan-id 3124;
> > > family inet {
> > > address 10.235.43.0/31;
> > > }
> > > }
> > ___
> > 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
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX204 FPC won't start after upgrade.

[Michael Hare via juniper-nsp]

Matt,

Are you hitting https://prsearch.juniper.net/problemreport/PR1629943 ?

-Michael

> -Original Message-
> From: juniper-nsp  On Behalf Of
> Matthew Crocker via juniper-nsp
> Sent: Sunday, October 16, 2022 4:39 PM
> To: juniper-nsp@puck.nether.net
> Subject: [j-nsp] MX204 FPC won't start after upgrade.
> 
> 
> I have an MX204 running 20.2R3-S5.6 current and I want to upgrade to
> something newer.When I do upgrade it goes through smoothly but the FPC
> will not come online.   It looks like an I2C error, may need a firmware 
> update.
> 
> So far I've tried to upgrade to:
> 
> junos-vmhost-install-mx-x86-64-21.4R2-S2.6.tgz
> junos-vmhost-install-mx-x86-64-22.2R1-S2.4.tgz
> 
> I'm pretty sure there is a new BSD version starting at 21 as well
> 
> I can downgrade back to 20.2.R3 and everything boots and works fine.
> 
> Has anyone had a similar issue?  Is there a firmware update I need to try to
> find?
> 
> Thanks
> 
> -Matt
> 
> ___
> 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] port-mirror with source inside routing-instance type vrf

[Michael Hare via juniper-nsp]

Chuck,

Thanks for the suggestion.  I have tried it at least four ways; both with and 
without the static-arp entry and with egress interface in global and egress 
interface in VRF.  When I tried without static-arp, I forced mirror up with a 
ping from our mirroring device.  My fw counters imply > 100pps hitting the 
relevant firewall "then" clause.

@re0# run show forwarding-options port-mirroring 
Oct 11 11:00:33
Instance Name: uwwhitewater   
  Instance Id: 3  
  Input parameters:
Rate  : 1
Run-length: 0
Maximum-packet-length : 0
  Output parameters:
Family  State Destination  Next-hop
inetupxe-0/0/4:2.3124  10.235.43.1

-Michael

> -Original Message-
> From: juniper-nsp  On Behalf Of
> Chuck Anderson via juniper-nsp
> Sent: Tuesday, October 11, 2022 10:59 AM
> To: juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] port-mirror with source inside routing-instance type vrf
> 
> Did you try creating a static ARP entry for the port mirroring destination?
> 
> interfaces {
> xe-0/0/4:2 {
> vlan-tagging;
>   mtu 9192;
>   encapsulation flexible-ethernet-services;
> unit 3124 {
>   description "mirror test";
>   vlan-id 3124;
> family inet {
> no-redirects;
> no-neighbor-learn;
> address 10.235.43.0/31 {
> arp 10.235.43.1 mac 02:02:02:02:02:02;
>     }
>         }
> }
> }
> }
> 
> On Tue, Oct 11, 2022 at 02:37:47PM +, Michael Hare via juniper-nsp
> wrote:
> > show interfaces xe-0/0/4:2 | no-more
> > enable;
> > vlan-tagging;
> > mtu 9192;
> > encapsulation flexible-ethernet-services;
> > ...
> > ...
> > unit 3124 {
> > description "mirror test";
> > vlan-id 3124;
> > family inet {
> > address 10.235.43.0/31;
> > }
> > }
> ___
> 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

[j-nsp] port-mirror with source inside routing-instance type vrf

[Michael Hare via juniper-nsp]

Hello,

Cluebats appreciated, I can contact JTAC on this but am trying to avoid the 
timesink of opening a case.

Topic is filter based port mirroring for family inet with the wrinkle being 
that I'm trying to mirror traffic from inside "instance-type vrf".   I've done 
this countless times before successfully [including today as a sanity check] 
with source being in global table.

So far I've tried putting the output interface both inside the same VRF and in 
global; no traffic seems to mirror.  What is the correct stance?  Yes, I've 
tried to prime the macaddr pump with ICMP from the mx10003 doing the mirroring.

I am aware of mirroring "family any" but am unsure if that applies here, as the 
source interface I am trying to mirror is edge of VRF and doesn't have family 
mpls on the logical interface of interest.

I'm confident the traffic I want to mirror is hitting my filter term based on 
incrementing counters.

Lightly sanitized config below. 


# I confirmed this is attached to the interface of question and counters are 
incrementing.
term mirror-2 {
then {
count :mirror:all;
port-mirror-instance uw;
next term;
}
}

show forwarding-options 
port-mirroring {
instance {
uw {
input {
rate 1;
}
family inet {
output {
interface xe-0/0/4:2.3124 {
next-hop 10.235.43.1;
}
}
}
}
}   


}


show chassis  
fpc 0 {
...
port-mirror-instance uw;
sampling-instance ins1;
}

show interfaces xe-0/0/4:2 | no-more 
enable;
vlan-tagging;
mtu 9192;
encapsulation flexible-ethernet-services;
...
...
unit 3124 {
description "mirror test";
vlan-id 3124;
family inet {
address 10.235.43.0/31;
}
}

and then I've put xe-0/0/4:2.3124 inside and outside the relevant 
routing-instance as tests.

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

Re: [j-nsp] bgp graceful-shutdown receiver

[Michael Hare via juniper-nsp]

Mark,

I was told by JTAC that the 19.1 default "'set protocols bgp graceful-shutdown 
receiver" does exactly that [blindly trusts 65535:0 as zero] for iBGP learned 
routes, but not eBGP.  Unless I'm daft that's not what their public 
documentation implies.

A set command that means "no really, I want 65535:0 to mean localpref=X for 
whatever group hierarchy I configure said feature" might be neat.  It would 
have saved me a few hours as I am a tool assisted CLI jockey, not fully pushing 
from a database.  But the ship has long since sailed as I ended up changing my 
import/export policies instead.  It was a worthwhile endeavor anyway as I also 
incorporated prepending and MEDs as part of our outbound shutdown approach.

Thanks for the reply,
-Michael

> -Original Message-
> From: juniper-nsp  On Behalf Of
> Mark Tinka via juniper-nsp
> Sent: Friday, May 6, 2022 7:49 AM
> To: juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] bgp graceful-shutdown receiver
> 
> 
> 
> On 4/18/22 17:24, Michael Hare via juniper-nsp wrote:
> > Hello,
> >
> > Is anyone using "bgp graceful-shutdown receiver" successfully out-of-the-
> box for eBGP peers without modifying their import policies to account for
> 65535:0?
> >
> > For example our production AS peers with lab AS over eBGP.  Import policy
> on the production side sets local preference.  "I was assuming" that the
> reception of 65535:0 would set localpref to 0 and that's not what I see.  JTAC
> is claiming this is expected and that any import policy that sets local
> preference will override having graceful-shutdown receiver enabled.
> >
> > Yes, I have confirmed gshut is enabled and I am indeed receiving 65535:0.
> If I change my import policy to match 65535:0 and set local pref to 0, it
> unsurprisingly works.  Thankfully I have disaggregated the terms that accept
> a route from those that set local preference so I'm just looking at a major
> annoyance instead of major pain, but I find this a bit unbelievable as a 
> default
> behavior.  But perhaps I'm missing the concept of why the hook to set
> localpref appears to be at start of policy evaluation and not after route
> acceptance inside RPD.
> 
> My understanding is that 65535:0 is "universally" accepted across eBGP
> neighbors to signal LOCAL_PREF=0. However, receiving operators need to
> setup the policy infrastructure to make that happen.
> 
> I'd find it rather odd if a vendor automatically changed the LOCAL_PREF
> to 0 for a route that shipped with 65535:0, without the operator
> specifically pre-defining the policy infrastructure to support that. I
> certainly wouldn't want that from my vendor.
> 
> Unless I am missing something...
> 
> 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

[j-nsp] bgp graceful-shutdown receiver

[Michael Hare via juniper-nsp]

--- Begin Message ---
Hello,

Is anyone using "bgp graceful-shutdown receiver" successfully out-of-the-box 
for eBGP peers without modifying their import policies to account for 65535:0?

For example our production AS peers with lab AS over eBGP.  Import policy on 
the production side sets local preference.  "I was assuming" that the reception 
of 65535:0 would set localpref to 0 and that's not what I see.  JTAC is 
claiming this is expected and that any import policy that sets local preference 
will override having graceful-shutdown receiver enabled.

Yes, I have confirmed gshut is enabled and I am indeed receiving 65535:0.   If 
I change my import policy to match 65535:0 and set local pref to 0, it 
unsurprisingly works.  Thankfully I have disaggregated the terms that accept a 
route from those that set local preference so I'm just looking at a major 
annoyance instead of major pain, but I find this a bit unbelievable as a 
default behavior.  But perhaps I'm missing the concept of why the hook to set 
localpref appears to be at start of policy evaluation and not after route 
acceptance inside RPD.

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

Re: [j-nsp] MX204 port 1G

[Michael Hare via juniper-nsp]

--- Begin Message ---
Just chimed in to agree with Tobias.  Speed 1g definitely needed.  Recently 
migrated from an mx104 to an mx204 with remote end being a different AS.   
Mx204 end was link up but remote end was not.  In our case the diff in 'show 
int $x' output implied that the mx104's default was auto-negotiation whereas 
the mx204 was ambiguous.  We added auto-negotiation to resolve our issue.

-Michael

> -Original Message-
> From: juniper-nsp  On Behalf Of
> Tobias Heister
> Sent: Friday, October 9, 2020 7:45 AM
> To: Łukasz Trąbiński ; Juniper List  n...@puck.nether.net>
> Subject: Re: [j-nsp] MX204 port 1G
> 
> Hi,
> 
> Am 09.10.2020 um 13:12 schrieb Łukasz Trąbiński:
> > In Lab I'm trying to set up 1G port on MX204.
> 
> You might need to play around with autoneg options. we have a working 1G
> LX SFP running on 18.4R1-S7 on MX204
> 
> in our case thats the gigether section:
> gigether-options {
>  no-flow-control;
>  no-auto-negotiation;
>  speed 1g;
> }
> 
> Not sure if the Flow Control stuff was mandatory, but without the no-auto-
> negotation the link was not useable. It might also help to check autoneg
> settings on the other end (if you have access).
> 
> --
> Kind Regards
> Tobias Heister
> ___
> 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] BGP output queue priorities between RIBs/NLRIs

[Michael Hare via juniper-nsp]

--- Begin Message ---
I'm quite interesting in this topic as I am in the same boat.  I have problems 
similar to Rob in 18.3R3.

We do have jtac support but I haven't contacted them; a time/priority issue so 
far.

- "show bgp output-scheduler" is empty without top-level "protocols bgp 
output-queue-priority" config, regardless of anything else
= same here, so I pasted a canonical top level from 
https://www.juniper.net/documentation/en_US/junos/topics/topic-map/bgp-route-prioritization.html]
= I'm not sure I get the significance of the defaults section if priority has a 
token assignment; what ends up in low/medium/high by default?  Is his related 
to assignment via policy-statement?

protocols {
bgp {
output-queue-priority {
expedited update-tokens 100;
priority 1 update-tokens 1;
priority 2 update-tokens 10;
..
..
priority 15 update-tokens 75;
priority 16 update-tokens 80;
defaults {
low priority 1;
medium priority 10;
high expedited;
}
}
}
}

Anyway, I tried the following under lab iBGP, for fun, to prioritize VPN-ish 
things before global [for us internet is NOT in VRF].

Group: iBGP-reflector-client-v4
family inet-vpn {
unicast {
output-queue-priority priority 10;
route-refresh-priority priority 4;
withdraw-priority priority 16;
}
}
family inet6-vpn {
unicast {
output-queue-priority priority 10;
route-refresh-priority priority 4;
withdraw-priority priority 16;
}
}
family evpn {
signaling {
output-queue-priority priority 11;
route-refresh-priority priority 5;
withdraw-priority expedited;
}
}


And output [below] is implying on the first nlri in the list has priority.  
Where is the priority output for evpn and inet6-vpn-unicast?  With this 
technique must you do a different group per NLRI?  

Lastly the lack of counters and reliance on gauges makes it really difficult to 
determine what is going .

@lab # run show bgp group output-queues iBGP-reflector-client-v4 
Group Type: InternalAS: 65400  Local AS: 65400
  Name: iBGP-reflector-client-v4 Index: 4  Flags: 
  Export: [ flowspec-advertise select-iBGP-reflector-routes next-hop-self 
accept-selected-routes ] 
  Options: 
  Holdtime: 0
  NLRI inet-vpn-unicast: 
OutQ: priority 10 RRQ: priority 4 WDQ: priority 16 

  Total peers: 2Established: 2
  $rrip1+179
  $rrip2+179
Table  Tot Paths  Act Paths SuppressedHistory Damp StatePending
inet.0   
 12  0
inetflow.0   
  0  0
bgp.l3vpn.0  
  6  0
bgp.l3vpn-inet6.0
  6  0
bgp.evpn.0   
 38  0
L3VPN-9105.inet.0
  1  0
L3VPN-9105.inet6.0   
  1  0
L3VPN-9104.inet.0
  1  0
L3VPN-9104.inet6.0   
  1  0
EVPN-9100.evpn.0 
 31  0
EVPN-9101.evpn.0 
  3  0
__default_evpn__.evpn.0 
  4  0

[FIN]

-Michael


> -Original Message-
> From: juniper-nsp  On Behalf Of Rob
> Foehl
> Sent: Monday, July 27, 2020 10:06 PM
> To: juniper-nsp@puck.nether.net
> Subject: [j-nsp] BGP output queue priorities between RIBs/NLRIs
> 
> Anyone know the secret to getting BGP output queue priorities working
> across multiple NLRIs?
> 
> Had trouble with EVPN routes getting stuck behind full refreshes of the v4
> RIB, often for minutes at a time, which causes havoc with the default DF
> election hold timer of 3 seconds.  Bumping those timers up to tens of
> minutes solves this, but... poorly.
> 
> The documentation[1] says:
> 
> "In the default configuration, that is, when no output-queue-priority
> configuration or policy that overrides priority exists, the routing
> protocol process (rpd) enqueues BGP routes into the output queue per
> routing information base (RIB). [...] While processing output queues, the
> BGP update code flushes the output queue for the current RIB 

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

[Michael Hare via juniper-nsp]

--- Begin Message ---
If you are absolutely certain you are not providing DHCP you could always set 
the punt rate to 1 and disable logging. 

Beware, this can be an awfully sharp sword.  Ask me how I know!

system {
ddos-protection {
protocols {
{$protocol} {
aggregate {
bandwidth 1;
burst 1;
flow-level-detection {
subscriber off;
logical-interface off;
}
no-flow-logging;

-Michael

> -Original Message-
> From: juniper-nsp  On Behalf Of
> Mike
> Sent: Tuesday, May 5, 2020 1:32 PM
> To: juniper-nsp@puck.nether.net
> 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] Trouble with 100G link MX204 <-> Dell S4100F-ON

[Michael Hare via juniper-nsp]

--- Begin Message ---
We haven't had 1G fiber problems yet, 18.3R3.  I've had intermittent success 
with SFP-T at 1G, but they are third party pluggables.

It sounds like you don't have a PR?  But in case you do, I'm sure many 
(including our network) would benefit.  

-Michael

> -Original Message-
> From: juniper-nsp  On Behalf Of
> Mark Tinka
> Sent: Friday, March 13, 2020 1:07 PM
> To: juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] Trouble with 100G link MX204 <-> Dell S4100F-ON
> 
> 
> 
> On 13/Mar/20 19:54, Chris Adams wrote:
> 
> > I'm using 1G optics on MX204 with 18.1.  Not sure why you need to go to
> > 19...
> 
> There are some that worked on 18, and others only worked on 19.
> 
> Could be where we got them from. Didn't have the time to work it out -
> 1Gbps optics are the exception on our end, not the rule.
> 
> Mark.
> ___
> 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] [EXT] firewall filter misses connected interface addresses

[Michael Hare via juniper-nsp]

--- Begin Message ---
Charles-

This may be off mark but you have tried removing and re-adding the filter to 
your lo0.0 or doing a commit full?

I have seen apply-groups inheritance issues in 16.1 that match the sort of 
issues you are having.  I have experienced them both in BGP and firewall 
filters.  For example, I used an apply-group for iBGP and I have seen changes 
inside the config group result in a mismatch between config and operational 
behavior after a commit.  Same deal with firewall filters.  I've seen it across 
all of my MX gear and I didn't see this behavior in 14.1.

At some point JTAC pointed me to this the following PR.  

https://prsearch.juniper.net/InfoCenter/index?page=prcontent=PR1357802 

I have seen the description of this PR change over time.  When I was first 
pointed to the PR it was all about vrf-import but now I see it has been 
expanded to other types of inheritance.  Personally I have NOT seen an RPD core 
with respect to this issue.  

I have been using 18.3R3 in my lab and haven't seen inheritance issues (yet?)

-Michael

> -Original Message-
> From: juniper-nsp  On Behalf Of
> Anderson, Charles R
> Sent: Monday, December 9, 2019 3:13 PM
> To: juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] [EXT] firewall filter misses connected interface 
> addresses
> 
> I use something like this so the same firewall filter is applied on all lo0.*
> interfaces of all VRFs and logical-systems:
> 
> set groups RE-FILTER logical-systems <*> interfaces lo0 unit <*> family inet
> filter input ROUTING-ENGINE
> set groups RE-FILTER logical-systems <*> interfaces lo0 unit <*> family inet6
> filter input ROUTING-ENGINE6
> set groups RE-FILTER interfaces lo0 unit <*> family inet filter input ROUTING-
> ENGINE
> set groups RE-FILTER interfaces lo0 unit <*> family inet6 filter input
> ROUTING-ENGINE6
> set apply-groups RE-FILTER
> 
> On Mon, Dec 09, 2019 at 05:10:01PM +0100, Andreas wrote:
> >  Hello Mike,
> >
> >  if you're using that lo0.0 in a routing-instance or use more than one
> >  loopback you could also run into these restrictions:
> >
> >  - If you configure Filter A on the default loopback interface and
> >  Filter B on the VRF loopback interface, the VRF routing instance uses
> >  Filter B.
> >
> >  - If you configure Filter A on the default loopback interface but do
> >  not configure a filter on the VRF loopback interface, the VRF routing
> >  instance does not use a filter.
> >
> >  - If you configure Filter A on the default loopback interface but do
> >  not even configure a VRF loopback interface, the VRF routing instance
> >  uses Filter A.
> >
> >  See
> >  https://www.juniper.net/documentation/en_US/junos/topics/usage-
> guidelines/vpns-configuring-logical-units-on-the-loopback-interface-for-
> routing-instances-in-layer-3-vpns.html
> >
> >
> >  BR
> >  Andreas
> >
> >  On Mon, 9 Dec 2019 15:46:38 +, Anderson, Charles R wrote:
> > > What hardware and software version?  There were some
> bugs/limitations
> > > with certain combinations.
> > >
> > > On Mon, Dec 09, 2019 at 07:42:02AM -0800, Mike wrote:
> > >> Hello,
> > >>
> > >> I have a problem getting junos to filter out admin access to my
> > >> router
> > >> from unauthorized addresses.
> > >>
> > >> I have some addresses bound to lo0.0 which I am advertising
> > >> internally
> > >> in my igp, and which are the 'official' addresses used for SNMP, SSH
> > >> and
> > >> BGP to the router.
> > >>
> > >> I have firewall filters also that limit access to these protocols
> > >> using
> > >> prefix lists and such, and these filters are applied to lo0.0. The
> > >> filters work and I can observe log messages for invalid accesses to
> > >> the
> > >> protocols from unauthorized ip addresses. HOWEVER, snmp/ssh/bgp
> > >> access
> > >> to other ip addresses bound on the router, such as ethernet
> > >> interface
> > >> addresses, are still being allowed. I thought, according to various
> > >> junos docs, that applying a filter to lo0.0 filters out packets
> > >> destined
> > >> locally to the box regardless of actual interface. Could use some
> > >> help.
> ___
> 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] Suggestions for Edge/Peering Router..

[Michael Hare via juniper-nsp]

--- Begin Message ---
Nikolas,

I have been running into "committed config doesn't match operational reality" 
issues with JunOS since at least 16.1.  I've seen this under protocol bgp, 
firewall filters, etc.

My issues appear apply-group related.  Are your affected BGP policies achieved 
via apply-group inheritance?   Do you use " system commit delta-export " or " 
system commit persist-groups-inheritance" ?

I was a bit skeptical but JTAC pointed me to PR1357802.  Public notes were not 
an exact match of my symptoms by any means (I was not experiencing RPD 
crashes), but the JTAC engineer implied that there were some more holistic 
apply-group fixes as part of this release.  Smoke might have been blown but we 
were targeting 18.X releases in our lab so it was easy to test.  

I haven't been able to reliability reproduce the problem in either release 
(16.x or 18.x) but at the same time I haven't had it recur in our 18.x lab so...

-Michael

> -Original Message-
> From: juniper-nsp  On Behalf Of
> Nikolas Geyer
> Sent: Sunday, September 22, 2019 6:27 PM
> To: juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] Suggestions for Edge/Peering Router..
> 
> I have to play devils advocate around “Right this inconsistency between
> configured and operational state in my opinion is THE biggest problem of XR”
> 
> Have had this problem occur multiple times in Junos, as recently as Junos 17,
> where what was being advertised did not reflect configured policy. Worse
> still, the only recovery was complete deletion of the policy (and any peers
> using it) then re-adding it.
> 
> So it’s definitely not a XR only problem.
> 
> Sent from my iPhone
> 
> On Sep 19, 2019, at 8:11 AM, "adamv0...@netconsultings.com"
>  wrote:
> 
> >> From: Saku Ytti 
> >> Sent: Thursday, September 19, 2019 12:33 PM
> >>
> >>> On Thu, 19 Sep 2019 at 14:22,  wrote:
> >>>
> >>> Just a few examples when you change export policy it resets the peer
> >>> or the cockup with RR clearing all sessions or the fact BGP is part of
> >>> very complex RDP monolith -to me that's not really "carrier grade"
> >>> implementation
> >>
> >> This happens when export policy breaks update-group. It may sometimes
> be
> >> difficult for operator to understand if it will do that or not, so it's 
> >> fair
> concern.
> >> Perhaps system should not clear, but tell manual clear is needed for policy
> >> change to take effect.
> >>
> > Ideally I'd like to see equivalent of Cisco's dynamic update peer-groups in
> Junos.
> >
> >> If monolith is good or bad, I'm not sure. If you thread you have high
> >> performance with some risk. If you have process separation you have IPC
> >> problem, and you have low performance and many will solve this by
> >> duplicating state. Junos is moving towards multi process model with Junos
> >> Evolved, if this will be positive or negative direction remains to be seen.
> >>
> > I like where XR and Junos Evolved is heading,
> > In future I'd like to have the option to install only stuff I need on a 
> > particular
> type of node/deployment and not worry about the rest all the way to being
> able to mix and match protocols of different vendors.
> > Although cRPD is also interesting development pathway, but again cBGP
> would be even better :)
> >
> >> Operationally speaking, BGP in JunOS for us works great, on IOS-XR right
> now
> >> we have sessions where policy isn't what is configured and there is no
> way to
> >> verify which one, and we've propagated leaks because acting
> configuration
> >> isn't the one we've configured. We've not had similar problems in JunOS.
> This
> >> is anecdote, not data.
> >>
> > Right this inconsistency between configured and operational state in my
> opinion is THE biggest problem of XR, I'm afraid it has to be something
> fundamental since they haven't been able to consistently address these
> inconsistencies across the board for years now (or ASR9k HW? Not sure if
> these types of issues can be experienced on other platforms).
> > Though usually it's CP state does not trickle down to DP
> correctly/completely where what you described seems to be CP only.
> >
> > adam
> >
> > ___
> > 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] EVPN - BGP attribute propagation on MXes

[Michael Hare via juniper-nsp]

Hello Guillermo-

I had a somewhat similar issue.  For me I was trying to add a normal bgp 
community in vrf-export to an E-VPN instance.   This config caused RPD core 
dumps in 18.2 although it worked as I had hoped in 16.1.  JTAC reported at the 
time: "... using vrf-export in EVPN instance with non-rt target is not yet 
supported. Please don’t use it until it is officially targeted at 19.4 ... "

-Michael

> -Original Message-
> From: juniper-nsp  On Behalf Of
> Guillermo Fernando Cotone
> Sent: Wednesday, July 3, 2019 4:16 AM
> To: Alexander Arseniev 
> Cc: Juniper List 
> Subject: Re: [j-nsp] EVPN - BGP attribute propagation on MXes
> 
> Hi Alexander,
> 
> Not really.
> BGP route propagation works and some attributes are preserved, e.g. as-
> path
> and local-preference, but not the attached communities.
> It looks like they are doing implicitly —in juniper syntax— "then community
> *set* EVPN-EXT-COMM" instead of "*add*" while importing BGP routes into
> EVPN
> .
> 
> Best,
> Guillermo
> 
> On Wed, Jul 3, 2019 at 10:55 AM Alexander Arseniev
> 
> wrote:
> 
> > 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
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] RSVP-TE broken between pre and post 16.1 code?

[Michael Hare via juniper-nsp]

Adam-

Have you accounted for this behavioral change?

https://kb.juniper.net/InfoCenter/index?page=content=KB32883=print=LIST==currentpaging

-Michael

> -Original Message-
> From: juniper-nsp  On Behalf Of
> adamv0...@netconsultings.com
> Sent: Friday, June 28, 2019 9:16 AM
> To: juniper-nsp@puck.nether.net
> Subject: [j-nsp] RSVP-TE broken between pre and post 16.1 code?
> 
> Hi gents,
> 
> Just wondering if anyone experienced RSVP-TE incompatibility issues when
> moving from pre 16.1 code to post 16.1 code.
> Didn't get much out of Juniper folks thus far so I figured I'll ask here as
> well.
> 
> The problem we're facing is that in case 17 code is LSP head-end and 15 code
> is tail-end works, but in the opposite direction 17/15-to-17 (basically
> cases where 17 is the LSP tail-end) the LSP signalling fails.
> Trace reveals that the 17 gets the PATH message for bunch of LSPs, accepts
> it (yes reduction and acks are used), creates the session, then deletes it
> right away for some reason.
> Our testing suggests there are two workarounds for this:
> You might be aware that in 16.1 among other RSVP-TE changes the default
> refresh-time (governing generation of successive refresh messages
> Path/Resv)
> changed to 1200s -so no what you think making it 1200 on 15 side wont do, it
> has to be less (e.q. 1999s).
> If you want to keep refresh time at 1200 or higher then another option
> strangely enough is to disable CSPF on the affected LSPs (didn't know that
> SPF/CSPF changes contents of the PATH msg that in one case 17 code is cool
> with PATH msg in other case not).
> 
> Would appreciate any pointers.
> 
> 
> adam
> 
> 
> ___
> 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] Hyper Mode on MX

[Michael Hare via juniper-nsp]

Replying to myself before someone else catches my egregious error...  

After going back to review what I actually did vs what I thought I did when 
enabling hyper-mode, I very much got it backwards re icmp redirects.  You have 
to allow redirects to be sent to use hyper-mode.  That's a step backwards and a 
calculated risk to take.  I disallow ICMP redirects via firewall filter.

I'm academically curious why this is a requirement (allow icmp redirects to be 
sent) of hyper-mode. 

-Michael

> -Original Message-
> From: juniper-nsp  On Behalf Of
> Michael Hare via juniper-nsp
> Sent: Saturday, March 9, 2019 4:23 PM
> To: Saku Ytti 
> Cc: juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] Hyper Mode on MX
> 
> Saku/Franz-
> 
> I admit I didn't know what vlan padding was going into enabling hyper mode
> (or frankly even this conversation) and made an educated guess at relative
> safety at the time based on lab work (simplified production test) and a slow
> production roll out.
> 
> In case of the hyper mode feature, it looks like Juniper docs now do a better
> than average job explaining constraints.
> 
> Sorry if this URL was already shared in this thread
> https://www.juniper.net/documentation/en_US/junos/topics/reference/g
> eneral/hypermode-unsupported-commands.html
> 
> In this case, Franz, it appears you would have had to had configured "set
> interfaces interface-name gigether-options pad-to-minimum-frame-size"
> and that the commit parser wouldn't even let you try to enable hyper-mode
> if you had it set.   In fact, I do remember being forced to add "set system 
> no-
> redirects" to our config at the time.  I say forced but in reality it was a 
> good
> change to make at any rate.  I think I verified this one with lo0 counters
> (memory is failing me) to make sure I could safely add without changing
> expected behavior.
> 
> -Michael
> 
> > -Original Message-
> > From: Saku Ytti 
> > Sent: Friday, March 8, 2019 11:11 AM
> > To: Michael Hare 
> > Cc: Franz Georg Köhler ; juniper-
> n...@puck.nether.net
> > Subject: Re: [j-nsp] Hyper Mode on MX
> >
> > Hey Michael,
> >
> > > I have used successfully used hyper mode on MPC4E in M2K for a few
> > years with little regrets.   I chose to do this as I didn't have the 
> > equipment
> to
> > do line rate testing and I do a significant amount of counters on untrusted
> > ports.  As others have suggested, you need to know feature limitations.
> We
> > certainly do .1q as well as double tagging so the vlan padding feature is 
> > not
> > what you think it is.
> >
> > What do you and Franz think it is? What I think it is
> >
> > a) IP packet comes in to a router, and the packet is 41B or smaller
> > b) router sends the IP packet out via VLAN encapped interface, adding
> > VLAN to the 41B, for packet of 45B
> > c) 45B is invalid ethernetII payload size, frame may get dropped in L2
> > transport
> >
> > I read hypermode as victim of Trio's success. Juniper has been able to
> > use same microcode for over decade now. Obviously after 10 years of
> > development any code base is in dire need of spring cleaning. But you
> > can't fix code without breaking code. So I think hypermode is just
> > Juniper's strategy to rewrite Trio microcode and pay up some technical
> > debt they have, but in a way that they release it to the market
> > staggered, without single flag day.
> > You could say Cisco is doing the same right now, because in ASR9k
> > history first time are introducing non-microcode compatible lookup
> > engine, forcing them to rewrite all forwarding plane code. Just JNPR
> > isn't forced to do it, they just choose to do it.
> >
> > --
> >   ++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] Hyper Mode on MX

[Michael Hare via juniper-nsp]

Saku/Franz-

I admit I didn't know what vlan padding was going into enabling hyper mode (or 
frankly even this conversation) and made an educated guess at relative safety 
at the time based on lab work (simplified production test) and a slow 
production roll out.

In case of the hyper mode feature, it looks like Juniper docs now do a better 
than average job explaining constraints. 

Sorry if this URL was already shared in this thread
https://www.juniper.net/documentation/en_US/junos/topics/reference/general/hypermode-unsupported-commands.html

In this case, Franz, it appears you would have had to had configured "set 
interfaces interface-name gigether-options pad-to-minimum-frame-size" and that 
the commit parser wouldn't even let you try to enable hyper-mode if you had it 
set.   In fact, I do remember being forced to add "set system no-redirects" to 
our config at the time.  I say forced but in reality it was a good change to 
make at any rate.  I think I verified this one with lo0 counters (memory is 
failing me) to make sure I could safely add without changing expected behavior.

-Michael

> -Original Message-
> From: Saku Ytti 
> Sent: Friday, March 8, 2019 11:11 AM
> To: Michael Hare 
> Cc: Franz Georg Köhler ; juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] Hyper Mode on MX
> 
> Hey Michael,
> 
> > I have used successfully used hyper mode on MPC4E in M2K for a few
> years with little regrets.   I chose to do this as I didn't have the 
> equipment to
> do line rate testing and I do a significant amount of counters on untrusted
> ports.  As others have suggested, you need to know feature limitations.  We
> certainly do .1q as well as double tagging so the vlan padding feature is not
> what you think it is.
> 
> What do you and Franz think it is? What I think it is
> 
> a) IP packet comes in to a router, and the packet is 41B or smaller
> b) router sends the IP packet out via VLAN encapped interface, adding
> VLAN to the 41B, for packet of 45B
> c) 45B is invalid ethernetII payload size, frame may get dropped in L2
> transport
> 
> I read hypermode as victim of Trio's success. Juniper has been able to
> use same microcode for over decade now. Obviously after 10 years of
> development any code base is in dire need of spring cleaning. But you
> can't fix code without breaking code. So I think hypermode is just
> Juniper's strategy to rewrite Trio microcode and pay up some technical
> debt they have, but in a way that they release it to the market
> staggered, without single flag day.
> You could say Cisco is doing the same right now, because in ASR9k
> history first time are introducing non-microcode compatible lookup
> engine, forcing them to rewrite all forwarding plane code. Just JNPR
> isn't forced to do it, they just choose to do it.
> 
> --
>   ++ytti
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Hyper Mode on MX

[Michael Hare via juniper-nsp]

Franz-

I have used successfully used hyper mode on MPC4E in M2K for a few years with 
little regrets.   I chose to do this as I didn't have the equipment to do line 
rate testing and I do a significant amount of counters on untrusted ports.  As 
others have suggested, you need to know feature limitations.  We certainly do 
.1q as well as double tagging so the vlan padding feature is not what you think 
it is.

Re MX204, I read that line rate thread differently.  I thought hypermode 
actually increased PPS on the ingress processing side but I 100% agree that 
hypermode does NOT affect the WO queue difference on the MX204.  So in short I 
think there is some benefit in enabling hypermode on MX204 but not the full 
benefit of a native MPC7 if you have a especially complex ingress ACL policy?

-Michael

> -Original Message-
> From: juniper-nsp  On Behalf Of
> Franz Georg Köhler
> Sent: Thursday, March 7, 2019 3:40 AM
> To: juniper-nsp@puck.nether.net
> Subject: [j-nsp] Hyper Mode on MX
> 
> Hello,
> 
> I wonder if it is gererally a good idea to enable HyperMode on MX or if
> there are reasons not do do so?
> 
> We are currently running MX960 with FPC7.
> 
> 
> Best regards,
> 
> Franz Georg Köhler
> ___
> 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