Migration from 2100 to 4100
-
Hello,
I migrated my config from Netgate 2100 to 4100.
- Export XML from 2100
- Import XML to 4100
- Reassign ports
- Reboot
- Create a bridge interface with LAN2-LAN4
- Assign bridge0 to LAN (took over IP and other config)
- Add LAN1 to bridge0
- Changed net.link.bridge.pfil_member to 0
- Changed net.link.bridge.pfil_bridge to 1
- Reboot (just in case)
All seemed to work fine at the first sight. Then I swapped the 2100 with the 4100 and odd things started to happen on the LAN. It took ages for some hosts to get an IP from DHCP. Even after the DHCP eventually passed, ARP for the gateway (bridge0) was missing.
As Eero mesh is connected to one of the bridged ports, I also tried ti change the edge ports config. No luck.
I know that bridging is not ideal, but majority of the traffic is anyway passing via wifi and only RPi and home-gateway are connected to the other ports, so I don’t really need a switch in this case.
Anyone faced similar issue?
-
@mgi if I had to guess, most likely related to switching from switch interfaces to discrete interfaces. Your issue most likely resides in that somewhere.
I believe - but please don't take my word as gospel or anything. But I "believe" netgate will do some conversion of your config from your 2100 to your 4100 for you.
You prob want to open up a tac case about your migration - I am pretty sure have seen threads about this in the past where netgate would do the changes in the config needed to migrate to another one of their boxes where the hardware doesn't actually line up exactly, ie going from switch to interfaces.
Worse case is they say no.. I would ask.. @stephenw10 or maybe @rcoleman-netgate would be able to verify if that is a service they offer or not.
-
@johnpoz Thanks.
I was thinking the same, but it's odd that the ports worked ok until I connected the AP.
Anyway, I restored the config again but without the bridge this time. All seems to be working fine. Which is a bit odd because I can't imagine there's a loop in the previous setup — it's very simple.
┌───────┐ │ Modem │ └───────┘ │ WAN │ │ ┌──────────────┐ ┌────│ Netgate 4100 │────┐ │ └──────────────┘ │ │ │ │ LAN bridge LAN bridge LAN bridge │ │ │ │ │ │ ┌───────┐ ┌───────┐ ┌───────┐ │ Eero1 │ │ RPi │ │Home GW│ ╱ └───────┘ ╲ └───────┘ └───────┘ ─ ─ ╱ │ ╲ Wireless Wireless Wireless ╱ │ ╲ ┌───────┐ ┌───────┐ ┌───────┐ │Client1│ │ Eero2 │ │ Eero3 │ └───────┘ └───────┘ └───────┘ Wireless ╱ Wireless╱ ╱ ╱ ┌───────┐ ┌───────┐ │Client2│ │ClientN│ └───────┘ └───────┘I'll configure the bridge again later today or tomorrow and see how that behaves. Worst case, I'll restore the settings from backup.
After that, I'll see if anyone else responds. If not, I'll try TAC.
EDIT: I slightly fixed the diagram
-
So I can easily replicate this just by assigning the
bridge0interface to LAN. The local network goes crazy.Then I switch back to a single interface, and everything is fine.
-
@mgi said in Migration from 2100 to 4100:
The local network goes crazy.
What does that mean exactly? if I had to guess you have a loop, but sure don't see it via your drawing.
-
@johnpoz I should have been more precise about this, but basically, it's what I said in my first post...
- first, I spotted that DHCP either fails or takes long to kick in
- hosts configured with static IP or those that already got IP from DHCP before switching to
bridge0can communicate together even over the bridge with no issue - I don't see
bridge0MAC in the ARP table on connected hosts
I don't think this is a loop. My network is only two hosts connected to the bridge, and chaining two switches (the bridge and AP) together on one port. None of my devices is connected to the wifi and the bridge at the same time.
I needed the network stable for work, so I didn't spend too much time troubleshooting the issue. I'll try again over the weekend and probably also contact the TAC.
-
Try running a pcap when you have a client trying to pull a dhcp lease.
You'll probably see either missing replies or missing responses somewhere.
You should probably spoof the MAC of bridge0 if you're running the dhcp server on it otherwise clients will see it as a new gateway after each boot.
Steve
-
@stephenw10 I ran a pcap today. I thought before that (as well) DHCP is part of the problem, but that looks ok.
The problem is that the box stops responding to ARP requests.
I was waiting with spoofing the MAC until I get evrything working. Anyway, I spoofed the MAC and the network started working. Then I restarted the interface on my laptop and the box stopped responding to ARPs again.
I can see the same even when I set static IP on my laptop.
This seems to be the same or at least very simillar issue. I’ll try to spoof the MAC on the bridge and all bridge-members later today and tomorrow even that sounds odd.
-
You only need to spoof it on the bridge interfaces because otherwise it uses a randomly generated MAC at each boot.
Are you using VLANs?
Steve
-
@stephenw10 That’s what I did, but then I found the post. It sounds strange but I might give it a shot.
I don’t use any VLANs. My home network is very simple - exactly as the diagram I posted.
-
Mmm, I can't see how it would help but easy to test.
-
@stephenw10 Tbh, me neither. I just found that post and I’m wondering if this might be a bug
¯\_(ツ)_/¯I don’t want to mess with this anymore tonight. I’ll test again tomorrow morning even I have my doubts.
-
I tested the thing with same MAC on the bridge and all bridge members. No difference.
Anyway, something seems wrong as the bridge L3 interface does not respond to ARP requests.
-
But it only does it when the mesh wifi is connected to it?
Do you have STP enabled on the bridge?
-
@stephenw10 so it's even more weird :)
I tested again and only the port where the AP is connected seems to be affected. The other bridge ports seem to work ok.
I as well played with (R)STP combinations again and again, but no luck. I also tried to force the port to be edge, but that didn't help either.
There might be some incompatibility with the Eero mesh, but I'm not sure why; I can't see a reason why the port or ARP response should be blocked.
I had the APs connected to Ubiquiti ER-12, Juniper SRX and Netgate 2100 before. There was no issue, but all of those have HW switching.
-
Never understand why users continue to think bridging is the same as switch... If you want to switch, then use a switch ;)
Why do users always want to waste good discrete interfaces by trying to turn them into switch ports?
You have everything on a flat network, a 20$ 5 port gig switch would solve your problem ;) Make that $15 I see a netgear gs305 on amazon for 14.99 right now.
-
@johnpoz I know bridge and switch are not exactly the same, but there’s a “0” difference in my case :)
I already have a switch connected, that’s not the problem. The problem is that the bridge is not working as expected. I’m just trying to figure out if’s because of Eero or pfSense/Netgate.
In my case, using a switch is wasting ports on the 4100 because otherwise I don’t have use for those. I need 4100 only for the (IPSec) throughput.
-
Mmm, I agree that this could be trivially solved with the cheapest 5 port switch.
However I'm of the opinion that if you have interfaces you're not using then adding them to a bridge is not necessarily a bad use. But you need to be aware of the limitations of doing so. Mostly that it loads the firewall just to pass traffic between the bridged ports.
Mesh wifi is weird though, it's ot to be something in the ARP handling there.
Were you seeing ARP requests leave the client but never arrive at the bridge? -
@mgi said in Migration from 2100 to 4100:
but there’s a “0” difference in my case :)
I would beg to differ, if you were using a switch we wouldn't be having this conversation and you wouldn't have spent how much time trying to get it to work ;)
because otherwise I don’t have use for those
Also going to differ on that opinion as well - just because you not currently using an interface doesn't mean its "wasted" it means you don't currently have a need for that interface.. I have ports open on my switch - are they "wasted" ;)
They are discrete interfaces - when you at some point? Decide to actually segment your network, they will be quite valuable..
I have TBs of space on my disks in my nas currently not in use - am I wasting it? I have currently not using all the ram in my PC, is that wasted? Room for growth is not wasted.. Now if you bought a 48 port switch and have 3 devices.. That might be wasteful ;) But a couple of interfaces on you router that are currently not being used because your only using 1 network segment is not the same thing.
An intelligent man is sometimes forced to be drunk to spend time with his fools
If you get confused: Listen to the Music Play
Please don't Chat/PM me for help, unless mod related
SG-4860 24.03 | Lab VMs 2.7.2, 24.03 -
@stephenw10 said in Migration from 2100 to 4100:
Mmm, I agree that this could be trivially solved with the cheapest 5 port switch.
Yes, that's true and that's what I'm doing for now. But I want to avoid having a dedicated switch if possible.
However I'm of the opinion that if you have interfaces you're not using then adding them to a bridge is not necessarily a bad use. But you need to be aware of the limitations of doing so. Mostly that it loads the firewall just to pass traffic between the bridged ports.
As I mentioned before, I need the bridge only for my APs (only one is connected directly), one RPi and a home GW.
I changed the
net.link.bridge.pfil_memberto0andnet.link.bridge.pfil_bridgeto1. Do I have to configure FW rules for each bridge member explicitly even after changing those two knobs and assigning thebridge0interface to the LAN "profile"?Mesh wifi is weird though, it's ot to be something in the ARP handling there.
Were you seeing ARP requests leave the client but never arrive at the bridge?Yeah, I agree mesh is weird, but usually works nice for home networks :)
This is from
tcpdumpon the Netgate.00:18:08.679414 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.254 tell 192.168.1.59, length 60 00:18:08.837574 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.254 tell 192.168.1.16, length 60 00:18:08.841753 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.254 tell 192.168.1.97, length 46 00:18:09.108861 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.254 tell 192.168.1.60, length 60 00:18:09.151828 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.254 tell 192.168.1.63, length 60 00:18:09.210252 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.254 tell 192.168.1.15, length 60 00:18:09.236770 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.254 tell 192.168.1.79, length 60 00:18:09.679341 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.254 tell 192.168.1.59, length 60 00:18:09.839371 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.254 tell 192.168.1.16, length 60 00:18:09.868070 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.254 tell 192.168.1.97, length 46 00:18:10.109070 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.254 tell 192.168.1.60, length 60 00:18:10.152127 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.254 tell 192.168.1.63, length 60 00:18:10.260658 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.254 tell 192.168.1.79, length 60 00:18:10.633207 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.254 tell 192.168.1.15, length 60 00:18:10.679315 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.254 tell 192.168.1.59, length 60 00:18:10.889649 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.254 tell 192.168.1.97, length 46 00:18:11.108905 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.254 tell 192.168.1.60, length 60That really doesn't look good.
