• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 990
  • Last Modified:

Spanning tree not detecting loop?

Background:

I have two office locations, each with a Cisco 3560G switch.  It is desireable to have both sites within the same LAN segment (well technically there are a few VLANs, but that is beside the point for now).  The locations two switches were initially connected to one another via fiber, using an ethernet to fiber media converter on each end, which formed a transparent L2 bridge between the switches.  Everything has been working well for quite some time as if the switches were plugged into one another with a single piece of UTP cable.

Because of the necessity of this link to remain available, an alternate link between the two sites was obtained in the form of a T1 circuit -- it is a point to point private line, nothing from the telcos in the way.  What I have done with this is connect it to a T1 interface card in a Cisco 28xx series router on each end, and set them both up to bridge the Serial interface to an Ethernet interface.  This has essentially given me another transparent L2 bridge, which works just like the fiber link (with less bandwidth of course).

The plan now is to connect the two 3560's together, and have the link via T1 remain in a blocked state, using spanning tree to manage the "failover" as necessary if the fiber link were to go down.  However, when I connect both links, I get a loop in the network and a resulting broadcast storm until one is disconnected (or at least shutting down an interface on one end).

I was under the impression that as long as the BPDUs go through (which they do) the switches should be able to properly negotiate via STP which port(s) to block & which to forward regardless of the up/down state of the interface.


Relevant configuration information:

Building A
----------
spanning-tree mode pvst
spanning-tree extend system-id
spanning-tree vlan 1-3,37,100 priority 24576
!
interface GigabitEthernet0/18
 description Link to B via T1
 switchport trunk encapsulation dot1q
 switchport trunk allowed vlan 1-3,100
 switchport mode trunk
!
interface GigabitEthernet0/24
 description Link to B via fiber
 switchport trunk encapsulation dot1q
 switchport trunk allowed vlan 1-3,37,100
 switchport mode trunk
 spanning-tree port-priority 64

Building B
----------
spanning-tree mode pvst
spanning-tree extend system-id
spanning-tree vlan 1-3,37,100 priority 28672
!
interface GigabitEthernet0/6
 description Link to A via fiber
 switchport trunk encapsulation dot1q
 switchport trunk allowed vlan 1-3,37,100
 switchport mode trunk
 spanning-tree port-priority 64
!
interface GigabitEthernet0/7
 description Link to A via T1
 switchport trunk encapsulation dot1q
 switchport trunk allowed vlan 1-3,100
 switchport mode trunk


Official Questions:

Is there any reason that the redundant links between switches have to all be direct physical connections (as in a single piece of cable)?

Is there some additional STP configuration that has to be used because of the fact that the switch interface does not go "down" when a fiber cut occurs?

Is the problem that I'm using PVST (which allegedly only works with ISL) instead of PVST+ (which does work with 802.1Q, but doesn't seem to be an option on the 3560)?

Is there something else that I'm missing here?


P.S. Yes, I intentionally left VLAN 37 out of the T1 link because that would be carrying SAN volume replication traffic, which I do not need bogging down the T1 during a failover scenario.  The replication will be queued up while the primary link is restored, this is fine.
0
drcheap
Asked:
drcheap
  • 6
  • 4
3 Solutions
 
Don JohnstonInstructorCommented:
I'm only speculating since I've never tried to bridge a multi-VLAN environment over a serial link before, but I think your problem is bridging the trunk. I suspect that the router isn't doing PVST. As such the BPDU's are making it across the link.
0
 
drcheapAuthor Commented:
Going with that I double checked my settings on the routers.  Somehow one of them did have an out of place configuration line on both interfaces in the bridge:
     bridge-group 1 spanning-disabled

That might be why BPDUs weren't going through okay.  Not sure how it got there either as I set them up identically in the first place, and would have no reason to use such a command.  Odd indeed.

So after removing that offending line, I tried once again to bring up the alternate interfaces on the 3560s and they seemed to behave a little closer to what I expected, but not quite 100% ...

After a bit of STP listening/learning/etc. things finally settled with the root switch (Building A as expected) indicating FWD for all VLANs, and the other one showing the following:

BuildingB#s sp int gi0/7

Vlan             Role Sts Cost      Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
VLAN0001         Desg FWD 19        128.7    P2p
VLAN0002         Altn BLK 19        128.7    P2p
VLAN0003         Altn BLK 19        128.7    P2p
VLAN0100         Altn BLK 19        128.7    P2p


