[j-nsp] EX boot loader

[joe mcguckin]

Anyone know what the various variables (e.g. bootsequencing, bootsuccess) do?

Thanks,

Joe


Joe McGuckin
ViaNet Communications

j...@via.net
650-207-0372 cell
650-213-1302 office
650-969-2124 fax



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

Re: [j-nsp] SRX 1500

[Dale Shaw]

Hi,

On Friday, 20 May 2016, Maxwell Cole  wrote:
>
>
> Has anyone used box yet?

[...]


> It looks like a nice box 12 Copper 1G 4x 1G sfp and 4x 10g sfp+ 2mill fib
> and 86x running Junos 15 at 11k msrp.


srx1500 uses the new disaggregated software model, so it's $11K for
hardware only; you still need to buy software (Junos).

It's a really nice box to use -- really snappy RE. I didn't get to use it
"in anger" but the form factor is great.

Xeon + crypto co-pro + FPGA

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

Re: [j-nsp] Juniper vmx not able to find op and event script files

[Martin T]

Hi,

thanks for reply! Actually I tried that already, but SLAX script file
was still not found:

root@vMX-A> op ?
Possible completions:
  

Re: [j-nsp] SRX 1500

[Hugo Slabbert]

Fair enough; probably better stated as "*even* more fixed form factor" 
given room for one single-width card in the SRX1400 vs. 2x PIM slots on the 
1500.



1500 seems like a fair compromise


Agreed ;)

--
Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
pgp key: B178313E   | also on Signal

On Thu 2016-May-19 14:10:59 -0700, Brent Jones  wrote:


The 1400's are basically a fixed form factor too - never saw much in the
way of an upgrade path (unless you just jump to 3400's).
1500 seems like a fair compromise

On Thu, May 19, 2016 at 2:06 PM, Hugo Slabbert  wrote:



On Thu 2016-May-19 14:03:31 -0700, Brent Jones 
wrote:

I use SRX1400's, so if the 1500 is just a "newer, better. faster", I'm

interested.



More juice; more of a fixed form factor.  Also running 1400s and have not
yet toyed with the 1500s.
--
Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
pgp key: B178313E   | also on Signal




On Thu, May 19, 2016 at 12:57 PM, Maxwell Cole <
mcole.mailingli...@gmail.com


wrote:



Heya.


Has anyone used box yet?


http://www.juniper.net/us/en/products-services/security/srx-series/srx1500/
<

http://www.juniper.net/us/en/products-services/security/srx-series/srx1500/
>

It looks like a nice box 12 Copper 1G 4x 1G sfp and 4x 10g sfp+ 2mill fib
and 86x running Junos 15 at 11k msrp. Looks like it might be pretty
interesting for a small deploy depending on the speeds it can get in
packet
mode. Pick up a table or two on the sfp+ and an IX on the 1g sip.
Anyone comment on convergence time, feature set, commit time etc? I see
16G of ram which should be nice for its RIB but no info on the CPU
itself.
Is it a xeon?

Looks like a very interesting box but I have yet to hear anything about
it.

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





--
Brent Jones
br...@brentrjones.com
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp






--
Brent Jones
br...@brentrjones.com


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

Re: [j-nsp] SRX 1500

[Brent Jones]

The 1400's are basically a fixed form factor too - never saw much in the
way of an upgrade path (unless you just jump to 3400's).
1500 seems like a fair compromise

On Thu, May 19, 2016 at 2:06 PM, Hugo Slabbert  wrote:

>
> On Thu 2016-May-19 14:03:31 -0700, Brent Jones 
> wrote:
>
> I use SRX1400's, so if the 1500 is just a "newer, better. faster", I'm
>> interested.
>>
>
> More juice; more of a fixed form factor.  Also running 1400s and have not
> yet toyed with the 1500s.
> --
> Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
> pgp key: B178313E   | also on Signal
>
>
>
>> On Thu, May 19, 2016 at 12:57 PM, Maxwell Cole <
>> mcole.mailingli...@gmail.com
>>
>>> wrote:
>>>
>>
>> Heya.
>>>
>>> Has anyone used box yet?
>>>
>>>
>>> http://www.juniper.net/us/en/products-services/security/srx-series/srx1500/
>>> <
>>>
>>> http://www.juniper.net/us/en/products-services/security/srx-series/srx1500/
>>> >
>>>
>>> It looks like a nice box 12 Copper 1G 4x 1G sfp and 4x 10g sfp+ 2mill fib
>>> and 86x running Junos 15 at 11k msrp. Looks like it might be pretty
>>> interesting for a small deploy depending on the speeds it can get in
>>> packet
>>> mode. Pick up a table or two on the sfp+ and an IX on the 1g sip.
>>> Anyone comment on convergence time, feature set, commit time etc? I see
>>> 16G of ram which should be nice for its RIB but no info on the CPU
>>> itself.
>>> Is it a xeon?
>>>
>>> Looks like a very interesting box but I have yet to hear anything about
>>> it.
>>>
>>> Cheers,
>>> Max
>>> ___
>>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>>
>>>
>>
>>
>> --
>> Brent Jones
>> br...@brentrjones.com
>> ___
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
>


-- 
Brent Jones
br...@brentrjones.com
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] SRX 1500

[Hugo Slabbert]

On Thu 2016-May-19 14:03:31 -0700, Brent Jones  wrote:


I use SRX1400's, so if the 1500 is just a "newer, better. faster", I'm
interested.


More juice; more of a fixed form factor.  Also running 1400s and have not 
yet toyed with the 1500s. 


--
Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
pgp key: B178313E   | also on Signal



On Thu, May 19, 2016 at 12:57 PM, Maxwell Cole 

It looks like a nice box 12 Copper 1G 4x 1G sfp and 4x 10g sfp+ 2mill fib
and 86x running Junos 15 at 11k msrp. Looks like it might be pretty
interesting for a small deploy depending on the speeds it can get in packet
mode. Pick up a table or two on the sfp+ and an IX on the 1g sip.
Anyone comment on convergence time, feature set, commit time etc? I see
16G of ram which should be nice for its RIB but no info on the CPU itself.
Is it a xeon?

Looks like a very interesting box but I have yet to hear anything about it.

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





--
Brent Jones
br...@brentrjones.com
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


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

Re: [j-nsp] SRX 1500

[Brent Jones]

I use SRX1400's, so if the 1500 is just a "newer, better. faster", I'm
interested.


On Thu, May 19, 2016 at 12:57 PM, Maxwell Cole  wrote:

> Heya.
>
> Has anyone used box yet?
>
> http://www.juniper.net/us/en/products-services/security/srx-series/srx1500/
> <
> http://www.juniper.net/us/en/products-services/security/srx-series/srx1500/
> >
>
> It looks like a nice box 12 Copper 1G 4x 1G sfp and 4x 10g sfp+ 2mill fib
> and 86x running Junos 15 at 11k msrp. Looks like it might be pretty
> interesting for a small deploy depending on the speeds it can get in packet
> mode. Pick up a table or two on the sfp+ and an IX on the 1g sip.
> Anyone comment on convergence time, feature set, commit time etc? I see
> 16G of ram which should be nice for its RIB but no info on the CPU itself.
> Is it a xeon?
>
> Looks like a very interesting box but I have yet to hear anything about it.
>
> Cheers,
> Max
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>



-- 
Brent Jones
br...@brentrjones.com
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] vSRX Cluster ip-monitoring secondary address

[Hugo Slabbert]

In that case, you build a LAG on node0 that goes to a LAG on the switch, 
and a LAG on node1 that goes to a separate LAG on the switch.


Is that the setup you're having issues with?  e.g. (assuming a 2-member EX 
switch on the other end for simplicity's sake):


 |= - ge-0/0/0 <---> ge-0/0/0 -
srx1 | /   \
 |=   /-- ge-0/0/1 <---> ge-1/0/0 --- ae0 on some switch
 /
reth0 (w/ lacp)
 \
 |=   \-- ge-1/0/0 <---> ge-0/0/1 --- ae1 on some switch
srx2 | \   /
 |= - ge-1/0/1 <---> ge-1/0/1 -


We have that running in production without issue, though we are not using 
IP monitoring.


The key part is in that diagram is that the 2 LACP interfaces on the 
switch(es) are discrete; you don't have 1 LACP bundle for all 4x SRX 
interfaces together.  There is no actual aeX interface on the SRX chassis 
cluster; you just add LACP config to the reth, and the links are brought up 
sensibly given the LACP config on the other (switch) end with two discrete 
bundles:



show configuration interfaces reth0

description "Outside Shared Interface to EX Stack (ge-0/0/16 and ge-1/0/16)";
redundant-ether-options {
redundancy-group 1;
lacp {
active;
periodic fast;
}
}

Again, we're not running ip-monitoring, so I'm not sure if that is 
also/still problematic even with the LAGs sorted out.


--
Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
pgp key: B178313E   | also on Signal

On Thu 2016-May-19 20:22:45 +0100, sukhjit.ha...@googlemail.com 
 wrote:




Hi Hugo

No you have it wrong, say you wanted to double the links from node0 to switch 1 
or node1 to switch 2 because it was close to being utilised.

That's the design where static routing/ip-monitoring is not supported per the 
initial email I sent and due to issue that I described.

--
BR

Sukhjit Hayre
2xCCIE #40428 (SP, R/S)

Sent from iPhone


On 19 May 2016, at 19:51, Hugo Slabbert  wrote:

This is very delayed, but are you connecting up the reth members to a LAG?  e.g.

reth0 members are:
- srx1: ge-0/0/0
- srx2: ge-1/0/0

srx1  ge-0/0/0 <---> ge-a/b/c
/   \
   reth0 aeX some switch (or MC-LAG setup)
\   /
srx2  ge-1/0/0 <---> ge-x/y/z

That's not how reth's work.  The reth is not a LAG; ge-a/b/c and ge-x/y/z on 
the switch should be discrete interfaces, just running the same config (e.g. 
same access VLAN or trunks with same member VLANs).

Does that make sense?

--
Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
pgp key: B178313E   | also on Signal


On Mon 2015-Mar-16 20:47:33 +, Sukhjit Hayre  
wrote:

hi all,

I managed to resolve this issue as being down to the arp replies not being
deterministic from the switch port-channel facing the secondary SRX cluster
node1.

i.e they would use the incorrect physical interface from the port-channel
list, where the arp's are sourced from the lowest physical interface number
it seems from node1.

so to me it seems unless junos supports a valid way of not using the
physical interface mac-address i.e moving this mac-address to a second
rethX.X sub-interface then a dual legged design from each SRX to the
switches which could be running MC-LAG or vPC (or simple LACP to the same
switch) then ip-monitoring for this purpose would not be supported.

I would be surprised if this has not been considered, I am new to junos so
go easy on me ;)

br

On Mon, Mar 16, 2015 at 12:22 PM, Sukhjit Hayre <
sukhjit.ha...@googlemail.com> wrote:



I'm confused on where to physically or logically assign this address.

I have declared my secondary address in the ip-monitoring stanza but the
connected Router is receiving quite a few ARPs from this address because
it's trying to ICMP for IP-monitoring purposes

Issue is where do I expect the ARP to be received back on by Node1 as I
can see the reth1 child physical mac is being used to source the ARP and I
can the Router reply back to this MAC address

The source address from the primary reth1 (node0) is ICMP'd fine but not
the secondary this causes issues down the line as the ip-monitoring
pre-check fails hence the node1 chassis is not ready to take the data-plane
for one of my redundancy-groups in this case RG1

Any pointers on this would be appreciated

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


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

[j-nsp] SRX 1500

[Maxwell Cole]

Heya.

Has anyone used box yet? 

http://www.juniper.net/us/en/products-services/security/srx-series/srx1500/ 


It looks like a nice box 12 Copper 1G 4x 1G sfp and 4x 10g sfp+ 2mill fib and 
86x running Junos 15 at 11k msrp. Looks like it might be pretty interesting for 
a small deploy depending on the speeds it can get in packet mode. Pick up a 
table or two on the sfp+ and an IX on the 1g sip. 
Anyone comment on convergence time, feature set, commit time etc? I see 16G of 
ram which should be nice for its RIB but no info on the CPU itself. Is it a 
xeon?

Looks like a very interesting box but I have yet to hear anything about it.

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

Re: [j-nsp] vSRX Cluster ip-monitoring secondary address

[Hugo Slabbert]

This is very delayed, but are you connecting up the reth members to a LAG?  
e.g.


