native VLANs

I am reading the ICND2 Cisco Press book and don't understand a couple things about native VLANs. Hopefully someone can help me out. The book says:

"When the switch on the other side of the trunk receives a frame that does not have an 802.1Q header, the receiving switch knows that the frame is part of the native VLAN. Note that because of this behavior, both switches must agree which VLAN is the native VLAN."

1. So, let's say an unmanaged switch is connected to that trunk port. That switch will get frames that are tagged and untagged. Will the unmanaged switch simply drop the tagged frames?

2. I'm guessing that if you have more than one trunk port on a switch they would all have to have the same native VLAN, correct?

3. What happens if you connect an unmanaged switch to an access port? I would guess frames arriving in that switchport would be tagged if it wasn't an access port of the native VLAN. So, wouldn't it be better to create an access port that's in the native VLAN and connect it to the unmanaged switch? It seems like it would eliminate all the dropped frames that I'm suspecting from question 1.

Thanks.

Find more posts tagged with

Save $250 on 2025 certification boot camps from Infosec!

Book now with code EOY2025

Button

Comments

tim100

snickered wrote: »

I am reading the ICND2 Cisco Press book and don't understand a couple things about native VLANs. Hopefully someone can help me out. The book says:

"When the switch on the other side of the trunk receives a frame that does not have an 802.1Q header, the receiving switch knows that the frame is part of the native VLAN. Note that because of this behavior, both switches must agree which VLAN is the native VLAN."

1. So, let's say an unmanaged switch is connected to that trunk port. That switch will get frames that are tagged and untagged. Will the unmanaged switch simply drop the tagged frames?

Unmanaged switches are usually just basic switches that don't have any of the capabalities of a managed switch. An unmanaged switch's ports are all access ports and there is no VLAN. They are all under one broadcast domain. If an unmanaged switch is connected to that trunk port then yes the ummanaged switch will drop tagged frames and only process untagged frames. So basically the unmanaged switch will only be able to communicate with any other access port that is a member of the native VLAN on that trunk port. This is not a common practice.

snickered wrote: »

2. I'm guessing that if you have more than one trunk port on a switch they would all have to have the same native VLAN, correct?

snickered wrote: »

3. What happens if you connect an unmanaged switch to an access port? I would guess frames arriving in that switchport would be tagged if it wasn't an access port of the native VLAN. So, wouldn't it be better to create an access port that's in the native VLAN and connect it to the unmanaged switch? It seems like it would eliminate all the dropped frames that I'm suspecting from question 1.

If you connect an unmanaged switch to an access port then any device connected to the unmanaged switch will be able to communicate with any device in the VLAN that port is a member of.

LBC90805

Tim, you mean you can have different native VLANs per trunk? Would imagine that is beyond the scope of the CCNA exam!

Also an unmanaged switch would just drop baby giant frames. 1500 + 4, for that DOT1Q tag, byte frames.

tim100

LBC90805 wrote: »

Tim, you mean you can have different native VLANs per trunk?

Yes, you can have one trunk between two switches with let's say Native VLAN 1 and another trunk between the two switches with Native VLAN 2.

snickered

tim100, you say:

"Yes, you can have one trunk between two switches with let's say Native VLAN 1 and another trunk between the two switches with Native VLAN 2."

This confuses me terribly. I think I'm confused on the "order of operations" when tagging. I was under the impression that frames were tagged upon arriving at a switchport. But this can't be true with what you said.

It must be that switches are intelligent enough to determine when to tag and when not to tag based on the trunk port. Here's a scenario...

int fa0/1
switchport mode access
switchport access vlan 2

int fa0/2
switchport mode access
switchport access vlan 3

int fa0/23
switchport mode trunk
switchport trunk native vlan 3

int fa0/24
switchport mode trunk
switchport trunk native vlan 2

Let's say ComputerA is connected to fa0/1 and ComputerB is connected to fa0/2.

1. ComputerA sends a broadcast frame.
2. The switch tags the frame and doesn't tag the frame.
3. The switch sends the tagged frame out fa0/23.
4. The switch sends the untagged frame out fa0/24.

and it would be reversed in ComputerB's situation:

1. ComputerB sends a broadcast frame.
2. The switch tags the frame and doesn't tag the frame.
3. The switch sends the tagged frame out fa0/24.
4. The switch sends the untagged frame out fa0/23.

Is this how it would work? Thanks.

tim100

snickered wrote: »

tim100, you say:

This confuses me terribly. I think I'm confused on the "order of operations" when tagging. I was under the impression that frames were tagged upon arriving at a switchport. But this can't be true with what you said.

It must be that switches are intelligent enough to determine when to tag and when not to tag based on the trunk port. Here's a scenario...

int fa0/1
switchport mode access
switchport access vlan 2

int fa0/2
switchport mode access
switchport access vlan 3

int fa0/23
switchport mode trunk
switchport trunk native vlan 3

int fa0/24
switchport mode trunk
switchport trunk native vlan 2

Let's say ComputerA is connected to fa0/1 and ComputerB is connected to fa0/2.

1. ComputerA sends a broadcast frame.
2. The switch tags the frame and doesn't tag the frame.
3. The switch sends the tagged frame out fa0/23.
4. The switch sends the untagged frame out fa0/24.

and it would be reversed in ComputerB's situation:

1. ComputerB sends a broadcast frame.
2. The switch tags the frame and doesn't tag the frame.
3. The switch sends the tagged frame out fa0/24.
4. The switch sends the untagged frame out fa0/23.

Is this how it would work? Thanks.

You've got it somewhat correct. First get rid of #2 in your order of operations. for #3 in your scenarios, the switch tags the frame on egress. For #4 the switch sends the frame untagged.

snickered

So, it tags it on egress. That's what I was missing. Thanks a lot. It's clear now.

kryolla

Below is from Cisco Docs. Since both native vlans have to match on the trunk link or else you get a spanning-tree error the egress switch will send the frame untagged and the receiving switch will look at the PVID assigned from trunk native vlan command and assign it to that vlan.

"Each physical port has a parameter called PVID. Every 802.1Q port is assigned a PVID value that is of its native VLAN ID (default is VLAN 1). All untagged frames are assigned to the LAN specified in the PVID parameter. When a tagged frame is received by a port, the tag is respected. If the frame is untagged, the value contained in the PVID is considered as a tag."

snickered

tim100 wrote: »

unmanaged switches are usually just basic switches that don't have any of the capabalities of a managed switch. An unmanaged switch's ports are all access ports and there is no vlan. They are all under one broadcast domain. If an unmanaged switch is connected to that trunk port then yes the ummanaged switch will drop tagged frames and only process untagged frames. So basically the unmanaged switch will only be able to communicate with any other access port that is a member of the native vlan on that trunk port. This is not a common practice.

So, does this mean it is common practice to connect an unmanaged switch to an access port instead?

kryolla

well if a unmanaged switch does not understand trunking protocol then yes just hook it to an access port

snickered

I know it seemed like a silly question but the ICND2 Cisco Press book says:

The 802.1Q native VLAN provides some interesting functions, mainly to support connections to devices that do not understand trunking. For example, a Cisco switch could be cabled to a switch that does not understand 802.1Q trunking. The switch could send frames in the native VLAN--Meaning that the frame has no trunking header--so the other switch would understand the frame.

But in the field no one uses it like this because it creates overhead for the attached switch (dropping frames) so it would be just as good to connect it to an access port. I'm looking for a good application of native VLAN. Other than a case where you don't use the default native VLAN in your environment.