(solved) Bridged Interfaces Flapping after discon/recon
-
Heh fixed, sorry for the disruption.
Try next snapshot.Normally the interface will be added to the bridge during newwanip event triggering.
-
Loading the new snap right now. :)
2.2-BETA (amd64)
built on Tue Nov 25 16:45:15 CST 2014 seemed to fix it though… -
I had never really thought about bridging the WAN side until now. Just thinking out loud here…
Would there be any advantage, or disadvantage, to adding both physical interfaces to the bridge and assigning the bridge itself as the WAN? The same way it's often done LAN side.Steve
-
I had never really thought about bridging the WAN side until now. Just thinking out loud here…
Would there be any advantage, or disadvantage, to adding both physical interfaces to the bridge and assigning the bridge itself as the WAN? The same way it's often done LAN side.Steve
That is my first choice as well. With my primary box (2.1.x) Ive tried and cannot get the box to receive an address from my ISP via DHCP when I assign WAN to the bridge. Possibly something Im doing wrong or missing..??
I have a couple of DHCP available and a Static address that Ive purchased from them. I only use one DHCP but should be able to register two macs with the cable modem for DHCP before I have to re-boot yet I do reboot it while trying.. I hand the static to the server directly and control access with firewall rules.
With my test box Im trying to reproduce this in a lab setting. :)
-
Loading the new snap right now. :)
2.2-BETA (amd64)
built on Tue Nov 25 16:45:15 CST 2014 seemed to fix it though…Still good.
Below- physically unplug and reconnect event.
Nov 26 08:43:57 syslogd: kernel boot file is /boot/kernel/kernel Nov 26 08:44:04 kernel: em1: link state changed to DOWN Nov 26 08:44:04 devd: Executing '/usr/local/sbin/pfSctl -c 'interface linkup stop em1'' Nov 26 08:44:08 kernel: em1: link state changed to UP Nov 26 08:44:08 devd: Executing '/usr/local/sbin/pfSctl -c 'interface linkup start em1'' Nov 26 08:44:08 check_reload_status: Linkup starting em1 -
Can you be more clear here!
-
@ermal:
Can you be more clear here!
Sorry- ADHD.
As of 2.2-BETA (amd64)
built on Tue Nov 25 16:45:15 CST 2014The interfaces no longer flap when disconnected and reconnected.
I now have the latest as of now snaphot built on Wed Nov 26 08:02:53 CST 2014 and can report that the interfaces still behave and do not flap when disconnected and reconnected.
-
One thing that might be an issue is that the bridge interface, because it's not a physical device, doesn't have a MAC address. In order to operate like any other interface a MAC is generated when the bridge is created. However the MAC may be obviously fake and can change at each boot. Either of those could be causing an issue for dhcp. You can spoof the MAC on the bridge to prevent it though.
This was true in 2.1.X anyway, not tried it in 2.2.Steve
-
You can spoof the MAC on the bridge to prevent it though.
This was true in 2.1.X anyway, not tried it in 2.2.Steve
I have tried spoofing the mac but Im not as good at taking notes as I should be. With the American holiday tomorrow I may spend some time messing again with the primary box and see if I can make it work. It seems like I am just missing something. Ill do my best to document better as I try. ;D
Thanks!
-
In that circumstance, it may or may not be better to assign the bridge itself as WAN. Probably doesn't matter either way. One thing that'll bite you in that circumstance is the bridge has a virtual MAC address that's randomly generated when the bridge is created, hence will be different at each boot unless you specify a MAC under Interfaces>(whichever is the bridge). What I typically do there in situations where you don't want the bridge interface's MAC to ever change is just statically configure the MAC it sets automatically so it'll stick to that.
Your ISP not allowing a different MAC than your physical WAN NIC is probably why it didn't work that way. Setting the bridge to something specific, and doing whatever you need to do to change MACs with your ISP (usually just power cycle your modem) should work.
-
@cmb:
Your ISP not allowing a different MAC than your physical WAN NIC is probably why it didn't work that way. Setting the bridge to something specific, and doing whatever you need to do to change MACs with your ISP (usually just power cycle your modem) should work.
Thanks Chris!
I played with it for about a half a day recently and just had no luck. Being that it is the primary I have to pick and choose the downtime so tomorrow looks good for a re-review.
With the Watchguard Im using the Macs decrease the last octlet from interfaces 0-3. I usually just go one higher or lower when I clone. Ill do a full reboot of everything tomorrow and see If I can make it work. It is working just fine the way it is now but at this point Im curious. :)
-
Yep, Chris explained it better. ;)
I'd be interested to hear either if this helps you connect or if you think it actually helps at all.Steve
-
I did a quick writeup that I hope makes sense-
https://forum.pfsense.org/index.php?topic=84680.0