reth0 members are:
- srx1: ge-0/0/0
- srx2: ge-1/0/0

srx1  ge-0/0/0 <---> ge-a/b/c
 /   \
reth0 aeX some switch (or MC-LAG setup)
 \   /
srx2  ge-1/0/0 <---> ge-x/y/z

That's not how reth's work.  The reth is not a LAG; ge-a/b/c and ge-x/y/z 
on the switch should be discrete interfaces, just running the same config 
(e.g. same access VLAN or trunks with same member VLANs).


Does that make sense?

--
Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
pgp key: B178313E   | also on Signal

On Mon 2015-Mar-16 20:47:33 +, Sukhjit Hayre  
wrote:


hi all,

I managed to resolve this issue as being down to the arp replies not being
deterministic from the switch port-channel facing the secondary SRX cluster
node1.

i.e they would use the incorrect physical interface from the port-channel
list, where the arp's are sourced from the lowest physical interface number
it seems from node1.

so to me it seems unless junos supports a valid way of not using the
physical interface mac-address i.e moving this mac-address to a second
rethX.X sub-interface then a dual legged design from each SRX to the
switches which could be running MC-LAG or vPC (or simple LACP to the same
switch) then ip-monitoring for this purpose would not be supported.

I would be surprised if this has not been considered, I am new to junos so
go easy on me ;)

br

On Mon, Mar 16, 2015 at 12:22 PM, Sukhjit Hayre <
sukhjit.ha...@googlemail.com> wrote:



I'm confused on where to physically or logically assign this address.

I have declared my secondary address in the ip-monitoring stanza but the
connected Router is receiving quite a few ARPs from this address because
it's trying to ICMP for IP-monitoring purposes

Issue is where do I expect the ARP to be received back on by Node1 as I
can see the reth1 child physical mac is being used to source the ARP and I
can the Router reply back to this MAC address

The source address from the primary reth1 (node0) is ICMP'd fine but not
the secondary this causes issues down the line as the ip-monitoring
pre-check fails hence the node1 chassis is not ready to take the data-plane
for one of my redundancy-groups in this case RG1

Any pointers on this would be appreciated




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


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

Re: [j-nsp] srrd process

[Tim Jackson]

451m here on an MX104 running 14.2:

 2269 root 1  400   451M   445M select  36:07  0.00% srrd

Looks to be the sampling daemon:

http://www.juniper.net/techpubs/en_US/junos15.1/information-products/topic-collections/release-notes/15.1F5/topic-104232.html

With Junos OS Release 15.1F2 and later, when inline sampling is enabled on
MX Series-based FPC, the srrd (Sampling Route-Record Daemon) process would
be created to maintain, collect and export JFLOW records. On a regular time
intervals, the srrd scans through the sampling database for any
update/change in the record. In a scaled environment with more route churn,
for example 1.14M routes, the scan process might hog CPU for more than
2.5sec which leads to FPC crash. In some situations, the scan process can
run for longer time without causing FPC crash, but it can cause BFD
sessions to flap. PR1158154

--
Tim


On Thu, May 19, 2016 at 12:03 PM, Han Hwei Woo 
wrote:

> We had an MX80 become unresponsive the other night while trying to turn
> down our peers at an exchange during a maintenance, which was due to
> running out of RAM and a bunch of processes swapping out. We had recently
> upgraded to 14.2R6.5, and have now noticed there is a new process that
> wasn't present in 12.3 and 13.3.
>
>   PID USERNAME   THR PRI NICE   SIZERES STATETIME   WCPU
> COMMAND
>  1733 root 1   40   778M   705M kqread  43:13  0.73% rpd
>  1745 root 1  400   585M   578M select   0:20  0.00% srrd
>
> I can't seem to find anything about what srrd is. Anyone have any ideas,
> and what function it serves? Almost 600MB out of a total 2GB on an MX80 is
> quite a good portion.
>
> --
> Han Hwei Woo
> h...@astutehosting.com
>
> Astute Hosting Incorporated
> T: 1.888.685.1661 (604.637.7939)
> M: 604.417.2092
> F: 604.738.0518
> www.astutehosting.com
> 100% Uptime Dedicated Hosting in Vancouver, Seattle,
> Los Angeles, Toronto, New York, and Miami
>
> ___
> 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] srrd process

