How does a switch manage the fact that all its SVI interfaces may have the same MAC address?
For the 6500, this is the case. With a 3750, it is not; each SVI is unique. But when they are not unique, how does the switch compensate for this when it has to make a forwarding decision based on the MAC address?
Hey Victor, haven't spoken in a while. Hope your'e well.
Key thing to remember here is that SVI's are virtual ie. they do not correspond to any physical interface as such. A L3 switch receives and forwards packets out of physical interfaces so it is not actually a problem that all SVI's have the same unique mac-address.
So if a client on vlan 10 sends a packet to it's default-gateway that packet will have a destination mac-address of vlan 10 SVI. But as you quite rightly point out that is also the mac-address of all the other SVI's. But it doesn't matter because the port that the client is transmitting on is in vlan 10 so the switch knows which SVI the packet is destined for.
It sort of makes sense...I think. LOL...I just have to work it ou tin my head, I guess.
But now that I got your attention, let me ask you another question.
If I have a switched access layer in a campus, with L2 uplinks to a collapsed core, and each vlan is confined to the switch (no spanning across a trunk), and only an L3 connection between the core switches, is there any reason to deploy STP? Or put another way, is there any reason not to deploy it? What are the advantages/disadvangtages of it given the environment I described?
Personally, given the fact that each vlan is already confined to the access layer switch, and the client does not like STP, then I would just deploy a routed access layer and be done with it. With each vlan already confined to a specific switch, which is a routed access layer's biggest drawback, why the heck maintain a switched layer?
What are your thoughts on the different points I make?
We have discussed this before but i'll put a slightly different viewpoint than i normally do.
"is there any reason to deploy STP? Or put another way, is there any reason not to deploy it?"
STP has a rather bad press sometimes and a lot of this is due to the original 45 second failover time which in many modern environments is not acceptable. But obviously with the introduction of RSTP/MST (which uses RSTP anyway) a lot of the negatives have been alleviated.
So i would ask what do you gain by turning it off. Not a lot as far as i can see and you stand to lose a whole lot if someone accidentally or maliciously creates a loop in the network. It's not so much a question of turning it off/on but more about limiting the span of STP across your infrastructure.
So you have 2 distro switches connected to each other via a layer 3 etherchannel and you have access-layer switches uplinked to the distro switches by L3 etherchannels as well. So STP is in effect confined to each switch. Would i still enable it - yes because it is an added layer of protection. It is not going to add to any of your failover times as all your links are L3.
That's a general answer to your question. To be more specific in your example if each access-layer switch has only one vlan, which is not a great design anyway as this suggests the management of the switch is using the same vlan as the users, and there is never a need to extend this vlan past the switch, and you have no service-modules in your collapsed core that you need to use in bridged/transparent mode then i would be very tempted to convert to L3 uplinks.
It always comes back to the same thing for me. Whenever i design L3 from the access-layer i am limiting my options in terms of flexibility. Nothing inherently wrong with that if you don't need that flexibility because there are other advantages that you don't get with L2, see all our previous discussions :-), but you need to balance the two.
I agree. I would leave STP enabled. In fact, gievn the fact that they are going with a switched access layer with L2 uplinks to the distro (not L3, as you said), then I would even go with rstp. No point in disabling STP.
Anyway, I also think that they should deploy a routed access layer in this case. They are already confining the vlans to the switch (by design) and they are using a collapsed core (WAN edge included). So they gain absolutely nothing by going with a switched access layer, and have everything to gain with going L3. They are using a non-looped triangle topology. Each access switch is dual-homed (L2) to a routed distro layer. No L2 between distro or access switches, so no loops are created. But, since its L2, one of those links will sit idly by. So they lose the ability to load balance across ECMPs, increase the bridging domain, etc...
We are pleased to announce availability of Beta software for 16.6.3. 16.6.3 will be the second rebuild on the 16.6 release train targeted towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are looking for early feedback from custome...