Re: [j-nsp] Outgrowing a QFX5100

On Sep 20, 2022, at 1:36 PM, Chuck Anderson via juniper-nsp wrote: > Why would you want DHCP snooping or dot1x on a campus core router? Those > functions are typically implemented at the access layer switches connected > directly to end users. My understanding is that DHCP relay only works on

Re: [j-nsp] Outgrowing a QFX5100

On Sep 20, 2022, at 12:57 AM, Mike Gonnason wrote: > Do you have any more details about what limitations you are encountering on > the QFX? Is it hardware related or software? The example that spurred my email was DDOS protection on the QFX. We're getting lots of L3NHOP errors (still, I

[j-nsp] Outgrowing a QFX5100

Looking for a little wisdom from the list. We're a small school campus that's been running a QFX 5100 as our core switch/router for several years. It's been a good piece of equipment but we continue to hit weird limitations and I'm wondering if we're pushing the platform too hard. My

[j-nsp] IPv6 Filter-based Forwarding on QFX5100

Looking for anyone with real-world experience on this. I've been wanting to do filter-based forwarding (aka policy-based routing) on my QFX 5100 for a while. It works on IPv4, but didn't on IPv6. That means you can't have a firewall rule with a "routing instance" terminating action in v6.

Re: [j-nsp] Decoding DDOS messages

Saku, Thank you for your responses. I'm trying to learn about this as I go... On Mar 18, 2020, at 10:39 AM, Saku Ytti wrote: > > Your L2 should be in its virtual-switch/vpls (doesn't imply VPLS) > instance with forwarding-plane filter policing BUM. But unrelatd to > subject. You might need

[j-nsp] Decoding DDOS messages

Questions about the ddos-protection "features". We're on a qfx5100-48 running 16.1. I know that folks on the list aren't always big fans of ddos-protection; I'm just trying to understand what is triggering it so I can make decisions about tuning/disabling/ignoring it. We are not a service

Re: [j-nsp] Rock-solid JUNOS for QFX5100

On Aug 13, 2019, at 1:50 PM, Dan Římal wrote: > > Model: qfx5100-48s-6q > Junos: 17.3R3-S4.2 > > Creating vlan means stop forwarding traffic for approx 3 seconds probably on > trunk ports with allowed all vlans, or something like this. Pretty bad for > bfd going through this ifaces. > > Does

Re: [j-nsp] Tail drop on EX3400

On May 30, 2019, at 2:23 AM, Saku Ytti wrote: > > 12MB / 1Gbps == 96ms. That would be massive buffer. Not if you're Arista... ;-) You're correct that it's 96ms for the 1Gbps side, but if packets are arriving at 10Gbps then that's only 9.6ms (ish) before you run out of buffer. It's the

Re: [j-nsp] Tail drop on EX3400

On May 28, 2019, at 10:17 PM, Philippe Girard wrote: > > I've asked all of those questions but I can't seem to get a clear answer. One additional question: what is upstream from the 1g interface that's showing drops? Is it 10g (or larger)? We have several small buildings that we're feeding

Re: [j-nsp] Mirroring IPv6 neighbor advertisements

On Apr 16, 2019, at 12:46 PM, James Stapley wrote: > > This is the most relevant SNMP OID I've found: > https://apps.juniper.net/mib-explorer/navigate.jsp#object=ipNetToPhysicalTable=Junos%20OS=17.3R3 > > That all needs to be regularly slurped into a database of some kind, and > then you need

Re: [j-nsp] Mirroring IPv6 neighbor advertisements

On Mar 22, 2019, at 9:25 PM, Crist Clark wrote: > > Maybe you should be looking at DHCPv6 if you want those kinds of logs. We did. ;-) However, Google seems quite set on not supporting it on Android: https://issuetracker.google.com/issues/36949085

[j-nsp] Mirroring IPv6 neighbor advertisements

We're starting to play around more with IPv6, and one thing we're missing is a log of who has which address. In IPv4 we have DHCP and can check the logs, but we're using SLAAC for v6 so that's not an option. I set up a quick trunk interface with all our VLANs as members and started sniffing.

Re: [j-nsp] dsc interface on qfx5100

On Oct 12, 2018, at 9:07 AM, Niall Donaghy wrote: > > Yes we (large ISP) tried using dsc interfaces (MX series) to count RTBH > traffic and found, 1) they don't count, and 2) IPv6 is unsupported for dsc. That's what I needed to know! Back to standard discard routes it is... Thanks to you and

[j-nsp] dsc interface on qfx5100

I'm more of a layer-2 guy, but I'm trying to tighten up a few things on our qfx5100 that acts as our l3 core here at our campus. We use RFC1918 space internally, but I'd like to discard any traffic to these ranges if they aren't one of our known subnets. I have that working with standard

Re: [j-nsp] 40G QSFP problems on QFX5100 after 16.1R6

On Aug 22, 2018, at 4:52 AM, Sebastian Wiesinger wrote: > > apparently there is now a PR for this: PR1309613 I realize you may not have the answers, but if you do... 1) Does this affect platforms other than the QFX? 2) Were you seeing the CRC count increase in all cases of traffic loss? 3)

Re: [j-nsp] How to maintain scripts