[Han Hwei Woo]

We had an MX80 become unresponsive the other night while trying to turn 
down our peers at an exchange during a maintenance, which was due to 
running out of RAM and a bunch of processes swapping out. We had 
recently upgraded to 14.2R6.5, and have now noticed there is a new 
process that wasn't present in 12.3 and 13.3.


  PID USERNAME   THR PRI NICE   SIZERES STATETIME   WCPU 
COMMAND

 1733 root 1   40   778M   705M kqread  43:13  0.73% rpd
 1745 root 1  400   585M   578M select   0:20  0.00% srrd

I can't seem to find anything about what srrd is. Anyone have any ideas, 
and what function it serves? Almost 600MB out of a total 2GB on an MX80 
is quite a good portion.


--
Han Hwei Woo
h...@astutehosting.com

Astute Hosting Incorporated
T: 1.888.685.1661 (604.637.7939)
M: 604.417.2092
F: 604.738.0518
www.astutehosting.com
100% Uptime Dedicated Hosting in Vancouver, Seattle,
Los Angeles, Toronto, New York, and Miami

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

Re: [j-nsp] Option B L2vpn

[Saku Ytti]

On 19 May 2016 at 18:02, Adam Vitkovsky  wrote:
> Maybe something like flexible vlan matching, but in this case interface would 
> be selected based on incoming optE label (instead of S-Tag).

Yes. Obviously like OptB you'll need different label per VRF at least.

So you're entirely free to program through which IFL given label is
evaluated. Either common interface or dedicated.

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

Re: [j-nsp] Option B L2vpn

[Adam Vitkovsky]

> Of Saku Ytti
> Sent: Thursday, May 19, 2016 3:38 PM
>
> Before doing OptB, consider the implications.
>
> a) no per customer QoS
> b) no per customer ACL
> c) no per customer counters
> d) need 100% trust on far end, unless RFC4364 page32 last sentence is
> implemented (it is not)
>
> If you have 100% trust, why not just do straight up OptC or native? If you
> don't have 100% trust, you need to do OptA.
>
> There has been some ideas thrown around how to solve this issue, but not
> enough traction. What most people doing MPLS NNI's want is OptA like trust,
> OptB like provisioning, with optional ability to add QoS/ACL/counters when
> needed. There is no technical reason it couldn't exist. I've spent all 5min
> thinking about this, and I'd love to see something like this 
> http://ip.fi/mpls-
> optX.txt
>
Wow the config looks amazing -that's what I want, straightforward per IFL 
control.
But just trying to think how it would work under the hood.
Maybe something like flexible vlan matching, but in this case interface would 
be selected based on incoming optE label (instead of S-Tag).


adam









Adam Vitkovsky
IP Engineer

T:  0333 006 5936
E:  adam.vitkov...@gamma.co.uk
W:  www.gamma.co.uk

This is an email from Gamma Telecom Ltd, trading as “Gamma”. The contents of 
this email are confidential to the ordinary user of the email address to which 
it was addressed. This email is not intended to create any legal relationship. 
No one else may place any reliance upon it, or copy or forward all or any of it 
in any form (unless otherwise notified). If you receive this email in error, 
please accept our apologies, we would be obliged if you would telephone our 
postmaster on +44 (0) 808 178 9652 or email postmas...@gamma.co.uk

Gamma Telecom Limited, a company incorporated in England and Wales, with 
limited liability, with registered number 04340834, and whose registered office 
is at 5 Fleet Place London EC4M 7RD and whose principal place of business is at 
Kings House, Kings Road West, Newbury, Berkshire, RG14 5BY.


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

[j-nsp] Juniper vmx not able to find op and event script files

[Martin T]

Hi,

I have a Juniper vmx router running Junos 14.1R1.10. For some reason
it does not find op and event scripts. For example:

root@vMX-A> file list detail /var/db/scripts/op/

/var/db/scripts/op/:
total blocks: 12
-rw-r--r--  1 root  wheel286 May 19 13:37 test.slax
total files: 1

root@vMX-A> show configuration system scripts
op {
file test.slax;
}

root@vMX-A> op test.slax detail
error: invalid filename: /var/db/scripts/op/test.slax

