User Tools

Site Tools


computing:openwrt

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
computing:openwrt [2025/12/23 02:43] oemb1905computing:openwrt [2026/08/11 11:49] (current) oemb1905
Line 103: Line 103:
 {{ :computing:mt6000_3-1692964916.png?direct&600 |}} {{ :computing:mt6000_3-1692964916.png?direct&600 |}}
  
-Thanks+Update: 08-11-26 
-oemb1905+ 
 +When I first wrote thisI had the good fortune of having mainly dual-NIC machines in the shop / home office. For this reason, I simply untagged the main lan on the 2.5Gbps switch and untagged the guest lan on the 1Gbps switch. From there, I could simply run cables to each machine and had dual-connectivity to each vlan/subnet with minimal fuss. However, over time, I expanded this to having an additional subnet/vlan that is not tied to pihole+unbound. The reason for this was to mitigate downtime for others in the house if/when my pihole+unbound vms failed, etc., or a fallback interface / SSID as it were. This meant I either had to expand to get tri-NIC setups or finally setup proper vlan support on my clients. I chose the latter. First, I use managed ifupdown within Network Manager so I need to let it know to manage (not overlook) my interfaces file: 
 + 
 +  sudo apt install network-manager nm-connection-editor networking bridge-utils 
 +  sudo nano /etc/NetworkManager/NetworkManager.conf 
 +   
 +Inside there, make sure that your file includes these directives: 
 + 
 +<code> 
 +[main] 
 +plugins=ifupdown,keyfile 
 + 
 +[ifupdown] 
 +managed=true 
 +</code> 
 + 
 +Then, after that, install the vlan package and setup your interfaces file to match the ''.xxx'' vlan designations you created in openWRT. 
 + 
 +  sudo apt install vlan 
 + 
 +Inside interfaces, I setup the following: 
 + 
 +<code> 
 +# ===== First NIC (enp1s0) – 2.5G ===== 
 +auto enp1s0 
 +iface enp1s0 inet manual 
 + 
 +# Private 10.30.30.0/24 – untagged 
 +auto br-priv 
 +iface br-priv inet dhcp 
 +    bridge_ports enp1s0 
 +    bridge_stp off 
 +    bridge_fd 0 
 + 
 +# VLAN 178 (172.60.60.0/24) – tagged 
 +auto enp1s0.178 
 +iface enp1s0.178 inet manual 
 +    vlan-raw-device enp1s0 
 + 
 +auto br-open 
 +iface br-open inet dhcp 
 +    bridge_ports enp1s0.178 
 +    bridge_stp off 
 +    bridge_fd 0 
 + 
 +# VLAN 177 (172.38.38.0/24) – tagged 
 +auto enp1s0.177 
 +iface enp1s0.177 inet manual 
 +    vlan-raw-device enp1s0 
 + 
 +auto br-lock 
 +iface br-lock inet dhcp 
 +    bridge_ports enp1s0.177 
 +    bridge_stp off 
 +    bridge_fd 0 
 + 
 +# ===== Second NIC (enp2s0) - 1Gbps ===== 
 +#auto enp2s0 
 +#iface enp2s0 inet dhcp 
 +# this was moved to NM only since they seemed to fight over this one 
 + 
 + 
 +#If bridge is needed on enp2s0, use the following 
 +# VLAN 177 (172.38.38.0/24) – untagged 
 +#auto enp2s0 
 +#iface enp2s0 inet manual 
 + 
 +#auto br-lock2 
 +#iface br-lock2 inet dhcp 
 +#    bridge_ports enp2s0 
 +#    bridge_stp off 
 +#    bridge_fd 0 
 +</code> 
 + 
 +For the second NIC, I found that - if left unbridged - Network Manager would take it over. Of course, you could disable the interface in Network Manager's connection editor, which let ifupdown take over. You could also just comment out the second interface in ifupdown and let Network Manager handle it. Since I was not bridging the second interface, only the first (including the three subnets/vlans), I decided letting Network Manager handle it was fine. I did, however, put the entries above showing how you could just as easily let ifupdown handle the second NIC and/or even bridge that interface too within ifupdown. I found upon reboot that ''ifupdown-pre.service'' was trying to do stuff before the vlans/subnets all got raised, causing failures. For that reason, I disabled the service: 
 + 
 +  systemctl mask ifupdown-pre.service 
 +   
 +After that, I was able to freely reboot without errors. Every once and a while a bridge will take a bit to raise or fail to raise. If that happens, just restart networking and it populates. It takes time for all the negotiations, so this is a feature not a bug from what I can tell.
  
 -- -- OLD STUFF - EDIT -- --  -- -- OLD STUFF - EDIT -- -- 
computing/openwrt.1766457798.txt.gz · Last modified: by oemb1905