Re: [j-nsp] MX204 sFlow and BGP attributes

--- Begin Message --- We end up backfilling the ASN data in with pmacct - you can hook it up to a BGP full table, and it'll readd the source/dest ASN based on that. On 10/21/2020 12:08 PM, Gerald wrote: Coming from Foundry/Brocade we have still an sFlow monitoring in production. Our new MX204s

[j-nsp] 10k FPC vs routing table

We hit a weird issue recently where the FPC and routing table do not agree on the nexthop for a route: > show route 68.232.191.191 68.232.191.0/24    *[BGP/170] 6d 23:14:33, localpref 100, from   AS path: 64515 64514 I, validation-state: unverified     >

Re: [j-nsp] JunOS interop problems with RFC5549

On 2/19/2019 4:08 PM, Bjørn Mork wrote: Brian Rak writes: They both negotiate the Extended next hop capability, and JunOS accepts the routes just fine if I make Cumulus only send 16 byte nexthops (still IPv6, just not containing a link-local address) Ah, right. And the RFC2545 requirements

Re: [j-nsp] JunOS interop problems with RFC5549

On 2/19/2019 3:19 PM, Bjørn Mork wrote: Brian Rak writes: I'm running into an issue where JunOS will not accept BGP updates containing a MP_REACH_NLRI attribute with a 32 byte nexthop.  As soon as I send one, the session gets closed and the following logged: rpd[16187]: bgp_read_v4_update

[j-nsp] JunOS interop problems with RFC5549

I'm running into an issue where JunOS will not accept BGP updates containing a MP_REACH_NLRI attribute with a 32 byte nexthop.  As soon as I send one, the session gets closed and the following logged: rpd[16187]: bgp_read_v4_update:12111: NOTIFICATION sent to fe80::ae1f:6bff:fe8a:435d

[j-nsp] QFX10k PFE

