LAN Bridge vs Routed Subnets vs ??
-
Well - yeah. If you want one LAN/Subnet, that is the way I'd go.
I see no reason to complicate things. Maybe someone else will. -
Thank you again. It's all on one broadcast domain so I can't see why I shouldn't daisy chain it, and I will probably switch to that for the time being.
I would like to hear from someone on why I shouldn't keep it in bridged mode, since that's how most all (non-enterprise) routers with multiple ports seem to be set up.
-
With that many machines devices you probably should thing about dividing into subnets but that's not going to be a quick decision.
There's almost no point bridging the ports together. It will just put unnecessary load on the pfSense box. Though that box would probably handle it no problems. The only time you might want to do that is if you need filtering between different network segments but they have to be in one large subnet.Then there's the situation a number of us find ourselves in where the box has more ports than we currently need and it seem wasteful to leave them empty. ;)
I would daisy chain them unless you have some good reason not to.
Steve
-
A stack of managed switches would be better but you don't want to bridge pfSense interfaces.
I'd daisychain the switches and put the higher-value devices/servers on the switch directly connected to pfSense.
-
A stack of managed switches would be better but you don't want to bridge pfSense interfaces.
I'd daisychain the switches and put the higher-value devices/servers on the switch directly connected to pfSense.
Totally agree, and that's the direction I want to head in the future; vlans on stacked managed switches.
but you don't want to bridge pfSense interfaces
Is this only because it will put more load on the pfsense box, or is there other reasons to avoid a bridged LAN?
With that many machines devices you probably should thing about dividing into subnets but that's not going to be a quick decision.
There's almost no point bridging the ports together. It will just put unnecessary load on the pfSense box. Though that box would probably handle it no problems. The only time you might want to do that is if you need filtering between different network segments but they have to be in one large subnet.Then there's the situation a number of us find ourselves in where the box has more ports than we currently need and it seem wasteful to leave them empty. ;)
I would daisy chain them unless you have some good reason not to.
Steve
My reason not to was because people normally say 'Never daisy chain switches' and my old router was setup with each switch on a separate port.
I assume daisy chaining in this case will only add a few ms of latency on the second switch, I guess we'll see.
-
pfSense is not a switch with custom ASICs for MAC address switching. Let your switches switch. Let your router route. I doubt you'll notice a difference in latency from one switch to the other. I can pretty much guarantee your users won't.
-
pfSense is not a switch with custom ASICs for MAC address switching. Let your switches switch. Let your router route. I doubt you'll notice a difference in latency from one switch to the other. I can pretty much guarantee your users won't.
Excellent point! I have already restored my config to a previous state with just the one LAN interface. Thank you to all who replied, if anyone has any other thoughts I'd love to hear them.
-
I think everything I've ever worked with was always at least 2 deep in daisy chained switches.
Lets say you needed 5 switches, as a for instance…I'd plug 1 directly into the pfsense, and the other 4 directly into the 1st switch.
Its daisy chained, but its not daisy chained stupidly.
Maybe people are warning you against running 1 > 2 > 3 > 4 >5? That would maybe create a bit of unnecessary latency and would also be less fault tolerant but would still work.
-
I have to say I'd never really considered latency as a reason for not doing this. Perhaps I've been overlooking something. My understanding is that when you chain switches together all the clients on the switch(es) further down the chain have to share a single uplink at whatever speed that is. If you have 5 switches all chained together that's potentially a huge number of clients all sharing the last link. If that first switch has some heavy resource on it that could be a significant restriction. If you do find yourself in that situation try to distribute the clients and servers in such a way that no single link is trying to pass some huge load.
Ideally you want to link the switches at, or close to, the backbone bandwidth which in a Gigabit switch is big. So, say, 5 16 port Gigabit switches all uplinked to a single 5 port 10Gbps switch.
Steve
-
Should have said this is the OP… The IP phones have passthrough for each desk's PC, so that cut's switch port needs in half... also several servers are virtualized. I'm not quite using all 48 ports.
sounds like you need 2 or 3 more 24 port switches.
After that, I like option 3.
You think daisy chaining is acceptable in this situation? Thank you for your response.
I'd setup at least two vlans - one for the pc's and another for the VOIP traffic. Once you have it setup to break this traffic across the 2 plans you may find other logical groups your want to segregate onto a vlan.
This allows you to be more selective on your firewall rules - e.g.: voip has a different footprint versus desktop pc's, etc.
As for switches you want to reduce hops when possible. So I'd have a root switch that plugs into the PF sense box, and all your other switches plug into that switch.
-
He said earlier - The IP phones have passthrough for each desk's PC
Separating phones / computers by vlan is going to be PITA.
-
My experience with IP phones is extremely limited but my understanding is that it's almost always very easy put the phones in a separate VLAN. IP phones usually have built in VLAN handling such that the client connected to the pass through port can easily be tagged onto a VLAN by the phone. VOIP traffic from the phone is tagged (or can be) onto a different VLAN. It should be a simple matter of reconfiguring the phones, easy if you have some central management.
Steve
-
Hmmmm - That would be nice.
I guess I'd have to see the specs on the equipment - For sure my IP phone adapters won't do that.
-
My experience with IP phones is extremely limited but my understanding is that it's almost always very easy put the phones in a separate VLAN. IP phones usually have built in VLAN handling such that the client connected to the pass through port can easily be tagged onto a VLAN by the phone. VOIP traffic from the phone is tagged (or can be) onto a different VLAN. It should be a simple matter of reconfiguring the phones, easy if you have some central management.
Steve
It can be done, but it's definitely adding some additional administration. My Polycom IP 335 phones have in the Ethernet section an option for DHCP VLAN Discovery which you can set to "Custom" and DHCP VLAN Option which you set to "129". Then in pfSense on the DHCP Server Tab for Additional BOOT/DHCP Options you select Advanced and add an option with "129" in the Number field, "Text" as Type and "VLAN-A=22;" in the Value field. The Phones use VLAN 22 and the attached PCs use VLAN 11. I have the Ports on the POE Switch set to PVID 11, VLAN 11 Untagged, VLAN 22 Tagged.
-
I'd setup at least two vlans - one for the pc's and another for the VOIP traffic. Once you have it setup to break this traffic across the 2 plans you may find other logical groups your want to segregate onto a vlan.
This allows you to be more selective on your firewall rules - e.g.: voip has a different footprint versus desktop pc's, etc.
As for switches you want to reduce hops when possible. So I'd have a root switch that plugs into the PF sense box, and all your other switches plug into that switch.
That's exactly how I would do it also.
