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

Service was interrupted due to global traffic policy

Publication Date:  2016-05-06 Views:  211 Downloads:  0
Issue Description

Customer reports a problem phenomenon that traffic to some special websites was unreachable, after traceroute the website on the gateway NE40E-X8A, it works fine. But after a random time, this issue reoccur again, even pinging IP addresses of the websites is not reachable.

As we can see the topology below, in normal flow procedure, when gateway NE40E receives the traffic from internal hosts in vlan 4 to Internet websites, it will redirect the traffic to Firewall in vlan 5, then Firewall NAT source IP of hosts and forward the traffic back to NE40E in vlan 6. After receiving traffic from vlan 6, NE40E will route the traffic to ISP.


Customer configures the traffic policy on interface as below:

NE40E-X8A V600R008C10SPC300

#
acl 3000
rule 5 permit ip source 192.168.1.0 0.0.0.255  //The network of Internal hosts
#
traffic classifier nat operator or
if-match acl 3000
#
traffic behavior nat
redirect ip-nexthop 192.168.50.2        //The IP of NAT Firewall
#
traffic policy NAT
share-mode
statistics enable
classifier nat behavior nat
#
interface GigabitEthernet1/0/6
portswitch
undo shutdown
port link-type trunk
port trunk allow-pass vlan 4 to 6 
stp root-protection
traffic-policy NAT inbound vlan 4
undo dcn
#

Alarm Information
None
Handling Process

1. During the problem existing, we traceroute the websites on host, it stops at the first hop (gateway NE40E)

2. According to the flow procedure, when NE40E receives traffic from 192.168.1.0/24, it will redirect the traffic to 192.168.50.2. So we enable traffic-statistics on interface G1/0/6 which connect NAT Firewall, but the result is no packets redirected.

[Huawei 40E-acl-adv-3999]disp traffic policy  statistics  interface  g1/0/6 vlan  5 outbound v r
Interface: GigabitEthernet1/0/6 , Vlan: 5
Classifier: test operator or
if-match ACL 3999
  rule 5 permit icmp source 192.168.1.251 0 destination x.x.x.x 0
    0 bytes, 0 packets
    Last 30 seconds rate 0 pps, 0 bps

3.From step1 and step2, we can get conclusion that packets from 192.168.1.0/24 arriving at NE40E but don't redirect to NAT Firewall correctly, it seems that traffic policy nat in interface G1/0/6 doesn't take effect. At the meanwhile, we find another traffic policy enabled in system-view.

#
traffic-policy NAT inbound
#

4.We double confirm with customer, this global traffic-policy in system-view is not in used. After removing this traffic-policy, internal hosts can access the websites which cannot reach before.

Root Cause

After enabling traffic-policy in system-view, the flow proccess procedure changes a lot.

1. If there is no global traffic policy, redirect next-hop will be proceeded directly, that means the traffic will be redirected on the inbound interface directly.


2. If global traffic policy enabled, NE40E will check routing entry/ARP entry/MAC entry of the next hop, and then proceed redirect next-hop procedure.


3. In this case, there are two outgoing interfaces, the uneachable website go through vlanif801 with next-hop x.x.218.108, other traffic go through vlanif801 x.x.219.69

[Huawei 40E]disp ip rout x.x.189.167
Route Flags: R - relay, D - download to fib
------------------------------------------------------------------------------
Routing Table : Public
Summary Count : 1
Destination/Mask    Proto   Pre  Cost      Flags NextHop         Interface

     x.x.0.0/16  EBGP    255  0           D   x.x.218.108 Vlanif801

[Huawei 40E]disp ip rout 8.8.8.8
Route Flags: R - relay, D - download to fib
------------------------------------------------------------------------------
Routing Table : Public
Summary Count : 1
Destination/Mask    Proto   Pre  Cost      Flags NextHop         Interface

        8.8.8.0/24  EBGP    255  0           D   x.x.219.69  Vlanif801

During the problem existing, there is only ARP entry for x.x.219.69 but no ARP for x.x.218.108. So, according to the procedure above, traffic from internal hosts was dropping before redirect next-hop.

[Huawei 40E]display arp vlan 801
IP ADDRESS      MAC ADDRESS     EXPIRE(M)  TYPE                           INTERFACE   VPN-INSTANCE
                                                                            VLAN/CEVLAN PVC
x.x.219.69          544b-8cf5-8fc4        12               D-0                             GE1/0/1
                                                                            801/-

If we do traceroute to the website, NE40E trigger ARP learning. This can explain why hosts can access the website after traceroute on NE40E.

[Huawei 40E]display arp vlan 801
IP ADDRESS      MAC ADDRESS     EXPIRE(M)  TYPE                           INTERFACE   VPN-INSTANCE
                                                                            VLAN/CEVLAN PVC
x.x.219.69          544b-8cf5-8fc4        12               D-0                             GE1/0/1
                                                                             801/-
x.x.218.108         8071-1ff2-0533        18              D-0                             GE1/0/1                                                               
                                                                             801/-

4. To sum up, after enabling global traffic policy, NE40E will check routing, ARP and MAC of next-hop before redirect procedure, but it will not trigger ARP learning but just drop the packets if there is no ARP entry of next-hop.

Solution
Removing the global traffic policy which is not used in this case.
Suggestions
From the analysis above, we can see process procedure of global traffic policy is not reasonable. It should trigger ARP learning when no ARP entry in ARP table.

END