This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

xg210 lan interface stops responding for a few seconds every 4 hours

Hi guys, I hope everyone is doing well.

I am experiencing a curious problem with my XG 210. The LAN interface (Port1) simply stops responding for about 30s. The curious thing is that this occurs religiously every 4 hours.

- I have already changed interface speed and operating mode settings

 - I already reviewed syslog and other logs and nothing was found

- I have already monitored the Switch and noticed that the interface is not disconnected

- I already switched Switch, cable etc (Although of course it is not a hardware problem)

It's been a week since I updated to version 18.0.4 MR-4, but the problem started to happen since January 21, 2021 and the appliance was still in version 17.5.12 MR-12. Has anyone had this problem?



This thread was automatically locked due to age.
  • 'pathping' may be another useful troubleshooting tool (from Windows 10)  It works as a combination of ping and tracert, and you leave it running for a few minutes (around the time you are getting the problem)

    It will test the whole path to the external IP, say 8.8.8.8, and tell you where the packets are being dropped.  You are expecting them to be dropped in the XG, but it may be worth verifying this is true.

  •    Some update of the problem.

    - set up a Lan ip on port3 and set it in the Lan zone and realized that for port 3 the failure does not occur

    - today I made a TCPDump capture and found it strange at the time of failure these ARP requests on ports 1,3,5 on the firewall's own IP.

    08:32:49.589214 Port1, OUT: ARP, Reply 192.168.1.1 is-at 7c:5a:1c:xx:xx:xx, length 28
    08:32:49.619697 Port1, OUT: IP 192.168.1.1.38727 > 192.168.1.9.53: 27895+ A? chat.cdn.whatsapp.net. (39)
    08:32:49.632652 Port3, IN: ARP, Request who-has 192.168.1.1 tell 192.168.1.1, length 46
    08:32:49.632653 Port1, IN: ARP, Request who-has 192.168.1.1 tell 192.168.1.1, length 46
    08:32:49.632655 Port5, IN: ARP, Request who-has 192.168.1.1 tell 192.168.1.1, length 46
    08:32:49.776296 Port5, IN: ARP, Request who-has 192.168.1.9 tell 192.168.1.1, length 46
    08:32:49.776299 Port3, IN: ARP, Request who-has 192.168.1.9 tell 192.168.1.1, length 46
    08:32:49.776300 Port1, IN: ARP, Request who-has 192.168.1.9 tell 192.168.1.1, length 46
    08:32:50.016317 Port5, IN: ARP, Request who-has 192.168.1.3 tell 192.168.1.1, length 46
    08:32:50.016319 Port3, IN: ARP, Request who-has 192.168.1.3 tell 192.168.1.1, length 46
    08:32:50.016321 Port1, IN: ARP, Request who-has 192.168.1.3 tell 192.168.1.1, length 46
    08:32:50.073558 Port5, IN: ARP, Request who-has 192.168.1.1 (ff:ff:ff:ff:ff:ff) tell 192.168.2.123, length 46
    08:32:50.073559 Port3, IN: ARP, Request who-has 192.168.1.1 (ff:ff:ff:ff:ff:ff) tell 192.168.2.123, length 46
    08:32:50.073560 Port1, IN: ARP, Request who-has 192.168.1.1 (ff:ff:ff:ff:ff:ff) tell 192.168.2.123, length 46
    08:32:50.073571 Port1, OUT: ARP, Reply 192.168.1.1 is-at 7c:5a:1c:xx:xx:xx, length 28
    08:32:50.140041 Port5, IN: ARP, Request who-has 192.168.1.1 tell 192.168.1.220, length 46

    I didn't find anything else that could help to identify the reason for the failure on port1.

    On Sunday I will change everything to port3, including any rules that may exist and see if this will work or if the problem will follow.