Intenet Access with Dot1q Tunnel

Is there a way to provide internet service over a dot1q tunnel using VLAN tunneling? Yes, there is a way, it is not the most intuitive method but works nicely. Basically it has to do with what does the switch do with untagged frames when they arrive on a tunnel port. In this configuration, the untagged frames (native VLAN 200) are not tunneled but go to the routed interface for processing. As long as the provider’s switches has a routed interface for the customer ID VLAN and a default route, traffic should reach the Internet.

To explain this, I’ll use a basic topology with 4 switches and one router. SW1 and SW2 are service provider switches, with their interfaces Fa0/21 configured as dot1q-tunnels using access VLAN 100. SW3 and SW4 are customer switches and R1 is acting as the service-providers internet edge router.

 

Internet Access with Dot1q Tunnel
Service provider’s switches SW1 and SW2 relevant configuration:

interface FastEthernet0/21
 switchport access vlan 100
 switchport trunk encapsulation dot1q
 switchport mode dot1q-tunnel
 no cdp enable

Customer ID is VLAN 100 and the port fa0/21 is set to mode dot1q-tunnel.

Customer Site A’s SW3 relevant configuration:

interface FastEthernet0/21
 switchport trunk encapsulation dot1q
 switchport trunk native vlan 200
 switchport mode trunk
interface Vlan200
 ip address 10.200.3.3 255.255.0.0

Customer Site B’s SW4 relevant configuration:

interface FastEthernet0/21
 switchport trunk encapsulation dot1q
 switchport trunk native vlan 200
 switchport mode trunk
interface Vlan200
 ip address 10.200.4.4 255.255.0.0

One command that stands out on the customer switches is theĀ native VLAN 200. It forwards frames on VLAN 200 without a dot1q tag. These untagged frames will be routed on the service provide switches and won’t be encapsulated.

You can verify end to end tunneling with a simple ping from CE SW3 to CE SW4’s IP address 10.200.4.4 using the VLAN200 interface.

sw3#ping 10.200.4.4

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

I will create VLAN100 interface on the service provider’s SW1. This SVI will be on VLAN 100 and not on the native VLAN 200. VLAN 100 is the metro tag added by the tunnel, while VLAN 200 is the VLAN interface on SW3. By adding a routed interface for the customer’s ID VLAN, SW1 will be able to route their traffic without tunneling it.

interface Vlan100
 ip address 10.200.1.1 255.255.0.0

Verify that this new interface is accessible from customer SW3 (interface VLAN100):

sw3#ping 10.200.1.1

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

What we were able to accomplish is allow the customer’s switch (SW3) to access the service provider’s switch (SW1) which should only be tunneling, but in this case it is able to respond back. It is expecting tagged frames, any un-tagged frames are processed by the device, which in this case they could be routed to R1.

Additional Notes:

– Make sure to include static or dynamic routes, which are not depicted here for simplicity.
– On the customer side, the VLAN interface has to be on the same VLAN as its native VLAN. In my example this was interface VLAN200 with IP address 10.200.3.3/16
– On the provider side, the metro VLAN (customer ID) should have the VLAN interface configured, as it processes the untagged frames. In my example that’s 10.200.1.1/16.
– When configuring dynamic protocols, make sure to watch out for MTU issues, especially with OSPF. The SW1 has a higher system MTU because of the configured dot1q-tunnel (1504 Bytes), than SW3 which by default is set to 1500 Bytes.
– This works on a Catalyst 3560, I have not tested it on any other models. Please let me know if you do.