VLAN Numbering, and Priority Given by IOS ??

DAVE GENTON · ‎02-03-2009

I was forwarded this as gospel, but find it hard to swallow. There may be "some" truth to it, but technically different than this. Anyone know for sure ??

Cisco Voice VLANs...Why Spanning Tree is a Killer!

Ouch! Poor voice or video quality...dropped calls and sessions, etc....the enemies of Voice over IP, IP Telephony and other real-time applications in Cisco Multi-layer Switched Network Environments.

Did you know that the VLAN 'number' that you assign to the Voice VLAN and the number of VLANs that exist on the switch have everything to do with the speed by which PVST or Rapid-PVST will converge your network and allow traffic to flow after a failure occurs? Even in a fully redundant network, with all timers set properly, EIGRP operating perfectly, HSRP implemented with sub-second failover and Spanning Tree as optimized as it can possibly get, if your Voice VLAN numbers are higher than other VLANs on your switch, they will converge last....and you will feel the impact immediately. Even with 802.1w (Rapid Spanning Tree), Cisco implements a 100msec throttle delay on each VLAN when communicating information about VLAN loss to the routing process (EIGRP/OSPF). Therefore, if you have 10 VLANs on an access switch, upon failure of an uplink, fiber traffic on the tenth VLAN will converge 900msec after the first.....Ouch! 900msec of downtime on a VoIP network can be a catastrophe.

So how do we keep the convergence time from affecting our real-time applications? Simple. To ensure optimal convergence for voice or other real-time applications, VLAN number assignments should be mapped such that loss-sensitive applications, such as voice, are assigned the lowest VLAN numbers on the switch or physical interface. This will allow the Voice VLANs to be converged first, thus eliminating the effect of the throttle delay. Seems to be too simple, and yet it is, such a simple step to ensure the best possible quality of service for this type of traffic.

avillalva · ‎02-03-2009

Hi,

I lab-ed this scenario and I did not find any delay. (see attached timestamps) In this case I dropped vlan interfaces on the neighbor switch. As you can see, all adjacencies dropped at once.

Here are the logs.

Feb 4 03:56:22.604: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.114.1.1 (Vlan114) is down: interface down

Feb 4 03:56:22.604: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.115.1.1 (Vlan115) is down: interface down

Feb 4 03:56:22.604: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.116.1.1 (Vlan116) is down: interface down

Feb 4 03:56:22.613: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.117.1.1 (Vlan117) is down: interface down

Feb 4 03:56:22.613: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.118.1.1 (Vlan118) is down: interface down

Feb 4 03:56:22.613: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.119.1.1 (Vlan119) is down: interface down

Feb 4 03:56:22.613: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.120.1.1 (Vlan120) is down: interface down

Feb 4 03:56:22.613: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.121.1.1 (Vlan121) is down: interface down

Feb 4 03:56:22.621: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.122.1.1 (Vlan122) is down: interface down

Feb 4 03:56:22.621: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.123.1.1 (Vlan123) is down: interface down

Feb 4 03:56:22.621: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.124.1.1 (Vlan124) is down: interface down

Feb 4 03:56:22.621: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.125.1.1 (Vlan125) is down: interface down

Feb 4 03:56:22.629: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.126.1.1 (Vlan126) is down: interface down

HTH,

Andres

avillalva · ‎02-03-2009

I guess to be more precise it would be 0.025 ms per 13 VLANS according to my test.

Giuseppe Larosa · ‎02-04-2009

Hello Andres,

the original post was referring to PVST+ you should try to emulate an STP change in topology to see the effects.

if you shut a L3 SVI interface for vlan x, STP doesn't need to recalculate.

So you should shut a trunk port to root bridge carrying all the 25 vlans.

I liked your approach, testing is the right approach (when possible: available HW and time)

Hope to help

Giuseppe

DAVE GENTON · ‎02-04-2009

I was just reading the thread for first time since I posted, and you are correct, also I want to send the same sentiment, GREAT JOB ! now let's see (if possible) if the higher numbered vlans do actually recover with set delays over lowered number vlans.

dave

avillalva · ‎02-04-2009

Hi Dave,

Thanks, the VLANS recovered as they dropped, in a seemingly random order.

Note: I can't paste the full log because of message length restrictions in this forum...

