Migration from 2100 to 4100

johnpoz

@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.

mgi

@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_member to 0 and net.link.bridge.pfil_bridge to 1. Do I have to configure FW rules for each bridge member explicitly even after changing those two knobs and assigning the bridge0 interface 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 tcpdump on 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 60

That really doesn't look good.

mgi

@johnpoz It's you right to differ :)

If I eventually decide that I need more segments (I don't see any reason for that in the foreseeable future) on my home network, I can always add a switch.

We can have a different understanding of what's "wasting" — anyway yes, I'm currently also wasting a 48 port switch from my lab.

{master:0}
root@ex-tmp-homenet> show chassis hardware | match "engine" 
Routing Engine 0          BUILTIN      BUILTIN           RE-EX4400-48T

I really don't have a problem adding a small switch to my network, but I'm also interested in why the bridge is not working and I came here to ask if anyone faced a similar issue with similar setup and similar equipment. That's all.

johnpoz

@mgi said in Migration from 2100 to 4100:

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

So pfsense is not answering arp for its IP.. Where exactly is that IP assigned - the bridge interface?

mgi

@johnpoz Yes, it seems so. The IP’s on the bridge0 interface.

I found this Reddit post. Sounds as my problem, but they never really solved it.

I need to have a look again when I have some time.

johnpoz

@mgi he did solve it ;)

"and is actually a better architecture anyway as I get to kick the bridge to the curb"

he got rid of the bridge hehhehehe

stephenw10

Are the MAC addresses in that pcap correct?

Is it using a multicast MAC address?

That will be blocked by default unless you add the appropriate tunable:
https://docs.netgate.com/pfsense/en/latest/install/upgrade-before-2.2.html?highlight=mesh#microsoft-load-balancing-open-mesh-traffic

Though I wouldn't expect that to be bridge specific.

Steve

johnpoz

@stephenw10 said in Migration from 2100 to 4100:

Is it using a multicast MAC address?

I was just coming back to ask the same question ;)

mgi

@johnpoz he applied a workaround that also happens to be a solution for him ;)

mgi

@stephenw10 Thanks.

There are actually no MACs in the pcap. I even ran tcpdump with the -v option.

I don't want to say Eero's not using multicast for "something", and that it's not causing issues. I want to have a look at this again when I have some time, so I'll also try the workaround.

stephenw10

Just run the pcap in the gui and download the capture file. It will have the MACs in it.

mgi

@stephenw10

MACs look good, but still no reply.

I’ll redo the bridge config from scratch and reboot the box again (hopefully) over the weekend. I only spent a couple of minutes on this today.

If that doesn’t help, I’ll put in a small switch :)

mgi

No luck even after rebuilding the bridge.

It seems that the Eero APs can act really crazy and I would say that's the main issue. I tried to migrate all of them to a wired backhaul and that looped my network

Anyway, I like the 4100, so I decided to completely rebuild my wireless/wired network on a different kit.

I might test the bridge again at some point, but I really don't have time for this at the moment.

Thanks guys for your help and patience.

johnpoz

@mgi said in Migration from 2100 to 4100:

migrate all of them to a wired backhaul and that looped my network

so you had them all on wired and wireless for backhaul - that for sure could create a loop.. That is not what you showed in your drawing.

mgi

@johnpoz That drawing is still valid for when I was testing the bridge.

I just mentioned (off-topic) that I also tried to migrate the APs to wired backhaul, but that didn’t go well either. I decided to give up on those and redo my network completely (except Netgate).