2008-2009 huawei access network product cases

2008-2009 Huawei Access Network Product Cases

MSAN UA5000 Cases Table of Contents

Confidential Information of Huawei. No Spreading without Permission

i

Table of Contents Chapter 1 MA5600 Cases............................................................................................................ 1

1.1 Fan Block Alarm Is Generated Because of the Fan Fault............................................... 1 1.2 Description of the Traffic-suppress Command................................................................ 2 1.3 The Broadcast Packets Cause the 678 Error for the User Dialup Through Certain Modems Connected to the MA5600 After the Cutover............................................................... 4 1.4 Dialup Error 691 Is Displayed Sometimes Because the Modem Selects a Wrong PVC in the Case of Single-Port Multi-PVC Service of the MA5600........................................................ 5 1.5 The 691 or 678 Error Occurs When the Multi-PVC Service Is Configured on the Single-PVC Modem Working with the DSLAM ........................................................................... 6 1.6 The Loop Detection Function Fails Because the Modem Does Not Transmit the BPDU Packet for the Loop Detection .................................................................................................... 6 1.7 Dark Screen Occurs When an IPTV User Is Watching a Scrambled Live Channel Under the MA5600 Because the Encryption Key of the CA Card Expires ............................................ 8 1.8 The IPOA Encapsulation Causes the Failure to Delete the Service Port ..................... 10 1.9 The Dialup of the Subscribers Connected to the MA5600 Fails Due to the Incorrect Setting of the Broadcast Suppression on the Convergence Switch ......................................... 11 1.10 Continuously Online and Offline of ADSL ports ............................................................ 12 1.11 MA5600 is not showing alarms on imanager N2000 BMS............................................ 13 1.12 Conflict mac-address also can not manage dslam from inbound management ........... 14 1.13 Why is the Multicast Service Unstable After the MA5600 Enables the CAC Function . 16 1.14 FAQ-How Does the MA5600 Support Anti DoS Attack Function.................................. 17 1.15 FAQ-Precautions for Modifying the ADSL Line Profile of the MA5600 ......................... 18 1.16 FAQ-How to Solve the Problem That the MA5600 is Enabled with Anti-MACspoofing So That the Hot-Spot Service in the Modem with the Fixed IP Address is Interrupted............ 19 1.17 FAQ-how to judge what is the problem about ADSL line quality .................................. 20 1.18 FAQ-How to recover admin password in MA5600 ........................................................ 20 1.19 FAQ - How can you avoid dial-in delay while using PPPoE+ ....................................... 21 1.20 FAQ-How to Solve the Problem That the Entire Shelf Fail to Go Online Due to the MA5600 Upstream Fiber Problem ............................................................................................ 21 1.21 FAQ-Is the 32-Channel Service Board Slot Compatible with the 64-Channel Service Board on the MA5600............................................................................................................... 22 1.22 FAQ-How to Connect and Configure the Humidity Sensor in the H304ESC................ 23 1.23 FAQ- Why configurations are lost when using save configuration command............... 24

Chapter 2 MA5600T (IP DSLAM) Cases................................................................................... 25 2.1 Failure to save data after recover a data from Data Center.......................................... 25 2.2 Abnormal PADT Packet Attack interrupting access users to dialup ............................. 25 2.3 Interruption of the BTV Service at an Interval of About 5 Minutes Due to Deferred Response to the General Query Packets ................................................................................. 26 2.4 CPE under MA5600T forward PADIs from other CPE cause PPPoE user disconnected randomly. .................................................................................................................................. 27 2.5 On the MA5600T the line-rate of ADSL2+ port is not enough for watch two programs at the same time ........................................................................................................................... 28 2.6 Smart AX MA5600T ACL malfunction caused by PPP&DHCP packets SCUB CPU capturing and not processing by ACL....................................................................................... 29

NGN Cases Table of Contents


ii

2.7 Pause Point in the Program Caused by the Loss of the UDP Fragment in the Multicast Service of the Smart MA5600T................................................................................................. 31 2.8 Smart MA5600T NTP time problem caused synchronized time abnormally................. 32 2.9 Smart MX 5600T PPP use cannot get IP cause by BAS malfunction........................... 33 2.10 FAQ-How to Connect and Configure the Humidity Sensor in the H304ESC................ 34 2.11 FAQ- Why configurations are lost when using save configuration command............... 34 2.12 FAQ-why we can not get the same value of SNR margin use the same line-profile in the same physical-line. ................................................................................................................... 36 2.13 FAQ-What is the maximum number of line-profile and line-template that can be defined in MA5600T............................................................................................................................... 37 2.14 FAQ-How to Select the Correct Frequency Spectrum Profile During the Configuration of the VDSL2 Line Profile ............................................................................................................. 38 2.15 FAQ-What Is by Default the Running Mode of the Fan of the MA5606T...................... 39 2.16 FAQ-How to config dynamic and static Multicast program at MA5606T....................... 39 2.17 FAQ-How to find out the reason for unable to call certain numbers via SIP................. 40 2.18 FAQ-What is difference between ADSL mode and NGADSL mode............................. 41

Chapter 3 GPON FTTx Cases ..................................................................................................... 42 3.1 How to enable MA5680T ETHB Port to connect to other vendor's equipment ............. 42 3.2 256 multicast channels can't be online at the same time in 5680T............................... 42 3.3 The Matching Status of the ONT and the Profile Is 'Mismatch' Because the Numbers of the GEM Ports Supported by the MA5680T and the MA5626G Are Different ......................... 43 3.4 The Voice Communication on the MA5606T Is Unidirectional Because of the Routing Problem of the Media Stream................................................................................................... 44 3.5 FAQ-How to Perform Inter-Board Mirroring on the Upstream Board on the MA5680T 45 3.6 FAQ-How to Implement the Interworking Between Different FE Ports on the MA562xG46 3.7 The Interconnection Between the Switch of Company C and MA5600T Fails Because the LACP Configuration of the Switch of Company C Is Incorrect ........................................... 46 3.8 FAQ-How to Change the Default T-CONT 0 Type of the MA5600T Providing the GPON Service ...................................................................................................................................... 47 3.9 THE GICF Board Is in the config State and the Service Cannot Recover After the MA5680T Is Restarted.............................................................................................................. 47 3.10 The MA5620G Plays the Busy Tone After Offhook Because of Incorrect Descriptor Signaling Delivered by the Softswitch of company x ................................................................ 47 3.11 AQ-How to Calculate the Actual Split Ratio when the xPON Uses the Multi-level Optical Splitting Mode ........................................................................................................................... 47 3.12 Users Connected to the MA5620G Cannot Make Calls Normally After Taking the Phone off the Hook Because RTP Resources of the Softswitch Are Allocated Insufficiently .. 47 3.13 FAQ-How to Configure the ACL Rule on the MA5680T So That the Priority of the Outer VLAN Can Be Changed Based on the Inner VLAN Tag........................................................... 47 3.14 All ONTs (HG850s) Connected to a PON Port Get Online and Offline Frequently Because One of the ONTs Connected to the PON Port Is Faulty............................................ 47 3.15 The ONT Connected to the MA5680T Goes Offline Frequently Due to the Incorrect Connection of Optical Fibers on the Optical Splitter................................................................. 47 3.16 Users Fail to Log In to the Server from the N2000 BMS Client Because of the Incorrect Setting of the Client................................................................................................................... 47 3.17 FAQ-How to Implement the VoIP Service of the MA5680T .......................................... 47 3.18 The FE Port Cannot be Activated After the HG810e Connected to the MA5680T Is Powered Off Because the ONT Profile Does Not Match the ONU Profile................................ 47 3.19 A Port of the H813e Cannot Forward Packets Normally Because the Native VLAN of the Port Is the Same as the Multicast VLAN ............................................................................ 47

MSAN UA5000 Cases Table of Contents


iii

3.20 The ONT Connected to the MA5680T Cannot Receive the Broadcast Packet Due to the Fault of the ONT ....................................................................................................................... 47 3.21 All ONTs (HG850s) Connected to a PON Port Get Online and Offline Frequently Because One of the ONTs Connected to the PON Port Is Faulty............................................ 47 3.22 FAQ-Can the ONT Register with the OLT if the ONT Connected to the MA5680T Is Over 20 km Away from the OLT ............................................................................................... 47