root@vMX-A>


..or in case of an event script:

[edit]
root@vMX-A# run file list detail /var/db/scripts/event/

/var/db/scripts/event/:
total blocks: 12
-rw-r--r--  1 root  wheel286 May 19 13:25 test.slax
total files: 1

[edit]
root@vMX-A# run file show /var/db/scripts/event/test.slax
version 1.0;

ns junos = "http://xml.juniper.net/junos/*/junos;;
ns xnm = "http://xml.juniper.net/xnm/1.1/xnm;;
ns jcs = "http://xml.juniper.net/junos/commit-scripts/1.0;;

import "../import/junos.xsl";

match / {
{
   }
}

[edit]
root@vMX-A# show | compare
[edit]
+  event-options {
+  event-script {
+  file test.slax;
+  }
+  }

[edit]
root@vMX-A# commit check
error: invalid filename: /var/db/scripts/event//test.slax
error: Reading the configuration from event scripts failed
error: configuration check-out failed

[edit]
root@vMX-A#


I also tried to load scripts from flash("load-scripts-from-flash") and
stored the scripts in respective directory under /config, but this
didn't help.


Am I doing something wrong?


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

Re: [j-nsp] Option B L2vpn

[Saku Ytti]

Before doing OptB, consider the implications.

a) no per customer QoS
b) no per customer ACL
c) no per customer counters
d) need 100% trust on far end, unless RFC4364 page32 last sentence is
implemented (it is not)

If you have 100% trust, why not just do straight up OptC or native? If
you don't have 100% trust, you need to do OptA.

There has been some ideas thrown around how to solve this issue, but
not enough traction. What most people doing MPLS NNI's want is OptA
like trust, OptB like provisioning, with optional ability to add
QoS/ACL/counters when needed. There is no technical reason it couldn't
exist. I've spent all 5min thinking about this, and I'd love to see
something like this http://ip.fi/mpls-optX.txt

On 19 May 2016 at 16:40, Anand Anand  wrote:
> Hi,
>
> Looking for Option B l2vpn configuration using Juniper MX.
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp



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

[j-nsp] Option B L2vpn

[Anand Anand]

Hi,

Looking for Option B l2vpn configuration using Juniper MX.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] BFD/IS-IS wait to re-establish adjacency after failure tweak knob?

[James Bensley]

On 19 May 2016 at 10:53, Mark Tinka  wrote:
>
>
> On 19/May/16 11:49, James Bensley wrote:
>
>> In Cisco land we have the interface command "carrier-delay", for Junos
>> (this scenario) can the OP not use some variant of "set interfaces
>> xe-0/0/1 hold-time up 5000" ?
>
> OP says the issue is remote.
>
> Local link to provider's switch does not fail, and appears to have no
> way of relaying upstream outages to the OP's port.

Ah OK I missread, although in the case the physical interfaces is up
to the carriers switch but the far end is down, BFD should keep the
OP's interface down.

>From the original post:

> However, the IS-IS adjacency is coming up more quickly than desired.
> On average, it is coming up 7-8 seconds later. Unfortunately, the L2
> link is still unstable, so the BFD causes the session to drop again
> fairly quickly. This causes a lot of flapping that I do not need.

OK so assuming BFD is detecting the link as recovered then I think the
only options are dampening or increasing the carrier delay / hold
time.

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

Re: [j-nsp] BFD/IS-IS wait to re-establish adjacency after failure tweak knob?

[Mark Tinka]

On 19/May/16 12:13, Saku Ytti wrote:

> +1 why create higher abstraction layers and complicated notifications
> per protocols, when usually if we need single-hop BFD, we need it
> because we broke physical liveliness detection

+1.

It has always been assumed that routing or signaling protocols are the
clients of BFD. If BFD can be protocol-independent, that would be great.

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

Re: [j-nsp] BFD/IS-IS wait to re-establish adjacency after failure tweak knob?

[Saku Ytti]

On 19 May 2016 at 12:38, Adam Vitkovsky  wrote:

> /rant/
> I don’t understand why BFD can't be configured as a standalone protocol under 
> protocols stanza same way as oam lfm is.
> Something like the below.
> set protocols bfd interface ae0 pdu-interval 100
> set protocols bfd interface ae0 pdu-threshold 3
> set protocols bfd interface ae0 apply-action-profile put-link-to-a-rest
> set protocols bfd action-profile put-link-to-a-rest event link-adjacency-loss
> set protocols bfd action-profile put-link-to-a-rest action link-down
> /rant/