So it was blocking for all but VLAN1 for some reason...and naturally there was a broadcast storm on that subnet.  So I'm a little closer here, but not quite there yet.
0
 
predragpetrovicCommented:
Hi,

You should try by doing this on all ports which you use for interconnection:

spanning-tree portfast trunk

This solved my issues with Nortel interconnectivity.
0
Become a Leader in Data Analytics

Gain the power to turn raw data into better business decisions and outcomes in your industry. Transform your career future by earning your MS in Data Analytics. WGU’s MSDA program curriculum features IT certifications from Oracle and SAS.  

 
drcheapAuthor Commented:
I did try the 'spanning-tree portfast trunk' option, but that behaved as expeted...it just instantly put the port into FWD for all VLANs, creating not just one loop, but a loop on each VLAN -- even worse.

Again, the problem is still that the STP figures out that it needs to block on all but VLAN 1.
I figured that might have something to do with VLAN 1 being the native VLAN for the trunk.  So I created a new dummy VLAN 99 and set that as the native VLAN for the trunk ports on each end of the T1 link.  This had no effect on the BLK vs. FWD state of VLAN 1 when bringing the alternate link online.

In other testing scenarios, there is something else going on that might be the root cause of this issue.  I think there is something affecting communication on VLAN 1 over this T1 link.  Why that particular VLAN and not others I have no idea, it's just set up as a transparent bridge anyway!

But here's the symptom...I bring the T1 online, and force the fiber offline.  Now there is still only a single trunk between switches.  The ports are correctly in FWD state for that link, and traffic passes okay for all VLANs except VLAN 1.  The really odd part is that *SOME* traffic passes okay for VLAN 1 where as the rest doesn't.  Meaning that I can reach some hosts on opposite sides of the link (all within VLAN 1) can communicate and others can't.

Any ideas on what would cause that last symptom?  I think figuring that out might solve the original problem, or at least make it a lot easier to solve.
0
 
drcheapAuthor Commented:
Bringing this one back to life...I found a few new debug commands relating to STP, and figured I'd share the output.  The problem appears to be on the Building B side switch as it is not sending topology change notices for VLAN 1 when I bring up Gi/0/18 on Building A.  So for some reason it doesn't seem to think anything has changed for that VLAN, which explains why it leaves the port in FWD state for only that one while BLKing the others.

Building A:

26w2d: %LINK-3-UPDOWN: Interface GigabitEthernet0/18, changed state to up
26w2d:     pm_vp 1/18(1): during state not_present, got event 3(trunk_add)
26w2d: @@@ pm_vp 1/18(1): not_present -> present
26w2d:     pm_vp 1/18(1): during state present, got event 11(trunk_linkup)
26w2d: @@@ pm_vp 1/18(1): present -> authentication
26w2d:     pm_vp 1/18(1): idle during state authentication
26w2d: @@@ pm_vp 1/18(1): authentication -> authentication
26w2d:     pm_vp 1/18(1): during state authentication, got event 18(authen_disable)
26w2d: @@@ pm_vp 1/18(1): authentication -> notforwarding
26w2d:     pm_vp 1/18(2): during state not_present, got event 3(trunk_add)
26w2d: @@@ pm_vp 1/18(2): not_present -> present
26w2d:     pm_vp 1/18(2): during state present, got event 11(trunk_linkup)
26w2d: @@@ pm_vp 1/18(2): present -> authentication
26w2d:     pm_vp 1/18(2): idle during state authentication
26w2d: @@@ pm_vp 1/18(2): authentication -> authentication
26w2d:     pm_vp 1/18(2): during state authentication, got event 18(authen_disable)
26w2d: @@@ pm_vp 1/18(2): authentication -> notforwarding
26w2d:     pm_vp 1/18(3): during state not_present, got event 3(trunk_add)
26w2d: @@@ pm_vp 1/18(3): not_present -> present
26w2d:     pm_vp 1/18(3): during state present, got event 11(trunk_linkup)
26w2d: @@@ pm_vp 1/18(3): present -> authentication
26w2d:     pm_vp 1/18(3): idle during state authentication
26w2d: @@@ pm_vp 1/18(3): authentication -> authentication
26w2d:     pm_vp 1/18(3): during state authentication, got event 18(authen_disable)
26w2d: @@@ pm_vp 1/18(3): authentication -> notforwarding
26w2d:     pm_vp 1/18(9): during state not_present, got event 3(trunk_add)
26w2d: @@@ pm_vp 1/18(9): not_present -> present
26w2d:     pm_vp 1/18(9): during state present, got event 11(trunk_linkup)
26w2d: @@@ pm_vp 1/18(9): present -> authentication
26w2d:     pm_vp 1/18(9): idle during state authentication
26w2d: @@@ pm_vp 1/18(9): authentication -> authentication
26w2d:     pm_vp 1/18(9): during state authentication, got event 18(authen_disable)
26w2d: @@@ pm_vp 1/18(9): authentication -> notforwarding
26w2d:     pm_vp 1/18(100): during state not_present, got event 3(trunk_add)
26w2d: @@@ pm_vp 1/18(100): not_present -> present
26w2d:     pm_vp 1/18(100): during state present, got event 11(trunk_linkup)
26w2d: @@@ pm_vp 1/18(100): present -> authentication
26w2d:     pm_vp 1/18(100): idle during state authentication
26w2d: @@@ pm_vp 1/18(100): authentication -> authentication
26w2d:     pm_vp 1/18(100): during state authentication, got event 18(authen_disable)
26w2d: @@@ pm_vp 1/18(100): authentication -> notforwarding
26w2d: *** vp_statechange: trunk: added: 1/18(1) 1/18(2) 1/18(3) 1/18(9) 1/18(100)
26w2d: set portid: VLAN0001 Gi0/18: new port id 8012
26w2d: STP SW: Gi0/18 new blocking req for 1 vlans
26w2d: STP: VLAN0001 Gi0/18 -> listening
26w2d: set portid: VLAN0002 Gi0/18: new port id 8012
26w2d: STP: VLAN0002 Gi0/18 -> listening
26w2d: set portid: VLAN0003 Gi0/18: new port id 8012
26w2d: STP: VLAN0003 Gi0/18 -> listening
26w2d: set portid: VLAN0009 Gi0/18: new port id 8012
26w2d: STP: VLAN0009 Gi0/18 -> listening
26w2d: set portid: VLAN0100 Gi0/18: new port id 8012
26w2d: STP: VLAN0100 Gi0/18 -> listening
26w2d: *** vp_linkchange: trunk: up: 1/18(1) 1/18(2) 1/18(3) 1/18(9) 1/18(100)
26w2d: STP: VLAN0002 Topology Change rcvd on Gi0/24
26w2d: STP: VLAN0003 Topology Change rcvd on Gi0/24
26w2d: STP: VLAN0100 Topology Change rcvd on Gi0/24
26w2d: STP: VLAN0009 Topology Change rcvd on Gi0/24
26w2d: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/18, changed state to up
26w2d: STP SW: Gi0/18 new learning req for 1 vlans
26w2d: STP: VLAN0001 Gi0/18 -> learning
26w2d: STP: VLAN0002 Gi0/18 -> learning
26w2d: STP: VLAN0003 Gi0/18 -> learning
26w2d: STP: VLAN0009 Gi0/18 -> learning
26w2d: STP: VLAN0100 Gi0/18 -> learning
26w2d: STP SW: Gi0/18 new forwarding req for 1 vlans
26w2d: STP: VLAN0001 Gi0/18 -> forwarding
26w2d: STP: VLAN0002 Gi0/18 -> forwarding
26w2d: STP: VLAN0003 Gi0/18 -> forwarding
26w2d: STP: VLAN0009 Gi0/18 -> forwarding
26w2d: STP: VLAN0100 Gi0/18 -> forwarding
26w2d:     pm_vp 1/18(1): during state notforwarding, got event 14(forward_notnotify)
26w2d: @@@ pm_vp 1/18(1): notforwarding -> forwarding
26w2d:     pm_vp 1/18(2): during state notforwarding, got event 14(forward_notnotify)
26w2d: @@@ pm_vp 1/18(2): notforwarding -> forwarding
26w2d:     pm_vp 1/18(3): during state notforwarding, got event 14(forward_notnotify)
26w2d: @@@ pm_vp 1/18(3): notforwarding -> forwarding
26w2d:     pm_vp 1/18(9): during state notforwarding, got event 14(forward_notnotify)
26w2d: @@@ pm_vp 1/18(9): notforwarding -> forwarding
26w2d:     pm_vp 1/18(100): during state notforwarding, got event 14(forward_notnotify)
26w2d: @@@ pm_vp 1/18(100): notforwarding -> forwarding
26w2d: *** vp_list_fwdchange: forward: 1/18(1)
26w2d: *** vp_list_fwdchange: forward: 1/18(2)
26w2d: *** vp_list_fwdchange: forward: 1/18(3)
26w2d: *** vp_list_fwdchange: forward: 1/18(9)
26w2d: *** vp_list_fwdchange: forward: 1/18(100)
26w2d:     pm_vp 1/18(1): during state forwarding, got event 7(trunk_remove)
26w2d: @@@ pm_vp 1/18(1): forwarding -> notforwarding
26w2d: @@@ pm_vp 1/18(1): notforwarding -> present
26w2d: @@@ pm_vp 1/18(1): present -> not_present
26w2d:     pm_vp 1/18(2): during state forwarding, got event 7(trunk_remove)
26w2d: @@@ pm_vp 1/18(2): forwarding -> notforwarding
26w2d: @@@ pm_vp 1/18(2): notforwarding -> present
26w2d: @@@ pm_vp 1/18(2): present -> not_present
26w2d:     pm_vp 1/18(3): during state forwarding, got event 7(trunk_remove)
26w2d: @@@ pm_vp 1/18(3): forwarding -> notforwarding
26w2d: @@@ pm_vp 1/18(3): notforwarding -> present
26w2d: @@@ pm_vp 1/18(3): present -> not_present
26w2d:     pm_vp 1/18(9): during state forwarding, got event 7(trunk_remove)
26w2d: @@@ pm_vp 1/18(9): forwarding -> notforwarding
26w2d: @@@ pm_vp 1/18(9): notforwarding -> present
26w2d: @@@ pm_vp 1/18(9): present -> not_present
26w2d:     pm_vp 1/18(100): during state forwarding, got event 7(trunk_remove)
26w2d: @@@ pm_vp 1/18(100): forwarding -> notforwarding
26w2d: @@@ pm_vp 1/18(100): notforwarding -> present
26w2d: @@@ pm_vp 1/18(100): present -> not_present
26w2d: *** vp_fwdchange: trunk: notfwd: 1/18(1) 1/18(2) 1/18(3) 1/18(9) 1/18(100)
26w2d: *** vp_linkchange: trunk: down: 1/18(1) 1/18(2) 1/18(3) 1/18(9) 1/18(100)
26w2d: *** vp_statechange: trunk: remove: 1/18(1) 1/18(2) 1/18(3) 1/18(9) 1/18(100)
26w2d: %LINK-5-CHANGED: Interface GigabitEthernet0/18, changed state to administratively down
26w2d: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/18, changed state to down
26w2d: STP: VLAN0002 Topology Change rcvd on Gi0/24
26w2d: STP: VLAN0003 Topology Change rcvd on Gi0/24
26w2d: STP: VLAN0100 Topology Change rcvd on Gi0/24
26w2d: STP: VLAN0009 Topology Change rcvd on Gi0/24