Chapter 4 UA5000 Broadband Service ........................................................................................ 47 4.1 standard vlan cause the bad packet for multicast traffic ............................................... 47 4.2 ADSL Subscribers cannot be authenticated due to high temperature .......................... 47 4.3 A UA5000 Fails to Copy All Multicast Streams to All STBs Because the Traffic Exceeds the Traffic Restriction of the UA5000........................................................................................ 47 4.4 The Broadband Service of the UA5000 Fails because the VE on the BAS Is Not Configured with the MAC Address............................................................................................ 47 4.5 Error 678 Is Prompted Frequently During the Dialup of the UA5000 Broadband Subscriber because the Wire Sequence of the Uplink Straight Through Cable Is Incorrect.... 47 4.6 Download speed is too slow because of the wrong cable connect between UA5000 and S6500 47 4.7 (IPTV service) VOD is working normally but Live channel service is not available ...... 47 4.8 Packet loss to UA5000. When occurring, the IPMB reports CPU occupancy at 73 ..... 47 4.9 All PPPoE subscribers in two sites unable to connect to internet due to the uplink GE port lost the BRAS mac-address .............................................................................................. 47 4.10 Improper Configuration of the Switch Causes Erratic Display to Two Communicating Video Terminals of the UA5000................................................................................................ 47 4.11 The IPMB Fails to Communicate with the Upstream EP1A Through the Backplane Interface Because the Subboard of the IPMB Is Incorrect ....................................................... 47 4.12 The Ethernet Port Fails to Be Activated Because the Upstream Port Mode of the IPMD Board Is Not Modified ............................................................................................................... 47

Chapter 5 UA5000 Narrow-band Service ................................................................................ 47 5.1 Retransmission of H.248 Packets Fails in the UA5000R17C02B107 Because the Interface Attribute Is Incorrect................................................................................................... 47 5.2 The MG Interface Fails to Be Established Because of Incorrect H.248 Negotiation Version...................................................................................................................................... 47 5.3 Service Boards in the Entire Slave Shelf of the UA5000 Fail to Register Because One DSL Board in the Shelf Is Faulty............................................................................................... 47 5.4 Service Boards in the Entire Slave Shelf of the UA5000 Fail to Register Because One DSL Board in the Shelf Is Faulty............................................................................................... 47 5.5 Slow Reporting of Collected Digits due to Conflict Between the Long and Short Timers47 5.6 Activation Failure of the IUA Link on the UA5000 Because the Corresponding Port on the SoftSwitch Firewall Is Not Enabled..................................................................................... 47 5.7 Busy Tone Upon Off-hook Due to the Abnormal Maximum Leak Rate After the UA5000 Is Upgraded .............................................................................................................................. 47 5.8 Voice Noise caused by PVMB ethernet port working mode in half duplex ................... 47 5.9 Household Alarm Working Abnormally Due to the Large Packet Disassembly Duration47 5.10 Service Failure Because the Upstream Port Mode of the H601PVMD Is Not Modified 47 5.11 No Tone upon Offhook for Subscribers under the UA5000 Because the HSCI Board of the SoftX3000 Is Faulty ............................................................................................................ 47 5.12 FAQ-Voice Subboard Round Robin Mechanism of the PVM Board ............................. 47

Chapter 6 iManager N2000 BMS Cases................................................................................... 47 6.1 Failure in Alarm Displaying on the N2000 BMS Due to the Error of Setting the Source IP Address of the Trap Packets on the MA5680T .................................................................... 47

NGN Cases Table of Contents


iv

6.2 Unable to Telnet DSLAM From BMS Because of Device access Proxy Process Problem..................................................................................................................................... 47 6.3 NEs Are Detached from the N2000 BMS After the Anti-ARP Attack Feature Is Enabled on the Uplink Switch ................................................................................................................. 47 6.4 Device Is Added and Then Disappears During the Synchronization Because of the License Issue ............................................................................................................................ 47 6.5 N2000 BMS Fails to Add an NE Because of the Deadlock of the Account on the Device Side 47 6.6 N2000 BMS Server Is Shut Down Automatically Because the Setting of the Configuration File of Solaris OS Is Incorrect ............................................................................ 47 6.7 Login to the Xmanager Fails Because the Default Monitoring Port of the dtlogin Process Is Port 0..................................................................................................................................... 47 6.8 N2000 BMS Fails to Automatically Detect Devices Because of the Auto-Negotiation Error of the Network Card......................................................................................................... 47 6.9 Standby Server Fails to Be Started Because the N2000 BMS HA System Is Powered Off Abnormally .......................................................................................................................... 47 6.10 Troubleshooting of the Abnormal Replication Relation Between the Active and the Standby Servers of the N2000 BMS HA System...................................................................... 47 6.11 GPON ONT terminal upgrade function isn't available on BMS N2000 ......................... 47 6.12 Failure in the Establishment of the Replication Relation on the HA System (Watchman) Because of Inconsistency of the Name of the Replication Link................................................ 47 6.13 Operating the N2000 BMS Through the Monitor Fails Because of a Fault of the Input and Output Modes .................................................................................................................... 47 6.14 All the Narrowband NEs Fall out of Management After the N2000 BMS Server Is Restarted .................................................................................................................................. 47 6.15 While login the Database Backup Tool,it appears Fail to connect the server............... 47 6.16 FAQ-What is the compatibility between BMS and Solaris ............................................ 47 6.17 FAQ-How to handle solaris prompt 'Device busy' when used 'eject command' to pop out the cdrom failed ........................................................................................................................ 47 6.18 FAQ-How to Mirror Disks on Solaris OS ....................................................................... 47 6.19 FAQ-How to Enable the SSH and SFTP Functions on Solaris 10................................ 47 6.20 FAQ-The TFTP configuration on Solaris system .......................................................... 47

MSAN UA5000 Cases Chapter 1 MA5600 Cases


1

Chapter 1 MA5600 Cases

1.1 Fan Block Alarm Is Generated Because of the Fan Fault

Title: Fan Block Alarm Is Generated Because of the Fan Fault

ID: SE0000352549 Information

Type : Troubleshooting Cases Quality Level: C

Product Family: Broadband Access Product: SmartAX MA5600

Fault Type: Backplane/Board Hardware

Keywords: Fan, block alarm, high temperature

Permission Level: Warranty Users Permission Phenomenon Descr

iption: 1. The ADSL service boards in slots 13 and 14 of an MA5600 often restart automatically or the ports of the service boards are dead locked. 2. Query the temperature inside the MA5600. It is found that the temperature even reaches 48C, and the fan block alarm is generated. 3. Pull out the fan tray. It is found that the fan responsible for slots 13 and 14 has stopped working. When the device is powered, the fan does not work either. The fan type is: fan boxPDU, MA5300, H53E1FCBA, 6-fan 1U fan box.

Alarm Information:

ALARM 764355 fault alarm important 0x15411024 environment 2008-07-14 09:15:40 Alarm name: fan block alarm Parameters: Alarm description: fan block alarm Alarm cause: Some subjects block the fan. Troubleshooting suggestion: Check the fan.

Cause Analysis: The temperature inside the device is too high, the fan block alarm is generated, and the ADSL service boards in slots 13 and 14 cannot provide the internet service. After the analysis, it is estimated that one of the six fans in the fan box of the MA5600 fails, and this faulty fan is responsible for the heat dissipation of the ADSL boards in slots 13 and 14. The prerequisite for generating the fan block alarm is the hardware failure of the fan.

Handling Process:

According to the fault analysis, it is determined that the fan fails. After the fan is removed and checked, we confirm that the hardware fault of the fan exists. That is, the fan responsible for the heat dissipation of the slots 13 and 14 fails. After a new fan is installed, in half an hour, query the temperature of the device. It is found that the temperature falls, and thus the ADSL service boards in slots 13 and 14 no longer automatically restart and the service ports are not dead locked.

Suggestions and Summary:

The high temperature of the device usually results from the failure of the fan in the device. When the fan fails, query the alarm and replace the fan in time to avoid burning the service board or the backplane.

NGN Cases Chapter 1 MA5600 Cases


2

1.2 Description of the Traffic-suppress Command

Title: Description of the Traffic-suppress Command


Type : Troubleshooting Cases Quality Level: B


Fault Type: QACL Service

Keywords: traffic-suppress


