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 Negotiation Between the USG2200 and the NE40 through E1 Fails

Publication Date:  2012-07-25 Views:  27 Downloads:  0
Issue Description

Since the number of E1 interfaces is insufficient, the customer replaces the original device with the USG2200. After the E1 interface is connected to the NE40, the physical and protocol layers of the E1 interfaces are Up, but they cannot be pinged through. Check the debugging information. The device fails to negotiate with the peer device during the IPCP negotiation.

Alarm Information
None.
Handling Process
According to the previous analysis, the DNS/NBNS field contained in the ConfigRequest packet that is sent by the USG2200 cannot be identified by the NE40. As a result, the peer incorrectly replies the ConfigReject packet, which does not impact the status of the E1 interface on the USG2200. Therefore, the physical-layer and logical-layer interfaces are Up, but the IPCP negotiation is not established.
Either of the following methods can be adopted to solve the problem:
Method 1: Upgrade the version of the NE40.
Upgrade the NE40 from VRPv3 to VRPv5.
The NE40 of the VRPv3 version does not support the DNS option, but the VRPv5 version does.
Method 2: Upgrade the firewall to USG2200 V100R002C01SPC200 and later versions. In the serial view, use command lines to check whether the IPCP conf_req packet should have the DNS/NBNS option.
By default, the conf_req packet on the serial interface has the DNS option, run the undo ppp ipcp dns request command to deselect the DNS option.
By default, the conf_req packet on the serial interface has the NBNS option, run the undo ppp ipcp nbns request command to deselect the NBNS option.
Root Cause
When the problem occurs, analyze debug the device and the network. The procedure is as follows:

1. Analyze related configurations

First analyze the configuration of the USG2200, and compare its configuration with the configuration of the original device. Their configurations are different only in the format of commands.
      USG2200:                                                                 
interface Serial4/0/0:0                          
 link-protocol ppp                                                  
 ip address 172.16.0.74 255.255.255.252             #                                                  
                                                
Original device:
interface Serial1
 link-protocol ppp
 fe1 unframed
 ip address 172.16.0.74 255.255.255.252
 nat outbound 2000 interface

2. Analyze the process of the packet negotiation.

According to the analysis of IPCP negotiation, the USG2200 receives a ConfRej packet. However, the error information received wrong Reject! is displayed when the USG2200 analyzes the ConfRej packet. This problem does not occur in the laboratory interconnection environment. Is the problem caused by the environment? The reason why the ConfRej packet is generated should be analyzed.
2010-05-22 16:17:17 NEEA-34-RGW %%01PPP/8/debug2(d):
  PPP State Change:
      Serial4/0/0:0 IPCP : reqsent --> acksent
2010-05-22 16:17:17 NEEA-34-RGW %%01PPP/8/debug2(d):
  PPP Packet:
      Serial4/0/0:0 Input  IPCP(8021) Pkt, Len 32
      State acksent, code ConfRej(04), id 0, len 28
      IP Address(3), len 6, val ac10004a 
      IP Address(3), len 6, val ac10004a 
      IP Address(3), len 6, val ac10004a 
      IP Address(3), len 6, val ac10004a 
2010-05-22 16:17:17 NEEA-34-RGW %%01PPP/8/debug2(d):
  PPP Event:
      Serial4/0/0:0 IPCP RCN(Receive Config Nak/Reject)  Event
      state acksent
2010-05-22 16:17:17 NEEA-34-RGW %%01PPP/8/debug2(d):
  PPP Error:
      Serial4/0/0:0 IPCP : Ipcp_rejci: received wrong Reject!
First, the reason why the Config-Reject packet is generated should be analyzed. According to the description of the IPCP protocol, when the recipient cannot identify the configuration parameters from all senders, the recipient sends a Config-Reject packet to the peer. Only the configuration parameters that cannot be identified are contained in the Config-Reject packet (when the types of the configuration parameters cannot be identified). The Config-Reject packet that is replied by the peer contains four IP address(3), as shown in the following:
  PPP Packet:
      Serial4/0/0:0 Input  IPCP(8021) Pkt, Len 32
      State acksent, code ConfRej(04), id 0, len 28
      IP Address(3), len 6, val ac10004a 
      IP Address(3), len 6, val ac10004a 
      IP Address(3), len 6, val ac10004a  
      IP Address(3), len 6, val ac10004a 
However, the field of IP Address[3] in the Config-Reject packet is not contained in the ConfigRequest packet that is sent by the USG2200. The parameters of the USG2200 are as follows:
  PPP Packet:
      Serial4/0/0:0 Output IPCP(8021) Pkt, Len 38
      State reqsent, code ConfReq(01), id 0, len 34
      IP Address(3), len 6, val ac10004a 
      Primary DNS Server Address(81), len 6, val 00000000 
      Primary NBNS Server Address(82), len 6, val 00000000 
      Secondary DNS Server Address(83), len 6, val 00000000 
      Secondary NBNS Server Address(84), len 6, val 00000000 
       As shown in the preceding figure, the field carried by the USG2200 is four DNS/NBNS fields. However, the option that is denied by the peer is the field of four IP addresses. Therefore, the version of the NE40 is too old to identify the DNS/NBNS option. The field goes to an incorrect branch, and the ConfigReject packet is sent mistakenly. The NE40 of the VRP5.5 supports the IPCP DNS option, but the earlier versions do not. It is likely that the NE40 does not support the DNS/NBNS option on the USG2200. The R&D tests the version: delete the DNS/NBNS option when the ConfigRequest packet is sent. The interconnection succeeds after the USG2200 is upgraded.
Suggestions
None.

END