Gateway offline, Packetloss
-
Okay but then how will this issue solve ?
-
It won't. You need to make sure pfSense is actually sending the ARP query when you remove the entry fro the table. That's why you are running the pcap and filtering for ARP and the gateway IP.
If your previous pcap the gateway starts to respond each time pfSense sends that query.
-
If it does then one thing we could do it set the ARP timeout much shorter. That would be a workaround though, it shouldn't be required.
sysctl net.link.ether.inet.max_age=300Steve
-
@stephenw10 Can you help me a bit sir, I don't know much about it. I deleted the gateway entry from the ARP table, what to do now ?
-
After deleting the ARP table the gateway shows as incomplete mac address.
-
Run a pcap and see what's happening. If it shows as incomplete in the ARP table that means pfSense is ARPing and the gateway isn't replying, which is not what was happening in the last pcap.
-
@stephenw10 i ll run a packet capture and send you the file in some time.
-
stephen if you look into ^my IPV6 thread (link send)^, you can see that:
- at certain moment ^pfsense^ detect that the GW is gone
- the GUI keeps that state ^for ever^
- and later on a ping shows that the GW is back again
- something not detected by ^pfSense^
So in ^my error case^ it is clear that ^pfSense^ is not behaving correctly
-
@louis2 said in Gateway offline, Packetloss:
https://forum.netgate.com/topic/173356/issues-with-ipv6
You are clearly seeing some issue there but it's with DHCPv6 over PPPoE in 2.7. None of those things are in play here so it seems unrelated to me.
Steve
-
@stephenw10 Sent the Pcap on the same old link
-
Ok, so if you look at the pcap you can see pfSense first sends an ARP query in packet 2278 and the gateway responds correctly. Then it immediately starts responding to the other traffic.
That is 776s into the pcap. Is that when you deleted the ARP entry?Traffic continues until packet 2341 at 788s. So only 12s.
But later in the pcap we see traffic for 21s and then 13s so it's not consistent.
However it is exactly the same behaviour we saw in the previous pcap. I also note it is still monitoring the gateway IP directly and not something external.
I would retest with a client directly on the connection there and see if that still works. From what we are seeing here I wouldn't expect anything using that to work for more than 20s at a time unless it's spamming ARP queries.
You could try, as a test only, setting that max_age tunable to something very low like 10s. I'm betting the connection would remain up in that situation.
This really looks like someone else is also trying to use the IP address.
Steve
-
@stephenw10 Can you please help me setting up the max age.
-
At the command line run:
sysctl net.link.ether.inet.max_age=10That can really only be as a test though. 10s is a ridiculously short ARP timeout.
Steve
-
@stephenw10 Okay Sir I will try that
-
@stephenw10 Done Sir!
-
Did it make any difference?
-
@stephenw10 I haven’t checked it yet, i m out. Can i let you know by tomorrow. Sorry !
-
@stephenw10 No Still the gateway is showing offline, I will try to do a Pcap and send you the file.
-
@stephenw10 It is working, Thank you Sir for your help. Just this command helped.
sysctl net.link.ether.inet.max_age=10 -
Ok, so that proves it's some odd ARP issue but it appears to be at the provider.
You should contact them and ask why you are having to send them ARP requests every 10s to prevent the gateway forgetting about you.
I still think it's probably another customer trying to use the same IP address. Setting the ARP timeout so low will have completely broken it for the other customer though so they will be complaining to the ISP.
I did ask this before, but just to confirm, there is no possibility that you have another device connected using the same IP?
If it was connected to the same link as pfSense you would see pfSense complaining in the logs because it would be able to see the ARP broadcasts from the other device. So I doubt that's the case.Steve
