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

Re: [j-nsp] MX104 and NetFlow - Any horror story to share?

[Michael Hare]

Alain,

Do you want to collect IPv6?  You are probably passed 14.X code on MX104 but I 
observed that I was unable to change the ipv6-flow-table-size at all (including 
after reboot).  I was able to set flow-table-size in 16.X but my load average 
on 16.X on MX104 is pretty terrible; seems like I got all of the performance 
penalty of threading in 16.X without an additional core unlocked on the MX104 
RE.  Since 14.X is near EOL I didn't harass JTAC.

Thanks and a nod to Olivier, I hadn't seen "flex-flow-sizing" before, seems 
like I really wanted that, not the explicit flow-table-size commands.

abbreviated code example below.

chassis {
afeb {
slot 0 {
inline-services {
flow-table-size {
ipv4-flow-table-size 7;
ipv6-flow-table-size 7;
}
}
}
}
}

-Michael

>>-Original Message-
>>From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf
>>Of Alain Hebert
>>Sent: Tuesday, May 01, 2018 8:23 AM
>>To: juniper-nsp@puck.nether.net
>>Subject: Re: [j-nsp] MX104 and NetFlow - Any horror story to share?
>>
>>     Yeah I had the feeling I would break those MX's.
>>
>>     At this point it is worth it to rebuilt our vMX lab to test the
>>IPFIX variant...
>>
>>     Thanks for the input.
>>
>>
>>     As for routing we have a pretty good mix of T1/T2 providers and we
>>rarely drop sessions so it is providing a pretty good uptime...  And
>>that's why we got a pair of MX960 coming down anytime this year.
>>
>>
>>     PS: Unrelated quote - Yeah fat fingers sorry list.
>>
>>-
>>Alain Hebertaheb...@pubnix.net
>>PubNIX Inc.
>>50 boul. St-Charles
>>P.O. Box 26770 Beaconsfield, Quebec H9W 6G7
>>Tel: 514-990-5911  http://www.pubnix.netFax: 514-990-9443
>>
>>On 04/30/18 19:41, Olivier Benghozi wrote:
>>> Hi Alain,
>>>
>>> While you seem to already be kind of suicidal (5 full tables peers on an
>>MX104), on an MX you must not use netflow v9 (CPU based) but use inline
>>IPFIX (Trio / PFE based).
>>> I suppose that Netflow-v9 on an MX104 could be quickly an interesting
>>horror story with real traffic due to its ridiculously slow CPU, by the way.
>>> With inline IPFIX it should just take some more RAM, and FIB update could
>>be a bit slower.
>>>
>>> By the way on MX104 you don't configure «fpc» (bigger MXs) of «tfeb»
>>(MX80) in chassis hierarchy, but «afeb», so you can remove your fpc line and
>>fix your tfeb line.
>>>
>>> So you'll need something like that in services, instead of version9:
>>> set services flow-monitoring version-ipfix template ipv4 template-refresh-
>>rate
>>> set services flow-monitoring version-ipfix template ipv4 option-refresh-
>>rate
>>> set services flow-monitoring version-ipfix template ipv4 ipv4-template
>>>
>>> And these ones too, to allocate some memory for the flows in the Trio and
>>to define how it will speaks with the collector:
>>> set chassis afeb slot 0 inline-services flex-flow-sizing
>>> set forwarding-options sampling instance NETFLOW-SI family inet output
>>inline-jflow source-address a.b.c.d
>>>
>>> Of course you'll remove the line with «output flow-server  source
>>».
>>>
>>>
>>>
>>> I don't see why you quoted the mail from Brijesh Patel about the Routing
>>licences, by the way :P
>>>
>>>
>>> Olivier
>>>
 On 30 apr. 2018 at 21:34, Alain Hebert  wrote :


 Anyone has any horror stories with something similar to what we're about
>>to do?
  We're planning to turn up the following Netflow config (see below) on
>>our MX104s (while we wait for our new MX960 =D), it worked well with
>>everything else (SRX mostly), the "*s**et chassis"* are making us wonder
>>how high would be the possibility to render those system unstable, at short
>>and long term.

  Thanks again for your time.

  PS: We're using Elastiflow, and its working great for our needs atm.


 -- A bit of context

  Model: mx104
  Junos: 16.1R4-S1.3

  They're routing about 20Gbps atm, with 5 full tables peers, ~0.20 load
>>average, and 700MB mem free.


 -- The Netflow config

 *set chassis tfeb0 slot 0 sampling-instance NETFLOW-SI*

 *set chassis fpc 1 sampling-instance NETFLOW-SI*

 set services flow-monitoring version9 template FM-V9 option-refresh-
>>rate seconds 25
 set services flow-monitoring version9 template FM-V9 template-refresh-
>>rate seconds 15
 set services flow-monitoring version9 template FM-V9 ipv4-template

 set forwarding-options sampling instance NETFLOW-SI input rate 1 run-
>>length 0
 set forwarding-options sampling instance NETFLOW-SI family inet output
>>flow-server  port 2055
 set forwarding-options sampling instance NETFLOW-SI family inet 

Re: [j-nsp] Prefix independent convergence and FIB backup path

[Michael Hare]

Hi Mark-

We had a long thread on a similar topic last spring, if you haven't browsed 
through this you may find it valuable.

https://puck.nether.net/pipermail/juniper-nsp/2017-April/034145.html

-Michael

> -Original Message-
> From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf
> Of Mark Smith
> Sent: Thursday, February 8, 2018 6:02 AM
> To: juniper-nsp@puck.nether.net
> Subject: [j-nsp] Prefix independent convergence and FIB backup path
> 
> Hi list,
> 
> Test topology below. 2x MX80 with dual ip transit (full table ~600k
> prefixes). TRA1 preferred over TRA2 (Localpref 200 set by PE1 import
> policy). Plain unlabeled inet.0, no mpls in use. In lab topology both
> transits belong to same AS65502.
> 
> What I'm trying to accomplish is somewhat faster failover time in case
> of primary transit failure. In case of no tuning the failover (FIB
> programming) can take up to 10 minutes.
> 
> 
> 
> | TRA1 || TRA2 |   AS65502
> 
>| xe-1/3/0  | xe-1/3/0
> --- ---
> | PE1 | --ae0-- | PE2 |AS65501
> --- ---
>|
> ---
> | test pc |
> ---
> 
> In the lab PE1 and PE2 are MX80s running 15.1R6.7.
> I have configured BGP add-path and PIC edge (routing-options protect
> core) on both PEs.
> All looks ok on PE1. Both primary and backup paths are installed in
> FIB. PE1 converges fast.
> The backup path is missing in PE2 FIB. When PE1-TRA1 cable is cut PE1
> quickly switches to backup path but PE2 does not and the result is a
> temporary routing loop between PE1 and PE2.
> If I switch the active transit to PE2 (set LP220 on TRA2 import on
> PE2, no other changes), the situation is reversed. All looks ok on PE2
> but not on PE1. So it looks like the PIC works only on the box
> connected to primary transit (=EBGP route is better than IBGP route).
> NHS/no-NHS on ibgp export does not have an effect. Is this a bug,
> feature, or am I doing something wrong?
> 
> I know that a better solution could be to get rid of full table and
> just use 2x default route from upstream... anyways I would like to get
> more familiar with PIC.
> 
> Stable situation, all ok on PE1:
> admin@PE1> show route table inet.0 8.8.8.8
> 
> inet.0: 607797 destinations, 1823329 routes (607797 active, 0
> holddown, 0 hidden)
> @ = Routing Use Only, # = Forwarding Use Only
> + = Active Route, - = Last Active, * = Both
> 
> 8.8.8.0/24 @[BGP/170] 05:03:44, localpref 200
>   AS path: 65502 65200 25091 15169 I,
> validation-state: unverified
> > to 10.100.100.133 via xe-1/3/0.0
> [BGP/170] 05:05:55, localpref 100, from 10.100.100.40
>   AS path: 65502 65200 25091 15169 I,
> validation-state: unverified
> > to 10.100.100.137 via ae0.0
>#[Multipath/255] 05:02:54
> > to 10.100.100.133 via xe-1/3/0.0
>   to 10.100.100.137 via ae0.0
> 
> admin@PE1> show route forwarding-table destination 8.8.8.8 table
> default extensive
> Routing table: default.inet [Index 0]
> Internet:
> 
> Destination:  8.8.8.0/24
>   Route type: user
>   Route reference: 0   Route interface-index: 0
>   Multicast RPF nh index: 0
>   Flags: sent to PFE, rt nh decoupled
>   Next-hop type: unilist   Index: 1048575  Reference: 607767
>   Nexthop: 10.100.100.133
>   Next-hop type: unicast   Index: 826  Reference: 4
>   Next-hop interface: xe-1/3/0.0Weight: 0x1
>   Nexthop: 10.100.100.137
>   Next-hop type: unicast   Index: 827  Reference: 3
>   Next-hop interface: ae0.0 Weight: 0x4000
> 
> 
> But not on PE2:
> admin@PE2> show route table inet.0 8.8.8.8
> 
> inet.0: 607798 destinations, 1215564 routes (607798 active, 607766
> holddown, 0 hidden)
> @ = Routing Use Only, # = Forwarding Use Only
> + = Active Route, - = Last Active, * = Both
> 
> 8.8.8.0/24 *[BGP/170] 00:02:10, localpref 200, from 10.100.100.30
>   AS path: 65502 65200 25091 15169 I,
> validation-state: unverified
> > to 10.100.100.136 via ae0.0
> [BGP/170] 1d 01:54:47, localpref 100
>   AS path: 65502 65200 25091 15169 I,
> validation-state: unverified
> > to 10.100.100.134 via xe-1/3/0.0
> 
> admin@PE2> show route forwarding-table destination 8.8.8.8 table
> default extensive
> Routing table: default.inet [Index 0]
> Internet:
> 
> Destination:  8.8.8.0/24
>   Route type: user
>   Route reference: 0   Route interface-index: 0
>   Multicast RPF nh index: 0
>   Flags: sent to PFE
>   Next-hop type: indirect  Index: 1048574  Reference: 607767
>   Nexthop: 10.100.100.136
>   Next-hop type: unicast   Index: 790  Reference: 11
>   Next-hop interface: ae0.0
> 
> 
> 
> During TRA1 failure before PE2 convergence
> 

[j-nsp] multicore JunOS CPU utilization collection method .. ?

[Michael Hare]

A bit of cli sleuthing and googling has left me blank, so before I spend time 
opening a jtac case...

In short, for multicore JunOS (MX 16.1, for example), does anyone have a method 
for retrieving per CPU core usage statistics?  SNMP would be preferred, XML 
tolerable.

Historically I used 1.3.6.1.4.1.2636.3.1.13.1.8 [jnxOperatingCPU] to retrieve 
Routing Engine CPU usage, but in 16.X it looks like jnxOperatingCPU still only 
returns a single CPU value for the RE.  To be clear, I am specifically 
interested in the following information(user/nice/system/interrupt summarized 
would be fine), which I can only get as far as I know interactively with the 
'top' command from the shell

% top

last pid: 38153;  load averages:  0.08,  0.28,  0.36
 up 0+13:45:04  09:38:01
90 processes:  2 running, 87 sleeping, 1 zombie
CPU 0:  2.0% user,  0.4% nice,  4.7% system,  0.4% interrupt, 92.5% idle
CPU 1:  1.2% user,  0.4% nice,  5.9% system,  1.2% interrupt, 91.3% idle
CPU 2:  2.0% user,  0.0% nice,  3.5% system,  0.4% interrupt, 94.1% idle
CPU 3:  0.4% user,  0.0% nice,  3.1% system,  0.4% interrupt, 96.1% idle

