Huawei - Switch: Basic QinQ Tunnel (aka 802.1Q Tunneling)

How to Configure Basic QinQ?

Posted on December 8, 2014

 

Networking Requirements

As shown in the below figure, there are two enterprises on the network, Enterprise 1 and Enterprise 2. Enterprise 1 has two office locations, and Enterprise 2 has 2 office locations. The office locations of the two enterprises access SwitchA and SwitchB of the ISP network. A non-Huawei device with the TPID value 0x9100 exists on the public network.

The requirements are as follows:

• Enterprise 1 and Enterprise 2 plans their VLANs independently.
• Traffic of the two branches is transparently transmitted on the public network. Users using the same services in the two branches are allowed to communicate and users using different services are isolated.

You can configure QinQ to meet the preceding requirements. VLAN 100 provided by the public network can be used to implement communication of Enterprise 1 in the two branches and VLAN 200 is used for Enterprise 2. You can set the TPID value in the outer VLAN on the interface that connects the non-Huawei device to implement communication between devices.

Note: This example can be applied to Huawei switches higher level than Quidway S2700 and with EI version.

 

Configuring basic QinQ

 

Configuration Roadmap

The configuration roadmap is as follows:

• Configure VLAN 100 and VLAN 200 on both SwitchA and SwitchB. Set the link type of the interface to QinQ and add the interfaces to VLAN. In this way, different outer VLAN tags are added to different services.
• Add interfaces connecting to the public network on SwitchA and SwitchB to VLAN 100 and VLAN 200 to permit packets from these VLANs to pass through.
• Set the TPID values in the outer VLAN tag on interfaces connecting to the public network on SwitchA and SwitchB to implement communication between the device with devices from other vendors.

Procedure

 

Create VLANs.

# Create VLAN 100 and VLAN 200 on SwitchA.
<HUAWEI> system-view
[HUAWEI] sysname SwitchA
[SwitchA] vlan batch 100 200

# Create VLAN 100 and VLAN 200 on SwitchB.
<HUAWEI> system-view
[HUAWEI] sysname SwitchB
[SwitchB] vlan batch 100 200

 

Set the link type of the interface to QinQ.

# Configure GE0/0/1 and GE0/0/2 of SwitchA as QinQ interfaces. Set the VLAN of GE0/0/1 to VLAN 100 and the VLAN of GE0/0/2 to VLAN 200. The configuration of SwitchB is similar to the configuration of SwitchA, and the configuration details are not mentioned here.
[SwitchA] interface gigabitethernet 0/0/1
[SwitchA-GigabitEthernet0/0/1] port link-type dot1q-tunnel
[SwitchA-GigabitEthernet0/0/1] port default vlan 100
[SwitchA-GigabitEthernet0/0/1] quit

[SwitchA] interface gigabitethernet 0/0/2
[SwitchA-GigabitEthernet0/0/2] port link-type dot1q-tunnel
[SwitchA-GigabitEthernet0/0/2] port default vlan 200
[SwitchA-GigabitEthernet0/0/2] quit

Configure the interface connecting to the public network on the switch.

# Add GE0/0/3 of SwitchA to VLAN 100 and VLAN 200. The configuration of SwitchB is similar to the configuration of SwitchA, and the configuration details are not mentioned here.
[SwitchA] interface gigabitethernet 0/0/3
[SwitchA-GigabitEthernet0/0/3] port link-type trunk
[SwitchA-GigabitEthernet0/0/3] port trunk allow-pass vlan 100 200
[SwitchA-GigabitEthernet0/0/3] quit

Configure the TPID value for an outer VLAN tag

# Set the TPID value of an outer VLAN tag to 0x9100 on SwitchA.
[SwitchA] interface gigabitethernet 0/0/3
[SwitchA-GigabitEthernet0/0/3] qinq protocol 9100

# Set the TPID value of an outer VLAN tag to 0x9100 on SwitchB.
[SwitchB] interface gigabitethernet 0/0/3
[SwitchB-GigabitEthernet0/0/3] qinq protocol 9100

