trunk allowed vlan on ports beyond the core?

[baselzind]

we usually apply allowed vlan list on trunk port between the core and the edge switch in the floors and branches , but what about the switches connected to the edge switch? am i supposed to apply also allowed vlan? as it would be very tedious incase of new vlan

[Kasun Bandara]

@baselzind  hi, it depends on your requirement. for ex. if you have VLAN 10,20,30 in core switch. you can allow all or few towards edge switches. but are you really need all in edge switches? imagine you have 3 edge switches. switch 1 is only connected to end devices which needs vlan 10. in that case you can allow only vlan 10 from core to edge switch 1.

second scenario is if you have another new switch (switch 10) connected to the edge switch 1. if your switch 10 needs only vlan 10, then you only need to allow VLAN 10 from switch 1 to switch 10. incase, if you have any plan to connect vlan 20 users to switch 10, then you need to enable vlan 10,20 from core to switch 1, and van 20 from switch 1 to switch 10 trunk port.

[baselzind]

thanks for the input however what i meant is does applying allowed vlan between core and the direct edge switch only , is enough to limit loop damage and also reduce vlan broadcast to all the switches behind that first edge switch?

[Kasun Bandara]

hi @baselzind , if you have only 1 line of edge switch and few more connected to them will be not an issue. but try to allow only required VLANs. STP will take care of loops if you not disabled it. but if you have roughly 50+ switches in same broadcast domain, better to configure STP properly or reduce the L2 domains using L3 domains.

[balaji.bandi]

 but what about the switches connected to the edge switch? am i supposed to apply also allowed vlan?

yes if you like to extend the VLAN daisy chained Switches beyond Edge switches, Not for the host.

Make sure you properly configured spanning root bridge to be core -

[MHM Cisco World]

For vlan in trunk you can

1- manually allow vlan or range of vlan (this range includes vlan you maybe in feature add) 

2- automatically via vtp pruning' this I dont recommend it have some issue

MHM

[Joseph W. Doherty]

I'm unsure I completely understand your question.

If, for example, your asking something like having four switches interconnected with trunks like sw1<>sw2<>sw3<>sw4 where sw1 is the core switch and on it you block VLANs to sw2, do you also need to further block those VLANs on switches 2, 3 and 4?

Answer depends on what your trying to accomplish, and logically what you're trying to do.

For example, say VLAN 5 is defined on sw1, but not switches 2, 3 and 4.  If VLAN 5 is blocked going to sw2, and, again, undefined on 2, 3 and 4, logically there no need for further blocking it.

If, though VLAN 5 is known on all those switches (perhaps via VTP), but without port assignments, one might argue it should be further blocked, but I wouldn't bother.

Lastly, perhaps there's active VLAN 5 ports on switches, 2, 3, and/or 4.  In that case you're logically have two different VLANs, both numbered as 5, which is ripe for confusion and errors, which if really intentional, sw2 should also now block VLAN 5 to sw1.

The above is a long way of saying you should only need to block (prune) VLAN traffic on trunks where you don't want to extend that VLAN, i.e. no need to repeat such blocking on switches beyond the logical demarcation, unless you reusing a VLAN number (the latter, again, poor practice, unless usage is separated by L3).

[baselzind]

thanks alot for the input however that wasn't what i wanted to ask , my question was based on your example if i made "allowed vlan" "that includes all the vlans used in the sw1-5" on the link between sw1 and the core , do i need to also configure allowed vlan between sw1-sw2 sw2-s3..etc? my goal is to protect against loop damage in case it happen and to reduce traffic on the uplink. like would allowed vlan between sw1 and core be enough?

[Joseph W. Doherty]

If I remember correctly, allowed all is the default.  So, really the question becomes whether you bother to prune and if you do, where to apply.

Pruning isn't usually considered in regard to precluding loops, as that is usually done by something like STP.  That said you could construct a loopfree topology, on a looping physical topology, manually blocking VLANs, but even then, something like STP is recommended to preclude accidentally loop creation.

Pruning can, and perhaps should be, used to preclude needless traffic on trunk links, but in a switched environment, usually there's not a whole lot of this traffic (also that traffic volume, generally, hadn't grown proportionally with interswitch bandwidths).

Wherever you manually block a trunk VLAN, it's blocked in both directions, but for link bandwidth usage consideration, it's only effective for egress.

So, for example, you have two interconnected switches, 1 and 2, and sw1 has a VLAN not used by sw2 or any other switches that VLAN would transit via sw2, you only need to block that VLAN on sw1's trunk to sw2.  Again, if you don't block this traffic, normally the volume going needlessly to sw2 would be minor, but you're also correct, there are cases where that's not true like a loop in sw1, but even for those blocking on just sw1 should be sufficient.  (Of course, if there's a loop on sw1, sw1 becomes, somewhat a crapshoot, whether it will maintain the block.  If that a concern, you could block every trunk interface to only allow necessary VLANs, or just on the first connecting trunk interface, e.g. sw2's, which will preclude further propagation from sw1 running wild.)

[Joseph W. Doherty]

To clarify further, some examples:

Given  sw1<>sw2<>sw3<>sw4, where sw2 is the core switch, and VLAN 5 is defined on switches 1 and 2 and for switch 1, we also have PC1<>sw1<>PC2.

PC1 want to send data to PC2.  So it first ARPs for PC2's MAC, which all 4 switches "see" on their trunks and switches 1 and 2 also see on any VLAN 5 ports (as ARP is a broadcast).

If you block VLAN 5 on sw3's trunk to sw2, ARP broadcast will transit sw2<>sw3 trunk, but won't go further.

If you block VLAN 5 on sw2's trunk to sw3, ARP broadcast will transit sw2<>sw3 trunk.

When PC2 responds to ARP request, switches 1 and 2 will not know edge port for PC and unicast traffic will only flow across sw1.

If however, PC1 had IP MAC hard coded on it, it wouldn't need to ARP.  And if PC2 doesn't respond in some way, PC1 can send traffic to PC2, but as no switches has seen PC2's MAC, this unknown unicast flow will be flooded to every VLAN 5 port on switches 1 and 2 (like the ARP did) and also will flow across all the switch trunks (again like ARP did).

You can block this unicast flow, the same way, with the same results, as you did for ARP.  Big different, if you block on sw3 ingress, rather than a single ARP packet coming down the link, now all the unicast data flows down the trunk.  If blocked on sw2, trunk bandwidth is not consumed by unicast traffic to an unknown MAC.

Switch 4 only see switches' 1 and 2 VLAN traffic, if traffic not blocked upstream of it, like when all trunks allow all VLANs.  So, no need to block VLAN 5 unless you believe upstream switches have not already blocked unneeded VLAN traffic.

Again, even if VLAN5 traffic comes down the trunk, unless there's another trunk or access ports in that VLAN, switch would not forward that VLAN traffic.

As I alluded to in earlier replies, even if all VLANs were allowed, "normally" there would not be much needless undesired VLAN traffic on transit trunks.  But in the case where a known unicast destination is not being used, blocking undesired VLANs can be very useful, but you don't need to do on every trunk interface.  Only really need to apply on a trunk interface that would be the "edge" of the VLAN, in my example above, sw2 trunk to sw3 block VLAN 5 (as we don't want any VLAN 5 traffic on switches 3 or 4).