IOS XE 15.5
IOS XR 5.3
The topology for this demo:
This post will be a bit more focused simply because we are continuing on from the previous PORT and VLAN rollouts in prior posts, we are taking the VLAN mode one level deeper by utilizing 802.1Q Tunneling as the AC connection. The concept for me at least was a bit difficult at first until I educated myself on QinQ. With VLAN mode, you have 1 VLAN that is specified on the PE and the CE, encap dot1q 100 for instance. This is what the provider will use to forward traffic from the ingress PE to the egress PE. This isn't QinQ end to end in the traditional sense of maintaining VLAN 100 in the provider core, but leveraging the QinQ technology at the AC level.
The idea is that the inner VLAN ID or the "encapsulation dot1q 100" is considered to be the provider VLAN or S-Tag. If you look at wireshark captures, you won't see it show up. The outer VLAN ID or the "second-dot1q 200" is considered the customer VLAN or the C-Tag. The inner VLAN ID or S-Tag is actually stripped off as it enters the interface which is why it is not seen in wireshark outputs. The Outer VLAN ID or C-Tag is maintained by the SP which is why it is seen by wireshark outputs. When we get to EVC/EFP configurations in later posts you will see how that can be changed with EVC rewrite options.
The entire configuration is 1 line consisting of "encapsulation dot1Q 100 second-dot1q 200". This is configured on the PE interface facing the customer and the customer interface facing the provider. In our lab, R3 on G3.100, R6 on G2.100, R8 on G1.100 and R10 on G1.100.
R3
interface GigabitEthernet3.100
encapsulation dot1Q 100 second-dot1q 200
xconnect 192.168.1.6 200 encapsulation mpls
R6
interface GigabitEthernet2.100
encapsulation dot1Q 100 second-dot1q 200
xconnect 192.168.1.3 200 encapsulation mpls
R8
interface GigabitEthernet1.100
encapsulation dot1Q 100 second-dot1q 200
ip address 192.168.200.8 255.255.255.0
R10
interface GigabitEthernet1.100
encapsulation dot1Q 100 second-dot1q 200
ip address 192.168.200.10 255.255.255.0
Before we can move on, we need to verify the config is working.
R3#show xconnect all
Legend: XC ST=Xconnect State S1=Segment1 State S2=Segment2 State
UP=Up DN=Down AD=Admin Down IA=Inactive
SB=Standby HS=Hot Standby RV=Recovering NH=No Hardware
XC ST Segment 1 S1 Segment 2 S2
------+---------------------------------+--+---------------------------------+--
UP pri ac Gi3.100:100/200(Eth VLAN) UP mpls 192.168.1.6:200 UP
Awesome, it's up and running! You'll notice a few things, the output states (Eth VLAN) and we have 100/200, where 100 is the S-Tag and 200 is the C-Tag. I am using the older syntax so let's kill R3's side and use the L2VPN Protocol CLI. I won't continue to use the "xconnect'' style moving forward since that configuration style limits our scalability, plus we will be moving into ECVs and EFPs very soon so it make sense to leverage those capabilities.
R3
interface pseudowire200
encapsulation mpls
neighbor 192.168.1.6 200
l2vpn xconnect context QinQ
member GigabitEthernet3.100
member pseudowire200
Now let's verify it too!
R3#sho l2vpn atom vc
Service
Interface Peer ID VC ID Type Name Status
--------- --------------- ---------- ------ ------------------------ ----------
pw200 192.168.1.6 200 p2p QinQ UP
Excellent! We are up and running as I expected we would be.
Since we know that the PW is up between R3 and R6, we should try to ping and verify ARP on the CEs. If you are feeling frisky you could also try setting a routing adjacency over the connection.
R8#ping 192.168.200.10
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.200.10, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms
R8#show arp | in 192.168.200.
Internet 192.168.200.8 - 000c.29c9.1f5c ARPA GigabitEthernet1.100
Internet 192.168.200.10 176 000c.2994.b818 ARPA GigabitEthernet1.100
R8
router eigrp 100
network 192.168.200.0
R8(config-router)#
*Nov 23 14:16:34.968: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 192.168.200.10 (GigabitEthernet1.100) is up: new adjacency
Let's take a look at some wireshark outputs so help make this crystal clear.
As you can see from the output we have a ping reply from R10 to R8 and an EIGRP hello from R10 to 224.0.0.10. You'll notice that the 802.1Q VLAN field has the ID of 200 indicating that the the QinQ configuration is working.
Thanks for stopping by!
Rob Riker, CCIE #50693
No comments:
Post a Comment