ARP and llinfo error on interface drop when interface has a static route.

[ChrisCCC]

Hi All,

I'm running pfSense 2.1.5 (Can't run higher at the moment due to stability issues we experienced with 2.2.6 during testing). I have multiple interfaces configured on different VLANS on one physical interface (em1) of my router.

I have recently noticed that when I add a new VLAN to the interface, I lose ARP resolution and all existing ARP entries, for all interfaces on the physical adapter. I also see "arpresolve: can't allocate llinfo for <ip>" logged. After a little trial and error I worked out that I see the same result for any process which causes interruption to the adapter in any way (physically unplugging and plugging back in, for example, has the same effect).

After testing for much of Friday I've managed to work out that the only interfaces that are affected are those which have routes setup on them. If I setup a new interface on em1 but don't configure a static route, I can interrupt the connectivity of the adapter and all interfaces stop resolving ARP except the newly added interface. Likewise, I can cause the issue to occur and then remove the route from one of the affected interfaces and, after applying the change, that interface will start to resolve ARP again.

I figured most of this out last thing Friday, and don't have much info beyond these basic findings. I'll be investigating further tomorrow and will hopefully be able to try on different hardware to eliminate that as the cause. In the meantime I thought I'd post here in case anyone has seen any similar behaviour in the past. I've searched these forums and trawled Google and have been unable to find anything that seems to match my issue.

Any input on this problem will be gratefully received as a minor connectivity blip has potential to cripple the network at the moment.

Many thanks in advance.</ip>

[David_W]

An old thread on the Overclockers forum suggests that this is a problem with apinger, the monitoring daemon.

apinger is a very troublesome piece of code. In 2.3, apinger has been replaced by dpinger, which is vastly superior. Repeat your tests with the latest 2.3 beta snapshot - if the issue cannot be reproduced there, then the issue is resolved in a forthcoming version and no further effort need be expended on investigating the issue.

Though it is still a beta version, the pfSense 2.3 base system is now pretty stable and contains numerous valuable fixes over pfSense 2.2. The main shortcoming of 2.3 at this time is with packages - some packages are unavailable for 2.3 whilst others do not have a fully functional GUI.

To get a failed pre-2.3 system back into operation, the chances are that all you need to do is restart apinger (for example using Status -> Services). If you don't need gateway monitoring, you may be best choosing "Disable gateway monitoring" for the affected gateway(s) until such time as you can upgrade to 2.3.