SRX

Is there anyway to bounce an interface which is easier and quicker than:

set {interface} disable
commit
delete {interface} disable
commit

in configuration mode. (which besides being cumbersome and slow, has the effect of adding rollback cruft)

You know, something like many other vendors support (shut/no shut), maybe in Junos-speak, it might be like

request {interface} disable
request {interface} enable

in operational mode.

For a physical interface the disable and deactivate commands are the only options i know of. Both require a commit. 

Disable only disables the port and leaves the configuration active for the port. Deactivate disables all config for the port. Depending on the equipment being used, you can "request chassis fpc slot slot-number online/offline" or "request chassis pic (offline | online) fpc-slot slot-number pic-slot slot-number". This can be done at the operational mode without a commit. 

CAUTION***This disables all interfaces on the particular type of pic or fpc-slot though. If it is one port you are looking to bounce without a commit, manually pull the cable 🙂

HTH,

BL 

---

@Mike.S wrote:

Is there anyway to bounce an interface which is easier and quicker than:

 [...]

in configuration mode. (which besides being cumbersome and slow, has the effect of adding rollback cruft)

You know, something like many other vendors support (shut/no shut), maybe in Junos-speak, it might be like

request {interface} disable
request {interface} enable

in operational mode.

---

I don't have an answer, but I agree on both your points.  This has been one gripe of mine for as long as the moon has been rising.

+5 Internets to you, sir.

Hello,

There are several methods, pick the most appropriate:

1/ on M/T/MX - If you have 1GE copper with autoneg enabled , then

test interface ge-x/y/z restart-auto-negotiation

 2/ on any JUNOS platform (example below for 10GE interface, substitute for your interface name):

start shell user root
ifconfig xe-y/z/w down
ifconfig xe-y/z/w up
exit

 WARNING - if You abort command sequence after "ifconfig .. down" and forget to bring interface up in shell, then Your interface will display   as & stay DOWN in JUNOS CLI printouts and MIB without apparent reason.

3/ in PFE shell, works for 10 GE XFP:

start shell pfe network fpc<number>
show xfp list
test xfp <index> laser off
test xfp <index> laser on

 IMPORTANT: XFP index begins from 1, not 0. Hence, XFP in port xe-0/0/0 will have index 1 locally in FPC 0 shell.

HTH

Thanks

Alex

Alex, interesting suggestions.

#2 is the only one that's more "universal" but the big issues there are that it:

1.  Requires root.  This is not common in most networks, "root" is closely guarded behind lock and key and folks are given rights via radius/tacacs, etc.

2.  Requires dropping into the shell -- AS *ROOT*.  This is highly dangerous and bad juju all around on a production network.

I would be much more comfortable with a mechansim through "request" or "test" to simply down the interface.  It's such a very common thing to do, though there would have to be some kind of coordination with the configuration.  Much like your example of taking it down with ifconfig, if there was a "request interface xxx disable" kind of command, it would result in a down interface that should be "up" according to the committed config.  Some kind of warning or mandatory sync would have to be built in.

Hello,

---

@keithr wrote:

 

 

I would be much more comfortable with a mechansim through "request" or "test" to simply down the interface.  It's such a very common thing to do, though there would have to be some kind of coordination with the configuration.  Much like your example of taking it down with ifconfig, if there was a "request interface xxx disable" kind of command, it would result in a down interface that should be "up" according to the committed config.  Some kind of warning or mandatory sync would have to be built in.

 

 

---

Please contact Your nearest friendly Juniper SE for a chat and Enhancement Request writing/collaboration session 

Thanks

Alex

Is this something which could perhaps be done with an op script? Can you get to the shell and/or call a shell script from SLAX? One could have a shell script which was setuid root to do the dirty work.

To avoid problems with keeping in sync with the config - just have a command which bounces an interface (bonus points: check first, only bounce if it's not disabled/deactivated):

op bounce [interface] [seconds]

Where seconds is how long to let it be down before bringing it back up, maybe default to 1 second.

Hello,

---

@Mike.S wrote:

Is this something which could perhaps be done with an op script? Can you get to the shell and/or call a shell script from SLAX? 

---

Only carefully selected shell command calls (i.e. "sysctl <variable>"  which reads the variable, sysctl variable writing is disabled. Corresponding SLAX function call is jcs:sysctl() ) can be run from SLAX, this is a security measure.

"ifconfig" shell command call is definitely not supported in SLAX.

Perhaps You could join keithr to articulate Your case to Your Juniper SEs who would be able to help.

HTH

Thanks
Alex

Any similar method (to #2) to change the vlan a port belongs to without commit?

No way to change vlan of a port without commit, vlan is config based.

Regards,

c_r

Please Mark My Solution Accepted if it Helped, Kudos are Appreciated too