QinQ configuration being provider and customer edge on same switch

[tdeserranno]

I did not setup any IRF stack in my simulation.

Just took two switches, linked them through an 1G on their Gi1/0/1 ports and configured the vlans and qinq.

And finally made a connection on each switch between the gi1/0/2 and gi1/0/3 port.  (you have to do this connection in HCL using 'adding a 'manual' link'

[Mike_ES]

Yes, understood your topology. My question was little out-of-scope of this tread :-), because I haven't much experience with HLC. Now I testing it and check usefulness for my HPN cases.

Anyway, backing to the problem maybe it would be worth to create Edge switches in the path (just to simulate provider switches and full path) for testing if HLC switches properly imitates QinQ config with Comware 7?

Br,

Michal

[Joepske]

Hi Michal, Of topic, yes you can setup IRF in HLC: I have 2 switches running in IRF.

irf member 1 priority 1
irf member 2 priority 1

irf-port 1/1
port group interface Ten-GigabitEthernet1/0/49
port group interface Ten-GigabitEthernet1/0/50
#
irf-port 2/2
port group interface Ten-GigabitEthernet2/0/49
port group interface Ten-GigabitEthernet2/0/50

[Mike_ES]

Ok now IRF is working, sorry to all for off-topic ;-)

thx

Michal

[tdeserranno]

I doubt whether QinQ will work in the HCL simulator ?  I can't get it to work.

I have experienced that other layer 2 functionalities do not work in HCL while they work on real HW

For instance, applying L3 ACL's as packet-filter on a L2 interface does not work in HCL

For instance, applying a VLAN QOS policy to a VLAN does not work in HCL.

Will have to look for HW !

[Joepske]

Hi Tdesserrano

First of all, thanks for trying! 

I tried it myselfe too, struggeling arround with the simulator, and also hoping / guessing this is an simulator issue and not a real deal :) Just can't get QinQ to work.

I tried several things, also with a 'provider switch in between. But no luck to get it to work. So I will test it on the hardware itselfe.

I also notices that the command

display mac-address

doesn't show any entry's. Also an simulator issue? And maybe causing QinQ to fail.

Anyway, below a screenshot of the HCL layout.

[tdeserranno]

Indeed, no mac-address table entries in HCL.  We noticed this too.

I guess we'll have to simulate on HW.  Tomorrow I'll have hands on a couple of HP 5500 HI to test with.  I hope to be able to see at least a minimal QinQ testbed working.

I'll keep you posted.

[tdeserranno]

I setup the following test with two HP 5500 HI switches

Ping from VLAN 200 at one side to VLAN 200 at the other side worked.  Between the two sites, VLAN 200 was QinQ'ed over SVLAN 1000.

Configuration and pings+display commands attached.

[Joepske · Accepted solution]

Hi,

Thanks for the testing and setting it up. 

As told, I run the temporary environment on an HP 3500-24G switch, wich with the latest firmware also supports QinQ / BGP etc... I Thought, let me share these 'strange' settings with you. Because, when setting it up on the same switch with a looped cable as descibed above, you need to change the Layer3 MAC address on the VLAN that crosses QinQ.

Article here: http://h20564.www2.hpe.com/hpsc/doc/public/display?docId=mmr_kc-0131185&sp4ts.oid=3437443

Extra changes to be made:

Within VLAN200 (Customer VLAN) I added:

ip-recv-mac-address 223344-223344

On the Customer QinQ port (on wich the looped cable is connected, I added the commands:

unknown-vlans disable
qinq port-type customer-network
untagged svlan 1000

On the Serviceprovider QinQ port (on wich the uplink to MS Azure is connected) I added the commands:

unknown-vlans disable
QinQ port-type Provider-network (which is default and not visible)
tagged svlan 1000

And so QinQ with a Looped cable on the same switch works on a HP3500 switch also, with above adjustments.

In the weekend of the 25th of March, I'll be migrating the customer, and the 5800's will be connected and configured. So fingers crossed that I don't need an L3 MAC RECV command (which doens't excists on the comware switches, but possibly could be replaced by the IP Source Binding <IP> <MAC> command?)

But overall conclusion for this post is, that it is NOT POSSIBLE to add an S-VLAN tag to an C-VLAN on the same switch WITHOUT using a looped cable construction.

Case closed!

Joep