Problem with ethernet ports
I have a SuperMicro X7SPE-HF-D525 with 2 built in intel ports. I also had a add on card with for a third port. This config was working fine but I wanted to add a 4th port.
When I removed the add on card and added a 2 port add on card, I started having issues.
The built in ports are not working properly with pfsense (ver 2.3.4). I see them when I go to assign ports but they do not properly show the port as being up or down. I see some sort of error assigning arp….....
I removed the 2 port external card and even factory defaulted pfsense (and reset the bios) but the software just doesn't seem to be happy with the internal ports, even with no additional ports installed.
The 2 add on ports did work fine.
I'm almost at the point of getting a 4 port card and disabling the two internal ports.
Am I must being a NOOB here?
heper last edited by
You could try to Reset bios to factory defaults. Also could try using a different pcie slot.
Even when I removed the 2 port ethernet card the on-board ethernet wasn't being reported properly.
I reset BIOS and did a fresh install of PF. NADA.
I went out and bought a 4 port NIC. If that works, I'll just disable the on-board NICs via jumpers.
Can you say exactly what the errors are you're seeing?
It would be surprising to see issues with Intel NICs. Especially of that age where I'm guessing they are detected as em?
It was something to the effect of:
arpresolve: can't allocate….. (I don't recall the rest)
And yes, it is recognizing them as em2 and em3.
I would have thought that a fresh install would resolve any arp table issues in PF. But then again, what do I know…
Hmm, arp resolve errors are usually a result of a layer 2 issue but could be a symptom not a cause.
But 'cannot allocate'…..something could be more significant. You may have exhausted the available mbufs for example.
We'd need to see the full error message to know more.
For now I am using the 2 port NIC and have turned off the on-board Ethernet ports. My plan is to abandon the on-board Ethernet altogether and go with a 4 port NIC.
If I get the problem again with the 4 port, I will surely update this thread.
If that is unreasonable, please advise.
PS: my current MBUF usage is 15% (4056/26368). This for a router that is basically just handling a few VOIP phones. Seems high??
That does not seem high at all I would not worry about levels like that.
The more interfaces and cores you add the more mbufs may get used even if there is no traffic.
I would expect to be able to use those on-boards NICs. Not using them seems like a waste IMO but…. if it aint broke. ;)
So I received a 4 port NIC and I put it in. Same problem. em0 and em1 work fine. em2 and em3 are reported by PF (V 2.3.3) but incorrectly display up / down status when plugging in the Ethernet.
I am checking for the port status by selecting 1 (assign ports) at the console.
As a NOOB, I'm not even sure where to go from here. If anyone has step by step things to check for, I would be very appreciative.
Did I say UGH already???
You are seeing the same symptoms but with ports on the new NIC?
That seems statistically unlikely at least.
Are you confident you're checking the correct port? pfSense will label the NICs in the order they are detected and when you add a new card that order can change. So the ports that were em0 and em1 before you added it may not be now.
Were you able to get the complete error you were seeing previously?
Thank you for the reply. I am sure that I was checking the correct ports.
When I got into the web config, it looked like the port status was reporting correctly, so I trudged ahead and configured everything, hoping it would be good.
Low and behold, the ports are all working on the NIC card (I did not re-enable the on-board NIC).
I know what I saw on the console. It was not reporting correctly. But things seem to be working now, though I do have some ipsec messages in the log that I do not understand.
e.g.: Oct 2 11:26:29 charon 14[KNL] <con1000|4>unable to query SAD entry with SPI c3567c27: No such file or directory (2)
This connection happens to be on one of the ports that was questionable.
But everything seems to be working so I guess I'll leave well enough alone.
Ah, good news. :)
The log message from Strongswan is normal. When the SA is rekeyed the old value is destroyed and if the other side sends further packets using it you see that logged. You would normally see the new SA negotiation complete also logged there and should not see any loss of traffic.