Building B:

21w2d: STP: VLAN0002 sent Topology Change Notice on Gi0/6
21w2d: STP SW: Gi0/7 new blocking req for 1 vlans
21w2d: STP: VLAN0002 Gi0/7 -> blocking
21w2d: STP: VLAN0003 sent Topology Change Notice on Gi0/6
21w2d: STP: VLAN0003 Gi0/7 -> blocking
21w2d:     pm_vp 1/7(2): during state forwarding, got event 15(notfwd_notnotify)
21w2d: @@@ pm_vp 1/7(2): forwarding -> notforwarding
21w2d:     pm_vp 1/7(3): during state forwarding, got event 15(notfwd_notnotify)
21w2d: @@@ pm_vp 1/7(3): forwarding -> notforwarding
21w2d: *** vp_list_fwdchange: notfwd: 1/7(2)
21w2d: *** vp_list_fwdchange: notfwd: 1/7(3)
21w2d: STP: VLAN0100 sent Topology Change Notice on Gi0/6
21w2d: STP SW: Gi0/7 new blocking req for 1 vlans
21w2d: STP: VLAN0100 Gi0/7 -> blocking
21w2d: STP: VLAN0009 sent Topology Change Notice on Gi0/6
21w2d: STP: VLAN0009 Gi0/7 -> blocking
21w2d:     pm_vp 1/7(9): during state forwarding, got event 15(notfwd_notnotify)
21w2d: @@@ pm_vp 1/7(9): forwarding -> notforwarding
21w2d:     pm_vp 1/7(100): during state forwarding, got event 15(notfwd_notnotify)
21w2d: @@@ pm_vp 1/7(100): forwarding -> notforwarding
21w2d: *** vp_list_fwdchange: notfwd: 1/7(9)
21w2d: *** vp_list_fwdchange: notfwd: 1/7(100)
21w2d: STP SW: Gi0/7 new listening req for 1 vlans
21w2d: STP: VLAN0002 Gi0/7 -> listening
21w2d: STP: VLAN0003 Gi0/7 -> listening
21w2d: STP: VLAN0100 Gi0/7 -> listening
21w2d: STP: VLAN0009 Gi0/7 -> listening
21w2d: pm_vp_list_set_stp_state Gi0/7(2): ps(blocking) == vpd->stpState already!
21w2d: pm_vp_list_set_stp_state Gi0/7(3): ps(blocking) == vpd->stpState already!
21w2d: pm_vp_list_set_stp_state Gi0/7(9): ps(blocking) == vpd->stpState already!
21w2d: pm_vp_list_set_stp_state Gi0/7(100): ps(blocking) == vpd->stpState already!
21w2d: STP SW: Gi0/7 new learning req for 1 vlans
21w2d: STP: VLAN0002 Gi0/7 -> learning
21w2d: STP: VLAN0003 Gi0/7 -> learning
21w2d: STP: VLAN0100 Gi0/7 -> learning
21w2d: STP: VLAN0009 Gi0/7 -> learning
21w2d: STP SW: Gi0/7 new forwarding req for 1 vlans
21w2d: STP: VLAN0002 sent Topology Change Notice on Gi0/6
21w2d: STP: VLAN0002 Gi0/7 -> forwarding
21w2d: STP: VLAN0003 sent Topology Change Notice on Gi0/6
21w2d: STP: VLAN0003 Gi0/7 -> forwarding
21w2d: STP: VLAN0100 sent Topology Change Notice on Gi0/6
21w2d: STP: VLAN0100 Gi0/7 -> forwarding
21w2d: STP: VLAN0009 sent Topology Change Notice on Gi0/6
21w2d: STP: VLAN0009 Gi0/7 -> forwarding
21w2d:     pm_vp 1/7(2): during state notforwarding, got event 14(forward_notnotify)
21w2d: @@@ pm_vp 1/7(2): notforwarding -> forwarding
21w2d:     pm_vp 1/7(3): during state notforwarding, got event 14(forward_notnotify)
21w2d: @@@ pm_vp 1/7(3): notforwarding -> forwarding
21w2d:     pm_vp 1/7(9): during state notforwarding, got event 14(forward_notnotify)
21w2d: @@@ pm_vp 1/7(9): notforwarding -> forwarding
21w2d:     pm_vp 1/7(100): during state notforwarding, got event 14(forward_notnotify)
21w2d: @@@ pm_vp 1/7(100): notforwarding -> forwarding
21w2d: *** vp_list_fwdchange: forward: 1/7(2)
21w2d: *** vp_list_fwdchange: forward: 1/7(3)
21w2d: *** vp_list_fwdchange: forward: 1/7(9)
21w2d: *** vp_list_fwdchange: forward: 1/7(100)
0
 