Here are a few entries:

Feb 4 23:06:09.978: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.10.10.1 (Vlan10) is up: new adjacency

Feb 4 23:06:10.112: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.119.1.1 (Vlan119) is up: new adjacency

Feb 4 23:06:10.229: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.101.1.1 (Vlan101) is up: new adjacency

Feb 4 23:06:10.741: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.106.1.1 (Vlan106) is up: new adjacency

Feb 4 23:06:10.867: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.118.1.1 (Vlan118) is up: new adjacency

Feb 4 23:06:11.068: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.123.1.1 (Vlan123) is up: new adjacency

Feb 4 23:06:11.085: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.104.1.1 (Vlan104) is up: new adjacency

Feb 4 23:06:11.160: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.100.1.1 (Vlan100) is up: new adjacency

Feb 4 23:06:11.630: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.103.1.1 (Vlan103) is up: new adjacency

Feb 4 23:06:11.706: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.116.1.1 (Vlan116) is up: new adjacency

DAVE GENTON · ‎02-05-2009

Then the key indicator pertaining to the original post is that vlan 10 (lowest numbered) recovered first, while the others are indeed random, they are also very close in values so I dont know how that affects it, but spacing out might be the way to know, vlan1, vlan10, vlan 100, vlan 300 etc..

Thanks for the great lab work, one more question. Did vlan 10 recover first everytime you forced an STP topology change ??

dave

avillalva · ‎02-05-2009

There were no similarities in the order of recovery between tests.

HTH,

Andres

avillalva · ‎02-04-2009

Hi all,

Thanks for your feedback. I figured spanning tree was mentioned because that would be the most likely cause of losing comms in the real world (as opposed to losing a vlan).

Nevertheless, your point is taken and I have modified the lab to run PVST. I also ensured that an STP topology change occured by shutting down one of the trunks.

Here are the results:

Feb 4 23:05:48.511: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.106.1.1 (Vlan106) is down: holding time expired

Feb 4 23:05:48.880: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.118.1.1 (Vlan118) is down: holding time expired

Feb 4 23:05:49.124: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.104.1.1 (Vlan104) is down: holding time expired

Feb 4 23:05:49.199: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.121.1.1 (Vlan121) is down: holding time expired

Feb 4 23:05:49.426: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.123.1.1 (Vlan123) is down: holding time expired

Feb 4 23:05:49.434: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.101.1.1 (Vlan101) is down: holding time expired

Feb 4 23:05:49.442: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.103.1.1 (Vlan103) is down: holding time expired

Feb 4 23:05:49.468: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.100.1.1 (Vlan100) is down: holding time expired

Feb 4 23:05:49.736: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.114.1.1 (Vlan114) is down: holding time expired

Feb 4 23:05:49.962: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.122.1.1 (Vlan122) is down: holding time expired

Feb 4 23:05:50.080: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.120.1.1 (Vlan120) is down: holding time expired

Feb 4 23:05:50.197: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.111.1.1 (Vlan111) is down: holding time expired

Feb 4 23:05:50.281: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.105.1.1 (Vlan105) is down: holding time expired

Feb 4 23:05:50.332: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.108.1.1 (Vlan108) is down: holding time expired

Feb 4 23:05:50.709: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.125.1.1 (Vlan125) is down: holding time expired

Feb 4 23:05:50.843: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.116.1.1 (Vlan116) is down: holding time expired

Feb 4 23:05:51.036: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.112.1.1 (Vlan112) is down: holding time expired

Feb 4 23:05:51.053: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.115.1.1 (Vlan115) is down: holding time expired

Feb 4 23:05:51.514: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.113.1.1 (Vlan113) is down: holding time expired

Feb 4 23:05:51.581: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.117.1.1 (Vlan117) is down: holding time expired

HTH,

Andres

DAVE GENTON · ‎02-04-2009

Do you have the capture of the time it took spanning tree to recover ?? or at least if it's true that the lowerer numbered vlans come up first, in an ascedning order ?

avillalva · ‎02-04-2009

No, I didn't capture STP.

VLAN interfaces were not dropped in the second test, the uplink was dropped. All the EIGRP convergence times are pasted in the forum.

The neighbor adjacencies never dropped or came back up in order, nor in regular intervals.