These two 3750's are for different customers, but they have one common network (10.74.13.0/24), but one of the customers set this network up as VLAN33 and the other set it up as VLAN100. So I want to setup a trunk which rewrites VLAN33 to VLAN100 from one switch to another (if you understand what I mean). Ill put up a jpg of the network setup to explain better.

Cheers

Vidar,

Just recreated what you want to do and you don't need to set a trunk. Just create a regular access switchport on both ends. CDP will complain about the mismatch but it works.

Here is my config

(On Switch with Vlan 33).

sh run int vlan 33

interface Vlan33

ip address 10.74.13.251 255.255.255.0

sh run int f0/13

interface FastEthernet0/13

switchport access vlan 33

switchport mode access

(On Switch with Vlan 100)

sh run int vlan 100

interface Vlan100

ip address 10.74.13.250 255.255.255.0

sh run int f0/13

interface FastEthernet0/13

switchport access vlan 100

switchport mode access

__________

This is the message you get from CDP

%CDP-4-NATIVE_VLAN_MISMATCH: Native VLAN mismatch discovered on FastEthernet0/13 (100), with xxxxxx FastEthernet0/13 (33).

You can disable CDP on those interfaces if you want to avoid this message.

_________

Pinging test

sh ip int bri | ex una

Interface IP-Address OK? Method Status Protocol

Vlan100 10.74.13.250 YES manual up up

xxxxxxx#ping 10.74.13.251

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.74.13.251, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/9 ms

sh ip int bri | in Vlan33

Vlan33 10.74.13.251 YES manual up up

xxxxx#ping 10.74.13.250

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.74.13.250, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

HTH,

__

Edison.

Hi Vidar,

An awsome example from Edison.

This is called as vlan leakage. When traffic goes out of access port it does not carry vlan information so in above setup also when traffic will pass from access port which is for vlan 33 it will not carry any vlan information and when it hits the other switch on access port 100 it will be a part of vlan 100 from there onwards. Sam will hold true vice versa.

HTH

Ankur

ok edison, this works. but if you have an other vlan spanning the 2 switches, users from different switches in this vlan, can't see each other. so in this case i think there is no solution using trunking.

Oussama,

I don't understand what you are trying to say. Can you expand a bit?

i mean:

in this senario we have vlan33 in switch1 and vlan100 in switch2, they can communicate together using a simple cascade. but if we have in addition, vlan5 in switch1 and switch2. so i think it is impossible to make:

-users in vlan5 communicate

-users in vlan33/vlan100 communicate

using a trunk port (.1q/isl)

Correct. You can always use another switchport :)

Kevin,

Good idea in theory, I'm afraid it does not work in practice.

On the switch holding Vlan33

Fa0/13 on 802.1q trunking 33

interface FastEthernet0/13

switchport trunk encapsulation dot1q

switchport trunk native vlan 33

switchport mode trunk

interface Vlan33

ip address 10.74.13.251 255.255.255.0

On the switch holding Vlan 100

Fa0/13 on 802.1q trunking 100

interface FastEthernet0/13

switchport trunk encapsulation dot1q

switchport trunk native vlan 100

switchport mode trunk

interface Vlan100

ip address 10.74.13.250 255.255.255.0

Pinging from this switch

sw2#ping 10.74.13.251

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.74.13.251, timeout is 2 seconds:

.....

Success rate is 0 percent (0/5)

Pinging from the remote switch:

sw1#ping 10.74.13.250

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.74.13.250, timeout is 2 seconds:

.....

Success rate is 0 percent (0/5)

___

CDP Errors:

%CDP-4-NATIVE_VLAN_MISMATCH: Native VLAN mismatch discovered on FastEthernet0/13 (33), with sw2 FastEthernet0/13 (100)

__

Therefore, you can't do Vlan propagation with trunk ports, you must employ access ports.

HTH,

__

Edison.

Edison,

(Ooops, forgot the attachments! Please see next posting.)

Edison,

You can get it to work, but it is a bit of a struggle.

The first problem I encountered was that the Spanning Tree would shut the port down because of the PVST+ BPDU received untagged for the wrong VLAN. So I filtered the BPDUs.

Next step is to be absolutely sure that there are no other trunk links between the switches. (Actually, that should have been the first step - lucky it wasn't a production network ;-)

Then just to be on the safe side, on each end of the trunk I disallowed the VLAN that the other side was using as native. In fact, I allowed only the local native VLAN, and VLAN 5 for testing.

Here are my results attached.

Kevin Dorrell

Luxembourg

I had some further thoughts on this. These are just for the fun of thinking it through.

On each side of the trunk, I had disallowed the VLAN that the other side was using as native. That should not affect the operation, because each side is just processing untagged frames as if they were on the local native. Each side has no idea that the other side is using a different native.

I wanted to consider whether it was really necessary to disallow the other side's native. I don't think is is necessary. Provided there are no loops in either VLAN, I don't see why we shouldn't have both VLANs permeating both sides of the link.

At first I thought that would also ease migration to a cleaner architecture. The argument was that then it does not matter whether a host is on VLAN 33 or VLAN 100, on either side of the divide, so you could migrate them one at a time. However, there is a snag to that migration plan - a host on VLAN 33 on CAT1 will not talk to a host on VLAN 100 on the same CAT1. That is because the traffic would traverse the trunk on VLAN 33, and would be picked up by CAT 2 on VLAN 100, but would not get sent back on the port it arrived on. So for that migration, the better scenario would be one with the access link to do the hopping, plus a trunk link to do the rest.

Interesting how my switches each believe they are root for each VLAN. That is becase I broke Spanning Tree on the trunk link. Its a pity you cannot do bpdufilter selectively per VLAN! Nevertheless, the scenario still works.

Of course, there is another completely different solution to all this: a router configured with a vlan-bridge between VLAN 33 and VLAN 100, and let both VLANs permeate both boxes.

Kevin Dorrell

Luxembourg