Hi Andrew,

Thanks for your reply.

As a matter of fact, STP tunneling is supported.

You can find the related information at follow link:

http://www.cisco.com/en/US/docs/switches/lan/catalyst3550/software/release/12.2_44_se/configuration/guide/swtunnel.html#wp1001998

Thanks,

Peter Bian

Nice find - I will add that url to my favorites....but did you also read:-

•If an encapsulated PDU (with the proprietary destination MAC address) is received from a tunnel port or an access port with Layer 2 tunneling enabled, the tunnel port is shut down to prevent loops. The port also shuts down when a configured shutdown threshold for the protocol is reached. You can manually re-enable the port (by entering a shutdown and a no shutdown command sequence). If errdisable recovery is enabled, the operation is retried after a specified time interval.

•Only decapsulated PDUs are forwarded to the customer network. The spanning-tree instance running on the service-provider network does not forward BPDUs to tunnel ports. CDP packets are not forwarded from tunnel ports.

•When protocol tunneling is enabled on an interface, you can set a per-protocol, per-port, shutdown threshold for the PDUs generated by the customer network. If the limit is exceeded, the port shuts down. You can also limit BPDU rate by using QoS ACLs and policy maps on a tunnel port.

•When protocol tunneling is enabled on an interface, you can set a per-protocol, per-port, drop threshold for the PDUs generated by the customer network. If the limit is exceeded, the port drops PDUs until the rate at which it receives them is below the drop threshold.

•Because tunneled PDUs (especially STP BPDUs) must be delivered to all remote sites so that the customer virtual network operates properly, you can give PDUs higher priority within the service-provider network than data packets received from the same tunnel port. By default, the PDUs use the same CoS value as data packets.

???

Hello Peter,

you have written of a physical loop.

RPVST should be able to manage it if all ports are normal ports.

the 802.1Q tunnel ports should be out of the ring and deployed in pairs to emulate point-to-point links.

RPVST cannot inspect the inner vlans inside the tunnel and so only the instance for the external (customer-id) vlan should be able to work.

Hope to help

Giuseppe

Hope to help

Giuseppe

Hi Giuseppe,

Thanks for the reply.

I thought the RPVST should prevent the loop logically too.

But I still get the storm, I suspect there is something wrong with the Service Provider network.

Thank you,

Peter Bian