Re: [j-nsp] QFX DDOS Violations
Hi! The leaf switches are QFX5k and it seems to be lacking some of the command you mentioned. We don't have any problem with bgp sessions going down, the impact is only the payload inside vxlan. Protocol Group: VXLAN Packet type: aggregate (Aggregate for vxlan control packets) Aggregate policer configuration: Bandwidth:500 pps Burst:200 packets Recover time: 300 seconds Enabled: Yes Flow detection configuration: Flow detection system is off Detection mode: Automatic Detect time: 0 seconds Log flows: YesRecover time: 0 seconds Timeout flows: No Timeout time: 0 seconds Flow aggregation level configuration: Aggregation level Detection mode Control mode Flow rate Subscriber Automatic Drop 0 pps Logical interface Automatic Drop 0 pps Physical interface Automatic Drop 500 pps System-wide information: Aggregate bandwidth is no longer being violated No. of FPCs that have received excess traffic: 1 Last violation started at: 2022-11-30 09:08:02 CET Last violation ended at: 2022-11-30 09:09:32 CET Duration of last violation: 00:01:40 Number of violations: 1508 Received: 3548252144 Arrival rate: 201 pps Dropped: 49294329Max arrival rate: 160189 pps Routing Engine information: Bandwidth: 500 pps, Burst: 200 packets, enabled Aggregate policer is never violated Received: 0 Arrival rate: 0 pps Dropped: 0 Max arrival rate: 0 pps Dropped by individual policers: 0 FPC slot 0 information: Bandwidth: 100% (500 pps), Burst: 100% (200 packets), enabled Hostbound queue 255 Aggregate policer is no longer being violated Last violation started at: 2022-11-30 09:08:02 CET Last violation ended at: 2022-11-30 09:09:32 CET Duration of last violation: 00:01:40 Number of violations: 1508 Received: 3548252144 Arrival rate: 201 pps Dropped: 49294329Max arrival rate: 160189 pps Dropped by individual policers: 0 Dropped by aggregate policer: 50294227 Dropped by flow suppression:0 Flow counts: Aggregation level Current Total detected State Subscriber0 0Active vty)# show ddos scfd proto-states vxlan (sub|ifl|ifd)-cfg: op-mode:fc-mode:bwidth(pps) op-mode: a=automatic, o=always-on, x=disabled fc-mode: d=drop-all, k=keep-all, p=police d-t: detect time, r-t: recover time, t-t: timeout time aggr-t: last aggregated/deaggreagated time idx prot groupproto mode detect agg flags state sub-cfg ifl-cfg ifd-cfg d-t r-t t-t aggr-t --- -- --- - - - - - --- --- --- -- 23 6400 vxlanaggregate auto no 1 2 0 a:d:0 a:d:0 a:d: 5000000 Johan On Wed, Nov 30, 2022 at 8:53 AM Saku Ytti wrote: > Hey, > > Before any potential trashing, I'd like to say that as far as I am > aware Juniper (MX) is the only platform on the market which isn't > trivial to DoS off the network, despite any protection users may have > tried to configure. > > > How do you identify the source problem of DDOS violations that junos logs > > for QFX? For example what interface that is causing the problem? > > I assume you are talking about QFX10k with Paradise (PE) chipset. I'm > not very familiar with it, but I know something about it when sold in > PTX10k quise, but there are significant differences. Answers are from > the PTX10k perspective. If you are talking about QFX5k many of the > answers won't apply, but the ukern side answers should help > troubleshoot it further, certainly with QFX5k the situation is worse > than it would be on QFX10k. > > > DDOS_PROTOCOL_VIOLATION_SET: Warning: Host-bound traffic for > > protocol/exception VXLAN:aggregate exceeded its allowed bandwidth at > fpc 0 > > for 30 times, started at... > > > > The configured rate for VXLAN is 500pps, ddos protection is seeing rates > > over 150 000pps > > Do you mean you've configured: > 'set system ddos-protection protocols vxlan aggregate bandwidth 500'. > What exactly are you seeing? What does 'show ddos-protection protocols > vxlan' say?Also 'start shell pfe network fpcX' + 'show ddos scfd > proto-states vxlan' > > Paradise (unlike Triton and Trio) does not support PPS policing at > all. So when you configure a PPS policer, what actually gets > programmed is 500pps*1500B bps. I've tried to argue this is a poor > default, 64B being superior choice. > In paradise 500pps would admit 500*(1500/64) or about 12kpps per > Paradise if those VXLAN packets were small. These would then be > policed by the LC CPU
[j-nsp] QFX DDOS Violations
Hi! How do you identify the source problem of DDOS violations that junos logs for QFX? For example what interface that is causing the problem? DDOS_PROTOCOL_VIOLATION_SET: Warning: Host-bound traffic for protocol/exception VXLAN:aggregate exceeded its allowed bandwidth at fpc 0 for 30 times, started at... The configured rate for VXLAN is 500pps, ddos protection is seeing rates over 150 000pps This is an spine/leaf setup, one theory is that the vxlan traffic that most of our QFX boxes are activation ddos protection for is actually vxlan services running inside the vxlans, for example we have kubernetes clusters using vxlan. Is that a sane theory? Johan ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Strange IGMP traffic
Hi I have a EX4550 acting as a PE router, mpls, mp-bgp, rsvp and so on. For some reason that I can't figure out this device have started to try to send out IGMP traffic to a host on Internet, all traffic is towards one specific host. The traffic is coming from one of the linknet address on the physical mpls network, so not from any VRFs, it is currently blocked by firewalls but I can't figure out why this is happening. I can't find any trace of this traffic on the device itself, but I can see all the attempts in our firewall logs. Any ideas? Johan ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX SCBE firmware error
No it's an older card, but I can't find firmware requirements anywhere. Johan On Thu, Jul 2, 2020 at 3:13 PM Jared Mauch wrote: > Is this a newer one? I’ve seen vendors release revised boards that have > the same part number but require newer software. > > - Jared > > > On Jul 2, 2020, at 8:19 AM, john doe wrote: > > > > Hi > > > > I just started up an SCBE we had on the shelf, has anyone seen this error > > before? > > > > Major CB 0 SG2P Revision unsupported > > > > CB 0 REV 20 750-031391Enhanced MX SCB > > > > Isn't the firmware usually bundled with software upgrades? Is there a > > way to upgrade the SCBE? > > > > Johan > > ___ > > 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] MX SCBE firmware error
Hi I just started up an SCBE we had on the shelf, has anyone seen this error before? Major CB 0 SG2P Revision unsupported CB 0 REV 20 750-031391Enhanced MX SCB Isn't the firmware usually bundled with software upgrades? Is there a way to upgrade the SCBE? Johan ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Ramp up old MX480
Thank you for all answers! Is there any licenses required for MPC-3D-16XGE-SFPP, or is the "reduced scale L3" only a gentlemen agreement? Johan On Wed, Aug 28, 2019 at 5:27 PM Tobias Heister wrote: > On 28.08.2019 17:10, Brian Johnson wrote: > > Do you know if you have the enhanced mid-plane? If not, it’s a chassis > upgrade to install MPC3 or better line cards. > > There is no need to upgrade the chassis even with old midplane. The worst > you get is performance impact on MPC4/5E on SCBE2 or MPC10E on SCBE2/3. > All MPCs will work on old midplane (some with reduced capacity) > > MPC7E and the already proposed 16 Port 10GE MPC (technically a quad MPC2 > trio cramped into one card) work fine on the old mid-plane. > > You will loose support for some linecards when upgrading fabrics (e.g. no > DPC from SCBE2 onward, and no MPC1/2E(non NG) from SCBE3 onward) > > If you only need some 10GE Ports you could just use the 16 Port 10GE Cards > with the existing SCB and deactivate/use 8 of the ports. The cards are > probably cheap enough on the second hand market to justify it. > If you can get used SCBEs you can go up to 12 Ports (1+1 fabrics) or 16 > Ports (2+0 fabrics) if memory serves well. > > For new cards cheapest per port price typically comes from MPC7E ... but > overall costs depend on target number of 10GEs. > Cooling/Filter and Power supplies will need upgrading as already mentioned > from others. > > -- > Kind Regards > Tobias Heister > ___ > 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] Ramp up old MX480
Hi! I need to bump one of my MX480 with better line cards so it can live in the DFZ another year or so :) Services running are MPLS/RSVP, DFZ and so on. Existing is: RE-S-1800x2 MX-SCB DPCE-R linecards I'm thinking refurbished hw. I only need 10G-ports, what MPC generation would be suitable to swap to? Do I need to change SCB? Is the RE ok? Johan ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] MTU issue
Hi So I have some kind of MTU problem. The setup is a Cisco on one side and a MX one the other. Between them are a 10G wavelength. MPLS, RSVP is running and the ERO of my LSP is taking the direkt path between the boxes. All interfaces on both sides are well above 8000 in MTU, MPLS MTU on Cisco and Juniper side is also above 8000. Both boxes are PE routers. If I do a ping sweep from other routers connected to Cisco-router aswell as juniper-router to respective router both can show a sweep result that is above 8000, but not the path between them. If I make a ping sweep from the juniper to the Cisco on a LSP taking the direkct path I get this: 100! 5052. 2576. 1340! 2580. 1960. 1652. 1496! 1576. 1536. 1516! 1528! 1540. 1536. 1532! --- lsp ping sweep result--- Maximum Transmission Unit (MTU) is 1532 bytes What could cause the Low MTU? Johan ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Junos 15.1 and DPC
Hi Will 15.1 work well on MX boxes with old DPC cards? Anyone running 15.1 on MX with DPC? Johan ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Cisco ASR 9001 vs Juniper MX104
Hey mate, What was the reason? From what I can gather 9K is pretty much a copy of MX range. Considering the MX960 shipped before the ASR9000, doubtful. Yup, that's what I wrote ) XR is very JunOS like. Hmmmh, not quite. There are still some major cosmetic differences, and a few similarities, and definitely different fundamental architectural principles. Both are okay for their platforms, but I wouldn't go as far as saying they "alike". Yeah, I was just referring to cli experience. commits, rollback, hierarchy within. Prior XR IOS was wall of text, no? Real curious how these boxes do in the wild since looks i'll be doing lots of SP related stuff in the near future. As a BNG, the MX struggled for a long time. The ASR9000 was slightly better at this; although between the two, the ASR1000 is likely to be a more sensible option if you want a BNG that has "experience". Hm, I hear good things about Subscriber management on MX for config options and scale. Some are still running ERX boxes to this day. Overall, they both have their places. Personally, in 2015, I prefer the MX as an edge router, especially after we got the Policy Map feature (ingress QoS marking for various protocols) introduced into Junos. What puts me off the ASR9000 is the long IOS XR upgrade process (which I could live with if I was asked) and the poor implementation at LAG-based policing (deal-breaker). As a peering router, I don't mind either - we deploy MX's, ASR1000's and ASR9000's in this role, and happy with either of them. Thanks for taking time to write this up. Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Cisco ASR 9001 vs Juniper MX104
Hey mate, What was the reason? >From what I can gather 9K is pretty much a copy of MX range. XR is very JunOS like. Real curious how these boxes do in the wild since looks i'll be doing lots of SP related stuff in the near future. Sent using Zoho Mail On Tue, 01 Dec 2015 13:14:47 +0100 sth...@nethelp.nowrote ASR9010 is much better product than MX960 -i.e. much better than MX104, so if space or power consumption is not a concern I wouldn 1ryt think twice. People clearly have differing opinions on this issue. We got rid of our ASR9010s and kept our MX960s. YMMV. Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Cisco ASR 9001 vs Juniper MX104
On 30/Nov/15 22:56, Amos Rosenboim wrote: I don't think ASR1K is comparable to MX. I think the ASR1000 is comparable to the MX104 specifically. Both are platforms that are suited to a mix of Ethernet and non-Ethernet ports in a cost-effective manner. Where the ASR1000 edges our the MX104 is that there are various variants of the chassis, supporting low-, mid- and high-end forwarding capacities, native additional services such as IPSec, NAT, e.t.c. I think price wise MX is a better deal. ASR fully loaded with cards and licences for various services gets expensive fast. The Juniper platform we position against ASR1K is the Juniper SRX. That is not really the ideal comparison, if you ask me. If you want to pit something against the SRX, for better or worse, I'd do the ASA. Mark. Buddy runs SRX in small SP as a NAT box. Pretty happy with it. Also apparently better multicast performance than ASA. Had a customer running SRX 650 with full BGP and MPLS on top of FW/VPN. I don't think ASA can do the same. I had some tests on high end ASA back in 09. Couldn't do line rate 10Gbps across all packet sizes. We ended up using ASR 1K for it. Now with all the NG stuff I'm very skeptical about the future of ASA aka PIX v2. Sure they've sandwiched it with SourceFire, but wasn't it tried before with ASA CX? ___ 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] Cisco ASR 9001 vs Juniper MX104
Hey guys, Working on a project here and it's more or less SP focused, Which is not a muscle I've worked on lately, mostly been doing campus stuff. Looking at MX104 vs ASR 9001 as a potential solution. Requirements are fairly straightforward - 1GE to collect customers and 10GE going northbound (up to 30 Gbps), full MPLS and IP stack, possibly Carrier NAT. Customer wants a box that will give them most room to grown in terms of scale/features. And we can't go full modular since rack space is big pain for these guys. Price is also an issue (as usual) I heard good stuff about Juniper SP gear, while not so complimentary things of ASR. But that was when platform was introduced and they had all sorts of IOS-XR adventures. Would love to hear some input from here as vendor claims are conflicting (nothing new here I guess) Cheers p.s. Anyone with experience on ISSU on these platforms? I've done some googling and it seems like on both platforms it's dependent upon line cards you use. Plus most of the stuff I found was covering big chassis systems, not the low range. Sent using Zoho Mail ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
