asked on

Two different VLAN's connected by access port

I have two switches. One I don't have control over which is setup with all of it's access ports set to vlan 14.

My switch is using the default vlan of 1.

They network guy before me connected the switches via an access port. vlan 14 on one side and vlan 1 on the other. This situation is working and they share the same subnet 10.89.101.0/24.

I do not like this setup and I need to create more vlan's on trunk ports.

I was under the impression that I could trunk the ports and ask the owner of the other switch to do the same and just set the native vlan to 14, but that does not work.

How can I get vlan 14 on his switch to communicate with my switch on vlan 1 without changing the subnet and getting away from the connected access ports as the uplink? A lot of the devices have static IP set on them that is connected to his switch on access vlan 14. I hope this makes sense.

NOTE: I will eventually be given access to the other switch if that helps with coming up with a solution here. I have two wireless AP's on his switch that I will need to trunk the port they connect to and send that traffic over to my switch which is my ultimate goal here. The important thing is the devices on vlan 14 cannot change their subnet and neither can the devices on my switch which also use the same subnet.

#not_my_switch
#int g1/0/24
#switchport access vlan 14 ---------------> PC1: 10.89.101.10/24
|
|
|
#my_switch
#int g1/0/24
#switchport access ---------------------> PC2: 10.89.101.11/24

Craig Beck

Once you introduce a trunk you also introduce 802.1Q. This tags traffic with the appropriate VLAN ID and that means that all your VLAN1 traffic must be either tagged in VLAN1, or untagged. For this to work the other side of the link must also do the same.

So, if your switchport which links to the other switch is configured like:

int Gi1/0/24
switchport mode access

and the other switchport is configured as:

int Gi1/0/24
switchport mode access
switchport access vlan 14

that will work fine. All traffic on your VLAN1 will just go on far end VLAN14. The cable between the two switches links these broadcast domains together.

If you then want to introduce a trunk you need some synchronization. For a trunk to stay up the native VLAN should be consistent at each end. If one end was a trunk port but the other end wasn't (ie an access port) it could work only for untagged (native) traffic. So,

Your end:

int Gi1/0/24
switchport mode access

Far end:

int Gi1/0/24
switchport trunk encapsulation dot1q
switchport mode trunk
switchport trunk native vlan 14

This would work exactly as you have it now. Traffic from your VLAN1 would go on VLAN14 at the far end.

This wouldn't work though:

Your end:

int Gi1/0/24
switchport trunk encapsulation dot1q
switchport mode trunk
switchport trunk native vlan 1

Far end:

int Gi1/0/24
switchport trunk encapsulation dot1q
switchport mode trunk
switchport trunk native vlan 14

The native VLAN is mismatched.

In your scenario you would need to align the VLAN ID at each end, or the trunk will fail to pass traffic.

ArronG

As already said, it's probably easier for you to change your default vlan to 14 so they are matched and change IP on int vlan14 for your network and remove IP from int vlan1.
Once that's done then the trunk links should be ok and both tagged with right VLAN ID.

lconnell

ASKER

Thanks for the responses. I am using an ASA for my inter-vlan routing at the moment.

int eth0/0
nameif inside
security-level 100
ip address 10.89.101.2 255.255.255.0

int eth0/1
no nameif
no security-level
no ip address

int eth0/1
vlan 16
nameif VOICE
security-level 100
ip address 10.89.16.1 255.255.255.0

I have a lot of nat statements referencing "inside". Can I just add "vlan 14" to that interface or do I have to create the following? I tried removing "nameif inside" and it wouldn't let me.

int eth0/0.14
vlan 14
nameif inside
security-level 100
ip address 10.89.101.2 255.255.255.0

I have a bunch of ESX hosts on my switch, so for this to work I would have to tag the management vlan with 14 and any other connected computers I would set access vlan 14 on the switchports?

SOLUTION

ArronG

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

Craig Beck

Interface names are unique - you can't apply the same interface name to two different interfaces even if they're subinterfaces.

Once you have attached a name to an interface you can't remove it if there are rules associated to it. You can change it though.

lconnell

ASKER

ArronG,

I tried that configuration you mentioned. When I set the trunk between "my_switch" and "their_switch" with native vlan 14, ping worked for two replies and then stopped.

I did not set native vlan 14 on the ASA trunk to "my_switch"

SOLUTION

Craig Beck

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

lconnell

ASKER

Great!

Three more questions and I think I am good :)

1. Can you explain what the native vlan 14 is doing? Doesn't that make sure vlan 14 is not tagged going in and coming out of that trunk? What is the point of it in this situation?