Specifically, "show chassis routing-engine" still only displays a system total, 
not a per-core breakdown.

> show chassis routing-engine
Routing Engine status:
  Slot 0:
...
   5 sec CPU utilization:
  User   0 percent
  Background 0 percent
  Kernel 0 percent
  Interrupt  1 percent
  Idle  99 percent

I do already grab load average, personal experience with runaway processes on 
multicore Cisco DSBU (Catalyst 38xx, for example) makes me want the per core 
CPU details.

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

Re: [j-nsp] MX104 won't recognize fpc, mpc and onboard interfaces

[Michael Hare]

Hello-

Did your factory default include doing a install-media from front facing USB?  
I might suggest carefully looking at boot sequence for logs indicating possible 
package corruption.  

While I haven't had the exact problem you describe we have a > 25% failure 
(data corruption) rate on our MX104 REs manifesting themselves in all sorts of 
ways. We have caught some of this corruption by doing a sha1 checksum of tgz 
files in the package directory but we've also seen things like our 
/etc/services file corrupt, locking us out of SSH.

-Michael

> -Original Message-
> From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf
> Of Caio
> Sent: Thursday, December 21, 2017 6:32 PM
> To: juniper-nsp 
> Subject: [j-nsp] MX104 won't recognize fpc, mpc and onboard interfaces
> 
> Hello there,
> 
> We had a MX104 router in production for a very long time and recently we
> replaced it with a brand new MX480 and we took it to our lab in order to
> load the default configuration on it and start to configure it over to
> another POP.
> However, after the factory default it won't recognize the FPC anymore
> and/or any inserted MIC or even the onboard SFP+ interfaces.
> 
> The license seems to be ok (I will attach the show licenses output below)
> and I couldn't find anything to brought it back online, I have tried to
> push the Online button with a paper clip and through the command request
> chassis fpc / mic online and nothing...
> Has anyone been through something like that?
> Can anyone shed a light on it ?
> 
> Thanks in advance.
> 
> *PS:* By looking through the log files I've found just these unusual
> strings:
> ed_chmic ifpfed_controller ifpfed_ds0 ifpfed_ds1e1 ifpfed_ds3e3
> ifpfed_ethkldload: can't load /modules/ifpfe_drvLoading POS driver
> /ifpfed_eth.ko: Exec format error
> 
> and
> 
> CHASSISD_IFDEV_DETACH_FPC: ifdev_detach_fpc(0)
> Dec 21 20:30:07 2017  RT_SRR-CORE chassisd[1556]:
> CHASSISD_IFDEV_DETACH_FPC: ifdev_detach_fpc(1)
> Dec 21 20:30:07 2017  RT_SRR-CORE chassisd[1556]:
> CHASSISD_IFDEV_DETACH_FPC: ifdev_detach_fpc(2)
> 
> Command outputs below:
> 
> > show system license usage
> 
>  Licenses LicensesLicensesExpiry
> 
>   Feature name   usedinstalled  needed
> 
>   scale-subscriber  0 1000   0
>  permanent
> 
>   scale-l2tp0 1000   0
>  permanent
> 
>   scale-mobile-ip   0 1000   0
>  permanent
> 
>   MX104-2x10Gig-port-0-101   0
>  permanent
> 
>   MX104-2x10Gig-port-2-301   0
>  permanent
> 
> 
> > show chassis fpc
> 
>  Temp  CPU Utilization (%)   CPU Utilization (%)
>  MemoryUtilization (%)
> 
> Slot State(C)  Total  Interrupt  1min   5min   15min  DRAM
> (MB) Heap Buffer
> 
>   0  Empty
> 
>   1  Empty
> 
>   2  Empty
> 
> > request chassis pic fpc-slot 0 pic-slot 0 online
> 
> FPC slot 0 is empty
> 
> 
> > request chassis pic fpc-slot 1 pic-slot 0 online
> 
> FPC slot 1 is empty
> 
> > request chassis pic fpc-slot 2 pic-slot 0 online
> 
> FPC slot 2 is empty
> 
> > show chassis hardware
> 
> Hardware inventory:
> 
> Item Version  Part number  Serial number Description
> 
> ChassisX MX104
> 
> Midplane REV 51   750-XX   CAEX  MX104
> 
> PEM 0REV 05   740-XX   XX   DC Power Entry
> Module
> 
> PEM 1REV 05   740-XX   X   DC Power Entry Module
> 
> Routing Engine 1 REV 09   750-XX   CAFBX  RE-MX-104
> 
> AFEB 0BUILTIN  BUILTIN   Forwarding Engine
> Processor
> 
> Fan Tray 0   REV 03   711-XX   CAET8414  Fan Tray
> 
> > show interfaces terse
> 
> Interface   Admin Link ProtoLocal Remote
> 
> dsc upup
> 
> em0 upup
> 
> em0.0   upup   inet 10.0.0.5/8
> 
> 128.0.0.1/2
> 
> 128.0.0.5/2
> 
>inet6fe80::201:ff:fe00:5/64
> 
> fec0::a:0:0:5/64
> 
>tnp  0x5
> 
> em1 upup
> 
> fxp0updown
> 
> gre upup
> 
> ipipupup
> 
> jsrvupup
> 
> jsrv.1  upup   inet 128.0.0.127/2
> 
> lo0 upup
> 
> lo0.16384   upup   inet 127.0.0.1   --> 0/0
> 
> lo0.16385   upup   inet
> 
> lsi upup
> 
> me0 up  

Re: [j-nsp] Experience with Junos 15.1 on MX960?

[Michael Hare]

We are looking at moving to 16.1R6 within the new few weeks on an MX2010 from 
14.1.  Several folks have mentioned cosmetics bugs in 16.1.  If anyone is 
willing to highlight (publically or privately) PRs or high level descriptions 
of the cosmetic issues (no more than a sentence), I'd be curious.  Admittedly I 
can read the release notes, but there is value in hearing from others what 
cosmetics bugs affected them.

-Michael

>>-Original Message-
>>From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf
>>Of Olivier Benghozi
>>Sent: Tuesday, December 12, 2017 4:45 PM
>>To: juniper-nsp@puck.nether.net
>>Subject: Re: [j-nsp] Experience with Junos 15.1 on MX960?
>>
>>We've been running 16.1R4-S3 or S4 for 4/5 months (we had to choose
>>between 15.1F and 16.1R for our MPC7s), without MC-LAG.
>>We've been hit by about 8 PR, including 4 non-cosmetic ones (with 3 also
>>present in 15.1F anyway).
>>Most of them are allegedly fixed in 16.1R6.
>>17 might be the next step in 6 months.
>>
>>> On 12 dec. 2017 at 22:01, Nikolas Geyer  wrote :
>>>
>>> We’re running 16.1R4 and it’s been stable for the most part, aside from a
>>few annoying cosmetic problems.
>>>
>>> Running it on MX480’s and 960’s, a variety of RE’s, a variety of
>>MPC2/MPC3/MPC4/MPC7, usual protocols such as BGP, OSPF, MPLS, RSVP
>>and a few Tbps of traffic. No MC-LAG unfortunately though.
>>>
>>> Will probably schedule moving up to 17 some time early 2018.
>>
>>___
>>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] IPV6 IPFIX Flow issues "nodata" on flow collector.

[Michael Hare]

I am having success with v4 and v6 ipfix on 16.1R6, coming from 14.1R8.  
Collector is nfcapd, tested platform is MX2010 MPC4E.

-Michael

>>-Original Message-
>>From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf
>>Of Gustavo Santos
>>Sent: Monday, December 04, 2017 3:44 PM
>>To: sth...@nethelp.no
>>Cc: juniper-nsp@puck.nether.net
>>Subject: Re: [j-nsp] IPV6 IPFIX Flow issues "nodata" on flow collector.
>>
>>Hi Steinar,
>>
>>I am using about the same settings from IPv4 with IPv6 just changing the
>>template version..
>>
>>About the flow monitoring settings I as using the same one as you can see
>>below on IPv4 with IPv6, the current one was done after some tests...
>>
>>
>>
>>
>>sampling {
>>traceoptions {
>>file ipfix.log size 10k;
>>}
>>instance {
>>FLOW-INSTANCE {
>>input {
>>rate 1000;
>>max-packets-per-second 1;
>>}
>>family inet {
>>output {
>>flow-server xxx..xxx.xxx{
>>port 9995;
>>autonomous-system-type origin;
>>no-local-dump;
>>version-ipfix {
>>template {
>>ipv4;
>>}
>>}
>>}
>>inline-jflow {
>>source-address xxx.xxx.xxx.xxx;
>>}
>>}
>>}
>>family inet6 {
>>output {
>>flow-server xxx.xxx.xxx.xxx {
>>port 9995;
>>autonomous-system-type origin;
>>no-local-dump;
>>version-ipfix {
>>template {
>>ipv6;
>>}
>>}
>>}
>>inline-jflow {
>>source-address xxx.xxx.xxx.xxx;
>>}
>>}
>>}
>>}
>>
>>
>>
>>
>>vlan-id 2XX8;
>>family inet6 {
>>sampling {
>>input;
>>output;
>>}
>>address 2001:xxx:0:xxx::216/64;
>>}
>>
>>
>>
>>flow-monitoring {
>>version-ipfix {
>>template ipv4 {
>>flow-active-timeout 600;
>>flow-inactive-timeout 30;
>>template-refresh-rate {
>>packets 48000;
>>seconds 60;
>>}
>>option-refresh-rate {
>>packets 48000;
>>seconds 60;
>>}
>>ipv4-template;
>>}
>>template ipv6 {
>>flow-active-timeout 150;
>>flow-inactive-timeout 100;
>>template-refresh-rate {
>>seconds 10;
>>}
>>option-refresh-rate {
>>seconds 10;
>>}
>>ipv6-template;
>>}
>>}
>>}
>>
>>2017-12-01 15:10 GMT-03:00 :
>>
>>> > Anyone else had issues with Junos 16.1R4 with IPV6 and IPFIX?
>>> >
>>> > Here we use Plixer Scrutinizer as Flow collector and analyzer. IPv4 flow
>>> > monitoring is working as intended. With IPv6 , looks like the collector
>>> is
>>> > don´t know what to do with the data the Router is sending (MX480).
>>> >
>>> > After a Call , looks like the router is not sending the correct templates
>>> > to Scrutinizer, the only information it can identify is the current
>>> > interface traffic from the flows. But no source and destination ipv6
>>> > address.
>>>
>>> Can't comment on 16.1R4. We're running IPFIX flow collection on 15.1R6
>>> and it seems to be working reasonably well, both for IPv4 and IPv6. No
>>> problem showing IPv6 addresses with nfdump.
>>>
>>> You may want to show your config.
>>>
>>> Steinar Haug, Nethelp consulting, sth...@nethelp.no
>>>
>>___
>>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] IPV6 IPFIX Flow issues "nodata" on flow collector.

[Michael Hare]

If anyone has contacted jtac and has a PR to reference I would appreciate it 
(publically or privately).  We are evaluating moving from 14.1 to 16.1R6 but I 
haven't yet tested v6 IPFIX.

-Michael

>>-Original Message-
>>From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf
>>Of João Lyma.
>>Sent: Friday, December 01, 2017 2:53 PM
>>To: juniper-nsp@puck.nether.net
>>Subject: Re: [j-nsp] IPV6 IPFIX Flow issues "nodata" on flow collector.
>>
>>Hi Gustavo,
>>
>>Same problem here...
>>I use nfdump with nfsen.
>>Router: MX480 with JUNOS 16.1R3.10 64-bit kernel
>>JNPR-10.3-20160927.337663_build
>>
>>Regards,
>>
>>Lyma
>>
>>
>>Em 30/11/2017 00:13, Gustavo Santos escreveu:
>>> Hi,
>>>
>>> Anyone else had issues with Junos 16.1R4 with IPV6 and IPFIX?
>>>
>>> Here we use Plixer Scrutinizer as Flow collector and analyzer. IPv4
>>> flow
>>> monitoring is working as intended. With IPv6 , looks like the collector
>>> is
>>> don´t know what to do with the data the Router is sending (MX480).
>>>
>>> After a Call , looks like the router is not sending the correct
>>> templates
>>> to Scrutinizer, the only information it can identify is the current
>>> interface traffic from the flows. But no source and destination ipv6
>>> address.
>>>
>>> I already opened a JTAC support, but looks like the JTAC doesn´t even
>>> have
>>> a clue... I asked a friend that have the same router at another ISP and
>>> he
>>> have the same issue with NFSEN/FASTNETMON..
>>> ___
>>> 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] Anyone uses Adaptive Load Balancing?

