dot1q tunnel problem

t-andrews · ‎06-26-2008

Our ISP is delivering our traffic on a single metro ethernet link. This comes directly into G0/1 on our 3560G. G0/1 is a trunk port and allows vlans 202,210 and 285.

As part of a QnQ experiment, they are sending vlan 285 as a dot1q tunnel. So G0/1 picks that up and G0/23 is set up in dot1q tunnel mode (vlan 285) and I simply looped a cable from that port to port G0/22 on the switch. G0/22 is set up as a trunk port and allows the only vlan we are trying to encapsulate across the tunnel... vlan 300.

So a workstation at the remote site is attached to a switch in vlan 300. That traffic goes to our ISP, who encapsulates that traffic in vlan 285 and sends it out on the network. The traffic is picked up by my 3560, passed to port 23, and is then passed to vlan 300.

The host at the remote site was able to pick up an ip address from the server at my end... and we can see its MAC address in the table on the 3560, but we cannot seem to get traffic to route either direction.

I think the problem is that when we look up the MAC address of the device at the remote end, it shows up in vlan 285 on port 0/1 and in vlan 300 on port 0/22. Nothing shows up on port 0/23 where we would have expected it. I'm not sure how we would get traffic destined for the other side on vlan 300 to go to the tunnel on port 0/23 to get encapsulated and sent back out to our ISP

Config:

vtp mode transparent

spanning-tree mode rapid-pvst

spanning-tree extend system-id

no spanning-tree vlan 210

!

vlan internal allocation policy ascending

!

vlan 202,210

!

vlan 278

name HoraceMay

!

vlan 280,285,300

interface GigabitEthernet0/1

description Metro Ethernet

switchport trunk encapsulation dot1q

switchport trunk allowed vlan 202,210,278,285

switchport mode trunk

interface GigabitEthernet0/22

description to Tunnel 285

switchport trunk encapsulation dot1q

switchport trunk native vlan 202

switchport trunk allowed vlan 202,280,300

switchport mode trunk

!

interface GigabitEthernet0/23

description VLAN Tunnel 285

switchport access vlan 285

switchport mode dot1q-tunnel

no cdp enable

interface Vlan300

ip address 10.61.0.1 255.255.0.0

ip helper-address 10.2.0.216

Thoughts appreciated.

n.nandrekar · ‎06-26-2008

hi!

What you see is the right behaviour!!! Port gi0/23 wont learn the macadress of the remote device as the traffic is sent out on that port (and not recieved on that port). The remote PC frame is first recieved on GI0/1 on vlan 285. So the mac is learnt on gi0/1 on vlan 285. The frame is then sent on gi0/22 with only vlan 300(inner tag). So the mac address is not learnt here as the frame is sent out... and not recieved.

Then the port gi0/23 recieves the frame tagged with 300 and so it learns the mac address on vlan 300.

And since you are able to get an IP address from the DHCP server, the path seems to work fine. There could be different problems for the "routing does not seem to be working".

For this, can you give me the exact details of how you are trying to route traffic ( I mean source IP / destimation IP and how they are connected?

Regards,

Niranjan

t-andrews · ‎06-27-2008

Thanks for the reply.

As indicated in the config, subnet 10.61.0.0/16 is attached to vlan 300, which has the ip address 10.61.0.1. The helper address 10.2.0.216 is the dhcp server sitting on a port on the same switch (vlan 202).

So a "show ip route" indicates that subnet 10.61.0.0/16 is directly connected to vlan 300, 10.2.0.0/16 is directly connected to vlan 202.

The dhcp scope is set up in the 10.61.11.0 - 10.61.12.255 range and supplies 10.61.0.1 as the gateway along with dns information.

This is where I was puzzled. The workstation at the remote site picked up ip address 10.61.11.1 no problem... yet I am unable to ping that workstation from anywhere at the local end and cannot ping even the 10.61.0.1 gateway from the remote workstation.

Tony

n.nandrekar · ‎06-27-2008

Hi Tony,

I am not sure but just trying to think about the reason which might give you a direction...

I dont think that the solution of looping back physically might work correctly. This is because, assume that the remote pc has sent a icmp request. So the frame will come in with the destination mac as the "interface vlan300" mac address. This is its own mac. The way 6500 decides to L2 switch the frame or to route it depends on the destination mac address of the frame.

If the destimation mac is not router-mac (its own mac), then it forwards the frame using the l2 engine. If the destination mac is its own mac, then it passes to that L3 interface and the L3 engine takes over.

So in your scenario, when the mac frame comes in on gi0/1 on vlan 285, the 6500 doesnt forward it through gi0/22 but rather sends it to the L3 engine since its his own mac.

I am not sure what would happen after this, as the frame is still considered to be in vlan 285. so either

a>>> the frame is dropped because of the second tag still present, or

b>>> routed on wrong vlan ... or

something else.. I dont know,. But in any case, It wont work.

The explaintion for your ip address getting picked could be explained by the fact that the whole process would work on broadcast. The helper ip makes it a single broadcast domain and the router ip is never seen in the destination mac in any of the process.

The same would apply for ARP. I wouldne be surprized to find that the remote PC has learnt the correct arp for gateway and also sends the packets.

This makes better sense .. and i guess I worked it out while writing the solution ;)

Regards,

Niranjan