Re: [j-nsp] QFX5200 switches and fresh install of OS.
On Aug 29, 2024, at 6:22 PM, Lee Starnes via juniper-nsp wrote: > > Does anyone know of and can point to a document for doing a format and > reinstall of the OS on the QFX5200 like what you can do on the EX series > switches? https://supportportal.juniper.net/s/article/Procedure-to-format-install-QFX5200-48Y-device-using-a-USB?language=en_US https://supportportal.juniper.net/s/article/EX-QFX-Procedure-to-format-install-QFX5K-device-using-a-USB?language=en_US That second one mentions 5200 in the footnotes, so even though the title doesn't say it, it might apply. I have only tested on 5100 series. Jason ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
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 layer-3 devices; all our edge switches are layer-2 (the core trunks VLANs to the edge switches; all inter-VLAN traffic is routed on the core only). Thus, the core does DHCP relay. dot1x is primarily done on our edge switches as you describe. However, we occasionally connect dumb layer 2 switches for very small closets over fiber (we're a small enough campus that all our buildings are cabled directly to the qfx), so it's nice to have the option to have a core device provide the same "edge" dot1x functionality for those devices. That one isn't as big of a deal; I could use Juniper switch with dot1x as an aggregation device if the core won't handle it. Jason ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
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 wrote to the list a while back about it) and have been trying to track them down. On some platforms you can capture the flows causing the DDOS violation, but not the QFX. We've been forced to perform random packet captures in the hope of finding the traffic on the right interface. Another bug causes DHCP relay to fail when an ACL is applied on an interface, even if the filter explicitly permits DHCP traffic. The chipset has a "feature" where IPv6 counters aren't incremented at all (they claim this is "working as designed"). Filter-based forwarding is not supported on IPv6 (the documentation on this has been corrected, but only after we escalated our case through ATAC). There's a bug where setting a 0.0.0.0/0 match in an inet firewall filter prevents ipv6 traffic from passing (incorrect hardware programming). We have to use ether-type instead in order to hack around it. There are limitations on egress filters that don't appear to apply on other platforms. Many of these issues were not stated in the official documentation, and some still aren't (you have to search KB articles to find the limitations). That makes product evaluation very difficult and is part of why I was asking the list. Most of our problems seem to center around L3 stuff (ACLs, forwarding, etc), which I why I asked about the router line. It seems like I'm asking "too much" of the QFX as a core router, though it does pretty well as a switch. The full router line is overkill for me (I don't need a full table, for example), but if it means some of these other features will actually work as designed, it might be worth it. The mx304 is an interesting option, as is the ACX line. Maybe one of the newer QFX models will fix some issues that the broadcom chipset had, but I'll need to test the heck out of that first. Thanks, Jason ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[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 question is, what would be the logical "step up" from the qfx on a small network? I'm thinking the MX240 as it's the smallest router that has redundant REs. However, I have no experience with the router family (we're all EX/QFX). I'd consider a newer member of the QFX family, but I'd need to know I'm not going to bump into a bunch of weird "unsupported on this platform" issues. Does the MX line handle all the layer-2 stuff that the QFX has, like DHCP snooping, vlan firewall filters, or even dot1x? Coming from the switching family, I wasn't sure how prevalent those features are on the layer-3 equipment, or if they're configured in some totally different way. I'm fine with EOL/aftermarket equipment; we've got a pretty traditional layer-2 spoke-and-hub setup with layer-3 for IRB and a default route to our ISP (no VXLAN, tunneling, etc). Our campus isn't growing so capacity isn't a huge issue (we're 1g/10g uplinks everywhere, and the 10g aren't close to saturation). I *might* want 40g as a handoff to an aggregation layer, but that's about it. Thus, I'm OK with a relative lack of new features. Thanks, Jason ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[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. I'd given up on it ever working, but I noticed the docs were updated to say the feature was added for the qfx5100 in 19.1R1: https://www.juniper.net/documentation/us/en/software/junos/routing-policy/topics/concept/filter-based-forwarding-qfx-series.html Well, I happen to be on 20.2R2 so I tried to configure it again and... it still doesn't seem to work. Anybody out there have FBF for IPv6 working on a qfx5100? Is there any reason it would be listed in 19.1 but not work in 20.2? There wasn't a Feature Explorer entry for this specific feature so I can't find any other info on the exact releases that support it. Now that it's EOL, I guess I could just jump to 21.2 (the last supported release) and hope for the best... Thanks, Jason ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
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 to email me off-list for that one... I'm not sure if I'm following the theory on that. >> IPMCAST-miss (lots of this one!) > > Probably punts for programming flow, and subsequent will be HW > switched. You may want to have ACL to drop all MCAST traffic at edge. > This should be 0 if you don't actually run multicast. We're applying an l2 filter at the vlan level to scrub all but well-known multicast on this switch. Can it still get to the CPU even if blocked in this manner? Or is the flow assignment done prior to l2 firewalling? >> ARP > > Self-explanatory? You shouldn't want to see this exceeded, ideally you > should police this on IFD level, but I'm not sure if QFX5k can, MX > can. Assuming there is not malicious traffic, wouldn't exceeding this counter imply that the defaults are tuned too low? We are a small school with ~1500 devices. While we might get bursts of ARP traffic at peak times (like when students move between classes), I would be surprised if it was so high as to be a concern. >> TTL > > TTL exceeded message. Normal to hit this policer in uloops. We're spoke-and-hub, static routing, so not expecting a lot of microloops due to convergence. Possible we're seeing this from "lost" packets being misrouted to our ISP (then routed back). >> Redirect > > IP redirect, you probably want to disable them at network edge. This > should be 0. Is there an easy way to find/locate IP redirects? I'm curious if these are sourced from our ISP. >> L3MTU-fail > > Egress MTU was too small for packet. It is punted for potentially ICMP > message generation. Depending on config expected or unexpected. We should be jumbo (9216) throughout, including uplink to our ISP. Any way to narrow these down? Thanks for all the replies, I'm starting to get a better idea on this. Jason ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[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 provider; we're an end site running a flat L2 network (LAN) with the QFX as our L3 core for IRB and routing to our ISP. Since the QFX is seeing all the BUM traffic I'm curious if ddos-protection is being triggered as a result of seeing all the L2 packets. In the past month we've seen violations for the following packet types: IPMCAST-miss (lots of this one!) ARP TTL Redirect L3MTU-fail RESOLVE L3NHOP I'm trying to figure out if these violations are normal in a LAN environment. For example, we have a lot of Apple devices that are sending mDNS all day long; that might trigger the MCAST counters. When our students change classes (all at the same time), that might cause a spike in ARP traffic as everyone comes online when they open their laptops. Does anyone have a link to documentation for these packet types? The Juniper docs don't give any examples; you just get descriptions like this: arp: ARP traffic So is that all ARP? ARP that the switch needs to answer for? Similar for the other packet types: are these thresholds for packets that the switch is processing (sent to the RE), or just for any traffic that is seen on any interface? If it's just an issue of too much stuff going to the RE I can firewall it off so long as I know it's spurious. Sorry if I'm not asking the right questions... I'm just trying to figure out if these errors are actually problems that I need to track down, or if the default reporting is just too noisy. Thanks, Jason ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
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 anyone have a similar issue? We have attempted (twice) to get to 17 from 14 on our QFX 5100. The first time we got to 16 and none of the interfaces would come up. TAC couldn't figure it out on the spot and we reverted. In the post-mortem they discovered that we had an "unsupported" config item (a discard interface) that essentially prevented the box from booting and bringing up any interfaces. Second time we tried we got to version 16, but then the subsequent move to 17 was a disaster. The switch ate all the DHCP traffic passing through it, rendering the network quite unusable. Again TAC couldn't figure it out during the maintenance window so we rolled back. So we're still on 16, but I haven't wanted to try another update. Sounds like we might need to just jump to 18 and see if we can skip over some of this other stuff. Jason ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
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 mismatch in speed more than the actual buffer itself (assuming we're talking about megabytes of buffer, not gigabytes). For steady state at a rate less than 1Gbps, the switch has enough buffer to handle the packets in flight. However, if packets arrive in microbursts then you can exceed the buffer briefly even though the amount of traffic is low on a larger timescale. 15MB of traffic evenly spread out over one second is not an issue, but 15MB of traffic arriving at 10Gbps at the start of a second, even with the rest of the second unused, is enough to overflow a buffer. Both rates are "15MB/s", but the arrival rate makes a huge difference. I've certainly seen tail drops on interfaces in bursts like this where it quiets down very quickly, but is enough to trip monitoring alarms. We've maxed out the buffer configs on specific ports and haven't been able to eliminate the issue (not sure if it's reduced, as it's relatively infrequent). Jason ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
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 1g to from an EX4200-24F. However, the uplink to our core is 10g, so there's a speed mismatch in terms of how fast packets can arrive in the distribution switch versus how fast they can drain. We'll frequently see tail drops on egress when a burst of packets come in until TCP does its thing and the bandwidth levels out. If you look at the bandwidth graphs, we're rarely over a hundred Mb/s, so it looks like the interface isn't maxing out. However, the packets arrive much more quickly than they can leave, so there's a bottleneck there. There really isn't any clever way around it; I think those switches have 12MB of buffer (or is that the QFX?). Anyway, if you do the math you quickly find out that works out to like 10ms of traffic, so the switch simply can't buffer even short amounts of mismatched speed traffic no matter what you do with the buffers. And at 10ms, most monitoring software simply doesn't have the resolution to catch those bursts. As you noted, the end user often doesn't notice. However, it might help explain how you're seeing loss even at low rates, yet that don't appear to adversely affect traffic. Jason ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
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&product=Junos%20OS&release=17.3R3 > > That all needs to be regularly slurped into a database of some kind, and > then you need some tools for your support agents / sysadmins to query it... > > I've not yet gone much beyond thinking up the above, but it's going to need > to be built at some stage! James, Thanks for your email. After messing around a big longer, we finally settled on polling, as you mentioned above. We started out with SNMP, but walking the tables took a fair amount of clock/cpu time. We ran some tests and found that netconf over SSH had less overhead in our setup, even when accounting for the SSH setup and teardown. We now have a script that happily sucks up the ND table once or twice a minute and parses all the entries. The netconf output had some additional items (like ageout) that help us track adds, refreshes, and deletes (much like DHCP discover, renew, and release), which works better for our linear logging. Again, you could probably do just as much with SNMP, but this was easier to script and had better performance. We haven't started on the "database" part just yet, but there are some things out there that have tried to do this: http://netdisco.org No idea if it handles IPv6 yet (been a few years since we've tried it), but on v4 it did most of the "accounting" type stuff you mentioned. Thanks, Jason ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
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 https://www.techrepublic.com/article/androids-lack-of-dhcpv6-support-poses-security-and-ipv6-deployment-issues/ Thus, we need some kind of measure to deal with SLAAC, as it seems that no Android device will do DHCPv6 (we're a school that allows BYOD, so I can't ban Android devices). On another note, since my last post I've found that Junos 17 has a feature for MLD snooping, including static subscriptions to a listening group. I'm going to need to update our QFX and see if that might get me more of what I need. Thanks, Jason ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[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. While I'm seeing plenty of neighbor discoveries, I'm not seeing any(?) neighbor advertisements. I'm guessing that because the sniffing box doesn't have an address on each VLAN, it's not participating in ND and registering for multicast, so we're getting pruned. IGMP snooping is on by default on all VLANs. I'd prefer not to have to add an interface on each VLAN just to grab all this traffic (more to keep in sync, security concerns, etc). Is there a way to tell the switch to force IPv6 multicast traffic for ff02::1 to go to a specific port? Our core is a QFX5100; the other switches in the network are a mix of EX3200/4200/3400. For the moment I've got it to work by setting up firewall filters on each VLAN in our core and port-mirroring just the ICMPv6 (type 136) traffic to a monitoring port. That works, but it's also a lot of configuration overhead. If there's a better way, I'd love suggestions! Thanks, Jason ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
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 Tom for saving me any more pain trying to figure this out. Jason ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[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 "discard" routes.
I've seen some best-practice documents where you can set up the discard (dsc)
interface to blackhole traffic, rather than using a direct "discard" route. I
thought it might be nice to use that so I could analyze the stuff that's
getting discarded (count packets, maybe even mirror or analyze the traffic).
TL;DR: I got dsc working and it is discarding, but the counters aren't
incrementing. I need to know if I'm doing it wrong or if this is a "feature"
of the qfx5100 similar to its inability to count ipv6 packets...
I've created the interface and assigned an IP with a "destination" I can route
to, and a filter to count packets:
dsc {
unit 0 {
family inet {
filter {
output sa-discard-v4;
}
address 10.255.254.2/32 {
destination 10.255.254.1;
}
}
}
}
The filter just counts:
filter sa-discard-v4 {
term default-discard {
then {
count discard-v4-default;
/* Not supported on egress on this platform */
inactive: log;
}
}
}
And I've added some rules to discard the traffic:
[edit routing-options rib inet.0 static]
+ route 10.0.32.64/32 next-hop 10.255.254.1;
That's a live IP on my network, and I've confirmed that traffic is discarded
with that route active. Alas, the counters on the interface don't budge:
qfx> show interfaces dsc
Physical interface: dsc, Enabled, Physical link is Up
Interface index: 5, SNMP ifIndex: 5
Type: Software-Pseudo, MTU: Unlimited
Device flags : Present Running
Interface flags: Point-To-Point SNMP-Traps
Link flags : None
Last flapped : Never
Input packets : 0
Output packets: 0
Logical interface dsc.0 (Index 548) (SNMP ifIndex 709)
Flags: Down Point-To-Point SNMP-Traps Encapsulation: Unspecified
Protocol inet, MTU: Unlimited
Flags: Sendbcast-pkt-to-re
Addresses, Flags: Is-Preferred Is-Primary
Destination: 10.255.254.1, Local: 10.255.254.2
Nor do the firewall counters:
qfx> show firewall filter sa-discard-v4 counter discard-v4-default
Filter: sa-discard-v4
Counters:
NameBytes Packets
discard-v4-default 00
Has anyone set this up with static routing? All the examples use BGP, but I
can't imagine why that would make a difference for the reporting if the traffic
is correctly discarded.
Thanks,
Jason
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
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) Was there any pattern to the traffic loss (e.g., every X seconds, certain types of traffic, certain percentage of all traffic)? I ask because we have a setup right now with a EX4600 VC going to a QFX5100 via 40Gb DWDM fiber. Client devices are seeing "pauses" in traffic with ICMP loss or severe delay. However, there are no CRC errors reported on either switch as mentioned in the PR. Also, we've only observed serious loss over WiFi clients so there are still plenty of possible culprits. This is our only EX4600 stack, and our first 40Gb optics, so we don't have a similar working setup elsewhere that's known to be good. Thanks, Jason ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
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 non-ELS switches) We make a lot of use of groups and templating so that the unique part of the config stays small. We reference the scripts from the group config, and use version numbers in the script names so we can have multiple versions of the same script on the device at the same time and reference them as the config changes. Finally, I crufted up some perl to help with copying and deploying the script versions to all the REs in the field so we don't have to do it manually on each switch. I believe we could reference the scripts from a central web server, but things don't change often enough and I like having a manual step in the process (for the moment) as this is relatively recent. Jason ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
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 >> those prefix-lists if needed. And also have functional ddos-protection >> configuration out-of-the-box. People who want and can could override >> and configure themselves. > > That would be really wonderful. A great start would be if there was a > way to get just the /32 (or /128) interface IP addresses in > apply-groups. I started working on a commit script that would harvest all the local interface addresses and dump them in a prefix list so you could do just this. Never got around to finishing it, but it's on my ever-growing todo list. Jason ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
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): https://www.netgate.com/products/tnsr/ https://www.netgate.com/blog/the-behemoth-router-is-here.html Jason ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
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 48 and a
> MTP-4xLC breakout cable connected to a couple of servers. The qfx5100-48t
> just can't/won't figure out the fact that I want it to channelize.
This is ringing a bell... judging from the comment in my config, have you tried
this:
chassis {
fpc 0 {
pic 0 {
/* Must explicitly set speed for fan-out interfaces to be
recognized */
port 48 {
channel-speed 10g;
}
}
}
}
Jason
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
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 12.x to 15.x and got badly burned with switches that didn't come up. JTAC told us (after the fact) that we needed to be on the VERY LATEST 12 series before making the upgrade or else there might be 'issues'. Ended up having to do a format reinstall from USB on about a third of the switches. Jason ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
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 have a few 3200s left
for trade. ;-)
I misread your earlier email; yes, you would need an irb as the L3 interface
for management where you previously used a vlan... a find and replace should
take care of that, though.
I haven't bumped into the "default VC" port issue yet, but I guess I was lucky
and chose xe-0/2/3 as my uplink.
We had some growing pains when we got a QFX5100 for our all-EX network and had
to adjust to the ELS stuff. "port" became "interface", "vlan" became "irb",
etc. Plus they moved a bunch of stuff around.
Juniper does have a conversion tool where you dump in your non-ELS config and
it will output the ELS version (requires JTAC login). It wasn't perfect, but
if you work through it by hand you can figure most of it out:
https://www.juniper.net/customers/support/configtools/elstranslator/index.jsp
Since we did the QFX a couple years ago, once the 3400s, I was familiar enough
that it wasn't a huge deal.
The commit script I wrote lets you put stuff like this in the config:
interfaces {
ge-0/0/0 {
apply-macro sa-portrole {
role static; # or trunk/dot1x
vlan some-vlan;
}
}
}
I just finished that last month, so I'm still rolling it out. Happy to share
if you think it will help. Unfortunately, it won't paper over the other ELS
differences for you; just the stuff dealing with VLANs, trunk/access, STP, and
dot1x.
Jason
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
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. Amen. I've finally written a commit script that allows me to assign roles to ports and then sets the correct config options depending on platform. That's making my life a little easier. > this coupled with what seems a requirement to enable an IRB interface > to attach the management ip address to seems ... wonky. What's this one? I don't remember having to do that part on my switch. That said, I'm currently hunting down some weird disconnect issues on my 3400s so maybe I do... Jason ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
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 dot1x process having memory leaks and some other issues, things stabilized and have been solid for a while. We dynamically assign VLANs for all printers and phones so they can be plugged into any port on campus and put on the correct VLAN. We don't use voice VLANs. There are occasional log messages about ARP inspection, but I believe it's devices that aren't renewing their leases often enough or aren't transmitting enough traffic to stay in the MAC table. We've set our monitoring software to ping or probe all printers once a minute and that keeps everything active in the MAC tables. We're also looking at cranking up the global mac aging timeout. > I've also discovered that all VLANs that might end up being assigned > to a port either statically or dynamically or via the VOIP VLAN > feature must have matching examine-dhcp/ip-source-guard/arp-inspection > settings under ethernet-switching-options secure-access-port. Yes. We have a "vlan all" for everything, and then carve out exceptions for VLANs that have old devices that use static addressing and won't support DAI. Jason ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
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. I was hopeful for a second because it looked like prefix lists were going to work (I'll take anything I can get...), but it turned out that they would match all traffic because they were looking for v4 addresses only. Once I added some terms to check for that, nothing matched. So, what we're left with is the "ether-type ipv6" match condition. Everything else fails to catch any traffic: Filter: fw-ipv6 Counters: NameBytes Packets destination-prefix-list 00 ether-type-ipv6 8224 68 from-protocol-icmp6 00 source-prefix-list 00 unmatched2244 22 What's depressing is that it looks like the 2300/3400 are the only EX switches that support any IPv6 on layer 2 filters (Phil, you mentioned the 4300, but the docs list that as unsupported as well). And people wonder why IPv6 adoption is so slow... Jason ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[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? The documentation says no, but the config says yes (at least for certain special cases). More info: We're trying to do some multifield classification on inbound traffic, and while we're at it, drop some junk (unwanted multicast) at the edge. We're a flat L2 network, so our edge devices don't do any routing. For the most part, it's EX3200 and 4200 switches that our users connect to. So, we're crufting up some 'family ethernet-switching' filter terms, and so far so good. There are match terms like "protocol icmp6" and "destination-address" which seem to be accepting IPv6 addresses without complaint. A little further in, I tried to match on "proto ipv6" and "source-port" and that wouldn't commit, claiming "source-port" is IPv4-only. A little digging (including this list's archives) turned up: http://www.juniper.net/techpubs/en_US/junos/topics/reference/general/firewall-filter-ex-series-match-conditions-support.html Which says: "On EX2200, EX2300/EX3400, EX3200/EX4200, EX3300, EX4500, and EX6200 switches port and VLAN filters on IPv6 traffic can match only layer 2 header fields." Which is a funny way of saying "we basically can't match IPv6 at all". And further down under "Platform Support for Match Conditions for IPv6 Traffic" only "layer 3" interfaces are listed as supporting IPv6 match conditions. However, the documentation is in conflict with the configuration interface and with other documentation on Juniper's site. For example, IPv6 filter-based forwarding is listed as supported in the Feature Explorer, but not on the page above. Also, the "protocol icmp6" statement that I'm using isn't listed on the official docs, and it would be weird to go to all the trouble to add it as a new feature and not have it work (though Juniper has failed me before on this one). So... is this a bug in the switch (it's accepting a config that will silently ignore IPv6 match conditions), or a bug in the documentation (match conditions that commit are supported)? I plan to test as best I can, but if someone has first-hand experience or a KB/PR to share, that would save me a lot of time... Thanks, Jason ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[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 suspect this is an issue with the device (not the switch), and I have a question for the list: Does the QFX5100 dhcp-relay or EX4200 DHCP snoop have any built-in feature that drops non-compliant DHCP packets? The device is being worked on, so I can't have it in the failure state right now to take a trace. I'm hoping someone might know off the top of their head. The device is giving itself an auto-assigned IP (169.254.36.130). Nothing wrong with that, but it's using that address as the source of its DHCPDISCOVER packets: 18:19:51.846671 00:10:7f:5b:a0:d4 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: (tos 0x0, ttl 128, id 23, offset 0, flags [none], proto UDP (17), length 328) 169.254.36.130.49152 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 00:10:7f:5b:a0:d4, length 300, xid 0x7bad5324, Flags [Broadcast] (0x8000) Client-Ethernet-Address 00:10:7f:5b:a0:d4 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Discover Client-ID Option 61, length 7: ether 00:10:7f:5b:a0:d4 Parameter-Request Option 55, length 7: Subnet-Mask, Default-Gateway, Domain-Name-Server, Domain-Name Netbios-Name-Server, Netbios-Node, Netbios-Scope Hostname Option 12, length 15: "DMPS3-A0D4-BHDH" END Option 255, length 0 PAD Option 0, length 0, occurs 21 Per RFC 2131: "DHCP messages broadcast by a client prior to that client obtaining its IP address must have the source address field in the IP header set to 0." So, does anyone know if this might cause the packets not to get relayed? Also, any opinions on the client behavior? Doesn't seem RFC-compliant, but there's plenty of that to go around so I'm not sure if that's the root cause here. Thanks for any help; I'll try to get a full trace at some point when the tech for the equipment is available to fail it back to DHCP (we have it set to static temporarily as a workaround). Thanks, Jason ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
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 with switches used for iSCSI, > such as the Cisco 3750s we started out with (despite common notions, QoS > actually has to be enabled as the 'default'/'disabled' buffers are > insufficient to deal with microbursts). We're actually starting to experience this now. We have a QFX with 10g and 1g links, and seeing significant drops on the 1g interfaces when traffic arrives on a 10g. We have QoS enabled on our WAN connection, but haven't put it on the internal interfaces (where the drops are). Do you have links to guidelines for basic QoS guidelines where you have this mismatched interface speed? I haven't had a lot of luck finding out things like underlying buffer size, so that makes troubleshooting a little tricky. Thanks, Jason ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
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 the chain at Juniper and have essentially been told that the switch is working "as advertised" and that the "feature" is not present on this platform. Of course, this wasn't noted in the documentation, isn't prevented from the configuration, and we were sold the QFX to overcome IPv6 issues we'd had on the EX4500. So that meant a lot of wasted time and frustration for us when we hit this issue. If the SRX is anything like the QFX, then you are likely out of luck. Jason ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
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 each > queue. One item of note here from someone who has been trying to shape on the EX/QFX for a while... "output firewall filters" won't work. Shaping only applies to outbound traffic. However, you cannot (on the EX platform, anyway) apply a firewall rule on outbound traffic that will classify and then shape that traffic. I used to have a diagram showing the packet flow on the EX and the "firewall" stage was shown AFTER the "shaping" stage. In other words, the output firewall is too late to have any effect on classifying packets for shaping. The firewall filter documentation hints at this: http://www.juniper.net/techpubs/en_US/junos12.2/topics/concept/firewall-filter-ex-series-understanding.html Note that the firewall points that mention CoS are inbound only. So you end up having to classify traffic as it arrives on the switch. With the classification done, you set up schedulers on the egress interfaces as Chris mentioned earlier. Sorry if that's old news, but figured this might save someone some pain down the line... Jason ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
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 with JTAC on that one. We had a 4500 that had a software bug where a bunch of bogus MACs were learned (a few thousand). However, that exposed a "feature" in the 4500's MAC-learning algorithm. They use a hash table to store the MACs and if there are too many hash collisions the switch simply gives up trying to learn the MAC. Because the fake MACs from the first bug were all sequential, it caused very poor hash performance and we had devices that couldn't get on the network because the switch refused to learn them (too many collisions). Not saying that's exactly what happened to you; more of a warning that sometimes what's going on under the hood may not be entirely obvious/sane based on the documentation. Jason ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
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 a thing. I just joined this list because of frustrations we're having with IPv6 feature parity on the QFX5100. We've run into undocumented issues and then sales tells us it was never supposed to do what we're asking for and it would be an "enhancement" to add the functionality. And that's just the bugs that could be fixed in software. Hardware issues are even worse. Jason ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