[Michael Hare]

Alex-

I've used it AS wide in 14.1 for ~2+ years without observing any negative side 
effects.  My main driver was a connector's SAN replication MPLS service across 
an Nx10 bundle mixed with regular IP traffic with the SAN wanting to be one big 
flow.

-Michael

>>-Original Message-
>>From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf
>>Of Alex K.
>>Sent: Saturday, November 18, 2017 1:09 AM
>>To: serge vautour 
>>Cc: juniper-nsp 
>>Subject: Re: [j-nsp] Anyone uses Adaptive Load Balancing?
>>
>>Hello Serge and thank you.
>>
>>Yes, there are indeed, not that many cases for ALB. That's why I turned to
>>community.
>>
>>Thank you for sharing your experience.
>>
>>בתאריך 18 בנוב' 2017 1:41 AM,‏ "serge vautour"
>>
>>כתב:
>>
>>> Hello,
>>>
>>> We have been using it for a while. Works great. We have a few small links
>>> in a LAG bundle with a small number of fat flows over them. Without
>>> adaptive LAG the flows would sometimes hash on the same link. With
>>adaptive
>>> LAG they are always split.
>>>
>>> I agree that there probably aren't many use cases for this. We ran into
>>> one and this solution worked.
>>>
>>> Serge
>>>
>>>
>>> On Fri, Nov 17, 2017 at 6:36 PM, Alex K.  wrote:
>>>
 Hello everyone,

 A customer of mine, is looking forward for a technology able to load
 balance a traffic across a LAG.

 The LAG in question comprised of Ethernet link and can grow from a few
 links (4) to say, 20 - as required bandwidth grows. The gear is MX boxes.

 Since I'm familiar with adaptive load balancing but never used it myself,
 I'll glad if someone here can share his/her experience using it? Can it
 deliver pretty good load balancing across a LAG between routers? Is it
 stable? Is there any caveats one should avoid? Anything else we should
 consider, before deploying this thing into production? Feel free to share
 (off list/on list) your experience and everything else you think relevant.

 Thank you.
 ___
 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] Sporadic LUCHIP IDMEM read errors

[Michael Hare]

Yes, I see them as well.  I've never bothered contacting jtac, nor have I seen 
a detectable impact from these.

Between production and lab/sparing we have ~50 MX104s and 3 MX2010s.   Below 
data is for 2017.

#occurrences, chassis descr, date

 26 MX104 #10 - 2017-01-06
 12 MX104  #3 - 2017-06-15
  8 MX2010 #3 - 2017-04-23
  8 MX104  #2 - 2017-02-16
  5 MX2010 #1 - 2017-07-07
  4 MX2010 #3 - 2017-04-25
  4 MX104  #6 - 2017-06-13
  2 MX2010 #3 - 2017-05-31
  2 MX2010 #3 - 2017-04-27
  2 MX2010 #2 - 2017-05-01
  2 MX2010 #1 - 2017-08-25
  2 MX104  #9 - 2017-05-12
  2 MX104  #8 - 2017-08-21
  2 MX104  #8 - 2017-07-30
  2 MX104  #7 - 2017-02-05
  2 MX104  #5 - 2017-02-03
  2 MX104  #4 - 2017-04-29
  2 MX104  #1 - 2017-01-29

-Michael

> -Original Message-
> From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf
> Of Sebastian Wiesinger
> Sent: Tuesday, September 26, 2017 3:15 AM
> To: Juniper NSP 
> Subject: [j-nsp] Sporadic LUCHIP IDMEM read errors
> 
> Hello,
> 
> we're seeing sporadic LUCHIP IDMEM read errors like these (from two
> routers):
> 
> fpc5 LUCHIP(0) IDMEM[112821] read error
> 
> tfeb0 LUCHIP(0) IDMEM[303084] read error
> 
> It is a single error and does not impact traffic in any measurable way
> for us. It appears to be random on different router models (MX960,
> MX480, MX80) and JunOS versions. It seems these have increased in the
> last few weeks. At least one other provider I asked is seeing them as
> well.
> 
> Is anyone here seeing these? Has anyone found a reason for it or has
> already a case open for this?
> 
> Best Regards
> 
> Sebastian
> 
> --
> GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A  9D82 58A2 D94A 93A0
> B9CE)
> 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE
> SCYTHE.
> -- Terry Pratchett, The Fifth Elephant
> ___
> 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] improving global unicast convergence (with or without BGP-PIC)

[Michael Hare]

Admittedly this late to arrive follow up may not be J specific.

Our transit extensions aren't really traditional metro ethernet circuits, 
topology looks more like following

a-vlanXbc-vlanX---d

The "shared l2" device connects several .edu institutions into major 
aggregation facilities.  link 'a---b'  is optically protected.  .   'b' to 'c' 
is actually a vlan-ccc so 'b' and 'c' are already tied but the point is moot.  
We run BFD with 'd'.

If I understand correctly a theoretical eOAM session between 'a' and 'd' could 
cause both 'a' and 'd' IFLs to drop on end to end connectivity fault but eOAM 
assumes you manage both eOAM endpoints and is not meant for a cross domain 
situation.  Is it the correct conclusion that eOAM between 'a' and 'd' is 
unlikely to be supported by any reasonable upstream?  In this case 'd' is a 
tier1.

using this URL as a starting point for exploring eOAM
https://www.juniper.net/documentation/en_US/junos12.3/topics/example/layer-2-802-1ag-ethernet-oam-cfm-example-over-bridge-connections-mx-solutions.html

-Michael


From: Alexander Arseniev [mailto:arsen...@btinternet.com]
Sent: Wednesday, April 19, 2017 11:19 AM
To: Michael Hare <michael.h...@wisc.edu>; juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] improving global unicast convergence (with or without 
BGP-PIC)


Hi Michael,

With multiple full tables from two or more eBGP providers + iBGP peers, Your 
ASBR has to go via BGP best path reselection first before it can start 
programming FIB. And most specific route always wins, even if it otherwise 
inferior so BGP has to go over 100,000s of prefixes to find the bests among 
specific prefixes.

JUNOS INH helps at FIB programming stage, not at BGP best path reselection 
stage. Additionally in recent JUNOS versions, there are improvements made 
regarding FIB programming speed, please ask Your Juniper account team for 
details.

If You would  not have full tables over iBGP peering, then the picture would be 
simplified in a sense that in case of full-table eBGP peer down its invalidated 
prefixes need to be only removed, and eBGP 0/0 becomes best path. But I guess 
You won't like to run the network that way?

You can sense L2 failures by using either LACP with single member link 
(assuming Your Metro Ethernet provider passes LACP PDU), or Ethernet OAM 
(assuming Your Metro Ethernet provider passes EOAM PDU) or BFD. I would 
personally rate BFD as tool of last resort as (a) BFD being an UDP/IP protocol 
means there are many other failures  that affect BFD like access-lists (b) even 
when BFD is down, the BGP session may be still up whereas You want the BFD to 
follow BGP and (c) BFD failure does not bring the interface down, it just tears 
down the BGP session whereas LACP failure/EOAM failure brings the logical 
interface down. Presumably, someone will point out to uBFD over LAG but it 
still requires LACP so LACP+uBFD is overkill for a simple network UNLESS You 
are really into microseconds convergence.

When I said "JUNOS is different from IOS - BGP session will stay up until 
holdtime fires ..." - this is default behavior, You don't need to configure 
anything for it.

HTH

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

Re: [j-nsp] improving global unicast convergence (with or without BGP-PIC)

[Michael Hare]

While reading this thread I think I understand that updating the trie is 
expensive such that there is really no way to quickly promote use of the 
default route, so while I still may have use for that default (provider of last 
resort) it won't help with convergence.  

In several locations there is an ethernet switch between myself and 
transit/peers.  So I don't always lose local link on end to end path failure 
and if transit networks were in IGP they wouldn't necessarily be withdrawn.  
FWIW I am currently doing NHS with transit subnets in iBGP (for ICMP 
monitoring).

Alex said: "JUNOS is different from IOS - BGP session will stay up until 
holdtime fires but the protocol NH will disappear, the routes will be 
recalculated and network will reconverge even if BGP session to gone peer is 
still up."

I think I see the same behavior as Alex using "routing-options resolution rib", 
correct?   This is something we are already doing iBGP wise already for our 
default and aggregate announcements that contain our NHS addrs, unless there is 
yet another feature I should be considering?

An enlightening part of this thread is that I didn't realize the difference 
between BGP PIC Core vs BGP PIC Edge, the latter is seemingly what I'm most 
interested in and is seemingly unobtainable at this time.  Our network is 
extremely simplified in that we really have two ABSR so I don't think PIC Core 
would accomplish anything?

-Michael