iption: The traffic suppression is used to suppress the traffic of the broadcast, unknown unicast, and unknown multicast packets in the inbound direction of the port. For the broadcast and unknown unicast, the suppression is implemented according to the number of the packets. For the unknown multicast, the suppression is implemented according to the traffic of the packets. This command is mainly used to avoid the effect on the system and the network after a large number of such packets are broadcasted. The broadcast packets refer to the packets whose destination MAC addresses are all Fs, such as ARP packets, PADI packets in PPPoE protocol, and DHCP discover packets in DHCP protocol. Many protocols send the handshake packets through broadcast. The unknown unicast packets refer to the packets whose destination MAC addresses are unicast MAC addresses. In the LAN switch chip of the control board, however, no forwarding entry related to the destination MAC addresses is created, so the LAN switch chip does not know to which port the packet is forwarded. In this case, the MA5600 broadcasts the packets in the VLAN where the port that sends the packets is located. If too many unknown unicast packets (for example, caused by the malicious attack) are broadcasted, the congestion occurs or even the ongoing service is interrupted. Therefore, the traffic suppress command is used to suppress the unknown unicast packets. The unknown multicast packets refer to the packets whose destination MAC addresses are multicast MAC addresses (the highest bit of such MAC address is 01, such as the MAC address of IGMP packets and some BPDU packets). In the LAN switch chip of the control board, however, no forwarding entry related to the destination address is created, so the LAN switch does not know to which port the packets are forwarded.

Alarm Information:

Null

Cause Analysis: Entry Description: MA5600(config-if-scu-0/7)#display { board|port|mirror|traffic-suppress }:traffic-suppress { portid|all }:all Commands: display traffic-suppress all Traffic suppression ID definition: --------------------------------------------------------------------- NO. Min bandwidth(kbps) Max bandwidth(kbps) Package number(pps) --------------------------------------------------------------------- 1 6 145 12 2 12 291 24 3 24 582 48 4 48 1153 95 5 97 2319 191 6 195 4639 382 7 390 9265 763 8 781 18531 1526 9 1562 37063 3052 10 3125 74126 6104 11 6249 148241 12207 12 12499 296483 24414 ---------------------------------------------------------------------



3

--------------------------------------------------------------------- PortID Broadcast_index Multicast_index Unicast_index --------------------------------------------------------------------- 0 OFF -- 7 1 7 -- 7 2 7 -- 7 3 7 -- 7 4 7 -- 7 5 7 -- 7 --------------------------------------------------------------------- Min bandwidth (kbit/s): Indicates the minimum bandwidth. If the minimum length of each packet is 64 bytes and 12 packets are allowed to be transmitted per second (for example), the minimum bandwidth is calculated as 64B x 8b x 12 1000 = 6 kbit/s. Max bandwidth (kbit/s): Indicate the maximum bandwidth. If the maximum length of each packet is 1518 bytes and 12 packets are allowed to be transmitted per second (for example), the maximum bandwidth is calculated as 1518B x 8b x 12 1000 = 145 kbit/s. Package number (pps): Indicates the number of the packets that are allowed to transmit per second through the port. --------------------------------------------------------------------- PortID Broadcast_index Multicast_index Unicast_index --------------------------------------------------------------------- 2 OFF -- 7 3 OFF -- 7 --------------------------------------------------------------------- Index: Profile index "OFF": Indicates that the packets are transparently transmitted with no suppression. Run the undo traffic-suppress command to configure the suppression. "": Indicates that the "IGMP" or "multicast" tunnel is enabled. In this case, the value of the multicast index is invalid, and then the unknown multicast packets are either totally transparently transmitted or discarded. For details, refer to "Introduction to the Traffic-suppress Command" in this document.

Handling Process:

Implementation principles: Broadcast and unknown unicast packets: The traffic is suppressed according to the number of the packets. After the port on which the broadcast suppression and the unknown unicast suppression are configured receives the broadcast and unknown unicast packets, the chip counts the number of the packets. At a certain interval, if the count reaches the preset threshold, the chip discards the broadcast and unknown unicast packets that the port later receives until the next interval starts. When the next interval starts, the counts of the broadcast and unknown unicast packets received by the port are cleared. Unknown multicast packets: The chip does not support the traffic suppression by the number of the packets, so the traffic can be suppressed only according to the bandwidth in the ACL mode. In this case, the bandwidth that equals to the number of the packets transmitted to the host multiplied by 512 bytes (the average length of a packet is 512 bytes in calculation) is set in the chip.


Command description: Command format:traffic-suppress { broadcast | multicast | unicast } value value { portid | all }undo traffic-suppress { broadcast | multicast | unicast } { portid | all }Parameter description:Broadcast: Indicates the configuration of the broadcast suppression. Multicast: Indicates the configuration of the unknown multicast suppression.Unicast: Indicates the configuration of the unknown unicast suppression. Value: Indicates the index of the traffic suppression profile, ranging from 1 to 12.Portid: Indicates the port number, ranging from 0 to 5.All: Indicates all ports.Mode & Level SCU configuration mode, operator level Guideline: This command is used to configure the traffic suppression of the broadcast, unknown unicast and unknown multicast on the SCU board. The index of the traffic suppression profile ranges from 0 to 12. Example:



4

Configure the broadcast traffic suppression on all ports, and the index of the profile is 2: huawei(config-if-scu-0/7)#traffic-suppress broadcast value 2 all Command: display traffic-suppress { portid | all }

1.3 The Broadcast Packets Cause the 678 Error for the User Dialup Through Certain

Modems Connected to the MA5600 After the Cutover

Title: The Broadcast Packets Cause the 678 Error for the User Dialup Through Certain Modems Connected to the MA5600 After the Cutover ID: SE0000364212

Information Type : Troubleshooting Cases Quality Level: C


Fault Type: Upgrade/Cutover

Keywords: Broadcast, modem, 678

Permission Level: 03Equipment Users Permission Phenomenon Descr

iption: Before the cutover: MA5200G-----MA5600-----modem----PC (each port of the MA5200G is connected to one MA5600) After the cutover: MA5200G-----S7802 (convergence switch)-----MA5600 (multiple)-----modem-----PC Before and after the cutover, the data on the MA5600 is the same, and two PVCs are configured on each port of the MA5600 8 /46(smart vlan19) E8-2 management vlan 0/35(stacking vlan 1225 ) E8-2 PPPOE service vlan Before the cutover, the modem in the bridge mode of the A Company works normally and the user can go online through the modem dialup. After the cutover, the user fails to go online through the dialup with the modem of the A company, with the 678 error displayed. Other modems on the same port work in the normal state.

Alarm Information:

The 678 error is displayed through the dialup on the PC.

Cause Analysis: After the cutover, the sub-port is re-planned only on the MA5200G. That is, VLANs are transparently transmitted on the S7802. Therefore, it is possible that the fault is caused in the following conditions: 1. On the MA5200G, the configuration of the inner VLAN of the QinQ VLAN is incorrect, or the range of the inner VLAN is small. 2. The network planning of the S7802 is incorrect.

Handling Process:

1. Check the data of the MA5200G. It is found that the data is correct. 2. Check the condition that the S7802 learns the MAC address of the PC. Modem of the A company: dis mac-address 0040-d06e-c3b7 MAC ADDR VLAN ID STATE PORT INDEX AGING TIME(s) 0040-d06e-c3b7 19 Learned Ethernet3/0/3 AGING Huaweis modem: MinHe_S7802>dis mac-address 0040-d06e-c3b7 MAC ADDR VLAN ID STATE PORT INDEX AGING TIME(s) 0040-d06e-c3b7 19 Learned Ethernet3/0/3 AGING 0040-d06e-c3b7 1220 Learned Ethernet3/0/3 AGING It is found that the 678 error is displayed because the S7802 learns the MAC address of the PC connected to the modem of the A company, and the MAC address corresponds to VLAN 19. 3. Check the condition that the MA5600 learns the MAC address of the PC. The condition is the same as that displayed in step 2. After PVC 8/46 carrying the E8-2 service is deleted on the MA5600, reset the modem. It is found that the dialup on the PC is in the normal state. In



5

addition, query the learning of the MAC address of the PC on the MA5600. The information is displayed as follows: QHHD-MHSN-MA5600(config)#display mac-address adsl 0/0/0 ----------------------------------------------------------------------- Type MAC MAC Type F/S/P VPI VCI VLAN ID ----------------------------------------------------------------------- adl 0040-d06e-c3b7 dynamic 0/0/0 0 35 1220 ----------------------------------------------------------------------- Total: 1 It is found that the fault occurs because the modem of the A company is a single-PVC modem and the modem learns PVC 8/46 with the VLAN 19 tag by mistake. 4. By the careful analysis of the networking before and after the cutover, it is found that before the cutover, the E8-2 services with the VLAN 19 tag of different MA5600 devices are terminated on different ports of the BAS; after the cutover, the E8-2 services with the VLAN 19 tag of all the MA5600 devices are terminated on the same port of the BAS within one broadcast domain. On any port of any MA5600, after the modem of the A company receives the PADI packets with the VLAN 19 tag from other MA5600 devices, the PVC automatic search function is enabled, and it is determined that the PVC of the modem of the A company is PVC 8/46. The modem of the A company is a single-PVC modem, so when the PVC is determined to be PVC 8/46, other PVCs (including PVC 0/35 for Internet access through dialup) are deactivated by the modem. In this case, the 678 error occurs when the user connected to the modem of the A company goes online through dialup. 5. There are four ways to solve the problem: 1) Replace the single-PVC modem of the A company with the multi-PVC modem. 2) Delete PVC 8/46 on the DSLAM device. The modems that do not provide the E8-2 services are in the bridge mode, so only PVC 0/35 is needed for the dialup. 3). Enable the port isolation on the S7802 to prevent the broadcast. 4). Re-plan the data, and ensure that the E8-2 management VLAN 19 of each DSLAM device is labeled with the service VLAN to prevent the broadcast.


