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>Search


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


NE40Es Cannot be Interconnected on the Private and Public Networks Due to a Configuration and Device Implementation Problem

Publication Date:  2012-07-27 Views:  69 Downloads:  0
Issue Description
For the network topology, see the attached topology figure.
Two offices, S and N, exist on the network. Each office has two NE40Es that work as PEs, which are connected to service systems through VRRP configuration. Site personnel reported that the public and private networks could not access each other on NE40Es in office N. The same configuration, however, is viable in office S. The two offices have the same service model. One difference is that, compared with office N, in office S, office S has two more switches deployed between the NE40E and service system for Layer-2 transparent transmission.
NE40E version: V300R002C06B325 
Alarm Information
Handling Process
1. According to the feedback from site personnel, the configuration was checked first. A lookup in the command manual did not reveal any configuration problem. The normal running of office S also proved this.
The configuration of office S is as follows:
Static route for accessing the private network from the public network is:
ip route-static Vlanif145
Static route for accessing the public network from the private network is:
ip route-static vpn-instance Media public
(Note: All the IP addresses used here are 10.X.X.X. The difference between a private network and a public network is whether VPN is bound.)
After a similar command is configured in office N, however, no interconnectivity is available. But the interconnectivity becomes available after the following command is configured:
ip route-static vpn-instance Media //The nexthop is a 32-bit host route.
ip route-static vpn-instance Media public
If the static route on the public network is changed to similar configuration in office S:
ip route-static vpn-instance Media
In this case, the public network and private network cannot access each other.
2. When the problem occurred again on site, the following check was performed from office N:
First, on N-NE40E-2, the route on the public network was checked. It was found that the route is a network segment route, with an output port of vlanif11. The NE40E randomly selects a member port in vlan11 as the actual output port. On the running network, g1/0/11 is selected.
Then, the ARP entries of g1/0/11 were checked. No entry for was found. A check of the ARP entries on the interface board No.8 found that the output port of the ARP entries of was eth-trunk (this trunk port is the Layer-2 link between two PEs of the two offices, using slot 8 and running VRRP heartbeat packets).
Therefore, it can be determined that the public network could not access the private network because there was no corresponding ARP entry.
An analysis shows that the fundamental reason is as follows:
When the problem occurred, as the output port of the network segment route configured via a static route, the specific host route cannot be known on the public network. When the public network needs to access, N-NE40E-2 detects that the output port is vlanif and has to randomly select a member port in the vlan for sending a packet.
In this case, g1/0/11 is selected and an ARP request is sent through the port to learn the corresponding ARP entry. Though g1/0/11 is directly connected with, there is ARP entry for Therefore, the packet is discarded. The reason why g1/0/11 did not learn the ARP entry of is as follows:
After a confirmation of networking information shows that device in the service system has two interfaces, one active and the other standby. The standby interface is inactive.
The active interface is connected to N-NE40E-1. The standby interface is connected to N-NE40E-2. Therefore, device does not return any ARP reply from the standby port. On g1/0/11 of N-NE40E-2, no ARP entry can be generated for The ARP reply is returned from the active port to g1/0/11 of N-NE40E-1.
G1/0/11 of N-NE40E-1 is a member port of vlan11, so is the eth-trunk of N-NE40E-1. Therefore, ARP packets are sent to the eth-trunk port of N-NE40E-2 through these two interfaces in vlan11.
This shows that when vlanif works as the output port, no network segment route can be configured and a 32-bit host route needs to be configured.
This is why the 32-bit static route configured on site can realize interconnectivity. The reason why office S can be connected to the network is that a switch is deployed in between for Layer-2 transparent transmission. 
Root Cause
Mutual access between public and private networks in VPN is a simple function. Initially, it was believed that it was not a product quality problem. Therefore, the check is made in these two aspects:
1. The configuration is incorrect.
2. The problem is caused by special networking.