Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

Untagged packets on native vlan

Hello, it's my first time posting here and I will very much appreciate your kind response guys. I was just wondering how does a switch handle untagged traffic? If an untagged tragfic from a vlan passed through a trunk going to another switch, will the receiving switch forward the untagged traffic to all the ports no matter what vlan they belong to since the traffic has no vlan mark on it? Why or why not? Thanks in advanced. :-)

-dar

16 REPLIES

Hi

Hi

By default the vlan 1 is used as native vlan on the trunks, the native vlan is the one allowed to pass untagged frames between the switches, the rest of the frames will be tagged with their respective vlans to the other end.

Now for security reason the native vlan should be a created vlan for that specific role not used for operations and the vlan 1 should be shutdown. 

VIP Gold

will the receiving switch

will the receiving switch forward the untagged traffic to all the ports no matter what vlan they belong to since the traffic has no vlan mark on it?

No, untagged packets are not considered "packet belonging to no VLAN". And no, they are not subject of special processing like "broadcasted to all ports".

It's less complex than you expect.

On input - untagged packets are considered packets of native VLAN

On output - native VLAN packets are transmitted untagged.

Rest of processing is the same.

Note - native VLAN is per-port (not global) configuration option.


And one more "administration" note. There are so many communities on CSC. You created this discussion in "Additional communities" which is not related to the matter. This thread has been moved by moderators team to appropriate place. 

New Member

Thanks for the answer Sir Dan

Thanks for the answer Sir Dan :-)...and im sorry about the what I've done....I still have a question, upon receipt of untagged frame, how will a switch know which port it will forward the received untagged frame?

VIP Gold

As mentioned already -

As mentioned already - untagged frame is considered packets of the native VLAN.Let consider number of native VLAN to be "default tag" that's apply when there's no explicit tag is present.

The rest of "frame routing" process is exactly the same - for packet tagged as well as for packets untagged (= assigned to particular VLAN by default tag).

Or I'm still missing the matter of your question ?

New Member

Hello sir, i'm getting the

Hello sir, i'm getting the concept clearer and clearer however i still have questions (pardon me). What if I create a native vlan(999) and moved the ports originally from vlan 1 into it. In it, Different ports belong to several vlans (10, 20, 30). All of those ports are using 999 as native vlan. Is that a good practice? Because untagged traffic from vlaj 10 might end up forwarded to vlan 20 and 30?

VIP Gold

Because untagged traffic from

Because untagged traffic from vlaj 10 might end up forwarded to vlan 20 and 30?

No, it can't. You claimed native VLAN to be 999. Thus received packets with no tag are considered VLAN 999 packets.

VLAN x packets are newer fowarded to VLAN y, thus VLAN 999 packets will not be forwarded to neither VLAN 20 nor VLAN 30.

Only those ports belonging to VLAN 999 may forward VLAN 999 packets.

But there still must be a sort of misunderstanding. You mentioned:

untagged traffic from vlan 10

Packet is either tagged as VLAN 10 packet, or it's untaged. No packet can be tagged and untagged at the same time.  Thus, nothing like "untagged packet from vlan 10" can exist.

Super Bronze

Again, don't confuse a

Again, don't confuse a "native VLAN" being provided "special" VLAN forwarding treatment.

The "native VLAN" just allows one particular VLAN's frames to be sent untagged out a trunk, and likewise, when received on a trunk, "identified" as belonging to a particular VLAN.  Other than a native VLAN's frames being untagged, it's processed just as it woud be if its frames were tagged.

Super Bronze

I believe the other posters

I believe the other posters have well answered your questions, but just to say it another way, untagged frames, on a trunk, are still VLAN specific, just like the VLAN tagged frames.  The difference is, unlike the frame's tag indicating the frame's VLAN, the trunk's port configuration determines what VLAN untagged frames belong to.  If a trunk port does not explicitly define the VLAN for untagged frames, it's usually defaulted to VLAN 1.

BTW, if I recall correctly, a Cisco trunk port will accept native VLAN frames either untagged or tagged.

New Member

Thanks joseph :-)....how

Thanks joseph :-)....how should I explicitly define it on a trunk port? Say for example i have vlan 10, 20, and 30 on both switches connected via trunk link.

Super Bronze

Something like:

Something like:

int gig #/#
 switchport
 switchport trunk encapsulation dot1q
 switchport mode trunk
 switchport trunk allowed vlan 10 , 20, 30

VIP Gold

... and native VLAN

... and native VLAN configuration for particular port:

switchport trunk native vlan 999

New Member

If i do that, the 3 vlans

If i do that, the 3 vlans will utilize the same trunk so how can it be vlan specific? Untagged traffic from vlan 10 might end up in vlan 20 since they both use the same trunk and the same native vlan.

Super Bronze

Yes, you're correct, you can

Yes, you're correct, you can mix up VLANs using a native VLAN between different switches.  (Just as you might do with access ports.)

I.e.

If switch 1 has a port configured:

int gig #/#
 switchport
 switchport trunk encapsulation dot1q
 switchport mode trunk
 switchport trunk native vlan 10
 switchport trunk allowed vlan 10 , 20, 30

While it's connected to a switch 2 port configured as:

int gig #/#
 switchport
 switchport trunk encapsulation dot1q
 switchport mode trunk
 switchport trunk native vlan 20
 switchport trunk allowed vlan 10 , 20, 30

The VLAN 10 traffic on switch 1 would be processed as switch 20 traffic on the second switch (and the converse).

However, if CDP is active, it might log messages that the native VLANs differ.

VIP Gold

Note that according Cisco

Note that according Cisco documentation, both ends of trunk line should have same native VLAN configured. It's considered unsupported configuration with undefined behavior to have different native VLANs configured on both ends.

Thus switch is reporting it as configuration error (if it detects such condition).

But in general you are true, with such (forbidden) configuration, VLAN 10 traffic on switch 1 would be processed as switch 20 traffic on the second switch

Super Bronze

Yep, and if I implied I was

Yep, and if I implied I was recommending such a configuration, such was not my intent.

However, to the OP, understand native or tagged VLAN traffic does not get mixed up on the same switch.

Again, keep in mind the access ports can belong to different VLANs and their traffic is also untagged as it goes in and out of a port.  Although it's untagged, it doesn't get mixed up on the same switch.

But, if you interconnect switches using access ports, which you can, like the above, you can have Switch 1 with an access port in VLAN 10 connect to Switch 2 with an access port in VLAN 20.  Again, something you would not normally do, and its also something, I recall, CDP will complain about.

Also to the OP, I don't know if you're familiar with switches that support "voice" VLANs on access ports.  On these ports, you have the "normal" untagged VLAN traffic, but you also have one additional VLAN whose traffic is sent/received with tagged frames.  Basically this is a "special" trunk port, only using two VLANs, one "native".

VIP Gold

OK. It's time to describe

OK. It's time to describe frame processing algorithm in more details. It should help you to understand the processing.

In general, frame is entering the switch (input), then is subject to switching decision process, then it's leaving the switch (output).


Input

There are two modes if input port. Access and trunk.

Input on access mode port

When you configure a port in access mode, you can specify which VLAN will carry the traffic for that interface. Untagged frames received are assigned to such VLAN.

If an access port receives a frame with an 802.1Q tag in the header other than the access VLAN value, that port drops the frame without learning its MAC source address.

Exception: frames tagged for voice VLAN are accepted (if there's tagged voice vlan configured on port)

There must be access vlan configured on every port. If there's no access vlan configured, VLAN1 is assumed.

Related commands:

switchport mode access
switchport access vlan vlan-id
switchport voice vlan ...

Input on trunk mode port

When you configure a port in trunk mode, tagged frames belonging to allowed vlans are accepted. Untagged frames are accepted and assigned to native vlan as configured on such port. Other frames are discarded.

There MUST be native vlan on every port. If there's no native VLAN configured, then VLAN 1 is assumed.

Related commands:

switchport mode trunk
switchport trunk allowed vlan ...
switchport trunk native vlan ...

Frame switching

Note that there are no "untagged frames" possible at this phase. All frames are classified to belong to particular VLAN by input processing.

Frame is submitted for transmission according database of learned MAC.  If the target MAC is not known yet, it's queued to all ports carrying traffic for VLAN in question. 

Exception: frame is never retransmitted back to the port where it has been received from.

Note: Private-VLANs use slightly different frame switching algorithm.

Output

Output on access mode port

Frames are transmitted untagged.

Exception: voice VLAN frame may be transmitted tagged even on access port (if configured).

Output on trunk mode port

Frame belonging to native VLAN (as configured on particular port) is transmitted untagged, other frames are transmitted tagged.


Hope it will help you to understand the switching process.

872
Views
0
Helpful
16
Replies
CreatePlease login to create content