Null

1.4 Dialup Error 691 Is Displayed Sometimes Because the Modem Selects a Wrong PVC in

the Case of Single-Port Multi-PVC Service of the MA5600

Title: Dialup Error 691 Is Displayed Sometimes Because the Modem Selects a Wrong PVC in the Case of Single-Port Multi-PVC Service of the MA5600 ID: SE0000356410

Information Type : Troubleshooting Cases Quality Level: C Update Time: 2008-11-10 17:18:08

Views: 27

Author: l93239


Fault Type: xDSL MODEM Terminal Interconnection

Keywords: Modem, Multi-PVC for multiple services, 691

Permission Level: 04Common Users Permission

Phenomenon Description:

Networking: modem ? MA5600 ? S6506 ? CISCO BAS Dual PVCs (0.35) and dual services (Internet access and IPTV) are configured on the ADSL port of the MA5600. On the S6506 and BAS, the corresponding data is configured. The Internet access service and IPTV service adopt the dialup mode, using two types of accounts respectively. When the common modem providing a single Ethernet port is used, sometimes error 691 is displayed and sometimes the service is normal. When the modem providing four Ethernet ports is used, the service is always normal.

Alarm Informatio None



6

n:

Cause Analysis: 1. The user name or password is incorrect. 2. The BAS is improperly connected to the RADIUS server. 3.The modem cannot cooperate with the MA5600 well.

Handling Process:

1. Check the user name and password. It is found that they are correct. 2. When the modem providing four Ethernet ports is used, the service is always normal. Therefore, it can be determined that the BAS is properly connected to the RADIUS server. 3. When error 691 for the subscriber connection is displayed, it is found that PVC (0,35) cannot be pinged but PVC (8,81) can by running the atm-ping command. Therefore, it can be determined that the connection between the modem and the MA5600 adopt PVC (8,81) but the account is that for the common Internet access service. Thus, error 697 is generated. By default, these two PVCs (0,35) and (8,81) are configured on a common modem, which chooses a PVC at random when the MA5600 is configured with multiple services. Test shows that the fault cannot be rectified if PVC (8,81) is deleted. Delete the IPTV service configured on the MA5600 ADSL port. It is found that the fault is rectified.


Among the four Ethernet ports of the modem, by default, the first two use PVC (0,35), used for the Internet access service, and the last two use PVC (8,81), used for the IPTV service. No additional PVC exists, so no fault occurs in the case of the four-port modem. Furthermore, we can set the common modem to work in the auto-dialup mode (VPI 0 and VCI 35 is used) to avoid such a fault.

1.5 The 691 or 678 Error Occurs When the Multi-PVC Service Is Configured on the

Single-PVC Modem Working with the DSLAM

Title: The 691 or 678 Error Occurs When the Multi-PVC Service Is Configured on the Single-PVC Modem Working with the DSLAM ID: SE0000390210



Fault Type: ADSL Access Service

Keywords: Multi-PVC, dial-up, 678, 691, single-PVC modem

Permission Level: 04Common Users Permission Phenomenon Descr

iption: Networking: PC----modem----MA5600----L2----BRAS 1. The modem is a single-PVC modem. 0/32 (VLAN 10) corresponds to the dial-up service, 0/33 (VLAN 20) to the IPTV service, 0/34 (VLAN 30) to the VoIP service, and 0/35 (VLAN 40) to terminal management. 2. The PPPoE dial-up service is enabled on the BRAS for the four VLANs. 3. The user account is bound to VLAN 10 on the RADIUS server. When non-multi-PVC users dial up, sometimes the 691 error occurs, and sometimes the 678 error occurs. When the modem of the user is powered off and reset, the user can dial up successfully sometimes; when the board on the device is reset, the user can also dial up successfully sometimes.

Alarm Information:

Null

Cause Analysis: 1. When the user dials the numbers, the PADI packet is sent from the user side. After the PADI packet arrives at the ADSL service board, the packet is broadcast to the four PVCs. After the BRAS receives the PADI packet, the BRAS processes the packet and responds with the PADO packet because the PPPoE dial-up service is enabled for the VLANs of the four PVCs. Then, based on the line conditions, latency, and the time required for the processing on the BRAS, the modem adapts to only the PVC whose PADO packet is received first by the modem. Then, the modem does not adapt to other PVCs, because the modem is a single-PVC modem.In the



7

networking of this case, assume that the PADO packet of PVC 0/33 is received first by the modem, the modem adapts to PVC 0/33 and does not adapt to other PVCs any more.When the PC of the user sends the PADR packet, only PVC 0/33 is available now. After the PPP packet exchange, the user authentication packet is sent to the RADIUS server. On the RADIUS server, the user account is already bound to VLAN 10, and now the user authentication packet sent through PVC 0/33 carries VLAN ID 20, the 691 error occurs consequently. 2. If the dial-up service is not enabled for the four VLANs but is enabled for only VLAN 10 instead on the BRAS, the BRAS does not respond to the packets sent through the other three PVCs, and responds with the PADO packet to the packet sent through the correct PVC only. Therefore, in normal conditions, the user can dial up successfully. If the 678 error occurs in such a case, check which PVC is currently effective on the modem. If PVC 0/32 (carrying the dial-up service) is currently not effective, it is natural that the 678 error occurs, because the dial-up service is not enabled for other PVCs on the BRAS. Before the user dials up, a certain PVC has received a packet (a broadcast packet or protocol packet from the network) sent from the DSLAM port. As a result, a link is set up between the modem and this PVC, and the modem does not negotiate with other PVCs. Hence, the 678 error occurs.

Handling Process:

The solutions to such problems are: 1. On the single-PVC modem, configure only one PVC and delete the other PVCs. For multi-PVC users, configure the multi-PVC service on the multi-PVC modem. 2. The DSLAM of certain versions supports the deactivating of the PVC. Upgrade the DSLAM to such a version and deactivate the PVCs that are currently not used. 3. Replace the single-PVC modem with a multi-PVC modem.


The problems discussed in this case occur in the ONE HOME service of China Telecom. In many areas, the multi-PVC service is configured for users whose modems currently do not support the multi-PVC service. Because of the implementation mechanism of certain single-PVC modems, the problems occur. The problems do not relate to the device quality.

1.6 The Loop Detection Function Fails Because the Modem Does Not Transmit the BPDU

Packet for the Loop Detection

Title: The Loop Detection Function Fails Because the Modem Does Not Transmit the BPDU Packet for the Loop Detection ID: SE0000383809




Keywords: Loop detection failure


iption: Networking: MA5600-S8505-BAS-MAN Fault symptom: The S8505 reports an alarm indicating that the loop exists on the port of the MA5600. The loop detection function is enabled on the MA5600, but no loop alarm is reported. The user reports that the 678 error is prompted during the dialing.

Alarm Information:

Null

Cause Analysis: 1. The loop detection function of the MA5600 is not enabled. 2. The loop detection intervals of the MA5600 and the S8505 are different. 3. The S8505 reports a false loop alarm.



8

Handling Process:

1. View the configurations. The loop detection function is enabled. 2. Deactivate all the ports manually one by one to locate the faulty port, because the new MA5600 does not have many users. 3. After port 0/0/4 is deactivated, the S8505 does not report the loop alarm and the user reports that the dialing is normal. Therefore, the loop exists on port 0/0/4. 4. Check on site. It is found that the user connects two ADSL lines (the corresponding ports are 0/0/4 and 0/0/5 respectively) to the hub to increase the bandwidth. Thus, the loop occurs. 5. According to the designed loop detection mechanism of the MA5600, the PC connected to the modem can capture the loop detection packet (see the attachment) whose destination address is 0180-c200-0011. When the PC is connected to the modem of a certain type that is connected to port 0/0/4 and port 0/0/5, the PC cannot capture the loop detection packet whose destination address is 0180-c200-0011. Therefore, the packet is discarded by the modem. 5. After the modem to which port 0/0/4 and port 0/0/5 are connected is replaced by the MT800, the PC can capture the loop detection packet whose destination MAC address is 0180-c200-0011. 6. Use the MT800 and set up the loop network again (that is, both cables are connected to the hub). In this case, the MA5600 reports a loop alarm and deactivates the port. HZ_XingShiA_MA5600(config)# ! running major 2009-02-12 10:01:03 alarm name :user port forms a loop network parameter :local port of the loop network: frame ID: 0, slot ID: 0, port ID: 4; peer port of the loop network: bridge MAC: 00E0-FC91-2FBE, frame ID: 0, slot ID: 0, port ID: 5 HZ_XingShiA_MA5600(config)# ! running major 2009-02-12 10:01:03 alarm name :user port forms a loop network parameter :local port of the loop network: frame ID: 0, slot ID: 0, port ID: 5; peer port of the loop network: bridge MAC: 00E0-FC91-2FBE, frame ID: 0, slot ID: 0, port ID: 4 7. The modem of a certain type (no manufacturer is indicated) cannot transparently transmit the loop detection packet transmitted by the MA5600 with the destination address 0180-c200-0011. Thus, the loop detection function fails.


Currently, the loop detection function of the MA5600 V300R002 can be implemented only if the modem of the user transparently transmits the BPDU packet that is used for the loop detection. If the modem of the user does not transparently transmit the BPDU packet that is used for the loop detection, the loop detection function cannot be implemented. The modems in the existing network are various. Most of the modems, however, do not support the transparent transmission. Therefore, the loop detection function cannot be implemented in the existing network. The loop detection function of the MA5600 V300R003C05 is optimized. The loop detection function is implemented through a private packet, and the protocol type can be set. If a port receives the loop detection packet transmitted by the MA5600, the MA5600 deactivates this ADSL port that receives the packet based on the information of the ADSL port in the packet. Thus, the loop network on the user side can be prevented.

1.7 Dark Screen Occurs When an IPTV User Is Watching a Scrambled Live Channel Under

the MA5600 Because the Encryption Key of the CA Card Expires

Title: Dark Screen Occurs When an IPTV User Is Watching a Scrambled Live Channel Under the MA5600 Because the Encryption Key of the CA Card Expires ID: SE0000383788



Fault Type: BTV Service

Keywords: MA5600, IPTV, CA system, encryption key, dark screen


iption: A certain IPTV user on the triple play network of certain operator reports that dart screen occurs when watching the scrambled live channel. Other services for the user, such as HSI and VoD,



9

are normal. In addition, the user can watch the unscrambled channels.

Alarm Information:

Run the debug IGMP packet command on the MA5600 and it is found that the MA5600 can receive the report messages from the multicast groups with the IP addresses 226.1.1.1 and 226.1.3.10. The MA5600, however, prompts that the programs do not exist.

Cause Analysis: The possible causes of dark screen when end users watch live channels are as follows: 1. The hardware of the STB terminal is faulty or the STB is not configured properly.. 2. The home gateway is not configured properly or the physical connection of the home gateway is improper. 3. The DSLAM is configured improperly. For example, the multicast programs where dark screen occurs are not configured, or the IGMP bandwidthCAC command is executed. 4. The upper-layer multicast router is faulty, which causes that the multicast stream is not added to the terminal. 5. A certain head-end system of the IPTV, such as the CA system, encoder, or middleware, is faulty.

Handling Process:

According to onsite tests, the fault is not caused by the user-side network or improper configuration of the DSLAM. It is confirmed that the subsystems at the head-end of the IPTV work normally. In addition, the multicast stream is issued when the user demands programs, which is confirmed by the port traffic information queried on the DSLAM. Hence, the fault is not caused by the upper-layer multicast router. Through the analysis of the symptoms and scope of the fault, it is found that the fault is caused by the CA system at the head-end of the IPTV. This is also proved by the fact that the terminal end can watch unscrambled channels. The CA system is a product of a third-party manufacturer. The manufacturer explains that the fault occurs because the encryption key of the CA card in the STB expires. Usually, the head-end CA system transmits the group and global EEM streams to the CA system periodically to update the encryption key of the CA card. The group and global EEM streams are transmitted through multicast addresses 226.1.1.1 and 226.1.3.10. The validity period of the CA card is preset when it is delivered from the factory. If the CA card fails to receive any updated EMM streams during the validity period of the encryption key, dark screen occurs when IPTV users watch scrambled live channels under the MA5600 after the encryption key expires. According to onsite tests, the encryption key of the CA card fails to be updated mainly because of the following causes: 1. The MA5600 is not configured with the multicast programs that issue the EMM streams. Hence, the STB cannot receive the EMM streams to update the encryption key of the CA card. Run the debug IGMP packet command on the MA5600 and it is found that the MA5600 can receive the report messages from the multicast groups with the IP addresses 226.1.1.1 and 226.1.3.10. The MA5600, however, prompts that the programs do not exist. 2. The STB of certain versions is configured with an incorrect update address when it is installed. Hence, the version of the STB fails to be updated. In this case, the STB does not request the DSLAM to issue the EMM streams. That is, the STB does not transmit the report message. 3. The fault is caused by personal behaviors of the end user. For example, the user does not watch TV for a long time. The STB is in the shutdown state, and thus the encryption key of the CA card fails to be updated. In this case, the user needs to wait for 90 minutes at most after starting the terminal so that the encryption key can be updated.


This fault cannot be recognized easily, and thus is not recognized during earlier PAT and FUT tests. The IPTV is a complicated system that contains a number of products. Hence, we need to learn the service flow of the entire IPTV system profoundly. In this case, the MA5600 fails to be configured with the multicast programs that issue the EMM streams because the access network engineers do not know the CA system and engineers from different product lines lack communication with each other. The EMM streams are not common media program streams. Hence, the terminal user can watch live channels normally even if the precedingly mentioned multicast programs are not configured on the DSLAM. In the case of long period for the first update of the encryption key after it expires, the third-party manufacturer optimizes the parameters of the CA system according to the requirement of Huawei. Currently, the update of the encryption key of the CA card in the STB terminal requires less than 20 seconds.



10

1.8 The IPOA Encapsulation Causes the Failure to Delete the Service Port

Title: The IPOA Encapsulation Causes the Failure to Delete the Service Port




Fault Type:

Keywords: IPOA


iption: MA5600V3R2D260(config)#undo service-port vlan 400 { |ima|autosense|atm|e3|adsl|shdsl }: Command: undo service-port vlan 400 It will take several minutes, and console may timeout, please use command idle -timeout to set time limit Are you sure to release service virtual port(s)? (y/n)[n]:y Failure: No service virtual port can be released, service virtual port is being used or processed

Alarm Information:

Failure: No service virtual port can be released, service virtual port is being used or processed

Cause Analysis: 1. The right is restricted. 2. The port is for the BTV user. 3. The port is bound to an IP address or a MAC address. 4. The port is configured with a static MAC address. 5. The port is encapsulated as the PPPoA, IPoA or Auto mode.

Handling Process:

1. Log in to the MA5600 as admin. It is found that the right is not restricted. 2. Run the display igmp user command. It is found that no multicast user exists. 3. Run the display bind adsl command. It is found that the port is not bound to any IP or MAC address. 4. Run the MA5600V3R2D260(config)#display mac-address static command. The result displayed is as follows: Failure: MAC address does not exist The port is not configured with a MAC address. 5. Check the encapsulation mode. It is found that the encapsulation mode is IPOA. MA5600V3R2D260(config)#display encapsulation { type|number|frame/slot/port|frame/slot }:0/0/4 { |type|number }: Command: display encapsulation 0/0/4 ---------------------------------------------------------------------------- F/S /P VPI VCI ENCAP SRCIP DSTIP SRCIP-MODE ---------------------------------------------------------------------------- 0/0 /4 8 35 llc_bri - - - 0/0 /4 0 35 llc_ip 0.0.0.0 192.168.1.1 dynamic ----------------------------------------------------------------------------



11

Total: 2 Note : F--Frame, S--Slot, P--Port(or Virtual Port, such as IMA GROUP, VLAN ID etc.), The VPI is access-end VLAN ID in VDSL port 6. Encapsulate the port as bridge mode, and the service port can be deleted successfully. MA5600V3R2D260(config)#encapsulation 0/0/4 vpi 0 vci 35 type bridge llc Set encapsulation type successfully


Null

1.9 The Dialup of the Subscribers Connected to the MA5600 Fails Due to the Incorrect

