[c-nsp] STP to L2 FTTx gear

[Phil Mayers]

Justin Shore wrote:
> Given all the STP questions on the list this past week I thought I'd add 
> mine to the group while STP is on everyones' minds.
> 
> We've recently deployed the beginning of our FTTx offering.  The vendor 
> we went with is L2-only (that's a good thing).  The GigE rings have been 
> built and the L3 side of things on my 7600s has been built.  I'm meeting 
> the FTTx gear with 5 VLANs on 2x 1Q trunks for redundancy from, 1 trunk 
> from each 7600.  The 5 VLANs are allowed across the port-channel between 
> the 7600s and I'm running HSRP on each SVI.  We didn't set up the trunks 
> with a native VLAN.  The config is fairly basic.

Just one minor correction; You didn't setup the trunks with a native 
VLAN, so it defaults to 1. Given the somewhat special nature of vlan 1 
on Ciscos, and the fact these ports face a 3rd party, this might be 
unwise. I would recommend using a dummy vlan as the native vlan on the port.

Dear Cisco - please provide a way to put the entire port into "no native 
vlan" mode, as opposed to the entire chassis. Sincerely yours etc.

> 
> interface GigabitEthernet1/9
>   description TO FTTx
>   switchport
>   switchport trunk encapsulation dot1q
>   switchport trunk allowed vlan 800,801,811,821,831,851
>   switchport mode trunk
>   spanning-tree portfast trunk
> 
> I'm leaving out the SVIs unless someone thinks their pertinent.  The 
> current default spanning tree mode for both 7600s is PVST.  The problem 
> I has is that I can't have both physical interfaces (the trunks) turned 
> up at the same time.  Doing so causes 2 of my VLANs to go into blocking:
> 
> 7613-1# sh spanning-tree interface gi1/9
> 
> Vlan                Role Sts Cost      Prio.Nbr Type
> ------------------- ---- --- --------- -------- 
> --------------------------------
> VLAN0800            Desg FWD 4         128.9    Edge P2p
> VLAN0801            Desg BKN*4         128.9    Edge P2p *PVID_Inc
> VLAN0811            Desg BKN*4         128.9    Edge P2p *PVID_Inc



> VLAN0821            Desg FWD 4         128.9    Edge P2p
> VLAN0831            Desg FWD 4         128.9    Edge P2p
> VLAN0851            Desg FWD 4         128.9    Edge P2p
> 
> Same thing for the other 7600.  The FTTx vendor set up the hardware to 
> not participate in any form of STP on the interfaces facing my 7600s. 
> They're running EPS on the GigE rings.  I haven't sniffed this yet to 
> prove it but I expect to see all BPDUs leaving Gi1/9 on one 7600 being 
> received on Gi1/9 of the other 7600 untouched by what's in the middle.

I think not:

http://tinyurl.com/yak4ls

"""Port VLAN ID (PVID) inconsistency—A per-VLAN spanning tree (PVST+) 
Bridge Protocol Data Unit (BPDU) is received on a different VLAN than it 
was originated: (Port VLAN ID Mismatch or *PVID_Inc)."""

I'll bet your L2 provider has gotten vlan 801 & 811 swapped around on 
one of the links to the 7600 somehow. Or, has somehow left PVST running 
inside their own network, and is doing vlan remapping, but only on the 
carrier vlans for 801/811.

> 
> So, my question is which form of STP would be best for this particular 
> scenario?  1d, 1w, PVST, Rapid-PVST or should I be looking at MST?  I 

None are likely to work with 100% reliability if you can't get a 
completely clean L2 path.

My personal view is that PVST still wins in most cases. MST is a bad 
joke, because you can only run one MST "process" on a cisco; this can be 
crippling in some topologies e.g. ours.

> don't care about load-balancing at the present.  It would be nice is the 
> physical link mimicked HSRP but I'm not that picky.  I'm assuming that 

I am assuming you have a link between the 7600s with the vlans on; 
simply set the STP cost lower on that, and the 7600 which is the STP 
secondary root will block the ports facing the L2 provider, and favour 
the port(s) facing the other 7600.

Making the HSRP master always be the same as the STP master is tricky, 
but can be achieved with "standby preempt" and appropriate "standby 
track" statements, especially if you're on 12.2(33) with the much better 
object tracking,

> the FTTx vendor could participate in 1d or 1w if I asked but not having 
> to have that level of integration could be a good thing.  One less thing 
> to troubleshoot when something breaks.

Our experience procuring L2 links from providers (not FTTx it must be 
said) has been distinctly mixed; we've had MTU issues, vlan tagging 
problems, unidirectional forwarding losses, and failure of unicast flooding.

I can imagine letting your provider participate in your STP being very, 
very painful!

> 
> Suggestions?  Thanks
>   Justin
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/