Re: [j-nsp] arp from correct IP address

[Baldur Norddahl]

Yes subscriber management has a lot of small but important things that are
not quite "done". Juniper should put on a task force to get all the bugs
sorted out. Could be a great system if they allow it to be.

For me the trouble with this is that without functioning ARP the customer
becomes "MAC locked". If he wants to upgrade his equipment, he has to call
us so we can clear his session. We have two routers and sometimes a user
somehow manages to register with different MAC addresses on the two.
Needless to say that creates a lot of trouble that will not sort itself
out. With functioning ARP I believe the wrong MAC address would be
corrected soon enough without intervention.

I wish I could just have a user defined radius variable and use that
instead of $junos-preferred-source-address. My script that generates that
radius configuration could easily calculate the correct source address and
program that in with the other radius variables for each user.

I am not creating a JTAC case on this before I have a fix for my other JTAC
cases (IPv6 is broken, dynamic VLAN with IP demux on top is broken, DHCP
combined with non-DHCP is likely also broken). So far I got IPv4 fixed
(access-internal routes ignored, work around use access routes), so they do
work on the problems I report.

Regards,

Baldur


Den man. 27. jan. 2020 kl. 04.53 skrev Chris Kawchuk :

> Ran into the same bug.
>
> $junos-preffered-source-address for an unnumbered for BNG functions does
> NOT return the "closest/must suitable address" based on the IP+Subnet that
> was given the subscriber... contrary to the BNG template doucmentation. It
> just defaults the actual loopback of the router. (the dynamic template that
> gets created against a demux0. subscriber says $preffered of "NONE")
>
> This means that things like Subscriber "ARP liveliness detection" doesn't
> work/cant work. (since the subscriber won't arp-respond to an ARP requests
> where the source isn't in the local subnet)
>
> I've had a JTAC case open on this for 8 months. Sent full configs, built a
> full lab for them (so they could trigger it remotely), self full PCAPs.
>
> MX204 + JunOS 18.3R + BNG (DHCP/IPoE naturally)
>
> Also on MX80 w/same code - so it's the BNG code, not the platform doing it.
>
> - Ck.
>
>
>
>
> On 25 Jan 2020, at 10:27 pm, Baldur Norddahl  wrote:
>
> Hello
>
> I have a problem where some customer routers refuse to reply to arp from
> our juniper mx204. The arp will look like this:
>
> 11:57:46.934484 Out arp who-has 185.24.169.60 tell 185.24.168.248
>
> The problem is that this should have been "tell 185.24.169.1" because the
> client is in the 185.24.169.0/24 subnet. The interface is
> "unnumbered-address lo0.1" with lo0.1 having both 185.24.168.248 and
> 185.24.169.1 among many others. A Linux box would select the nearest
> address but apparently junos does not know how to do this.
>
> Tried adding in "preferred-source-address $junos-preferred-source-address"
> but this just results in "preferred-source-address NONE" and does nothing.
> Also there is zero documentation on how junos will fill in that variable.
>
> Is there a solution to this? Is there a radius variable I can set with the
> preferred source address?
>
> Regards,
>
> Baldur
> ___
> 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] arp from correct IP address

[Chris Kawchuk]

Ran into the same bug.

$junos-preffered-source-address for an unnumbered for BNG functions does NOT 
return the "closest/must suitable address" based on the IP+Subnet that was 
given the subscriber... contrary to the BNG template doucmentation. It just 
defaults the actual loopback of the router. (the dynamic template that gets 
created against a demux0. subscriber says $preffered of "NONE")