Verify the configuration.

In Enterprise 1, ping a PC of a VLAN in a branch from a PC of the same VLAN in another branch. If the two PCs can ping each other, internal users of Enterprise 1 can communicate.

In Enterprise 2, ping a PC of a VLAN in a branch from a PC of the same VLAN in another branch. If the two PCs can ping each other, internal users of Enterprise 2 can communicate.

Ping a PC in a VLAN of Enterprise 2 in a branch from a PC in the same VLAN of Enterprise 1 in either branch. If the two PCs cannot ping each other, users in Enterprise 1 and Enterprise 2 are isolated.

 

Configuration Files

# Configuration file of SwitchA
sysname SwitchA
#
vlan batch 100 200
#
interface GigabitEthernet0/0/1
port link-type dot1q-tunnel
port default vlan 100
#
interface GigabitEthernet0/0/2
port link-type dot1q-tunnel
port default vlan 200
#
interface GigabitEthernet0/0/3
qinq protocol 9100
port link-type trunk
port trunk allow-pass vlan 100 200
#
return

#Configuration file of SwitchB
sysname SwitchB
#
vlan batch 100 200
#
interface GigabitEthernet0/0/1
port link-type dot1q-tunnel
port default vlan 100
#
interface GigabitEthernet0/0/2
port link-type dot1q-tunnel
port default vlan 200
#
interface GigabitEthernet0/0/3
qinq protocol 9100
port link-type trunk
port trunk allow-pass vlan 100 200
#
return

The more information about technical support you can consult with our engineer – Bill, and his e-mail address is as below:

bill@huanetwork.com

Taken From: http://www.huanetwork.com/blog/how-to-configure-basic-qinq/

Cisco IP NAT – Extendable Option

Recently at work I ran across a weird static NAT implemention, where it had the “extendable” key word, and the router had two Internet connections (two public IPs):

ip nat inside source static 10.0.0.1 100.0.0.2 extendable
ip nat inside source static 10.0.0.1 200.0.0.2 extendable

The “extendable” option allows static NAT mappings of one Inside Local Address (private address) to multiple Inside Global addresses (public addresses), the keyword “extendable” is added to the end of the mapping statements. [cisco]

This is a good option for accessing one a server via two Internet connections, the traffic can come from any internet connection, that public address gets translated to the same private address (server address), this raises no ambiguity.

As for traffic started by the server with destination to the Internet, I didn’t found very clear information on how the router handles the ambiguity created by the fact that the SERVER address (private address) can be translated to two public addresses.

So in order two answer this question i did some testing, using the topology above.

 

Testing Conclusions

My conclusions where the following:

The Nat extendable works great in following direction:

• R3->R1 (ISP1 –> SERVER)
• R4->R1 (ISP2 –> SERVER)

because the isn't any ambiguity

But in the inverse direction

• R1->R3 (SERVER –> ISP1)
• R1->R4 (SERVER –> ISP2)

it depends on the on the order of intruduction of the NAT rules,

R2-CFG1 
ip nat inside source static 10.0.0.1 100.0.0.2 extendable - R1->R3 - OK
ip nat inside source static 10.0.0.1 200.0.0.2 extendable - R1->R4 - NOK
or
R2-CFG2 
ip nat inside source static 10.0.0.1 200.0.0.2 extendable - R1->R4 - OK
ip nat inside source static 10.0.0.1 100.0.0.2 extendable - R1->R3 - NOK

where the first introduced NAT rule is the one that works
despite of always having the same order on the running-config

ip nat inside source static 10.0.0.1 100.0.0.2 extendable 
ip nat inside source static 10.0.0.1 200.0.0.2 extendable

My guess, is that it’s that this happens because the first rule is considered the main rule and second rule "extends" it (secondary rule), and when there’s ambiguity it defaults to the main rule. 

   

Topology and Configuration

R1
==========================
hostname R1

