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

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

Publication Date:  2012-07-27 Views:  34 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
Null
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 10.150.115.0 255.255.255.224 Vlanif145 10.150.115.1
Static route for accessing the public network from the private network is:
ip route-static vpn-instance Media 10.147.115.0 255.255.255.224 10.150.100.12 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 10.150.51.8 255.255.255.255 vpn-instance Media 10.150.51.8 //The nexthop is a 32-bit host route.
ip route-static vpn-instance Media 10.149.115.0 255.255.255.224 10.150.36.13 public
If the static route on the public network is changed to similar configuration in office S:
ip route-static 10.150.51.0 255.255.255.224 vpn-instance Media 10.150.51.10
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 10.150.51.8 on the public network was checked. It was found that the 10.150.51.8 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 10.150.51.8 was found. A check of the ARP entries on the interface board No.8 found that the output port of the ARP entries of 10.150.51.8 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 10.150.51.0 configured via a static route, the specific host route cannot be known on the public network. When the public network needs to access 10.150.51.8, 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 10.150.51.8, there is ARP entry for 10.150.51.8. Therefore, the packet is discarded. The reason why g1/0/11 did not learn the ARP entry of 10.150.51.8 is as follows:
After a confirmation of networking information shows that device 10.150.51.8 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 10.150.51.8 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 10.150.51.8. 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. 
 
Suggestions
Null

END