This means that things like Subscriber "ARP liveliness detection" doesn't 
work/cant work. (since the subscriber won't arp-respond to an ARP requests 
where the source isn't in the local subnet)

I've had a JTAC case open on this for 8 months. Sent full configs, built a full 
lab for them (so they could trigger it remotely), self full PCAPs.

MX204 + JunOS 18.3R + BNG (DHCP/IPoE naturally)

Also on MX80 w/same code - so it's the BNG code, not the platform doing it.

- Ck.




> On 25 Jan 2020, at 10:27 pm, Baldur Norddahl  wrote:
> 
> Hello
> 
> I have a problem where some customer routers refuse to reply to arp from
> our juniper mx204. The arp will look like this:
> 
> 11:57:46.934484 Out arp who-has 185.24.169.60 tell 185.24.168.248
> 
> The problem is that this should have been "tell 185.24.169.1" because the
> client is in the 185.24.169.0/24 subnet. The interface is
> "unnumbered-address lo0.1" with lo0.1 having both 185.24.168.248 and
> 185.24.169.1 among many others. A Linux box would select the nearest
> address but apparently junos does not know how to do this.
> 
> Tried adding in "preferred-source-address $junos-preferred-source-address"
> but this just results in "preferred-source-address NONE" and does nothing.
> Also there is zero documentation on how junos will fill in that variable.
> 
> Is there a solution to this? Is there a radius variable I can set with the
> preferred source address?
> 
> Regards,
> 
> Baldur
> ___
> 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] Automation - The Skinny (Was: Re: ACX5448 & ACX710)

[Robert Raszuk]

Hi Adam,

I would almost agree entirely with you except that there are two completely
different reasons for automation.

One as you described is related to service provisioning - here we have full
agreement.

The other one is actually of keeping your network running. Imagine router
maintaining entire control plane perfectly fine, imagine BFD working fine
to the box from peers but dropping between line cards via fabric from 20%
to 80% traffic. Unfortunately this is not a theory but real world :(

Without proper automation in place going way above basic IGP, BGP, LDP, BFD
etc ... you need a bit of clever automation to detect it and either alarm
noc or if they are really smart take such router out of the SPF network
wide. If not you sit and wait till pissed customers call - which is already
a failure.

Sure not everyone needs to be great coder ... but having network eng with
skills sufficient enough to understand code, ability to debug it or at min
design functional blocks of the automation routines are really must have
today.

And I am not even mentioning about all of the new OEM platforms with OS
coming from completely different part of the world :) That's when the real
fun starts and rubber hits the road when network eng can not run gdb on a
daily basis.

Cheers,
Robert.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Automation - The Skinny (Was: Re: ACX5448 & ACX710)

[adamv0025]

> Mark Tinka
> Sent: Friday, January 24, 2020 2:32 PM
> 
> On 24/Jan/20 12:10, Saku Ytti wrote:
> 
> > In my opinion we do roughly the same thing, the same way in networks,
> > with the same protocols since my start of career in 90s, very little
> > has changed and you could drop competent neteng from 90s to today and
> > they'd be immediately productive. Compare this to what has happened to
> > compute the difference is striking.
> 
> Agreed - but is it really enough to the extent that the common buzz
sentence
> nowadays is "Network engineers are dead, they'll all be replaced by
software
> [developers]"?
> 
> I mean, I'd wager that more than half of the problems you find with
> automation and tooling development is a total lack of protocol between
> software developers and network engineers; in the same company. While
> there has been plenty of success with a software developer reading a
> networking-related RFC and writing code for that without needing to
> understand, really, how IP/MPLS networks work, it's a whole other issue
> trying to teach a network engineer how to write code, or a software
> developer what IS-IS actually does.
> 
You nailed it Mark,
My opinion is that this new NetDevOps/NetOps initiative is the biggest
blunder of the networking industry.
If as a network engineer/architect you have some coding skills well good for
you,
But are programming skills a requirement to get into network
engineering/architecture nowadays - that absolutely should not be the case. 
We need skilled network engineers and architects to know how to build and
operate complex networks 
We need skilled developers and system architects to know how to build and
operate complex systems (including network automation systems)
We need these two groups to be able to talk to each other in a constructive
manner - check out Model-driven engineering to get you started.
Following these 3 simple premises you can then afford to have an army of
web-ui clickers - provisioning network services not knowing the first thing
about what' going on in the background of the network automation system. Or
not, and you just handover the web-ui/API to your customers and have them
self-service.  