> -Original Message-
> From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf
> Of Alexander Arseniev
> Sent: Wednesday, April 19, 2017 8:12 AM
> To: adamv0...@netconsultings.com; juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] improving global unicast convergence (with or without
> BGP-PIC)
> 
> Sorry, "Juniper’s “Provider Edge Link Protection for BGP” (Cisco’s BGP
> PIC Edge)" is not there in 15.1R5:
> 
> [edit]
> user@labrouter# set protocols bgp group IBGP family inet unicast protection
>  ^
> syntax error.
> 
> [edit]
> user@labrouter# run show version
> Hostname: labrouter
> Model: mx240
> Junos: 15.1R5.5
> 
> 
> The "Juniper BGP PIC for inet" (in global table) is definitely there:
> 
> https://www.juniper.net/techpubs/en_US/junos/information-
> products/topic-collections/release-notes/15.1/topic-83366.html#jd0e6510
> 
> So, what feature in the global table You were surmising to helps the OP?
> 
> HTH
> 
> Thx
> Alex
> 
> 
> On 19/04/2017 13:42, adamv0...@netconsultings.com wrote:
> >
> > Wow, hold on a sec, we’re starting to mix things here,
> >
> > Sorry maybe my bad, cause I’ve been using Cisco terminology,
> >
> > Let me use juniper terminology:
> >
> > I’d recommend using Juniper’s “Provider Edge Link Protection for BGP”
> > (Cisco’s BGP PIC Edge). –which in Junos for some reason was supported
> > only for eBGP session in routing-instance –that changes since 15.1.
> >
> > -that’s what me and OP is talking about (at least I think that’s what
> > OP is talking about)
> >
> > Cmd:
> >
> > set routing-instances radium protocols bgp group toCE2 family inet
> > unicast protection
> >
> > What you mentioned below is  Juniper’s “BGP PIC Edge” (Cisco’s BGP PIC
> > Core).
> >
> > Cmd:
> >
> > [edit routing-instances routing-instance-name routing-options]
> >
> > user@host# set protect core
> >
> > adam
> >
> > netconsultings.com
> >
> > ::carrier-class solutions for the telecommunications industry::
> >
> > *From:*Alexander Arseniev [mailto:arsen...@btinternet.com]
> > *Sent:* Wednesday, April 19, 2017 1:28 PM
> > *To:* adamv0...@netconsultings.com; 'Michael Hare';
> > juniper-nsp@puck.nether.net
> > *Subject:* Re: [j-nsp] improving global unicast convergence (with or
> > without BGP-PIC)
> >
> > Hi there,
> >
> > BGP PIC for inet/inet6 is primarily for complete ASBR failure use case:
> >
> > When the BGP Prefix Independent Convergence (PIC) feature is enabled
> > on a router, BGP installs to the Packet Forwarding Engine the second
> > best path in addition to the calculated best path to a destination.
> > The router uses this backup path when an egress router fails in a
> > network and drastically reduces the outage time. You can enable this
> > feature to reduce the network downtime if the egress router fails.
> >
> > https://www.juniper.net/techpubs/en_US/junos/topics/concept/use-
> case-for-bgp-pic-for-inet-inet6-lu.html
> >
> >
> > The original topic was for eBGP peer failure use case.
> >

Re: [j-nsp] improving global unicast convergence (with or without BGP-PIC)

[Michael Hare]

Agreeing with Raphael, my reading implies indirect-next-hop cannot be disabled 
on TRIO.  That said I do explicitly configure it on all of our MX gear.

You may also want to look at indirect-next-hop-change-acknowledgements, in my 
case I use LFA and dynamic-rsvp-lsp and have it configured acknowledging (no 
pun intended) it may be adding to my poor convergence woes without BGP PIC.  
FWIW I left krt-nexthop-ack-timeout at its default of 1s.

http://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/indirect-next-hop-change-acknowledgements-edit-routing-options-forwarding-options.html

-Michael

> -Original Message-
> From: Jared Mauch [mailto:ja...@puck.nether.net]
> Sent: Tuesday, April 18, 2017 2:48 PM
> To: Charlie Allom <char...@evilforbeginners.com>
> Cc: Jared Mauch <ja...@puck.nether.net>; Michael Hare
> <michael.h...@wisc.edu>; juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] improving global unicast convergence (with or without
> BGP-PIC)
> 
> On Tue, Apr 18, 2017 at 08:45:17PM +0100, Charlie Allom wrote:
> > On Tue, Apr 18, 2017 at 7:36 PM, Jared Mauch <ja...@puck.nether.net>
> wrote:
> >
> > You want to set indirect-next-hop in all use-cases.  This allows
> > > faster FIB convergence upon RIB events because all shared next-hops can
> be
> > > updated
> > > at once.
> > >
> > Is this the case for chassis MX104 and 80? Is your recommendation to run
> > with indirect-next-hop on them as well?
> >
> > ..or are there downsides on these smaller units?
> 
>   Yes, I would use this on all JunOS devices myself.
> 
>   - Jared
> 
> --
> Jared Mauch  | pgp key available via finger from ja...@puck.nether.net
> clue++;  | http://puck.nether.net/~jared/  My statements are only mine.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] improving global unicast convergence (with or without BGP-PIC)

[Michael Hare]

Hello,

Sorry if this is an easy question already covered.  Does anyone on list have an 
understanding of what happens in the FIB in the following circumstance?

Simplified topology;
* Router 1 RIB default points to reject
* Router 1 RIB has default free feed from attached eBGP neighbor A
* Router 1 RIB has default free feed from attached iBGP neighbor B (add-path)

I guess what I'm trying to understand, from the perspective of improving 
upstream convergence for outbound packets from our AS, if my default route 
pointed to a valid next hop of last resort am I likely to see an improvement 
(reduction) in blackholing on router 1 during topology changes?  The thought 
being that if Router 1 FIB invalidates next-hop A quickly (en masse) packets 
could match default route with valid next-hop while FIB is being re-programmed 
with more specifics via B?

I am aware of indirect-next-hop being default on MPC but my understanding is 
this will not work for directly connected eBGP peers?  So if session with A 
drops (BFD, link, whatever) are routes with next hop to neighbor A deprogrammed 
nearly atomically due to some level of indirection or are routes considered one 
by one until all routes (~600K) have been processed?  I suspect the latter but 
perhaps looking for verification.

I am aware of BGP PIC but not yet running 15.X [when internet is not in VRF].  
I am willing to accept that if BGP PIC is the best approach to improving this 
scenario an upgrade is the best path forward.  I'd be curious to hear from 
anyone who is on 15.1 [or newer] and using MPC4 in terms of perceived code 
quality and MPC4 heap utilization before/after.  

Historically the AS I primarily manage has been default free (default pointing 
to reject), but I'm considering changing that to improve convergence (aware of 
the security considerations).  As for our "real" topology, adding up all the 
transit and peering we have our RIB is nearing 6M routes.  We are not doing 
internet in a VRF.  Our network has add-path 3 enabled.  In some cases our 
peers/upstreams are on unprotected transport that is longer than I'd like.  
Providing a ring and placing the router closer would be nice but not 
necessarily in budget.

I haven't yet approached our account team to ask about this.

Thanks in advance for any suggestions or pointers for further reading.

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

Re: [j-nsp] Output filter on discard interface doesn't work as expected

[Michael Hare]

Any more details on platform or version you can share?  I'm doing this on MPC4 
in 14.1 with no issues.

Since it's a lab have you tried commit full?  Presumably no oddities in syslogs?

-Michael

> -Original Message-
> From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of
> Alex D.
> Sent: Friday, March 10, 2017 11:17 AM
> To: juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] Output filter on discard interface doesn't work as 
> expected
> 
> Am 10.03.2017 16:27, schrieb Karsten Thomann:
> > Hi,
> >
> > Already tried to set the firewall filter as input on dsc.0?
> >
> Yes, i already tried that. Also no success.
> According to the Juniper documentation, it definitely must be applied as
> an output filter.
> Regards,
> 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] RE-S-X6-64G & ISSU?

[Michael Hare]

Agree with Mark, if you count loss of redundancy as a high priority issue find 
the funds to purchase dual RE even on dual chassis designs.

We made this engineering mistake; initially saved money with a single RE design 
with dual PE MX104s.  We've had some NAND corruption RE failures that are 
undetectable until the fan gets hit.  The MX104 recovery process requires 
physical access (would love to be proven wrong).  Some of these chassis are 
distant and/or not convenient to access physically.  We are walking back and 
installing dual RE everywhere.

-Michael

> -Original Message-
> From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of
> Mark Tinka
> Sent: Tuesday, November 22, 2016 12:00 AM
> To: Aaron ; 'Sebastian Becker' 
> Cc: juniper-nsp@puck.nether.net; 'Clarke Morledge' 
> Subject: Re: [j-nsp] RE-S-X6-64G & ISSU?
> 
> 
> 
> On 14/Nov/16 17:04, Aaron wrote:
> 
> > Have y'all ever thought through the benefits of having dual RE in one
> > chassis compared to 2 chassis with 1 RE in each ?
> >
> > Like if I'm thinking about getting a MX480 with dual RE... what about
> > instead, getting dual MX240 with 1 RE in each ?  ...and possibly Virtual
> > Chassis'ing the dual MX240's as one virtual router
> >
> > Chassis diversity seems nice...then whatever would connect in that location,
> > can be redundantly connected to both MX240's.
> 
> Firstly, unless you're tight for space, I'd not spend money on an MX240.
> MX480 should be the bare minimum. Line cards are hungry for space.
> 
> We used to run single control planes in core switches, and have 2 core
> switches per PoP. This was because those switches only handled Ethernet
> traffic, no IP/MPLS.
> 
> I'd be hesitant to run any kind of routing device on a single control
> plane unless it was designed as such. Then again, control planes are not
> that much more expensive in current-generation core switches, so we are
> now kitting them fully out from that perspective as well.
> 
> 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] conditions [and negation] in bgp import policies

[Michael Hare]

Anyone have experience using conditions in bgp import policies?

Normally in our core we point v4/v6 default to discard like I suspect most here 
do.  I have default route from a transit provider of last resort that I want to 
activate "when I need to".  With all of its caveats of the approach in general, 
I'm looking at use 'policy-options condition' to install said default if I 
believe I've become isolated.  In my lab I'm testing with v4 [would use this 
for v4 as well] and am using 8.8.4.0/24 as a proof of concept.

'if-route-exists' does not have a built in negation so I tried to roll my own 
as follows.  0.0.0.0/0 is still being rejected [by import policy] despite no 
8.8.8.0/24 in the RIB.  This occurs even from a BGP clear when I can confirm 
8.8.8.0/24 was not in the local RIB during the entire BGP startup process.

I thought about doing a generated route, but I like the safety net idea of 
requiring the advertisement over BGP from this specific peer to be present.

Thought I'd try asking here before going to JTAC.  I respect this may evolve 
into a "bad idea in general" discussion.

-Michael

==/=


## my config

cooldude@r-mx2010-lab-re1# show policy-options policy-statement conditional-bgp 
term google-reachable {
from {
route-filter 0.0.0.0/0 exact;
condition route-to-google-dns;
}
then reject;
}
term google-unreachable {
from {
route-filter 0.0.0.0/0 exact;
}
then {
preference 1;
accept;
}
}

cooldude@r-mx2010-lab-re1# show policy-options condition route-to-google-dns 
if-route-exists {
8.8.8.0/24;
table inet.0;
}


## 8.8.8.0/24 not present

cooldude@r-mx2010-lab-re1# run show route 8.8.8.0/24 

{master}[edit]
cooldude@r-mx2010-lab-re1# 


## hidden default

cooldude@r-mx2010-lab-re1# run show route 0.0.0.0/0 exact hidden extensive 
table inet.0 

inet.0: 595731 destinations, 1191437 routes (595721 active, 9 holddown, 3 
hidden)
0.0.0.0/0 (3 entries, 1 announced)
State: 
TSI:
KRT in-kernel 0.0.0.0/0 -> {}
OSPF area : 0.0.0.0, LSA ID : 0.0.0.0, LSA type : Extern
Page 0 idx 0, (group iBGP-reflector type Internal) Type 5 val 0x2023c080 
(addpath tsi)
 Addpath Path ID: 1
 Source route: Static
   Advertised metrics:
 Nexthop: Self
 Localpref: 100
 AS path: [65010] I
 Communities:
 (AddPath PathId)
Advertise: 0007
Path 0.0.0.0 Vector len 4.  Val: 0
 BGP /-101