On Jul 13, 2018, at 4:43 AM, amor...@orion.amorsen.dk wrote: > > Maintaining scripts is a bit of a pain. > > Do you have scripts on most of your devices? We do, but we're a campus not a provider, so: - we don't upgrade code versions often - things are pretty homogenous (except for ELS vs

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

On Jul 12, 2018, at 10:09 AM, Benny Amorsen wrote: > > Saku Ytti writes: > >> I think best compromise would be, that JNPR would offer good filter, >> dynamically built based on data available in config and referring to >> empty prefix-lists when not possible to infer and customer can fill >>

Re: [j-nsp] [c-nsp] Leaked Video or Not (Linux and Cisco for internal Sales folks)

On Jun 29, 2018, at 8:49 AM, adamv0...@netconsultings.com wrote: > > Just wondering what's the latest on the GPU for packet forwarding front (or > is that deemed legacy now)? Waiting for the bare-metal version of this to land (you can test it on AWS right now):

Re: [j-nsp] Channelizing a 40GbE port

On Feb 8, 2018, at 10:46 AM, Jonathan Call wrote: > > Juniper has instructions on how to disable auto-channelization on the QFX > series, but there doesn't appear to be a way to force (or even encourage) > channelization. I have a qfx5100-48t with a QSFP-40G-SR in port

Re: [j-nsp] Software Upgrade failures on EX4200

On Sep 27, 2017, at 1:56 AM, Kamal Dissanayaka wrote: > > The issue with this is remote upgrades. Remote upgrades fails randomly and > some has to visit the sit to fix it. Is there any way fix it ? What version were you running previously? We bumped all of our 4200s from

Re: [j-nsp] Moving onto EX2300

> On Sep 20, 2017, at 10:10 PM, Chris Morrow wrote: > > man.. I'd like to take a gander at your setup.. because I'm fairly > certain I'm going to send this 3400 back and work out my anger on some > firewood. :) Mail it my way; I'd be happy to have a spare! I probably

Re: [j-nsp] [JUNK] Re: Moving onto EX2300

On Sep 20, 2017, at 2:18 PM, Chris Morrow wrote: > > I found the 3400's are painfully different from 3300/3200's.. with > respect to vlans, trunks and access port assignment into said > vlans.. and actually getting traffic to traverse a trunk port to an > access port.

Re: [j-nsp] EX4200: Ricoh printers, DHCP Snooping, dot1x Dynamic VLAN assignments

On Jul 10, 2017, at 8:22 PM, Chuck Anderson wrote: > > Is anyone using EX4200 with DHCP Snooping + dot1x Dynamic VLAN > assignments? Yes, we've been running that setup for several years on EX3200 and 4200 VC setups campus-wide. During the first year we hit several bugs with the

Re: [j-nsp] EX3200/4200 ipv6 match conditions in family ethernet-switching

On Apr 10, 2017, at 7:51 AM, Phil Mayers wrote: > > My memory is hazy, but I think we saw the CLI accept but ignore partial v6 > config, same as you are seeing, so I'd guess CLI bug on that score. Ugh. I whipped up a quick filter with anything ipv6 that would commit.

[j-nsp] EX3200/4200 ipv6 match conditions in family ethernet-switching

I've been burned plenty of times by the (lack of) IPv6 feature parity, so I'm hoping the list's collective wisdom can save me from a lot of extra testing and phone calls with JTAC... TL;DR: are ANY layer 3 match conditions supported for IPv6 in family ethernet-switching on the EX3200/4200?

[j-nsp] DHCP relay helper ignoring non-zero source address?

I'm troubleshooting a network issue with an appliance that isn't getting on our network. We've already solved one problem (hash-collision causing the MAC not to be learned), and JTAC is working on that. However, even with that worked around, the equipment isn't getting a DHCP address. We

Re: [j-nsp] QoS when there is no congestion

On Nov 14, 2016, at 6:19 PM, Ross Halliday wrote: > > This is called a "microburst", and WILL cause packet delay and reordering if > the buffer isn't large enough. Anyone operating an IP SAN should be familiar > with this concept. This is a big issue issue

Re: [j-nsp] Filter based forwarding for IPv6 with SRX

On Sep 15, 2016, at 10:19 AM, Mircho Mirchev wrote: > > Has someone ever tried to do FBF for inet6 on SRX? I don't have an SRX, but we do have a QFX5100. We tried to set up IPv6 FBF and, although the configuration is accepted, it does not work. We've raised this issue up

Re: [j-nsp] ACX2200 - bandwidth control at subinterfaces

On Aug 25, 2016, at 10:22 PM, Chris Kawchuk wrote: > > I think you can still shape per-queue (i.e. [edit class-of-service > schedulers] best-effort shaping-rate XX;); so, using some output firewall > filters, you can put different VLANs into different queues, and shape

Re: [j-nsp] EX4550 - global or per-vlan mac table?

On Aug 22, 2016, at 4:41 AM, Jeff wrote: > > Can someone confirm this? Will a static mac entry for the router work if I > just add it to any random vlan or do I have to add an entry for each vlan > individuelly although the mac stays the same? Might want to double-check

Re: [j-nsp] ACX50xx l2circuit counters

On Jun 20, 2016, at 1:12 PM, Saku Ytti wrote: > > If JNPR would list them, people might unfairly assume vendor who does > not, is superior. > > We really should have community pages documenting devices and their > limitations. Like dpreview for networking kit :/ I would love such