Force VLAN up?

Started by netspork, August 10, 2017, 07:26:42 PM

Previous topic - Next topic

netspork

Hi all, this is a really common question, but I'm having trouble narrowing down an answer that addresses my use case.

I know the rule for a VLAN interface to come "up/up" is that there must be at least one access with that VLAN configured on it and that port must be up. The "autostate" stuff for VLANs will then mark the VLAN up.  Makes sense, I get it.

What about a scenario where the only place I need that VLAN is a trunk port?  In that case (at least on 3750 and similar), the port only comes up if you jiggle things around ("state active" in the vlan config, "shut/no shut" in the vlan interface config), and that's probably not going to survive a reload.

Shorthand example:

int gig 1/0/2
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 101,102
switchport mode trunk

int vlan 101
ip address 10.10.10.1 255.255.255.0


In that scenario, "vlan 101" will remain down/down, and that's how it's supposed to work.

In my use-case, I have no need to have vlan 101 on a port that's in access mode.  gig 1/0/2 above goes to a dumb layer 2 switch that puts vlan 101 on a few access ports. 

How can I make vlan 101 stay up/up no matter what?

I've seen some interesting/dumb hacks, like forcing a port up by disabling keepalives and then throwing the vlan over there, but that's just terrible and I won't do it.

Dieselboy

Hi OP :)

The command you might need is:
interface vlan x
no autostate


This keeps the SVI up. I've used this on my 877W but I can't remember exactly what the use case was. I've checked this command and it's not there on 2960 switches I have here but IS there on my Nexus switches:

CIN-3048-1(config)# vlan 999
CIN-3048-1(config-vlan)# name test
CIN-3048-1(config-vlan)# int vl 999
CIN-3048-1(config-if)# ip add 192.168.99.254/24
CIN-3048-1(config-if)# no shut
CIN-3048-1(config-if)# exi
CIN-3048-1(config)# do sh int vl 999
Vlan999 is down (VLAN is down), line protocol is down, autostate enabled
  Hardware is EtherSVI, address is  6c41.6a33.cb3c
  Internet Address is 192.168.99.254/24
  MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec
  Last clearing of "show interface" counters never

CIN-3048-1(config)# int vl 999
CIN-3048-1(config-if)# no autostate
CIN-3048-1(config-if)# do sh int vl 999
Vlan999 is up, line protocol is up, autostate disabled
  Hardware is EtherSVI, address is  6c41.6a33.cb3c
  Internet Address is 192.168.99.254/24
  MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec
  Last clearing of "show interface" counters never


So you can see that without any ports in the VLAN at all, the SVI is up. This is working similarly to a loopback right now, where a loopback is up and there's no physical ports obviously in a loopback.

Interesting, are you running a management VLAN hence why you need the SVI up without any ports in there? Can't think of an easy solution for a 2960 at the moment without "fudging" something together.

netspork

Should have mentioned, 3750 doesn't have the "autostate" command.

Dieselboy

yea I think the 2960 shares the code.

Can you share your use case? Might help me provide you with useful info rather than "you can do this or that..." :)

Two things I've thought of if this is for a management VLAN:
1. use a loopback IP, but it may not work for you

2. use a tiny cat6 cable and link 2 ports together on the switch -> =fudge and not a good idea in production unless you plan it accordingly.

We used QinQ for our customers networks in London and the customer equipment was in a shared comms room. To do the QinQ decapsulation we needed a short cat6 crossover cable and linked 2 ports together on the same switch. This removed the outer VLAN and brought the traffic into its respective normal 802.1Q VLANs. This customers network went down at least twice and I was rushed to site to take a look. Someone kept unplugging the looped cable. I can only think that they were working in the comms room on their own customers network and noticed this cable on our switch and thought it was wrong, seeing flashing link lights on both sides of the link into the same switch. Was very annoying because it was completely normal and completely designed, and they shouldn't have been touching our equipment anyway.

srg

#4
There's no need for an access interface to be up, a trunk works as well. The initial configuration should work, given that the VLAN exists.

https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3560/software/release/12-2_52_se/configuration/guide/3560scg/swint.html#wp2040589
QuoteSVI Autostate Exclude
The line state of an SVI with multiple ports on a VLAN is in the up state when it meets these conditions:

•The VLAN exists and is active in the VLAN database on the switch.

•The VLAN interface exists and is not administratively down.

•At least one Layer 2 (access or trunk) port exists, has a link in the up state on this VLAN, and is in the spanning-tree forwarding state on the VLAN.
som om sinnet hade svartnat för evigt.

netspork

Quote from: srg on August 11, 2017, 12:33:07 AM
There's no need for an access interface to be up, a trunk works as well. The initial configuration should work, given that the VLAN exists.

https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3560/software/release/12-2_52_se/configuration/guide/3560scg/swint.html#wp2040589
QuoteSVI Autostate Exclude
The line state of an SVI with multiple ports on a VLAN is in the up state when it meets these conditions:

•The VLAN exists and is active in the VLAN database on the switch.

•The VLAN interface exists and is not administratively down.

•At least one Layer 2 (access or trunk) port exists, has a link in the up state on this VLAN, and is in the spanning-tree forwarding state on the VLAN.

Pretty sure I have the last (port that's up, VLAN as an allowed member of the trunk), but was only able to get the VLAN up with a weird sequence of "shut/no shut" and "status active" commands.  Perhaps the STP part?  The other side of the trunk is a ubiquiti wireless AP in bridge mode, and one of the clients of that AP has a Netonix switch hanging off of it where these VLANs are all de-encapsulated and presented on various access ports on that switch.  This all works from end to end - just had this issue today when swapping the 3750 in for a 3550.

As requested, the use case here is to have this switch handle layer 3 stuff and have another switch that's only got layer 2 capabilities present these vlans untagged to various customers.

--- 3750 ---- trunk port ----  AP ---  wireless --- CPE --- trunk port ---- Netonix switch ---- customer per port

So vlan 101 ends up on a port of the netonix, vlan 102 on another port, etc.  The netonix has no layer 3 capabilities, so that's why I'm having the 3750 handle that...  Does that make sense?

srg

Quote from: netspork on August 11, 2017, 01:40:02 AM
Quote from: srg on August 11, 2017, 12:33:07 AM
There's no need for an access interface to be up, a trunk works as well. The initial configuration should work, given that the VLAN exists.

https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3560/software/release/12-2_52_se/configuration/guide/3560scg/swint.html#wp2040589
QuoteSVI Autostate Exclude
The line state of an SVI with multiple ports on a VLAN is in the up state when it meets these conditions:

•The VLAN exists and is active in the VLAN database on the switch.

•The VLAN interface exists and is not administratively down.

•At least one Layer 2 (access or trunk) port exists, has a link in the up state on this VLAN, and is in the spanning-tree forwarding state on the VLAN.

Pretty sure I have the last (port that's up, VLAN as an allowed member of the trunk), but was only able to get the VLAN up with a weird sequence of "shut/no shut" and "status active" commands.  Perhaps the STP part?  The other side of the trunk is a ubiquiti wireless AP in bridge mode, and one of the clients of that AP has a Netonix switch hanging off of it where these VLANs are all de-encapsulated and presented on various access ports on that switch.  This all works from end to end - just had this issue today when swapping the 3750 in for a 3550.

As requested, the use case here is to have this switch handle layer 3 stuff and have another switch that's only got layer 2 capabilities present these vlans untagged to various customers.

--- 3750 ---- trunk port ----  AP ---  wireless --- CPE --- trunk port ---- Netonix switch ---- customer per port

So vlan 101 ends up on a port of the netonix, vlan 102 on another port, etc.  The netonix has no layer 3 capabilities, so that's why I'm having the 3750 handle that...  Does that make sense?
Sure, not that unsual scenario. I've had loads of 3750s just doing routing with only trunks. STP might've been a culprit, if you're not using rapid-pvst/MST or some fallback then it could take a while for the port to be forwarding.
som om sinnet hade svartnat för evigt.

Dieselboy

I must apologise, I was wrong further up. I forgot about VPC and because I done this as a quick test I didn't bother to configure the other switch in the vpc. There was no spanning tree instance either.
I done another test, and put the test VLAN onto a regular trunk port and the SVI does come up:

CIN-3048-1(config-if)# do sh int vl 999
Vlan999 is up, line protocol is up, autostate enabled
  Hardware is EtherSVI, address is  6c41.6a33.cb3c
  Internet Address is 192.168.99.254/24
  MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec
  Last clearing of "show interface" counters never

CIN-3048-1(config-if)# show vlan
999  test                             active    Eth1/45


:wall:

LynK

Not trying to be the devils advocate here, but what is the purpose of an SVI with no interfaces attached? Sounds to me like a job for a loopback interface.
Sys Admin: "You have a stuck route"
            Me: "You have an incorrect Default Gateway"

srg

Quote from: LynK on August 14, 2017, 08:48:43 AM
Not trying to be the devils advocate here, but what is the purpose of an SVI with no interfaces attached? Sounds to me like a job for a loopback interface.
Not 'no interfaces attached', but 'only trunks'.
som om sinnet hade svartnat för evigt.

netspork

I just added another VLAN and I'm seeing this again.  VLAN interface created, added to a trunk port, VLAN is up/down.  In the 5 minutes or so it took me to write that, get distracted, and come back here, it flipped to up/up.  This is the first time I saw this happen without me fiddling around in the switch to try to get it to up/up.  So some kind of timer must hit (I'm guessing something spanning tree related).  Just another datapoint for anyone finding this thread.


icecream-guy

There needs to be a minimum of 1 switch port active in a VLAN for the SVI to go up/up. does that help ?
:professorcat:

My Moral Fibers have been cut.