RSPAN over Q-in-Q ?

bvilajoliu · ‎02-02-2009

Hello all,

We need to transport a RSPAN session across non-cisco infrastructure. One of the options we are taking into account is implementing a l2tunnel mechanism (QinQ) and forward de RSPAN data across it.

Could it work? Not so much information about this stuff.

At this time we have a testbed with QinQ working (IP connectivity between the two L2 islands, but not the RSPAN).

- SW1 is the RSPAN source, with VLAN1213 clients

- SW2 is the RSPAN destination

- RSPAN vlan is 161

- Provider VLAN is 150

- Client VLAN is 1213 (to be SPANed)

SW1:fa1/0/4<---->SW1:fa1/0/5 + SW1:fa1/0/1<---dot1Q150-->SW2:fa1/0/1 + SW2:fa1/0/5<---->SW2:fa1/0/4

SW1############################

...

vlan dot1q tag native

!

vlan 30

name BOGUS-VLAN-3

!

vlan 150

name vlan-PROVIDER

!

vlan 161

name VLAN-RSPAN

remote-span

!

vlan 1213

name VLAN-CGA

...

interface FastEthernet1/0/1

switchport trunk encapsulation dot1q

switchport trunk allowed vlan 150

!

interface FastEthernet1/0/4

switchport trunk encapsulation dot1q

switchport trunk allowed vlan 1,30,161

switchport mode trunk

no cdp enable

spanning-tree portfast trunk

spanning-tree bpdufilter enable

!

interface FastEthernet1/0/5

switchport access vlan 150

switchport mode dot1q-tunnel

l2protocol-tunnel cdp

l2protocol-tunnel stp

l2protocol-tunnel vtp

no cdp enable

spanning-tree portfast trunk

spanning-tree bpdufilter enable

!

...

monitor session 1 source vlan 1213 rx

monitor session 1 destination remote vlan 161

SW2############################

vlan dot1q tag native

!

vlan 30

name BOGUS-VLAN-3

!

vlan 150

name vlan-PROVIDER

!

vlan 161

name VLAN-RSPAN

remote-span

...

interface FastEthernet1/0/1

switchport trunk encapsulation dot1q

switchport trunk allowed vlan 150

switchport mode trunk

!

interface FastEthernet1/0/4

switchport trunk encapsulation dot1q

switchport trunk allowed vlan 1,30,161

switchport mode trunk

spanning-tree portfast trunk

spanning-tree bpdufilter enable

!

interface FastEthernet1/0/5

switchport access vlan 150

switchport mode dot1q-tunnel

l2protocol-tunnel cdp

l2protocol-tunnel stp

l2protocol-tunnel vtp

no cdp enable

spanning-tree portfast trunk

spanning-tree bpdufilter enable

...

monitor session 1 destination interface Fa1/0/12

monitor session 1 source remote vlan 161

From the point of view we have E2E connectivity into VLAN-BOGUS we can state the tunnel is working fine. Ont he other hand, we know rspan VLAN is special because of the supression of ARP messaging but we expect the RSPAN will work because of the transparency of the QinQ. But not.

Any idea? Other solitions are welcome as well.

Thanks in advance

Giuseppe Larosa · ‎02-02-2009

Hello Berenguer,

being 802.1 Q in Q tunneling a transparent point to point service it will work also for the RSPAN vlan.

The RPSAN vlan disables MAC address learning so you need to verify you have enough bandwidth to carry the mirrored traffic.

Actually I've seen this disabling of MAC address learning also on point-to-point EoMPLS.

You need also to be sure that it is a true point-to-point topology.

Hope to help

Giuseppe

bvilajoliu · ‎02-03-2009

Hello Giuseppe, hello all,

The bandwidth is not a problem nor the topology. For sure it is a point-to-point.

I think the problem with QinQ is the non-forwarding because of the absense of learned MAC addresses within the RSPAN VLAN. It is like having non-cisco switches in the midle of the path of the RSPAN. You need to hardcode de mac addresses along all the path in a hop-by-hop basis (working). With QinQ I supose I also need to hardcode de MAC addresses but only at tunnel endpoint switches. I'm looking for non-hardcoding solutions.

With EoMPLS, the RSPAN works over an xconnect, without hardcoding of nothing, but we prefer to use QinQ because of the customer scenario and available hardware.

Thanks for your comments. If I get it working with QinQ I'll post here the config.

Berenguer Vilajoliu

Giuseppe Larosa · ‎02-03-2009

Hello Berenguer,

I've reviewed the sample of configuration you have reported.

In my understarding of 802.1 Q in Q

sw1 normal trunk port that carries RPSPAN vlan has to connect to an 802.1Q tunnel port on SW2.

Using customer vlan (outer vlan )it goes via provider network and on penultimate switch that should be the outgoing 802.1Q tunnel port.

Last switch connects using a normal trunk port that includes the RSPAN vlan.

I see the 802.1Q tunnel port configured also on SW1 and this confuses me.

Probably it is only an error in pasting.

Or you have only two switches in the lab like the chain suggests ?

Hope to help

Giuseppe

bvilajoliu · ‎02-03-2009

Hello again Giuseppe,

And thanks for your fast reply.

I only have 2 x 3750 Metro switches in testbed. I have more switches (3550) that can act as RSPAN sender and receiver but I don't want to use it. I suppose my 2-switch scenario is the same

4-switch scenario you tell to me.

Thanks,

Giuseppe Larosa · ‎02-03-2009

Hello Berenguer,

I would try to use 4 switches I'm not sure it is the same.

Try to add two C3550 to the testbed.

Hope to help

Giuseppe