Reddit Feeds

Sign up and stay connected to your favorite communities.

sign uplog in
Posted byA+, SEC+8 days ago

Question about VLANs and broadcast domains

Reading Odoms book and am on the chapter about VLANs and how each VLAN is a separate broadcast domain. I am trying to understand how the frame decides where it is going, so is it correct that the frame comes to the switch and uses 802.1q to decide what VLAN it needs to go to. Then from there it looks at what interfaces are part of that VLAN and broadcasts out to all the devices in that range and then from there decides where its going?

100% Upvoted
What are your thoughts? Log in or Sign uplog insign up

The packet's VLAN is known by the switch based on the access port it ingresses on. Tags are only applied if it's crossing a trunk.

On a port where more than one VLAN exists, vlan tagging is used to indicate where it needs to go.

A+, SEC+Original Poster1 point·8 days ago

right, so the frame comes in on a trunk port and does vlan tagging to decide where to go

CCNP|CCDP|CCNA-V|CMNA1 point·8 days ago

Keep in mind, packets/frames don't decide anything - once they're put on the wire by the sending device, the packet itself doesn't decide anything, everything is left up to the routers/switches/etc.

When a broadcast frame is sent to a switch, if it has a VLAN ID tagged and the switch also that VLAN ID tagged on the interface, the switch will flood the frame out all the ports that either have that VLAN ID tagged (like trunk ports) or are untagged in that specific VLAN (access ports in the VLAN).

A+, SEC+Original Poster1 point·8 days ago·edited 8 days ago

the switch will flood the frame out all the ports that either have that VLAN ID tagged (like trunk ports) or are untagged in that specific VLAN (access ports in the VLAN).

That's what I was getting at, just didn't really know how to word it.

So another question, and it might be a dumb one. Once the mac address is saved to the mac table and the switch knows exactly what interface to send frames destined to that mac and does not need to flood, is that vlan still considered a broadcast domain? Like if nothing is broadcasting, or flooding because the macs are known and saved, is it still considered a broadcast domain?

CCNP|CCDP|CCNA-V|CMNA1 point·8 days ago

VLANs are always broadcast domains - the idea of a broadcast domain is that any broadcast will be flooded within that domain but won't leave it. E.g. a broadcast in VLAN 10 won't be seen by any device in VLAN 20 but will reach all devices in VLAN 10. A broadcast domain is just a concept, it's not something that goes away if a device isn't actively sending a broadcast.

You may be thinking of unknown unicast flooding, which is a special case of broadcast flooding. Normal broadcast traffic has a destination MAC address of all F's (ffff.ffff.ffff), and when the switch sees a frame with a destination of ffff.ffff.ffff it will forward it out all ports besides the port it came in on.

Unknown unicast is where a frame is destined to a specific MAC address (aaaa.bb12.3456) but the switch doesn't know where aaaa.bb12.3456 lives. In this case, the switch will flood the frame out all ports, and if the device is actually on the network when it responds the switch will update its table with the port the response was seen coming into. Then the next time a device tries to talk to aaaa.bb12.3456, the switch doesn't need to flood the frame because it knows which port the device is connected to.

A+, SEC+Original Poster1 point·8 days ago

So I didn't realize there was different kinds of flooding. I thought flooding was just a general term of what a switch does with a frame when the destination mac address is not on the mac-table. If you don't mind, could you give me an example of when regular broadcast flooding is used, and also when unicast flooding is used. I was always thinking they were the same thing.

Community Details





Create Post

r/ccna Rules

No posting of illegal materials
No posting of braindumps
Be courteous and helpful
Don't ask others to complete your labs
Cookies help us deliver our Services. By using our Services or clicking I agree, you agree to our use of cookies. Learn More.