So for anyone counting, that brings my lab to 3 x 1841, 3 x 3560, 1 x 2621xm and 1 x 2621. I do also have a 2950 and a 3500xl, but those are at my office and I'm not currently using them for labbing. This should be enough for me to lab up any tech that I need to.
Seeing as how the 2560's are new to me I of course wanted to play with something on them that I haven't been able to do on my routers. By a purely random selection that ended up being QinQ tunneling.
So without further ado here's an actual blog post!
QinQ tunneling is officially defined by the 802.1ad Provider Bridges standard. This is not to be confused with 802.3ad Link Aggregation (of which LACP is a part of), though later on in this post I will be using some LAG's in the configuration. QinQ tunneling is a method by which frames received on a switchport are tagged with an additional 802.1Q tag to any that are already contained within the layer 2 headers. The goal is to allow providers to transport customer VLAN information across their backbones unmodified. This process is transparent to the customer as two switches (or more) at different sites will appear to be directly connected to each other.
I think that if you're here, and you're reading this post then you likely know what QinQ is, and have seen better explanations that what I just did above. To that end, let's dispense with the chatter and configure this stuff up.
I'm going to start with the following topology:
I'm using routers as the customer equipment here, but that's irrelevant really since all the magic happens on the switches. But, I am using subinterfaces with dot1q encapsulation on the routers to generate tagged frames that will enter the provder network. Here's the simple interface configs I'm using on both routers:
r1#sh run int f0/0
Building configuration...
Current configuration : 73 bytes
!
interface FastEthernet0/0
no ip address
duplex auto
speed auto
end
r1#sh run int f0/0.1
Building configuration...
Current configuration : 97 bytes
!
interface FastEthernet0/0.1
encapsulation dot1Q 12
ip address 192.168.1.1 255.255.255.0
end
r2#sh run int f0/1
Building configuration...
Current configuration : 73 bytes
!
interface FastEthernet0/1
no ip address
duplex auto
speed auto
end
r2#sh run int f0/1.1
Building configuration...
Current configuration : 97 bytes
!
interface FastEthernet0/1.1
encapsulation dot1Q 12
ip address 192.168.1.2 255.255.255.0
end
Also preconfigured is the etherchannel between SW1 and SW2. Again, nothing special here, just a simple LACP bundle, and the ports configured for static trunking using 802.1q. Four ports of config is a little long, and I need to work on my usage of show commands, so here's some show commands to illustrate instead!
sw1#sh ether 12 sum | beg Group
Group Port-channel Protocol Ports
------+-------------+-----------+-----------------------------------------------
12 Po12(SU) LACP Fa0/21(P) Fa0/22(P)
sw1#sh int tru
Port Mode Encapsulation Status Native vlan
Po12 on 802.1q trunking 1
Port Vlans allowed on trunk
Po12 1-4094
Port Vlans allowed and active in management domain
Po12 1,99
Port Vlans in spanning tree forwarding state and not pruned
Po12 1,99
sw1#sh cdp nei | b Device
Device ID Local Intrfce Holdtme Capability Platform Port ID
sw2 Fas 0/21 176 S I WS-C3560- Fas 0/19
sw2 Fas 0/22 174 S I WS-C3560- Fas 0/20
sw2#sh ether 12 sum | b Group
Group Port-channel Protocol Ports
------+-------------+-----------+-----------------------------------------------
12 Po12(SU) LACP Fa0/19(P) Fa0/20(P)
sw2#sh int tru
Port Mode Encapsulation Status Native vlan
Po12 on 802.1q trunking 1
Port Vlans allowed on trunk
Po12 1-4094
Port Vlans allowed and active in management domain
Po12 1,99
Port Vlans in spanning tree forwarding state and not pruned
Po12 1,99
sw2#sh cdp nei | b Device
Device ID Local Intrfce Holdtme Capability Platform Port ID
sw1 Fas 0/19 154 S I WS-C3560- Fas 0/21
sw1 Fas 0/20 153 S I WS-C3560- Fas 0/22
Etherchannels... Check!
You'll notice that I've created VLAN 99. I've done that because VLAN 99 is going to be the VLAN that I use as the second 802.1Q tag, also called a Metro tag, for the customer frames that traverse my provider network. How exactly do we do this? We do this with a little hard work, determination, and the following commands (the following commands were entered without any hard work or determination).
First we should start with MTU. The Catalyst 3560's I'm using here have a default system MTU of 1500 bytes.
sw1#sh system mtu
System MTU size is 1500 bytes
System Jumbo MTU size is 1500 bytes
Routing MTU size is 1500 bytes
With the addition of the metro tag we're going to be adding an additional 4 btyes to each frame, so we should increase our MTU accordingly.
sw1(config)#system mtu 1504
With that out of the way we can get to actually making this happen:
SW1
interface FastEthernet0/1
switchport access vlan 99
switchport mode dot1q-tunnel
no cdp enable
end
SW2
interface FastEthernet0/2
switchport access vlan 99
switchport mode dot1q-tunnel
no cdp enable
end
A little underwhelming eh?
We just did two things here. First off we specified an access VLAN of 99. In this context the switchport access vlan defines the tag that we are going to use as our metro tag as frames move across our backbone. If you think about it this effectively is the same mechanism that you're enabling when you're configuring an access port. The difference here is the mode: switchport mode dot1q-tunnel. By enabling this mode we are telling the interface to allow frames that are entering the interface already tagged to be accepted, and tagged again with the value specified by the switchport access vlan command.
A third command is present in the config; CDP is now disabled. That is something that automatically happens when you enable the dot1q tunneling mode.
And now to wow and amaze you...
r1#ping 192.168.1.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms
PING FTW!
To better illustrate what is actually going on here is a packet capture showing the multiple tags.
If you're interested, here's a pcap file of the above ping test that has all the ICMP Echo and Echo Replies with the multiple tags.
https://www.dropbox.com/s/23rjsee7pwxcloh/qinq.pcap
In Part 2 we'll get into doing L2 Protocol tunneling and the fun things you can do there (Hint: the post title).
No comments:
Post a Comment