redundant Q-in-Q injection

d-mark · ‎02-20-2007

Hi,

I have to inject traffic in a dot1q-tunnel and this has to happen in a redundant way. The structure of the underlying network is the following:

There are 2 pairs of switches the first one consists of 2 Catalyst 6509-E which both belong to 1 mst region and the second one is made up of 2 Catalyst 4948 which don't run any kind of spanning-tree. The 2 switches of each pair are connected to each other and this link should be the primary one. There are also 4 connections acting as trunks between these two pairs of switches, so that each switch has one direct connection to each one of the 2 switches of the opposite pair.

To inject the traffic into the Q-in-Q tunnel this structure of 4 direct connections between the switches is repeated. But this time the interfaces of the Catalyst 4849 terminate these links configured with "switchport mode dot1q-tunnel". At the other side the interfaces of the 2 Catalyst 6509-E are configured as trunk with allows only the vlans which had to be insert into the dot1q-tunnel.

My problem is that I can't get this running. With just one of the 4 Q-in-Q links active this works. But if I activate just one of the other 3 Q-in-Q connections this stops working properly. I lose the remote connection to the 2 Catalyst 6509-E and it seems there is a loop. But "debug spanning-tree all" won't show any thing at all at the 2 Catalyst 6509-E.

Has someone of you been able to setup a similar scenario? And/Or can give me some kind of hind in the right direction?

thanks in advance

kind regards

Mark

sadbulali · ‎02-26-2007

Tag Stacking is a Cisco's implementation of Q-in-Q. Tag Stacking in the context of VPLS is used to bundle all customer VLANs into a single L2VPN identifier that identifies which VSI is used to switch the frame. The outer 802.1q label in the Tag Stack is a service delimiting Tag.

PPPoE - QinQ Support on Subinterfaces:

PPPoE - QinQ Support simply adds another layer of IEEE 802.1Q tag (called "metro tag" or "PE-VLAN") to the 802.1Q tagged packets that enter the network. The purpose is to expand the VLAN space by tagging the tagged packets, thus producing a "double-tagged" frame. The expanded VLAN space allows the service provider to provide certain services, such as Internet access on specific VLANs for specific customers, and yet still allows the service provider to provide other types of services for their other customers on other VLANs.

Generally the service provider's customers require a range of VLANs to handle multiple applications. Service providers can allow their customers to use this feature to safely assign their own VLAN IDs on subinterfaces because these subinterface VLAN IDs are encapsulated within a service provider-designated VLAN ID for that customer. Therefore there is no overlap of VLAN IDs among customers, nor does traffic from different customers become mixed. The double-tagged frame is "terminated" or assigned on a subinterface with an expanded encapsulation dot1q command that specifies the two VLAN ID tags (outer VLAN ID and inner VLAN ID) terminated on the subinterface. See Figure 1.

PPPoE - QinQ Support is generally supported on whichever Cisco IOS features or protocols are supported on the subinterface. For example, if you can run PPPoE on the subinterface, you can configure a double-tagged frame for PPPoE. IPoQ-in-Q supports IP packets that are double-tagged for Q-in-Q VLAN tag termination by forwarding IP traffic with the double-tagged (also known as stacked) 802.1Q headers.

Try:

http://www.cisco.com/en/US/products/sw/iosswrel/ps5207/products_feature_guide09186a00801f0f4a.html

d-mark · ‎02-26-2007

Hi,

I've found my mistake. The "l2protocol-tunnel stp" was missing at the Q-in-Q ports, so the STP wasn't able to work properly and remove the loops.

regards

Mark