Setting of the Broadcast Suppression on the Convergence Switch

Title: The Dialup of the Subscribers Connected to the MA5600 Fails Due to the Incorrect Setting of the Broadcast Suppression on the Convergence Switch ID: SE0000374652



Fault Type:

Keywords: Broadcast suppression, PADI, 678


iption: Networking: MA5600---Convergence switch---BRAS Symptom: Around 7 p.m. when a large number of subscribers go online, the 678 error is displayed for the subscribers connected to the MA5600. The services of the subscribers online, however, are in the normal state.

Alarm Information:

Null

Cause Analysis: The cause of the "678 the remote PC has no response" error is that the PC does not receive the PADO packets from the BRAS within a period of time after transmitting the PADI packets. Any faulty segment of the link between the PC and the BRAS can cause the 678 error when the PADI packets cannot be transmitted to the BRAS or the PADO packets transmitted from the BRAS are lost. Therefore, when the 678 error is displayed, the link between the PC and the BRAS needs to be checked segment by segment to locate the fault.

Handling Process:

1. When the 678 error is displayed, the services of the subscribers online are in the normal state. Ping the N2000 BMS from the device. It is found that the packets are not lost on the N2000 BMS. It indicates that the physical link is normal. 2. Check the data configuration of the MA5600. It is found that no ACL is bound to the upstream port and the script of this MA5600 is the same as the scripts of other normal MA5600s. Therefore, it can be determined that the data configuration of this MA5600 is correct. 3. Check the configuration of the convergence switch. It is found that the port of the MA5600 is configured with "broadcast-suppression 1", which indicates that when the broadcast packets occupy more than 1% of the total port bandwidth, the excessive broadcast packets will be discarded. During the peak hours, the bandwidth occupied by various broadcast packets (including the normal ARP request packets, PADI packets and the packets transmitted by the PC after being infected with viruses) exceeds 1% of the total bandwidth. As a result, the PADI packets transmitted by the new dialup subscribers are discarded, which results in the dialup failure. Disable the broadcast suppression on the port of the convergence switch, and it is found that the fault is rectified.



12


When the 678 error is displayed, the link between the PC and the BRAS needs to be checked segment by segment to locate and then rectify the fault.

1.10 Continuously Online and Offline of ADSL ports

Title: Continuously Online and Offline of ADSL ports

ID: SE0000388676


Views: 16

Author: Dikshant Vijayvargia



Keywords: Continuously Online and Offline of ADSL Port

Permission Level: 03Equipment Users Permission


When I was implementing Broadband Service then I found the repeated online and offline of ADSL port. Before implementing this service i didn't check the SNR Margin at the port. I found same problem for many eqipment. And finally I checked the line condition at the port. At some ports the supported Upstream Channel SNR Margin was 16.5 dB and downstream Channel SNR Margin was 23 dB but configured Upstream Channel SNR Margin is 31 dB and downstream Channel SNR Margin is 46 dB (As per Configuration). Due to this mismatch the problem was arised. This SNR Margin check was applicable for all versions.

Alarm Information:

Null

Cause Analysis: The problem was arised due to faulty physical line.The available physical line didn't support the required SNR Margin for the Line Profile configured.

Handling Process:

To solve this problem i changed the physical line to another line and check the line conditions. The SNR Margin of new physical line were matched with our requirements. To check the SNR margin i use this command "display line operation port port_no."


This will be very useful when we are implementing any service on any port. Before providing any service to a customer ( on any particular port ), we should check theSNR Margin for that particular physical line. By doing this we can imlement the service according to the standards.

1.11 MA5600 is not showing alarms on imanager N2000 BMS

Title: MA5600 is not showing alarms on imanager N2000 BMS

ID: SE0000380726




13

Views: 8

Author: Vikas chaudhary


Fault Type: Host/Network Management System (independent from service)

Keywords: MA5600 is not showing alarms on imanager N2000 BMS



MA5600 version-V2 Imanager N2000 BMS version-V2 MA5600 is not showing any alarm on Imanager N2000 BMS. If some Fault occur on MA5600 ,it is not get noticed on Imanager N2000 BMS.

Alarm Information:

There was a red LED(alarm) glowing on the controller card of MA5600.

Cause Analysis: There is a red LED(alarm) glowing on the controller card of MA5600 but there was no indication of this alarm on imanagerWhen i manually generate some alarm on MA5600 example pull out one of the controller card,then also there was no alarmconfiguration of SNMP trap source on MA5600 ---->> ADN-DLM-960-M-01 (config)# snmp-agent community read public ADN-DLM-960-M-01 (config)# snmp-agent community write private ADN-DLM-960-M-01 (config)# snmp-agent sys-info version v1 v2c ADN-DLM-960-M-01 (config)# snmp-agent target-host trap address 172.16.2.183 securityname Huawei ADN-DLM-960-M-01 (config)#snmp-agent trap enable standard ADN-DLM-960-M-01 (config)#snmp-agent trap source Meth0 Problem solving procedure: 1. SNMP-agent traget-host trap adress should be floating ip in case of two ip adress of server. I have changed snmp-agent2. I have changed snmp-agent trap source Meth0 to Management Vlan,i.e replace Meth0 by Management vlan of MA5600.3.On imanager N2000 BMS go to fault setting and make auto sink to be on.

Handling Process:

There is a red LED(alarm) glowing on the controller card of MA5600 but there was no indication of this alarm on imanagerWhen i manually generate some alarm on MA5600 example pull out one of the controller card,then also there was no alarmconfiguration of SNMP trap source on MA5600 ---->> ADN-DLM-960-M-01 (config)# snmp-agent community read public ADN-DLM-960-M-01 (config)# snmp-agent community write private ADN-DLM-960-M-01 (config)# snmp-agent sys-info version v1 v2c ADN-DLM-960-M-01 (config)# snmp-agent target-host trap address 172.16.2.183 securityname Huawei ADN-DLM-960-M-01 (config)#snmp-agent trap enable standard ADN-DLM-960-M-01 (config)#snmp-agent trap source Meth0 Problem solving procedure: 1. SNMP-agent traget-host trap adress should be floating ip in case of two ip adress of server. I have changed snmp-agent2. I have changed snmp-agent trap source Meth0 to Management Vlan,i.e replace Meth0 by Management vlan of MA5600.3.On imanager N2000 BMS go to fault setting and make auto sink to be on. problem is resolved and we can see the alarm of MA5600 on imanager N2000 BMS.


1.SNMP agent trap source should be management vlan on MA5600.2. SNMP-agent-trap-host trap adress should be floating ip. 3.On Imanager N2000 BMS auto sink should be on.



14

1.12 Conflict mac-address also can not manage dslam from inbound management

Mac Address (Case Topology)

10.12.24.7136

10.12.24.7237

10.12.24.7338

10.12.24.7035

10.12.24.6934

10.12.24.6833

10.12.24.6732

10.12.24.6631

10.12.24.6530

10.12.24.6429

10.12.24.6328

10.12.24.6227

10.12.24.6126

10.12.24.6025

10.12.24.5924

10.12.24.5823

10.12.24.5722

10.12.24.5621

10.12.24.5520

10.12.24.5419

10.12.24.5318

IP of DSLAMDSLAM

Title: Conflict mac-address also can not manage dslam from inbound management

ID: SE0000365895


Views: 19

Author: Kores F B Sinaga - 00713498


Fault Type: Host/Network Management System (independent from service)

Keywords: mac-address conflict inbound management



Can not manage DSLAM33 and DSLAM 34 from Inbound-NMS network.Also found conflict mac-address both of DSLAM34 and BRAS. (You can the topology case in the attachments bellow)

Alarm Information:

Null --> No Alarm, (These not impacted to The Service)

Cause Analysis: Found MAC ADDRESS CONFLICT BETWEEN DSLAM33, DSLAM34, AND BRAS. A.Check All DSLAM on site, Local DSLAM (Telkom Central Office of Gambir Area) B.Can not reach (Ping and Telnet) DSLAM34 from Inbound-NMS, The Interface VLAN Management was down.C.Found DSLAM34 mac-address used in DSLAM33 Mac-Address. C.1.Check Mac-Address of Interface VLAN Management firstly both of DSLAM33 and DSLAM34. C.2.Found VLAN Management Interface of DSLAM34 Down, even the physical interface up, service running normally, and also already delete and recreate vlan management interface of DSLAM34. Use with these command bellow : DSLAM33-D2-GBR(config)#display arp all IP Address MAC Address VLAN ID Port Type 10.12.24.69 00e0-fc84-a76e 26 0 /7 /0 Dynamic >> DSLAM 34 ......... 10.12.24.1 00e0-fc84-a76e 26 0 /7 /0 Dynamic >> BRAS DSLAM34-D2-GBR(config)#display interface vlanif 26



