@Joseph W. Doherty wrote:
I'm using rapid-pvst.
Good.
By packet loss I mean that if I ping some switches on VL60 or the default gateway, I see packet loss.
Pinging network devices, can very much be hit or miss, as Cisco network devices deprioritized and even ignore ping requests when busy. Usually, more important is recording ping performance through a switch, although any host can also give poor treatment to pings. (Don't misunderstand that the kinds of pings you were doing are useless, it's just their results are not always truly representative.)
I agree about ICMP but I don't think this is the case because when I removed the link between C101 and C109, every ICMP that had issues started to work flawlessly.
I set the priority on the other switches just in case, it's useless?
Depends on what benefit you sought to accomplish. Which is why I asked that.
I thought It would be better to have it set than not.
What do you mean by pruning? Removing unnecessary vlans?
Removing and blocking (on trunks) from LAN segments where there's no need. Avoids sending VLAN traffic, to LAN segments where there's nothing to receive it.
I need vlan 60 on multiple switches because it's the management subnet where we keep the Ubiquiti APs, Idracs, San, Esxi.
We use L2 because we wanted to separate each vlan from each other and use our firewall to restrict traffic.
That's unclear. You're using a FW as a L2 bridge?
No, the firewall is the default gateway on each vlan.
How can I implement L3 with that?
Generally something like:
host 192.168.1.10/24 <v10> L2 SW <trunk> L2 SW <v10> host 192.168.1.11/24
becomes:
host 192.168.1.10/24 <v10> L3 SW <routed p2p /30> L3 SW <same or different V#> host 192.168.2.11/24
I.e. hosts that were within the same L2 domain, in the same subnet, are now in different L2 domains, in different subnets.
That would work if I had a clear separation i'd say. I have the need to have the subnet of the Vlan 60 in many switches, how would I implement that? Or I wouldn't at all?
I inherited the ring and the customer has a fiber ring connecting the whole network for redundancy.
Redundancy - good, but you can use L3 in ring topologies too, and it's usually better; often much better. The only time you should use L2, is when you cannot use L3; which is often not the case. Decades ago, we had large L2 topologies, because we only had routers and hub, but with the advent of L3 switches, in many cases, you're better off using a L3 topology, and I believe the Catalyst 1300s are L3 switches.
I confirm that 1300s can do some L3.
Assuming you're pinging after STP converges after activation of the C101<>C109 link, activation of that link does change the logical topology.
Yes, the issue arises when I enable the C101<>C109 link and I physically move an AP from a switch down the chain to another or when I reboot one on the same switch.
For example, without that link, for C105 and C107 to exchange data, they would do so across the C105<>C107 link. But when the C101<>C109 link is activated, or C105 and C107 to exchange data, they would like do so like C105<>C104<>C103<>C102<>C101<>C109<>C106<>C107. If, they (C105 and C107) were exchanging lots of data, they may very well impact all the transit switches, and those transit switches traffic would also not impact C105 and C107.
The is no C102.
BTW, if the ring of switches were using routing, C105 and C107, would likely be used, while still having the redundancy of the ring. (I have mentioned, L3 is often better.)
Without L3 or pruning, it's possible, while C105 and C107 want to exchanged data, C104 and C105 are also exchanging data, but under some circumstances, send copies of (flood) that data to C107.
Insufficient information to say for certainly, why activation of the C101<>C109 link causes the ping issues you described, and nothing revealed so far, screams "it's me!", but large and/or ring L2 topologies, are somewhat infamous, for having issues. (Larger ring topologies and STP, often aren't a good mix either [why there's protocols like REP].)
7 switches considering the root is considered large with rapid-pvst?
Lastly, FWs can easily become performance bottlenecks.
Firewalls are not an issue because the can manage more than 10 Gbit of traffic.
I suggest:
Confirming you ping issue extends to just pinging network switch IPs, as such results aren't a reliable indicator.
Not only, DNS queries fail, issues with DHCP too.
Prune VLAN where not needed on trunks.
I will try.
Consider migration to a L3 topology, which, on L3 switches, can be done concurrently while maintaining L2, and you're not required to convert all L2, as again, you can have both on L3 switches.
I will try, not easy though...
Note: L3 topology will very likely require host IP addressing changes, which is pretty trivial if using DHCP.