Don JohnstonInstructorCommented:
I think your issue is going to be that you're trying to trunk over a T1 line. Trunks are ethernet features.

An additional complication is that the switch is doing perVLAN spanning tree which I doubt routers (bridges) can do.


0
 
drcheapAuthor Commented:
Could be, but why does it work for all the other VLANs, just not VLAN 1?

FWIW, I can confirm that the switch is just not seeing this as a topology change on that particular VLAN...

Building A:

# show spanning-tree vlan 1 detail | i topo
Number of topology changes 77 last change occurred 00:04:15 ago
Times:  hold 1, topology change 35, notification 2
Timers: hello 1, topology change 0, notification 0, aging 300

# show spanning-tree vlan 2 detail | i topo
Number of topology changes 57 last change occurred 00:03:27 ago
Times:  hold 1, topology change 35, notification 2
Timers: hello 1, topology change 0, notification 0, aging 300


Building B:

# show spanning-tree vlan 1 detail | i topo
Number of topology changes 73 last change occurred 18:04:34 ago                     <--- should be more recent!
Times:  hold 1, topology change 35, notification 2
Timers: hello 0, topology change 0, notification 0, aging 300

# show spanning-tree vlan 2 detail | i topo
Number of topology changes 60 last change occurred 00:04:34 ago
Times:  hold 1, topology change 35, notification 2
Timers: hello 0, topology change 0, notification 0, aging 300
0
 
