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

Parts of L2TP Dial-up Users Dial in LNS but cannot Access Network because of Address Conflict

Publication Date:  2012-07-27 Views:  51 Downloads:  0
Issue Description
Topology:
    PC---LAC---R1760 (LNS)
Phenomenon:
    When R1760 accesses L2TP dial-up users, there is overlap for address allocation. Many users dial to R1760 (LNS) and allocate the same IP address.
    Check the state of R1760 and related abnormal information is as follows:
    [bdyb]dis aaa user
 User Name  UserID  User Type    IP Address  Accounting Time  Calling Number
 bdchaoyangbei@bdjh.133vpdn.he      1      PPP      192.168.2.2         00:03:34  
 bdhyyf@bdjh.133vpdn.he      2      PPP      192.168.2.2         00:03:22  
 admin@bdjh.133vpdn.he      3      PPP      192.168.2.2         00:02:01  
 bdmckc@bdjh.133vpdn.he      4      PPP      192.168.2.3         00:00:06
Alarm Information
Null
Handling Process
The site change static IP as dynamic IP and there is no address conflict.
Root Cause
Analyze debug ppp all information and it is found that some PC dial-up users set static IP address. But this IP address is allocated by R1760 to other users. There is address conflict.
Related information is as follows:
1. Abnormal user, the user configures IP address on PC.
A 'bdchaoyangbei@bdjh.133vpdn.he'
  Virtual-Template1:0
  PPP I IPCP(8021) Pkt, Len 12
  State reqsent, code ConfReq(01), id 26, len 10
  IP Address(3), len 6, val c0a8020b 
  Virtual-Template1:0
  PPP O IPCP(8021) Pkt, Len 14
  State reqsent, code ConfAck(02), id 26, len 10
  IP Address(3), len 6, val c0a8020b  192.168.02.11
  
B 'bdhyyf@bdjh.133vpdn.he'
  Virtual-Template1:1
  PPP I IPCP(8021) Pkt, Len 12
  State reqsent, code ConfReq(01), id 54, len 10
  IP Address(3), len 6, val c0a80203 
  Virtual-Template1:1
  PPP O IPCP(8021) Pkt, Len 14
  State reqsent, code ConfAck(02), id 54, len 10
  IP Address(3), len 6, val c0a80203 
  
2. Normal user: user does not configure address.
   'admin@bdjh.133vpdn.he'
 Virtual-Template1:2
  PPP I IPCP(8021) Pkt, Len 24
  State ackrcvd, code ConfReq(01), id 1, len 22
  IP Address(3), len 6, val 00000000 
  Primary DNS Server Address(81), len 6, val 00000000 
  Secondary DNS Server Address(83), len 6, val 00000000 
  Virtual-Template1:2
  PPP O IPCP(8021) Pkt, Len 20
  State ackrcvd, code ConfRej(04), id 1, len 16
  Primary DNS Server Address(81), len 6, val 00000000 
  Secondary DNS Server Address(83), len 6, val 00000000 
  Virtual-Template1:2 (I) Len 12
         80 21 01 02 00 0a 03 06    00 00 00 00 
  Virtual-Template1:2
  PPP I IPCP(8021) Pkt, Len 12
  State ackrcvd, code ConfReq(01), id 2, len 10
  IP Address(3), len 6, val 00000000 
  Virtual-Template1:2
  PPP O IPCP(8021) Pkt, Len 14
  State ackrcvd, code ConfNak(03), id 2, len 10
  IP Address(3), len 6, val c0a80202 .
  Virtual-Template1:2 (I) Len 12
         80 21 01 03 00 0a 03 06    c0 a8 02 02 
  Virtual-Template1:2
  PPP I IPCP(8021) Pkt, Len 12
  State ackrcvd, code ConfReq(01), id 3, len 10
  IP Address(3), len 6, val c0a80202 
Virtual-Template1:2
  PPP O IPCP(8021) Pkt, Len 14
  State ackrcvd, code ConfAck(02), id 3, len 10
  IP Address(3), len 6, val c0a80202 
According to the definition of PPP RFC, when PC reaches dial-up server thorugh PPP,  IPCP state is "reqsent" if PC configures IP address. IPCP state is "ackrcvd" if PC does not configure IP address.
Suggestions
Null

END