2. Concerning the "trunk allowed" command. Say I have vlan 10,12,13 on my access switch that needs to talk to vlan 14 on the 3rd party switch. I would add those to the trunk allowed. What if the 3rd party switch was using vlan 10,12,13? Is this an issue? Would I just get broadcasts from the 3rd party switch on my trunk? Do the allowed vlans on the trunk have to match on both sides like a native vlan does?

3. If i remove the interface "inside" from e0/0 will that remove my nat's? I know doing that will remove any dhcpd entries if I have any.

Craig Beck

1] Basically the native VLAN tells the switchport to put ingress packets on that VLAN if it doesn't contain an 802.1Q tag. A packet always leaves an access port with no tag - it is already placed onto the correct VLAN. With a trunk port each packet is tagged with the desired VLAN tag on egress. On ingress the packet is placed into whichever VLAN is contained in the tag.

2] You tell the trunk which VLANs to allow, or you can allow all VLANs by default. The allowed VLANs don't have to match at each end, but if you want VLAN14 to be accessible over the trunk it needs to be allowed at both ends. So, at the access switch you might say allow all VLANs, but at the core switch you selectively say which VLANs to allow.

3] Removing the 'inside' interface will remove any NAT/ACL/etc you have tied to that interface.

lconnell

ASKER

so if i have some access ports on vlan 20, and a trunk to another switch, the access ports don't tag the traffic, only when it goes over a trunk so the other switch knows where it belongs?

then if i put native vlan 14 on that trunk, it's going to see the packet is coming from vlan 20, but it is not tagged so then will get put on vlan 14? I'm confused here because the way I'm seeing it, every vlan would go on the native vlan.

if i did change my default vlan to be 14 on the asa, why would i need native vlan 14 on the trunk? they should already be able to talk right?

what is the alternative if i don't want to lose all my nat/acl configurations?

Craig Beck

If you have an access port in VLAN20, all traffic gets put into (or tagged in) VLAN20 on ingress. When traffic on VLAN20 goes out of the port the VLAN tag gets stripped. This is for an access port.

With a trunk port the 802.1Q tag is maintained, unless it's on the native VLAN. When the receiving switch sees the untagged traffic it puts it into the native VLAN on ingress.

if i did change my default vlan to be 14 on the asa, why would i need native vlan 14 on the trunk? they should already be able to talk right?

No, the switch needs to untag the traffic on VLAN14 before it leaves the port. Remember native = untagged.

lconnell

ASKER

Ok, I believe I have found what is causing my confusion about the native vlan and untagged packets. Please correct me if I am wrong.

-a normal access port with vlan 14 will go over the trunk "tagged" as vlan 14

-an access port with voice vlan 16 will go over the trunk "tagged" as vlan 16

-a computer connected to a voice vlan access port will be "untagged"

Now since the traffic is "untagged" I would need to tell the trunk port which vlan it belongs in using "native vlan 14"?

The last piece that I am not sure about is:

-if the access port for the PC's are not tagged, how are they kept separate from any other "untagged" traffic like the native vlan on the switch?

Is this where the switch knows "internally" that it belongs to vlan 14? If I am correct above, I just need the explanation here and I will finally understand it!

Thanks!

ASKER CERTIFIED SOLUTION

Craig Beck

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

lconnell

ASKER

If the traffic is untagged for the access/voice port and the management interface is untagged traffic, wouldn't it be possible to speak with each other? For instance, what if DHCP was configured on the management interface's subnet, the access/voice ports will get DHCP from there?

I would want my voice ports to get DHCP from somewhere else.

Craig Beck

Not quite...

The switch untags traffic when it leaves the port. If the management VLAN is 999 and the user VLAN is 14 it doesn't mean the traffic will go into 999 instead when it gets untagged. It will go in whichever VLAN is the access VLAN.

lconnell

ASKER

I thought the switchport untags traffic coming from the switch to the port, where as traffic coming from the connected device to the switchport gets tagged with the access vlan id?

So even though the vlan is untagged it still will only talk to other access ports in the same vlan, it doesn't have to be tagged? Default VLAN and Native VLAN are different broadcast domains?

Craig Beck

I thought the switchport untags traffic coming from the switch to the port,

Yes that's right. When a packet gets to the switchport from the client the switch tags the packet with the access VLAN ID. When the packet leaves the port to go to the client it is untagged so that the client can receive it.

So even though the vlan is untagged it still will only talk to other access ports in the same vlan, it doesn't have to be tagged? Default VLAN and Native VLAN are different broadcast domains?

The VLAN isn't untagged as such. The switch will always tag it while the packet is 'in' the switch. That's how it knows which VLAN to put the packet on.

