Re: [j-nsp] What do you think about the MX line?
On Mon Jun 27 13:48:51 2011, Keegan Holley wrote: Other than the obvious I'm at a loss for the definition of BRAS. broadband remote access server http://en.wikipedia.org/wiki/BRAS ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] What do you think about the MX line?
On Monday, June 27, 2011 06:48:51 PM Keegan Holley wrote: Please elaborate. This is interesting since most edge boxes have the fewest features configured. Is this an metro-e edge or just vanilla IP? V4/v6? For us, the edge is where we tax the box the most. Peering and core functions tend to be very minimal, and fairly easy on the box and software in general, in our environment. It's the edge where things get quite demanding because the edge is where we offer (initiate or terminate) services. The core is simply forwarding traffic boringly, while peering is just an exit point from the routing domain. Nothing kinky. On the MX, we've had major issues with Multicast (NG-MVPN deployment), QoS, IPv6, hardware capabilities, e.t.c., in the edge. This is mostly due to the types of services we offer our customers. We've also had similar issues with Cisco's IOS XR. In our core, we use the CRS and ASR9010 routers extensively (including Juniper's of course), and couldn't complain one bit. But we recently deployed some ASR9010's in the edge, and we've uncovered a plethora of issues in IOS XR's RPL (Routing Policy Language) that makes 'route-maps' in IOS/IOS XE seem much more sane. But all in all, our largest problems with any platform (the MX not being an exception) has been in the edge. At this time, we use the MX only in an edge role. Other than the obvious I'm at a loss for the definition of BRAS. See Patrick's wiki URL. For BRAS issues on the MX Trio's: o We can't have DHCP and PPP in the same VLAN (feature limitation; support coming). o We can't have DHCP and PPP on the same physical interface (feature limitation; support coming). o IPv6 broadband features pending; support coming, but slowly. o MC-LAG won't support broadband features today (feature limitation; support coming). I'm not so worried about lack of features, just that it places our planning into uncertainty. I'm more worried about how features will work and scale, as the last several months with Junos have shown that just because features are there, doesn't mean they'll work as expected. Features that are needed but have to wait also means we'll likely be chasing code to fix bugs to chase code to fix bugs to chase code to fix bugs to chase code to fix bugs... My advice is test, test, test before you buy. You really can't take anything for granted. We've been bitten many a time on the MX, and we can't simply ask for a refund :-). Mark. signature.asc Description: This is a digitally signed message part. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Can per flow load-balancing result in TCP session drops?
Hi experts, Is MX80 a flow based or packet based router? With asymmetric routing, will the TCP session ever get established. Suppose if SYN packet goes out through one interface and the SYN+ACK is received on another interface, will this router drop this SYN+ACK as this behavior is seen in J series routers. Thanks, Siva JNCIS-M ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Community-count does not work for extended community
Hello experts, Community-count is the new feature in 10.4. It works only for standard COMMUNITY not for EXTENDED COMMUNITY such as target:7473:1000. Does anyone know if this is expected behavior, Coz I don't find anything in the release notes. Thanks, SiVa JNCIS-M. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Can per flow load-balancing result in TCP session drops?
On Jun 27, 2011, at 8:07 AM, MSusiva wrote: Hi experts, Is MX80 a flow based or packet based router? the trio chipset and by extention all MX routers are packet based devices. flow cached routing hasn't worked in the internet core for a long time. With asymmetric routing, will the TCP session ever get established. Suppose if SYN packet goes out through one interface and the SYN+ACK is received on another interface, will this router drop this SYN+ACK as this behavior is seen in J series routers. Thanks, Siva JNCIS-M ___ 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] Any takers on 10.4R5.5 yet ?
I'm about to stand this up on some MX80s in the lab but wondered if any bleeding-edgers out there have already ruled it out on the platform, and if so, why. Certainly mileage will vary depending on what you're doing with it, but I'm asking in general (we're dual-stacked QoS-enabled MPLS with all services in BGP-signalled VPNs with some policing, for example). I know it's unreasonable to have people continually posting to the list asking about which code is best, but I know many were waiting for a stable 10.4 revision (due in part to its' EEOL nature) but last I heard, 10.4R2 (or was it R3) wasn't ready for primetime. Didn't find much in the archives about 10.4R4. David ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Any takers on 10.4R5.5 yet ?
we're running it on trio only mx960s in production. it's got a few issues at least one our outstanding one's (frame-relay encapsulation lti interfaces not working) is fixed in 11 but I don't think we're willing to make that jump yet outside the lab. On Jun 27, 2011, at 10:05 AM, David Ball wrote: I'm about to stand this up on some MX80s in the lab but wondered if any bleeding-edgers out there have already ruled it out on the platform, and if so, why. Certainly mileage will vary depending on what you're doing with it, but I'm asking in general (we're dual-stacked QoS-enabled MPLS with all services in BGP-signalled VPNs with some policing, for example). I know it's unreasonable to have people continually posting to the list asking about which code is best, but I know many were waiting for a stable 10.4 revision (due in part to its' EEOL nature) but last I heard, 10.4R2 (or was it R3) wasn't ready for primetime. Didn't find much in the archives about 10.4R4. David ___ 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] Any takers on 10.4R5.5 yet ?
On Mon, Jun 27, 2011 at 11:05:48AM -0600, David Ball wrote: I know it's unreasonable to have people continually posting to the list asking about which code is best, but I know many were waiting for a stable 10.4 revision (due in part to its' EEOL nature) but last I heard, 10.4R2 (or was it R3) wasn't ready for primetime. Didn't find much in the archives about 10.4R4. 10.4R4 has been the least problematic code on MX (either trio or ichip, but not mixed) that we've seen in a very long time, probably at least 1.5 years. There were a handful of mostly minor issues in it, but in theory they've been fixed in 10.4R5 (though we have only a couple of routers running R5 so far, so we don't have a massive experience base yet). As always it varies by your feature set, but for a v4/v6/mpls/bgp heavy core router things are finally starting to look up. About damn time too. :) -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Any takers on 10.4R5.5 yet ?
We're running R5.5 for a couple of our MX480s undergoing testing as BRAS. Ran the code to resolve an issue where PPPoE states are stucked at Terminating only to run to an issue where PPPoE state unable to move beyond Init in this release. Go figure. Last we heard from our SEs, the 10.4 release may even go as far out as R8 so given our situation with MX PPPoE subscriber management, we're most likely going to play catchup. ihsan On Jun 28, 2011, at 1:05 AM, David Ball wrote: I'm about to stand this up on some MX80s in the lab but wondered if any bleeding-edgers out there have already ruled it out on the platform, and if so, why. Certainly mileage will vary depending on what you're doing with it, but I'm asking in general (we're dual-stacked QoS-enabled MPLS with all services in BGP-signalled VPNs with some policing, for example). I know it's unreasonable to have people continually posting to the list asking about which code is best, but I know many were waiting for a stable 10.4 revision (due in part to its' EEOL nature) but last I heard, 10.4R2 (or was it R3) wasn't ready for primetime. Didn't find much in the archives about 10.4R4. David ___ 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] L2VPN Active Route Selection
-Original Message-
From: Stacy W. Smith [mailto:st...@acm.org]
Sent: Monday, June 27, 2011 12:34 PM
To: Eric Van Tol
Cc: 'Juniper-Nsp'
Subject: Re: [j-nsp] L2VPN Active Route Selection
Do you have anything configured under [edit protocols bgp path-
selection]? Specifically, do you happen to have cisco-non-
deterministic configured?
--Stacy
No, I do not. The BGP config on the PE is pretty bare - no options besides the
family:
admin@lab.router# show protocols bgp | display inheritance
local-address 10.18.20.46;
group 65000-dr {
type internal;
family inet {
unicast;
}
family inet-vpn {
unicast;
}
family l2vpn {
signaling;
}
export ibgp-car_to_dr;
peer-as 7784;
neighbor 10.18.20.72;
neighbor 10.18.20.73;
}
group 65000-vpn {
type internal;
family inet-vpn {
unicast;
}
family l2vpn {
signaling;
}
neighbor 10.18.20.10;
}
I thought about configuring 'bgp-always-compare-med' or
'cisco-non-deterministic', but figured it would be pointless, because the MEDs
are all equal, and thus, the options wouldn't have any effect.
Thanks,
evt
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Can per flow load-balancing result in TCP session drops?
Siva, The MX80 is a router. It's packet-based. It does however have a services card that allows for some flow-based use cases. On a side note, the J Series is both a flow and packet-based device. If you want packet-based functionality, disable the security with delete security; set security forwarding-options family mpls mode packet-based On the flipside the J Series has a software forwarding plane while the MX has a hardware forwarding plane. Thank you, Doug Hanks Systems Engineer JNCIP-M/T #1441 -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of MSusiva Sent: Monday, June 27, 2011 8:07 AM To: juniper-nsp@puck.nether.net Subject: [j-nsp] Can per flow load-balancing result in TCP session drops? Hi experts, Is MX80 a flow based or packet based router? With asymmetric routing, will the TCP session ever get established. Suppose if SYN packet goes out through one interface and the SYN+ACK is received on another interface, will this router drop this SYN+ACK as this behavior is seen in J series routers. Thanks, Siva JNCIS-M ___ 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] SRX vx IPad IOS Junos Pulse
From internet explorer in Windows I can download, install and establish VPN
but not from IOS in iPad.
I think JunOS pulse supports IPsec (SRX dynamic vpn), SRX is generating self
certificate but I accept it on iPad screen. Following is seen in the iPad JunOS
registers:
20110627194718.892045 Pulse Mobile[p218.t1799] info Configuration
authentication method is: Password (VPNDeviceImplementation.m:426)
20110627194718.892888 Pulse Mobile[p218.t1799] info LoginManager:: Starting
VPN. (Logger.m:92)
20110627194718.895958 Pulse Mobile[p218.t1799] info VPNManager:: Start tunnel.
(VPNManager.m:149)
20110627194718.897147 Pulse Mobile[p218.t1799] info Connection status changed
to Estableciendo contacto (SSLVPNControllerImpl.m:627)
20110627194718.971162 Pulse Mobile[p218.t1799] info User Agent: JunosPulseiPad
(null) (LoginManager.m:1239)
20110627194718.972305 Pulse Mobile[p218.t1799] info
LoginManager::shouldStartLoadWithRequest with URL: about:blank and navigation
type: 5 (LoginManager.m:1242)
20110627194718.976269 Pulse Mobile[p218.t1799] error Failed to connect to the
server, error = Error Domain=NSURLErrorDomain Code=-1004 No se ha podido
establecer conexión con el servidor. UserInfo=0x1e0350
{NSErrorFailingURLStringKey=https://200.52.93.228/dana/home/am_params.cgi?am=nc,
NSErrorFailingURLKey=https://200.52.93.228/dana/home/am_params.cgi?am=nc,
NSLocalizedDescription=No se ha podido establecer conexión con el servidor.,
NSUnderlyingError=0x15fd10 No se ha podido establecer conexión con el
servidor.} (SSLVPNControllerImpl.m:332)
20110627194718.977317 Pulse Mobile[p218.t1799] info Connection status changed
to Desconectado (SSLVPNControllerImpl.m:627)
20110627194718.983778 Pulse Mobile[p218.t1799] info LoginManager:: VPN
disconnected. (Logger.m:92)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] What do you think about the MX line?
Yes, I'd go for MX240 and upper, as you could grow them redundantly and also in memory in the future. -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Mehmet Akcin Sent: domingo, 26 de junio de 2011 11:25 p.m. To: Ryan Finnesey Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] What do you think about the MX line? you probably want MX240-480-960s rather. mehmet On Jun 26, 2011, at 8:59 PM, Ryan Finnesey wrote: We are looking at the MX80s for about 60GB of traffic with also some private MLPS interconnection. Cheers Ryan -Original Message- From: Timothy Kaufman [mailto:tkauf...@corp.nac.net] Sent: Sunday, June 26, 2011 11:49 PM To: Ryan Finnesey; 'mti...@globaltransit.net'; 'juniper-nsp@puck.nether.net' Subject: Re: [j-nsp] What do you think about the MX line? Which one are you looking at? How many peers do you plan to configure? How much traffic? Thanks Tim Kaufman Sent via blackberry - Original Message - From: juniper-nsp-boun...@puck.nether.net juniper-nsp-boun...@puck.nether.net To: mti...@globaltransit.net mti...@globaltransit.net; juniper-nsp@puck.nether.net juniper-nsp@puck.nether.net Sent: Sun Jun 26 22:15:34 2011 Subject: Re: [j-nsp] What do you think about the MX line? For us I will be looking at the MX Line mainly for peering. Anyone having issues with using them with peering? Cheers Ryan -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Mark Tinka Sent: Sunday, June 26, 2011 9:19 PM To: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] What do you think about the MX line? On Monday, June 27, 2011 06:56:48 AM Keegan Holley wrote: I think the general attitude is positive towards them. They are a good compliment to the M/T series and generally solid flexible boxes. You should probably include how you plan to use them in your question. For example a few list members complain about multicast/IGMP bugs and other issues with the new trio based cards and some of the new code. If you don't run alot of multicast these wouldn't really apply to you. For us, we use them heavily in the edge, and that hasn't been the smoothest of rides. My guess is if you need them for peering or in the core, you might have less issues, but not necessarily (we already know of core applications where the MX could be troublesome - but the edge role takes the cake, by far). There are also some limitations, so far, if we use them as BRAS's, but these are mostly bugs are feature unavailability at this time. The problem is that without the feature being present today, it's hard to know how the box will scale, which could be a big problem unto itself. All in all, it depends on the complexity/sophistication of your deployment, the role you're placing the MX in, and what features you're going to need. For some folk, it's the perfect box. For others, it's less so. Mark. ___ 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 ___ 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] SRX vx IPad IOS Junos Pulse
Last time I looked (which was a while ago), the iPad/iPhone version of pulse
used SSL to establish the VPN Tunnel.
The SRX only support Pulse over IPSEC (which the Windows client also supports).
The Secure Access (now Juniper Pulse Gateway/MAGx600) appliance supports both
SSL and IPSEC termination using Pulse.
Confused? ; )
On 28/06/2011, at 11:00 AM, Correa Adolfo wrote:
From internet explorer in Windows I can download, install and establish VPN
but not from IOS in iPad.
I think JunOS pulse supports IPsec (SRX dynamic vpn), SRX is generating self
certificate but I accept it on iPad screen. Following is seen in the iPad
JunOS registers:
20110627194718.892045 Pulse Mobile[p218.t1799] info Configuration
authentication method is: Password (VPNDeviceImplementation.m:426)
20110627194718.892888 Pulse Mobile[p218.t1799] info LoginManager:: Starting
VPN. (Logger.m:92)
20110627194718.895958 Pulse Mobile[p218.t1799] info VPNManager:: Start
tunnel. (VPNManager.m:149)
20110627194718.897147 Pulse Mobile[p218.t1799] info Connection status changed
to Estableciendo contacto (SSLVPNControllerImpl.m:627)
20110627194718.971162 Pulse Mobile[p218.t1799] info User Agent:
JunosPulseiPad (null) (LoginManager.m:1239)
20110627194718.972305 Pulse Mobile[p218.t1799] info
LoginManager::shouldStartLoadWithRequest with URL: about:blank and navigation
type: 5 (LoginManager.m:1242)
20110627194718.976269 Pulse Mobile[p218.t1799] error Failed to connect to the
server, error = Error Domain=NSURLErrorDomain Code=-1004 No se ha podido
establecer conexión con el servidor. UserInfo=0x1e0350
{NSErrorFailingURLStringKey=https://200.52.93.228/dana/home/am_params.cgi?am=nc,
NSErrorFailingURLKey=https://200.52.93.228/dana/home/am_params.cgi?am=nc,
NSLocalizedDescription=No se ha podido establecer conexión con el servidor.,
NSUnderlyingError=0x15fd10 No se ha podido establecer conexión con el
servidor.} (SSLVPNControllerImpl.m:332)
20110627194718.977317 Pulse Mobile[p218.t1799] info Connection status changed
to Desconectado (SSLVPNControllerImpl.m:627)
20110627194718.983778 Pulse Mobile[p218.t1799] info LoginManager:: VPN
disconnected. (Logger.m:92)
___
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] SRX vx IPad IOS Junos Pulse
On Mon, Jun 27, 2011 at 6:12 PM, Ben Dale bd...@comlinx.com.au wrote: Last time I looked (which was a while ago), the iPad/iPhone version of pulse used SSL to establish the VPN Tunnel. The SRX only support Pulse over IPSEC (which the Windows client also supports). The Secure Access (now Juniper Pulse Gateway/MAGx600) appliance supports both SSL and IPSEC termination using Pulse. Confused? ; ) Indeed, I think that the iOS Pulse client only terminates on gateways running the IVE-style SSL VPN software. I've used both the SA-2500 and MAG2600 for terminating Pulse and Network Connect clients (both to IVE/SSL VPN software), and both worked just fine. As far as the software goes, it's a little bloated (in my opinion), but it gets the job done and CPUs are fast and disk space is cheap nowadays. I've had some luck configuring Macintosh OS X to terminate IPSec/L2TP on an SRX in the past, so presumably the iOS client could be coerced into doing something similar. From what I hear from SEs and resellers is that the SA-2500 (maybe other SA appliances) are being EOLed in favor of the newer MAG appliances. They're Intel Atom boxes that can run the IVE (SSL VPN) or UAC/NAC (802.1x, virus scanning, etc.) software set on the same hardware. I've found them to be a little funky in that they don't seem all that well-suited for datacenter use. The simplest unit (MAG2600) requires an additional tray for rack-mounting, and most seem to have one-sided or side-to-side airflow. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] What do you think about the MX line?
Thank you I will look into that unit some more. Cheers Ryan -Original Message- From: Correa Adolfo [mailto:acor...@mcmtelecom.com.mx] Sent: Monday, June 27, 2011 9:22 PM To: Mehmet Akcin; Ryan Finnesey Cc: juniper-nsp@puck.nether.net Subject: RE: [j-nsp] What do you think about the MX line? Yes, I'd go for MX240 and upper, as you could grow them redundantly and also in memory in the future. -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Mehmet Akcin Sent: domingo, 26 de junio de 2011 11:25 p.m. To: Ryan Finnesey Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] What do you think about the MX line? you probably want MX240-480-960s rather. mehmet On Jun 26, 2011, at 8:59 PM, Ryan Finnesey wrote: We are looking at the MX80s for about 60GB of traffic with also some private MLPS interconnection. Cheers Ryan -Original Message- From: Timothy Kaufman [mailto:tkauf...@corp.nac.net] Sent: Sunday, June 26, 2011 11:49 PM To: Ryan Finnesey; 'mti...@globaltransit.net'; 'juniper-nsp@puck.nether.net' Subject: Re: [j-nsp] What do you think about the MX line? Which one are you looking at? How many peers do you plan to configure? How much traffic? Thanks Tim Kaufman Sent via blackberry - Original Message - From: juniper-nsp-boun...@puck.nether.net juniper-nsp-boun...@puck.nether.net To: mti...@globaltransit.net mti...@globaltransit.net; juniper-nsp@puck.nether.net juniper-nsp@puck.nether.net Sent: Sun Jun 26 22:15:34 2011 Subject: Re: [j-nsp] What do you think about the MX line? For us I will be looking at the MX Line mainly for peering. Anyone having issues with using them with peering? Cheers Ryan -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Mark Tinka Sent: Sunday, June 26, 2011 9:19 PM To: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] What do you think about the MX line? On Monday, June 27, 2011 06:56:48 AM Keegan Holley wrote: I think the general attitude is positive towards them. They are a good compliment to the M/T series and generally solid flexible boxes. You should probably include how you plan to use them in your question. For example a few list members complain about multicast/IGMP bugs and other issues with the new trio based cards and some of the new code. If you don't run alot of multicast these wouldn't really apply to you. For us, we use them heavily in the edge, and that hasn't been the smoothest of rides. My guess is if you need them for peering or in the core, you might have less issues, but not necessarily (we already know of core applications where the MX could be troublesome - but the edge role takes the cake, by far). There are also some limitations, so far, if we use them as BRAS's, but these are mostly bugs are feature unavailability at this time. The problem is that without the feature being present today, it's hard to know how the box will scale, which could be a big problem unto itself. All in all, it depends on the complexity/sophistication of your deployment, the role you're placing the MX in, and what features you're going to need. For some folk, it's the perfect box. For others, it's less so. Mark. ___ 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 ___ 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
