I decided to reconfigure my home network from scratch, it grew and grew over the last 10 years and became overly complex. Complexity is the worst enemy of security .
Attached is the plan: My ISP delivers VLAN 50 that assigns one public IP, and VLAN 40 for one IP for a VoIP client. Internally, I use VLAN 15 for a guest WLAN and 25 for IoT devices. All else goes over the default VLAN 1.
My good old RB1100AH seems to have 3 switch chips https://i.mt.lv/cdn/product_files/RB1100AHx4v5_180118.png, my question is: Does it make sense to use two bridges to handle the VLANs as shown or would just one bridge for all VLANs make more sense?
When it comes to bridge HW offload to underlying switch(es), itâs important to keep in mind a few facts:
one bridge can be offloaded to single switch chip. If ports, connected to a switch chip, belong to different bridges, then only a part of ports will actually enjoy benefits of HW offload
one bridge can be offloaded to multiple switch chips. However traffic between bridge ports, controlled by different switch chips, will pass CPU and will also use the switch-CPU interconnect (which may become bottleneck). Bridge also might need additional setup to work around bridge offload bug (which probably doesnât affect you, itâs a problem in a more switch-like use cases where CPU/ROS software stack doesnât need to talk to all VLANs passing bridge).
According to the diagram you posted itâs clear that first bullet is waiting to bite you if you go with twin bridge concept.
Personally Iâd go with single bridge concept, which in principle doesnât limit the flexibility ⌠and with carefully selecting physical ports to connect particular clients you can control amount of traffic passing the switch-CPU interconnects (using ether13 to connect CRS may not be the best idea in this regard, but depends on amount of traffic expected inside VLANs 1, 15 and 25). Iâd use ether6-10 instead of 3, 4, 5 and 13 and figure another way of powering RB1100 from PoE switch (if youâd really like to use PoE, then you can use a dedicated cable only for PoE ⌠this wastes a port on CRS which might not be feasible if port count is tight).
Indeed, PoE in is only on Port 13, and this is on a switch chip with only 3 ports (11,12,13). I think I will change it as
follows: eth1 â 12, eth2 â 13 (VoIP also goes into the switch), eth13 â 1. Bridge-ISP and Bridge-LAN will then be on different switch chips.
If youâre passing VLAN 40 to switch, then by using single bridge you may run into issues with STP/RSTP (these donât take VLANs into account). But OTOH nothing is stopping you from adding VLAN 40 to the trunk connection with single-bridge approach.
Beware of specifics of ether11/12 on RB1100AHx4 ⌠(in case of VoIP it actually makes sense)
Hm ⌠what do you mean? I only found âThe bypass switch allows binding ports 11 and 12 together in bypass mode, which means that if the device loses power, the ports will be connected together, allowing data pass from one port to the other, as if the device would not be there.â in the documentation.
Yup, Iâve had this in my mind. So in event of power loss, does this behaviour pose a threat to security of your LAN devices? If youâre going to connect ISP and VoIP to these two ports, then described behaviour might even be wanted (if port connects dedicated VoIP infrastructure ⌠VoIP phones would likely continue to work). But if âVoIP portâ connects to LAN switch, then this might become a problem (attacker from WAN side might be able to craft correct VLAN headers âŚ).
Good point. If I power the Router on port 13 over PoE from the Switch, the switch should also be down if the router is. Unless the router fails internally⌠will think about it.
I will change it to a single bridge concept:
port1 connects VLAN 1, 15 , 25 to the switch
port 2-5 have untagged VLAN 1 (most traffic is on VLAN 1)
port 6-10 have untagged VLAN 15 or 25
port 12 is ISP, 13 VLAN 40 (VoIP) going to the switch.
So if understand you right, both port 1 and port 13 will connect to the switch. If this is so, then set port 13 to be edge port. You will probably have to do similar thing on switch. Otherwise you may have issues with RSTP blocking one of these ports.
.