Imagine a case where network engineer builds an automation solution based on
number of hacks involving ansible, python, ydk, whatever... and this
solution gets traction and is used by the company.
Now that poor networking guy has a full-time job supporting the automation
solution, fixing bugs, developing new functionality and you just lost one
network engineer. This is a good example of jack of all trades but master of
none.
Even if you're a small operation or a start-up hiring a developer and make
him talk to the network engineer in a virtual team is a much better option.



> > People who think that netconf and yang are solving big problems and
> > are key to solve automation probably haven't done much automation.
> 
> Totally agreed. But to also be fair, NETCONF/YANG are normally being
touted
> by vendors (much like Segment Routing, 5G and SD-WAN, but I digress). I've
> not really found actual operators with anything meaningful and useful to
say
> about NETCONF/YANG.
> 
> Raise your hands if I'm talking nonesense.
> 
> For us, we find this whole NETCONF/YANG thing to be too heavy for simple
> instructions you need to send to devices, not to mention the fact that
> support within and between vendors is questionable (FlowSpec, anyone?).
> 
> I mean, that's why Ansible was so pleasing to our fingertips - all you
need is
> SSH and a large-enough, repetitive problem you want to go away quickly.
> 
Don't judge the book by its cover, in other words just give NETCONF and YANG
a try, seriously.

I'd say that NETCONF's biggest advantage over SNMP/CLI is it's transaction
mechanism particularly atomicity and consistency ("all or nothing" and "all
at once") from the full ACID, but all these are addressed by all NOS-es
supporting two stage commit via CLI (As Saku mentioned below), so not a
biggie. 
Sorry Mark XE is not one of those NOS-es, but you could still get the
functionality on XE using NETCONF ;)  

YANG on the other hand gives one a common modelling language for
representing services layer configuration and network layer configuration,
which I find useful.
But I'm a minority, I guess there aren't many of you using RFC8299 & RFC8466
as bases for decomposing your L2 and L3 services and building a service
abstraction layer, on top of network configuration layer, so YMMV.

> > Roughly netconf is new snmp and yang is new mib, what ever they enable
> > could have been enabled by existing protocols decades ago, the
> > advantages are modest and will remain so.
> 
> Completely agreed!
> 
Regarding SNMP vs NETCONF similarities, 
For pulling operational data yes, for pushing configuration not really...
see ACID above.  


> >  The key enabler for
> > automation is device accepting arbitrary new B config when it is
> > running arbitrary new A config and transition 

Re: [j-nsp] Juniper support offline?

[Christian Scholz]

Everything works here again - without resetting.
Looks like it’s recovering



Von meinem iPhone gesendet

> Am 26.01.2020 um 17:08 schrieb Ross Halliday 
> :
> 
> Seems to be back albeit a bit rocky - I could not get in with my previous 
> password and had to reset. SRM and Downloads appear to be functioning
> 
> Ross
> 
> 
> -Original Message-
> From: juniper-nsp  On Behalf Of Thomas 
> Scott
> Sent: January 26, 2020 6:14 AM
> To: Nathan Ward 
> Cc: Juniper NSP 
> Subject: Re: [j-nsp] Juniper support offline?
> 
> Just got off the phone with JTAC and was informed the website was down for
> "maintenance". We managed to open a case last night, but were unable to
> this morning... I'm hoping that the "issue" doesn't last too long..
> 
> Phone number I called was 1-888-314-5822.
> 
> - Thomas Scott | mr.thomas.sc...@gmail.com  
> 
> 
 On Sun, Jan 26, 2020 at 5:28 AM Nathan Ward  wrote:
