Ethernet Vlan-aware switch query.

It's not clear to me if you're writing the switch code for a new device or trying to anticipate what the correct behavior is for an off-the-shelf device you have in hand is.

Either way, I think the answer is, "It depends." Some switches will revert to a port-based "VLAN" and route the packet based on the ingress port's membership in a port group. Others will drop it. I think some will flood the frame (or direct it if the destination MAC is known). Some have security settings that let you choose between those behaviors.

In article , dilip snipped-for-privacy@hotmail.com wrote: :I am working with ethernet-switch i have query regarding VLAN.

:Ethernet switch supports shared VLAN feature. :Let say in-comming packet to any port is vlan-tagged packet. :First, destination address lookup will be perform. :Secondly Vlan-lookup will be perform based on current tag.

There are two possible modes of operation: single spanning tree and per-vlan spanning tree. In the per-vlan spanning tree mode, the lookup would happen in the other order, VLAN first and then destination MAC within that.

:but,if this tag with current packet is not program in the VLAN-table, i :mean to say this tag is new for the switch. :So, switch can not able to find that which port are the member of this :vlan-tag.

:In this case, what switch should do ? :1)Drop the packet ?

You mention "shared" VLAN. The dynamic VLAN membership services, such as Cisco's VMPS, are "push" technologies: until a switch has been notified to know about a VLAN, the VLAN effectively doesn't exist. In such a case, the switch should really drop the packet, but there are often overrides available for that behaviour.

this is the wrong way around for many switches.

modern switches tend to allow the same MAC address to occur in different VLANs - this allows a network to include multiple instances of the same well known MAC, bridging between VLANs, or devices with multiple interfaces where the MAC is the same.

if it is an unknown MAC, then it probably goes to the CPU anyway - but you should drop the packet since there isnt anywhere you can usefuly send it unless you have some sort of "any VLAN allowed" setting for a port.

Doing anything else makes it possible for someone who can craft an arbitary packet to get it to cross between VLANs - there are enough security issues around without inventing extra ones......

since the drop is a misconfiguration issue the switch should possibly log the event as an error somewhere.

If the VLAN tag is one that the switch hasn't seen before, it means it doesn't have a untagged/tagged membership set associated with that VLAN yet. In that case, if the switch has ingress filtering enabled, it will drop the packet there (because the ingress port is not part of the VLAN's membership). If the switch does not have ingress filtering on, then the frame will make it through the learning process and that MAC address will get learned on the port that it came in on. However, when it is forwarded and the egress port (or ports) do a lookup to determine if the port is in the member set for that VLAN, the frame will end up getting drop.

In other words, if the VLAN is new to the switch, the frame will always be discarded. However, depending on whether or not ingress filtering is implemented and enabled, the frame may be dropped on ingress or egress.

Anoop

This statement should have read "If the VLAN tag is one that the switch doesn't know about (i.e. the VLAN has not been configured on that switch)...".

Anoop

Hi Anoop,

Thanks a lot for detailed answer.

Regards Dilip.

ano>