The premiere source of truth powering network automation. Open and extensible, trusted by thousands.
NetBox is now available as a managed cloud solution! Stop worrying about your tooling and get back to building networks.
SVI autostate
By stretch | Monday, November 9, 2009 at 4:21 a.m. UTC
Cisco IOS SVIs, also called VLAN interfaces, exhibit what might be considered an odd behavior: by default, an SVI will show an interface state of up but a line protocol state of down. Consider the following minimal configuration:
Switch(config)# vlan 10 Switch(config-vlan)# interface vlan10 Switch(config-if)# ip address 192.168.10.1 255.255.255.0 Switch(config-if)# ^Z Switch# show ip interface brief Interface IP-Address OK? Method Status Protocol Vlan1 unassigned YES unset administratively down down Vlan10 192.168.10.1 YES manual up down FastEthernet0/1 unassigned YES unset down down FastEthernet0/2 unassigned YES unset down down ...
This is because an SVI must meet all of the following conditions to transition to the full "up/up" state:
- Its VLAN must exist and be active in the VLAN database.
- At least one switched port in the VLAN (access or trunk) must be up.
- That port must be in the STP forwarding state.
Typically, a newly created VLAN will not yet have been assigned to any ports. Once it is, and provided at least one of those ports is operational, we see the SVI line protocol transition to the up state:
Switch(config)# interface f0/3 Switch(config-if)# switchport access vlan 10 Switch(config-if)# LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan10, changed state to up
Cisco refers to this behavior as autostate. While usually very handy, this behavior might not always be desirable. For example, an engineer might wish for an SVI to always remain up so that a can be reached via its associated IP address even if all ports associated with that VLAN are down (or if the VLAN itself has gone missing).
On some platforms (routers running 12.4T at least, possibly others), Cisco includes the ability to disable the autostate feature with the command no autostate under SVI configuration. Sadly, this command seems only to be available on routers and not Catalyst switches, where one assumes it would be most useful.
Posted in Switching
Comments
November 9, 2009 at 6:22 a.m. UTC
A bit more information on autostate:
http://blog.ioshints.info/2009/07/followup-vlan-interface-status.html
Things can get tricky when you have trunking ports; you can also explicitly remove an interface from autostate computation.
November 9, 2009 at 9:04 a.m. UTC
THNX 4 pointing this out...I am also wondering why the Catalyst switches don't know "no autostate"!
November 9, 2009 at 10:41 a.m. UTC
Cool, didn't know about the "port must be in the STP forwarding state" part of the requirement. Thanks Stretch =]
November 9, 2009 at 11:44 a.m. UTC
Hmm, it's nice to know this, but I wonder why someone would want an SVI to stay up, although none of it's members are awake.
If it's for remote reachability or having a static ID-like IP address for the router, loopback interfaces are always there handy.
Right?
November 9, 2009 at 1:33 p.m. UTC
Autostate is commonly used by those platforms, such as the Catalyst C6500, that have Modules such as the ACE, FWSM, IDS, Guard/Detector and so on. When these Modules are installed, you can have VLANs that have no physical interfaces used since they only exist between, for example, the FWSM Firewall instance and the ACE load balancing instance.
Because this use case will never have a physical interface in a given VLAN, and the VLAN must be up so that the logical SVI is presented to the Module. Therefore I would draw the conclusion that the feature is only supported on those platforms that have these modules.
These types of Modules are only supported in IOS and not CatOS, probably due to how the backplane is handled in software. So my thinking, is that's why the feature exists in certain hardware only.
November 15, 2009 at 3:48 p.m. UTC
It is also possible to use the 'suspend vlan' feature if required?
Conf t
vlan 123 state suspend
November 16, 2009 at 11:36 p.m. UTC
On Catalyst switches, you can enter into vlan configuration, by "vlan x" and issue the "state active" command, and your Vlan interface will be up/up.
December 14, 2009 at 4:39 p.m. UTC
I have to say that the as a best practice, the reachability of a device should always be to a loopback and not it's physical interfaces. Obviously in certain topologies it's not a big deal, but often with redundant routes monitoring a device using a physical port or an SVI can slow down troubleshooting efforts.
October 9, 2011 at 10:45 p.m. UTC
Excellent
December 22, 2013 at 11:58 p.m. UTC
We have got another way where we can actullay disable any interace which is definded under a VLAN but does not play any role in defining the status of the SVI. We can use "switchport auto-state exclude" under the interface config mode of any physical interface and then assign it to any VLAN and now this particular interface will not play any role in defining the state of SVI.
February 12, 2014 at 9:10 p.m. UTC
Thanks for this.
May 5, 2015 at 10:54 a.m. UTC
I am not sure why this command is perceived as it is. Using the 'switchport autostate excluded' command will not keep your SVI up and running. If I only had f0/1 in Vlan-10. F0/1 is status and protocol is up, the protocol of the SVI for Vlan-10 goes up. The second I put the autostate excluded command on f0/1, then protocol for interface Vlan-10 will go down, and that connected interface will be removed from the routing table.
The autostate excluded command states this: The interface will not play a factor in determining if the SVI's protocol status will be up or down. Which means, if the interface goes up, it will not bring up the SVI. There is no way for the interface to effect if the SVI goes down, this is why.....
The interface does not effect the SVI at all, so if that is the case, when the interface comes up, nothing happens. That means if this interface is up, the only way for the SVI's protocol to be up is to have another port that is up in that Vlan and does not have the autostate exlcuded command on it.
So this command eliminates a port from effecting the SVI at all. So this command does not allow you to have an SVI up when there are no ports active in that VLAN. If there is multiple ports up in that Vlan, then the SVI's protocol status will remain up until the last port (that does NOT have the autostate command on it) goes down.
Where could I use this? Lets say I have port that is up, in a vlan, and is going to a device that will not be communicating on that vlan (like a monitoring source port). If that port is the only one up, then my interface VLAN protocol is up. Well, I don't want my SVI to be up if this is the last port that is active. Now the SVI is in my routing table, and drawing traffic towards me, and that is not want I want since there are no real communicating interfaces in that Vlan
July 21, 2016 at 12:29 a.m. UTC
It seems Catalyst IOS default to "no autosense" on SVI interface, but Nexus NX-OS default to "autosense".
Working on a pair of Nexus9000 switches, with two 10G trunk links for form a port-channel 1, all the VLAN interfaces are all in down/link-down state.
# sh int vlan23 Vlan23 is down (VLAN/BD is down), line protocol is down, autostate enabled Vlan123 10.19.103.2 protocol-down/link-down/admin-up Vlan124 10.19.104.2 protocol-down/link-down/admin-up Vlan125 10.19.112.2 protocol-down/link-down/admin-up
Put "no autosense" command under the VLAN interface bring up the interface:
interface Vlan22 description xxxxxxxxxxxx no shutdown no autostate cv-core-sw01-new# sh int vlan 22 Vlan22 is up, line protocol is up, autostate disabled