Re: [j-nsp] How reliable is EX multichassis? 3300 and 8200 switches
Confirmed as a bug. AE interfaces flap when master switch in VC reboots. Fixed in 11.4r6 (not released yet) or 12.1 Luca -Original Message- From: Luca Salvatore Sent: Thursday, 1 November 2012 12:51 PM To: Luca Salvatore; Morgan McLean Cc: juniper-nsp@puck.nether.net Subject: RE: [j-nsp] How reliable is EX multichassis? 3300 and 8200 switches Just an update on this after some more troubleshooting today. I'm only seeing the issue on my EX4500-VC switches. On my EX4200-VC switches, when the master reboots my OSPF neighbours stay up - i drop about 2 pings but that's it. The EX4500 switches have the exact same configuration. All switches are running 11.4r2.14 Probably log this with JTAC - looks to me like a bug. Luca -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Luca Salvatore Sent: Thursday, 1 November 2012 7:32 AM To: Morgan McLean Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] How reliable is EX multichassis? 3300 and 8200 switches I see the 60 sec delay when crashing master. It seems the backup switch takes a while to notice the master is gone. But my main delay is the fact that my OSPF neighbours are lost when master crashes. @Doug, nonstop bridging is also configured. Luca On 01/11/2012, at 7:25 AM, Morgan McLean wrx...@gmail.commailto:wrx...@gmail.com wrote: Did you see the failover times I mentioned? Is that expected timing? 8 seconds using VC-LAG w/ LACP to a third switch when pulling masters power over 60 seconds when crashing master Morgan On Wed, Oct 31, 2012 at 1:20 PM, Doug Hanks dha...@juniper.netmailto:dha...@juniper.net wrote: Don't forget to configure NSB to help with LACP and other L2 stuffs. set ethernet-switching-options nonstop-bridging On 10/31/12 1:05 PM, Luca Salvatore l...@ninefold.commailto:l...@ninefold.com wrote: Yes so GRES and NSR is configured am correctly then? The AE is a VC-lag with one member on each switch. Luca On 01/11/2012, at 3:56 AM, Stefan Fouant sfou...@shortestpathfirst.netmailto:sfou...@shortestpathfirst.net wrote: On Oct 31, 2012, at 10:01 AM, Luca Salvatore l...@ninefold.commailto:l...@ninefold.com wrote: Yep my mistake. However I do have 'set chassis redundancy graceful-switchover' configured as well as 'set protocols nonestop-routing' On 31/10/2012, at 11:24 PM, Stefan Fouant sfou...@shortestpathfirst.netmailto:sfou...@shortestpathfirst.net mailto:sfou...@shortestpathfirst.netmailto:sfouant@shortestpathfirst .net wrote: I think you are confusing GRES w/ GR. NSR and GRES are NOT mutually exclusive and in fact NSR requires it to function. 'set chassis redundancy graceful-switchover' is GRES, not GR. What I actually see when the master switch robots is that the AE interfaces between my devices flaps. I think this causes my OSPF neighbours to go down. I see this in the logs: rpd[2241]: RPD_OSPF_NBRDOWN: OSPF neighbor 10.255.255.9 (realm ospf-v2 vlan.83 area 0.0.0.1) state changed from Full to Down due to KillNbr (event reason: interface went down Which device is the ae interface tied to? Is it a VC-LAG with members tied to multiple physical devices, or is it comprised of only links belonging to a single device? Stefan Fouant JNCIE-SEC, JNCIE-SP, JNCIE-ENT, JNCI Systems Engineer, Juniper Networks ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Layer 2 circuit - Traffic not flowing between Cisco and Juniper with mismatched VLAN ID
I ve tried all of the recommended options provided but it did not work out,
...
if the VLAN ID are same on both Cisco and Juniper, traffic is passing
through but with different VLAN ID, traffic is not...
Steinar - when you said, pseudowire working fine between cisco and juniper,
did you mean even with different VLAN ID.. in our network we only have same
VLAN ID if the pseudowire is built between cisco and juniper...
Known working example with different VLAN IDs at each end, corresponding
to your option 3 at the Juniper end. Equipment is 12K / IOS 12.0(32)SY
and MX / JunOS 10.4:
interface GigabitEthernet7/0/0
mtu 4470
no ip address
interface GigabitEthernet7/0/0.24701423
encapsulation dot1Q 247
xconnect 10.0.0.1 68790300 encapsulation mpls
interfaces {
ge-1/0/0 {
flexible-vlan-tagging;
mtu 4488;
encapsulation flexible-ethernet-services;
unit 1084 {
encapsulation vlan-ccc;
vlan-id 1423;
input-vlan-map {
swap;
vlan-id 247;
}
output-vlan-map swap;
}
}
}
protocols {
l2circuit {
neighbor 10.0.0.2 {
interface ge-1/0/0.1084 {
virtual-circuit-id 68790300;
no-control-word;
mtu 4470;
}
}
}
}
Steinar Haug, Nethelp consulting, sth...@nethelp.no
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Layer 2 circuit - Traffic not flowing between Cisco and Juniper with mismatched VLAN ID
On (2012-11-02 11:04 +0530), Arun Kumar wrote:
Option 1:
encapsulation vlan-ccc;
vlan-id 601
input-vlan-map pop;
output-vlan-map push;
Shouldn't work. VXR side is VLAN mode, and will barf. Missing family 'ccc'.
Option 2:
encap vlan-ccc;
vlan-tags outer 601;
output-vlan-map swap;
family ccc;
Should work. We have literally hundreds of these, none where VLANs match in
each end. Both sides will swap SVLAN on egress.
show mpls l2transport vc X detail -- from cisco
show l2circuit connections interface X extensive - from juniper
Option 3:
encapsulation vlan-ccc;
vlan-id 601;
input-vlan-map {
swap;
vlan-id 610;
}
output-vlan-map swap;
Should work (I presume family ccc is there). Useles input-vlan-map, but
it doesn't break anything either.
if the VLAN ID are same on both Cisco and Juniper, traffic is passing
through but with different VLAN ID, traffic is not...
What Cisco IOS, if you have older than 7-8 years, then Cisco is not
supporting output vlan swap. (7304 for example does not support vlan
rewrite, or didn't 4 years ago when I last looked)
--
++ytti
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] How reliable is EX multichassis? 3300 and 8200 switches
On 11/02/2012 02:21 AM, Luca Salvatore wrote: Confirmed as a bug. AE interfaces flap when master switch in VC reboots. Fixed in 11.4r6 (not released yet) or 12.1 Luca Do you have the PR# by chance, or any info I can read up on at juniper.net? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Strange VRRP problem -- question about restarting process
We have a very odd problem that we've been dealing with for a couple of weeks. JTAC is involved but we have not come to a resolution yet. The gist of the problem is that we have two MX960s and we're running VRRP on multiple interfaces with different Cisco switches in between each pair of Juniper interfaces. [J] - [C][C]-- [J] The switches are just layer two and we're running VRRP on the routers. The problem is that one day, three of the interfaces on the backup router suddenly stopped receiving VRRP messages from its peer. JTAC seems to think that the Cisco switches just suddenly stopped forwarding VRRP messages to the backup router, but that makes zero sense unless some bizarre issue just happened to occur on multiple unrelated switches at exactly the same moment. I'm still leaning toward a problem on the router. Which leads me to my question. What is the risk of restarting the VRRP process? I see we have soft and graceful as options. Both sound fairly low-risk. I'm tempted to just restart the process on the backup router to see if that fixes the problem. What do you think? Thanks, John ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Strange VRRP problem -- question about restarting process
We have a very odd problem that we've been dealing with for a couple of weeks. JTAC is involved but we have not come to a resolution yet. The gist of the problem is that we have two MX960s and we're running VRRP on multiple interfaces with different Cisco switches in between each pair of Juniper interfaces. [J] - [C][C]-- [J] The switches are just layer two and we're running VRRP on the routers. The problem is that one day, three of the interfaces on the backup router suddenly stopped receiving VRRP messages from its peer. JTAC seems to think that the Cisco switches just suddenly stopped forwarding VRRP messages to the backup router, but that makes zero sense unless some bizarre issue just happened to occur on multiple unrelated switches at exactly the same moment. I'm still leaning toward a problem on the router. Did you try disabling IGMP snooping for the VLAN on the switches? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Strange VRRP problem -- question about restarting process
Well, that's fairly straightforward - either (1) VRRP on master [J] stopped sending or (2) CSCO switches stopped forwarding VRRP hellos, or (3) backup [J] drops incoming VRRP hellos. You can verify (1) by using monitor traffic interface blah no-resolve size . (2) could be verified with SPAN/RSPAN (3) cannot be verified with monitor traffic interface _if_ there is an input FW filter. monitor traffic interface a.k.a. tcpdump does not capture packets dropped by FW filter. Which begs a question - do you have an input FW filter on VRRP interfaces or lo0 and if yes, do you allow protocol vrrp as well as AH/proto 51 and have you added/changed VRRP auth type recently? Proto 51 is used when VRRP MD5 auth is configured. In any case, I'd suggest to configure a FW filter to log/syslog incoming VRRP packets (dst.ip 224.0.0.18/32) on backup [J]. HTH Rgds Alex - Original Message - From: John Neiberger jneiber...@gmail.com To: juniper-nsp@puck.nether.net Sent: Friday, November 02, 2012 3:37 PM Subject: [j-nsp] Strange VRRP problem -- question about restarting process We have a very odd problem that we've been dealing with for a couple of weeks. JTAC is involved but we have not come to a resolution yet. The gist of the problem is that we have two MX960s and we're running VRRP on multiple interfaces with different Cisco switches in between each pair of Juniper interfaces. [J] - [C][C]-- [J] The switches are just layer two and we're running VRRP on the routers. The problem is that one day, three of the interfaces on the backup router suddenly stopped receiving VRRP messages from its peer. JTAC seems to think that the Cisco switches just suddenly stopped forwarding VRRP messages to the backup router, but that makes zero sense unless some bizarre issue just happened to occur on multiple unrelated switches at exactly the same moment. I'm still leaning toward a problem on the router. Which leads me to my question. What is the risk of restarting the VRRP process? I see we have soft and graceful as options. Both sound fairly low-risk. I'm tempted to just restart the process on the backup router to see if that fixes the problem. What do you think? Thanks, John ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Running a EX3200-48P with a 320W power
Hey everybody-- I got my hands on an EX-3200 PoE switch, and I don't need the PoE. Can I run it with a 320W power, rather than the 740W (which I don't have). I'm not seeing any errors. Does this just disable PoE, or am I looking at other problems? Thanks much. --Dave Peters ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] ex4200 doesn't reply to jnxCosIfqIfIndex
does anyone know why this might be the case? my lab box is running 11.4R2.14. when querying the subject oid i'm getting back: JUNIPER-COS-MIB::jnxCosIfqIfIndex = No Such Object available on this agent at this OID my googles comes up blank. also tested against an mx80 running 11.2 with the same response. thanks! ryan ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Strange VRRP problem -- question about restarting process
Sorry for the lack of replies. I got swamped today and haven't had a chance to look at this much. Another one of our engineers has been working it. I did notice that the three interfaces I originally looked at back when this started all seem to be fine now. However, this weird behavior seems to have moved to some other interfaces. I'm going to need to investigate a bit more to find out what changed when I wasn't looking. :) We do not have IGMP snooping enabled on the Cisco switches and we have no inbound filters that would block traffic. In fact, we have this identical config on several different routers and dozens of interfaces and switches with no problem. Whatever is wrong seems to be isolated to this router. I'll try to regroup and get the latest info. Thanks! John On Fri, Nov 2, 2012 at 11:18 AM, Alex Arseniev alex.arsen...@gmail.comwrote: Well, that's fairly straightforward - either (1) VRRP on master [J] stopped sending or (2) CSCO switches stopped forwarding VRRP hellos, or (3) backup [J] drops incoming VRRP hellos. You can verify (1) by using monitor traffic interface blah no-resolve size . (2) could be verified with SPAN/RSPAN (3) cannot be verified with monitor traffic interface _if_ there is an input FW filter. monitor traffic interface a.k.a. tcpdump does not capture packets dropped by FW filter. Which begs a question - do you have an input FW filter on VRRP interfaces or lo0 and if yes, do you allow protocol vrrp as well as AH/proto 51 and have you added/changed VRRP auth type recently? Proto 51 is used when VRRP MD5 auth is configured. In any case, I'd suggest to configure a FW filter to log/syslog incoming VRRP packets (dst.ip 224.0.0.18/32) on backup [J]. HTH Rgds Alex - Original Message - From: John Neiberger jneiber...@gmail.com To: juniper-nsp@puck.nether.net Sent: Friday, November 02, 2012 3:37 PM Subject: [j-nsp] Strange VRRP problem -- question about restarting process We have a very odd problem that we've been dealing with for a couple of weeks. JTAC is involved but we have not come to a resolution yet. The gist of the problem is that we have two MX960s and we're running VRRP on multiple interfaces with different Cisco switches in between each pair of Juniper interfaces. [J] - [C][C]-- [J] The switches are just layer two and we're running VRRP on the routers. The problem is that one day, three of the interfaces on the backup router suddenly stopped receiving VRRP messages from its peer. JTAC seems to think that the Cisco switches just suddenly stopped forwarding VRRP messages to the backup router, but that makes zero sense unless some bizarre issue just happened to occur on multiple unrelated switches at exactly the same moment. I'm still leaning toward a problem on the router. Which leads me to my question. What is the risk of restarting the VRRP process? I see we have soft and graceful as options. Both sound fairly low-risk. I'm tempted to just restart the process on the backup router to see if that fixes the problem. What do you think? Thanks, John __**_ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/**mailman/listinfo/juniper-nsphttps://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Strange VRRP problem -- question about restarting process
Okay, I've been looking at this for a little bit and it's just really bizarre. I was wrong about the connectivity earlier. It's really just a single Cisco 4948 in the middle between these two MX960s. IGMP snooping is not enabled, nor are there any inbound filters on the routers. I have verified that our RE filter is allowing VRRP. We have verified with the monitor traffic command that router 1 is sending and receiving vrrp multicasts, but router 2 is not receiving them, only sending them. The switch is a pretty vanilla config. The two links are in the same VLAN and there are no special features enabled, like MAC filtering or whatever. It's very straightforward, which is why we're all stumped. Something is stopping those multicasts from reaching router 2, but for the life of me I don't see what it could be. On Fri, Nov 2, 2012 at 3:53 PM, John Neiberger jneiber...@gmail.com wrote: Sorry for the lack of replies. I got swamped today and haven't had a chance to look at this much. Another one of our engineers has been working it. I did notice that the three interfaces I originally looked at back when this started all seem to be fine now. However, this weird behavior seems to have moved to some other interfaces. I'm going to need to investigate a bit more to find out what changed when I wasn't looking. :) We do not have IGMP snooping enabled on the Cisco switches and we have no inbound filters that would block traffic. In fact, we have this identical config on several different routers and dozens of interfaces and switches with no problem. Whatever is wrong seems to be isolated to this router. I'll try to regroup and get the latest info. Thanks! John On Fri, Nov 2, 2012 at 11:18 AM, Alex Arseniev alex.arsen...@gmail.comwrote: Well, that's fairly straightforward - either (1) VRRP on master [J] stopped sending or (2) CSCO switches stopped forwarding VRRP hellos, or (3) backup [J] drops incoming VRRP hellos. You can verify (1) by using monitor traffic interface blah no-resolve size . (2) could be verified with SPAN/RSPAN (3) cannot be verified with monitor traffic interface _if_ there is an input FW filter. monitor traffic interface a.k.a. tcpdump does not capture packets dropped by FW filter. Which begs a question - do you have an input FW filter on VRRP interfaces or lo0 and if yes, do you allow protocol vrrp as well as AH/proto 51 and have you added/changed VRRP auth type recently? Proto 51 is used when VRRP MD5 auth is configured. In any case, I'd suggest to configure a FW filter to log/syslog incoming VRRP packets (dst.ip 224.0.0.18/32) on backup [J]. HTH Rgds Alex - Original Message - From: John Neiberger jneiber...@gmail.com To: juniper-nsp@puck.nether.net Sent: Friday, November 02, 2012 3:37 PM Subject: [j-nsp] Strange VRRP problem -- question about restarting process We have a very odd problem that we've been dealing with for a couple of weeks. JTAC is involved but we have not come to a resolution yet. The gist of the problem is that we have two MX960s and we're running VRRP on multiple interfaces with different Cisco switches in between each pair of Juniper interfaces. [J] - [C][C]-- [J] The switches are just layer two and we're running VRRP on the routers. The problem is that one day, three of the interfaces on the backup router suddenly stopped receiving VRRP messages from its peer. JTAC seems to think that the Cisco switches just suddenly stopped forwarding VRRP messages to the backup router, but that makes zero sense unless some bizarre issue just happened to occur on multiple unrelated switches at exactly the same moment. I'm still leaning toward a problem on the router. Which leads me to my question. What is the risk of restarting the VRRP process? I see we have soft and graceful as options. Both sound fairly low-risk. I'm tempted to just restart the process on the backup router to see if that fixes the problem. What do you think? Thanks, John __**_ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/**mailman/listinfo/juniper-nsphttps://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Strange VRRP problem -- question about restarting process
Sorry for the barrage of emails, but I wanted to mention that we can ping in both directions through the switch from one router interface to the other, so we know broadcasts (ARP) and unicast work. How could the problem be limited to only multicast if IGMP snooping is off? This is such a simple scenario that it's really bugging me that I can't figure it out. lol On Fri, Nov 2, 2012 at 4:43 PM, John Neiberger jneiber...@gmail.com wrote: Okay, I've been looking at this for a little bit and it's just really bizarre. I was wrong about the connectivity earlier. It's really just a single Cisco 4948 in the middle between these two MX960s. IGMP snooping is not enabled, nor are there any inbound filters on the routers. I have verified that our RE filter is allowing VRRP. We have verified with the monitor traffic command that router 1 is sending and receiving vrrp multicasts, but router 2 is not receiving them, only sending them. The switch is a pretty vanilla config. The two links are in the same VLAN and there are no special features enabled, like MAC filtering or whatever. It's very straightforward, which is why we're all stumped. Something is stopping those multicasts from reaching router 2, but for the life of me I don't see what it could be. On Fri, Nov 2, 2012 at 3:53 PM, John Neiberger jneiber...@gmail.comwrote: Sorry for the lack of replies. I got swamped today and haven't had a chance to look at this much. Another one of our engineers has been working it. I did notice that the three interfaces I originally looked at back when this started all seem to be fine now. However, this weird behavior seems to have moved to some other interfaces. I'm going to need to investigate a bit more to find out what changed when I wasn't looking. :) We do not have IGMP snooping enabled on the Cisco switches and we have no inbound filters that would block traffic. In fact, we have this identical config on several different routers and dozens of interfaces and switches with no problem. Whatever is wrong seems to be isolated to this router. I'll try to regroup and get the latest info. Thanks! John On Fri, Nov 2, 2012 at 11:18 AM, Alex Arseniev alex.arsen...@gmail.comwrote: Well, that's fairly straightforward - either (1) VRRP on master [J] stopped sending or (2) CSCO switches stopped forwarding VRRP hellos, or (3) backup [J] drops incoming VRRP hellos. You can verify (1) by using monitor traffic interface blah no-resolve size . (2) could be verified with SPAN/RSPAN (3) cannot be verified with monitor traffic interface _if_ there is an input FW filter. monitor traffic interface a.k.a. tcpdump does not capture packets dropped by FW filter. Which begs a question - do you have an input FW filter on VRRP interfaces or lo0 and if yes, do you allow protocol vrrp as well as AH/proto 51 and have you added/changed VRRP auth type recently? Proto 51 is used when VRRP MD5 auth is configured. In any case, I'd suggest to configure a FW filter to log/syslog incoming VRRP packets (dst.ip 224.0.0.18/32) on backup [J]. HTH Rgds Alex - Original Message - From: John Neiberger jneiber...@gmail.com To: juniper-nsp@puck.nether.net Sent: Friday, November 02, 2012 3:37 PM Subject: [j-nsp] Strange VRRP problem -- question about restarting process We have a very odd problem that we've been dealing with for a couple of weeks. JTAC is involved but we have not come to a resolution yet. The gist of the problem is that we have two MX960s and we're running VRRP on multiple interfaces with different Cisco switches in between each pair of Juniper interfaces. [J] - [C][C]-- [J] The switches are just layer two and we're running VRRP on the routers. The problem is that one day, three of the interfaces on the backup router suddenly stopped receiving VRRP messages from its peer. JTAC seems to think that the Cisco switches just suddenly stopped forwarding VRRP messages to the backup router, but that makes zero sense unless some bizarre issue just happened to occur on multiple unrelated switches at exactly the same moment. I'm still leaning toward a problem on the router. Which leads me to my question. What is the risk of restarting the VRRP process? I see we have soft and graceful as options. Both sound fairly low-risk. I'm tempted to just restart the process on the backup router to see if that fixes the problem. What do you think? Thanks, John __**_ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/**mailman/listinfo/juniper-nsphttps://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Running a EX3200-48P with a 320W power
On 03/11/2012, at 3:55 AM, Dave Peters - Terabit Systems d...@terabitsystems.com wrote: Hey everybody-- I got my hands on an EX-3200 PoE switch, and I don't need the PoE. Can I run it with a 320W power, rather than the 740W (which I don't have). I'm not seeing any errors. Does this just disable PoE, or am I looking at other problems? I vaguely remember trying this once with a 600W PSU in a 48P and as I recall it disabled half the PoE ports. My memory is hazy though. But yes, no other issues expected. Ben ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] How reliable is EX multichassis? 3300 and 8200 switches
I was told PR/677087 but its currently marked as internal so not public On 02/11/2012, at 11:24 PM, Billy Sneed bi...@middlebury.edu wrote: On 11/02/2012 02:21 AM, Luca Salvatore wrote: Confirmed as a bug. AE interfaces flap when master switch in VC reboots. Fixed in 11.4r6 (not released yet) or 12.1 Luca Do you have the PR# by chance, or any info I can read up on at juniper.net? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
