Gateway offline, Packetloss
-
Hmm, you might check it's actually sending it.
If you run a packet capture on WAN and filter by ARP and the gateway IP then I expct that to see the ARP renewal sent by pfSense.
With the pcap running delete the entry for the gateway in the ARP table. If you refresh the page I expect it to be immediately replaced.
The pcap should then have the ARP request and reply shown.In your previous pcap that immediately restarted traffic.
The only other scenario that comes to mind that present like that is if the ARP entry in pfSense is wrong for some reason. But the pcap shows it sending to the correct MAC.
Steve
-
@stephenw10 Okay! I m confused sir, what to do?
-
What can i do to replace the mac address for the gateway ?
-
The MAC for the gateway should appear in the ARP table immediately unless the gateway doesn't reply to the ARP query. It did reply though in the pcap you uploaded. Both times pfSense queried it. You shouldn't need to do anything there.
-
@stephenw10 The ARP table detected the hostname for a sec of the ISP, but then it disappeared again.
-
The hostname doesn't matter, only the MAC and IP address are important.
-
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
