VIRL topology - STP blocking loop on VLAN 1 only

[Anthony L]

Not sure if this is a quirk with VIRL or my limited understanding with STP.

My setup:

• Two trunk links exist between switches SW1 and SW2 and are not in an etherchannel
• VLANs 1, 10 and 20 are defined on both switches and active
• Both switches have default priority values for all VLANs. Due to SW1 having the lowest numerical base MAC address, it becomes the root bridge for all VLANs with all ports in each VLAN assuming the "Designated" port role and forwarding status (as expected)
• Running show spanning-tree on SW2 shows STP is blocking one of the two trunk link interfaces for VLAN 1 (Gi0/2) to prevent a loop - which I'd expect - however, not expected is that it is keeping both interfaces in the forwarding state for VLAN 10 and 20 - i.e. not prevent a loop on those VLANs

Please can someone help me understand why STP on SW2 is not blocking one of its two trunk links for VLAN 10 and VLAN 20 and if there is a way to make it block one?

I've uploaded the VIRL file. 

[trfinkenstadt]

@Anthony L,

What does SW1 show for the same commands? Are vlan10,20 blocked on it?  i have a vague recollection of running into the same thing only to see the port/vlans are blocked on sw1.

--tim

[Anthony L]

Hi Tim

Thanks for coming back to me. I've updated the post with spanning tree output from both switches to make it a bit clearer.

SW1 is the root bridge for all VLANs with all ports forwarding as expected.

My understanding is that SW2 should be blocking one of its trunk links for VLAN 10 and 20 to prevent a loop, which it currently isn't.

No issue with VLAN 1.

[Martin L]

Yes, I have seen this behavior in VIRL before. There are several issues posted in CCIE RS Study group in CLN. If you go there, search posts in that group about virl, you should see at least 3 recent (this year) posts regarding Virl layer 2 image.
I would not use VIRL to study switching; I would use it to do routing.

I think your "issue" is same as spotted by Steven in https://learningnetwork.cisco.com/thread/133540

https://learningnetwork.cisco.com/groups/ccie-routing-and-switching-study-group

there is also a VRIL group where u can posts Qs about VIRL and get responses from VIRL people.

[Martin L]

bad things in VIRL
https://learningnetwork.cisco.com/thread/131953
https://learningnetwork.cisco.com/thread/134086
https://learningnetwork.cisco.com/thread/132063
https://learningnetwork.cisco.com/thread/129270
https://learningnetwork.cisco.com/thread/128931
https://learningnetwork.cisco.com/thread/127157
https://learningnetwork.cisco.com/thread/126491

[Anthony L]

Hi Martin

Thanks for this - I'll take a look at those posts. What's the name of that VIRL study group to subscribe to please?

[trfinkenstadt]

Anthony,

Just curious:  Why not make the connection between SW1 and SW2 a port-channel/GEC?  Wouldn't this solve your issue and increase performance?

Anyway, i just through together a quick lan on 3745 with nm-16esw on 12.4.25b routers and got the following:

ESW1:

VLAN10

/snip
FastEthernet1/0 128.41 128 19 FWD 0 32768 c401.06f8.0001 128.41
FastEthernet1/1 128.42 128 19 FWD 0 32768 c401.06f8.0001 128.42

!

VLAN20

/snip

FastEthernet1/0 128.41 128 19 FWD 0 32768 c401.06f8.0002 128.41
FastEthernet1/1 128.42 128 19 FWD 0 32768 c401.06f8.0002 128.42

ESW2:

VLAN10

<snip>

FastEthernet1/0 128.41 128 19 FWD 0 32768 c401.06f8.0001 128.41

FastEthernet1/1 128.42 128 19 BLK 0 32768 c401.06f8.0001 128.42

VLAN20

<snip>

FastEthernet1/0 128.41 128 19 FWD 0 32768 c401.06f8.0002 128.41
FastEthernet1/1 128.42 128 19 BLK 0 32768 c401.06f8.0002 128.42

So, it looks like it works as expected in this environment.

My FastE's are configured:

interface FastEthernet1/X
description link to eswX
switchport mode trunk
duplex full
speed 100
end

Not sure if this helped or not.

--tim

[Anthony L]

Hi Tim

Thanks for coming back.

My intention is to deliberately have a mini loop - caused by the two trunk link not being in a port channel - and see that one of the two trunk ports gets blocked by STP in each vlan. The correct behaviour would be that it should do this (would in the real world) but isn’t doing so on these IOSvL2 switches.

[Anthony L]

Hi All

Just wondering if any one has been able to replicate the issue and if there's is a fix/workaround.