15

vlanif26 current state : DOWN Line protocol current state : DOWN Description : HUAWEI, MA5600 Series, vlanif26 Interface The Maximum Transmit Unit is 1500 bytes Internet Address is 10.12.24.69/24 IP Sending Frames' Format is PKTFMT_ETHNT_2, Hardware address is 0018-8243-035a DSLAM32-D2-GBR(config)#display arp all IP Address MAC Address VLAN ID Port Type 10.12.24.69 00e0-fc84-a76e 26 0 /7 /0 Dynamic >> DSLAM 34 . 10.12.24.68 0018-8243-035a 26 0 /7 /1 Dynamic >> DSLAM 33 10.12.24.1 00e0-fc84-a76e 26 0 /7 /0 Dynamic >> BRAS D.Mac-address conflict both of DSLAM34 and BRAS.

Handling Process:

A.Check All DSLAM on site, Local DSLAM (Telkom Central Office of Gambir Area - Jakarta - Indonesia) B.Make sure that DSLAM34 already have same Mac Address for both of Current and Default. B.1.Example command to show the state : DSLAM34-D2-GBR(diagnose)%%display sysman mac-address Current MAC address of active mainboard: 0018-8243-0357 Default MAC address of active mainboard: 0018-8243-0357 B.2.If found difference mac-address, please restore it, with these sample below : MA5600(config)#diagnose MA5600(diagnose)%%display sysman mac-address Current MAC address of active mainboard: 00e0-fc5d-bc87 Default MAC address of active mainboard: 00e0-fc5e-a149 MA5600(diagnose)%%sysman mac-address current 00e0-fc5e- a149 Modifying current MAC address may cause the conflict of MAC address, are you sure?(y/n) [n]:y Command is being executed, please wait... The configuration takes effect after system is restarted (After System restart) MA5600(diagnose)%% display sysman mac-address Current MAC address of active mainboard: 00e0-fc5e-a149 Default MAC address of active mainboard: 00e0-fc5e-a149 (Note : Please due the step with used hwmusa) C.Make sure that DSLAM33 already have the same Mac Address for both of Current and Default. C.1.Found difference mac-address for both of current and default, also found mac-address DSLAM34 used in Vlanif26 DSLAM33, as you can seen with these state bellow : Use with these command bellow : DSLAM33-D2-GBR(config)#display interface vlanif 26 vlanif26 current state : UP Line protocol current state : UP Description : HUAWEI, MA5600 Series, vlanif26 Interface The Maximum Transmit Unit is 1500 bytes Internet Address is 10.12.24.68/24 IP Sending Frames' Format is PKTFMT_ETHNT_2, Hardware address is 0018-8243-035a DSLAM33-D2-GBR(diagnose)%%display sysman mac-address Current MAC address of active mainboard: 0018-8243-0357 Default MAC address of active mainboard: 0018-8243-001e D.Delete Interface Vlan Management (Vlanif26) in DSLAM33. E.Restore Current to Default mac-address in DSLAM33. Use with these command bellow : DSLAM33-D2-GBR(diagnose)%%display sysman mac-address Current MAC address of active mainboard: 0018-8243-001e Default MAC address of active mainboard: 0018-8243-001e F.Reboot System in DSLAM33 G.Delete VLAN MANAGEMENT (Vlanif26) in DSLAM34 H.Recreate VLAN MANAGEMENT (Vlanif26) in DSLAM34. I.Create VLAN MANAGEMENT (Vlanif26) in DSLAM33 after system rebooted. (Due after DSLAM34 has done delete and recreate vlanif first).


Problem happened because of Conflict Mac-Address between DSLAM33, DSLAM34, and BRAS. Problem in Inbound ManaNext, if you found the same case, please check the local network first, and make sure that each dslam already used their ow



16

1.13 Why is the Multicast Service Unstable After the MA5600 Enables the CAC Function

Title: Why is the Multicast Service Unstable After the MA5600 Enables the CAC Function

ID: SE0000367917


Views: 13

Author: w64795


Fault Type: BTV Service

Keywords: CAC



When the Set Top Box (STB) is connected to the ADSL service port of the MA5600, it is found that the multicast service is unstable. After running the igmp bandwidthCAC disable command, you can solve the problem. Why?

Alarm Information:

Null

Cause Analysis: BandwidthCAC---multicast bandwidth check, when it is set to disable, the bandwidth check is not performed. Be default, it is set to enable on the MA5600. The multicast bandwidth check is classified into the check on the uplink port bandwidth and the check on the user side bandwidth. Simply speaking, when the bandwidthCAC function is enabled, check the uplink port bandwidth: compare the bandwidth allocated to the uplink port with the bandwidth to be used by the uplink port program. If the former bandwidth is larger, you can order the program. Otherwise, you cannot order the program. Check the user side bandwidth: Compare the bandwidth allocated to the user with the bandwidth to be used by the user. If the former bandwidth is larger, you can order the program. Otherwise, you cannot order the program. The bandwidth allocated to the uplink port is the product of the uplink port bandwidth and the percentage of the bandwidth allocated to the multicast. The bandwidth to be used by the uplink port program is the bandwidth sum of the programs bound to the uplink port. The bandwidth allocated to the user is the product of the downstream rate of the user port and the percentage of the bandwidth allocated to the multicast user. The bandwidth to be used by the user is the bandwidth sum of all the programs ordered by the user. This is the reason that you can solve the problem by modifying the program bandwidth.

Handling Process:

igmp bandwidthCAC { enable | disable } This command is used to enable or disable the multicast Connection Admission Control (CAC) of the uplink port and the user port, which is called the bandwidth management function. When you need to restrict the bandwidth on the uplink port and the user port for the multicast program, you can run this command to enable this function. After the bandwidth management function is enabled, the bandwidth restriction on the uplink port takes effect immediately. The bandwidth restriction on the user port takes effect when you order the program the next time. After the multicast CAC function is disabled, the multicast bandwidth management is not performed for the uplink port and the user port. The system does not guarantee the bandwidth of the multicast program. When the CAC function is enabled: 1. Check the maximum multicast bandwidth that is allowed by the service port for passing. 2. Query the bandwidth of the program that is being played by the service port. 3. If the bandwidth of the required program is larger than the remaining allowed bandwidth of the service port, you cannot order the program. Otherwise, you can order the program. When the CAC function is disabled: 1. Check the maximum multicast bandwidth that is allowed by the service port for passing. 2. Query the bandwidth of the program that is being played by the service port. 3. If the bandwidth



17

of the required program is larger than the remaining allowed bandwidth of the service port, you can order the program. If the allowed bandwidth of the service port is insufficient, the packet loss occurs. In this case, the multicast service is unstable.


The program bandwidth is statically configured when the multicast program is added. For the actual IPTV service application, the program rate of the multicast source of the carrier should be invariable. When configuring the multicast program on the MA5600, ensure that the program bandwidth is configured the same as the bit rate of the program source of this program. In this way, the bandwidth check can be effective. The main purpose of the bandwidth check is to check and ensure that the total bandwidth occupied by the program of the uplink port/user port does not exceed the rate actually supported by the uplink port/user port (otherwise, the packet loss occurs). If you can ensure on the networking that the total bandwidth occupied by the program of the uplink port/user port does not exceed the rate actually supported by the uplink port/user port, you can disable the bandwidth check.

1.14 FAQ-How Does the MA5600 Support Anti DoS Attack Function

Title: FAQ-How Does the MA5600 Support Anti DoS Attack Function


Type : Troubleshooting Cases Quality Level: B


Fault Type: Virus/Attack

Keywords: DOS MA5600


iption: Q: How does the MA5600 support the anti DoS attack function?

Alarm Information:

Null

Cause Analysis: Null

Handling Process:

A: The anti Dos attack in the MA5600 is a function that the system detects whether the DoS attack occurs with the physical port as a granularity for xDSL boards. The principle: After the security anti-dos enable command is executed to enable the anti Dos attack function successfully, the system limits the rate of sending the packets to the CPU of each service board to 20 pps. Meanwhile, the packets sent to the CPU of each service board are detected once every five seconds, and the detection is performed four times consecutively. Every time the rate detected exceeds 20 pps, it is regarded that the DoS attack occurs. Then, the port sending the packets is added to the DoS blacklist, and an alarm is generated. The MA5600 system does not change the status of the port added to the blacklist, but prohibits the port from sending the packets to the CPU of the service board. Other service packets, however, can be forwarded (the forwarding is performed by each service board). Meanwhile, the system starts a timer with the duration of 180s. When the timer times out, which means that



