HP Switches 2530 vs 1950 vs 1920
-
I agree there aren't collisions anymore (at least with switches) but what do you call the domain that all broadcasts go to? You could still have saturation cause by broadcasts storms, but those are normally limited to a single VLAN - though I'm guessing the pegging out of the processor on the switch is the main concern, so it doesn't really matter if all of the VLANs run through the switch, they'll all be affected.
-
@Dashrender said:
I agree there aren't collisions anymore (at least with switches) but what do you call the domain that all broadcasts go to?
A broadcast domain. Broadcasts cross bridges, collisions do not.
If you have any concerns with broadcasts on /22 it means you have something wrong that you need to address. Being on /24 would be a bandaid, not a fix.
-
@scottalanmiller said:
@Dashrender said:
I agree there aren't collisions anymore (at least with switches) but what do you call the domain that all broadcasts go to?
A broadcast domain. Broadcasts cross bridges, collisions do not.
If you have any concerns with broadcasts on /22 it means you have something wrong that you need to address. Being on /24 would be a bandaid, not a fix.
yeah I came to that conclusion while writing the previous post.
-
@Dashrender said:
You could still have saturation cause by broadcasts storms, but those are normally limited to a single VLAN
You can have that with a /28. IF this is happening at any of these sizes it is because something is terribly wrong. If you are going to /24 because of this you are not addressing what is actually wrong on the network.
-
@Dashrender said:
though I'm guessing the pegging out of the processor on the switch is the main concern, so it doesn't really matter if all of the VLANs run through the switch, they'll all be affected.
That's possible. VLANs will limit some things in the case where there is a disaster. But yes, if it pushes the switch hard or bottlenecks any of the ports, you are screwed.
-
@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.
