Solved

Two different VLAN's connected by access port

Posted on 2014-02-05
25
4,994 Views
Last Modified: 2014-03-18
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
0
Comment
Question by:lconnell
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 12
  • 11
  • 2
25 Comments
 
LVL 46

Expert Comment

by:Craig Beck
ID: 39835186
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.
0
 
LVL 3

Expert Comment

by:ArronG
ID: 39835798
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.
0
 

Author Comment

by:lconnell
ID: 39836401
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?
0
Get 15 Days FREE Full-Featured Trial

Benefit from a mission critical IT monitoring with Monitis Premium or get it FREE for your entry level monitoring needs.
-Over 200,000 users
-More than 300,000 websites monitored
-Used in 197 countries
-Recommended by 98% of users

 
LVL 3

Assisted Solution

by:ArronG
ArronG earned 100 total points
ID: 39836729
on the trunk uplink to 'other switch' AND to your ASA
switch mode trunk
switch trunk native vlan 14

on your access ports:-
switch access vlan 14
switchport voice vlan 16

don't remove the nameif from eth0/0, not a good idea, and the ASA shouldn't let you do this.
sub interface 0.14 for vlan 14 is good as per your config.
0
 
LVL 46

Expert Comment

by:Craig Beck
ID: 39837058
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.
0
 

Author Comment

by:lconnell
ID: 39837112
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"
0
 
LVL 46

Assisted Solution

by:Craig Beck
Craig Beck earned 400 total points
ID: 39837206
If you want you can do this on the ASA, although you may need to edit the config in a text editor and upload it to the ASA then do a reload...

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

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

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

Open in new window


This on the 3rd-party switch...

interface GigabitEthernet4/21
 switchport
 switchport trunk encapsulation dot1q
 switchport mode trunk
 switchport trunk allowed vlan 14,16
 switchport trunk native vlan 14

Open in new window


As ArronG said... on your access switch uplink...

interface GigabitEthernet1/1
 switchport
 switchport trunk encapsulation dot1q
 switchport mode trunk
 switchport trunk allowed vlan 14,16
 switchport trunk native vlan 14

Open in new window


On your access switch user ports...

interface GigabitEthernet0/1
 switchport mode access
 switchport access vlan 14
 switchport voice vlan 16
 spanning-tree portfast

Open in new window

0
 

Author Comment

by:lconnell
ID: 39837269
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.
0
 
LVL 46

Expert Comment

by:Craig Beck
ID: 39837319
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.
0
 

Author Comment

by:lconnell
ID: 39837497
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?
0
 
LVL 46

Expert Comment

by:Craig Beck
ID: 39837501
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.
0
 

Author Comment

by:lconnell
ID: 39837777
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!
0
 
LVL 46

Accepted Solution

by:
Craig Beck earned 400 total points
ID: 39840380
-a normal access port with vlan 14 will go over the trunk "tagged" as vlan 14
Correct, if VLAN14 isn't the native VLAN.
-an access port with voice vlan 16 will go over the trunk "tagged" as vlan 16
Correct, if VLAN16 isn't the native VLAN.
-a computer connected to a voice vlan access port will be "untagged"
Correct.  A computer will use the access VLAN, while a phone will use the voice VLAN.
Now since the traffic is "untagged" I would need to tell the trunk port which vlan it belongs in using "native vlan 14"?
Correct
-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?
This is where your misunderstanding lies.  The 'switch' doesn't have a native VLAN, but rather each port has a native VLAN.  It is entirely possible to create two trunks on the switch, each using a different native VLAN.

The switch itself only belongs to a VLAN when a management interface is configured.  In the case of a layer-2 switch the management VLAN is the only VLAN which can have an IP address configured.  With a layer-3 switch you can configure multiple IP addresses on multiple VLANs for the purpose of routing.  This means the switch would 'belong' to multiple VLANs and could be managed (by default) on any of its configured IP addresses.
0
 

Author Comment

by:lconnell
ID: 39844883
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.
0
 
LVL 46

Expert Comment

by:Craig Beck
ID: 39845191
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.
0
 

Author Comment

by:lconnell
ID: 39846458
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?
0
 
LVL 46

Expert Comment

by:Craig Beck
ID: 39846897
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.
0
 

Author Comment

by:lconnell
ID: 39848899
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!
0
 
LVL 46

Expert Comment

by:Craig Beck
ID: 39849587
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.
0
 

Author Comment

by:lconnell
ID: 39902010
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
0
 
LVL 46

Expert Comment

by:Craig Beck
ID: 39902885
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 :-)
0
 

Author Comment

by:lconnell
ID: 39936067
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
0
 
LVL 46

Expert Comment

by:Craig Beck
ID: 39936639
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.
0
 

Author Comment

by:lconnell
ID: 39936851
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!
0
 
LVL 46

Expert Comment

by:Craig Beck
ID: 39937772
That's it! :-)
1

Featured Post

Manage your data center from practically anywhere

The KN8164V features HD resolution of 1920 x 1200, FIPS 140-2 with level 1 security standards and virtual media transmissions at twice the speed. Built for reliability, the KN series provides local console and remote over IP access, ensuring 24/7 availability to all servers.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

For months I had no idea how to 'discover' the IP address of the other end of a link (without asking someone who knows), and it drove me batty. Think about it. You can't use Cisco Discovery Protocol (CDP) because it's not implemented on the ASAs.…
WARNING:   If you follow the instructions here, you will wipe out your VTP and VLAN configurations.  Make sure you have backed up your switch!!! I recently had some issues with a few low-end Cisco routers (RV325) and I opened a case with Cisco TA…
Both in life and business – not all partnerships are created equal. As the demand for cloud services increases, so do the number of self-proclaimed cloud partners. Asking the right questions up front in the partnership, will enable both parties …
Both in life and business – not all partnerships are created equal. Spend 30 short minutes with us to learn:   • Key questions to ask when considering a partnership to accelerate your business into the cloud • Pitfalls and mistakes other partners…
Suggested Courses
Course of the Month9 days, 5 hours left to enroll

615 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question