+1 why create higher abstraction layers and complicated notifications
per protocols, when usually if we need single-hop BFD, we need it
because we broke physical liveliness detection

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

Re: [j-nsp] BFD/IS-IS wait to re-establish adjacency after failure tweak knob?

[Mark Tinka]

On 19/May/16 11:49, James Bensley wrote:

> In Cisco land we have the interface command "carrier-delay", for Junos
> (this scenario) can the OP not use some variant of "set interfaces
> xe-0/0/1 hold-time up 5000" ?

OP says the issue is remote.

Local link to provider's switch does not fail, and appears to have no
way of relaying upstream outages to the OP's port.

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

Re: [j-nsp] BFD/IS-IS wait to re-establish adjacency after failure tweak knob?

[James Bensley]

In Cisco land we have the interface command "carrier-delay", for Junos
(this scenario) can the OP not use some variant of "set interfaces
xe-0/0/1 hold-time up 5000" ?

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

Re: [j-nsp] BFD/IS-IS wait to re-establish adjacency after failure tweak knob?

[Adam Vitkovsky]

> Clarke Morledge
> Sent: Wednesday, May 18, 2016 11:54 PM
>
> I am trying to figure out the best way to configure an MX router, on an
> interface, to wait a specific time before it can re-establish an IS-IS 
> adjacency,
> after an adjacency has been lost.
>
> Assume I am using BFD with reasonably short timers/multipliers to detect
> when an IS-IS adjacency fails, without changing the default IS-IS timers.
> I have a situation where a point-to-point link, with an L2 device in between, 
> is
> sometimes losing the adjacency, as desired, due to BFD timers/mulipliers
> downing a session.
>
> However, the IS-IS adjacency is coming up more quickly than desired. On
> average, it is coming up 7-8 seconds later. Unfortunately, the L2 link is 
> still
> unstable, so the BFD causes the session to drop again fairly quickly. This
> causes a lot of flapping that I do not need.
>
> What is the appropriate JUNOS tweak knob to force IS-IS to wait a longer
> time on the unstable link, before trying to establish the adjacency?
>
I see what you mean I'm afraid there's no "ISIS adjacency dampening" feature.
And unfortunately there's no support to register the BFD session directly with 
physical link or IFL to monitor it's state.
Another option would be to use event options and disabling and enabling the 
interface manually, but once again I see there's no support for BFD (maybe in 
your version of code there will be).
So I guess what you remain with is LFM link-fault-management (you can use sub 
second timers there) to put the interface to a rest and use "hold-time up" to 
introduce a desired delay getting it up again.

/rant/
I don’t understand why BFD can't be configured as a standalone protocol under 
protocols stanza same way as oam lfm is.
Something like the below.
set protocols bfd interface ae0 pdu-interval 100
set protocols bfd interface ae0 pdu-threshold 3
set protocols bfd interface ae0 apply-action-profile put-link-to-a-rest
set protocols bfd action-profile put-link-to-a-rest event link-adjacency-loss
set protocols bfd action-profile put-link-to-a-rest action link-down
/rant/


adam











Adam Vitkovsky
IP Engineer

T:  0333 006 5936
E:  adam.vitkov...@gamma.co.uk
W:  www.gamma.co.uk

This is an email from Gamma Telecom Ltd, trading as “Gamma”. The contents of 
this email are confidential to the ordinary user of the email address to which 
it was addressed. This email is not intended to create any legal relationship. 
No one else may place any reliance upon it, or copy or forward all or any of it 
in any form (unless otherwise notified). If you receive this email in error, 
please accept our apologies, we would be obliged if you would telephone our 
postmaster on +44 (0) 808 178 9652 or email postmas...@gamma.co.uk

Gamma Telecom Limited, a company incorporated in England and Wales, with 
limited liability, with registered number 04340834, and whose registered office 
is at 5 Fleet Place London EC4M 7RD and whose principal place of business is at 
Kings House, Kings Road West, Newbury, Berkshire, RG14 5BY.


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