Solved

Two different VLAN's connected by access port

Posted on 2014-02-05
25
3,955 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
  • 12
  • 11
  • 2
25 Comments
 
LVL 45

Expert Comment

by:Craig Beck
Comment Utility
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
Comment Utility
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
Comment Utility
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
 
LVL 3

Assisted Solution

by:ArronG
ArronG earned 100 total points
Comment Utility
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 45

Expert Comment

by:Craig Beck
Comment Utility
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
Comment Utility
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 45

Assisted Solution

by:Craig Beck
Craig Beck earned 400 total points
Comment Utility
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
Comment Utility
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 45

Expert Comment

by:Craig Beck
Comment Utility
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
Comment Utility
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 45

Expert Comment

by:Craig Beck
Comment Utility
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
Comment Utility
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
Why You Should Analyze Threat Actor TTPs

After years of analyzing threat actor behavior, it’s become clear that at any given time there are specific tactics, techniques, and procedures (TTPs) that are particularly prevalent. By analyzing and understanding these TTPs, you can dramatically enhance your security program.

 
LVL 45

Accepted Solution

by:
Craig Beck earned 400 total points
Comment Utility
-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
Comment Utility
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 45

Expert Comment

by:Craig Beck
Comment Utility
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
Comment Utility
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 45

Expert Comment

by:Craig Beck
Comment Utility
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
Comment Utility
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 45

Expert Comment

by:Craig Beck
Comment Utility
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
Comment Utility
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 45

Expert Comment

by:Craig Beck
Comment Utility
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
Comment Utility
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 45

Expert Comment

by:Craig Beck
Comment Utility
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
Comment Utility
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 45

Expert Comment

by:Craig Beck
Comment Utility
That's it! :-)
0

Featured Post

IT, Stop Being Called Into Every Meeting

Highfive is so simple that setting up every meeting room takes just minutes and every employee will be able to start or join a call from any room with ease. Never be called into a meeting just to get it started again. This is how video conferencing should work!

Join & Write a Comment

Suggested Solutions

Title # Comments Views Activity
Cisco Switch Password ---Urgent 3 37
Extending  a subnet 9 34
Cisco ASA5508-X vs Barracuda X200 2 21
cisco nexus experiance 2 27
Cisco Pix/ASA hairpinning The term, hairpinning, comes from the fact that the traffic comes from one source into a router or similar device, makes a U-turn, and goes back the same way it came. Visualize this and you will see something that looks …
Overview The Cisco PIX 501, PIX 506e, ASA 5505 and ASA 5510 (most if not all of this information will be relevant to the PIX 515e but I do not have a working configuration handy to verify the validity) are primarily used within small to medium busi…
When you create an app prototype with Adobe XD, you can insert system screens -- sharing or Control Center, for example -- with just a few clicks. This video shows you how. You can take the full course on Experts Exchange at http://bit.ly/XDcourse.
You have products, that come in variants and want to set different prices for them? Watch this micro tutorial that describes how to configure prices for Magento super attributes. Assigning simple products to configurable: We assigned simple products…

762 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

Need Help in Real-Time?

Connect with top rated Experts

10 Experts available now in Live!

Get 1:1 Help Now