HPE 1950 - Getting lots of clients disconnections

[Dennis_Eduardo]

Hello everyone, please i need advice about issues im having with my switching topology.

I have 4 switches HPE 1950 connected in a ring topology, management is individually right now.

All switches connected via ten-gigabit-ports SPF+.

Here`s my topology

https://ibb.co/jVt4hLF 

Im getting random clients disconnections on computers, via ethernet or wifi. The client keeps the ip provided by the dhcp server, and can ping its vlan gateway but no other vlans gateways or clients in the same vlan or others.

Sometimes it takes15 mins or more to get the network service again, or i have to restart any of the switches, so thats a big problem.

At the beginning my topology was different, Switch A was the only one doing layer 3 routing and the other three layer 2, then the problem started. Tried to balanced the routing between Switch A and B (like the actual topology) there was an improvement but the problem was and is still there.  Clients keeps disconnecting but not the same ammount as before.

Tried IRF on four switches, but it was worse, because all my 8 Vlans were in the same switch, and the connections were dropping a lot, especially when i have the maximum of clients connected, so i have to revert to what i have right now.

Even i replaced the Switch A with a new one and is the same thing, so no hardware problem from the switch.

Some people have told me that the ARP table from my Switch model is only capable of 256 registries, so that means if i have more clients thant that, there will be disconnections.

Or maybe my routing on the switches is wrong, please i need advice.

Will really appreciate the help.

Regards

Dennis.

[parnassus]

Hi, the limit of ARP Table size could be a factor but, not knowing the number of clients currently present on your network and looking at static routes defined on each switch, I'm more inclined to think you should redesign your physical and logical topologies to (a) avoid a physical loop (if not necessary and if STP is not properly configured on all involved switches) and (b) avoid having more than one switch with routing role.

Point (a) could be easy to fix. Point (b) requires you to rethink your routing approach.

If I were you I will create/use a Transport VLAN (say a 10.10.1.0/30) created on Switch A (designated to be the Core router for all others switches B, C and D), assign the .1 to the VLAN 1 (VLAN 1 is not going to be necessary on all other switches) and the .2 to your Firewall's LAN interface (on its defined VLAN 1). On Switch A the Route of Last Resort 0/0 via Next Hop Gateway will become 0.0.0.0 0.0.0.0 via 10.10.1.2 and, viceversa, on your Firewall all 10.10.x.0/24 subnets will be reacheable via 10.10.1.1.

I will return to Layer 2 switch to switch (between A and B, C, D) carrying as tagged on the uplinks only VLANs that are exactly needed respectively on B, C and D.

I will check and, if needed, fix the STP so the A is going to have the highest STP priority to became root, I will leave all others with lower ones.

I will get rid of IP Routing on B, C and D. I will get rid of static routes on them (not necessary).

I will eventually define a VLAN (say 10.10.100.0/24 with VLAN id 100) to be used as Managment subnet and I will set an IP on that VLAN on A (say .1, B say .2, C say .3 and D say .4), the VLAN 100 will be transported (tagged or untagged) across A downlinks to B, C and D.

B, C and D will require only the Default Gateway settings to point to 10.10.100.1. Clients connected to A, B, C and D will require to have their D.G. set to point to respective VLAN SVI (all .1 on 10.10.x.1 where x=10, 20, 30, 40, and so on...).

The uplink on the Switch A Firewall could remain set as Access with PVID 1 (I mean: with VLAN 1 untagged on the link even if you can think of moving on an alternate dedicated VLAN and tag it, but you also need to make changes on the Firewall's LAN side to cope with that).

[Dennis_Eduardo]

Thanks for the response, at the moment of writing this message i have the following alive clients:

VLAN 192.168.1.1      18
VLAN 10.10.10.1       80
VLAN 10.10.20.1       19
VLAN 10.10.30.1       33
VLAN 10.10.40.1       22
VLAN 10.10.50.1       10
VLAN 10.10.60.1      48
VLAN 10.10.80.1      20
TOTAL CLIENTS   250

Im gonna try to break the ring, to keep the four switches connected in a daysi chain topology and see what happens then.

About centralizing all layer-3 on the Switch Core A, i have a question, what about if all layer-3 routing is managed by the fortigate firewall and the four HP 1950 switches create an  layer-2 IRF Fabric? Is this a good practice or not?

Thanks.

[parnassus]

Well...without going too far...just moving the IPv4 routing duties from your Core Switch (in a ideal topology) to your Firewall is going to mean that your Firewall becomes your unique router (for your VLANs) and all traffic traversing (ingressing/egressing) a VLAN for another - and vice-versa - shall pass through your Firewall's LAN interface back and forth (supposing you're going to use just one LAN interface in trunk mode carrying all VLANs down your Layer 2 switch or to your IRF)...that's a clear bottleneck compared to what happen when your routing takes place into your Core Switch and only traffic destined to external networks (0/0 via NHG e.g. for the Internet as destination) requires to traverse the Firewall's LAN link.