[j-nsp] j series query not answered on the KB

Ben Dale bdale at comlinx.com.au
Wed Apr 8 18:24:21 EDT 2009


In order to make a configuration change such as a routing update, you  
will have to write a op script triggered by an event though - there is  
a good example on the JUNOS website which disables an interface when  
an rpm probe fails:

http://junos.juniper.net/scripts/op_scripts/default.asp?docId=13055

Here's one to get you started - I wrote it for a client who was having  
issues with their ADSL services occasionally not restarting after a  
link flap (it seems to be an issue with certain DSLAMs and the ADSL  
PIM).

# Event Script and RPM Probe to check for WAN connectivity.  Script  
will restart
# PPPOE service on ADSL if far-end target is unreachable.

set services rpm probe comlinx test ping-ka probe-type icmp-ping
set services rpm probe comlinx test ping-ka target address 10.10.20.105
set services rpm probe comlinx test ping-ka probe-count 3
set services rpm probe comlinx test ping-ka probe-interval 1
set services rpm probe comlinx test ping-ka test-interval 60
set services rpm probe comlinx test ping-ka thresholds successive-loss 3
set services rpm probe comlinx test ping-ka traps test-failure

set event-options policy pppoe-restart events ping_test_failed
set event-options policy pppoe-restart then execute-commands commands  
"restart pppoe"
set event-options policy pppoe-restart then execute-commands user-name  
testuser
set event-options policy pppoe-restart then raise-trap

set event-options policy everythingsokayalarm events ping_test_completed
set event-options policy everythingsokayalarm then ignore

The rpm probe will run 3 pings every 60 seconds.  If three drop, then  
it will send an SNMP trap.
The log message (not the SNMP trap) that is generated when the rpm  
probe fails (PING_TEST_FAILED) will be seen by the event-options  
script and trigger the pppoe-restart event, which issues the "restart  
pppoe" command and rasies another trap to signal this happening.  As  
it is, the boxes these scripts are running on only have a single ADSL  
link, so the trap rarely gets seen by the trap host because the link  
is still down.

The "everythingsokayalarm" is used to filter out all the  
PING_TEST_SUCCESSFUL messages that will fill up your log file when you  
create an RPM probe.  It would make more sense to me if there was a  
way of filtering event notifications from the probe definition itself,  
but I couldn't find anything in the doco (8.3).

Be very careful with rpm probe thresholds and event-generated policy  
changes though.  Test what happens when a box is rebooted - i.e. make  
sure that before routing adjacencies come up that your script doesn't  
kick off and start flapping the link.  Also make sure your test  
intervals aren't too short, and that your method for recovering the  
original link isn't going to cause flapping between both services..

Good luck!

Ben



On 08/04/2009, at 3:00 AM, Andrew Jimmy wrote:

Hi do you have any real time example for Junos scripting. Run ping  
checks
and change static route based on result. If yea, can you please share  
the
code and the way it works.....


-----Original Message-----
From: juniper-nsp-bounces at puck.nether.net
[mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of Patrik Olsson
Sent: Tuesday, April 07, 2009 7:47 PM
To: Nick Ryce
Cc: juniper-nsp at puck.nether.net
Subject: Re: [j-nsp] j series query not answered on the KB

Hello!

1. There is a standard which even Cisco supports called BFD. That tracks
routes from all protcols including static routes. So if the other end
supports BFD, that settles it.

2. Dynamic routing using OSPF/ISIS/BGP?

3. Junos scripting. Run ping checks and change static route based on  
result.


Cheers
Patrik

> Hi there,
>
> I have predominantly used cisco and have recently forayed into the  
> land of
juniper and have the following question regarding a J2320 with junos 9.
>
> I have a j2320 with a 100meg metro ethernet connected on interface 0  
> with
a /30 link subnet (for example 10.0.0.0./30) this is also the default
gateway.
> Interface 1 is connected to a 10meg metro Ethernet with a /30 link  
> subnet
(10.0.1.0/30).
>
> What I am looking to do is have everything go across the 100meg link  
> and
if that goes down then route through the 10 meg.  The only problem is  
that
on interface 0 the link may not show as down as the provider  
connection is
through a switch and the fibre behind that may break.
>
> In cisco land I would use object tracking and set up a rule to ping  
> the
default gateway on interface 0 and when that became unreachable then it
would automagically failover.
>
> The juniper kb gives reference to track-ip but it doesn't seem to be  
> avail
on j series routers.
>
> Any help appreciated.
>
> Nick
>
>
> ________________________________
> --
>
> This email and any files transmitted with it are confidential and  
> intended
> solely for the use of the individual or entity to whom they are  
> addressed.
> If you have received this email in error please notify the sender. Any
> offers or quotation of service are subject to formal specification.
> Errors and omissions excepted. Please note that any views or opinions
> presented in this email are solely those of the author and do not
> necessarily represent those of Lumison and nPlusOne.
> Finally, the recipient should check this email and any attachments  
> for the
> presence of viruses. Lumison and nPlusOne accept no liability for any
> damage caused by any virus transmitted by this email.
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp

_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp



More information about the juniper-nsp mailing list