lconnell

ASKER

Ok,

How does the switch know what vlan/ports the packet belongs to if the port untags it on egress?

I thought it didn't get untagged until it entered the port of the receiving client. Not when it was leaving the sending client.

As far as a port configured as an access port and a voice port, the voice is tagged, the access traffic should also be tagged until it:

1. leaves the port it originated from?
2. enters the port it is destined for?

My patience would be wearing thin by now, so I really do appreciate you trying to get this through my thick skull!

Craig Beck

Don't mention it - I like to help :-)

How does the switch know what vlan/ports the packet belongs to if the port untags it on egress?

It doesn't need to know once it leaves the port. It only needs to maintain the VLAN tag when sending the packet across a trunk port (so the receiving switch knows which VLAN to place the traffic on).

I thought it didn't get untagged until it entered the port of the receiving client. Not when it was leaving the sending client.

No, the packet gets untagged by the switch (not the client) just before it sends it out of the access port. The client doesn't do VLAN tagging, so there is no tag to remove. The switch receives the untagged packet and puts the VLAN tag on it based on the access VLAN ID configured for that port.

As far as a port configured as an access port and a voice port, the voice is tagged, the access traffic should also be tagged until it:

1. leaves the port it originated from?
2. enters the port it is destined for?

This is a bit confusing for people to get, but the access traffic is untagged even though the voice traffic is tagged.

In short, the switch puts a tag on a packet when it receives one from an access port and strips it when it sends it out of an access port. With a trunk port the tag is untouched. The switch needs to 'see' the tag so it knows which ports it can send the packet out of (especially for broadcast traffic), but the clients don't.

lconnell

ASKER

I'm back! lol

. An access port will tag the traffic coming from the client.

. Before it leaves the access port, it is stripped, however at this point the switch knows which other access ports it's allowed to broadcast/communicate with? If the frame is being sent over a trunk it is "re-tagged"?

. If the frame is being sent to another access port on the switch the frame is already untagged, however the switch "somehow" knows which ports it can communicate with?

I'm confused on the fact the frame is stripped of it's tag, yet the switch still knows what to do with it.

Yours truly,

BrainDead & Foggy

Craig Beck

If the frame is being sent to another access port on the switch the frame is already untagged, however the switch "somehow" knows which ports it can communicate with?

When the packet leaves the port to get to the client it is stripped of its VLAN tag. When the client sends the packet back to the switch the packet is tagged with the VLAN ID which is configured in the switchport access vlan x command so it knows which other ports are on the same VLAN as the sending client.

If the frame is being sent over a trunk it is "re-tagged"?

The packet is never untagged while it remains 'in' the switch. If a client sends a packet to a host on a different switch it is tagged when it enters the switch. The tag remains on the packet while it traverses the trunk link and up to the point it gets to the access port where the receiver is connected, then it is untagged before it gets to the receiver as it leaves the port.

If the frame is being sent to another access port on the switch the frame is already untagged, however the switch "somehow" knows which ports it can communicate with?

As I said in the first paragraph. The client sends a packet. When it comes into the switch the packet is tagged according to the switchport access vlan x command on the sender's port. It keeps the tag until it leaves the port where the receiver is located. No magic involved :-)

lconnell

ASKER

Client1 -> [P1] -> switchport access vlan 10
Client2 -> [P2] -> switchport access vlan 10

. Client1 sends data to Client2
.Packet is tagged with vlan 10 when it enters [P1].
.Packet leaves Client1[P1] to enter Client2[P2]. UNTAGGED
.Packet enters Client2[P2] UNTAGGED

Is that right? You said the tag is stripped before it leaves the sending port, then you said it keeps the tag until the packet leaves the port of the receiving client?? Still confused on that part.

Here's another separate issue I'm having :) L3 Inter-VLAN Routing

Craig Beck

Yes that's right. Between leaving the switchport and getting to the client the packet is untagged - the client doesn't usually know about 802.1Q.

The sending client sends the packet. It is untagged until it hits the switch's receiving switchport. When it enters the switch it is tagged with the access vlan ID which is configured on the port that it came in on. While the packet is 'in' the switch It will keep the tag so the switch knows which VLAN it is supposed to be on. When the switch decides which port to send the packet out of it strips the VLAN tag before putting the packet on the wire. Therefore the packet is on the right port (where only one recipient exists) and goes to the right place.

lconnell

ASKER

Ok I get it :). I was getting confused with the sending/receiving port. Very simple actually :)

So it hits the trunk tagged and the trunk does not strip that tag. thanks!

Craig Beck

That's it! :-)