Re: [j-nsp] Outgrowing a QFX5100
On Fri, 16 Sept 2022 at 22:12, Jason Healy via juniper-nsp wrote: Hey Jason, > 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. Yes. I don't immediately cannot think of any feature that isn't supported on MX that is supported on EX/QFX. Broadly speaking if you are not cost-sensitive, and you don't need the density, always buy an NPU box such as MX, because it's inherently more feature complete. Pipeline boxes like EX/QFX make sense if you are cost sensitive or need high density and can answer what your requirements are ahead of time and run a field trial against those specific requirements. In my experience for access providers your requirements are not a knowable variable, because you will introduce a new product during the life cycle of a device, therefore you will be carrying additional risk with pipeline compared to NPU. If you're a cloudy shop or incumbent telco you likely can have a frozen set of requirements that are knowable a-priori, which supports pipeline use-case. > 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. Your problem is the slow rate interfaces and getting reasonable support for them. With MX if you are buying from a channel for chassis boxes you should be only buying LC9600, which is 24x400GE, another alternative is fixed config MX304. Both may be highly unsatisfactory to you in the front-plate. ACX portfolio may have some middle-ground to you. -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Flowspec not filtering traffic.
Hi, We have noticed that flowspec is not working or filtering as expected. Trying a DDoS detection and rule generator tool, and we noticed that the flowspec rule is installed, the filter counter is increasing , but no filtering at all. For example DDoS traffic from source port UDP port 123 is coming from an Internet Transit facing interface AE0. The destination of this traffic is to a customer Interface ET-0/0/10. Even with all information and "show" commands confirming that the traffic has been filtered, customer and snmp and netflow from the customer facing interface is showing that the "filtered" traffic is hitting the destination. Is there any caveat or limitation or anyone hit this issue? I tried this with two MX10003 routers one with 19.R3-xxx and the other one with 20.4R3 junos branch. Regards. ___ 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
