Re: [j-nsp] ACL for lo0 template/example comprehensive list of 'things to think about'?
Saku Ytti writes: > I think best compromise would be, that JNPR would offer good filter, > dynamically built based on data available in config and referring to > empty prefix-lists when not possible to infer and customer can fill > those prefix-lists if needed. And also have functional ddos-protection > configuration out-of-the-box. People who want and can could override > and configure themselves. That would be really wonderful. A great start would be if there was a way to get just the /32 (or /128) interface IP addresses in apply-groups. Another great thing would be if you could match, in interface filters other than lo0, "is destined for the RP" or the opposite. In most cases, traffic that is destined for the router itself has completely different security requirements to passthrough-traffic, which is also completely different from router-generated traffic. It is a pain to use IP-addresses to guess which category the traffic is. Linux (and therefore RouterOS) does this by having THREE filters, input, output, and forward. On router platforms you only get input and output. In practice JunOS attaches filters to interfaces, so that kind of design would lead to 4 filters: inputlocal, input, output, outputlocal. Having "src-local", "dst-local", and "local" as terms instead would keep it at 2 filters. The challenge might be that the input filter does not yet know whether it is going to forward the traffic to the RP, since input filtering necessarily happens before routing. It would definitely work for output filters. /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] [OT] unit-level vs interface-level description
Phil Shafer writes:
> ---
> version 1.0;
>
> ns jcs extension = "http://xml.juniper.net/junos/commit-scripts/1.0";;
>
> import "../import/junos.xsl";
>
> match configuration {
> for-each (interfaces/interface[description]/unit[not(description)]) {
> var $content = ../description;
> call jcs:emit-change($content, $tag = "transient-change");
> }
> }
> ---
Thank you, much prettier than what I would have done.
/Benny
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] [OT] unit-level vs interface-level description
Phil Shafer writes: > Cool. Consider it not done. You could publish a commit script to handle that... That way people can install it or not, and it should be a nice example script. /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ex4500 best-effort drops nowhere near congested
joel jaeggli writes: > There's literally no options in between. so a 1/10Gb/s TOR like the > force10 s60 might have 2GB of shared packet buffer, while an like an > arista 7050s-64 would have 9MB for all the ports, assuming you run it > as all 10Gb/s rather than 100/1000/1/4 mixes of ports it can > cut-through-forward to every port which goes a long way toward > ameliorating your exposure to shallow buffers. Why does cut-through help so much? In theory it should save precisely one packets worth of memory, i.e. around 9kB per port. 500kB extra buffer for the whole 50-port switch does not seem like a lot. Lots of people say that cut-through helps prevents packet loss due to lack of buffer, so something more complicated must be happening. /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Speed
Saku Ytti writes: > Obviously microbursts can (in both TCP or UDP) scenario happen without any > background traffic. Consider you're connected to 1GE port, testing another > host in 100M port, if you limit your rate to 100M, you still causes the > 100M port to congest, as incoming rate is always 1GE for variable duration > (depending on how you police the sending). Yes, you can in theory cause microbursting of UDP if you want. I am just not sure which tool I would use to do that. Typical UDP tests like iperf attempt to do perfect timing of packets so bursts are avoided, and they seem to do a fairly good job of it. In contrast, iperf TCP can get awfully bursty. /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Speed
Saku Ytti writes: > Microbursts will drop UDP has well, you'll experience this as packet loss > just the same, so you want to find value which has 0 packet loss. This same > number will indicate when TCP will start dropping (and reducing > window-size) There will only be packet loss if you test while there is background traffic on the link. If the only load is a perfect stream of UDP packets, the buffers will not fill and no packets will be dropped. /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Speed
Saku Ytti writes: > This highlights the fact that you should not test network with TCP, always > UDP, with TCP there are so many things to go wrong which are not network > related, UDP is much more reliable indication that problem actually may be > in the network. UDP tests can be too generous on the network. A stream of perfectly spaced UDP packets will not show problems with microbursts. Almost all bulk transfer protocols are TCP, so it is important to test with TCP. /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Speed
Saku Ytti writes: > make sure with tshark what your actual window size is, don't trust iperf. > Best thing is to configure OS TCP stack to window scaling and dont touch > iperf window settings, I don't know why, but they just seem to break stuff. In my experience, you cannot trust iperf to not override the OS window size. Explicit -w seems to be the only reliable solution. /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX80 port numbering
Pavel Lunin writes: > Why not convert this ritualistic stuff into something more useful, > like, say, turn particular port LED blue when user types "request > interface highlight "? But for some reason vendors don't > care and even switches/routers with ID-shields are rare things despite > modern DCs and POPs are becoming more and more dense. Yet another thing that server vendors have done right for years and router vendors haven't discovered... ethtool --identify en0 /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Best route reflector platform
Which Juniper platform would you pick for a dedicated route reflector? It does not currently seem obvious which Juniper router is best for dedicated route reflection duty for an MPLS network. It seems that the obvious choice used to be J-series; are they still fast enough in 2013? What about SRX? Dedicating an MX routing engine to the task seems a bit silly, particularly since it would probably have to be an MX240 due to the limitations of the MX80 RE. On the Cisco side the answer is ASR1k, but it seems less clear-cut with Juniper. /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MTU problems over VPLS
Luca Salvatore writes: > I have a few sites connected via a VPLS core. The core devices are all > MX 10 routers connected via 10Gb fibre. I'm having problems doing file > copies (SCP between two Centos VMs). > > The issue is that the file copy never gets anywhere, on the Centos CLI > it sits at 0% then says 'stalled' To fix this issue I have just set > the MTU on the Centos machines to be 1400 - when this is in place the > copy works and I get nice speeds. > > I don't believe I should have to modify the MTU though, shouldn't path > MTU discovery take care of this? VPLS presents a layer 2 link. There is no way for a L2 link to send ICMP messages. Fix your VPLS core to present a 1500 byte (or preferably much higher) MTU or tell the servers what the actual MTU is. /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Splitting Dot1q VLAN across Logical Systems
Skeeve Stevens writes: > I'm hearing I have to allocate a whole physical interface to a Logical > System which means I can't use a VLAN from it for another Logical System. > > Does this make sense with what I am looking to do? You should be able to assign logical interfaces to each logical system. E.g. place xe-0 unit 100 in logical system A and xe-0 unit 200 in logical system B on both routers. /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Smallest size IPv6 allocation typically advertised?
Morgan McLean writes: > Just curious what the smallest v6 advertisement providers will accept is > these days? I've seen no smaller than /48 mentioned on various boards, but > I see arin will allocate all the way down to /32. We currently have a /48, > and I advertise the whole thing but I'm considering splitting it up among > multiple sites. Please do not split up smaller than /48. You will be heavily filtered. If you have reasonable connectivity between sites, get something larger than /48, perhaps /44 or even /32 if you are a hosting provider. Announce /48 for each site and announce each /48 plus a covering /44 or /32 or whatever you were given. That way you will be reachable even from those providers who filter by database objects. On the other hand, if the sites each live in their own world, consider whether you can live with PA space from whichever provider you have at each site. If you must have PI, get a separate /48 for each site if possible. Akamai can get away with taking a /32 and splitting it to deaggregated /48's, because any ISP which cannot reach Akamai is going to get complaints from its customers. If you have that kind of clout, you can do whatever you want. For the rest of us, being strict in what you send and liberal in what you accept is the only -- and strict means no deaggregation without covering routes or separate database objects. /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX Switch Question
"Paul Stewart" writes: > Per VLAN ingress and egress bandwidth control (rate limiting on a per VLAN > basis with burst) That sounds like hierarchial shaping. You need MX for that, and even then you may meet challenges doing it on ingress. I would have thought that the 6500 needed ES cards for that, but those have only been available for about 5 years? /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] juniper cisco switch interconnection
"Patrick Dickey" writes: > Just a quick note: if you need multiple vlan STP (like what PVST+ has...), > use VSTP on the Juniper. Yes, my advide was wrong, I read RSTP as VSTP. I have only tried VSTP against a Cisco, never RSTP. /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] juniper cisco switch interconnection
harbor235 writes: > Has anyone connected a Juniper EX series switch with a Cisco switch (I have > a 3550)? Yes > Do you use a standard crossover cable? MDIX? I have only attempted 1Gbps, that just worked with a straight cable. > Any Layer 2 issues with RSTP and PVST+? It seems to work so far... > Any specific configuration required to make it work? Avoid VLAN 1. You can probably make VLAN 1 work if you try, but for me it was easier to simply not use it. /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] small multitenant datacenter
Ryan Goldberg writes: > I will re-review what we may need/what may be lacking. It seems the > 3300s are catching up, and we have had good luck in small > single-tenant deployments (3 vmware host + SAN), using them strictly > as stacked L2 switches, generally in place of a pair of 3750x or > 2960s. I avoid the EX3300 because it requires a feature license for q-in-q tunneling. Even HP has stopped doing that. Personally I find it confusing that feature licenses are so different across the EX series. It is probably unavoidable that not all hardware is equally capable feature-wise, but checking for which features need a license on which box is a bit of a nightmare. Not as bad as a certain other vendor, but still. /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] small multitenant datacenter
Ryan Goldberg writes: > Do you see an issue with blowing up ex4200s with all this ospf and > vrrp? I'm labbing tomorrow and will try to get the boxes to thrash. > From a routing table size POV I'm not worried (many customers having > no extra routes, lots have 4-6, a handful having as many as 30 or 40), > I'm a little concerned all those processes might upset the RE if > things get flappy. I can handle a little bump but if they just freak > out that wouldn't be good. I do not really have much experience with EX-series and layer 3. I let the MX80s do the VRRP and OSPF, which has not been entirely smooth sailing lately. > Good thought. Can you hook up L3 addresses to the inner tags on EX > boxes? I'll have to play with that. No, the EX4200 would have to handle a dual tag push, and the hardware can't do that. Rumour has it that the EX4500 and EX4550 has the necessary hardware, but even if that turns out to be true, their software can't do it (yet?). /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] small multitenant datacenter
Ryan Goldberg writes: > So, to the actual questions. I've got a design that basically does a > routing-instance per customer, and stuffs the customers server into > one vlan, default GWing to a VRRP address on RVIs handled by a pair of > ex4200 virt-chassis, and then uses another vlan/RVI "northbound" on > the ex4200 virt-chassis to talk to L3 address on NAT boxes (SRX), > DMVPN boxes (cisco x8xx), and MPLS boxes (MX80s). All those L3 > addresses are in customer-specific routing-instance (or, VRF on cisco) > and there's a per-customer ospf instance keeping things knitted > together. > > A diagram is perhaps useful: > https://www.dropbox.com/s/69hbtzgqomnre5m/simplified%20flow%20diagram.pdf That design is somewhat similar to one that I am familiar with; it all looks sane. The one challenge above any other has been handling private IP addresses. Especially because there was the additional requirement that it must be possible for monitoring servers to reach the hosted customer equipment and the CPEs. Will your design hit any problems if a customer already uses 10.144.x? In a green-field deployment today I would move all the "special" traffic to IPv6 and only care about public IP addresses in IPv4. The MPLS would still move customer traffic with IPv4 private IPs and the hosted servers and firewalls would still have private IPv4 addresses, but all monitoring traffic would be IPv6. One thing was different in the design: The equivalents of your VLANs 2000-2999 and 3000-3999 are carried inside q-in-q, to make it possible to eventually grow beyond 4000 customers and to ensure that overlap between customer VLANs and other VLANs would not cause problems. /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Routing Instance BGP Full Routing High Memory persists
Michael Loftis writes: > This is actually expected behavior of Unix-like OSes in general. RPD may > in fact have released the memory (using free()) but will still have that > RAM associated with it. This is due to the fact that Unix (BSDlike esp) > generally use brk() or sbrk() under the hood during malloc() to request > more RAM from the OS. There's actually no way for a process to return > memory to the OS. I believe you are a few years out of date with that information. Modern malloc() implementations tend to use mmap() to get their memory, and free() tends to unmap memory if the malloc library does not expect to need the memory again soon. There is often a delay before the unmap. However, it is easy to end up with fragmented memory which cannot be returned to the OS. As long as there is even a single byte in use on a page, that page has to be kept around. The various malloc libraries vary in how good they are at avoiding fragmentation, but none of them are perfect. Most often it doesn't matter anyway; if a single almost-never-used byte keeps a page from being freed, it can just go to swap. Similarly, if an empty page is kept around just-in-case and the system needs the space, it can just go to swap. Routers, however, rarely have swap... /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Distributing OSPF load on MX80
Pavel Lunin writes: > AFAIK, at least as of 11.something, BFD was handled by RE on MX80, not > the host-CPU like it is on the big MXes. Looks like it's because the > host-CPU on MX80 is quite less quick (marketing way of reading this is > "it's more power and heat efficient thus more suitable for mobile > applications, which is what MX80 was first primary designed for" :). Fair enough, it seems that moving to BFD would not help. Unless BFD is significantly cheaper for the CPU than full-blown OSPF hellos, of course. > The issue has been discussed here about a year ago: > https://puck.nether.net/pipermail/juniper-nsp/2011-March/019245.html > > I think it's worth to check if any hellows are dropped by the control > plane protection policers on the way to the RE. Thank you, I will check that. /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Distributing OSPF load on MX80
As mentioned in the thread on OSPF packet drops, I have an MX80 dropping OSPF packets during every commit, after adding ~1500 VLAN interfaces. The major load seems to be ppmd, not rpd. On larger MX's, it is apparently possible to distribute ppmd processing to the line cards. Does that work on the MX80? Alternative, is BFD cheap on an MX80? If I turn on BFD, I could set the OSPF hello timers longer than the current 10 seconds. Of course that is no good if BFD just makes even more work for the already-busy routing engine. /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Detecting OSPF packet drops
Saku Ytti writes: > RSP720 is lower spec pq3 than MX80 yet it runs circles around MX80 in terms > of convergence and scale. In fact when I heard about MX80, I wasn't worried > about RE performance at all, top-of-the-line pq3, faster than RSP720, > should suffice no problems, how naive I was. Indeed, the ~1500 L3 VLANs which were moved to the MX80 causing the problem came from an RSP720 which had no problem at all handling the load... (It had all sorts of other interesting problems, as everyone who has worked with the 7600 before SUP2T can surely attest, but it handled OSPF load just fine.) It was a nasty surprise I must say. /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Detecting OSPF packet drops
When I do a commit on an somewhat buxy MX80, I see Nov 27 21:14:10.443024 OSPF dropped 172 received packets due to flow blockage as long as I have set ospf traceoptions flag error. Without traceoptions, the error is not logged. Now, JTAC is telling me that I cannot run with any traceoptions on that box in production. That leaves me completely in the dark when it comes to dropped OSPF packets, and I will have no way of knowing if the packet drops hit a level where I risk losing neighbors. Is there anything I can do to monitor those drops, without using traceoptions? /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Weird SRX flow timeout issue
Tim Eberhard writes: > Benny, > > I've been working with the SRX since before it was in beta loading it > up on a SSG550-M and netscreen previous to that. TCP keep alives, or > any tcp packet that transverses that session has ALWAYS reset the > timeout. The only time where you would see this "not working" is if > you had a situation of asymmetric routing or some time of crazy load > balancing through firewalls. You are discussing this with the entirely wrong person. I do not have any SRX's running flow mode at all. /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Weird SRX flow timeout issue
Tim Eberhard writes: > The SRX's behavior is if any packet passes over that session to reset > the timeout on that session, keep alive, data packet, whatever. As > long as it matches that session it will reset the timeout to the > default value and start decrementing again. So I'm not sure what you > mean when it says dropping tcp sessions with active TCP keepalives. I proposed using TCP keepalives to keep sessions alive. Julien Goodwin informed me that this did not work on the SRX, as of a few years ago. If that is fixed, all is well. None of which has anything to do with tcp-syn-checking. /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Weird SRX flow timeout issue
Tim Eberhard writes: > While I haven't read this entire thread, it's worth mentioning that > this is a correct statement. TCP connections (by default) must be > initiated by a standard 3-way handshake. You can disabled this by > turning off tcp-syn-checking under security -> flow. > > I wouldn't recommend it however, as enforcing proper TCP state is > always a good security practice. Enforcing proper TCP state is certainly good security practice. Dropping a TCP session with active TCP keepalives is simply buggy and wrong. That does not have anything to do with the 3-way handshake or tcp-syn-checking which should be on. /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Weird SRX flow timeout issue
Julien Goodwin writes: > Sadly SRX doesn't (or at least a few years ago didn't) consider TCP > keepalives sufficient to keep the session open. Thank you for that heads-up, that is certainly something to keep in mind. /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Weird SRX flow timeout issue
Andrew Yager writes: > By default the SRX closes the flow after 30 minutes (1800 seconds) as there > is no activity on the wire during this time. I have no SRX firewalls, so I cannot help you with your actual problem, but I can provide an ugly workaround... If you play with tcp_keepalives_count tcp_keepalives_idle tcp_keepalives_interval in postgresql.conf, you can get Postgres to send TCP keepalive every so often. That should keep the session open. 30 minutes is IMHO a very low timeout for TCP sessions. Personally I set session timeout to 86400 for TCP on the firewalls that I control. If the number of sessions is becoming too large, a session timeout of 30 minutes is unlikely to help anyway, and TCP sessions tend to close properly with a FIN instead of by timer. /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Layer 2 circuit - Traffic not flowing between Cisco and Juniper with mismatched VLAN ID
Arun Kumar writes:
> Any option or workaround for this.
Have you tried just popping the VLAN completely and on the Cisco-side
simply doing:
xconnect 192.0.2.2 1234567 encapsulation mpls
On the MX80:
unit 1108 {
encapsulation vlan-ccc;
vlan-id 1108;
input-vlan-map pop;
output-vlan-map push;
}
neighbor 192.0.2.1 {
interface ge-1/0/7.1108 {
virtual-circuit-id 1234567
control-word
mtu 1500
encapsulation-type ethernet
}
}
It works for me between a 7600 and an MX80...
/Benny
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Security bugs in documentation
Bjørn Mork writes: > Yes, I understand what is going on here and I DO NOT APPROVE. I > considere the above a malicious attempt to force me to use software I do > not want to use. It is no better than any other phishing attemt. I was > wondering if I should open a case with JTAC for this, but I fear that > would only be ignored. This really deserves public humiliation. A PDF portfolio seems to be pretty much tar/zip implemented in PDF. This is a great leap forward. Before, Adobe had to implement their own security holes into PDF, now they get to take advantage of security holes in every other application installed on your computer! This was probably done in response to PDF getting beaten by Java to the #1 spot for successful exploits. /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] J6350 Router recommended version
Rachid DHOU writes: > Does someone use J6350 Router ? Yes :) > Is this router can support JUNOS 11 or 12 ? Yes, up to 12.1, not yet 12.2. > What is the recommended version ? http://kb.juniper.net/InfoCenter/index?page=content&id=KB21476 > What is the requirement on DRAM and compact flash, if we go to 12 ? http://www.juniper.net/techpubs/en_US/junos12.1/information-products/topic-collections/release-notes/12.1/index.html?topic-64983.html#jd0e8639 1GB RAM, 1GB flash /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] CCC on EX, link state propagation
Chris Kawchuk writes: > BTW, I also saw in the 12.2 Release Notes that LDP-based L2CKTs are > now supported on the EX4500/4550. > > You can maybe use an l2circut/L2CKT instead of a CCC; using martini > style status-tlvs to signal end-to-end availability. ...Haven't tried > this in the Lab yet. Might be worth a shot to drop the interface > ccc-style. Maybe I am reading the release notes wrong, but to me it looks like that only applies to EX4500, not to EX4550. Are you referring to this bit: "EX4500 standalone switches and EX4500 Virtual Chassis now support all MPLS features that are supported on EX8200 switches with the following exceptions"? /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] CCC on EX, link state propagation
Benny Amorsen writes: > Can the EX series do that? I'm thinking of the EX4550 in particular, but > information about other EX-switches is welcome as well. I hate to reply to myself, but according to http://www.juniper.net/techpubs/en_US/release-independent/junos/topics/concept/ex-series-software-features-overview.html#mpls-features-by-platform-table the EX4550 cannot do CCC at all. That makes it all rather moot :) The EX4500 can, in 12.2. It looks like I will be doing q-in-q-tunnelling instead of CCC. /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] CCC on EX, link state propagation
Ben Dale writes: > I don't think the EX has this exact capability, but depending on your > edge devices, you'd be better off running OAM (both CFM and LFM) which > the EXs do support (though sadly not the EX4500/4550): That is an excellent suggestion. Thank you. Some of the links will be carrying BGP/LDP-signalled MPLS traffic, so BFD should save the day for those. Some of the switches which are to be connected through this setup are themselves EX4550's, using LACP. It seems the only failure detection will be LACP itself, which means several seconds of packet loss if a link fails. > http://www.juniper.net/techpubs/en_US/junos11.2/topics/concept/cfm-ethernet-oam-ex-series.html > > http://www.juniper.net/techpubs/en_US/release-independent/junos/topics/concept/ex-series-software-features-overview.html#network-manage-monitor-features-by-platform-table Thank you very much for the links. > I haven't tried, but maybe you could tunnel OAM PDUs through your CCC so that > your edge devices have direct adjacency? > Alternatively, you could write an event script : ( I could :) It is a bit tricky I think. If I use the event script to disable the interface when CCC fails, then the CCC will not ever come up again -- the CCC itself will get disabled along with the interface. Then I need to periodically enable the interface, just to see if CCC comes up. Not nice. More ideas welcome! /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] CCC on EX, link state propagation
Tim Jackson writes: > gigether-options asynchronous-notification is the command for MX Thank you! My Google-fu completely failed when I tried to find the command. /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] CCC on EX, link state propagation
I am considering building a very simple setup with a number of ethernet interfaces on one switch each CCC-tunnelled through a common fiber to another switch. I.e. simply emulating a typical ethernet CWDM using EoMPLS. One feature which would be very handy is link state propagation across those EOMPLS links. Ideally, if the fiber breaks, the ports at each end go down so the equipment at each end quickly become aware of the break. Even better if loss of link on a port at one end also shuts down the link at the other end. Can the EX series do that? I'm thinking of the EX4550 in particular, but information about other EX-switches is welcome as well. /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Krt queue issues
Jared Mauch writes: > As far as the fallback 'default' route, if you are purchasing transit > from someone, you could consider a last-resort default pointed at > them. You can exclude routes like 10/8 etc by routing these to discard > + install on your devices. That only helps if the default gets installed first, though. If the default has to wait at boot in the krt-queue behind the 300k+ Internet-routes, I have not really gained anything... I suppose it is likely that a static default would be installed before the BGP sessions even come up. /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Krt queue issues
"Darren O'Connor" writes: > Indeed, this is the worst thing this router can do. I have redundant > routers sitting there doing absolutely nothing as this router's > control-plane says everything is fine. I'm looking at using MX80 as an Internet transit router too... Do you know if it is possible to prioritize which routes get installed first into the FIB? In that case, a default route could be used to catch the wrongly-blackholed traffic. It is not particularly elegant or in keeping with being otherwise default-free, of course. /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Commit status in SNMP
Tom Storey writes: > What about forcing the use of "configure exclusive" and "configure > private" as opposed to plain "configure"? This way you're either > locking configuration of the box to yourself for a good reason, or > multiple people/systems can work on configuration simultaneously? > > Its a tiny pain to get used to in the beginning, but not so bad. That is an excellent point. I will switch to using configure private when I am doing things by hand and let the provisioning system stick with configure exclusive. That should solve my problems. Thank you! /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] OSPF Forwarding Address
Stefan Fouant writes: > Although i have never done this myself, I think you should be able to > manipulate your OSPF export policy to include a 'then next-hop > 10.10.200.1' to manipulate the forwarding-address. Alas, no luck with 'then next-hop 10.10.200.1'. It seems to only work for BGP. /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] OSPF Forwarding Address
Jeff Wheeler writes: > Do router2 and router1 have an OSPF adjacency on the /27? This is > required for forwarding-address to be set. Yes, right now that is their only OSPF adjacency. Right now the VRF's only have that single interface. /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] OSPF Forwarding Address
Stefan Fouant writes: > In this case, router 1 is originating external the LSA through > redistribution of the static, hence the other routers will see R1 as > the next hop. I take it that this is expected behaviour in Junos? > Although i have never done this myself, I think you should be able to > manipulate your OSPF export policy to include a 'then next-hop > 10.10.200.1' to manipulate the forwarding-address. I will have to try that. I already tried "then next-hop peer-address" which did not change anything (not even for the same scenario redistributed from BGP instead of static). Thank you for the suggestion! /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] OSPF Forwarding Address
I have a weird problem where I can get IOS to set the Forwarding Address for an external type 2 route (LSA type 5) in OSPF, but I cannot get Junos to do the same. The test network has 3 devices. Two of them are VRF's in an MX80 (router1 10.10.200.10 and router2 10.10.200.11), the last one is a firewall (fw 10.10.200.1). All connected to the same switch, and the network is a /27. The MX80-VRF's are talking OSPF, again completely plainly configured simply by putting the interface in area 0.0.0.0. router1 has a static route to 192.168.200.0/24 via fw 10.10.200.1. It redistributes this route into OSPF, again a completely plain policy just saying "from static" "then accept". router2 receives the route through OSPF but Forwarding Address is not set. Therefore it sends traffic destined for 192.168.200.0/24 to router1 -- which is sort-of correct, but it would be much better if the traffic was passed directly to the firewall. If I replace router1 with a VRF on a Cisco 7600, Forwarding Address is set to 10.10.200.1 and everything works as I expected. This is obviously not my preferred solution :) /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Commit status in SNMP
Is it possible via SNMP to see if the configuration is locked or whether there are uncommitted changes? If I forget to commit my changes, our automated configuration systems cannot do their job. I'm wondering if I could make OpenNMS poke me when that happens -- before the automated scripts start failing. /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX hardware acceleration caveats
Per Granath writes: > For the record, the Miercom report is from tests without services > offload - so that's without 'hardware offload'. It is great to hear that. > In general, with that 22Gbps on the SPC processing, the processing > power could also be eaten up by IPSec termination and 'new connections > per second' processing, or IPS, which would lower amount of processing > left to 'firewall' traffic. Sure, but on the other hand some traffic will be subject to services offload, even if IPv6 takes off. At least for the foreseeable future IPv4 will still represent a good chunk of traffic, which should free up some SPC power. It seems that the Juniper specifications provide conservative performance numbers which do not include the benefits of services offload. That is quite generous. Thanks to you and everyone who contributed to this thread. I am much better informed now. /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX hardware acceleration caveats
Phil Mayers writes: > It's only a factor of two up, and they've had 6/7 years to get there. > I'm assuming the 5600/5800 can do 10Gbit/sec (of basic firewalling - > no deep inspection etc.) unless anyone has compelling evidence > otherwise. Yes, I am assuming that too. But does it do 10Gbps firewalling for IPv6? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX hardware acceleration caveats
Pavel Lunin writes: > Even 'independent tests' from Cisco's friends do not argue that SRX3k > can do 20G+. > http://www.cisco.com/en/US/prod/collateral/vpndevc/miercom_vs_juniper.pdf > > I am sorry for that sort of a link in such a respectful place :) I am sure the SRX3600 can do 22Gbps+. The question is not whether you can do 22Gbps+ using an SRX3k at all, instead the question is whether there exists a well-behaved unicast traffic profile which can force an SRX3600 which otherwise handles 20Gbps to only handle less than 10Gbps. I am asking this because a competing box I have experience with happens to have such limitations: IPv6 traffic and IPSEC passthrough do not get hardware offloaded, and CPU forwarding limits throughput to much less than we were hoping for from the specifications. So, can the the SRX3k handle 10Gbps+ IPv6? 10Gbps+ IPSEC passthrough? 10Gbps+ SCTP? (ok 10Gbps+ SCTP is unlikely to happen in practice...) /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX hardware acceleration caveats
Pavel Lunin writes: > Em… isn't 10G+ possible on SRX HE without offloading? I don't know, that is part of what I am trying to find out :) /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX hardware acceleration caveats
Pavel Lunin writes: > To be honest, by now it looks like a feature for a particular customer. To me it seems like a feature for every customer... Without offloading, how would you do stateful firewalling at 10Gbps+? To put it another way, is there a hardware/software configuration for an SRX3400 which will do 20Gbps of IPv6 firewalling? /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX hardware acceleration caveats
Benny Amorsen writes: > It is pretty sad that when it comes to >1Gbps firewalling, CNG is > cheaper and easier to buy than native IPv6... Carrier Grade NAT, not CNG. /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX hardware acceleration caveats
Thank you very much again. "No fragmentation" is a potential DoS vector but probably ok. The other limitations are similar to other vendors. However, "No IPv6" is really unfortunate. With Google, Youtube and Facebook on IPv6 already, that could be a serious limitation. It is pretty sad that when it comes to >1Gbps firewalling, CNG is cheaper and easier to buy than native IPv6... /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX hardware acceleration caveats
Saku Ytti writes: > EZchip is very much not software, ES+ linecards and ASR9k routers use > EZchip (albeit faster versions 3 and 4, SRX uses 2) for lookups also. > This 'service-offload' does what box should have been doing all along, punt > only first packet to RMI/Netlogic and use EZChip for subsequent packets. Thank you very much for your information, it make it a bit clearer how services offload actually works. However, I am still wondering if all traffic is eligible for services offload. Multicast traffic with fan-out > 1 is not, but that is not a large concern for me. Is there any other traffic which cannot be offloaded? /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] SRX hardware acceleration caveats
After having a few surprises from non-Juniper firewall equipment, I just thought I would ask here... Are there any surprises waiting when it comes to SRX enterprise firewalls and hardware acceleration? Is hardware acceleration limited to UDP and TCP, or does it work with e.g. ESP or SCTP? What about IPv6, does that get accelerated just like IPv4? /Benny (No the vendor with the surprises wasn't Cisco) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] How to query the results tree from a commit script?
Tore Anderson writes: > Hi, > > I'm trying to write a template for a commit script that, when called, > will find the first unused unit on an interface and add some transient > config to it. "Unused" means that that the unit isn't defined in the > main configuration file and that an earlier call to the template hasn't > written transient config to it yet. I had almost exactly the same problem when trying to pick unit numbers for q-in-q interfaces. I gave up on doing it transiently and now I simply save the unit numbers in apply-macros as permanent changes. If you don't care what the unit numbers are and you are parsing objects from somewhere else to generate them, you can just do position() + 5000 like I did originally. This does not work if you might reach the maximum ID or if you are parsing objects from multiple places (so position() could repeat). Curtis Call already pointed out the problem of ID's changing. I would recommend testing it, as at least when it comes to l2circuits, the router effectively tears down all the old units and builds the new ones if the ID's change -- even if everything ends up exactly the same apart from the unit ID's. That is service-impacting. /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] How to query the results tree from a commit script?
Curtis Call writes: > In SLAX 1.1 you'd be able to use mvars, but that isn't released in > Junos yet, so you'll need to use some sort of out-of-script storage > such as the Utility MIB or a disk file. > > BTW, this could cause your unit numbers to jump around between > commits. (If you remove one VPN then every following VPN will suddenly > have a lower unit number). Yes, I discovered that one the hard way. > Is that going to be a problem for you? Not for me personally, but apparently an MX does not like a thousand subinterfaces switching ID's... Not so surprisingly perhaps, but it took a few minutes before everything was back to normal. > It might be preferable to store the assigned unit number for each VPN > within the configuration, perhaps within an apply-macro, so that you > can ensure that a particular VPN doesn't change. That would allow you > to assign the numbers randomly as well, which would be more efficient. > (i.e. when the script makes the transient change it also makes a > permanent apply-macro change, recording the assigned unit [if it is a > previously unconfigured VPN]) Yes, I ended up going that route, apart from not choosing randomly. You are right, random will be more efficient eventually, when a sufficient number of lines have been added and removed. My solution right now is O(n). /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Unit-ID's revisited / accessing committed configuration
Curtis Call writes: > Junos 12.1 added new options for the > commit-scripts attribute, apply and apply-no-transients, that allow > you to retrieve the post-commit-script configuration, and prior to > Junos 12.1 you could always do something like "show > configuration | display xml | display commit-scripts" (be aware that > the returned XML structure will be different than > ), however, these work by running the configuration > through the commit scripts again, so if you try to call them from a > commit script you're liable to get a loop. Ah clever idea, but you are right, it would loop. It could only work if there was a way to get the actual configuration as it was applied after the commit scripts of the last commit, without having to actually rerun the commit script. > Why not just have your commit script automatically add the unit number > to the apply-macros. i.e. if the unit number is already present in the > macro then use it for the logical interface, but if it is missing then > figure out the first unused number, use it for the interface, and > record it in the macro. Yes that sounds like a workable solution. Thank you! /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Unit-ID's revisited / accessing committed configuration
Tim Jackson writes: > show configuration | display commit-scripts Sorry, I forgot to mention the crucial detail: It has to be available to a script. Unfortunately that command does not seem to have a junoscript equivalent; "display commit-scripts view" does have a junoscript equivalent but does not do what I need. /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Unit-ID's revisited / accessing committed configuration
Is it possible to somehow get the committed configuration as it looked
after commit-scripts were applied? I do not want the commit-scripts
re-run, I simply want to fetch the configuration as it was after all
scripts were run and the commit succeeded.
To explain why I need to do this, it is necessary to go back to the unit
ID problem I posted about earlier.
To reiterate, the challenge is to generate unit ID's for a bunch of
q-in-q interfaces like this:
unit 5239 {
encapsulation vlan-ccc;
vlan-tags outer 1559 inner 3;
input-vlan-map pop-pop;
output-vlan-map push-push;
}
I solved it, or so I thought, by keeping all configuration in
apply-macros, like this:
apply-macro eompls-1001089 {
inner 3;
interface ge-1/0/4;
outer 1559;
}
which then generates the above q-in-q interface as a transient-change.
The unit ID is simply the position of the apply-macro in the
configuration file + 5000, so this particular apply-macro happens to be
the 239th apply-macro.
It all works really well, in general. Except I had not considered what
happens if you remove an apply-macro. All is well if you remove the last
apply-macro, but if you happen to remove one of the first ones, every
interface below changes unit ID. The MX80 was less than happy about
hundreds of interfaces being torn down and rebuilt...
At this point it is tempting to give up on that design and "simply" add a
unit ID to the provisioning database and to the apply-macro. Keeping
them consistent is no fun at all.
However, I would like to give the dynamic ID's one more chance. If it is
possible to find out which unit ID the previous commit used for a
particular apply-macro, I can then reuse that unit ID. Since all the
changes my commit script does are transient, this seems to be a
challenging task.
Any help is really appreciated!
/Benny
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Retrieving specific ID's from junoscript
Phil Shafer writes: > > > > > ge-1/0/1 > > 1017 > > > > > That works perfectly, thank you! /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Retrieving specific ID's from junoscript
In the continuing saga of automatic provisioning of a PE router, I am still at the stage where I am trying to retrieve information... More specifically, I would like to retrieve a specific a sub-interface. For finding a specific interface, this works fine: ge-1/0/1 ge-1/0/1 9192 flexible-ethernet-services 1017 vlan-ccc 1017 1018 vlan-ccc 1018 However, I can't figure out how to retrieve a specific subinterface, like the unit 1017 above. It is obviously possible to just fetch them all and search "by hand", but there will eventually be hundreds of subinterfaces and it seems inefficient. The obvious solution of replacing ge-1/0/1 with ge-1/0/1.1017 in the request does not work. /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Unit ID's and q-in-q
Derick Winkworth writes: > Just do it sequentially and then write an op script that takes the > vlan(s) as an argument to show you the interface info you are looking > for... I am looking at this option, but it seems that there is no Junoscript command to get all objects with elements matching a specific pattern. More specifically, I can't even ask for "all interfaces which have vlan-id=1010". Can this really be true? Obviously I can just ask for all interfaces and loop. /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Unit ID's and q-in-q
Saku Ytti writes: > What ever you do, also open enhancement request. This is extremely annoying > and trivial to fix. > (While at it JNPR, give us tags/colours to direct routes, kthx). Certainly. What would be your preferred enhancement, just larger unit numbers or the ability to have unit ID's with dots in? If the commit check error message is to be believed, larger unit ID's are already available for certain interface types (demux0 and pp0). /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Unit ID's and q-in-q
Derick Winkworth writes: > Just do it sequentially and then write an op script that takes the > vlan(s) as an argument to show you the interface info you are looking > for... Thank you all for your suggestions! I will try to see if a bit of scripting can save some work for me. I might still be able to get away with not storing the unit ID in the provisioning database. /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Unit ID's and q-in-q
I am wondering if any of you have suggestions for allocating unit numbers for q-in-q interfaces on the MX platform. For plain VLAN's it is quite easy; just use the VLAN as the unit ID. That does not work for q-in-q because unit numbers are integers. The obvious solution 1017 for outer 1010 inner 7 does not work either, as the unit ID seems to be limited to be at most 16384. Just adding them sequentially is a possibility, but with several hundred subinterfaces per physical interface it becomes challenging for operators to find the correct unit ID for a particular VLAN. Perhaps I will have to add a per-interface unit ID database to our provisioning system. Ideas are welcome! /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ex4200 static arp
Ross Vandegrift writes: > Well, not in this case. But in the general case, if anyone accepted > multicast MACs for ARP entries, it'd be easy to start causing your > switches to flood more frames than they are switching. I forgot that bit. Just reply with an unused MAC address, and there's your denial-of-service. Multicast is less of a problem, on good switches it'll only propagate to the hosts who subscribe. /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] IPSEC into VRF
Which Juniper routers can terminate an IPSEC tunnel in a virtual router? M-series and T-series routers with the ES PIC can do it according to this: http://www.juniper.net/products/modules/100089.pdf What about the J-series and the MX-series? /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Triple-stacked VLANs
Do Juniper routers support triple stacked VLAN's? QinQinQ if you prefer. Right now my workaround (with non-Juniper routers) is to use stacked VLAN's and then use a separate switch to add the last tag. This works ok, but it would be nicer to be able to do it in one box. /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Which Router
"Peter E. Fry" <[EMAIL PROTECTED]> writes: > I don't know if this matters to anyone, but most of the J > series can be redeployed as firewalls, too, with a bit of > license work (money, time, and a bit of divine > intervention). How good are they in that capacity? We're considering exactly that, for hundreds of virtual systems with a low aggregate bandwidth. Netscreen doesn't let you have all that many virtual systems per box, and the price is actually higher per virtual system than simply giving each customer an SSG-5. Of course a rack full of SSG-5's would look a bit silly, and the cabling wouldn't be much fun... /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