Next hop type: Router, Next hop index: 775
Address: 0xaa35900
Next-hop reference count: 1415662
Source: X.Y.33.86
Next hop: X.Y.33.86 via ae1.3106, selected
Session Id: 0x14b
State: 
Inactive reason: Unusable path
Local AS: 65010 Peer AS:  3128
Age: 5:00 
Validation State: unverified 
Task: BGP_3128.X.Y.33.86+52615
AS path: 3128 I
AS path: Recorded
Localpref: 100
Router ID: X.Y.32.2
Hidden reason: rejected by import policy
 BGP /-101
Next hop type: Router, Next hop index: 774
Address: 0x26409e0c
Next-hop reference count: 1571275
Source: X.Y.33.76
Next hop: X.Y.33.76 via ae0.3105, selected  

  
Session Id: 0x14c
State: 
Inactive reason: Unusable path
Local AS: 65010 Peer AS:  3128
Age: 5:00 
Validation State: unverified 
Task: BGP_3128.X.Y.33.76+62875
AS path: 3128 I
AS path: Recorded
Localpref: 100
Router ID: X.Y.32.1
Hidden reason: rejected by import policy
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] options for adding communities to an EVPN routing-instance?

[Michael Hare]

Adam-

I opened a JTAC case a few weeks back and was told to use the bgp export policy 
method.  I haven't tried it in our lab yet, as I'm not keen on the method.  To 
be fair I was looking at instance granularity, not mac address.  If I end up 
testing something, I'll report back.

-Michael

> -Original Message-
> From: Adam Vitkovsky [mailto:adam.vitkov...@gamma.co.uk]
> Sent: Wednesday, May 11, 2016 9:04 AM
> To: Michael Hare <michael.h...@wisc.edu>; juniper-nsp@puck.nether.net
> Subject: RE: options for adding communities to an EVPN routing-instance?
> 
> > Michael Hare
> > Sent: Saturday, April 23, 2016 12:12 AM
> >
> > Does anyone know if it is possible and how to add communities to routes to
> > an EVPN routing-instance in the instance configuration itself?  For example,
> > in bgp.evpn.0, I have
> >
> > 2:a.b.c.d:200::1900::00:1f:45:a0:1b:bb/304 (2 entries, 0 announced) ...
> > Communities: target:64900:200
> >
> > I'd like to be able to add, for example, $MYISP:12345 to the mac
> > announcements.  I haven't tried but am guessing I could do this in the IBGP
> > export policy using 'from instance' but this is suboptimal because then my 
> > PE
> > will need different export policies whereas they are currently now all
> > congruent.
> >
> Very interesting question indeed,
> and I believe it's valid requirement as well.
> 
> I'm just trying to find out, to no avail, if one can control what MAC 
> addresses
> make it from MAC address table to MP-BGP and with what attributes.
> If such a policy attachment point would exist one could tag MAC addresses with
> standard communities there (but I think no such thing exist in Junos or XR)
> 
> So when you tried to tag the MAC routes using iBGP peer export policy -has
> that worked please?
> 
> 
> adam
> 
> 
> Adam Vitkovsky
> IP Engineer
> 
> T:  0333 006 5936
> E:  adam.vitkov...@gamma.co.uk
> W:  www.gamma.co.uk
> 
> This is an email from Gamma Telecom Ltd, trading as “Gamma”. The contents
> of this email are confidential to the ordinary user of the email address to 
> which
> it was addressed. This email is not intended to create any legal 
> relationship. No
> one else may place any reliance upon it, or copy or forward all or any of it 
> in
> any form (unless otherwise notified). If you receive this email in error, 
> please
> accept our apologies, we would be obliged if you would telephone our
> postmaster on +44 (0) 808 178 9652 or email postmas...@gamma.co.uk
> 
> Gamma Telecom Limited, a company incorporated in England and Wales, with
> limited liability, with registered number 04340834, and whose registered 
> office
> is at 5 Fleet Place London EC4M 7RD and whose principal place of business is 
> at
> Kings House, Kings Road West, Newbury, Berkshire, RG14 5BY.
> 

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

[j-nsp] options for adding communities to an EVPN routing-instance?

[Michael Hare]

Does anyone know if it is possible and how to add communities to routes to an 
EVPN routing-instance in the instance configuration itself?  For example, in 
bgp.evpn.0, I have

2:a.b.c.d:200::1900::00:1f:45:a0:1b:bb/304 (2 entries, 0 announced)
...
Communities: target:64900:200

I'd like to be able to add, for example, $MYISP:12345 to the mac announcements. 
 I haven't tried but am guessing I could do this in the IBGP export policy 
using 'from instance' but this is suboptimal because then my PE will need 
different export policies whereas they are currently now all congruent.

Sorry if this is a rookie question, I don't have experience with l3vpns or 
route leaking.

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

Re: [j-nsp] MX punting packets to RE - why?

[Michael Hare]

Ross-

Change 'fpc0' to 'afeb0' in your failed command.  I got goose eggs, but this 
lab chassis isn't doing multicast which may play a part.

$user@mx104-lab-re0> request pfe execute target afeb0 command "show nhdb mcast 
resolve" 
SENT: Ukern command: show nhdb mcast resolve
GOT:
GOT: Nexthop Info:
GOT:ID  TypeProtocolResolve-Rate
GOT: -    --  ---
LOCAL: End of file

-Michael

-Original Message-
From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of 
Ross Halliday
Sent: Monday, February 1, 2016 2:38 PM
To: Dragan Jovicic ; Saku Ytti 
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] MX punting packets to RE - why?

Hi Saku and Dragan,

Thank you for the responses, and apologies for the ambiguity.

The EXes are our video source switches. PIM RP is shared with MSDP to an 
anycast address. The MXes connect to the EXes at L3 via BGP - MX1/EX1 link is 
de-prioritized with a metric. Most of our receivers ride off of MX2, with a few 
further downstream.

Due to some interop issues and our use of VBR we've settled on a single MDT for 
this VRF. Being the default MDT it is of course joined on all PEs with this 
VRF. During normal operation, MX1, which doesn't have any active traffic for 
this VRF, has a full list of mcast routes with the source interface of the MDT.

So, in the first failure scenario - let's say EX2 or MX2 totally dies - MX1 
will lose a preferred BGP route to the RP and sources and see everything over 
the MX1/EX1 link, so all of the S,G entries will need to be updated from 
mt-0/0/0.1081344 to xe-0/3/0.3812.

If I am understanding what you guys are saying correctly, this would cause 
everything to get punted to the CPU until a new hardware shortcut is created, 
and in the meantime - since our entire channel lineup is in there - this would 
hammer the DoS protection mechanism?

Can the rate at which the joins are sent out be slowed? I can live with a bit 
of a delay on the channels coming back to life, but not with the entire slot 
getting blackholed... I am also open to tweaking the DoS protection settings 
but it seems to me that a 10x increase would be opening myself up to really 
slamming the RE and causing even bigger problems. I come from SUP720 world, and 
I rather like having a box that can process BFD and BGP updates at the same 
time LOL


The other failure scenario is when the EX1/EX2 link goes down. When this 
happens, all devices are still up, so as far as BGP or really anything on the 
MX "knows", nothing has changed. Metric and next-hops are identical to the PEs. 
Instead of pulling video from the direct link, EX1 & EX2 can only see each 
other through VLANs that the MXes carry as EoMPLS l2circuits. This is what 
truly baffles me, as none of what you guys mentioned with regards to should 
apply to an l2circuit.


Also,
> request pfe execute target fpc0 command "show nhdb mcast resolve"
error: command is not valid on the mx104

:(

Thanks for your help guys!

Ross



From: Dragan Jovicic [mailto:dragan...@gmail.com] 
Sent: Sunday, January 31, 2016 7:44 AM
To: Saku Ytti
Cc: Ross Halliday; juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] MX punting packets to RE - why?

Correct me if I'm wrong, this looks like MX doesn't have multicast cache for 
all those S,G routes (in inet.1).
So first packet of each S,G entry must first be resolved by kernel and 
downloaded to PFE.
DDOS feature is activated because large influx of unresolved packets are 
passing trough the router. You could change default DDOS setting for this type 
of traffic on your FPC.
Another thing that comes to mind is that kernel itself has limited number of 
resolves per second, which is 66. That is, 66 different NH S,G entries will be 
resolved per second.

dj@mx-re0> request pfe execute target fpc0 command "show nhdb mcast resolve" 
SENT: Ukern command: show nhdb mcast resolve
GOT:
GOT: Nexthop Info:
GOT:    ID  Type    Protocol    Resolve-Rate
GOT: -    --  ---
GOT:  1927   Resolve    IPv6   66
GOT:  1962   Resolve    IPv4   66
LOCAL: End of file
This is modified by (hidden) knob:

dj@mx-re0# set forwarding-options multicast resolve-rate ?  
Possible completions:
     Multicast resolve rate (100..1000 per second)
{master}[edit]
Mind you, I haven't tested this.
HTH,
Regards

On Sat, Jan 30, 2016 at 12:04 PM, Saku Ytti  wrote:
Hey Ross,

It's not clear to me if the mcast is only inside the EX or if it's
also on the MX's. And it's not clear to me how the faults impact the
multicast distribution tree. On stable state, do both MX80's have
mcast states for groups? Or only one of them?

Trio maps each multicast group into an input interface, if mismatch
occurs, that is group ingresses from other input interface than the
specified, I believe this causes host punt.

Alas DDoS-protection limits are quite insane, 

[j-nsp] Q re: 6PE on a native IPv6 enabled network

[Michael Hare]

j-nsp,

I'd to deploy 6PE on an existing dual stack network so that native IPv6 
prefixes can take advantage of path benefits MPLS has to offer.  In my setup it 
seems that traffic from PE1 to PE2 [PE2 router id: x.x.32.8] is being load 
balanced between MPLS and native IPv6, showing equal cost protocol next hops of 
:::x.x.32.8 and y:y:0:100::8.

If I want to force all v6 traffic into MPLS, is the only solution to disable 
native family inet6 iBGP between PE and RR, or is there a way to make the 
native IPv6 protocol next hop less preferable in some way?

-Michael

/

Please note equal cost path to z:z::/32 which is learned from CE on PE2.

user@PE1-re0> show route z:z:: active-path   

inet6.0: 213 destinations, 287 routes (213 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

z:z::/32 *[BGP/170] 6d 06:17:47, MED 0, localpref 2020, from y:y:0:100::a
  AS path: 46103 I, validation-state: unverified
  to x.x.33.123 via ae0.3449, Push 301680
  to x.x.33.130 via ae2.3459, Push 315408
> to fe80::86b5:9c0d:790d:d7f0 via ae0.3449
  to fe80::86b5:9c0d:8393:d92a via ae2.3459

user@PE1-re0> show route z:z:: active-path detail 

inet6.0: 213 destinations, 287 routes (213 active, 0 holddown, 0 hidden)
z:z::/32 (5 entries, 1 announced)
*BGPPreference: 170/-2021
Next hop type: Indirect
Address: 0x3574754
Next-hop reference count: 6
Source: y:y:0:100::a
Next hop type: Router, Next hop index: 1048816
Next hop: x.x.33.123 via ae0.3449 weight 0x1
Label operation: Push 301680
Label TTL action: prop-ttl
Load balance label: Label 301680: None; 
Session Id: 0x151
Next hop: x.x.33.130 via ae2.3459 weight 0xf000
Label operation: Push 315408
Label TTL action: prop-ttl
Load balance label: Label 315408: None; 
Session Id: 0x14f
Next hop type: Router, Next hop index: 1048583
Next hop: fe80::86b5:9c0d:790d:d7f0 via ae0.3449 weight 0x1, 
selected
Session Id: 0x14b
Next hop: fe80::86b5:9c0d:8393:d92a via ae2.3459 weight 0xf000
Session Id: 0x143
Protocol next hop: :::x.x.32.8
Indirect next hop: 0x358f478 1048718 INH Session ID: 0x1e7
Protocol next hop: y:y:0:100::8
Indirect next hop: 0x35d8b68 1048578 INH Session ID: 0x14e
State: 
Local AS: 65400 Peer AS: 65400
Age: 6d 6:17:39 Metric: 0   Metric2: 2055 
Validation State: unverified 
Task: BGP_65400.y:y:0:100::a+179
Announcement bits (3): 0-KRT 2-RT 6-Resolve tree 2 
...
...
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] SNMP OID for CPU temperature

[Michael Hare]

In my experience the MIB doesn't list all possible instrumentation points.  
Although the below may have enough for you, we've resorted to parsing "show 
chassis environment | display xml"

-Michael

> -Original Message-
> From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of
> Rajendra Maharjan
> Sent: Tuesday, December 01, 2015 1:18 AM
> To: Dale Shaw 
> Cc: juniper-nsp 
> Subject: Re: [j-nsp] SNMP OID for CPU temperature
> 
> Hi Dale,
> 
> I am on MX router and temperature value given by snmp walk is of RE which
> we are already using. But there is no any oid that points out CPU Temperature
> run show snmp mib walk jnxOperatingTemp
> jnxOperatingTemp.1.1.0.0 = 0
> jnxOperatingTemp.2.1.0.0 = 58
> jnxOperatingTemp.2.2.0.0 = 48
> jnxOperatingTemp.4.1.0.0 = 0
> jnxOperatingTemp.4.1.1.0 = 0
> jnxOperatingTemp.4.1.2.0 = 0
> jnxOperatingTemp.4.1.3.0 = 0
> jnxOperatingTemp.4.1.4.0 = 0
> jnxOperatingTemp.4.1.5.0 = 0
> jnxOperatingTemp.6.1.0.0 = 72
> jnxOperatingTemp.6.1.1.0 = 55
> jnxOperatingTemp.6.1.2.0 = 70
> jnxOperatingTemp.6.1.3.0 = 73
> jnxOperatingTemp.7.1.0.0 = 72
> jnxOperatingTemp.7.2.0.0 = 72
> jnxOperatingTemp.7.3.0.0 = 72
> jnxOperatingTemp.8.1.1.0 = 0
> jnxOperatingTemp.8.1.2.0 = 0
> jnxOperatingTemp.8.2.1.0 = 0
> jnxOperatingTemp.8.2.2.0 = 0
> jnxOperatingTemp.8.3.1.0 = 0
> jnxOperatingTemp.9.1.0.0 = 56
> jnxOperatingTemp.20.1.1.0 = 0
> jnxOperatingTemp.20.2.1.0 = 0
> jnxOperatingTemp.20.2.2.0 = 0
> jnxOperatingTemp.20.3.1.0 = 0
> 
> #run show chassis routing-engine
> Routing Engine status:
>   Slot 0:
> Current state  Master
> Election priority  Master (default)
> Temperature 56 degrees C / 132 degrees F
> CPU temperature 67 degrees C / 152 degrees F
> 
> 
> Regards,
> Rajendra Maharjan
> 
> 
> On Dec 1, 2015, at 12:26 PM, Dale Shaw  wrote:
> 
> > show snmp mib walk jnxOperatingTemp
> 
> ___
> 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] estimating affects on firewall filter configuration on MPC throughput?

[Michael Hare]

Hello-

I'm looking for knowledge on how a given Juniper firewall filter config affects 
forwarding performance, specifically on an MPC4.  I don't have 100G+ traffic 
generation at my disposal for direct testing.

The specific concern is that we have a dozen or two 'then next-term' counting 
terms on internet ingress for purposes of crude thresholding [things like UDP 
53 > 1400 byte, etc].  I know that minimizing 'then next-term' is recommended, 
and there is a hard cap of roughly 2^10 on next-term use [of which I am nowhere 
near].

I've tried to Google for this and didn't find anything.  If I did, I suspect 
I'd be stuck with biased, worst case scenario third party testing reports.  
Thought I'd start here before trying to engage Juniper; I suspect they may be 
evasive with this information.

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

Re: [j-nsp] Limit on interfaces in bundle

[Michael Hare]

All-

You are correct about ECMP, I encountered this 12+ months ago and forgot that 
specific details.  Mark said he put the whole AE bundle into per packet mode 
[on a short LAN hop], which can also cause reordering [not just the LSP] if 
used incorrectly.

Yes, I've specifically disabled control word.  For us, disabling control word 
avoid LSP contents being sticky to a single LAG member.  It worked for us, in 
that it solved a congestion issue carrying a high bandwidth LSP mixed with 
internet traffic on a two link bundle.  We are 100% Trio forwarding shop and 
avoid L3 ECMP [LACP only, with links having essentially the same latency 
characteristics].   YMMV, as I've been strongly reminded.

-Michael

> -Original Message-
> From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf
> Of Mark Tinka
> Sent: Friday, October 30, 2015 4:17 AM
> To: Adam Vitkovsky ; Saku Ytti
> 
> Cc: juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] Limit on interfaces in bundle
> 
> 
> 
> On 30/Oct/15 11:06, Adam Vitkovsky wrote:
> 
> > Yes I agree that control word should definitely be enabled across the
> board, it’s necessary on Cisco anyways.
> 
> Enabled by default in Junos. One would have to manually turn it off.
> 
> 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

Re: [j-nsp] Limit on interfaces in bundle

[Michael Hare]

I see that 14.1 [we're going there for E-VPN] also supports RFC 6391 and RFC 
6790, so I probably need to take a closer look.  Anyone have experience with 
either in JunOS yet?  Mark, was it you that was on 14.2 for ingress CoS 
purposes?

Sorry if this has been discussed before on list

https://www.juniper.net/documentation/en_US/junos14.1/topics/reference/configuration-statement/flow-label-transmit-static-edit-protocols-l2circuit.html
http://www.juniper.net/documentation/en_US/junos14.1/topics/task/configuration/mpls-entopy-label-configuring.html

-Michael

> -Original Message-
> From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf
> Of Michael Hare
> Sent: Friday, October 30, 2015 7:45 AM
> To: Mark Tinka <mark.ti...@seacom.mu>; Adam Vitkovsky
> <adam.vitkov...@gamma.co.uk>; Saku Ytti <s...@ytti.fi>
> Cc: juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] Limit on interfaces in bundle
> 
> All-
> 
> You are correct about ECMP, I encountered this 12+ months ago and forgot
> that specific details.  Mark said he put the whole AE bundle into per packet
> mode [on a short LAN hop], which can also cause reordering [not just the
> LSP] if used incorrectly.
> 
> Yes, I've specifically disabled control word.  For us, disabling control word
> avoid LSP contents being sticky to a single LAG member.  It worked for us, in
> that it solved a congestion issue carrying a high bandwidth LSP mixed with
> internet traffic on a two link bundle.  We are 100% Trio forwarding shop and
> avoid L3 ECMP [LACP only, with links having essentially the same latency
> characteristics].   YMMV, as I've been strongly reminded.
> 
> -Michael
> 
> > -Original Message-
> > From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On
> Behalf
> > Of Mark Tinka
> > Sent: Friday, October 30, 2015 4:17 AM
> > To: Adam Vitkovsky <adam.vitkov...@gamma.co.uk>; Saku Ytti
> > <s...@ytti.fi>
> > Cc: juniper-nsp@puck.nether.net
> > Subject: Re: [j-nsp] Limit on interfaces in bundle
> >
> >
> >
> > On 30/Oct/15 11:06, Adam Vitkovsky wrote:
> >
> > > Yes I agree that control word should definitely be enabled across the
> > board, it’s necessary on Cisco anyways.
> >
> > Enabled by default in Junos. One would have to manually turn it off.
> >
> > 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
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Limit on interfaces in bundle

[Michael Hare]

Thanks much for the replies, I better understand your dilemma.

Assume your P/PE support RFC 6790, isn't RFC 6790 essentially a superset of RFC 
6391?  If you configure RFC 6790 network wide for all LDP FECs [again, we're 
homogenous], you wouldn't need FAT-PW?

-Michael

> -Original Message-
> From: Mark Tinka [mailto:mark.ti...@seacom.mu]
> Sent: Friday, October 30, 2015 11:36 AM
> To: Michael Hare <michael.h...@wisc.edu>; Adam Vitkovsky
> <adam.vitkov...@gamma.co.uk>; Saku Ytti <s...@ytti.fi>
> Cc: juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] Limit on interfaces in bundle
> 
> 
> 
> On 30/Oct/15 15:49, Michael Hare wrote:
> 
> > I see that 14.1 [we're going there for E-VPN] also supports RFC 6391 and RFC
> 6790, so I probably need to take a closer look.  Anyone have experience with
> either in JunOS yet?  Mark, was it you that was on 14.2 for ingress CoS
> purposes?
> >
> > Sorry if this has been discussed before on list
> >
> >
> https://www.juniper.net/documentation/en_US/junos14.1/topics/reference/con
> figuration-statement/flow-label-transmit-static-edit-protocols-l2circuit.html
> >
> http://www.juniper.net/documentation/en_US/junos14.1/topics/task/configurat
> ion/mpls-entopy-label-configuring.html
> 
> If you're going to Junos 14, I'd suggest 14.2R4.9. It has the new Policy
> Map feature (ingress QoS support for 802.1p, IPP, DSCP and EXP), and
> also fixes the LAG policing issue I described a few months back.
> 
> We have the "Entropy Label for LSP's" feature enabled on our Juniper
> routing devices. This mostly helps for upstream routers that can
> understand this capability. However, be careful if you're running IOS XR
> 5.3.0 on a Cisco router deploying RSVP with a Juniper box running this
> feature. The signaling of this capability was broken by Cisco when they
> got to 5.3.0, which breaks the RSVP session; but this was fixed in IOS
> XR 5.3.1 and later.
> 
> We have not yet enabled FAT-PW because our issue was downstream of the
> MX boxes, not upstream into the core. We are more likely to move to
> 100Gbps faster on the core-facing links compared to the downstream
> links, so FAT-PW is not as critical there. However, we are looking into
> it and have not yet made the decision whether to go 100Gbps or FAT-PW
> for the particular data centre in question.
> 
> FAT-PW would not help in the case where we went with per-packet sprays
> as the downstreams switches are pure Layer 2 devices.
> 
> Mark.

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

Re: [j-nsp] Limit on interfaces in bundle

[Michael Hare]

Mark-

re: EoMPLS pw balancing, do you have no-control-word configured?  My 
understanding [and experience] is that vc is sticky due to hashing based on 
presence of control word.  If control word is absent you can hash based on 
normal IP/ethernet headers.  As I recall negative of removing control word has 
to do with drop optimizations during fragmentation.  I am struggling with same 
sort of thing for 10G backbone university san replication.  In my case it's 
because the traffic isn't well hashable even if it were native IP [consistent 
flow tuple] and short of pressuring vendor to support multiflow transfer, 
40G/100G appears to be the only reasonable solution at this point.  

-Michael