I have a 10k8 that's showing "data error" discards in `show pfe statistics traffic`.  JTAC gave me the very unhelpful suggestion to run packet captures and try and guess what's getting dropped, which isn't really something that's feasible to do (nor am I even sure the packets would show up

[j-nsp] QFX5200 and 100mbit management link

Is anyone successfully using a 5200 with a 100mbit (cat5) management link? We've been unable to get this to link up to anything at 100mbit. JTAC swears they have it working in the lab, but we're up to 10 or so 5200's that won't do it. It's documented as being a 10/100/1000 link, and from

Re: [j-nsp] QFX5110 : Q-in-Q in VXLAN

Are you trying to push multiple .1q tags onto the VXLAN traffic? (meaning you're trying to add a C-VLAN *and* a S-VLAN)? If so, JTAC has told me that QFX series devices (apparently the entire line...) do not support adding multiple .q1 tags On 9/10/2018 2:32 PM, Olivier FRUQUET wrote:

Re: [j-nsp] QFX5110 / VXLAN

Are the QFX5200/QFX5210 also only layer 2 EVPN-VXLAN? On 8/7/2018 1:42 PM, Richard McGovern wrote: Correct. For this functionality one needs either a 10K/MXPTX or EX9200 at current time. These situations may also require EVPN-MPLS, versus EVPN-VXLAN. QFX5110 is limited to EVPN-VXLAN at

[j-nsp] QFX10k8 GRE tunnels

Is anyone successfully using GRE tunnels on a QFX10008 running 17.4? I configured one, and traffic works normally from the control plane, however data plane traffic seems to just get dropped. So, ping from the router itself works fine, but it won't actually route any other traffic over the

Re: [j-nsp] Managing large route-filter-lists

On 5/22/2018 11:46 AM, Brian Rak wrote: On 5/22/2018 10:03 AM, Brian Rak wrote: On 5/22/2018 12:58 AM, Phil Shafer wrote: Brian Rak writes: The downside seems to be that these can blow up the router somehow... Not blow up, but obfuscate.  Imagine a user (or support person) who

Re: [j-nsp] Managing large route-filter-lists

On 5/22/2018 10:03 AM, Brian Rak wrote: On 5/22/2018 12:58 AM, Phil Shafer wrote: Brian Rak writes: The downside seems to be that these can blow up the router somehow... Not blow up, but obfuscate.  Imagine a user (or support person) who is unaware that ephemeral databases are in use

Re: [j-nsp] Managing large route-filter-lists

On 5/22/2018 2:48 AM, Pavel Lunin wrote: Hi list, Anyone knows if this "ephemeral configuration" thing is just a new fancy hipster-ish name of the dynamic database feature, which has been in JUNOS since 9.x and never really been widely used in production by normal people? -- Kind

Re: [j-nsp] Managing large route-filter-lists

On 5/22/2018 12:58 AM, Phil Shafer wrote: Brian Rak writes: The downside seems to be that these can blow up the router somehow... Not blow up, but obfuscate. Imagine a user (or support person) who is unaware that ephemeral databases are in use and resorts to pulling out hair, muttering

Re: [j-nsp] Managing large route-filter-lists

On 5/21/2018 3:37 PM, Vincent Bernat wrote: ❦ 21 mai 2018 14:51 -0400, Brian Rak <b...@gameservers.com> : We switched this over to using ephemeral configs: https://www.juniper.net/documentation/en_US/junos/topics/concept/ephemeral-configuration-database-overview.html This seems t

Re: [j-nsp] Managing large route-filter-lists

ase, but that alone is currently using up around 16% of the available space in /var/rundb On 5/21/2018 2:51 PM, Brian Rak wrote: We switched this over to using ephemeral configs: https://www.juniper.net/documentation/en_US/junos/topics/concept/ephemeral-configuration-database-overview.html This se

Re: [j-nsp] Managing large route-filter-lists

... hidden', and then offline create intersection of IRR data and received prefixes and only upload the intersection, in our case this would mean configuration size reduction of some 90%. On 21 May 2018 at 18:46, Brian Rak <b...@gameservers.com> wrote: What is the best way to manage large n

[j-nsp] Managing large route-filter-lists

What is the best way to manage large numbers of large route-filter-lists effectively? We've been generating per-peer route-filter-lists based on IRR data, and loading them via netconf.  However, I'm noticing that commits take longer and longer, and that we're hitting weird junos errors around

Re: [j-nsp] QFX5100 buffer allocation

On 5/17/2018 2:58 AM, Thomas Bellman wrote: On 2018-05-17 02:41, Brian Rak wrote: We're not even doing 10gbit of traffic, so the buffers should last at least a little bit. And you're not hitting 10 Gbit/s even under very short bursts of a few milliseconds? Microbursts like that don't show

Re: [j-nsp] QFX5100 buffer allocation

On 5/16/2018 7:02 PM, Thomas Bellman wrote: On 2018-05-16 18:06, Brian Rak wrote: We've been trying to track down why our 5100's are dropping traffic due to lack of buffer space, even with very low link utilization. There's only 12 Mbyte of buffer space on the Trident II chip. If you get

[j-nsp] QFX5100 buffer allocation

We've been trying to track down why our 5100's are dropping traffic due to lack of buffer space, even with very low link utilization. It seems like they're classifying all our traffic as best-effort: > show interfaces xe-0/0/49:0 extensive     Carrier transitions: 1, Errors: 0, Drops:

[j-nsp] Fwd: Hula Networks- Juniper Sale follow up

Huh, that's weird. I'm getting vendor spam within hours of signing up for this list. Forwarded Message Subject:Hula Networks- Juniper Sale follow up Date: Wed, 8 Mar 2017 19:20:16 + From: Scott J. Hobin To: b...@gameservers.com

Re: [j-nsp] QFX 5100 uRPF

On 3/8/2017 1:48 PM, Hugo Slabbert wrote: On Wed 2017-Mar-08 12:38:52 -0500, Brian Rak <b...@gameservers.com> wrote: Is anyone successfully using rpf-check on QFX5100's? I'm getting some really weird behavior.. If I enable uRPF, then disable it again, the device still a

[j-nsp] QFX 5100 uRPF

Is anyone successfully using rpf-check on QFX5100's? I'm getting some really weird behavior.. If I enable uRPF, then disable it again, the device still appears to continue to enforce it. (Spoofed packets continue to be blocked). I have to restart the device in order to fully remove RPF.