>> Hi,
>> The published number on the Juniper website - 0080025864737 doesn’t work,
>> and the +1888 US number went to Juniper, but to voicemail.
>> I’ve called the number Liam has posted here (same as above but with +
>> rather than 00), which worked - the agent had told me that there was
>> maintenance yesterday and now there is no way to get copies of images
>> apparently, even JTAC.
>> I was told that there is no ETA for login being restored. All they can do
>> is open a case so I get notified if and when it’s fixed. (Yeah, the agent
>> really said “if and when”).
>> Prsearch disappeared what, Jan 2019.. this year will it be case management
>> and download access we lose for almost a year?
>> On the off chance someone has them and is able to share, I need packages
>> for 18.2R3-S1 for MX204 (so, VMHost), and 18.4R2-S2 for QFX5120.
>> Those are the JTAC recommended versions, so I imagine they’ll be knocking
>> about on plenty of hard drives..
>> Luckily, checksums are still visible on the public site :-)
 On 26/01/2020, at 8:22 PM, Liam Farr  wrote:
>>> I just messaged some local at Juniper NZ and they advised that
>> +80025864737 is working for support.
>>> Seems to work from my 2D mobile here too.
>>> Cheers
>>> Liam
>>> On Sun, 26 Jan 2020 at 8:16 PM, Nathan Ward > > wrote:
>>> Hi,
>>> Looks to me and colleagues of mine like Juniper support is offline.
>>> Last night, I was able to log in but trying to download an image got to
>> some stage of the redirect process and hung, then a please try again later
>> message. It persisted for the next few hours of me trying every now and
>> then.
>>> Today, I can’t log in at all - Invalid user/password.
>>> Password reset process works, but, still doesn’t let me in. Different
>> browsers, cleared cache, all the usual “is it on at the wall sir” debugging.
>>> Hearing the same story for others.
>>> I’ve called both the NZ 00800 (international 800) and the US +1888
>> number. The former says “call cannot be completed”. The US number says
>> “high volume of calls please leave a message”.
>>> We’re in New Zealand - unsure if that’s relevant.
>>> Are others having these same issues?
>>> Any insight in to what’s going on?
>>> It’s a long weekend here, so the local sales/SE/etc. folks I usually
>> deal with are likely not anywhere near their phones.
>>> --
>>> Nathan Ward
>>> ___
>>> juniper-nsp mailing list juniper-nsp@puck.nether.net > juniper-nsp@puck.nether.net>
>>> https://puck.nether.net/mailman/listinfo/juniper-nsp <
>> https://puck.nether.net/mailman/listinfo/juniper-nsp>
>>> --
>>> Kind Regards
>>> Liam Farr
>>> Maxum Data
>>> +64-9-950-5302
>> ___
>> 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] Juniper support offline?

[Ross Halliday]

Seems to be back albeit a bit rocky - I could not get in with my previous 
password and had to reset. SRM and Downloads appear to be functioning

Ross


-Original Message-
From: juniper-nsp  On Behalf Of Thomas 
Scott
Sent: January 26, 2020 6:14 AM
To: Nathan Ward 
Cc: Juniper NSP 
Subject: Re: [j-nsp] Juniper support offline?

Just got off the phone with JTAC and was informed the website was down for
"maintenance". We managed to open a case last night, but were unable to
this morning... I'm hoping that the "issue" doesn't last too long..

Phone number I called was 1-888-314-5822.

- Thomas Scott | mr.thomas.sc...@gmail.com  


On Sun, Jan 26, 2020 at 5:28 AM Nathan Ward  wrote:

> Hi,
>
> The published number on the Juniper website - 0080025864737 doesn’t work,
> and the +1888 US number went to Juniper, but to voicemail.
>
> I’ve called the number Liam has posted here (same as above but with +
> rather than 00), which worked - the agent had told me that there was
> maintenance yesterday and now there is no way to get copies of images
> apparently, even JTAC.
> I was told that there is no ETA for login being restored. All they can do
> is open a case so I get notified if and when it’s fixed. (Yeah, the agent
> really said “if and when”).
>
> Prsearch disappeared what, Jan 2019.. this year will it be case management
> and download access we lose for almost a year?
>
>
> On the off chance someone has them and is able to share, I need packages
> for 18.2R3-S1 for MX204 (so, VMHost), and 18.4R2-S2 for QFX5120.
> Those are the JTAC recommended versions, so I imagine they’ll be knocking
> about on plenty of hard drives..
> Luckily, checksums are still visible on the public site :-)
>
> > On 26/01/2020, at 8:22 PM, Liam Farr  wrote:
> >
> > I just messaged some local at Juniper NZ and they advised that
> +80025864737 is working for support.
> >
> > Seems to work from my 2D mobile here too.
> >
> >
> > Cheers
> >
> > Liam
> >
> > On Sun, 26 Jan 2020 at 8:16 PM, Nathan Ward  > wrote:
> > Hi,
> >
> > Looks to me and colleagues of mine like Juniper support is offline.
> >
> > Last night, I was able to log in but trying to download an image got to
> some stage of the redirect process and hung, then a please try again later
> message. It persisted for the next few hours of me trying every now and
> then.
> >
> > Today, I can’t log in at all - Invalid user/password.
> > Password reset process works, but, still doesn’t let me in. Different
> browsers, cleared cache, all the usual “is it on at the wall sir” debugging.
> >
> > Hearing the same story for others.
> >
> > I’ve called both the NZ 00800 (international 800) and the US +1888
> number. The former says “call cannot be completed”. The US number says
> “high volume of calls please leave a message”.
> >
> > We’re in New Zealand - unsure if that’s relevant.
> >
> >
> > Are others having these same issues?
> >
> > Any insight in to what’s going on?
> > It’s a long weekend here, so the local sales/SE/etc. folks I usually
> deal with are likely not anywhere near their phones.
> >
> > --
> > Nathan Ward
> >
> > ___
> > juniper-nsp mailing list juniper-nsp@puck.nether.net  juniper-nsp@puck.nether.net>
> > https://puck.nether.net/mailman/listinfo/juniper-nsp <
> https://puck.nether.net/mailman/listinfo/juniper-nsp>
> > --
> > Kind Regards
> >
> >
> > Liam Farr
> >
> > Maxum Data
> > +64-9-950-5302
>
> ___
> 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] Juniper support offline?

[Thomas Scott]

Just got off the phone with JTAC and was informed the website was down for
"maintenance". We managed to open a case last night, but were unable to
this morning... I'm hoping that the "issue" doesn't last too long..

Phone number I called was 1-888-314-5822.

- Thomas Scott | mr.thomas.sc...@gmail.com  


On Sun, Jan 26, 2020 at 5:28 AM Nathan Ward  wrote:

> Hi,
>
> The published number on the Juniper website - 0080025864737 doesn’t work,
> and the +1888 US number went to Juniper, but to voicemail.
>
> I’ve called the number Liam has posted here (same as above but with +
> rather than 00), which worked - the agent had told me that there was
> maintenance yesterday and now there is no way to get copies of images
> apparently, even JTAC.
> I was told that there is no ETA for login being restored. All they can do
> is open a case so I get notified if and when it’s fixed. (Yeah, the agent
> really said “if and when”).
>
> Prsearch disappeared what, Jan 2019.. this year will it be case management
> and download access we lose for almost a year?
>
>
> On the off chance someone has them and is able to share, I need packages
> for 18.2R3-S1 for MX204 (so, VMHost), and 18.4R2-S2 for QFX5120.
> Those are the JTAC recommended versions, so I imagine they’ll be knocking
> about on plenty of hard drives..
> Luckily, checksums are still visible on the public site :-)
>
> > On 26/01/2020, at 8:22 PM, Liam Farr  wrote:
> >
> > I just messaged some local at Juniper NZ and they advised that
> +80025864737 is working for support.
> >
> > Seems to work from my 2D mobile here too.
> >
> >
> > Cheers
> >
> > Liam
> >
> > On Sun, 26 Jan 2020 at 8:16 PM, Nathan Ward  > wrote:
> > Hi,
> >
> > Looks to me and colleagues of mine like Juniper support is offline.
> >
> > Last night, I was able to log in but trying to download an image got to
> some stage of the redirect process and hung, then a please try again later
> message. It persisted for the next few hours of me trying every now and
> then.
> >
> > Today, I can’t log in at all - Invalid user/password.
> > Password reset process works, but, still doesn’t let me in. Different
> browsers, cleared cache, all the usual “is it on at the wall sir” debugging.
> >
> > Hearing the same story for others.
> >
> > I’ve called both the NZ 00800 (international 800) and the US +1888
> number. The former says “call cannot be completed”. The US number says
> “high volume of calls please leave a message”.
> >
> > We’re in New Zealand - unsure if that’s relevant.
> >
> >
> > Are others having these same issues?
> >
> > Any insight in to what’s going on?
> > It’s a long weekend here, so the local sales/SE/etc. folks I usually
> deal with are likely not anywhere near their phones.
> >
> > --
> > Nathan Ward
> >
> > ___
> > juniper-nsp mailing list juniper-nsp@puck.nether.net  juniper-nsp@puck.nether.net>
> > https://puck.nether.net/mailman/listinfo/juniper-nsp <
> https://puck.nether.net/mailman/listinfo/juniper-nsp>
> > --
> > Kind Regards
> >
> >
> > Liam Farr
> >
> > Maxum Data
> > +64-9-950-5302
>
> ___
> 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] Juniper support offline?

[Nathan Ward]

Hi,

The published number on the Juniper website - 0080025864737 doesn’t work, and 
the +1888 US number went to Juniper, but to voicemail.

I’ve called the number Liam has posted here (same as above but with + rather 
than 00), which worked - the agent had told me that there was maintenance 
yesterday and now there is no way to get copies of images apparently, even JTAC.
I was told that there is no ETA for login being restored. All they can do is 
open a case so I get notified if and when it’s fixed. (Yeah, the agent really 
said “if and when”).

Prsearch disappeared what, Jan 2019.. this year will it be case management and 
download access we lose for almost a year?


On the off chance someone has them and is able to share, I need packages for 
18.2R3-S1 for MX204 (so, VMHost), and 18.4R2-S2 for QFX5120.
Those are the JTAC recommended versions, so I imagine they’ll be knocking about 
on plenty of hard drives..
Luckily, checksums are still visible on the public site :-)

> On 26/01/2020, at 8:22 PM, Liam Farr  wrote:
> 
> I just messaged some local at Juniper NZ and they advised that +80025864737 
> is working for support. 
> 
> Seems to work from my 2D mobile here too. 
> 
> 
> Cheers
> 
> Liam
> 
> On Sun, 26 Jan 2020 at 8:16 PM, Nathan Ward  > wrote:
> Hi,
> 
> Looks to me and colleagues of mine like Juniper support is offline.
> 
> Last night, I was able to log in but trying to download an image got to some 
> stage of the redirect process and hung, then a please try again later 
> message. It persisted for the next few hours of me trying every now and then.
> 
> Today, I can’t log in at all - Invalid user/password.
> Password reset process works, but, still doesn’t let me in. Different 
> browsers, cleared cache, all the usual “is it on at the wall sir” debugging.
> 
> Hearing the same story for others.
> 
> I’ve called both the NZ 00800 (international 800) and the US +1888 number. 
> The former says “call cannot be completed”. The US number says “high volume 
> of calls please leave a message”.
> 
> We’re in New Zealand - unsure if that’s relevant.
> 
> 
> Are others having these same issues?
> 
> Any insight in to what’s going on? 
> It’s a long weekend here, so the local sales/SE/etc. folks I usually deal 
> with are likely not anywhere near their phones.
> 
> --
> Nathan Ward
> 
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net 
> 
> https://puck.nether.net/mailman/listinfo/juniper-nsp 
> 
> -- 
> Kind Regards
> 
> 
> Liam Farr
> 
> Maxum Data
> +64-9-950-5302

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp