Users Fail to Access Network because the Upper Layer of MA5200 L2TP is not Configured with Route to Loopback

Publication Date:  2012-07-27 Views:  127 Downloads:  0
Issue Description
Version: Independent of version
Symptom: the account is of radius authentication, and the attributes of L2TP are advertised by radius; the client prompts "it is authenticating the username and password" for a long time, and the error  with code of 650 is returned at last. 
Alarm Information
No
Handling Process
1. The configurations of both MA5200 and Ins are normal; 
2. Make sure the account is correct; 
3. During dial-up of users, both MA5200 and Ins debug the L2TP packets simultaneously, and the packets at MA5200 are as follows: 
 [L2TP Debug]Tunnel 1 Send SCCRQ  (T=1166(s):39)                                
 [L2TP Debug]Tunnel 1 proc ctrl ack timer expired, SendUp=1 SendLow=0 (T=1174(s)
:53)                                                                            
 [L2TP Debug]L2TP send to 61.155.66.20 result: requested data : 80 , real sended
 data : 80 (T=1174(s):53)                                                       
 [L2TP Debug]Tunnel 1 resend the ctrl message:Ns(0) 1 times (T=1174(s):53)      
 [L2TP Debug]Tunnel 1 proc ctrl ack timer expired, SendUp=1 SendLow=0 (T=1182(s)
:57)                                                                            
From the packets, we could know that MA5200 transmits SCCRQ, but cannot receive echo packets from radius, so MA5200 is transmitting SCCRQ packets again and again.Even though the L2TP attributes advertised by radius are false, MA5200 should receive the echo packets indicating the attributes are false from Ins usually, so  such a conclusion that L2TP attributes advertised by radius are false is ruled out. 
Packets at Ins side are as follows: 
 L2TP::Recv a SCCRQ or StopCCN pass to upper layer                              
.
.(The detailed packets are omitted)
.          
 L2TP:: O Tunnel  1 send START_CONTROL_CONNECTION_REPLY to Tunnel 1 
 L2TP::Recv a SCCRQ or StopCCN pass to upper layer                              
.
.(The detailed packets are omitted)
.                                       
 L2TP::Error::Discard SCCRQ for multi tunnel over the same pair of peers.       
According to checkup for packets, Ins has received the SCCRQ packets from MA5200, and it responds with SCCRP; latterly, the SCCRQ transmitted by MA5200 is received again, and Ins receives the same two packets, discarding it. 
So, Ins has echoed MA5200 with SCCRP, but MA5200 has not received it, and the packet may be discarded or blocked. MA5200 and Ins could ping through to each other. 
4. L2TP service of MA5200 takes the address of loopback1 as the source address of packet sent to interact with Ins, so that both equipments could ping through to each other does not mean the loopback1 address could interact with Ins. Failing to ping through to the address of Ins with the loopback1 address as source address indicates that loopback1 and Ins cannot communicate, and there is no route at between. According to L2TP packets captured at Ins, the L2TP packets transmitted by MA5200 could reach Ins, but the response packet from Ins cannot reach MA5200.  Check the route at equipment on link, and it is not configured with the route to loopback1 of MA5200; L2TP users could dial in to access network after configuring the route.  
Root Cause
The problem may arise because of a lot of reasons: 
1.The configuration of MA5200 is problematic; 
2. The configuration of accout at radius side or Ins side is problematic; 
3. The L2TP parameters advertised by radius are problematic; 
4. The negotiation between MA5200 and Ins is problematic. 
The case is actually caused by setting of route. MA5200 uses loopback address to send tunnel request to LNS, but LNS has no route to the loopback address of MA5200, failing the set-up of tunnel. 
Suggestions
For MA5200 at R009, if it does not set the address of loopback1 to the source address of packets transmitted out, the loopback1 address will be taken as the source address in L2TP service to interact with Ins,  and other else services take the address of uplink port as the source address of packets transmitted to interact with other equipments. 
For more, see the related cases. 

END