example:
l2circuit {
neighbor x.y.32.2 {
interface ge-1/1/0.0 {
virtual-circuit-id 3115;
no-control-word; <---
ignore-mtu-mismatch;
}


> -Original Message-
> From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of
> Mark Tinka
> Sent: Thursday, October 29, 2015 9:19 AM
> To: Saku Ytti ; Cydon Satyr 
> Cc: juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] Limit on interfaces in bundle
> 
> 
> 
> On 29/Oct/15 16:09, Saku Ytti wrote:
> 
> >
> > JunOS does have these days adaptive balancing, which essentially
> > monitors if one link has higher utilisation than others, then proceeds
> > to give smaller share of hash results to that interface. I don't know
> > how well it works in practice.
> 
> It works okay for IP traffic.
> 
> But we've had issues with it working for Layer 2 traffic which is
> carried in an EoMPLS pw. We had to workaround this by switching from
> "adaptive" to "per-packet". I know what you're thinking - no, we have
> not had any "per-packet"-related issues, as the downlink device to which
> the traffic is being sent is local within the data centre.
> 
> All the hashing features and algorithms that were present simply could
> not handle hashing outbound Layer 2 traffic equally. Juniper seemed to
> indicate some improvements for this in Junos 15, but 14.2 has been super
> stable for us and we'd like to keep it that way.
> 
> 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] 14.2 trio flexible firewall matching?

[Michael Hare]

I'm wondering if anyone on list has tried this or gotten decent caveat 
information on this feature.  I intend to lab it but haven't gotten around to 
it yet.

http://www.juniper.net/documentation/en_US/junos14.2/topics/concept/firewall-filter-flexible-match-conditions-overview.html

Some things I wanted to explore;
* Matching ethernet dst addr bit 8 to count/police ethernet multicast
* Poor man's DNS reflection firewall (counting/policing DNS ANY attempts, aka 
fkfkfkfz.guru lookups) 

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

[j-nsp] port or ifl, not vlan based, E-VPN?

[Michael Hare]

Hello-

I come greenfield to multipoint ethernet MPLS, so I have essentially zero 
experience with VPLS.  

I am currently using l2circuit to provide vlan agnostic point to point for our 
EDUs, but there is a desire to multipoint for redundancy.

I've read [and labbed] through the excellent "DAY ONE: USING ETHERNET VPNS FOR 
DATA CENTER INTERCONNECT", specifically the example using virtual-switch to 
transmitting multiple ESI (vlans) inside a single EVI.  For now there is no 
IP-VPN portion of the E-VPN service I'm looking to deploy so I am left with a 
question; are there any hacks allowing the P/PE to be ignorant of the CE-vlan?  

Given that loop prevention is per EVI/ESI I suspect the answer is no, but I 
[and the users] have enjoyed not having to tell me each time they spin up a new 
vlan.

However I see "port-based" options pop up in Juniper E-VPN whitepapers but 
can't find any documentation or examples.

link: http://www.juniper.net/assets/us/en/local/pdf/whitepapers/2000596-en.pdf 
search for "This service type also supports a special case known as a 
port-based service interface, where all of the VLANs on a port are part of the 
same service and map to the same bundle."

Is this whitepaper describing the virtual-switch day one example or something 
else?

Absent this, has anyone successfully used dual l2circuits as an alternative?  
I'm not thrilled about relying on customer loop prevention [spanning tree, 
LAG/multichassis LAG], but wondering if I could storm control/ddos-protection 
my way out of a customer bridge loop if it were to occur.

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

Re: [j-nsp] backup RE and default-address-selection question

[Michael Hare]

I've observed this behavior on MX104 in both 13.3R4.6 and 14.1R5.5, without or 
without nonstop routing [rpd running on backup RE].  In general I avoid ISSU 
and we don't always force failover from RE1 to RE0 after maintenance, so RE1 
isn't always our backup RE.  For now I am using "syslog host $host log-prefix" 
under re0/re1.

If I one day pursue this further with Juniper, I'll report back my findings.

-Michael

> -Original Message-
> From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf
> Of Chris Hellberg
> Sent: Wednesday, September 02, 2015 6:10 PM
> To: juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] backup RE and default-address-selection question
> 
> Docs seem to indicate that the source IP of host-initiated traffic is
> the fxp0 interface when you set default-address-selection and the egress
> interface is fxp0. Lo0 is used if traffic goes out a routed interface
> (e.g. when doing inline management).
> 
> http://www.juniper.net/documentation/en_US/junos13.2/topics/reference
> /configuration-statement/default-address-selection-edit-system.html
> 
> If not, may be a bug; what's your code version?
> 
> Another option that springs to mind and that's to put the [edit system
> syslog] source-address value of fxp0 of RE1 under your re1 apply-group.
> That may supersede default-address-selection.
> 
>  /Chris
> 
> On Mon, Aug 31, 2015, at 06:40 PM, Michael Hare wrote:
> > Hello-
> >
> > I know there have been a million threads on this topic, but I don't see
> > this particular variant being discussed.
> >
> > To date we have managed our Juniper devices inline [via lo0, default
> > address selection] instead of via fxp.  However, I would like to collect
> > syslogs from backup RE so I have begun connecting re0 and re1 fxp0
> > interfaces and using backup-router/inet6-backup-router via re0/re1 groups
> > with the master-only flag for basic IP connectivity and monitoring.
> >
> > I have observed that despite lack of RPD, the backup RE still has all of
> > its interfaces connected [including lo0], and we use
> > default-address-selection, so backup RE sources from lo0 meaning that by
> > IP address I cannot tell if the syslog is coming from master RE or backup
> > RE.
> >
> > Other than resorting to commit scripts, I couldn't figure out a way to
> > continue receiving syslogs from lo0 [via default address selection] from
> > master RE but use backup RE's fxp0 address as source for backup RE
> > traffic.
> >
> > I've read about the alternatives [logical systems, everything else in a
> > vrf].  Not going down that path, I'd rather live with suboptimal if
> > that's the only way.
> >
> > -Michael
> > ___
> > 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

[j-nsp] backup RE and default-address-selection question

[Michael Hare]

Hello-

I know there have been a million threads on this topic, but I don't see this 
particular variant being discussed.

To date we have managed our Juniper devices inline [via lo0, default address 
selection] instead of via fxp.  However, I would like to collect syslogs from 
backup RE so I have begun connecting re0 and re1 fxp0 interfaces and using 
backup-router/inet6-backup-router via re0/re1 groups with the master-only flag 
for basic IP connectivity and monitoring.

I have observed that despite lack of RPD, the backup RE still has all of its 
interfaces connected [including lo0], and we use default-address-selection, so 
backup RE sources from lo0 meaning that by IP address I cannot tell if the 
syslog is coming from master RE or backup RE.  

Other than resorting to commit scripts, I couldn't figure out a way to continue 
receiving syslogs from lo0 [via default address selection] from master RE but 
use backup RE's fxp0 address as source for backup RE traffic.

I've read about the alternatives [logical systems, everything else in a vrf].  
Not going down that path, I'd rather live with suboptimal if that's the only 
way.

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

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

[Michael Hare]

All-

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

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

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

From the KB:

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

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

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

Saku, thanks for your second set of eyes,

-Michael

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

[j-nsp] punting base address packets to RE

[Michael Hare]

Hello-

Sorry if this is remedial, but are packets sent to the base address of a 
directly connected subnet always punted to RE and if so, why?  Historic 
compatibility?  I couldn't determine any bucket under the ddos-protection 
protocol statistics such traffic ends up in, either.  I haven't seen any 
negative side effects of this, only noticing this after I followed up on a high 
pps drop rate for one of our routing engines.  This seems to happen regardless 
of what I have 'targeted-broadcast' configured with [absent, forward-only].

For example, in below I ran telnet X.Y.0.0 16888 and telnet X.Y.0.0 5 
from A.B.254.29, resulting in the firewall logs as follows.

Time of Log: 2015-08-24 12:53:38 CDT, Filter: pfe, Filter action: discard, Name 
of interface: ae1.3416
Name of protocol: TCP, Packet Length: 52, Source address: A.B.254.29:34776, 
Destination address: X.Y.0.0:16888

Time of Log: 2015-08-24 12:57:17 CDT, Filter: pfe, Filter action: discard, Name 
of interface: ae1.3416
Name of protocol: TCP, Packet Length: 52, Source address: A.B.254.29:31968, 
Destination address: X.Y.0.0:5

I have a 'then log' at the bottom of my protect-re filter in lo0.0 family inet.

As you can see X.Y.0.0/21 is directly connected on the given chassis, but the 
local address is not the X.Y.0.0/32 address.

# run show route X.Y.0.0 table inet.0 

inet.0: 396 destinations, 417 routes (395 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both

X.Y.0.0/21  *[Direct/0] 39w3d 18:24:03
 via irb.157

For what it's worth, the above is an MX104, but I also see this on other MX MPC 
hardware.

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

Re: [j-nsp] EVPN

[Michael Hare]

[resend: sent yesterday from wrong src addr, apologizes to those who are seeing 
this as a dupe]

Amos [and others]-

We're taking e-vpn to the lab a well as we are greenfield without VPLS, so I'm 
interested in any cookbooks you are willing to share [sanitized config, etc].

I have been collecting to RRD ddos aggregate stats [show ddos-protection 
protocols statistics terse | display xml] for quite some time so I can 
determine sensible juniper ddos policers for our network.

Are others going through the effort of tweaking per FPC policers?  I'm trying 
to weigh hassle vs reward of moving towards show ddos-protection protocols 
statistics detail | display xml.

I'm aware of Sauk's comments re: 100pps/4000pps, and curious if folks are 
deviating significantly from this [up or down].

-Michael

  -Original Message-
  From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On
 Behalf
  Of Amos Rosenboim
  Sent: Sunday, August 09, 2015 2:43 AM
  To: juniper-nsp@puck.nether.net; Chuck Anderson c...@wpi.edu
  Subject: Re: [j-nsp] EVPN
 
  Hi,
 
  We are in the final stages of testing EVPN for DCI as well as corporate
  customers access into a small IaaS provider cloud.
 
  So far the testing was really good.
  Few points we encountered:
 
  1. On single active multi homing, when the CE is a L2 switch. When failing
 the
  active link the switch will learn the remote destination MAC through the
  standby link very quickly.
  However, when the active link recovers and becomes active once again,
 the
  CE MAC table does not flush and the CE keep sending traffic to backup port
  that is now blocking.
  Obviously this is only applicable to uni directional traffic scenarios. On 
  bi-
  directional scenarios MAC learning works like a charm.
 
  2. We couldn't find an elegant way to associate The inner vlan in a QinQ
 stack
  directly into an EVI. We had to use a an ingress bridge domain and the
  infamous loop cable to do this.
  Still searching for a more elegant way.
 
  3. Loop testing- we tested what happens when a customer creates a loop.
  We looped several vlans, most were L2, but one was L3 running ospf with
 the
  MX.
  With the default configuration the results were the expected disaster.
  After applying interface specific ARP policers, and using flow detection for
  ddos protection (thanks to Saku Ytti for the pointers on this list), things 
  look
  much better now.
 
  This deployment is planned to go into production in a few weeks once we
 are
  all back from our various vacations.
 
  Any feedback from other deployments will be much appreciated.
 
  Cheers,
 
  Amos
 
  Sent from my iPhone
 
  On 9 Aug 2015, at 00:03, Chuck Anderson
  c...@wpi.edumailto:c...@wpi.edu wrote:
 
  On Wed, May 06, 2015 at 12:13:41PM +0100, Matt Bernstein via juniper-nsp
  wrote:
  On 05/05/2015 15:48, Chuck Anderson wrote:
  On Fri, May 01, 2015 at 05:53:54PM -0400, Chuck Anderson wrote:
  Is anyone doing EVPN in production yet?
  I take it from the deafening silence that either no one is doing EVPN
  in production, or no one is willing to admit it.
  You could ask me again in a few months :)
 
  I'm looking at a 10Gb/s L2 DCI over the Internet. EVPN (I think
  MPLSoGRE pseudowires), then over IPsec, using active/active MX240
  routers in each location. Looks elegant on paper, although if our
  PoC turns up any gremlins we can fall back to boring (but obviously
  less elegant) VPLSoGREoIPsec.
 
  I can report back here, hopefully before August, if people find it
  interesting. _I_ will be particularly interested in the encryption
  latency tax, given that without dedicated circuits latency is
  already potentially an issue.
 
  I will also be interested to see if anything cheap can do
  low-bandwidth encrypted EVPN; this might help those few corner-cases
  where people insist on a VLAN over our L3 campus fabric. The SRX100
  can do VPLSoGREoIPsec, but again EVPN strikes me as more elegant.
 
  Hi Matt,
 
  Do you have any news to report on your EVPN deployment?  Did you have
  to fall back to VPLS?
 
  Thanks,
  Chuck
  ___
  juniper-nsp mailing list juniper-nsp@puck.nether.netmailto:juniper-
  n...@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] DOM: SNMP polling of RX power for 1 GE SFP impossible?

