Re: [j-nsp] SRX - CPU utilization exceeds
That's flow based not packet based. You're running it as a firewall rather than router therefore any of the typical thinks that overwhelm stateful devices - rapid session setup, high levels of ICMP with embedded headers to decapsulate, etc - could be causing it. -- Sent from my mobile device, please excuse brevity and typos ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX - CPU utilization exceeds
Datasheet numbers are often optimistic. Is the device forwarding in flow or packet mode? If flow mode, what type of firewall services (appfw, IDP, etc.) and what is the session rate like? What does the bytes/packet distribution look like? On 19 September 2017 08:47:51 WEST, sameer mughalwrote: >Thanks a lot for the reply. > >However, as per the available SRX datasheet they can manage 300Mbps >throughput so why it is showing high CPU in btw 60 to 70 Mbps. This is -- Sent from my mobile device, please excuse brevity and typos ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX 3300 vs EX 3400 for access layer
On 14/09/17 16:54, John Kristoff wrote: Friends, Our engineering team is reviewing and contemplating whether to stick with the Juniper EX 3300 switch at the edge access layer (to user wired ports, some VoIP phones, and some wireless APs also connect to these). Typically these devices can last out in the field for five or more You haven't mentioned it, but worth noting that the EX3300 cannot filter IPv6. This is a hardware limitation, and caused us to reject the EX3300 in favour of the (frankly rather overkill) EX4300. I believe this is resolved in the EX3400, but we haven't had one in for testing. ___ 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 10/04/17 02:10, Jason Healy wrote: 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). I can't speak to the 3200, but I do know the EX3300 definitely does *not* support v6 matches in family ethernet-switching. We went through a long discussion about this with Juniper and eventually it was confirmed this was a forwarding hardware limitation by both JTAC and our account team. We stopped buying them as a result (fortunately we had only bought a few). Since the 3200s are older than 3300s, I'd guess the answer is no. 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. FWIW the EX4300 does not have this problem. Haven't tested the EX3400 yet but I'm hoping they've got parity there, too... I agree the Juniper docs are confusing on this topic (and many others sadly...). I cannot decide if this is just poor writing or a deliberate attempt to disguise the lack of feature parity by being as confusing as possible... Part of the discussion we had with Juniper on the topic was confirming exactly which interpretation of the docs you reference was correct, and the answer was "the one without IPv6 support" :o( Cheers, Phil ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] EX4300 SFP+ sometimes recognised incorrectly on boot w/ 14.1X53-D40.8
All, This is an odd one - we are having a hard time reproducing it on the bench, but we've seen it on production hardware quite a bit. Some portion of the time, with an EX4300 VC running 14.1X53-D40.8, we're seeing VC members boot and mis-detect the SFP/SFP+ module in the PIC (4x 1/10G SFP). We'll see modules mis-detected as 1G when they're 10G and thus the interface fail to come up; an SFP re-seat or PIC restart is required to clear the issue. I have a very, very vague suspicion that it might be corruption of an on-flash file due to sudden poweroff (i.e. removing the plug) but this is completely unsubstantiated. Exact same HW combos (switches, SFPs) were working fine on previous 13X releases. We're still trying to repro and are going to open an initial exploratory case with Juniper, but just in case, is anyone seeing SFP/SFP+ mis-detected on this HW/SW combo? Cheers, Phil ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] VC ports on EX4300
On 14/02/17 11:34, Anthony Johnson wrote: If you're skirting the 150 meter line, I would HIGHLY recommend going single mode also. It will save you headaches down the line. Personally I would recommend singlemode pretty much everywhere. Unless you are using a *seriously* large amount of fibre and xcvrs the cost savings just aren't worth the distance hassles IME. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] VC ports on EX4300
On 14/02/17 11:17, Valentini, Lucio wrote: Hi there, I was wondering what speed of VC port is necessary if I have 10 Gbps Well, that depends on your use-case; if you're only moving 100Mbps between VC members then you don't need 40Gbps VC ports. You really need to understand your traffic pattern to make an informed choice here. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX104 capabilities question
On 07/07/16 02:21, Gavin Henry wrote: That last sentence is quite a sweeping statement about C. The underlying basis for the statement - C is a hard language to program well - is not at this point a controversial one, IMHO. You can make great software in any language. I think this argument is false. I think the argument has a lot going for it. C is a difficult language to use well; even developers with decades of experience get caught out by the subtleties of things like pointer aliasing and integer behaviour. There's a huge research effort by smart people to improve that situation - as an example, things like ubsan in Clang to detect and warn on use of undefined behaviour. John Regehr's blog is a good read on the topic of how gnarly C can be, for those interested. I think it's totally reasonable to argue that other languages can fit a problem set better than C, can reduce the cognitive load on the developer, and can prove more amenable to things like static analysis and automated testing. Other languages could include, here, a restricted subset of C with least-surprise behaviours. But TBH, given the focus on multicore, I think a language with better support for concurrency would be a more appropriate choice (Erlang was mentioned; it's a shame that never took off, it's really ideally suited for the task of network protocol speaker). Developers are people, and recognising the human limits of the process is important. Frankly, I would agree with the notion that C is a very poor choice for almost anything outside hardware-level work (kernel, driver) these days, simply because CPU is cheap, and human cognition expensive, and higher level languages trade costs in former for savings in the latter. Cheers, Phil ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4600 QSFP+
On 10/06/16 17:06, Kevin Day wrote: This is kind of a hack but probably would work: http://www.10gtek.com/qsfp-extender One of these on each end with 10G ZR or 80km DWDM optics. Ha, that's quite clever. Thanks for the link, potentially useful thing to have in the toolbox. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4600 QSFP+
On 10/06/16 16:55, Paulhamus, Jon wrote: Hello Group - Is anyone aware of any optics for an EX4600 QSFP+ that reach 80km? I have never seen such a thing. Traditional line-encoding would I think need dispersion compensation for that bitrate at that distance; you may end up using a DWDM muxponder w/ coherent line-side or similar if you really need to reach that distance on 40G. Interested to hear if anyone else knows of a pluggable that works at that bitrate/distance combo, though? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Commit script portability between ELS and non-ELS platforms
On 07/06/16 21:51, Rob Foehl wrote: Does anyone have any clever methods for probing Enhanced Layer 2 Software support from a commit script on QFX/EX in order to generate changes appropriate to the platform? Specifically looking for something beyond checking hardware and version numbers, or for pieces of config hierarchy that might not be present on any given box either way. ...returns substantially different XML b/w ELS and non-ELS IIRC. An EX3300: http://xml.juniper.net/junos/12.3R12/junos;> http://xml.juniper.net/junos/13.2X51/junos;> That's how our off-box Junoscript code decides between ELS and not. Should be easy enough from an op/commit script. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX 1500
On 19 May 2016 23:01:31 BST, Dale Shawwrote: srx1500 uses the new disaggregated software model, so it's $11K for hardware only; you still need to buy software (Junos). The prices we've seen for the mpls license on the 1500 are an eye watering multiple of the hardware cost. Nearly double. Same for the 345. Slightly less objectionable for the 340. They appear to be charging the software license per-megabit/s :o/ This substantially reduces the attractiveness of the range for me. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4600 Vs QFX 5100 VS ACX 5048
On 10/05/16 21:47, Aaron wrote: I have been curious about the cisco catalyst 6800 line… seems that the 6840 might fit this realm of smaller mpls pe… not sure of price… The Cat6k including 6840 can certainly do a fair number of MPLS features, we use their older brother (6880, sup2T) and for a little while longer predecessor (sup720) as MPLS PE in L3VPN (inc. 6vPE), MVPN and some small amount of L2VPN (mainly EoMPLS) IIUC the layer2 and MVPN stuff is lagging the state of the art quite a bit on that software train, which might be an issue for you. The per-port cost will be relatively high compared to a merchant silicon-based device, but the features tend to be a bit better. Port density is also kind of low on the cat6k sadly. They also run plain old IOS, with it's paucity of modern comforts (like any form of API, or transactional commits, etc.). Slightly weedy CPU, especially if you use Netflow on them (do not get me started...) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SNMP walk on JunOS from inside a routing instance
On 27/04/16 16:58, Per Westerlund wrote: That is default behavior, but you can access other RI's interfaces by explicitly using the RI name. No way to reach all IFs at once via a RI. I'm a bit confused now. I just tested (SRX240H running 12.3X48-D15.4) and I can see all interfaces when hitting an IP inside a routing-instance, as well as in inet.0. We do *not* have "routing-instance-access" under the "snmp" block, but can still make SNMP queries to a routing instance; the docs suggest this should not work, so I'm not sure what's going on. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SNMP walk on JunOS from inside a routing instance
On 27/04/16 16:45, James Bensley wrote: Does Junos restrict the SNMP output to that which relates to the routing instance only, when polling in a routing instance? We have JunOS boxes with routing instances, and see the same when we poll them from inet.0 or a routing instance. username@mxrouter> show configuration snmp community SecretCommunity { authorization read-only; routing-instance SNMP-TEST { You've configured this community string to map to a routing-instance. Try removing it this config item, and just putting the "clients" directly under the community. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] QFX mc-lag and v6 ND
On 05/02/16 14:40, Adam Vitkovsky wrote: -that's the only occasion the internet where NDP and MC-LAG in listed the same sentence, which is not a good sign on its own. But no explanation about how it is done, especially the part about how the ND Cache is maintained between the LAG members, which clearly is what is not happening in your case. I must be missing something - why would a LAG of any type do any special processing of ND (or ARP, for that matter) traffic? All it has to do is forward the reply appropriately e.g. across the MC-LAG control link if the dest MAC is the peer switch or multi/broadcast. Obviously if you're doing some sort of active-active L3 forwarding on top of the MC-LAG then special things need to happen - but did OP say that? Or is there some subtlety (dumb-lety?) about the way Juniper do this? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] NETCONF in Junos
On 24/12/2015 09:10, Phil Shafer wrote: The real value is that the API comes for free, since it's using the same internal plumbing. This means that when a feature ships in the CLI, it's immediately available in the API. No lag. No additional cost. No missing bits. It's literally all there (with the exception of terminal-oriented commands like "monitor interface", etc). I keep having to explain to other vendors and fellow engineers why this approach is so valuable, and so inherently superior to off-box middleware "API" solutions or obfuscated "SDK" blobs. What's the cause of the few/occasional commands where "| dis xml rpc" doesn't work (e.g. "show virtual-chassis | display xml rpc")? I'm assuming CLI must know how to format it as XML to send it to MGD. In the example I've given I think that command might be an alias to "show virtual-chassis status" as the output is identical and "| dis xml rpc" does work there. I've come across a few others, but memory is failing me this close to Christmas! Sorry if this got a bit long, but honestly it was a soft pitch and I couldn't resist bragging about my baby. ;^) You should be justly proud of it. JunOS has its faults, but it's API and config model are the best in the industry by a very large margin IMO. FWIW the only two things I can cite as dislikes are the infinite-stream-of-XML for Junoscript (solved in Netconf of course) and the somewhat inexplicable embeddeing of the running software version (as opposed to a semantic version) into the various /junos-* XML namespaces, which makes them a bit of a bore to process with a namespace-strict XML library. But both of those are trivial to resolve, compared to (say) running expect against an ever-changing human-readable CLI! Cheers, Phil ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX performance
On 20/12/15 14:16, harbor235 wrote: Can anyone share real world SRX performance? ?I am looking at the SRX220 or SRX240 for a small website ~150-200Mbps in a co-location environment. The performance charts state the SRX220 can do 300Mbps with a mix of traffic and up to 900Mbps with mostly large packet sizes. Is this in firewall or packet mode? We've seen very decent performance from the SRX2xx given their prices; I've had one-way l2circuit throughput of >600Mbit/s in packet mode from an SRX210, which is frankly astonishing given the price. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Could JUNOS OP Script support generate firewall filter term and added before original one?
On 17/12/15 14:27, Chen Jiang wrote: term in the firewall filter, I haven't find any method to insert the new term before the original last "accept all" term and it will make traffic never hit the generated new term. Can't you just add the policy then reorder it using the standard syntax before doing the commit: http://www.juniper.net/techpubs/en_US/junos12.1/information-products/topic-collections/junos-xml-management-protocol-guide/index.html?topic-49517.html ? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SNMP NMS support of Junos VLAN MIBs
On 11/12/15 17:16, Chuck Anderson wrote: For those of us who wish to/need to use commercial NMS software, are there any that support NETCONF? And NETCONF isn't the answer yet anyway to cross-vendor standardization, at least not until standard YANG models are developed. At least Q-BRIDGE-MIB exists as a standard. On the commercial NMSes, no idea. I would hope that commercial products would provide a way to integrate external datasources, but maybe not. I take your point about Netconf versus SNMP, and I don't disagree with you that Juniper should really fix this - "it's been broken for ages" is a pretty poor excuse, they could always provide a config knob to toggle on the new behaviour. But I just don't see them fixing it. Re: YANG - at this point I'd take reliable, comprehensive APIs with *any* reasonably sane, documented data models, standard or otherwise. We're a long way from being able to rely on standard data models IMO, which is unfortunate but a reality. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SNMP NMS support of Junos VLAN MIBs
On 11/12/15 15:11, Ross Vandegrift wrote: I never ran into this, but it's not too surprising - I had unending problems with poor Q-BRIDGE-MIB. We used at least Junos, Procurve, and a few flavors of IOS 12. Only HP had a Q-BRIDGE-MIB that was correct enough to use - and if you poked it wrong, the switch would crash. Likewise, I've seen problems with the Q-BRIDGE on Extreme and Cisco. I've always ended up using some vendor-specific method (except for the pre-Huawei 3Com kit, which had excellent SNMP support in full standards compliance AFAICT). On Junos, I got sick of all this and switched to netconf. +1 (though Junoscript, in my case) ssh admin@switch 'show ethernet-switching table | display xml' ...is always the poor-mans version ;o) SNMP was an impressive effort for its time, and it could have been great, but it's getting less and less usable as vendors pay less and less attention to it. I've seen a number of devices from a number of vendors get *worse* SNMP support over the last couple of years / software releases. In addition for something like the P/Q bridge FDB, the requirement for the table to be sorted by OID can often be a substantial CPU impact, as naive implementations sort the table on every getnext. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Unwanted newline characters in Netconf XML
On 01/12/15 13:21, Tore Anderson wrote: I'm assuming this must be a JUNOS bug? $ echo '' | ssh -s lab-ex netconf [...] http://xml.juniper.net/junos/12.3R10/junos;> http://xml.juniper.net/junos/12.3R10/junos-interface; junos:style="normal"> ge-0/0/0 [...] Yuck. Does it happen if you send the same command over Junoscript rather than Netconf? I don't see this on Junoscript talking to 11.4R7.5 or 13.2X51-D35.3. It might be a Netconf-specific thing. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Unwanted newline characters in Netconf XML
On 01/12/15 14:07, Phil Mayers wrote: Yuck. Does it happen if you send the same command over Junoscript rather than Netconf? I don't see this on Junoscript talking to 11.4R7.5 or 13.2X51-D35.3. It might be a Netconf-specific thing. ...but I do see it over netconf. Sigh, looks like another Junoscript != Netconf issue :o( ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Multi Core on JUNOS?
On 22/10/15 13:05, Saku Ytti wrote: On 22 October 2015 at 14:31, Adam Vitkovskywrote: I see, so no possibility to offload BGP to another node nor multi-chassis capability in Junos right? With regards to IPC, there got to be some XR folks in Juniper so where's the holdup :) IOS-XR seems to have fair share problems with the IPC :) In fairness, concurrency is "teh hardz" on any platform, in any framework. You can use threads and shared memory then problems two you have. You can bodge it by serialising everything and pushing data between threads/processes with queues and using craploads of locking, but you typically want fast CPUs for that. Or you can cheat and coop multitask, but then you're back at IOS classic / JunOS rpd. You can write it in a concurrent-friendly language like Erlang (or maybe Go) but then you have problem employing developers on the cheap, and have to discard your existing codebase (yikes!) I'm sympathetic to Juniper/Cisco/etc. here - they've got huge codebases they can't afford to discard because of the years of accumulated real-world behavioural tweaks, but proper concurrency typically involves ground-up design principles. It's not a solved problem yet :o( ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Multi Core on JUNOS?
On 22/10/15 15:06, Raphael Mazelier wrote: The approach to run rpd on one core, and other process on avaibles one is a quick win. And optimizing the actual code before thinking in paralelism may be a faster approach to make speed gain ? Sure, moving the rest of the OS onto other cores is a no-brainer; they're already crossing a process boundary. Btw Junos on intel RE is fast enough for me. But not all on other cpu, specially on EX/QFX one... Perhaps Juniper should install x86 cpu on switch too (other vendor do this). Better CPU choices would help a lot of devices ;o) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4300 and full-duplex-only
On 28/09/15 11:52, Jackson, William wrote: The ex3300 does not have this limitation. FWIW, Juniper have come back and said this is a firmware limitation in the PHY. Apparently it's some sort of feature conflict or code space issue w.r.t. MACSEC, and there is some vague possibility of a release with an either/or MACSEC/half-duplex in the future. :o/ Agree the 3300 has no such limitation. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] EX4300 and full-duplex-only
Does anyone know the backstory to this? We just found out this platform doesn't support half-duplex - at all - and it was an unpleasant surprise, as it means some old SCADA and instrumentation can't link-up against an EX4300. I'm assuming they skimped and left out the hardware for detecting RX and queueing TX, but wonder if there's something I'm missing. Cheers, Phil ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4300 and full-duplex-only
On 23/09/15 14:38, Peter Tavenier wrote: There is only a note of duplex, not about the speed: Indeed. Note: On EX4300 switches, the interfaces operate in full duplex mode only. I do see on a EX4300 some links in 100Mb and 1000Mb, don’t have 10Mb devices attached. Not sure why this is. If you mean "why it's only duplex limitations", I'm guessing the device is missing the collision-detect/retransmit hardware for cost reasons. 10/half is pretty rare these days and, in theory, they're pitched as a datacentre device (though we have an IBM tape library which is 10/half on it's management port). You can force the link up by disabling autoneg, but that comes up duplex-mismatched - 10/full at the EX end, 10/half at the device end. All very disappointing; we did not think to specify "must comply with IEEE 802.3" in the RFP :o/ ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4300 and full-duplex-only
On 23/09/15 14:30, Chuck Anderson wrote: Really? So you can't use EX4300 at 10 Mbps (I don't know of any devices that support 10/Full)? If this is true, it is a purchase-stopper for us. 10/full works fine. 10/half (or 100/half) does NOT work: http://www.juniper.net/documentation/en_US/junos13.2/topics/task/configuration/ex-series-gigabit-interfaces-cli-els.html """ Note: On EX4300 switches, the interfaces operate in full duplex mode only. """ We've confirmed this by inspecting the autoneg caps advertised from the device; all half-duplex modes are absent. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX240 for route-reflector?
On 17/08/15 08:58, Stepan Kucherenko wrote: No. Just don't. SRX has 1 weak MIPS CPU for control plane and it's incredibly slow (commits took ages). Just get a couple of vMX/vRR and use them as a VM on a non-outdated x86 server, it'll work great. Agreed. They're nice cheap boxes for a range of use-cases, but I wouldn't use one for an RR - way too slow control plane, no dual PSU. As others have said, vMX/vRR or CSR 1000v for route-reflectors are IMO the obvious choice now; we'll move to that when our M7i REs run out of steam. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] vstp/pvst interop issues with non-Cisco
All, Has anyone run into problem with vstp/pvst interop with non-Cisco vendors, specifically Extreme XOS? We have a legacy STP-based environment that will be going away soon, and putting an EX 4300 running 13.2X51-D26.2 into it caused a loop. It appears the Extreme sends PVST PDUs with a trailing \x00 byte, which is reflected in the Ethernet length (a.k.a. ethertype) field. Cisco seem to ignore this, but the Junipers seem to be dropping it. Worse, they're not logging/counting the drops - it's silent, even with flag all traceoptions on the vstp instance. I'm not really interested in who is right and who is wrong with the on-the-wire format of the PDUs, but the silent drop thing is irritating... Anyone else seen this? Cheers, Phil ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Cisco ME3600 migration to something with more 10 gig ports
On 14/07/15 13:18, Mark Tinka wrote: On 14/Jul/15 14:12, Luis Balbinot wrote: Take a look at the EX4550. Just pay attention on the number of routes it supports and see if that suits you. It's not a core router, but neither is the ME3600. OP is looking for a 1U switch that is really a router with full IP/MPLS capabilities, but has reasonably dense 10Gbps port assets. The EX4550 falls very short of that re: full IP/MPLS capabilities. QFX 5100? Juniper cited that to us as a collapsed MPLS L3VPN P/PE and claim pretty good features. Not tried one yet. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Cisco ME3600 migration to something with more 10 gig ports
On 14/07/15 14:36, Richard Hartmann wrote: On Tue, Jul 14, 2015 at 2:54 PM, Phil Mayers p.may...@imperial.ac.uk wrote: QFX 5100? My experience with that platform and 14.1 has been very unpleasant. 13.2 does not support MPLS PE. Yikes. That's good (well, bad, but you know what I mean) to be aware of. Juniper cited that to us as a collapsed MPLS L3VPN P/PE and claim pretty good features. Not tried one yet. Interesting; not for L2VPN? L3VPN was our use-case; it may or may not do L2VPN, we don't have much use for it locally. Cheers, Phil ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] RTPERF_CPU_THRESHOLD_EXCEEDED on SRX3600
All, We've seen a constant, very infrequent background of these messages on our SRX 3600. This is apparently expected - brief spikes in load. In the last few days, we've started to get these constantly. The offered load in terms of bits/sec, pps, sessions/sec, concurrent sessions and other metrics hasn't changed - in fact it's dropped slightly as our term ends - but obviously something has. Port mirroring of the interface facing the firewall along with netflow analysis of the upstream routers doesn't show any standout traffic, but the volume and diversity is so large that it could be a single thing that we can't see in normal metrics. There's no particular config change - just the usual addition of hosts to/from groups. Our reseller has given us no useful information on how to diagnose the cause of this sudden step change - just the usual useless show chassis routing-engine, apparently failing to understand the distributed nature of the SRX. What do people generally do to track even the most basic info about the source of this kind of thing? I'm thinking even an attribution to input interface and functional area (policy processing, appid, traffic forwarding, policy logging, etc.) The volume of traffic makes a flow trace unworkable. show security monitoring ... doesn't show much, except the CPU spikes - no session spike, no obvious issues. Any ideas? Any way to attribute FPC CPU usage by functional area and time window? Cheers, Phil ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper SRX3600 have a bug i think
On 15/05/15 20:27, Cahit Eyigünlü wrote: root show security monitoring performance This came across mangled for me; all wrapped into one line, so unreadable. SRX start dropping packets after 500k pps of the udp attack. That sounds about right. The 3600 spec sheet claims ~270k sessions/sec for TCP 3-way handshakes. So, I'd expect the policy inspection speed to be about that, so 500k PPS UDP seems about right for the box to fall over, for relatively unique 5-tuples. Firewalls are not routers. They don't perform well in this kind of scenario, IME. We can not use threshold limit because it drops the real connections too while under attack. What is threshold limit. Do you mean the screen options? we cannot use session limit because the attack does not create session Do you mean that you have a deny policy, hence no sessions? Or you have a permit policy, but the session isn't being created for some other reason? The solution to your problem will depend on what the traffic looks like. What does the distribution of source and dest IP/port look like in your UDP flood? You could consider using S/RTBH in front of the firewall, driven by something like netflow/sflow; have a router eat the traffic statelessly before it hits the expensive stateful processing. We actually use the screen function in logging-only mode, and process the logs in realtime to do trigger S/RTBH. This allows us to whitelist some stuff that tends to false-positive the screens, as well as implement better timeout/backoff behaviour, while still using the SRX to do the counting. TBH you haven't really given enough information. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Junos BGP update generation inefficiency -cause for concern?
On 18/05/15 12:49, Saku Ytti wrote: I'm personally not too excited about templates in IOS, as I tend to have only like 3-5 peer-groups in IOS, and if I translate the config to template based, the amount of lines in my config increases. I think the break-even would require rather large amount of groups. Yeah, the templates aren't as nice as they could be in IOS; the particular syntax they chose makes the config messier, not cleaner. We dropped back to peer-groups when I re-visited our BGP configs. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX3600 Problem
On 22/04/15 13:20, Farrukh Haroon wrote: Hi Cahit Your assumption about the order of operations seems to be wrong. If the screen is before the filter, then how come the pings are blocked before you start your attack script? Since your initial pings are blocked this means the filter is working (at least during normal loads).. It is more likely that your are either hitting a bug or the box is incapable of the DOS generated from your script (which is running on a high speed LAN network) and packets are getting slipped/missed from the filter and leaking to the screen check... Cahit sent me some information off-list which I encouraged him to re-post here so others can contribute. From what I understand, they're finding the screen options are not working, presumably because it's a DDoS and there are too many sources for source-based to work; and destination-based of course blocks the target victim. As such, they're trying to use IDS/IDP rules to block the traffic, but the box is falling over under the load. Cahit, is this correct? We've reached the limits of my experience; it sounds like a big DDoS, and stateful filtering may not be able to handle the load. It's probably a question for JTAC. Cheers, Phil ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Helo Juniper, your docs need work..
On 12/02/2015 21:55, Chris Morrow wrote: EX3300 switch EX6200 switch Uhm, this is the year 2015, the device was built and designed in ~2013 ? and no ipv6 ? WHAT? Yes, we shouted at them about that. Hardware limitation. Can't be fixed, we were told. Made the EX3300 unsuitable for our needs since you can't do any form of RA guard, which is unfortunate as it's otherwise a nice box. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Helo Juniper, your docs need work..
On 13/02/2015 00:08, Olivier Benghozi wrote: By the way in current JunOS 12.3 it looks there's at least one fix; in: http://www.juniper.net/documentation/en_US/junos12.3/topics/concept/firewall-filter-ex-series-overview.html http://www.juniper.net/documentation/en_US/junos12.3/topics/concept/firewall-filter-ex-series-overview.html they write that You can apply port, VLAN, or router firewall filters to both IPv4 and IPv6 traffic on these switches: [...] • EX3300 switch • EX6200 switch [...] That's an extremely misleading bit of text that I had a very grumpy conversation with Juniper about. You can indeed apply the firewall filters to IPv6 traffic. But you can't specify any IPv6 protocols fields as matches. So w00t a default deny or ethertype deny will apply to IPv6 as opposed to skipping it entirely. EX3300 apparently has no IPv6 field matching capability in hardware. Which is almost unbelievable for a current-gen switch, but that's what Juniper told us, repeatedly. Cheers, Phil ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Helo Juniper, your docs need work..
On 13/02/15 15:14, Chris Morrow wrote: my guess is that this works because it's implemented as a loopback filter... so really it's a filter on the CPU on the ex3300 and NOT done in the hardware at the forwarding parts. If it claims to be RA/ND guard, it can't be. My guess is that they're punting based on layer2 MAC range, which has interesting implications for CPU performance. Cheers, Phil ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Helo Juniper, your docs need work..
On 13/02/15 14:14, Olivier Benghozi wrote: that you could use next-header on EX including 3300, but only on layer3 interfaces, not port or vlan... Sure - no family ethernet-switching support. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Helo Juniper, your docs need work..
On 13/02/15 10:34, Harald wrote: On 13.02.2015 11:13, Phil Mayers wrote: Yes, we shouted at them about that. Hardware limitation. Can't be fixed, we were told. Made the EX3300 unsuitable for our needs since you can't do any form of RA guard, which is unfortunate as it's otherwise a nice box. RA-guard was implemented in 14.1X53D10 on EX2200 and EX3300 along with ND-inspection, IPv6 source-guard and DHCPv6 guard/snooping. I vaguely recall them saying they were going to do this. Have you tried it? Does it work ok? If that was all we needed, that might be sufficient, but we were reluctant to buy a device which would be in service for 3 years or more without the ability to block on IPv6 address / UDPv6/TCPv6 ports. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] RTPERF_CPU
On 29/10/14 18:40, Paulhamus, Jon wrote: Seeing this on firewalls with very little throughput up through more than 2Gps of throughput. Are you doing any AppXXX e.g. AppID, AppFW, etc.? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] NETCONF vs SNMP for monitoring
On 30/08/14 17:30, Tyler Christiansen wrote: SNMP is less resource-intensive and faster than NETCONF. I would use SNMP for the things you can and NETCONF for the things you can't. If you I would agree with this, based on our extensive playing. We tend to monitor with SNMP, configure with Netconf/Junoscript. Couple of additional points: 1. Sometimes the SNMP MIB is really horribly organised either from a performance point of view (OIDs shall be ordered by prime factorial of birth date - hateful if you need to fetch a whole table of 10k rows to get one item) or needing to fetch a jillion separate tables to get the final result. In this case, Netconf *may* be faster but... 2. ...you need to account for the overhead of setup/teardown of the Netconf session, particularly the SSH/HTTPS key exchange. On low-end devices (EX3300) the CPU were sluggish enough that we opted for plain TCP transport Junoscript, relying on the firewalled management VLAN for security. Try to catch everything in one Netconf session - Tyler's point about async/threading is very relevant here. 3. Occasionally you'll find things not exposed over SNMP; obviously then Netconf 4. Finally, you may find that bulk data collection - e.g. all the counters, all the ARP / ethernet switching table entries - is quicker over Netconf. SNMP results need to be OID-sorted which can be slow, but also the TCP transport can end up being faster than UDP. Test and see which works, but also beware faster collection may mean higher CPU on the monitored device. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] 12.1X for SRX
On 22/08/14 23:44, Quoc Hoang via juniper-nsp wrote: Hi, JTAC recently updated their recommendation for SRX to 12.1X which specifically supports the security platform. We are currently on the 11.4 train (for both branch and HE) but evaluating the latest 12.1X as a possible next rev. Any stability concerns or major bugs that we should be aware? Would be interested in hearing everyone's experiences. As others have said, running X46-D10.2 on SRX3600, no real problems. Some minor issues with earlier X4x release, mostly cosmetic aside from SPC crash-bug with request support info on X45. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] juniper switch ex2200 how to find port from ip address?
On 26/08/14 12:22, Evangelos Kanarelis wrote: Hello everybody I am relatively new to networking and I am currently managing a few EX2200 switches. I need to find to which port a machine is connected to, but all I have is an IP Address. I know that I can use show ethernet-switching table brief but unfortunately I do not have the MAC address. Any help would be greatly appreciated. When you have time, consider looking into running something like Netdisco against your switches and routers. Without a MAC, it's not straightforward. It's not really difficult either, but if you're new to networking all the suggestions I can think of (put an IP address on the ports vlan, ping the host, look in the ARP table; put a logging firewall filter in, look for matches; enable DHCP/ARP snooping) carry a risk of breaking things. It would be a lot easier if you could find the MAC address from the router. Can you really not do that? Or if you can get to the host, just unplug then re-attach the host, then look in the switch logs for which port just came up. If not, the safest thing is probably to modify the switch to have an IP address on the port VLAN and ping the host, then find the MAC from the ARP table like so: == Add the IP to the vlan == configure set vlan name l3-interface vlan.tag set interfaces vlan unit tag family inet address ip/mask commit == Find the IP/MAC/port == run ping ip count 1 run show arp no-resolve hostname ip run show ethernet-switching table | match MAC from the ARP output == Undo adding the IP rollback 1 commit ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Netconf namespaces
On 25/06/14 02:32, Phil Shafer wrote: Phil Mayers writes: The fundamental question is: are namespaces used incorrectly all over the place in Netconf? JUNOS has some namespace issues, suffering from both pre-rfc implementation problems and attempts to re-use the underlaying Junoscript XML API code. PR 826463 is addressing these. That's useful to know. Whether other vendors accept that these are issues (cough cisco cough) is another matter... ;o) Namespaces are a two-edged sword, and while they are great for telling you _exactly_ what data you are seeing, this exactness is often painful. I guess. OTOH I've seem XML come back from some devices like this: rpc-reply namspaced:tag ... i.e. no xmlns for the namespace on a tag. This is just broken, and really hard to deal with using normal XML libraries. I don't think netconf wants to end up like XMPP where you have to use a custom XML parser and serialiser just to make it go, at which point you might as well not have used XML. We're still early enough into Netconf that we might be able to dodge that, if enough people push back on it. ns junos = http://xml.juniper.net/junos/*/junos;; Yeah, that's kind of annoying... I do wonder why you didn't rev the version number on dialect changes rather than software version cahnges, but I guess it's too late to go back on that one. Anyway thanks for the feedback - it's always reassuring to know people at the vendor side are paying attention. Cheers, Phil ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Netconf namespaces
On 18/06/14 07:52, Balasankar Rajaguru wrote: [balasank] This is a bug in JUNOS. This has been reported already and the fix is available from 13.1. Awesome good to know. [balasank] JUNOS doesn't validate the namespaces in 'rpc' as it goes by the postal principle which says be conservative in what you send, but liberal in what you receive. Thereby we receive the RPC requests happily without namespaces.. I guess. What about rpc payloads, thinking in particular config XML blocks? [balasank] Apart from hello, There are quite a few places where Junos deviates from spec, we have bugs filed up for the same. Cool, thanks for the feedback. Cheers, Phil ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] EX3300 IPv6 filtering
All, tl;dr - don't be misled by the release notes item for 12.3R6, EX 3300 *still* cannot match IPv6 fields in ethernet-switching filters. Some of you may have spotted the following: http://www.juniper.net/techpubs/en_US/junos12.3/topics/concept/firewall-filter-ex-series-overview.html You can apply port, VLAN, or router firewall filters to both IPv4 and IPv6 traffic on these switches: ... EX3300 switch ...and also the 12.3R6 release notes which mention PR954496 and say: Starting with Junos OS Release 12.3R6, you can configure new match conditions, actions, and action modifiers for IPv6 firewall filters on EX2200 and EX3300 switches For the avoidance of doubt; it is NOT possible to write an ethernet-switching firewall filter which matches IPv6 header fields on 12.3R6.6, and this is confirmed as expected behaviour by JTAC. The above release notes item (according to JTAC) refers to loopback firewall filters, and the aforementioned URL apparently means filters you write will apply to IPv6 packets, not you can write filters matching on IPv6 fields. So you can block IPv6 packets by MAC address... w00t... JTAC were not forthcoming on whether this is a current or forever limitation, and our account team have not yet been able to give us an answer. 2014 and it can't match an IPv6 address. Great going Juniper! /sarcasm ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Netconf namespaces
On 17/06/14 14:49, Keegan Holley wrote: I've looked at the PyEZ and ncclient code, and basically they seem to take the approach of just throwing away all namespace information. This seems icky to me, and make me wonder if Netconf is going to be another SOAP - so many implementation errors that interop ends up being a mess of special casing and workarounds. Do you really need the namespaces? If different vendors use the same tags for different things you’ll still have to write code to deal with it whether you have a namespace to warn you or not. Maybe I’m missing something. It's not really a matter of need. They're mandatory per the Netconf spec. It's not some optional thing you can dispense with if you don't like it, or because your COBOL libraries don't do them properly or some other reason. If vendors are generating XML without required namespace declarations, you can't validate the returned XML against the schema for the protocol, or for example against their published Yang data model. If you can't do that, you can't be sure it's well-formed semantically. You end up embedding all kinds of turn your head and squint workarounds, and we're back to being only slightly better off than parsing Cisco IOS configs by looking at the indent and using regexps... (I exaggerate here...) Obviously disposing of the namespace info is possible. But it might surprise you how complicated that makes certain things. For example, one thing I've found myself doing is pulling the config as XML from JunOS, annotating and mutating the document locally according to template and database info, then sending it back in the other direction. If I've thrown away namespaced tags and attributes, I might have received this: junos:commentLink to provider/junos:comment interface namege-0/0/0/name ... /interface ...but I send back: commentLink to provider/junos:comment interface namege-0/0/0/name ... /interface ...which is invalid. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4550 apparently dropping IPv6 RA
On 14/06/14 22:24, John Neiberger wrote: The EX4550 is just layer two. There is no routing configured on it, so it should just be passing the RAs from the router to the hosts on the second switch, but that doesn't seem to be happening. Is it RA/RS specific, or is forwarding to fe80::1 and related groups broken? Have any of you ever seen anything quite like this? On other platforms, I've seen IPv6 link-local multicast fail to flow as some tiny table, sized with IPv4 assumptions, overflowed. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Netconf namespaces
All, We've got some code to talk junoscript, but it's run into problems because the XML parser turns out to not reliably deliver start/end tag events to upper layers - it is dependent on the chunking of input data :o( To sidestep this difficulty, I started to look at Netconf, which of course is separate XML documents rather than one long-lived one, so flushing the parser at the delimiter is easy. Literally the very first thing I noticed is that JunOS doesn't put a namespace on the hello tag: !-- No zombies were killed during the creation of this user interface -- !-- user admin, class j-super-user -- hello capabilities This of course fails to validate against the .xsd schema in Appendix B of RFC4741 or 6241, and makes me sad. Similarly, it'll happily take rpc documents without the correct namespace, though it seems to always namespace rpc-reply ( Other vendors do different variations - Cisco IOS never namespaces anything, NX-OS namespaces everything, and so on. What, honestly, is the point of XML namespaces? No-one ever gets them right, ) Anyway, the actual question - is anyone using Netconf in anger against JunOS, and if so, how do you handle namespaces? Do you just ignore the fact that JunOS is broken for hello? Are there other places where the namespaces aren't handled according to spec? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Netconf namespaces
On 12/06/14 16:38, Tyler Christiansen wrote: What are you trying to accomplish? It may be easier to use the Juniper I am trying to integrate our new EX switches into our existing, extensive, automation and provisioning systems. I've already got it working with Junoscript, but as noted had a few problems (currently successfully being worked around) so took a look at Netconf, and found namespace issues. The fundamental question is: are namespaces used incorrectly all over the place in Netconf? Netconf Ruby gem or the Python junos-eznc module depending on your background and goals. I'd rather stab myself with a rusty fork than use Ruby. I've looked at the PyEZ and ncclient code, and basically they seem to take the approach of just throwing away all namespace information. This seems icky to me, and make me wonder if Netconf is going to be another SOAP - so many implementation errors that interop ends up being a mess of special casing and workarounds. In any event, our existing tooling uses Python Twisted, so synchronous/blocking libraries don't integrate well. I'll look at the Ruby code to at least see what they do about namespaces; I bet ignore them. Makes me wonder why we even bother with XML, sigh... ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Netconf namespaces
On 12/06/14 17:48, Tyler Christiansen wrote: I honestly couldn't tell you--but it wouldn't surprise me. Data formats like XML aren't very good data formats. Maybe, maybe not. But they're what we've got, so... I'd rather stab myself with a rusty fork than use Python. :) To each his own, I suppose. Indeed. Data formats are going to have this problem forever. It's not specific to NetConf or SOAP. Standards in general have this problem--implementation for a vendor's version of a standard starts, and then the standard changes or is improved and the vendor doesn't move forward (or at least not as quickly as we would like). Point taken, though here XML is being used as the transport layer encoding, and that's a really unfortunate place to have to code in crufty workarounds, particularly given that the *payload* is part of the same XML document as the transport :o( We'd all be a lot better off if Netconf had used HTTP I suspect... If you're really into Python/Twisted, you may want to look at Trigger I've seen trigger. It has some neat stuff, though it doesn't currently do anything we need. I keep meaning to see if there are bits I can either use locally or adapt our stuff to it and contribute it back. But AFAIK trigger doesn't use Netconf - it has a Junoscript implementation (very similar to the one we have - convergent evolution etc.) and a generic telnet/expect-alike. Still, a neat project. If we ever need ACL automation of that type, I'll look into it. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Junos 12.3 more strict about 3rd party optics?
On 11/06/14 15:01, Chuck Anderson wrote: Jun 10 11:40:54 ex4200 chassism[1293]: XCVR: Unit 0, SFP+ of type 0 EEPROM is Mis Programmed!! Yeah, this was the one that caught my eye. I wonder if it's choking on unknown values in the EEPROM. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Junos 12.3 more strict about 3rd party optics?
On 10/06/14 14:14, Chuck Anderson wrote: Is Junos 12.3 more strict about 3rd party MSA optics than 11.4? I've been using 3rd party MSA optics in EX without troubles, including DOM support working fine. I just deployed a new EX4200 VC with 12.3R6, and the DOM isn't working on the 3rd party MSA optics (but the link comes up and works), but those same optics work with DOM on an MX running 11.4. Interesting that it says unknown cable whereas my other 3rd party CWDM SFP+ optics say 10GBASE-LR there. We have working DOM for 3rd party 1G LR, 10G LR, and 10G DWDM ER, but no DOM for 3rd party 1G BX (bi-di) and 10G DWDM ZR. This is on EX3300 running 12.3R6.6 and the DOM reports ok. I wonder if it's the optic type, rather than vendor, that's in play here? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Junos 12.3 more strict about 3rd party optics?
On 10/06/14 16:17, Chuck Anderson wrote: Moving this same exact optic from the QFX5100 to an EX4200 running 11.4R8.5 it fails, so this seems to be an issue with how the optic is programmed vs. the specific switch/router hardware, rather than Junos-version specific: There are some suggestive entries in /var/log/messages now that I look; do you see anything there? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Config ordering of security address-book and address-set members
Does anyone know why JunOS on SRX doesn't apply alphabetical ordering for address-book members and address-set members? It seems rather pointless to have them ordered by insert order, since they don't have precedence - that all happens inside the policies. (We care because we have similar configs on multiple firewalls and a check/compare diff; so I had to write a Junoscript job to reorder them via a commit in order for the diff not to slowly grow) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Multicast/Broadcast Packets going to EX CPU
On 05/03/14 16:23, Andy Litzinger wrote: Chris, can you elaborate on why low TTL on multicast frames will cause high CPU? Sebastien, as Chris pointed out anything in the 224.0.0.0/24 will hit the CPU, but so will a few other ranges that fall into the Link-Local There's no inherent reason these packets need to hit the CPU on a purely layer2 vlan, any more than broadcast or unknown-unicast packets have to. It might be that the architecture of the device - either by necessity, choice or neglect, and either hardware or software - means these packets hit the CPU, but just being link-local or multicast doesn't imply it. TBH, most vendors have similar behaviour in similar product ranges e.g. the recent discussion on cisco-nsp re: layer2 multicast and Cisco 3xxx range, and I've seen Foundry/Brocade and Extreme switches do it as well. I've always chalked it up to laziness of implementation; the forwarding hardware just isn't setup and/or capable of being set to forward these in hardware for VLANs where the CPU doesn't need to see them. Even IGMP snooping should only be punting IGMP packets to CPU, not all multicast! ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper Product against DDoS
On 18/02/14 14:46, Samol wrote: Hi Experts, Does Juniper provide any DDoS solution ? would you please recommend the product line for this solution if there is? Funnily enough I was just talking to our Juniper account team about various things, and they mentioned this: http://www.juniper.net/as/en/products-services/security/junos-webapp-secure/ddos/ No idea if it's any good; haven't used it, but I know it has been deployed in front of some large sites. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Setting RTBH next-hop at RR for L3VPN routes
On 09/02/2014 05:34, Mark Tinka wrote: On Sunday, February 09, 2014 01:30:20 AM Phil Mayers wrote: So, what I'm asking is: how can I override an inet-vpn next-hop at a route-reflector, when the next-hop is not a real PE. I'm guessing this is dedicated route reflector - not running MPLS - and you have no problems reflecting regular l3vpn routes, yes? It is a dedicated route-reflector i.e. not in the traffic path, and I have no problems reflecting regular l3vpn routes. But it is running MPLS (ldp family mpls on core ifs), as to me this seems marginally cleaner than a 0.0.0.0/0 static in inet.3. This made me wonder if a static for the RTBH next-hop in inet.3 would help - no joy. Nor does adding the RTBH next-hop as a secondary on loopback, presumably because JunOS isn't allocating a label for it, or a couple of different variations of getting the route into inet.3, this time with valid labels (advertised by a 3rd router). Since the error message all along is: BGP label allocation failure: protocols mpls not enabled on interface ...I'm wondering what interface it's referring to. MPLS is defintely enabled on the core-facing interfaces, so which interface is it referring to? Time to break out traceptions methinks. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Setting RTBH next-hop at RR for L3VPN routes
On 09/02/2014 11:44, Phil Mayers wrote: On 09/02/2014 05:34, Mark Tinka wrote: On Sunday, February 09, 2014 01:30:20 AM Phil Mayers wrote: So, what I'm asking is: how can I override an inet-vpn next-hop at a route-reflector, when the next-hop is not a real PE. I'm guessing this is dedicated route reflector - not running MPLS - and you have no problems reflecting regular l3vpn routes, yes? It is a dedicated route-reflector i.e. not in the traffic path, and I have no problems reflecting regular l3vpn routes. But it is running MPLS (ldp family mpls on core ifs), as to me this seems marginally cleaner than a 0.0.0.0/0 static in inet.3. Doh! But I did *not* have: set protocols mpls interface lo0.0 ...which made it spring to life. Thanks for the useful prod. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Setting RTBH next-hop at RR for L3VPN routes
All, We're wanting to deploy RTBH, and I'm running into issues because when the route is injected into an L3VPN, the next hop is set to the advertising PE, not the RTBH discard next-hop. I figure I can change this with a route-map on the other PEs facing the RR, but that seems clumsy, so I tried to set it on the RRs instead using a policy like so: [edit routing-options] + rib inet.0 { + static { + route 192.0.2.1/32 { + discard; + no-readvertise; + } + } + } [edit protocols bgp group RR-client] +export BGP-rr-out; [edit policy-options] + policy-statement BGP-rr-out { + term t1 { + from community RTBH; + then { + next-hop 192.0.2.1; + accept; + } + } + term t2 { + then accept; + } + } [edit policy-options] + community RTBH members 64580:666; ...however the routes are not being advertised to the RR clients, reporting: * 192.168.0.0:1:x.x.x.x/32 (2 entries, 1 announced) BGP group RR-client type Internal Route Distinguisher: 192.168.0.0:1 BGP label allocation failure: protocols mpls not enabled on interface Nexthop: Not advertised Flags: Nexthop Change MED: 0 Localpref: 100 ... I'm assuming that what's happening here is the JunOS RR is trying to allocate a label to put into the inet-vpn update, but can't. Is there any way I can force this to happen? The actual label doesn't matter I guess, since the RTBH next-hop will be routed to null0/discard on all the RR clients. Note that the RR doesn't have routing-instance statements for the L3VPN; it's just reflecting inet-vpn. Presumably if I did define the routing-instances, and if I put the discard route in each instance, it would work but that again seems clumsy. Maybe I'm just being too choosy ;o) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX3300 family ethernet-switching IPv6 matches?
On 10/01/14 00:47, Han Hwei Woo wrote: I believe you're looking for next-header Yes, I am looking for that, but it's not supported on this platform. As the thread should have made clear... ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] EX3300 family ethernet-switching IPv6 matches?
All, The release notes for the EX3300 are a little vague on this, but strongly imply that as of Junos 12.3, IPv6 firewall filters are supported. However: [edit firewall family ethernet-switching filter FPP term deny-ra] admin@sh-299y# set from ip-version ? Possible completions: + apply-groups Groups from which to inherit configuration data + apply-groups-except Don't inherit configuration data from these groups ipv4 Define L3/L4 match items to match IPv4 packets Note: no IPv6. I can match on the IPv6 ether-type, but not any L3/L4 items: [edit firewall family ethernet-switching filter FPP term deny-ra from] 'protocol' ipv4 match item not allowed when ether-type is ipv6 [edit firewall family ethernet-switching filter FPP term deny-ra from] 'icmp-type' ipv4 match item not allowed when ether-type is ipv6 Is this expected to work? Or is the ipv6 support for routed packets only, and not for ethernet-switching? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX3300 family ethernet-switching IPv6 matches?
On 08/01/2014 19:33, Chuck Anderson wrote: and likewise for 13.2, and you'll notice that your last statement is correct. Platform Support for Match Conditions for IPv6 Traffic That's a damn shame. Up to that point, they'd been looking like really nice devices, but I'm afraid in 2014, any device lacking IPv6 parity in such a critical area goes back in the box and fails evaluation. Sigh. Why are enterprise L2 switches all so near, yet so far? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX3300 family ethernet-switching IPv6 matches?
Please, everyone contact your Juniper team and ask them about this. I just poked my team again. Oh, rest assured. Juniper will be hearing this from me loud and clear! -- Sent from my phone with, please excuse brevity and typos ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Resetting link-state and PoE on EX3300
All, We're trialing the EX3300 as an edge switch and there are a couple of things we do on our current devices that I can't find an easy way to do without making a (relatively slow) config change, commit, undo, commit cycle - namely, blipping the ethernet link and the PoE. The former we use to encourage devices to get a new DHCP lease, and the latter to fix hung/crashed wireless APs and VoIP phones. I can't see any way to do these without disabling the port or PoE via a config change, which seems awkward - our existing kit has operational-mode reset/clear commands for both. Any suggestions? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Resetting link-state and PoE on EX3300
On 06/01/2014 13:00, Paul S. wrote: As far as I know, the sanest way in Junos to do both of those is configuring them, and then using a commit confirmed 1 to commit it. Bleh. That wouldn't be quite so bad if commits weren't pretty slow on EX3300. But I still don't think it's very clean. (Fortunately the most important to us, flapping the link, can be done with a RADIUS CoA if you are doing dot1x or macauth, which we are, so I can probably live with that) This way, it commits and auto removes your disable a minute later -- saving you the hassle of doing it yourself. I'm not aware of any operational mode commands for either. The lack of a PoE restart seems in particular a bit of an oversight. Oh well, never mind - thanks for the reply. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Performing a junos-style diff offline
Does anyone know of a tool or code to do this? I'm writing some Junoscript to maintain the security config on our SRX from a database, and would like to be able to compare pairs of devices which should, after the updates, be identical but may end up with slight unmanaged differences. Getting it in junos-style, rather than plain old diff, would allow the differences to be resolved by operator intervention and load patch. Alternatively, is there a Junoscript RPC which can be used to diff against a remote URL? I don't want to have to load the other config via load-configuration as some of these are (very) large, and that's relatively slow. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] J series packet mode
On 19/12/13 14:25, Tom Storey wrote: Hi everyone. Whats the general consensus about using a J series entirely in packet mode? We do it with no problems on both J-series and branch SRX (210H, FWIW). Some people are annoyed about the amount of RAM consumed (wasted) by starting the flow daemon. Whether that matters will depend on how much RAM you need. Are there any gotchyas to be wary of, like missing features, Basically anything flow-related; no ipsec, etc. performance hit? It looks like you can configure 3 address families for packet mode (iso, inet6, mpls) but not inet4. But, from what Im reading, enabling MPLS packet mode forces the whole box in to packet mode, including inet4. Yes. FWIW the situation I am picturing would not require NAT or IPSEC or other services like that, just packet shifting with ACLs, some routing protocols (IS-IS/BGP), and something like VRRP for gateway redundancy. This is exactly what we do, with MPLS L3VPN and PIM multicast on top. It works fine. As I understand it the J series were originally a packet mode box until Juniper switched the default behaviour to flow based. Has there been any major architecture changes that would rule out packet mode operation? Not as far as I'm aware; current JunOS on our J-series is 11.4R7.5 and we're running packet-mode no problems. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] J series packet mode
On 19/12/13 15:06, Tom Storey wrote: On 19 December 2013 14:39, Phil Mayers p.may...@imperial.ac.uk wrote: performance hit? It looks like you can configure 3 address families for packet mode (iso, inet6, mpls) but not inet4. But, from what Im reading, enabling MPLS packet mode forces the whole box in to packet mode, including inet4. Yes. Just want to clarify, are you saying there is a performance hit? Or just that enabling MPLS packet mode forces the entire box in to packet mode? The latter. We've not seen any unexpected performance issues from being in packet mode. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SPUx jmpi mbuf stall on SRX3600 w/ routed multicast
On 26/11/13 04:25, Chris Cappuccio wrote: Phil Mayers [p.may...@imperial.ac.uk] wrote: cpp0 swanhill10: SPU10 mbuf stall exceed 80%, p 0% h 0% j 82%, set alarm. alarmd[1152]: Alarm set: FPC color=RED, class=CHASSIS, reason=FPC 10 Major Errors craftd[1153]: Major alarm set, FPC 10 Major Errors The chassis alarm can't be cleared without a reboot. Anyone run into anything similar? Any way to fix this without a reboot? Run better JunOS code. I'm not entirely sure if this was intended as humorous or helpful, but as it happens you're pretty close to the mark. Apparently this is present in the X45 but not X44 or 11.4 code, and is known under PR 918415. It will be fixed in X45-20, apparently due in January. FWIW we're running the 12.1X series code as we have the combined NP-IOC cards which need it. I can't remember if the NP-IOCs are supported in X44, but aside from this bug (which is pretty easy to avoid - don't remove a policy permitting multicast traffic) the X45 code has been OK so far, so we'll probably live with it. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] SPUx jmpi mbuf stall on SRX3600 w/ routed multicast
All, (I've got a case pending about this, but no response yet, which is really annoying...) We have a pair of SRX3600. They're due to go live shortly, but during testing I've discovered an issue - when passing routed multicast traffic, if I remove the policy matching the multicast, the device starts logging: cpp0 swanhill8: SPU8 jmpi mbuf stall 53%. cpp0 swanhill10: SPU10 jmpi mbuf stall 56%. cpp0 swanhill11: SPU11 jmpi mbuf stall 58%. ...and then: cpp0 swanhill10: SPU10 mbuf stall exceed 80%, p 0% h 0% j 82%, set alarm. alarmd[1152]: Alarm set: FPC color=RED, class=CHASSIS, reason=FPC 10 Major Errors craftd[1153]: Major alarm set, FPC 10 Major Errors The chassis alarm can't be cleared without a reboot. Anyone run into anything similar? Any way to fix this without a reboot? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SSD disks high failure ratio ?
On 10/08/2013 12:58 AM, Pierre-Yves Maunier wrote: Does anyone knows what is the 'software solution' that 'has also been developed to correct the affected REs in the field' as said in the KB ? Yes, that bit of the PR is annoyingly coy, isn't it? JTAC told me: So, you need to perform the secure erase of the contents on the SSD to fix this issue. This secure erase is done by TAC and I will work with service manager of this account to check how to move forward on this. This is just weird; it's not like a secure erase is some kind of super-secret thing - just break into the shell from alternate boot media and run the command - so why not document it for customers to self-perform? I have to wonder if there's more to it than that. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SSD disks high failure ratio ?
On 08/10/13 13:57, Paul Stewart wrote: Did you confirm by serial number that you were effected? The reason I ask is we had a pair of RE1800's that matched on part number but after JTAC ran the serial numbers they re-assured us that we were not actually effected (which is kind of scary in itself). They told me something contradictory; I was assured I was OK because they were bought after date X but I pointed out the HW rev was 04 and the KB said =05 was affected, at which point they decided I *was* affected. Seems they're a bit confused... ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SSD disks high failure ratio ?
Saku Ytti s...@ytti.fi wrote: On (2013-10-03 18:08 -0400), Paul Stewart wrote: Article is in review and not yet ready for viewing http://kb.juniper.net/InfoCenter/index?page=contentid=TSB16210 http://kb.juniper.net/InfoCenter/index?page=contentid=S:TSB16164smlogin= -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp Thanks, this is very useful - does look like our new REs are affected :o( Will contact support to get the fix implemented. -- Sent from my phone with, please excuse brevity and typos ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] DHCP snoop/DAI/IPSG and mac-based vlans?
Does anyone know if the layer2 security features in $subj work at the same time as dynamically-allocated vlans via 802.1x/macauth and RADIUS? I know of a few platforms from other vendors where this isn't the case - the DHCP/ARP/IPSG punts are bound to the static combo of portvlan defined in the config - and am wondering if this is true on the EX switches. The docs don't really specify, and I don't have a unit to test (but if it *does* work, may get one ;o) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] expected multicast forwarding behavior with igmp-snooping and local igmp querier
On 09/18/2013 12:47 AM, Andy Litzinger wrote: This does not appear to always be true. I obviously haven't tested every multicast address, but it seems that pretty much all multicast traffic directed to 224.0.0.0-239.0.0.255 will cause the switch to flood traffic to all ports in the vlan. But addresses from 239.0.1.0 and up seem to work as I expect. Sounds like you're running into the fact that 1 multicast group range maps to 1 multicast MAC range because there's not enough room to fit the 28 bits into the multcast mac lower-half. 239.0.0.0/24 maps to the same MAC address range as 224.0.0.0/24 and the latter is defined as no snooping because it's the link-local/control range, hence both flood. It's a cisco document, but see here: http://www.cisco.com/en/US/tech/tk828/technologies_white_paper09186a00802d4643.shtml#wp1002391 Some newer equipment (e.g. Cisco Sup2T) does IP-based multcast snooping - it reads into the IP header, rather than relying on the multicast mac - which solves the problem. No idea if the EX4xxx can do this, but I doubt it somehow. Basically, don't use (224-239).{0,128).0.0/24 for multicast. also- what I'm trying to do is relatively simple but maybe I'm going about it the wrong way. I have groups of servers in the vlan that use multicast packets as a periodic heartbeat to keep track of each other. I'd like to make sure the multicast heartbeat only goes to other servers that subscribe to the same multicast address- not send it to every server in the vlan. does my config seem like a valid way to do this? I don't need to route the multicast across subnets. FWIW we've had big problems with apps that do that. IMHO a broadcast-discovery / unicast-keepalive is superior to those kinds of multicast solutions. App developers often fail to test in realistic environments, and don't account for the myriad of ways that multicast can go wrong (e.g. the above issue!). We discourage multicast heartbeats for that reason. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Rationale behind set chassis aggregated-devices ethernet device-count
On 23/08/13 17:14, Michael Loftis wrote: Part of it probably has to do with SNMP. Pre-allocating the count keeps the SNMP index ID's from changing when devices are added/removed. ae0 is always index blah. A lot of tools are very dependent upon the SNMP index ID. I don't think so TBH. Having just snmpwalk'ed a JunOS box, the aeX interfaces and sub-ints ifindex values appear allocated sequentially: IF-MIB::ifDescr.521 = STRING: ae0 IF-MIB::ifDescr.522 = STRING: ae0.32767 IF-MIB::ifDescr.524 = STRING: ae1 IF-MIB::ifDescr.529 = STRING: ae0.1 IF-MIB::ifDescr.530 = STRING: xe-1/0/0.1 IF-MIB::ifDescr.531 = STRING: ae0.11 IF-MIB::ifDescr.532 = STRING: ae0.10 IF-MIB::ifDescr.533 = STRING: ae0.9 IF-MIB::ifDescr.534 = STRING: ae0.8 IF-MIB::ifDescr.535 = STRING: ae0.7 IF-MIB::ifDescr.536 = STRING: ae0.6 IF-MIB::ifDescr.537 = STRING: ae0.5 IF-MIB::ifDescr.538 = STRING: ae0.4 IF-MIB::ifDescr.539 = STRING: ae0.3 IF-MIB::ifDescr.540 = STRING: ae0.2 IF-MIB::ifDescr.541 = STRING: xe-1/0/0.11 IF-MIB::ifDescr.542 = STRING: xe-1/0/0.10 So, unless I'm misunderstanding what you mean, it's not doing anything interesting here. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Rationale behind set chassis aggregated-devices ethernet device-count
On 23/08/13 18:04, Doug McIntyre wrote: But imagine the case, where you start with needing 4 LAGs, so that is what you set. Then you add in 10 SFPs for various things, and then you add in 4 more LAGs, then you remove 4 SFPs for some other project. What do your SNMP indexes look like now? And hopefully your /var/db/dcd.snmp_ix file doesn't get corrupt and the indexes have to be recomputed at that point.. Sorry, but I've not understood what point you're trying to make here. That adding and removing interfaces will change which ifindex values are allocated? Well yes, obviously ;o) (IMNSHO, software that assumes persistent ifindex values is broken and should be thrown away) Back to the original question, there probably is some resources taken up by having the LAGs there. And if you just do max # right away, you do have all those new interfaces to gather stats on if your SNMP queries just do a bulk walk of all interfaces. That might be a reasonable explanation, but you could equally well argue that putting the interface into the IF-MIB when it's not defined under the interfaces stanza (as JunOS does) is dumb. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Config archive subtleties
On 08/07/2013 08:25 PM, Phil Shafer wrote: 7 aug 2013 kl. 18:03 skrev Phil Mayers p.may...@imperial.ac.uk: Recently this fell apart on us, as the SSH key on the server changed and the archival transfers started to silently[1] fail. Ick. Silence is deadly. This (and the other issues) is now PR 910647. Cool. All of which has me wondering if the feature is more trouble than it's worth. We definitely should be making it more robust and stable, but to me the value of catching each commit as a distinct delta is a win. It should also have the commit time, user, and commit comment, if given. Having this in a repo means one can ask questions like who has changed config in my network since last Friday? or when did this statement get added in the first place?. Agreed; preserving the separate commits and metadata is a big win, IMO, and I really like the feature. It was surprising and disappointing to find it had hung up! (To the many people who suggested RANCID - thanks, but we already have a config backup system. The question was specifically about strategies to integrate the JunOS commit archive feature with such systems *given* the failure modes I noted. This is a somewhat non-trivial problem to solve in the general case; sure you can have a scheduled fetch hourly beltbraces job, but that is both racy and discards data in some failure modes) What else can we do to make this more worthwhile? Trigger a chassis minor alarm if archive has failed for X minutes? (Configurable, of course). The PR may say that, but I can't see it yet ;o) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Config archive subtleties
All, For several years, we've used system archival configuration in on-commit mode, to backup each commit to a separate file on an sftp/scp server, then check them individually into subversion. Recently this fell apart on us, as the SSH key on the server changed and the archival transfers started to silently[1] fail. While trying to write a nagios check for outstanding archive transfers, I then discovered that in some circumstances, the archival config will give up and discard a file - I had assumed it would queue them forever, but apparently not in some cases (e.g. 3 successive failures with bad username/password). All of which has me wondering if the feature is more trouble than it's worth. What do other people do? It seems like it would be a nice feature to preserve the commits and so forth, but if it's not robust, maybe it's just misleading. Cheers, Phil [1] It did log en entry into /var/log/messages, but TBH JunOS logs so much crap there, we don't do anything with those logs... ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Correct config for SRX port channel - Cisco
On 25/07/13 20:16, OBrien, Will wrote: Here's a full working example that I pulled off my production link. It's comprised of a pair of 10gb links. I renumbered things to Presumably you either don't have vlan dot1q tag native enabled, or it's on a platform/version which doesn't (erroneously) tag the LACP packets with the native vlan? Can I ask which cisco device/OS version? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Correct config for SRX port channel - Cisco
On 24/07/13 17:11, Phil Mayers wrote: On 24/07/13 17:01, Olivier Benghozi wrote: Hi Phil, what is the Cisco model IOS? It's actually an Nexus 7009 running NX-OS. Did you create the vlan in the vlan database in your Cisco switch? :) Yep Maybe try switchport nonegotiate... No such command on NX-OS, there's no DTP. In case people are curious, this seems to be a bug on the Cisco side. If the port-channel is in trunk mode, the Cisco is sending the LACP PDUs tagged with the native vlan, as we have vlan dot1q tag native enabled. This an error IMO, as LACP is not part of a VLAN (it is doing the same for LLDP, FWIW) The SRX, correctly I believe, is ignoring the tagged LACP PDUs. I can work around this by using sub-interfaces on the Cisco side, but it's yucky. Oh well. Thanks all for the input. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Correct config for SRX port channel - Cisco
If I have a single SRX3600 device (NOT a cluster), what config (if any...) can I use to match a config on the Cisco side: int member lacp rate fast channel-group 20 mode active int Po20 switchport switchport mode trunk switchport trunk allowed vlan 999 int Vlan999 ip address 192.168.1.1 255.255.255.254 I would have thought it would be something like: chassis { aggregated-devices { ethernet { device-count 2; } } } interfaces { xe-1/0/0 { gigether-options { 802.3ad ae0; } } xe-1/0/1 { disable; } xe-4/0/0 { gigether-options { 802.3ad ae0; } } xe-4/0/1 { disable; } ae0 { vlan-tagging; aggregated-ether-options { lacp { active; periodic fast; } } unit 999 { vlan-id 999; family inet { address 192.168.1.2/31; } } } } ...but this never comes up. I've seen this before, and I think it's because there's something in the LACP PDUs which disagrees about trunk/access mode. The config works if I set the Cisco side to access, but obviously that's not what I want. Can you even do this on SRX? I see lots of documents talking about reth interfaces, but AFAICT those are all for chassis clustering, which we don't want to use. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Correct config for SRX port channel - Cisco
On 24/07/13 15:48, Stacy W. Smith wrote: In general, I see no problems with your AE configuration. Could you define never comes up? Is it the ae0 interface, or the ae0.999 unit that is in a down state? Both (see below) The output of show interfaces terse (at least for the member and ae interfaces) admin@srx-3600-1 show interfaces terse Interface Admin Link ProtoLocal Remote xe-1/0/0upup xe-1/0/0.999upup aenet-- ae0.999 xe-1/0/0.32767 upup aenet-- ae0.32767 ae0 updown ae0.999 updown inet 192.168.1.2/31 multiservice ae0.32767 updown multiservice and the output of show lacp interfaces might be helpful. admin@srx-3600-1 show lacp interfaces Aggregated interface: ae0 LACP state: Role Exp Def Dist Col Syn Aggr Timeout Activity xe-1/0/0 ActorNo YesNo No No Yes Fast Active xe-1/0/0 PartnerNo YesNo No No Yes Fast Passive LACP protocol:Receive State Transmit State Mux State xe-1/0/0Defaulted Fast periodic Detached FWIW, the two ends of your link are in different subnets. 192.168.1.1/31 and 192.168.1.2/31 are not in the same subnet. That's a typo on my part. I've seem something similar to this before, where a port-channel wouldn't come up between a Cisco IOS and IOS-XR box if one end was switchport trunk and the other switchport access. This confused me slightly - I didn't know LACP was aware of the trunk/access nature of the upper interface. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Correct config for SRX port channel - Cisco
On 24/07/13 16:07, Phil Mayers wrote: On 24/07/13 15:48, Stacy W. Smith wrote: In general, I see no problems with your AE configuration. Could you define never comes up? Is it the ae0 interface, or the ae0.999 unit that is in a down state? Both (see below) Interestingly, this comes up if you use sub-ints on the Cisco side: interface port-channel20 interface port-channel20.999 encapsulation dot1q 999 ip address 192.168.1.1/31 no shutdown ...as opposed to interface port-channel20 switchport switchport mode trunk switchport trunk allowed vlan 999 int Vlan999 ip address 192.168.1.1/31 no shutdown Clearly there's some sort of LACP-layer parameter that corresponds to trunk versus not - can this be influenced by the specific style of ae0 config on the SRX side? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Correct config for SRX port channel - Cisco
On 24/07/13 17:01, Olivier Benghozi wrote: Hi Phil, what is the Cisco model IOS? It's actually an Nexus 7009 running NX-OS. Did you create the vlan in the vlan database in your Cisco switch? :) Yep Maybe try switchport nonegotiate... No such command on NX-OS, there's no DTP. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] commit script to prevent duplicate service def' on SRX?
To save me the work, does anyone know of a commit script that will prevent people defining services which duplicate the JunOS or existing user-defined ones? Are the built-in defs (under groups/junos-defaults/applications/application/$name) in the candidate XML config? In which case it's easy, but if not, what the best way to get them? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] BOOTP helper on MX vrf
On 13/06/13 12:03, Sebastian Wiesinger wrote: Hello, as I'm hearing conflicting information regarding bootp helper on MX routers in a vrf routing-instance, has anyone a working configuration? What I need: Forward DHCP broadcast requests from one vrf interface to a central DHCP server in the same VRF (classical bootp helper functionality). I don't want bootp helper on *every* interface, just a few. It's a J-series, not MX, but should be the same: forwarding-options { helpers { bootp { interface { ge-0/0/2.2021 { server x.x.x.x routing-instance BLAH; ...and routing-instances { BLAH { instance-type vrf; interface ge-0/0/2.2021; Basically, you have to put the routing-instance on the server option, matching the routing instance of the interface. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX Reliability
On 12/06/13 10:47, Andrew Gabriel wrote: Hi, We are evaluating the SRX 3000 series firewalls for our datacenter, and would appreciate some feedback from folks who are already using/deploying the SRX platform. I understand that the initial software versions had a large number of bugs and features that just wouldn't work reliably. Juniper claims that they have addresses most of those and that the current releases are stable and well received by customers. How true is that, and would you recommend the SRX platform as a core datacenter firewall at all? We recently evaluated an SRX 3600, and modulo some minor cosmetic bugs and one major one (PSN-2012-10-754, fixed in later software) they seemed solid to me. We tested IPv4 IPv6 layer4 firewalling, AppFW, dynamic routing with BGP and multicast. It all seemed to work ok, and we have gone ahead and purchased. It might help if you could specify what sort of things you want to do on them e.g. IPsec, IDP, inline AV/web filtering (which the 3000s can't do) and so forth. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX Reliability
On 12/06/13 13:41, Andrew Gabriel wrote: On Wed, Jun 12, 2013 at 3:58 PM, Phil Mayers p.may...@imperial.ac.uk mailto:p.may...@imperial.ac.ukwrote: We recently evaluated an SRX 3600, and modulo some minor cosmetic bugs and one major one (PSN-2012-10-754, fixed in later software) they seemed solid to me. We tested IPv4 IPv6 layer4 firewalling, AppFW, dynamic routing with BGP and multicast. It all seemed to work ok, and we have gone ahead and purchased. It might help if you could specify what sort of things you want to do on them e.g. IPsec, IDP, inline AV/web filtering (which the 3000s can't do) and so forth. Hi Phil, Thanks, we are mainly looking at basic FW, VPN, and routing capability, which we need to be rock solid. We do not intend to use the IPS and UTM type features at the moment. The basic firewalling seemed solid, as did the dynamic routing - it is JunOS after all - but I didn't test VPN, so can't comment on that. We were running 12.1R6.5. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] What is this ethernet switching trace telling us?
On 06/09/2013 04:59 PM, John Neiberger wrote: We have several of these throughout our network and we're only seeing this problem in a couple of cases. The rest work just fine. Most of the SBCs are Obvious question: are you sure those two aren't configured different (wrongly) compared to the others, or running different software? Reading between the lines it sounds like a different group runs these devices, and in my experience, kit like this with odd network interface capabilities can be misconfigured by staff that don't fully understand networking - and it can be exacerbated by vendors using odd terminology (e.g. PHY used in a non-standard way) and confusing people. Are you sure they haven't just setup these two devices in active-active mode? Or more likely, something that *sounds* like an active-passive mode in the UI, to a non-expert, but is really some kind of weird active-active spatchcock. Our storage team did this with a couple of NetApps and the symptoms were pretty much identical. It only really brought things crashing down when they started sending 1Gbit/sec of performance testing traffic from them... ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] What is this ethernet switching trace telling us?
On 06/08/2013 08:35 AM, Gavin Henry wrote: your email to /etc/aliases. We found that the Linux kernel doesn't send the same arp response out of the same interface. For example, one interface was a public IP and one was a private IP. The kernel would send a I'm on MAC blah for the private IP out of the public IP port! arptables is the solution, but in 10 years it's the first time I'd The behaviour you describe can be disabled by sysctl, which is rather cleaner than arptables IMO; our cfengine config puts the following /etc/sysctl.conf: # These values make linux be sensible about making and replying # to ARP requests - specifically they force ARP requests to come # from an in-subnet IP, and ignore ARP replies for out-of-subnet # addresses net.ipv4.conf.all.arp_ignore = 1 net.ipv4.conf.all.arp_announce = 2 AIUI the Linux behaviour is intentional, claiming to be the letter of the relevant RFCs, but it's certainly problematic in a number of scenarios, including multihoming, transparent load-balancing and anycast routes. There's more documentation in the kernel source for the above sysctls. I have no idea if this is actually the OPs problem. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SLAX script, redefining variables
On 07/06/13 09:54, Tom Storey wrote: But without being able to redefine a variable, and with variables defined inside an IF block not being accessible outside of that IF block, I will need to reproduce my output code numerous times. Move the output code to a function? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX 3600 dropped packets - how to debug?
On 28/05/13 14:57, Phil Mayers wrote: I have my suspicions about what exactly the ALG is (mis)counting as a drop, and will be trying to reproduce it on the bench now it's been taken out of service. All, Just to confirm that, as tested on the bench on SRX 3600 and JunOS 12.1R6.5 *all* packets processed by the DNS alg count as a drop in the output of show security flow statistics, even though they're forwarded correctly. The SUNRPC alg seems to do the same; presumably the all do. So, if you have any ALGs enabled, that counter is misleading, and if you don't, DNS packets will consume a lot of your sessions. This is demo model so I can't open a support case, but when the real kit arrives, maybe I will... ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX 3600 dropped packets - how to debug?
On 29/05/2013 20:24, Morgan McLean wrote: Side note on the DNS ALG, RHEL 6 doesn't like the SRX DNS ALG. RHEL 6 makes both A and lookups for each name resolution in the same connection, resulting in two requests being sent out, one response being received and the session closing, cutting off the second response. This causes a 5-10 second time out for every name resolution on the server. That's not RHEL6-specific. glibc has done A/ lookups like this for a while now, and I've had problems with other stateful devices (load balancers in front of DNS recursive servers) as a result. See also https://bugzilla.redhat.com/show_bug.cgi?id=505105 In addition, my testing boxes *were* RHEL6 and the DNS alg seemed to be forwarding them fine - indeed, during my testing I saw other hosts sending tens of DNS requests down the same socket pair, and all were forwarded fine. Are you running an older JunOS - maybe they fixed it? There is a flag you can set under the resolv.conf to require a new socket per query, or you can turn off the DNS ALG. Could also custom define a DNS service that times out in 10 seconds or something? Even a 10 second timeout results in a significant rise in sessions - we tested exactly that. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX 3600 dropped packets - how to debug?
On 28/05/13 14:40, Julien Goodwin wrote: On 28/05/13 19:40, ashish verma wrote: That said, I can't believe the firewall was *actually* dropping 1500pps of DNS traffic; we'd have widespread problems reported, surely. So, it seems that maybe ALG-processed traffic is being counted under packets dropped for show security flow statistics? eDNS fallback perhaps? IME eDNS is pretty much exclusively confined to server-server DNS traffic (modulo newer stuff like in-app DNSSEC resolvers) and these are ordinary clients, which don't tend to make eDNS requests. A SPAN of the link(s) into the SRX tends to support this - no eDNS traffic in a 32Gb capture. I have my suspicions about what exactly the ALG is (mis)counting as a drop, and will be trying to reproduce it on the bench now it's been taken out of service. I never understood the use of DNS ALG's, unless it's to perform a NAT translation on addresses (which is a really bad idea) they just seem like a waste of valuable resources. Far better to ACL down so that DNS queries can only go to trusted DNS servers which can run something that doesn't break on a malformed query. I'm not a fan of ALGs, and in principle I agree with you. However, if you disable the DNS ALG, you might see a sharp increase in session utilisation, as the UDP session stays open for the UDP timeout, as opposed to the fraction of a second that the DNS request/response takes. With even moderate load, this can be tens or hundreds of thousands of sessions wasted, particularly because clients tend to use different UDP source ports - I know this because I tried it, both on our real Netscreen 5400s and on this SRX, and sure enough - big jumps. The best solution here is to avoid the DNS traffic hitting the firewall altogether. If you use L3VPN (as we do) this involves the well-known services VRF solution using appropriate route-targets, or simply multi-homing your DNS servers into each security zone. But this only gets *your* DNS servers. If you have people using Google DNS, Open DNS or whatever, you are faced with either blocking access to those services and eating the support costs (I have a roomful of VIPs and 3 of them can't access the internet) or worse, intercepting traffic to those services and pretending to be them. I'm not wild about the upswing in public DNS resolvers and their apparent popularity amongst customers, but they're a fact of life now, particularly in more open networks (such as universities). The idea of a malfunctioning client with 8.8.8.8 as a DNS server consuming 250,000 sessions on our firewall is not attractive :o( ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX 3600 dropped packets - how to debug?
On 28/05/13 14:51, OBrien, Will wrote: The primary use of the dns alg is to reduce session count. This is very apparent on net screens. I reduced 500k sessions down to 400k by turning it on. That said, you can achieve similar results by setting dns specific policies with short timeouts. Out of interest, how short a timeout have you experimented with? We set our Netscreen 5400s to 10 seconds at one point, but the extra session table use was still considerable by comparison with an ALG-enabled setup. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp