5

I'm not 100% sure of the vocabulary, so please bear with me.

Physical and Logical topography

Suppose I've set up some new VLANs to better divide my network logically. I have a 4507 as a core network switch with VLANs 1 and 10-19. The switches themselves have IP addresses on VLAN 1. Each of the three child switches I have each have three additional VLANs with said VLANs corresponding to individual departments. Several departments may be on one switch, but departments would be confined to one switch only. Some of the host interfaces on the child switches are configured as trunking interfaces to accommodate phones and PCs on the same int. The uplinks to the 4507 are configured as trunking intrtfaces as well.

Switch

  • 3524 should have 10, 11, and 12
  • 3550 should have 13, 14, and 15
  • 3560 should have 16, 17, and 18
  • 4507 should have VLAN 19 as well

Is it possible to configure each child switch so that they drop (?, *) or don't see VLAN traffic not intended for any VLANs present on any host interfaces? I.e., Switch

  • 3524 should drop* or not see traffic for VLANs 13-15, 16-18, and 19
  • 3550 should drop* or not see traffic for VLANs 10-12, 16-18, and 19
  • 3560 should drop* or not see traffic for VLANs 10-12, 13-15, and 19
  • 4507 should be the only switch to see VLAN 19 traffic

I'm trying to minimize the scope of a broadcast storm should another one occur (fun day).

I'm curious to see which switches would be affected and how far a broadcast storm would propagate if, for example, a broadcast storm started in VLAN 10 on 3524. Would it only affect 3524 and 4507? Or would the storm affect all switches because their uplinks and some of their host ints are configured as trunking interfaces? Assume bpduguard isn't available on 3524.

.* "Drop" versus "don't see" would be, I imagine, from the perspective of the switch. "Drop" means the child switches (3524/50/60) would decide to drop certain broadcast traffic because certain VLANs aren't present for any host ints. "Don't see" would be the 4507 not forwarding certain broadcast traffic because certain VLANs aren't advertised(?) by child switches.

Improve this question

2 Answers 2

Reset to default
4

You can control which VLANs are allowed on a trunk. For example:

On the 4507 trunk interface to the 3524:

switch port trunk allowed vlan 1,10-12

On the 4507 trunk interface to the 3550:

switch port trunk allowed vlan 1,13-15

On the 4507 trunk interface to the 3560:

switch port trunk allowed vlan 1,16-18

None of the traffic for any VLANs not allowed on a trunk will be sent to the access switches.

Cisco recommendations are actually pretty close to what you have, although you do have VLAN 1 going to all the switches. The current best practices allow multiple VLANs on an access switch, but no VLAN on an access switch should be trunked to another access switch. Also access switches should not be connected to each other, and no access interfaces should be allowed on the distribution switch. This will almost completely eliminate any spanning tree problems.

In fact, the best practices are moving toward running layer-3 connections, instead of trunks, to the access switches, and that will completely eliminate any spanning tree problems.

In either case, you leave spanning tree enabled as a failsafe.

Improve this answer
1
  • 2
    I think you've answered some of my other NE posts before too. Thank you for the continued support. :)
    – user208145
    Commented Mar 11, 2018 at 7:57
1

It seems the original question isn't quite answered:

How far is VLAN broadcast propagated?

Think of a contiguous VLAN as a single, virtual switch. A broadcast in a VLAN is propagated through all ports participating in the VLAN. Therefore, having all your switches and interconnects participate in all VLANs poses the risk of an unlimited broadcast storm - regarding the participating interfaces and trunks. Ron's recommendations are to limit the reach of each VLAN as far as possible to limit the effect of a broadcast storm as well.

You shouldn't drop/ignore a VLAN on an uplink trunk but the corresponding downlink shouldn't even include it - only this protects the trunk in case of a broadcast storm. Remember that a VLAN isn't only configured by switch but by port as well. (I think this clears up the drop vs don't see).

Dynamically advertising VLANs across switches (e.g. by MVRP or GVRP) requires careful planning and a definition of a trustworthy zone. In your limited scenario I wouldn't do it and instead use static VLANs throughout.

(I've assumed an equal speed of all interfaces - a fat tree using faster interfaces towards the root can also provide some broadcast storm protection as the storm's bandwidth is generally limited to twice the looping interfaces' bandwidth. A fat tree can't protect against MAC table instabilities, however.)

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.