18

within 180s, no DoS attack occurs (To CPU packet



19

1.16 FAQ-How to Solve the Problem That the MA5600 is Enabled with Anti-MACspoofing

So That the Hot-Spot Service in the Modem with the Fixed IP Address is Interrupted

Title: FAQ-How to Solve the Problem That the MA5600 is Enabled with Anti-MACspoofing So That the Hot-Spot Service in the Modem with the Fixed IP Address is Interrupted




Fault Type: Others

Keywords: MA5600, MAC spoofing, fixed IP hot-spot


iption: Host version: MA5600 V300R003C02B068Networking: Broadband access ADSL2+, triple play, and IPoA services Hotspot: clients-->wirelessAP-->Modem-->MA5600-->upper layer network Fault phenomenon: The customer complains that the port can be activated but the connected hotspot access service fails.

Alarm Information:

Null

Cause Analysis: The problem of activation success but access failure involves the entire shelf. In addition, it is confirmed that multiple sites have the similar problems. The involved service is single (hotspot). At the time, the customer tries to enable anti-MACspoofing, which causes the special service disconnection. Therefore, the hardware or system fault is excluded. The possible cause is that the terminal device is incompatible with the system configuration.

Handling Process:

1. After a query, it is found that the port is in activated status and passes atm-ping. It indicates that the channel between the CPE and the board is smooth. 2. Query the MAC address learnt by the port. It is found that no MAC address is obtained. The wireless AP problem is excluded. 3. After the MACspoofing is disabled, the service is in the normal state. The port can learn the MAC address. The problem focuses on why the CPE cannot send the packets with the MAC address in the normal state. 4. It is found that other IPoA users configured with the static IP addresses are not affected. According to query, the MAC addresses can be obtained but are assigned by the system MAC address pool. 5. Add the MAC address of the modem manually to the system. The problem is solved. 6. It is confirmed that the problem is caused by the terminal modem, which is configured with the static IP address. In this case, there is no DHCP/ARP interaction, and the authentication mode is not PPPoE/A. Therefore, the MA5600 cannot obtain the IP address.


After anti-MACspoofing is enabled, the mechanism for the MA5600 to learn the MAC addresses changes, which is that passively wait for the port to interconnect the modem and the MAC address is intercepted from the PPPoE/A,DHCP/ARP packets. The problems occur in this case mostly because the port cannot obtain the MAC address. The disable MACspoofing MAC function is obtained by the service board negotiating with the modem through the inAtmArp protocol. Therefore, this problem does not occur. In addition, the services to which the system uses the MAC pool to assign the MAC address type of the port are not affected, such as IPoA services.



20

1.17 FAQ-how to judge what is the problem about ADSL line quality

FAQ-how to judge what is the problem about ADSL line quality SE0000396417

Troubleshooting Cases Quality Level: C

Broadband Access Product: SmartAX MA5600

ADSL Access Service ADSL line quality

01Huawei Engineers Permission

Q: there are many problem is caused by ADSL line quality ,but how can we judge it and fix it ?

Null Null A: 1. check whether the line is too long or not. according the attenuation in down stream, if the attenuation in downstream is over 40dB, it means the length of the line is overrun about 4km, and it is hard to active2. check the line quality . if the attenuation in upstream is large that it in downstream, it means there is a probelm about line quality , and it need the customer to check the line . 3. check the disturbing by external factor. check the SNR parameter. if it changes in a large range, and it becomes to negative in sometimes. we can confirm there is disturbing by external factor. 4. check the line collocation at the user's home. check the bit allocation from MA5600, if there is sunken in the bit allocation, it means there is a problem in the filter or the phone in the subscriber side. Null

1.18 FAQ-How to recover admin password in MA5600

Title: FAQ-How to recover admin password in MA5600

ID: SE0000380843


Views: 34

Author: Ma Ming


Fault Type: Others

Keywords: MA5600 root admin password



Q: How to recover admin password of root user in MA5600?



21

Alarm Information:

Null.

Cause Analysis: Null.

Handling Process:

A: in MA5600 V300R002 series version, we have supper account to modify. but in MA5600 V300R003 series version, if we forg

1.19 FAQ - How can you avoid dial-in delay while using PPPoE+

Title: FAQ - How can you avoid dial-in delay while using PPPoE+

ID: SE0000371604


Views: 9

Author: A.Rahman Alaa


Fault Type:

Keywords: PITP Dial in Delay



Q: How you can avoid dial-in delay while using PPPoE+?

Alarm Information:

Null


Handling Process:

A: While using PPPoE encapsulation method for ADSL users and enabling PITP for their security and to prevent user roamiPADO and PADS respectively; the DSLAM removes these tags to forward PADO and PADS to CPE which results as short dLCP packet and dial in process will completed successfully. To avoid this delay; we have two solutions: 1 - On BRAS: let the BRAS wait a delay before sending the LCP cfgreq i.e.,increase the LCP delay by using the below comppp delay-lcp-negotiation. 2 - On DSLAM: Configure PITP mode as V-mode (VBAS) instead of P-mode (PPPoE+) where in V-mode no tags are addedRefer to attached file for PITP P-Mode and V-mode dial-in processes

1.20 FAQ-How to Solve the Problem That the Entire Shelf Fail to Go Online Due to the

MA5600 Upstream Fiber Problem

Title:

ID: SE0000369685


Views: 9

Author: s00705665


Fault Type: Others

Keywords: MA5600, fail to go online, upstream fiber


Phenomenon Descr Host version: MA5600 V300R003C02B068



22

iption: Networking: DSLAM broadband access ADSL2+ and triple play services Fault phenomenon: The customer complains that a large number of ports in a site fail to go online. The ports, however, can be activated.

Alarm Information:

Null

Cause Analysis: The modem can be activated but a large area of the entire shelf fails to go online or goes online very slowly. The main possible causes are as follows: 1. The backplane or the service board cannot communicate with the control board (upstream) in the normal state. 2. The profile configuration is incorrect and the line has interference. 3. A virus occurs in the MAC or IP address spoofing. 4. The upstream daughter board, fiber line, or interconnection switch of the MA5600 is faulty.

Handling Process:

Complaint process: The customer receives occasional complaints against the failure to go online. After a checking, it is found that the port is in the normal state and the modem can be activated for a successful access. The complaints, however, persist. After the port is performed with migration (replacing the slot), the complaints persist. After a week, the number of complaints increases. The customer requires Huawei to assist in the investigation. The initial complaints against the port activation failure cause great trouble to identify the problem. Subsequently, it is confirmed that the port can be activated successfully. The problem is identified as follows: 1. After the service runs on the existing network for a while, no hardware alarm is reported. The problem lies in the entire shelf. Multiple service boards are replaced. The hardware problem is excluded. 2. The line profile configuration complies with the line profile configuration in other sites of the existing network by trying the interleaved mode. Then, the problem is not solved. The loopback and the afe atm-ping are in the normal state. 3. Enable the anti IP address spoofing and anti MAC address spoofing functions for the host, and there is no record in the security blacklist. 4. Consult the upstream peer switch, and there is no ecrc error or other error code record. The PPPoE authentication and access are smoothly successful. 5. Connect the PC and the modem to the MA5600. The DHCP, DNS, and PPPoE packets are captured completely. The web site cannot be opened. After the optical module is replaced, the fault persists. After the customer replaces the interconnected switch port, the fault still persists. Use the special fiber detector to find that the RX is normal and the error code rate of the TX lower layer is relatively high. After the fiber is replaced, the problem is solved.


For the existing network problem, you need to identify the affected range of the single port, multiple ports, board, cross-boards, and entire shelf, and then identify the problem from software to hardware. If the protocol is in the normal state, identify the problem at the lower layer. For example, the fiber error code may not be displayed by capturing the ethereal packets.

1.21 FAQ-Is the 32-Channel Service Board Slot Compatible with the 64-Channel Service

Board on the MA5600

Title: FAQ-Is the 32-Channel Service Board Slot Compatible with the 64-Channel Service Board on the MA5600 ID: SE0000374651


Views: 16

Author: z93854



23


Fault Type: Backplane/Board Hardware

Keywords: 32-channel



Q: Is the 32-channel service board slot compatible with the 64-channel service board on the MA5600?

Alarm Information:

Null


Handling Process:

A: The heat generated by the 64-channel service board is more than that of the 32-channel service board, so the power of the fan tray for the 32-channel service board ca

2008-2009 huawei access network product cases

Documents