[Michael Hare]

We use an event script that converts parts of 'show interface 
diagnostics optics' and stuffs values into a MIB that is pollable.


The SLAX was given to us by Juniper several years ago after we whined a 
lot [ and didn't invest the effort to learn SLAX ].  It may not do 
everything -you- want, but might be useful as a start point.  We've used 
it successfully for 1/10g 'stuff' for several years.  I can't imagine 
they'd be upset with us sharing it.


-Michael

On 4/12/2012 4:13 AM, Per Granath wrote:

It should be possible to get the values via an op-script ...
Not sure if that can also populate MIB values.



So there is no way to poll by SNMP the power for 1 G SFP. Strange.


Yes, this is a significant omission, and you're certainly not the only
one to notice it. If enough people ask about it, maybe Juniper will do
something...


And when we do get them, next problem is, we don't know
programmatically what values to expect. As JNPR lacks 'entity mib' you can't
ask it via SNMP what type of optic it is, to determine what TX/RX/power etc
are expected for this optic.


___
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] Resource Temporarily Unavailable - Juniper MX

[Michael Hare]

I would be appreciate any on list replies as well.  We also see this, 
running 10.4r on MX gear.  Given other outstanding cases I haven't burnt 
a JTAC resource on this one.


-Michael

On 12/5/2011 6:48 AM, Paul Stewart wrote:

Can anyone shed some light on these log messages?



Nov 30 04:48:21  core2.toronto1 rpd[1359]: bgp_send: sending 19 bytes to
xx.xxx.52.50 (External AS x) blocked (no spooling requested): Resource
temporarily unavailable



We get these every so often .. Presuming it has to due with load on the
system for a short period of time?



Platform is Juniper MX boxes running 10.0R3.10



Thanks,



Paul



___
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] Graphs for IPv6 traffic

[Michael Hare]

That is what I do as well.  You will find the 'interface-specific' knob 
invaluable.  You'll have to apply it per ifl in/out.


-Michael

[pseudocode]

firewall {
  family inet 6 {
filter count-v6 {
interface-specific;
term count-v6 {
then {
count your-counter-name; #replace the name
accept; # or whatever
}
}
}
   }
}

On 8/24/2011 7:37 AM, Matti Saarinen wrote:

Ido Szargel wrote:


I am looking for a way to poll snmp data on IPv6 traffic (bps, pps) on
MX80 to a cacti graph, does anyone have any luck with doing that?


(Not MX80 but M10i but the difference isn't hopefully significant in
this case.) I configured an IPv6 filter under which I defined a counter
and the value of that counter is read by SNMP. Not the most elegant
solution but it appears to work.

Cheers,


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

Re: [j-nsp] JUNIPER-COS-MIB support in open source monitoring tools

[Michael Hare]

In .edu, so not surprisingly we rolled our own.

We use three queues and I grab the following per queue.

jnxCosIfqTxedBytes, jnxCosIfqTxedPkts, jnxCosQstatTailDropPkts, 
jnxCosQstatTotalRedDropBytes, jnxCosQstatTotalRedDropPkts


At 15 instances per ifl and 449 ifls on one box alone, it's a lot to 
grab every 5 minutes.  At times snmp becomes unresponsive on an mx960 
RE-2000.


-Michael

On 7/25/2011 5:10 PM, Dale Shaw wrote:

Hi all,

Is anyone aware of any effort to wrangle JUNIPER-COS-MIB support into
open source monitoring tools such as MRTG, cacti etc.?

Are there any commercial network monitoring/management packages that
understand this MIB?

I'm looking for something to allow us to graph/present things like
utilisation, bps, pps, and drop rates *per forwarding-class*.

If you've done this in your shop, could you please let me know? I'm
willing to have a go at getting something happening, preferably with
cacti.

Cheers,
Dale
___
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] JUNOS upgrade to 10.4R4.5 on M10i

[Michael Hare]

I had this problem today actually and went from 9.3 to 10.0 and then 
10.4.  I think there was a bulletin about it.  Too lazy to look :)


-Michael

On 7/11/2011 3:52 PM, Alex D. wrote:

Hello folks,

i want to upgrade a M10i (with RE-850 installed) to JUNOS 10.4R4.5.
When i try to install the software, i get the following error:

alex@test request system software add
/var/tmp/jinstall-10.4R4.5-domestic-signed.tgz no-validate

WARNING: Package jinstall-10.4R4.5-domestic-signed is not compatible
with this hardware.
WARNING: Please install a package with version 7.4 or higher.

In the release notes for 10.4R4.5 i saw that there's a compact flash
with 1G capacity needed since JUNOS 9.0. But an upgrade from 8.0R2.8 to
9.3R1.7 worked without problems.

alex@test show version
Hostname: test
Model: m10i
JUNOS Base OS boot [9.3R1.7]
JUNOS Base OS Software Suite [9.3R1.7]
JUNOS Kernel Software Suite [9.3R1.7]
JUNOS Crypto Software Suite [9.3R1.7]
JUNOS Packet Forwarding Engine Support (M/T Common) [9.3R1.7]
JUNOS Packet Forwarding Engine Support (M7i/M10i) [9.3R1.7]
JUNOS Online Documentation [9.3R1.7]
JUNOS Routing Software Suite [9.3R1.7]

Do you know the error mentioned above ?
Is it because of my 256MB compact-flash and what's the product number of
the compact-flash i need ?

Regards,
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] EX 10.4R4.3

[Michael Hare]

We upgraded a few (five?) EX4200's to 10.4R3.4 for the flash 
partitioning feature a few weeks ago.  We haven't ran across anything 
terrible but we are mostly simple layer2.  We did see a substantial drop 
in CPU, which was unexpected, but welcomed.


-Michael

On 4/28/2011 7:11 PM, Paul Goyette wrote:

Phew!

Thanks for the clarification!



-Original Message-
From: Bill Blackford [mailto:bblackf...@gmail.com]
Sent: Thursday, April 28, 2011 5:08 PM
To: Paul Goyette
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] EX 10.4R4.3

doh!

My apologizes. This should read 10.4R3.4
--- JUNOS 10.4R3.4 built 2011-03-19 22:06:32 UTC

-b


On Thu, Apr 28, 2011 at 5:00 PM, Paul Goyettepgoye...@juniper.net
wrote:

10.4R4.3 is not released software and should not be used by
anyone.  We have not yet completed the release process for
Junos 10.4R4 ...



-Original Message-
From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-
boun...@puck.nether.net] On Behalf Of Bill Blackford
Sent: Thursday, April 28, 2011 4:52 PM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] EX 10.4R4.3

Any notes from the field on 10.4R4.3 deployment?
Pros? Cons?
fixes? Features?

I saw some noise on the list recently. Anyone care to share a

summary?


Thanks in advance.

-b


--
Bill Blackford
Network Engineer

Logged into reality and abusing my sudo privileges.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp






--
Bill Blackford
Network Engineer

Logged into reality and abusing my sudo privileges.


___
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] juniper / mx series fib usage information?

[Michael Hare]

Hello-

A quick google didn't help; is there a way to tell how much space you 
have left in your FIB [absolute RAM, percentage, whatever], specifically 
for an MX with DPCs?


I am contemplating activating cymru fullbogons [v4/v6].  We currently 
carry about 350,000k v4 and 5000k v6 routes.


While initially I'm not worried, my gut tells me the v6 fullbogons feed 
will not be sustainable as it is already at 30k route for ~5k active v6 
announcements.  While their template doesn't suggest so, I plan to put 
in ingress prefix-limit maximum on their sessions to something 'reasonable'.


If I activate this, I'm hoping there is a better way to find out than 
the hard way [frantic syslogs when the FIB is full].


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

Re: [j-nsp] EX2200 series and q-in-q (802.1ad)

[Michael Hare]

Furthermore, on ex3200/ex4200, as of a few months ago, the inner and 
outer tpid's had to be the same, making interoperability with rfc 
compliant 802.1ad implementations [F10] not possible.  YMMV, I filed an 
ER but I don't think it went anywhere.


-Michael

On 2/2/2011 10:02 AM, Dan Wilkinson wrote:

I think its only supported on EX3200 and EX4200



--

Best regards

Dan



From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Stephane JAUNE
Sent: 02 February 2011 15:50
To: 'Juniper-Nsp'
Subject: [j-nsp] EX2200 series and q-in-q (802.1ad)





 Hi all,

 Does somebody know if EX2200 series support q-in-q ? we would like
to use some of them to tag customer traffic with a S-VLAN, and I only found
that 802.1Q is supported.


 Regards.

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

   _

No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1204 / Virus Database: 1435/3417 - Release Date: 02/01/11

___
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] TCP based RED profile on MX

[Michael Hare]

I first noticed this with the m120.  A workaround is to classify udp to 
a second best effort egress queue and use a different drop profile.  I 
decided to not deploy this method.


-Michael

On 12/19/2010 1:43 AM, Good One wrote:


thanks for pointing to a URL.. I was expecting that trio architecture MPCs will 
allow us to configure protocol options if not on DPC. it does not make sense to 
me drop UPD DNS queries if RED comes into play. JNPR we need protocol option on 
MXs ... ;)
thanks


Date: Sun, 19 Dec 2010 15:22:12 +0800
Subject: Re: [j-nsp] TCP based RED profile on MX
From: diogo.montag...@gmail.com
To: go...@live.com
CC: juniper-nsp@puck.nether.net

Hi,

On MX you can only configure to protocol any (see the note in the URL below).

http://www.juniper.net/techpubs/en_US/junos10.4/topics/usage-guidelines/cos-configuring-drop-profile-maps-for-schedulers.html

Regards
./diogo -montagner



On Sun, Dec 19, 2010 at 1:17 PM, Good Onego...@live.com  wrote:


just a quick one. can you configure red drop profile for tcp traffic only on 
MX-Boxes? There is a knob on T-Series so that you can define what protocol you 
want to pass through the red profile either tcp/udp but on MX i could not find 
that option so it seems if you configure a profile it will analyse/drop any 
protocol. And to me dropping a UDP packet using RED profile does not make sense 
at the moment.
___
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