New ISP - arpresolve: can't allocate llinfo for X.X.X.X on mvneta0.4090
-
@cfrudolphy said in New ISP - arpresolve: can't allocate llinfo for X.X.X.X on mvneta0.4090:
Nov 14 22:00:05 dhclient 2500 bound to 146.86.167.83 -- renewal in 302400 seconds.
Ok the first thing I would do here is set a shorter lease request in the dhcp client advanced options. Though it should already request a lease time of 2hrs by default but is being passed am 84hr lease which is very long.
Then it looks like the client is closing the connection before the default renewal at 50% of the lease time.
So something like:
Steve
-
You could also try in the 'option modifiers' field something like:
supersede dhcp-renewal-time 3600So the client renews the lease every hour.
Steve
-
Steve, made all changes you have suggested then released and renewed lease. We will see how it goes and I will let you know. I did go look at the filtered DHCP log and after renewal of lease here is the last line:
Nov 15 18:35:52 dhclient 65046 bound to 146.86.167.83 -- renewal in 1800 seconds.
Yet I did put in as you suggest 3600 as a value not 1800. Even if it renews every 30 minutes as opposed to an hour as long as it doesn't drop then I am ok. Will let you know in the morning.
Thanks much for your help! Have a good evening and I will post again in the morning.
Chuck
-
If you requested a lease time of 3600s and the server gave that you then it would try to renew at 1800s. It should always renew before the lease expires.
Steve
-
@stephenw10 Steve, I am still having issues. Since the changes you suggested, less frequently, but still too much. Beginning to wonder if this is a pfSense issue or an ISP issue. I will try to explain.
Since we added the line "dhcp-lease-time 3600" used the Presets radio button for pfSense Default. It tries to renew the DHCP lease every 1800 seconds (30 minutes) like clock work. Some times it renews and sometimes it doesn't. See this most recent snippet from the log:
Nov 16 14:16:07 dhclient 73086 bound to 146.86.167.83 -- renewal in 1800 seconds.
Nov 16 14:16:07 dhclient Creating resolv.conf
Nov 16 14:16:07 dhclient /sbin/route add default 146.86.160.1
Nov 16 14:16:07 dhclient Adding new routes to interface: mvneta0.4090
Nov 16 14:16:07 dhclient New Routers (mvneta0.4090): 146.86.160.1
Nov 16 14:16:07 dhclient New Broadcast Address (mvneta0.4090): 146.86.167.255
Nov 16 14:16:07 dhclient New Subnet Mask (mvneta0.4090): 255.255.248.0
Nov 16 14:16:07 dhclient New IP Address (mvneta0.4090): 146.86.167.83
Nov 16 14:16:07 dhclient ifconfig mvneta0.4090 inet 146.86.167.83 netmask 255.255.248.0 broadcast 146.86.167.255
Nov 16 14:16:07 dhclient Starting add_new_address()
Nov 16 14:16:07 dhclient BOUND
Nov 16 14:16:07 dhclient 73086 DHCPACK from 146.86.160.3
Nov 16 14:16:07 dhclient 73086 DHCPREQUEST on mvneta0.4090 to 255.255.255.255 port 67
Nov 16 14:16:07 dhclient ARPCHECK
Nov 16 14:16:05 dhclient ARPSEND
Nov 16 14:16:05 dhclient 73086 DHCPOFFER from 146.86.160.3
Nov 16 14:16:05 dhclient 73086 DHCPDISCOVER on mvneta0.4090 to 255.255.255.255 port 67 interval 1
Nov 16 14:16:05 dhclient PREINIT
Nov 16 14:16:05 dhclient Deleting old routes
Nov 16 14:16:05 dhclient EXPIRE
Nov 16 14:15:28 dhclient 73086 DHCPREQUEST on mvneta0.4090 to 255.255.255.255 port 67
Nov 16 14:14:58 dhclient 73086 DHCPREQUEST on mvneta0.4090 to 255.255.255.255 port 67
Nov 16 14:14:13 dhclient 73086 DHCPREQUEST on mvneta0.4090 to 255.255.255.255 port 67
Nov 16 14:13:45 dhclient 73086 DHCPREQUEST on mvneta0.4090 to 255.255.255.255 port 67
Nov 16 14:13:26 dhclient 73086 DHCPREQUEST on mvneta0.4090 to 255.255.255.255 port 67
Nov 16 14:13:12 dhclient 73086 DHCPREQUEST on mvneta0.4090 to 255.255.255.255 port 67
Nov 16 14:12:58 dhclient 73086 DHCPREQUEST on mvneta0.4090 to 255.255.255.255 port 67
Nov 16 14:12:45 dhclient 73086 DHCPREQUEST on mvneta0.4090 to 255.255.255.255 port 67
Nov 16 14:11:57 dhclient 73086 DHCPREQUEST on mvneta0.4090 to 255.255.255.255 port 67
Nov 16 14:11:26 dhclient 73086 DHCPREQUEST on mvneta0.4090 to 255.255.255.255 port 67
Nov 16 14:10:52 dhclient 73086 DHCPREQUEST on mvneta0.4090 to 255.255.255.255 port 67
Nov 16 14:10:34 dhclient 73086 DHCPREQUEST on mvneta0.4090 to 255.255.255.255 port 67
Nov 16 14:10:04 dhclient 73086 DHCPREQUEST on mvneta0.4090 to 255.255.255.255 port 67
Nov 16 14:09:08 dhclient 73086 DHCPREQUEST on mvneta0.4090 to 255.255.255.255 port 67
Nov 16 14:08:25 dhclient 73086 DHCPREQUEST on mvneta0.4090 to 142.202.164.42 port 67
Nov 16 14:08:10 dhclient 73086 DHCPREQUEST on mvneta0.4090 to 142.202.164.42 port 67
Nov 16 14:08:00 dhclient 73086 DHCPREQUEST on mvneta0.4090 to 142.202.164.42 port 67
Nov 16 14:05:55 dhclient 73086 DHCPREQUEST on mvneta0.4090 to 142.202.164.42 port 67
Nov 16 14:03:24 dhclient 73086 DHCPREQUEST on mvneta0.4090 to 142.202.164.42 port 67
Nov 16 14:02:12 dhclient 73086 DHCPREQUEST on mvneta0.4090 to 142.202.164.42 port 67
Nov 16 14:01:29 dhclient 73086 DHCPREQUEST on mvneta0.4090 to 142.202.164.42 port 67
Nov 16 14:01:03 dhclient 73086 DHCPREQUEST on mvneta0.4090 to 142.202.164.42 port 67
Nov 16 14:00:36 dhclient 73086 DHCPREQUEST on mvneta0.4090 to 142.202.164.42 port 67
Nov 16 14:00:28 dhclient 73086 DHCPREQUEST on mvneta0.4090 to 142.202.164.42 port 67
Nov 16 13:59:57 dhclient 73086 DHCPREQUEST on mvneta0.4090 to 142.202.164.42 port 67
Nov 16 13:59:16 dhclient 73086 DHCPREQUEST on mvneta0.4090 to 142.202.164.42 port 67
Nov 16 13:58:40 dhclient 73086 DHCPREQUEST on mvneta0.4090 to 142.202.164.42 port 67
Nov 16 13:57:18 dhclient 73086 DHCPREQUEST on mvneta0.4090 to 142.202.164.42 port 67
Nov 16 13:56:35 dhclient 73086 DHCPREQUEST on mvneta0.4090 to 142.202.164.42 port 67
Nov 16 13:56:08 dhclient 73086 DHCPREQUEST on mvneta0.4090 to 142.202.164.42 port 67
Nov 16 13:55:37 dhclient 73086 DHCPREQUEST on mvneta0.4090 to 142.202.164.42 port 67
Nov 16 13:55:12 dhclient 73086 DHCPREQUEST on mvneta0.4090 to 142.202.164.42 port 67
Nov 16 13:54:49 dhclient 73086 DHCPREQUEST on mvneta0.4090 to 142.202.164.42 port 67
Nov 16 13:54:14 dhclient 73086 DHCPREQUEST on mvneta0.4090 to 142.202.164.42 port 67
Nov 16 13:53:06 dhclient 73086 DHCPREQUEST on mvneta0.4090 to 142.202.164.42 port 67
Nov 16 13:52:08 dhclient 73086 DHCPREQUEST on mvneta0.4090 to 142.202.164.42 port 67
Nov 16 13:51:36 dhclient 73086 DHCPREQUEST on mvneta0.4090 to 142.202.164.42 port 67
Nov 16 13:51:15 dhclient 73086 DHCPREQUEST on mvneta0.4090 to 142.202.164.42 port 67
Nov 16 13:50:58 dhclient 73086 DHCPREQUEST on mvneta0.4090 to 142.202.164.42 port 67
Nov 16 13:50:20 dhclient 73086 DHCPREQUEST on mvneta0.4090 to 142.202.164.42 port 67
Nov 16 13:49:25 dhclient 73086 DHCPREQUEST on mvneta0.4090 to 142.202.164.42 port 67
Nov 16 13:48:30 dhclient 73086 DHCPREQUEST on mvneta0.4090 to 142.202.164.42 port 67
Nov 16 13:47:42 dhclient 73086 DHCPREQUEST on mvneta0.4090 to 142.202.164.42 port 67
Nov 16 13:47:17 dhclient 73086 DHCPREQUEST on mvneta0.4090 to 142.202.164.42 port 67
Nov 16 13:47:03 dhclient 73086 DHCPREQUEST on mvneta0.4090 to 142.202.164.42 port 67
Nov 16 13:46:49 dhclient 73086 DHCPREQUEST on mvneta0.4090 to 142.202.164.42 port 67
Nov 16 13:46:25 dhclient 73086 DHCPREQUEST on mvneta0.4090 to 142.202.164.42 port 67
Nov 16 13:46:14 dhclient 73086 DHCPREQUEST on mvneta0.4090 to 142.202.164.42 port 67
Nov 16 13:46:09 dhclient 73086 DHCPREQUEST on mvneta0.4090 to 142.202.164.42 port 67
Nov 16 13:46:06 dhclient 73086 DHCPREQUEST on mvneta0.4090 to 142.202.164.42 port 67
Nov 16 13:46:04 dhclient 73086 DHCPREQUEST on mvneta0.4090 to 142.202.164.42 port 67
Nov 16 13:16:04 dhclient 73086 bound to 146.86.167.83 -- renewal in 1800 seconds.
Nov 16 13:16:04 dhclient Creating resolv.conf
Nov 16 13:16:04 dhclient RENEW
Nov 16 13:16:04 dhclient 73086 DHCPACK from 142.202.164.42
Nov 16 13:16:04 dhclient 73086 DHCPREQUEST on mvneta0.4090 to 142.202.164.42 port 67
Nov 16 12:46:05 dhclient 68827 bound to 146.86.167.83 -- renewal in 1800 seconds.My summary of the above:
1.) As you can see from the above the lease was renewed at 12:46:05 for 1800 seconds.
2.) It started the renewal process again at 13:16:04 and was successful.
3.) It started the renewal process again at 13:46:04. Between 13:46:04 and 14:15:28 (1764 seconds) it made 51 requests to 142.202.164.42 port 67 (I know that this IP represents the ISP's DNS server don't know about DHCP) but requests to this IP in the past (13:16:04) worked. Then at 14:15:28 it "EXPIRED".
4.) At 14:16:05 I went to Status -> Interfaces then under WAN clicked the button to "Release" and confirmed and then clicked the button to "Renew" and confirmed.
5.) It then sent a discover packet to 255.255.255.255 received an offer fro 146.86.160.3 sent some ARP packets then sent a request, received an acknowledgement, and then renewed the lease.Based on the above sequence of events I have the following questions:
1.) It worked at 13:16:04 then failed at 13:46:04. Is this a pfSense issue or an ISP issue?
2.) I am confused, approximately 3/4 way through its 51 requests it switched from sending "DHCPREQUEST" packets from 142.202.164.42 to 255.255.255.255. Where at 14:16:05 it send a "DHCPDISCOVER" packet to 255.255.255.255. It makes sense to me to send the "discover" packet to the broadcast address, it does not make sense to me to send a "request" packet to the broadcast address.
3.) Every time I release and renew the lease manually it receives a response from 146.86.160.3 not 142.202.164.42. Within that process it discovers the other router at 146.86.160.1. What is going on here? Why is it requesting a renewal from 142.202.164.42 when 146.86.160.3 seems to be authoritative?
4.) Why when I go through the manual release and renewal process on the Status -> Interface page does it instantly work and when it goes through the automated process of renewing the lease it fails more times than works?Last night after we made our changes I noticed something else. Now that we are on this very regular 30 minute lease renewal I was able to very consistently predict what time it should renew. If that process failed then I would lose connectivity at that 30 minute interval. Sometimes I was losing that connectivity prior to the 30 minutes. I started looking at the ARP table at Diagnostics -> ARP Table. I don't know what the starting value of the timer is but I suspect 1200 seconds. I would use the remaining time left on the timer to predict when it would renew and sure enough very close to the calculated time I would lose connectivity. At that point I looked at the "System -> General" log and would see corresponding arpresolve messages.
That leads me to believe the following:
1.) DHCP lease renewal times are in no way co-ordinated with the ARP table timer.
2.) Failure at either causes pfSense to consider the interface "down" for a lack of a better term severing connectivity.
3.) If I had a fail-over wan setup it would then it would go through its process of directing traffic to the fail-over. As I don't have a failover available/setup and I have disabled the "Gateway Monitoring Action" what would the default now be?Note my current configuration is as follows:
System -> Routing -> Gateways
Interface: WAN
Address Family: IPV4
Name: WAN_DHCP
Gateway: Dynamic
Disable Gateway Monitoring Action: Checked
Monitor IP: 8.8.8.8 (As 146.86.160.1 doesn't respond to ping)
ADVANCED
Weight: 1
Data Payload: 1
Latency Thresholds: 200
Packet Loss Thresholds: 10
Probe Interval: 500
Time Period: 60000
Alert Interval: 1000Then in:
Interface -> WAN
Enable: Checked
Description: WAN
IPV4 Configuration Type: DHCP
IPV6 Configuration Type: None
Switch Port: 3
OPTIONS
Advanced Configuration: Checked
Protocol Timing:
TimeOut: 60
Retry: 15
Select Timeout: 0
Reboot: blank
Backoff Cutoff: blank
Initial Interval: 1
Presets: pfSense Default (radio button selected)
Send Options: dhcp-lease-time 3600
Block Private Networks: Checked
Block Bogon Networks: CheckedLong post, lots of info, I hope some of it might be useful in troubleshooting this. I tried to be as complete as I could. I hope it is not to verbose.
Let me know what you think is going on.
Thanks so much for your help!!!
Chuck
-
Yeah it's odd. What the ISP is doing is at the very least unusual!
It tries to renew the lease against the existing dhcp server at it's known IP and then switches to broadcasting for the dhcp server. I'd guess it does that 5mins before the lease expires.
I'm unsure why it doesn't switch to trying to discover any dhcp server at that point. It might be possible to configure that via a dhclient option. I have never had to though.
Switching from an 84 hour lease to 1 hour might have been a little extreme. You might try a 6 or 12h lease and see if that makes any difference there.
Steve
-
Hello, I have a Netgate 1541 and I have the exact same problem happening with my ISP. Was there ever a resolution to this?
Thanks
-
@dragonfire1119 no there was never a resolution. I tried to work with the ISP and they were of no help. I ended up having to rent one of their routers to be able to access the internet. My ISP is an electric utility that ran fiber to our neighborhood. I wanted to get away from Suddenlink (Altice) my previous ISP. Even paying the additional $10 for their router (Calis) it is still cheaper than before with symmetrical bandwidth. That is my story.
-
This post is deleted! -
@cfrudolphy thanks for the reply. We ended up calling and requesting a level 2 they said they had enough calls on level 1 which is a lot of calls to go to level 2. He fixed it on the first try. It's been working great hooked up to Calix ONT > pfsense.
Level 1 was blaming our equipment but this guy did not & actually listened to our problem which was on their end. We worked on this for 3 weeks and calling in constantly. This was some kind of DDoS attack coming through on that VLAN maybe? But the level 3s are going to have to look at it on their end.
Solution:
Switched to a static IP and to a different VLAN on their network.I would try to call in and ask for a level 2.