interface FastEthernet0/0
ip address 10.0.0.1 255.255.255.0
duplex auto
speed auto
ip route 0.0.0.0 0.0.0.0 10.0.0.254

line con 0
logging synchronous
line aux 0
line vty 0 4
password cisco
login

R2
===========================
hostname R2

interface FastEthernet0/0
ip address 10.0.0.254 255.255.255.0
ip nat inside
ip virtual-reassembly
duplex auto
speed auto
!
interface FastEthernet0/1
ip address 100.0.0.1 255.255.255.0
ip nat outside
ip virtual-reassembly
duplex auto
speed auto
!
interface FastEthernet1/0
ip address 200.0.0.1 255.255.255.0
ip nat outside
ip virtual-reassembly
duplex auto
speed auto
!        
ip nat inside source static 10.0.0.1 100.0.0.2 extendable
ip nat inside source static 10.0.0.1 200.0.0.2 extendable

R3
==========================
hostname R3

interface FastEthernet0/1
ip address 100.0.0.254 255.255.255.0
ip nat outside
ip virtual-reassembly
duplex auto
speed auto

R4
==========================
hostname R4

interface FastEthernet0/1
ip address 100.0.0.254 255.255.255.0
ip nat outside
ip virtual-reassembly
duplex auto
speed auto

Tests – Part 1

Initial NAT Table on R2
--------------------------------------------------------------
R2#show ip nat translations 
Pro Inside global      Inside local       Outside local      Outside global
--- 100.0.0.2          10.0.0.1           ---                ---
--- 200.0.0.2          10.0.0.1           ---                ---

Trying To Ping R3 and R4 from R1 via NAT on R2
--------------------------------------------------------------
R1#ping 100.0.0.254

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.0.0.254, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/21/40 ms

R1#ping 200.0.0.254

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 200.0.0.254, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

NAT Table on R2 after the Pings from R1->R3 / R1->R4
--------------------------------------------------------------
R2#show ip nat translations
Pro Inside global      Inside local       Outside local      Outside global
icmp 100.0.0.2:30      10.0.0.1:30    100.0.0.254:30     100.0.0.254:30
icmp 100.0.0.2:31      10.0.0.1:31        200.0.0.254:31     200.0.0.254:31
--- 100.0.0.2          10.0.0.1           ---                ---
--- 200.0.0.2          10.0.0.1           ---                ---

The ping to R4 didn't work, and you can see why on second translation in the NAT table (the "Inside Global" instead of beeing 200.0.0.2 it’s 100.0.0.2 and R4 does not know network 100.0.0.0/24, so it does not reply)

Trying To Ping R1 from R3 and R4 via NAT
--------------------------------------------------------------
R3#ping 100.0.0.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.0.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/24/36 ms

R4#ping 200.0.0.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 200.0.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/23/32 ms

As you can see in this direction things work great

NAT Table on R2 after the Pings from R3->R1 / R4->R1
--------------------------------------------------------------
R2#show ip nat translations
Pro Inside global      Inside local       Outside local      Outside global
icmp 100.0.0.2:5       10.0.0.1:5         100.0.0.254:5      100.0.0.254:5
icmp 200.0.0.2:7       10.0.0.1:7         200.0.0.254:7      200.0.0.254:7
--- 100.0.0.2          10.0.0.1           ---                ---
--- 200.0.0.2          10.0.0.1           ---                ---

Trying To Ping R3 and R4 from R1 via NAT on R2 (AGAIN)
----------------------------------------------------------
R1#ping 100.0.0.254

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.0.0.254, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/21/40 ms

R1#ping 200.0.0.254

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 200.0.0.254, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

This was just to see if the ping from R3->R1 and R4->R1,
could somehow influence the pings in the opposite direction
from R1->R3 / R1->R4, but no, the result is the same.

 

Tests – Part 2

R2 Config Change – Change the Order of the NAT Rules
--------------------------------------------------------
no ip nat inside source static 10.0.0.1 100.0.0.2 extendable
no ip nat inside source static 10.0.0.1 200.0.0.2 extendable
ip nat inside source static 10.0.0.1 200.0.0.2 extendable
ip nat inside source static 10.0.0.1 100.0.0.2 extendable

