No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

The Traffic Of One Egress Of the Firewall Dives Due To a Problem On the Peer Device

Publication Date:  2012-07-17 Views:  34 Downloads:  0
Issue Description
The customer uses the network management software to monitor the traffic at three public network egresses. The software detects that the traffic at the CNC egress dives at a certain time every day. The traffic dive reflects a network disconnection. The disconnection lasts about five minutes. This problem does not occur on the Telecom network or the education network.
Alarm Information
None.
Handling Process
  1. Check the firewall configuration. No problem is found.
 
Upon the traffic dive, the gateway can be pinged through from 192.168.100.200 (address after NAT: 218.62.42.5). The session also indicates that the gateway can be pinged through.
However, the intranet gateway cannot be pinged through from intranet addresses that are translated into 218.62.42.6 or 218.62.42.8. The session table indicates that the firewall sends the packets out but receives no response packets. Therefore, the problem originates from the CNC site. The CNC device has problem in processing packets whose destination address is 218.62.42.6 or 218.62.42.8. Probably, the CNC device has difficulty in ARP learning and refreshing.
  1. View the firewall session table.
<USG5360>display firewall  session table  verbose  destination i 218.62.42.1
10:37:18  2010/06/29
Current Total Sessions: 4
  icmp  VPN: public -> public
  Zone: trust -> cnc  TTL: 00:00:20  Left: 00:00:19
  Interface: G0/0/3  Nexthop: 218.62.42.1  MAC: 00-19-c6-01-50-41
  <-- packets:893 bytes:53580   --> packets:893 bytes:53580
  192.168.100.200:512[218.62.42.5:18317]-->218.62.42.1:512
--------------For intranet addresses that are translated into 218.62.42.5, the number of outbound packets matches the number of inbound packets. The intranet gateway can be pinged through from these IP addresses. 
icmp  VPN: public -> public
  Zone: trust -> cnc  TTL: 00:00:20  Left: 00:00:19
  Interface: G0/0/3  Nexthop: 218.62.42.1  MAC: 00-19-c6-01-50-41
  <-- packets:2533 bytes:151980 --> packets:2581 bytes:154860
  192.168.224.136:512[218.62.42.6:29208]-->218.62.42.1:512
 --------------Among the intranet addresses that are translated into 218.62.42.6, forty-eight (2581 - 2533 = 48) addresses fails to ping through the intranet gateway. The firewall sends packets out but receives no response packets. In addition, 240 S (48 x 5 S = 240 S) packets are lost. 
icmp  VPN: public -> public
Zone: trust -> cnc  TTL: 00:00:20  Left: 00:00:19
  Interface: G0/0/3  Nexthop: 218.62.42.1  MAC: 00-19-c6-01-50-41
  <-- packets:2202 bytes:132120 --> packets:2202 bytes:132120
  192.168.181.200:512[218.62.42.5:12992]-->218.62.42.1:512
--------------For intranet addresses that are translated into 218.62.42.5, the number of outbound packets matches the number of inbound packets. The intranet gateway can be pinged through from these IP addresses.
icmp  VPN: public -> public
  Zone: trust -> cnc  TTL: 00:00:20  Left: 00:00:18
  Interface: G0/0/3  Nexthop: 218.62.42.1  MAC: 00-19-c6-01-50-41
  <-- packets:4526 bytes:307768 --> packets:4553 bytes:309604
192.168.144.13:512[218.62.42.8:14191]-->218.62.42.1:512
 --------------Among the intranet addresses that are translated into 218.62.42.8, twenty-seven (4553 - 4526 = 27) addresses fails to ping through the intranet gateway. The firewall sends packets out but receives no response packets. In addition, 135 S (27 x 5 S = 135 S) packets are lost. Normally, the number of lost packets does not increase.
<USG5360>display firewall  session table  verbose  destination i 218.62.42.1                   
17:11:05  2010/06/29
Current Total Sessions: 1                                                                         icmp  VPN: public -> public
  Zone: trust -> cnc  TTL: 00:00:20  Left: 00:00:18
  Interface: G0/0/3  Nexthop: 218.62.42.1  MAC: 00-19-c6-01-50-41
  <-- packets:13761 bytes:825660        --> packets:13809 bytes:828540
  192.168.224.136:512[218.62.42.6:29208]-->218.62.42.1:512  
One day later, the value is still 48 (13809 -13761 = 48), the same as the value collected on the morning that day.
To conclude, the firewall has sent packets to the CNC gateway, but the CNC gateway does not forward packets whose destination address is 218.62.42.6 or 218.62.42.8 to the firewall. As a result, the traffic dives.
Root Cause
  1. The firewall configuration is improper.
  2. The firewall has a problem in forwarding data.
  3. The peer device is faulty.
Suggestions
None

END