HP Switches 2530 vs 1950 vs 1920
-
@scottalanmiller said:
That would be what to do. The most demanding networks work fine on /22. Since there is no such thing as collisions, any issue with a /22 or even a /21 means you have something wrong on the network already.
Where is a good document proving that though?
-
This is why I recommend a single big flat network with a single switching infrastructure. Gets rid of the bottlenecks.
-
@JaredBusch said:
Where is a good document proving that though?
That 256 is a problem? I'm not aware of there being anything to suggest that it is.
-
@scottalanmiller said:
This is why I recommend a single big flat network with a single switching infrastructure. Gets rid of the bottlenecks.
I recommend OBFN because I never know who may follow behind me, and VLAN setup is NOT simple for many in the SMB market.
But that reasoning has nothing to do with actual functionality and broadcast domain max sizes.
-
From the certification days, the use of the /24 was because of collisions primarily and because of the Classing, not because of size issues with broadcast domains. Which is why all the enterprises that I've seen moved to bigger networks once they went to switches.
-
@JaredBusch said:
@scottalanmiller said:
This is why I recommend a single big flat network with a single switching infrastructure. Gets rid of the bottlenecks.
I recommend OBFN because I never know who may follow behind me, and VLAN setup is NOT simple for many in the SMB market.
But that reasoning has nothing to do with actual functionality and broadcast domain max sizes.
That too, easier to set up, easier to make highly performant and way easier to hand off.
-
You can still do stacked switches or a single switch at this size without doing away with VLANs. But VLANs mean you need more expensive switches that have to do more processing. Technically, VLANs would necessitate L3 processing which, in turn, puts the switches at more risk of being overloaded as they are doing a lot more. But normally you overbuy L3 switches compared to L2, but latency still increases.
-
Yeah all that makes sense - Damn it will be a hassle to convert... but It's probably time to consider it. Now would be better than when I move to another 50 IP phones in a few months.
-
What I would recommend considering is this:
- Get a new switch designed around migrating to OBFN (stackable.)
- Slowly move IPs over time to the new IP range as you can do so easily.
- Every time you replace a switch, get another stack member and move things over.
- Profit
-
@Dashrender said:
Yeah all that makes sense - Damn it will be a hassle to convert... but It's probably time to consider it. Now would be better than when I move to another 50 IP phones in a few months.
Yes, when putting in a new switch and when doing a big move would be a good time.
-
Don't just do OBFN, I would really go to the stacked switches too. It means you end up with a "single switch" effectively at the end of the day. One thing to manage, one thing to monitor, one thing to troubleshoot and no bottlenecks between ports.
-
We don't have any VLANs here anywhere. But we do buy very high end switches from both Cisco and HP. We monitor the network heavily rather than block everything with the switches.
-
@thecreativeone91 said:
We don't have any VLANs here anywhere. But we do buy very high end switches from both Cisco and HP. We monitor the network heavily rather than block everything with the switches.
Good way to go. Once you get to any size you need good switches with full monitoring capabilities (fully managed.)
-
Unless the switches can stack over ethernet (I know some can) that won't be possible completely. We have 3 switches in one building and 3 in another (I just remembered about the 6th one).
-
@Dashrender said:
Unless the switches can stack over ethernet (I know some can) that won't be possible completely. We have 3 switches in one building and 3 in another (I just remembered about the 6th one).
At least stack those that you can, lower the total number of bottlenecks.
-
@Dashrender said:
Unless the switches can stack over ethernet (I know some can) that won't be possible completely. We have 3 switches in one building and 3 in another (I just remembered about the 6th one).
You don't usually stack like that anyway. You usually stack your core switches and then use Etherchannel over fiber to each access switch, they are spread out so you can't stack them like you normally would effectively but, you can set them up on Cisco Switches to share configs and VLAN databases.
-
Good to know, thanks.
-
@scottalanmiller said:
What I would recommend considering is this:
- Get a new switch designed around migrating to OBFN (stackable.)
- Slowly move IPs over time to the new IP range as you can do so easily.
- Every time you replace a switch, get another stack member and move things over.
- Profit
Would you start with a whole new IP range for the new network?
For example I currently use
172.168.30.x main network
172.168.40.x remote location 1
172.168.50.x remote location 2
172.168.60.x remote location 3
172.168.70.x remote location 4
172.168.80.x VOIP
172.168.90.x Wireless
172.168.100.x VPNFor my migration should I create something like 192.168.192/22?
We are closing 2 of the remote locations, so I'll still need two of those smaller networks for them. -
Well it depends BUT from looking at yours I would use 172.168.30.0/22 and put all new devices above 172.168.31.0 so that there is no overlap.
-
For security reasons, keeping VLANs or physically separate networks for VPN, DMZ and WiFi might make sense.
