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.
Parents
  • FormerMember
    0 FormerMember

    Hi ,

    Thank you for reaching out to the Community! 

    When this issue occurs, run the traceroute command from the workstation to google.com and take a packet capture on the firewall. 

    Could you show us the output of the "ifconfig" command for Port1? 

    Thanks,

  • Thanks for the answer

    I don't think tracert is going to help much. I leave a ping running from my machine towards the IP of XG's Lan and I notice that the ping always loses packets at the same times: 04:18 am, 08:18 am, 12:18 pm, 04:18 pm 08:18 pm, 12:18 am.

    The impression I have is as if there is a routine in XG that reloads the firewall rules or simply reloads the network interface.

    I have an open case in Brazil's support, but it hasn't helped me much.

    Port1     Link encap:Ethernet  HWaddr 7C:5A:1C:4A:82:38
              inet addr:192.168.1.1  Bcast:192.168.255.255  Mask:255.255.0.0
              inet6 addr: fe80::7e5a:1cff:fe4a:8238/64 Scope:Link
              UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
              RX packets:108831544 errors:0 dropped:0 overruns:0 frame:0
              TX packets:145308612 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:1000
              RX bytes:40844307424 (38.0 GiB)  TX bytes:136560654162 (127.1 GiB)

Reply
  • Thanks for the answer

    I don't think tracert is going to help much. I leave a ping running from my machine towards the IP of XG's Lan and I notice that the ping always loses packets at the same times: 04:18 am, 08:18 am, 12:18 pm, 04:18 pm 08:18 pm, 12:18 am.

    The impression I have is as if there is a routine in XG that reloads the firewall rules or simply reloads the network interface.

    I have an open case in Brazil's support, but it hasn't helped me much.

    Port1     Link encap:Ethernet  HWaddr 7C:5A:1C:4A:82:38
              inet addr:192.168.1.1  Bcast:192.168.255.255  Mask:255.255.0.0
              inet6 addr: fe80::7e5a:1cff:fe4a:8238/64 Scope:Link
              UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
              RX packets:108831544 errors:0 dropped:0 overruns:0 frame:0
              TX packets:145308612 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:1000
              RX bytes:40844307424 (38.0 GiB)  TX bytes:136560654162 (127.1 GiB)

Children
  • FormerMember
    0 FormerMember in reply to Cristiano Monteiro

    Hi ,

    Running traceroute and packet capture simultaneously would help identify where the traffic stops and for what reason.

    Try to turn off firewall acceleration by running the following command from the console and see if that helps. 

    console>system firewall-acceleration disable

    Thanks,

  • Hi H_Patel, good morning

    I disabled firewall acceleration but unfortunately the problem still persists.

    Below the tracert at the time of Lan's failure the first jump (in this case the XG) is not reached.

    Rastreando a rota para dns.google [8.8.8.8]
    com no máximo 30 saltos:

      1     *        *        *     Esgotado o tempo limite do pedido.
      2     *        *        *     Esgotado o tempo limite do pedido.
      3     *        *        *     Esgotado o tempo limite do pedido.
      4     *        *        *     Esgotado o tempo limite do pedido.
      5     *        *       11 ms  172.24.0.81
      6    11 ms    10 ms    10 ms  172.24.0.38
      7     9 ms    10 ms    13 ms  72.14.213.32
      8    12 ms    11 ms    20 ms  108.170.251.65

    Resposta de 192.168.1.1: bytes=32 tempo=2ms TTL=64
    Resposta de 192.168.1.1: bytes=32 tempo=2ms TTL=64
    Esgotado o tempo limite do pedido.
    Esgotado o tempo limite do pedido.
    Esgotado o tempo limite do pedido.
    Esgotado o tempo limite do pedido.
    Esgotado o tempo limite do pedido.
    Esgotado o tempo limite do pedido.
    Esgotado o tempo limite do pedido.
    Esgotado o tempo limite do pedido.
    Esgotado o tempo limite do pedido.
    Esgotado o tempo limite do pedido.
    Esgotado o tempo limite do pedido.
    Esgotado o tempo limite do pedido.
    Esgotado o tempo limite do pedido.
    Esgotado o tempo limite do pedido.
    Resposta de 192.168.1.1: bytes=32 tempo=2ms TTL=64
    Resposta de 192.168.1.1: bytes=32 tempo=3ms TTL=64

    The wan interfaces work normally, because I accessed the XG by the Wan address and pinged the internal network, but also without an answer.

     

    The hard thing is that nothing appears in the syslog or network logs. it seems that there is some type of scheduling that restarts some service every 4 hours, but I have not found where this is configured.

    Best regards.

  • FormerMember
    0 FormerMember in reply to Cristiano Monteiro

    Assuming 192.168.1.1 as Port1 interface IP address.

    Request to collect tcpdump and drop-packet-capture at the time of instance.

    Open two SSH sessions > 4. Device Console

    To collect tcpdump: console> tcpdump 'host 192.168.1.1 and proto ICMP

    To collect drop-packet: console> drop-packet-capture 'host 192.168.1.1 and proto ICMP


    It could be an issue with the internal network as well. To confirm that, is it possible to connect a laptop/desktop directly with Port1 interface in non-working hours to take an observation?

  • Thanks for the answer.

    Internal network I believe it is not. I already changed the lan interface of the XG switch including cables. But during the problem I can't access the appliance through the lan, but I can access it through the Wan from another firewall.

  •    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.