Don JohnstonInstructorCommented:
I dunno.

What you're trying to do is akin to carrying a ton of bricks in a Honda. :-) T1's just aren't intended to carry more than one broadcast domain.
0
 
drcheapAuthor Commented:
IT WORKS NOW!!!

So I was stuck in the mindset that, with the bridge group set up to "connect" the ethernet ports of the routers by way of the T1 that it worked like the fiber media converters.  That is, "what goes in one side comes out the other."  This is incorrect.

The fiber & media converters basically operate at layer 1, changing only the physical media.  The T1 is a layer 2 serial link, thus it is not "transparent" to other layer 2 components such as VLAN protocols.  Because of this, the routers do in fact need to be aware of both the VLANs and the STP because they are participating in them, not just tunneling them.

Anyway, I learned that the routers have some spanning tree settings for the bridge group, and when looking into that somehow one wasn't configured at all, and the other was set for vlan-bridge protocol.  With a "bridge 1 protocol ieee" command on each router, they are now both speaking the same language as the switches.

After the network converged, the Serial interface on one router was blocking.  Bringing down the fiber link caused a reconvergence, and afterwards the Serial interface was up and all traffic was passing as it should.  Switching the fiber on resulted in a similar scenario in the other direction, returning to the original state.

The only problem now is that it takes 30 seconds for the network to converge, which is better than an extended outage, but still unacceptable for the end user (as well as some applications).  To assist with this I have migrated my switches to Rapid-PVST, which makes then converge faster than I can type commands to watch it happen!  The routers, however, do not support Rapid-PVST apparently, just PVST (aka ieee), so it sitll takes 30 seconds to failover or failback.

I tried using the uplinkfast feature of the routers to encourage a faster transition to forwarding state on the Serial interface, but this doesn't seem to make any difference.  The only other idea at this point is to get the switch to be the one with the blocking port, in which case it should transition quickly under RSTP.  I haven't been able to figure that out yet, but it's really outside the scope of this question anyway.
0
 
Don JohnstonInstructorCommented:
Mixing legacy spanning-tree devices with rapid spanning-devices will negate some of the benefits. Especially if the legacy device is part of the loop.

You're just intent on getting all those bricks in the Honda, aren't you? ;-)
0
 
drcheapAuthor Commented:
Well I drive a Honda, and you'd be surprised how much stuff can be crammed in...

So the idea is to get the switch at B to have the fiber facing port forwarding for all VLANs, and the T1 facing port blocked as an alternate port for all VLANs.  That way when the primary link fails, the switch will change to the alternate ports within a couple of seconds via RSTP.

The issue is that the Serial interface on the rotuer further from the root switch is the one that blocks instead.  This makes sense as it is the most distant from the root based on root path cost.  So the next plan was to change the cost of the fiber facing port (which is also root facing) to equal that of the total root path cost of the T1 facing port.  Ports have equal cost, so now the paths are the same length, making this switch the furthest point from the root.  As the fiber facing one has a lower priority set already, it will be chosen as the primary, and the other becomes alternate.

Now for the kicker...setting the port path cost across the board (either not VLAN specific, or for all VLANs) results in 2 VLANs going over one connectio, and 3 going over the other.  I'm not sure why, the actual path costs are equal for all VLANs in this situation.  I think it has something to do with the router not even using PVST (it's just listed as "ieee" as the protocol, which would be regular old STP).

Anyway, it turns out that setting the port path cost of the fiber facing port for VLAN 1 only is enough to cause the router to put the serial interface into a forwarding state.  As a result, the switch now detects the loop on all of the VLANs, and of course blocks traffic on the T1 facing port.

Now for some testing...I bring down the fiber link and sure enough the switch puts the alternate ports into forwarding within a couple of seconds -- nice!  The only remaining side effect is that of MAC address caches, so there is about 5 or so additional seconds of delay for some traffic while those expire.

Total failover or failback transition time, from the perspective of an end user, is on the order of 10 seconds at most.  This is acceptable.
0

Featured Post

Hire Technology Freelancers with Gigs

Work with freelancers specializing in everything from database administration to programming, who have proven themselves as experts in their field. Hire the best, collaborate easily, pay securely, and get projects done right.

  • 6
  • 4
Tackle projects and never again get stuck behind a technical roadblock.
Join Now