PfSense and Disabled Interfaces
-
Good afternoon.
Faced with this.
Added 2 network cards. Assigned them to new interfaces. Reconfigured for these 2 new interfaces. Everything worked well.
But since this is due to the transition from the old IPtables server to fully PfSense and it was only testing (not everything worked out) so far, I unchecked ENABLE from these two new interfaces and disconnected the network cables accordingly. Those. so that the configuration remains, taking into account the new 2 network cards, and something could be changed further.
After the reboot, PfSense stopped working normally, for example PPPOE did not connect at all - no carrier. Everything just recovered after I removed 2 added network cards from PfSense altogether,
I repeat that with 4 boards and connected network cables everything worked as it should.
It is confusing that when you add 2 cards back, you probably have to repeat the configuration. And I noticed for a long time that disconnecting the cable from the network board on PfSense has a bad effect.
What do you advise?
Maybe somehow you need to disable the interfaces in order to enable them later?
Those. with PfSense stops working normally if you disconnect part of the interfaces and part of the network cables -
Most likely the interfaces were re-ordered when you added additional NICs such that the PPPoE parent was no longer actually connected to the modem.
Where the new NICs using the same driver type as the existing NICs? For exmaple all igb?
If you do that you have to test which NIC is which interface. What was igb0 may have moved to one of the new NICs as it's based entirely on the order in which they are detected at boot.
Steve
-
@stephenw10
there were 2 PPPOE (with 4 NICs) - just PPPOE0-re0 and PPPOE1-re1. But I checked everything - everything is in order with the numbering. At least in Assigned Interfaces. Although there really was a strange thing: no carrier on re0 with the cable connected. But if you remove the cable - active. The same goes for re1. This is with 2 disabled interfaces. And the cable flashed at this moment into both re0 and re1.I also noticed that for some reason the table state was filled up to 150,000 entries. Well, not right away, but for some time. Although from where - it is not clear. Only LAN worked fine. And the processor advanced to 90%.
The second network card from which the network cable was disconnected - ae 0 ip static. So she gets up after a while:
kernel ae0: phy read timeout: 17.
kernel arpresolve: can't allocate llinfo for on ae0I repeat, when 4 network cables are connected to 4 network cards, everything works as it should.
Why on
2.4.4-RELEASE-p3 (amd64)
built on Wed May 15 18:53:44 EDT 2019 FreeBSD 11.2-RELEASE-p10
disconnecting network cables is so affected. -
So what interfaces/NICs did you have on the firewall total?
ae(4) is pretty old, what hardware is this running on?
Steve
-
@stephenw10
was:
Wan - PPPOE0 - re0 -RealTek 8168/8111
Lan - ip static - fxp0 - Intel 82559 Pro / 100 Ethernet>.
Great job for months.added:
Wan1 - PPPOE1 - re1
Opt - ip static - ae0
Great job during testing.Then he disconnected the network cables (it was necessary to return the main router to work) from the added cards, rebooted and nothing worked except Lan. What I noticed - I tried to describe in the posts above.
L2TP VPN also flew while using 4 cards - no proposal encryption in ipsec.log. But he worked for several months without errors. This is restored from backup.Now there are Wan and Lan. But you need +2 - and without the described surprises.
The equipment is old - you noticed it correctly. But you have to deal with it.
CPU: Genuine Intel (R) CPU 2140 @ 1.60GHz (1600.01-MHz K8-class CPU)If the matter is in specific equipment, then on Monday I will describe in more detail this equipment.
-
Hmm, well I would guess the new re(4) card replaced the old one and became re0.
The only way to know for sure would be to check the MAC addresses.
You should obviously see one card with media status when only one cable is connected but you reported odd behaviour there.Steve
-
@stephenw10 said in PfSense and Disabled Interfaces:
You're right. Yes really network cards were messed up (by FreeBSD itself). re0 became re1, and vice versa. Defined it as you advised on MAC addresses.
Changed their places in the slots. re0 became re0, re1 became re1.kernel ae0: phy read timeout: 17.
kernel arpresolve: can't allocate llinfo for on ae0
In the interface properties, remove auto-negotiation and set the exact connection speed, for example 100 FD.