Migration from 2100 to 4100

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