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
MENU

PPPoE user irregularly dropped due to over ME60 capacity of user number

Publication Date:  2015-01-12 Views:  31 Downloads:  0
Issue Description

【Network Diagram 】
There are about 130 thousand xDSL access users in a new site of FTTx access network. HSI Service of FTTx user initial from ONT with PPPoE dial  and get IP address from ME60.



【 fault appearance 】


FTTx VIP user argue HSI Service is not stable. Service drop interval is not regular. The other users of BRAS also have the same problem.

【 version information 】

Product Version
ME60 V1R6C05SPC600
Board versions: CR52LPUA REVE Dummy MSISDN CR52EAGF REVA
NE40E V3R3C02B608
MA5600T MA5600V800R008C01
HG8247 V1R2C06S005

Handling Process
【 Interconnection technology 】
After establishing PPP connection between ONT and ME60E , ONT and ME60E regularly send and receive detection packets to make sure link status.
  • If  ONT send detection packets but don't receive response continuously. ONT will send disconnectioin request packet and  off-line record will be " PPP user request" on ME60E.
  • If ME60 send detection packets but don't receive response packets continuously. Detection is failure and link will be disconnected and off-line record will be "PPP echo fail" on ME60E. 
【 possible cause 】
  1. ONT is not stable.
  2. ONT hardware is fault.
  3. fiber quality of access network is  poor.
  4. ME60 problem.


Step 1: When FTTx user drop. U2000 ,network management, is no alarm and ONT status is normal.

           We eliminate physically UP/Down  and service path intermittent problem.
Step 2: Replace ONT to eliminate ONT hardware fault.
Step 3: Check fiber and confirm fiber quality is good.
Step 4: Check ME60 user off-line resord is "PPP user request".The possible causes are following

  • ME60 didn't receive PPP LCP request packet from ONT.
  • ME60 received PPP LCP request packet but didn't  reply.
  • ME60 responds reply packet but lose.

<ME60>display aaa offline-record mac-address 4c1f-cc06-92b2
-------------------------------------------------------------------
User name : msialbalam00002
Domain name : fttx.net.qa
User MAC : 4c1f-cc06-92b2
User access type : PPPoE
User access interface : Eth-Trunk3.5
Qinq Vlan/User Vlan : 1942/647
User IP address : 78.101.116.67
User ID : 14038
User authen state : authenticated
User acct state : AcctIdle
User author state : AuthorIdle
User login time : 2012/02/28 18:50:57
User offline time : 2012/02/28 14:23:54
User offline reason : PPP user request
-------------------------------------------------------------------
Step 5: Enable Trace user function of BRAS on ME60 to trace user online process. Because BRAS can only confirm echo request sending from BRAS it cannot make sure if BRAS properly respose PPP LCP echo request from ONT. We need to capture packet to analyze.
Step 6: We capture packet on MA5600T uplink port which user access and configure flow policy and port mirror. We mirror two problem user flows to observe port.

Capture rules and port mirror configuration are as follows:
Note:

1. In ACL 4000 , source MAC of rule configuration is user's MAC. 0000 -0000 -0000 that is to exactly match mac address.

2.In ACL 4001, destination MAC of rule configuration is user's MAC. 


acl 4000
rule 5 permit source 781d-baa7-2979 0000-0000-0000
rule 10 permit source 4c1f-cc06-92b2 0000-0000-0000

acl 4001
rule 5 permit destination 781d-baa7-2979 0000-0000-0000
rule 10 permit destination 4c1f-cc06-92b2 0000-0000-0000

Uplink port is trunk port and mirror traffice of member port to observe port


traffic-mirror inbound link-group 4001 port 0/19/0 to port 0/9/1
traffic-mirror outbound link-group 4000 port 0/19/0 to port 0/9/1
traffic-mirror inbound link-group 4001 port 0/20/0 to port 0/9/1
traffic-mirror outbound link-group 4000 port 0/20/0 to port 0/9/1

Step 7:  We mirror user traffic to observe port and capture packet on ME60E.

1.To determine observe port. For live network, ME60 is not support mirror egress traffic across the board and we need to make sure mirror port and observe port on the same board.

Command:
observe-port 1 interface GigabitEthernet 6/0/0


2.BRAS use eth-trunk however ME60 cannot mriior eth-trunk. We need to define all member port of eth-trunk to bidirectional mirror port. Command is below


interface GigabitEthernet6/0/3
port-mirroring to observe-port 1 inbound
port-mirroring to observe-port 1 outbound

interface GigabitEthernet6/0/4
port-mirroring to observe-port 1 inbound
port-mirroring to observe-port 1 outbound

3. Define observe filter based on the MAC and PPP protocol.  Command is below


observe-port 1 interface GigabitEthernet6/0/0
observe-filter 0 local src-mac 781d-baa7-2979 ether-type 8864 ppp-protocol c021
observe-filter 1 local dst-mac 781d-baa7-2979 ether-type 8864 ppp-protocol c021
observe-filter 2 local src-mac 4c1f-cc06-92b2 ether-type 8864 ppp-protocol c021
observe-filter 3 local dst-mac 4c1f-cc06-92b2 ether-type 8864 ppp-protocol c021


Step 8: To analyze captured PPP packet when user droped on MA5600T and ME60
1. captured packet from MA5600T and found that ONT didn't receive  encho reply packet four times from ME60 and request offline. At the same time, ME60 send request packet to ONT and ONT response all request packet.

2. To compared captured packet from ME60 we found ME60 receive echo request packet from ONT but didn't response echo reply packet. It means packet lose occurred to ME60. Because packet format and content is correct and satisfy protocol we suspect ME60 have problem.


(more detail see attachment)


Root Cause

PPPoE user irregularly dropped due to over ME60 capacity of user number.

Solution

1. Service migration and capacity expansion
2. Software upgrade to V6R2 and later can solve this problem, ME60 with new version response PPP detection packet by hardware that don't have capacity limitation.

Suggestions
  • For PPPoE User irregularly drop problem, We should know user off-line reason and analyze by protocol principle.
  • When User number is almost 10 thousand of board and  irregularly drop occurred. If off-line reason is "PPP user request" we suggest expansion or upgrade software.
  • Actual test performance of CR52LPUA REVE board with V1R6C05SPC600 version:Sending interval is 10 sec in terminal, Packet loss will occur when access user number up to 10,588 of board.  In live network, we suggest user number under 10,588 because of traffic burst and do something  when user number close to limitation. 

    END