As you will see bellow instead of a success ping from R1->R3,
you will see a successful ping from R1->R4, and the running
config looks the same before and after this change:

...
ip nat inside source static 10.0.0.1 100.0.0.2 extendable
ip nat inside source static 10.0.0.1 200.0.0.2 extendable
...   

Initial NAT Table on R2
---------------------------------------------------------------
R2#show ip nat translations
Pro Inside global      Inside local       Outside local      Outside global
--- 100.0.0.2          10.0.0.1           ---                ---
--- 200.0.0.2          10.0.0.1           ---                ---

Trying To Ping R3 and R4 from R1 via NAT on R2
--------------------------------------------------------------
R1#ping 100.0.0.254

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.0.0.254, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

R1#ping 200.0.0.254

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 200.0.0.254, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 24/31/60 ms

NAT Table on R2 after the Pings from R1->R3 / R1->R4
---------------------------------------------------------------
R2#show ip nat translations

Pro Inside global      Inside local       Outside local      Outside global
icmp 200.0.0.2:39      10.0.0.1:39        100.0.0.254:39     100.0.0.254:39
icmp 200.0.0.2:40      10.0.0.1:40    200.0.0.254:40     200.0.0.254:40
--- 200.0.0.2          10.0.0.1           ---                ---
--- 100.0.0.2          10.0.0.1           ---                ---

The ping to R3 didn't work, and you can see why on first translation in the NAT table (the "Inside Global" instead of beeing 100.0.0.2 it’s 200.0.0.2 and R3 does not know network 200.0.0.0/24, so it does not reply)

Trying To Ping R1 from R3 and R4 via NAT
--------------------------------------------------------------
R3#ping 100.0.0.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.0.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/20/24 ms

R4#ping 200.0.0.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 200.0.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/23/24 ms

NAT Table on R2 after the Pings from R3->R1 / R4->R1
--------------------------------------------------------------
R2#show ip nat translations

R2#show ip nat translations
Pro Inside global      Inside local       Outside local      Outside global
icmp 100.0.0.2:6       10.0.0.1:6         100.0.0.254:6      100.0.0.254:6
icmp 200.0.0.2:8       10.0.0.1:8         200.0.0.254:8      200.0.0.254:8
--- 200.0.0.2          10.0.0.1           ---                ---
--- 100.0.0.2          10.0.0.1           ---                ---

Trying To Ping R3 and R4 from R1 via NAT on R2 (AGAIN)
--------------------------------------------------------------
R1#ping 100.0.0.254

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.0.0.254, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

R1#ping 200.0.0.254

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 200.0.0.254, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/20/28

This was just to see if the ping from R3->R1 and R4->R1,
could somehow influence the pings in the opposite direction
from R1->R3 and from R1->R4, but no, the result is the same.

As stated before in the conclusions above:

• R1->R3 (SERVER –> ISP1) –– OK on Tests - Part 1
• R1->R4 (SERVER –> ISP2) –– OK on Tests - Part 2

the order of the introduction off the NAT static matters, because only the first rule is used, because of the ambiguity.

Links

• http://www.ciscopress.com/articles/article.asp?p=25273&seqNum=4
• http://www.cisco.com/en/US/technologies/tk648/tk361/tk438/technologies_white_paper09186a0080091cb9.html
• Example: http://ccie4all.wordpress.com/2013/01/12/nat-with-extendable-keyword/
• Small Example: http://network-101.blogspot.pt/2011/05/nat-extendable-option.html
• http://www.routerie.com/cgi-bin/ultimatebb.cgi?ubb=get_topic;f=50;t=003660
• http://network-101.blogspot.pt/2011/05/nat-extendable-option.html?m=1
  http://www.dslreports.com/forum/r24372553-Nat-Extendable-Command
• http://network-101.blogspot.pt/2011/05/nat-extendable-option.html?m=1