Bounce The Interface
Charise Farag
When I first heard this used I thought it meant shutting an interface down and then turning it on again, to clear a port-security violation and re-enable the port. But then I saw a training video which referred to shutting down the port and bouncing as if they were two different things. I found a lot of references to the term "bounce" in electronics as well, but not sure if that's where the term comes from.
Bounce - usually used for IT devices, interfaces, or protocols. Saying "bounce the interface" would typically mean to shut it down and then bring it back up again. In reference to routers, switches, firewalls... etc... it would be typically to bring the device down and then bring it back up again. I have even used it in reference to protocols like BGP where what I mean is I'm going to issue something like "clear ip bgp *" which will bring the BGP session down and then BGP will, by itself, bring the peer back up.
I was reading on Cisco Clean Access Server guide and came across the phrase "bounce the switch port after vlan is changed." Is it talking about doing shut down and no shut down to force the client to update necessary changes?
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.
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.
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.
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.
Only carefully selected shell command calls (i.e. "sysctl " 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.
Hi, I am currently testing 802.1x authentication. I have done the setup on an EX2300C running Junos 15.1X53-D56. Everything look to work as expected. Our radius server, freeradius, return proper vlan information and then the port is move to the right vlan. However I am having an issues where once the user logged in, if his assigned vlan different than the default assiged one to the PC, the system doesn't renew is IP address. I guess that when vlan change the port should be automatically bounce in order to force client to renew their IP address. Am I doing something wrong ? Here the configuration I use...
I am currently trying to do something similar. I think you need a new feature to be supported in Junos called 'port-bounce'. This is where the RADIUS server sends a COA (Change of Authorization) message to the switch that changes the VLAN and also bounces the port to force a new DHCP request.
Apparently no config is required on the switch, but the feature was only implemented in 17.3 on an EX4300 (what I am using - not sure about your switch). So you may want to look at Pathfinder.juniper.net to see if you need new Junos. Here is some info:
The other thing you need is for the Port-Bounce RADIUS VSA to be sent by the RADIUS server. Our server does not have this in the juniper.dct file, so it is unable to send it. Unfortunately I have also been unable to find a new juniper.dct dictionary anywhere.
Even though the CoA port bounce feature is there in 18.1R1 it's not officially tested for EX2300/EX3400 yet. With that said, I tried CoA session terminate and port bounce from Cisco ISE 2.3.0 with EX2300-C-12P running 18.1R1 and it works, so you can test it in your lab environment.
I change a litle bit this script: toggle-interface.slax to have the possibility to desactivate the Interface (xe-3/0/0) and not the unit of this interface. This script is trigger by a shutdown detection of another interface and it works well.
I am very new to the PANOS world so I will apologize in advance if this is obvious, however my search of documentation and knowledebase did not yield anything. I have been looking for a way to administratively shut down sub interfaces. Is this possible? While it's easy enough to shutdown a physical interface by assigning it's link-state we're not seeing a way to do the same for an individual sub-interface.
We do not have an option of shutting down a sub interface as its logical in nature. We could however, select "none" zone for the sub-interface or "none" virtual router or both, if you do not want traffic to ingress/egress via this sub interface.
It's a very useful feature when you are replacing existing equipment for example. The ability to disable a subinteterface would allow you to assign and commit an ip address that would potentially conflict with an existing piece of equipment. When you're ready to cut over you can just disable the interfaces on the old equipment and enable them on the PA firewall. This is why there's a concept of administrative shutdown in the cisco world for example.
You have a valid point, but we do not have that feature as of today on the box. You can contact your Sales Engineer for this enhancement request and he can apply one for you on your behalf. Till then you have to work around it with the steps that I mentioned before.
I'm facing the same situation right now. I want to replace the old FWs with the new Palo Alto FWs. So, I need to disable an exiting sub-interface on the old FWs and enable it on the new FWs. Select "none" for the sub-interface zone or "none" for the virtual router, or both it will take time for me. So, shutdown sub interfaces would make it easy.
Same here - I was going to hot-cut a 3-tier infrastructure into one cluster but I just got told yesterday I need to do it one tier at a time. I guess the zone workaround is about the same amount of but I don't feel comfortable with the zone option. I guess I'm old school, lol.
Edit: What about duplicate IP addresses? Does the zone workaround completely take it out of routing & ARP'ing? Since I'm moving multiple VLANs' gateways from one firewall to another there's the potential for IP address conflicts.
Is there anyway via GUI or CLI to shutdown a port on the Palo? There are times when I would like to do some configuration, such as sub-interfaces and so on to an aggregate group that is plugged into the core switches. At times this can cause an issue so I would like to be able to shut the ports down on my end, but still do the configuration.
"Only one command" because that is the only interface where my ssh is working on also. So if i'm about to use: ifdown and then ifup, i will never be able to hit the ifup command as my ssh has been terminated once after ifdown eth1 command.
So there should be a single command which allows me to altogether bring down and then bring up the interface which is serving my current ssh connection. So i do not need to worry about connection totally lost to my server.
If you're worried about using it on a production server that you don't have another method of access to, that's understandable. Though the command does exactly what you want, it's very easy to have a configuration error that is only noticed after running this command. If you don't have an alternate method of access (for example, out-of-band console, or SSHD running on another interface), it's safest not to do this.
A cool method is by using the screen utility to create a session by just typing 'screen'. Once you restart the network service and your SSH connection drops, use screen -ls to check that the session is still active (but detached) and screen -r to resume the detached session. This will work in case there is no error in your interface configuration file, i.e. the network service is restarted successfully.
And proceed with editing your interface configuration file and restarting the network service. In case of a mistake, you just have to wait 10 minutes, in order for the previous configuration to be reapplied and the network service to be restarted.
all answers talking about ifup & ifdown are not according to the question. ifup & ifdown just bring the interface up and down only, it doesn't effect the network service. for linux network service doesn't mean interfaces ip setup only.