3.6
FAQ-How to Implement the Interwork ing Between Different FE Ports on the MA562xG
Title:
FAQ-How to Implement the Interworking Between Different FE Ports on the MA562xG
ID: SE0000374104 Information Troubleshooting Cases Type : Product Family: Optical Access
Quality Level:
C
Product: MA5680T
Fault Type: ONT terminal Keywords: Interworking Permission 04Common Users Permission Level:
Confidential Information of Huawei. No Spreading without Permission
45
NGN Cases
Chapter 3 GPON FTTx Cases
Phenomenon De Q: scription: Different FE ports on the MA562xG are separated by default. How to implement the interworking between different FE ports in one VLAN at layer 2?
Alarm Informatio Null n: Cause Analysi Null s: Handling Proces A: s: Run the undo isolate port command to implement the interworking. For example, run the following commands to cancel the separation between ports 0/1/1 and 0/1/2 so that ports 0/1/1 and 0/1/2 can communicate with each other: MA5626(config)#undo isolate port 0/1/1 MA5626(config)#undo isolate port 0/1/2
3.7
The Interconn ection Between the Swit ch of Company C and MA5600T Fails Because the LACP Configuration of t he Switc h of Company C Is Incorrect
Title:
The Interconnecti on Betw een the Switch o f Company C and MA5600T Fails Because the LACP Configuration of the Switch of Company C Is Incorrect
ID: SE0000374363 Information Troubleshooting Cases Type : Product Family: Optical Access
Quality Level:
C
Product: MA5600T Series
Fault Type: Equipment Interconnection Keywords: Switch 6500 of company C, MA5600T, LACP Permission 03Equipment Users Permission Level: Phenomenon De In an oversea commercial office, the customer requests that Huawei MA5600T must be scription: connected upstream to the switch 6500 of company C in the lacp-static mode. After the lacp-static mode is configured normally as follo ws, alarms are generated and services fail. MA5680T(config)#link-aggregation 0/17 0-1egress-ingress workmode lacp-static MA5680T(config)#display link-aggregation all --------------------------------------------------------------------Master port Link-aggregation mode Port NUM Work mode --------------------------------------------------------------------0/17/0 egress-ingress 2 lacp-static --------------------------------------------------------------------Total: 1 link-aggregation(s)
46
Confidential Information of Huawei. No Spreading without Permission
MSAN UA5000 Cases
Chapter 3 GPON FTTx Cases
Alarm Informatio MA5600T(config)#link-aggregation 0/17 0-1 egress-ingress workmode lacp-static n: MA5600T(config)# ! EVENT MAJOR 2008-07-15 13:42:03 ALARM NAME :Port is forbidden to transfer the service packets PARAMETERS :FrameID: 0, SlotID: 17, PortID: 0 NWT_MA5680T(config)# ! EVENT MAJOR 2008-07-15 13:42:03 ALARM NAME :Port is forbidden to transfer the service packets PARAMETERS :FrameID: 0, SlotID: 17, PortID: 1
Cause Analysi 1. The optical path is faulty. Check the upstream GICF board and switch 6500 of s: company C. The ports are set to the 1000 M full-duplex mode forcibly and the optical port is in the UP state. This indicates that the optical path is normal. 2. The data configuration of the upstream port of the MA5600T is incorrect. Cancel the link aggregation. The upstream service of a single link is normal. This indicates that the data configuration of the upstream port of the MA5600T is correct. 3. The configuration of the Link Aggregation Control Protocol (LACP) is incorrect. Configure aggregation and do not run LACP: MA5600T(config)#link-aggregation 0/17 0-1egress-ingress MA5600T(config)#display link-aggregation all --------------------------------------------------------------------Master port Link-aggregation mode Port NUM Work mode --------------------------------------------------------------------0/17/0 egress-ingress 2 manual --------------------------------------------------------------------Note: the system at both ends of the LACP static aggregation group link runs LACP, but the system at both ends of the LACP manual aggregation group link does not run LACP. Services are normal when LACP is not run. Therefore, it can be determined that the fault is caused by the LACP interconnection. 4. The configuration of the switch 6500 of company C at the peer end is incorrect.
Handling Proces 1. The switch 6500 of company C supports two protocols, that is, Port Aggregation s: Control Protocol (PAgP) and LACP, and PAgP is used by default. It is suspected that the cause of the interconnection failure is that the default PAgP is configured. Check the configuration with the customer and find that LACP is configured. 2. Run the following commands to configure LACP of the switch 6500 of company C to be in the active mode: Router# configure terminal Router(config)# interface range fastethernet 5/6 -7 Router(config-if)# channel-group 2 mode active Router(config-if)# end Check services again and the problem is solved.
Suggestions and Summary: The switch 6500 of company C supports PAgP and LACP. PAgP is patented Summary: by company C and LACP is specified in the IEEE 802.3AD. The default configuration is PAgP. You can run the set channelprotocol [pagp | lacp] command to change the default configuration. PAGP uses the standard of company C, but LACP uses the IEEE standard. Therefore, company C modifies the new SUPERVISOR to support LACP. If WS-X6K-SUP1A-MSFC or WS-X6K-SUP1A-MSFC2 exists in the show module of switch 6500 of company C, LACP is supported. LACP of switch 6500 of company C includes two modes: Passive LACP mode: The port is in the passive state and the active LACP negotiation is disabled. This mode is used by default. Active LACP mode: The port is in the active state and the active negotiation is enabled on this port. In this case, the customer configures only the LACP mode on the switch 6500 of company C but does not enable the active negotiation. As a result, the interconnection Confidential Information of Huawei. No Spreading without Permission
47
NGN Cases
Chapter 3 GPON FTTx Cases between the switch 6500 of company C and MA5600T fails. Suggestions: When the MA5600T is aggregated upstream to the switch 6500 of company C, LACP and the active mode must be configured on the switch 6500 of company C so that the LACP negotiation between the MA5600T and s witch 6500 of company C is enabled. The active negotiation mode is used on Huawei MA5600T by default.
3.8
FAQ-How to Change the Default T-CONT 0 Type of the MA5600T Prov idi ng the GPON Service
Title:
FAQ-How to Change the Default T-CONT 0 Type of t he MA5600T Provi din g th e GPON Servi ce
ID: SE0000374364 Information Troubleshooting Cases Type : Product Family: Optical Access
Quality Level:
C
Product: MA5600T Series
Fault Type: Host/Network Management System(independent from service) Keywords: MA5600T, GPON, T-CONT 0, OMCI type Permission 01Huawei Engineers Permission Level: Phenomenon De Q: scription: How to change the default T-CONT 0 type of the MA5600T providing the GPON service?
Alarm Informatio Null n: Cause Analysi Null s: Handling Proces A: s: On the MA5600T of R51, the system configures a T-CONT 0 for each ONT by default and a fixed 5 Mbit/s bandwidth is used for the OMCI and cannot be ch anged. For details, see the FAQ-How to Allocate the Reserved Bandwidth of the MA5680T (ONT) Providing the GPON Service for the Upstream OMCI. On the MA5600T of R52 and later versions, the type of T-CONT 0 can be changed to assured and the minimum bandwidth can be configured to 1 Mbit/s. In the implementation, each ONT uses T-CONT 0 for the OMCI by default and each T-CONT 0 uses DBA 1 profile, which are applicable to R51 and R52. The DBA 1 profile uses the fixed 5 Mbit/s bandwidth by default. Therefore, when the MA5600T is upgraded from R51 to R52, the configuration does not change and the OMCI uses the fixed 5 Mbit/s bandwidth by default. To change the bandwidth and type of T-CONT 0 for the OMCI on the MA5600T of R52, do as follows: 1. Add a DBA profile, such as profile 10. The type of T-CONT 0 is assured and the bandwidth of this profile is 1 Mbit/s. Profiles 1-9 are default profiles and cannot be changed. 2. In the board mode, run the tcont modify-profil command to change the DBA profile bound to T-CONT 0 to 10. According to the command, this operation is to change the DBA profiles of ONTs one after another. Therefore, a script must be made to change the DBA profiles in batches. ———The detailed procedure is as follows:——— MA5600T(config-if-gpon-0/13)#display ont info 0 0 T-CONT-ID DBA-profile Alloc-ID 010 48
Confidential Information of Huawei. No Spreading without Permission
MSAN UA5000 Cases
Chapter 3 GPON FTTx Cases
T-CONT 0 of the OMCI uses DBA profile 1 by default. MA5600T(config)#dba-profile add type2 assure 1024 If the bandwidth and type of T-CONT 0 for the OMCI need to be changed on the MA5600T of R52, a DBA profile needs to be added. The type of the T-CONT 0 is assured and the bandwidth is 1Mbit/s. MA5600T(config)#display dba-profile all ---------------------------------------------------------------------------Profile-ID type Bandwidth Fix Assure Max Bind compensation (kbps) (kbps) (kbps) times ---------------------------------------------------------------------------1 1 No 5120 0 0 1 2 1 No 1024 0 0 0 3 4 No 0 0 32768 0 4 1 No 1024000 0 0 0 5 1 No 32768 0 0 0 6 1 No 102400 0 0 0 7 2 No 0 32768 0 0 8 2 No 0 102400 0 0 9 3 No 0 32768 65536 0 10 2 No 0 1024 0 0 ---------------------------------------------------------------------------DBA profile 10 is newly added through query. DBA profiles 1-9 are default p rofiles. The OMCI uses DBA profile 1. The bandwidth and type of T-CONT 0 for the OMCI in slot 13 PON port 0 ONT 0 are changed. MA5600T(config-if-gpon-0/13)#tcont modify-profile 0 0 0 profile-id 10 MA5600T(config-if-gpon-0/13)#display ont info 0 0 ---------------------------------------------T-CONT-ID DBA-profile Alloc-ID ---------------------------------------------0 10 0 ——DBA profile 10 is used.
Suggestions and If 64 ONTs are fully configured on the PON port, 256 Mbit/s (64 x 4) upstream Summary: bandwidths can be released through the preceding operation. This is considerable.
3.9
THE GICF Board Is in the conf ig State and the Service Cannot Recover After the MA5680T Is Restarted
Title:
THE GICF Board Is in th e confi g State and the Service Cannot Recover After the MA5680T Is Restarted
ID: SE0000374164 Information Troubleshooting Cases Type : Product Family: Optical Access
Quality Level:
C
Product: MA5680T
Fault Type: Backplane/Board Hardware Keywords: The GICF board is in the config state Permission 02Huawei Partners Permission Level: Phenomenon De After the MA5680T is restarted, the GICF board is in the config state and the service scription: cannot return to the normal state. The version of the MA5680T is V800R105C33B011. Alarm Informatio Null n: Cause Analysi The optical port must be enabled when the GICF board works normally. After the s: Confidential Information of Huawei. No Spreading without Permission
49
NGN Cases
Chapter 3 GPON FTTx Cases MA5680T is restarted, the LSW port is not in the UP state. As a result, when the high layer protocol of the optical port is enabled, an error is returned and thus the data configuration recovery fails. Therefore, the board is always in the config state.
Handling Proces 1. Delete the data configuration on the GICF board and then delete the GICF board so s: that the MA5680T can discovers the board automatically. Confirm the board and wait until the board works in the normal state. 2. Reconfigure the service data on the upstream GICF board. The s ervice returns to normal. 3. Upgrade the MA5680T to V800R105C33B015 to solve the problem. Suggestions and The condition for triggering this fault is: If service data is configured on the GICF board of Summary: the MA5680T, the GICF board is in the config state and the service cannot return to normal after the MA5680T is restarted. This fault may not occur in V800R105C33B011 and can be rectified after the MA5680T is upgraded to V800R105C33B015.
3.10 The MA5620G Plays the Busy Tone After Offh ook Because of Incorrect Descrip tor Signaling Delivered by the Softswitch of company x
Title:
The MA5620G Plays the Busy Tone Aft er Offhook B ecause of Incorrect Descrip tor Signaling Delivered by the Softswitch o f company x
ID: SE0000367076 Information Troubleshooting Cases Type : Product Family: Optical Access
Quality Level:
C
Product: MA5680T
Fault Type: Equipment Interconnection Keywords: MA5620G, VoIP, busy tone, RFC2327 Permission 04Common Users Permission Level: Phenomenon De Networking: MA5620G--softswitch of company Z scription: Version: SmartAX MA5600 V800R305C01B011HP0001 Symptom: Huawei MA5620G is connected to the softswitch of company Z. After the VoIP service is provided, the MA5620G plays the busy tone after offhook. Alarm Informatio Null n: Cause Analysi 1. The MG interface is disconnected. s: 2. The signaling is not compatible. Handling Proces 1. Check the status of the MG interface. The MG interface is in the normal state. s: 2. Trace the H248 signaling. The softswitch sends the busy tone signal and the local descriptor delivered by the softswitch is incorrect. A space exists between 8 and \n, which does not conform to the RFC2327 protocol. The incorrect packets are as follows: v=0\n c=IN IP4 $\n m=audio $ RTP/AVP 8 \n//A space exists between 8 and \n. a=ptime:20\n\n 3. Ask company Z to modify data of the softswitch. After the softswitch delivers the local descriptor that conforms to the RFC2327 protocol, the caller and callee can make and 50
Confidential Information of Huawei. No Spreading without Permission
MSAN UA5000 Cases
Chapter 3 GPON FTTx Cases
answer phone calls normally and the problem is solved. Suggestions and If devices of other manufacturers are interconnected to the MA5620G of Huawei and the Summary: VoIP service is enabled, tracing the H248 signaling is the best method to solve problems.
3.11 AQ-How to Calcu late the Act ual Spli t Ratio when the xPON Uses the Multi-level Optical Splitting Mode
Title:
FAQ-How to Calculate th e Actual Spli t Ratio when t he xPON Uses the Multi-level Optical Splitting Mode
ID: SE0000367138 Information Troubleshooting Cases Type : Product Family: Optical Access
Quality Level:
C
Product: MA5680T
Fault Type: Others Keywords: GPON, split ratio Permission 04Common Users Permission Level: Phenomenon De Q: scription: How to calculate the actual split ratio when the xPON uses the multi-level optical splitting mode? Alarm Informatio Null n: Cause Analysi Null s: Handling Proces A: s: When the xPON uses the multi-level optical splitting, the actual split ratio can be calculated as follows: Actual split ratio=multiplication of numbers of the optical splitting of each level For example, in theory, the maximum split ratio of the GPON is 64. In the actual operation, 1:8 optical splitting is used in the first level and 1:16 optical splitting is used in the second level. 8 x 16 = 128 > 64. The actual split ratio exceeds the theoretical value. As a result, services fail to be provided if the split ratio in the service planning is very large.
3.12 Users Connected to the MA5620G Cannot Make Calls Normally After Taking th e Phone off the Hook Because RTP Resources of the Softswitch Are Allocated Insuffic iently
Users Connected to t he MA5620G Cannot Make Calls Normall y After Taking the
Title: Phone off the Hook Because RTP Resources of the Softswitch Are Allocated Insufficiently
ID: SE0000367144 Information Troubleshooting Cases Type : Product Family: Optical Access
Quality Level:
C
Product: MA5680T
Fault Type: Others Confidential Information of Huawei. No Spreading without Permission
51
NGN Cases
Chapter 3 GPON FTTx Cases
Keywords: RTP Permission 04Common Users Permission Level: Phenomenon De The MA5620G is connected to the softswitch of company Z through the H248 protocol scription: and 16 voice users are connected to the MA5620G. In the test, only two calls are put through in each 16 calls and the busy tone is played for other 14 calls. Alarm Informatio Null n: Cause Analysi Null s: Handling Proces 1. It is suspected that the busy tone is played because the network quality is poor. Ping s: the softswitch. No packet loss occurs and the delay is only 2–3 ms. This indicates that the network quality is good. 2. Perform mirroring packet capture and analyze the signaling. When the MA5620G is associated, if the ID of RTP added in the association is larger than 00001, the busy tone is played on the softswitch side. If the RTP ID is 00000 and 00001, calls can be made normally. 3. Check the softswitch. On the softswitch, only two RTP resources are configured for the MA5620G. The RTP adding mechanism in the MA5620G is: The RTP ID starts from 00000 and is added by one when a call is made. When the RTP ID increases to 00015, the RTP ID starts from 00000 again and this process repeats. Therefore, only two calls are put through in each 16 calls and the busy tone is played for other calls. 4. Add the RTP resources to 16 on the softswitch and then conduct tests. Calls can be made normally. Suggestions and RTP resources of the softswitch of company Z are allocated in the static configuration Summary: mode. Therefore, before a device is interconnected to the softswitch, you should apply to the softswitch for sufficient RTP resources according to the model of the device.
3.13 FAQ-How to Confi gure the ACL Rule on the MA5680T So That the Prio rit y of the Outer VLAN Can Be Changed Based on t he Inner VLAN Tag
Title:
FAQ-How to Conf igur e the ACL Rule on the MA5680T So That the Prio rity o f th e Outer VLAN Can Be Changed Based o n th e Inner VLAN Tag
ID: SE0000367166 Information Troubleshooting Cases Type : Product Family: Optical Access
Quality Level:
B
Product: MA5680T
Fault Type: QACL Service Keywords: ACL, QinQ, priority Permission 02Huawei Partners Permission Level: Phenomenon De Q: scription: How to configure the ACL rule on the MA5680T so that the priority of the outer VLAN can be changed based on the inner VALN tag? Alarm Informatio Null n: Cause Analysi Null s: Handling Proces A: s: 52
Confidential Information of Huawei. No Spreading without Permission
MSAN UA5000 Cases
Chapter 3 GPON FTTx Cases
MA5680T(config)#acl 5000 //Create the user-defined acl 5000 MA5680T(config-acl-user-5000)#rule 5 permit 8100 ffff 16 { <2,8>|time-range<2,8>|time-range<5,15> }:0/3/0 Run the following command: traffic-priority inbound user-group 5000 cos 6 port 0/3/0 //According to the rule in acl 5000, change the priority of the outer CoS to 6 and deliver it to port 0/3/0 of the LSW in the incoming direction. Combine the preceding ACL rules. The rule after translation is: If packets sent from port 0/3/0 have two tags and the inner VLAN ID is 10, change the CoS priority of the outer VLAN of the packets to 6. Suggestions and If QinQ streams on the MA5680T need to be filtered or matched, the user-defined ACL Summary: must be used. The standard or extended ACL does not take effect on the QinQ stream.
3.14 All ONTs (HG850s) Connected to a PON Port Get Online and Offl ine Frequently Because One of the ONTs Connect ed to t he PON Port Is Faulty
Title:
All ONTs (HG850s) Con nected to a PON Port Get Onli ne an d Offl in e Frequen tl y Because One of the ONTs Connected to the PON Port Is Faulty
ID: SE0000374105 Information Troubleshooting Cases Type : Product Family: Optical Access
Quality Level:
C
Product: MA5680T
Fault Type: ONT terminal Keywords: ONU exception, ODN, get online and offline frequently Permission 01Huawei Engineers Permission Level: Phenomenon De In an office, all ONUs (HG850s) connected to a PON port of the MA5680T providing the scription: GPON service get online and offline frequently. The c ustomer checks the optical path on site. The optical path is normal. Replace one of the ONUs that get online and offline frequently. The fault persists. The ONU after replacement and other ONUs still get online and offline frequently. Alarm Informatio ! EVENT WARNING 2008-05-21 14:22:49 ALARM NAME :ONU in do wn state alarm n: PARAMETERS :FrameID: 0, SlotID: 3, PortID: 3, ONUID: 2 ! EVENT WARNING 2008-05-21 14:22:49 ALARM NAME :ONU in up state alarm PARAMETERS :FrameID: 0, SlotID: 3, PortID: 3, ONUID: 2
Confidential Information of Huawei. No Spreading without Permission
53
NGN Cases
Chapter 3 GPON FTTx Cases
Cause Analysi ONUs connected to other PON ports of the same GPBC board are normal and the fault s: is not caused by the optical path. Therefore, the possible causes of the fault are as follows: 1. The PON port is faulty. 2. The optical splitter is faulty. 3. The ONU is faulty. Handling Proces 1. Remove optical fibers that connect optical splitters of the first level to all optical s: splitters of the second level and directly connect the ONUs to the optical splitters of the first level. The ONUs go online normally and are stable. 2. Insert optical fibers that connect optical splitters of the first level to optical splitters of the second level. After the optical fiber that connects an optical splitter of the first level to an optical splitter of the second level is inserted, the fault recurs. 3. Check the ONUs connected to the optical splitter of the second level one after another. After the optical fiber that connects the optic al splitter to an ONU is removed, the fault is rectified. Suggestions and No exception alarm is generated on such faulty ONU and the fault persists after an ONU Summary: is replaced. Therefore, the fault can be located only by excluding possible causes one after another.
3.15 The ONT Connected to th e MA5680T Goes Offl ine Frequentl y Due to the Inco rrect Connection of Optical Fibers on the Optical Splitter
Title:
The ONT Connected to the MA5680T Goes Offli ne Frequently Due to th e Incorrect Connection of Optical Fibers on the Optical Splitter
ID: SE0000364557 Information Troubleshooting Cases Quality Level: C Type : Keywords: Optical splitter, incorrect connection, frequently, offline Permission 01Huawei Engineers Permission Level: Phenomenon De The packet loss of the new ONU connected to the MA5680T is severe, and the ONU scription: goes offline frequently. Alarm Informatio ALARM 9398 EVENT MAJOR 0x2e10700e ----- 2008-03-06 10:53:38 n: ALARM NAME : Alarm 2 for MAC layer frame error reach the limit PARAMETERS : FrameID: 0, SlotID: 1, PortID: 3, ONUID: 0 DESCRIPTION : Alarm 2 for MAC layer frame error reach the limit CAUSE : MAC layer frame error reach the limit of 1.953125*10E-6 Cause Analysi The threshold alarm for the error frames is generated because of the poor quality of the s: line or the ONT. Handling Proces 1. Query the alarms. It is found that a lot of alarms that the count of the error frames s: reaches the threshold are generated on the ONT. Run the displ ay port statistics command to query the statistics of the port. It is found that the number of the error packets increases by 200 per second. After the analysis, it is determined that maybe the problem is caused by the overlarge optical attenuation or poor ONT quality; however, the distance bet ween the ONT to the MA5680T is less than 50 meters. Therefore, the line quality should be good. 2. Replace the ONT. It is found that the problem persists. 3. Check the optical path segment by segment. The optical fiber, through primary splitting, is connected to the suspected ONT from the EPON port. Currently, the EPON port is connected to only one ONT. 54
Confidential Information of Huawei. No Spreading without Permission
MSAN UA5000 Cases
Chapter 3 GPON FTTx Cases
Check the optical splitter. It is found that the fiber in the inbound direction and the fiber in the outbound direction are both connected to the ingress of the optical splitter. Connect the fiber in the outbound direction to the egress of the optical splitter. The problem is solved. 4. The optical splitter has two ingresses, an active one and a standby one. The fibers in the inbound and outbound directions must be connected to the corresponding ports. The incorrect connection causes large optical attenuation, thus affecting the service. Suggestions and When the ONT goes offline frequently, query the alarms and the performance statistics Summary: of the port to find the cause. Then, check the optical path segment by segment to locate the fault.
3.16 Users Fail to Log In to the Server from t he N2000 BMS Client Because of the Inco rrect Setting of the Client
Title:
Users Fail t o Log In to th e Server fro m the N2000 BMS Client Because of t he Incorrect Setting of th e Client
ID: SE0000364646 Information Troubleshooting Cases Type : Product Family: Optical Access
Quality Level:
C
Product: MA5680T
Fault Type: Host/Network Management System (independent from service) Keywords: GPON, N2000 BMS Permission 02Huawei Partners Permission Level: Phenomenon De The N2000 BMS client can ping the server, and can automatically update the version scription: from the server, but fails to log in to the server, with the message "Communication fails" displayed. Alarm Informatio When users log in to the server from the client, the system displays the message n: "Communication fails". Cause Analysi 1. The version of the N2000 BMS on the server is not consistent with that on the client. s: 2. The communication between the N2000 BMS server and the client fails. 3. The settings on the N2000 BMS server or client are incorrect. Handling Proces 1. The client can ping the server, and automatically update the version from the server. s: Thus, the problem related to the communication is excluded. 2. Check the versions of the N2000 BMS server and client. It is found that the versions are the same. 3. Check the "server settings" of the client. It is found that the mode is set to common. Check the mode of the server, and it is found that the mode is set to SSL. Modify the mode in the "server settings" on the client to "SSL". Then, users can log in to the server from the client. Suggestions and The authentication mode of the server and the client of the N2000 BMS should be the Summary: same, "common" or "SSL".
Confidential Information of Huawei. No Spreading without Permission
55
NGN Cases
Chapter 3 GPON FTTx Cases
3.17 FAQ-How to Implem ent the VoIP Service of the MA5680T
Title: FAQ-How to Implement t he VoIP Service o f t he MA5680T ID: SE0000363358 Information Troubleshooting Cases Type : Product Family: Optical Access
Quality Level:
C
Product: MA5680T
Fault Type: Others Keywords: VoIP, voice Permission 02Huawei Partners Permission Level: Phenomenon De Q: scription: How to implement the VoIP service of the MA5680T? Alarm Informatio Null n: Cause Analysi Null s: Handling Proces A: s: The two POTS ports on the ONU (GPON terminal) can be adopted to implement the VoIP service. The VoIP service is implemented through the built-in IAD of the ONU. The IAD is an integrated access device specially for the VoIP service. After being transmitted to the IAD, the analog voice signals are sampled and converted into the digital signals through the built-in codec chip. Then, the digital signals are transmitted to the central processing chip for the DSP compression. After the compression, the signals, in the form of the RTP packets, are transmitted to the IP network. The IAD, supporting the MGCP protocol, exchanges signaling with the softswitch and thus implements the VoIP service. The OLT in a GPON network does not process the VoIP service, but provides the transparent transmission channel.
3.18 The FE Port Cannot be Act ivated Aft er the HG810e Connected t o the MA5680T Is Powered Off Because th e ONT Profile Does Not Match the ONU Profi le
Title:
The FE Port Cannot be Acti vated Aft er the HG810e Connect ed to t he MA5680T Is Powered Off Because the ONT Profi le Does Not Match the ONU Profi le
ID: SE0000374101 Information Troubleshooting Cases Type : Product Family: Optical Access
Quality Level:
C
Product: MA5680T
Fault Type: EPON Access Service Keywords: Profile Permission 02Huawei Partners Permission Level: Phenomenon De The HG810e is connected to the MA5680T. After the HG810e is powered off, the scription: network port of the PC fails to be activated. Remove the optical fiber and set the NIC of the PC to the 100 M full-duplex mode. The network port of the PC can be activated.
Alarm Informatio Null n: 56
Confidential Information of Huawei. No Spreading without Permission
MSAN UA5000 Cases
Chapter 3 GPON FTTx Cases
Cause Analysi 1. The capability set profile of the MA5680T or the ONT profile does not match that of the s: HG810e. 2. The port of the HG810e is faulty.
Handling Proces 1. Check the ONT profile configured on the MA5680T. The current ONT profile does not s: match that of the HG810e normally. The matched profile of the HG810e is an ONT profile providing a GE port. The current ONT profile, however, only provid es an FE port. As a result, after the ONU is powered off, the network port of the PC connected to the port of the ONU cannot be activated in the auto-negotiation mode, but activated only after set to the 100 M full-duplex mode forcibly. 2. Run the following command to reconfigure the capability set profile of an ONT connected to the EPON port and bind the profile to the ONT. That is, the profile matching the capability attribute of the ONT can be specified. ont-profile add epon [ profile-id profile-id | profile-name profile-name ] 3. Configure a profile providing a GE port that matches the profile of the HG810e. As a result, the ONU goes online normally. The network port of the PC need not be set forcibly and the ONU can get online again after the ONU is powered off.
Suggestions and Null Summary:
3.19 A Port of the H813e Cannot Forward Packets Normally Because the Nativ e VLAN of the Port Is t he Same as the Multic ast VLAN
Title:
A Por t o f t he H813e Cann ot Forwar d Packets Normall y Because t he Nativ e VLAN of the Port Is th e Same as the Multicast VLAN
ID: SE0000374103 Information Troubleshooting Cases Type : Product Family: Optical Access
Quality Level:
C
Product: MA5680T
Fault Type: EPON Access Service Keywords: MAC, forwarding exception Permission 01Huawei Engineers Permission Level: Phenomenon De In an office, the MC (video phone) is connected to the H813e. The MC cannot obtain the scription: IP address through DHCP and the OLT cannot learn the MAC address of the MC. Use a PC to replace the MC. The fault persists. The STB service of the H813e is normal. The networking is MC-> H813e->optical splitter->MA5606T. Packets sent from the MC do not contain tags. The VLAN 2103 tag, which is also the tag of the multicast service, is added to the packets on the H813e. The tag of the STB service is VLAN 2104.
Alarm Informatio Null n: Cause Analysi The MA5606T cannot learn the MAC address of the MC connected to a port of the s: MA5606T, but the STB service of the H813e connected to the MA5606T is normal. Therefore, the causes of the fault are as follows: 1. The port of the H813e is faulty. 2. The configuration is incorrect.
Confidential Information of Huawei. No Spreading without Permission
57
NGN Cases
Chapter 3 GPON FTTx Cases
Handling Proces Change the port and replace the H813e. The fault, however, persists. Check the data s: configuration. A multicast VLAN is configured on this port. Delete this multicast VLAN and then the fault is rectified.
Suggestions and Consult R&D engineers and then find that this restriction exists on the H813e (this Summary: restriction exists on all ONTs with PMC chips). That is, when the PVID of a port of the H813e is configured to be the same as the multicast VLAN, the port is in the faulty state and cannot forward packets normally. Therefore, in the similar net working, mitigate this problem through configurations.
3.20 The ONT Connected to th e MA5680T Cannot Receive the Broadcast Packet Due to the Fault of the ONT
Title:
The ONT Connected t o t he MA5680T Canno t Receive the B roadcast Packet Due to the Fault o f the ONT
ID: SE0000363353 Information Troubleshooting Cases Type : Product Family: Optical Access
Quality Level:
C
Product: MA5680T
Fault Type: ONT terminal Keywords: Broadcast Permission 02Huawei Partners Permission Level: Phenomenon De Networking: scription: ------(0/19/0)5680T(0/0/0)-----813e-----|---------------SmartBits-----------------------| The SmartBits is used to transmit 100 M broadcast traffic from the upstream port of the MA5680T to the PON port. The FE port of the ONT, however, cannot receive any traffic. Alarm Informatio Null n: Cause Analysi 1. The fault may be caused by the data configuration of the upstream port, but the s: upstream port can forward the unicast packets. Therefore, the fault is not caused by the data configuration. 2. The fault may be caused by the broadcast suppression of port 0/19/0. Run the display traffic-suppress command to query the port, and it is found that although the broadcast suppression is enabled, the maximum bandwidth is limited to 9265 kbit/s. Therefore, the ONT can receive certain traffic. Disable the broadcast suppression. It is found that the ONT cannot receive any traffic, either. The collected data is as follows: MA5680T(config-if-giu-0/19)#display traffic-suppress 0 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 58
Confidential Information of Huawei. No Spreading without Permission
MSAN UA5000 Cases
Chapter 3 GPON FTTx Cases
10 3125 74126 6104 11 6249 148241 12207 12 12499 296483 24414 -----------------------------------------------------------------------------------------------------------------------------------Current traffic suppression index of broadcast : 7 Current traffic suppression index of multicast : 7 Current traffic suppression index of unknown unicast : 7 MA5680T(config-if-giu-0/19)# 3. Replace the ONT with an ONT of the same type. It is found that the new ONT can receive the broadcast traffic. Then, check the versions of the ONTs. Version of the ONT before the replacement: V100R001C02B016 Version of the ONT after the replacement: V100R001C02B020 Later, it is confirmed that in the V100R001C02B016 version, the broadcast traffic is totally suppressed. Handling Proces Update the version of the 813e to V100R001C02B020. It is found that the problem is s: solved. Suggestions and Null Summary:
3.21 All ONTs (HG850s) Connected to a PON Port Get Online and Offl ine Frequently Because One of the ONTs Connect ed to t he PON Port Is Faulty
Title:
All ONTs (HG850s) Con nected to a PON Port Get Onli ne an d Offl in e Frequen tl y Because One of the ONTs Connected to the PON Port Is Faulty
ID: SE0000374105 Information Troubleshooting Cases Type : Product Family: Optical Access
Quality Level:
C
Product: MA5680T
Fault Type: ONT terminal Keywords: ONU exception, ODN, get online and offline frequently Permission 01Huawei Engineers Permission Level: Phenomenon De In an office, all ONUs (HG850s) connected to a PON port of the MA5680T providing the scription: GPON service get online and offline frequently. The c ustomer checks the optical path on site. The optical path is normal. Replace one of the ONUs that get online and offline frequently. The fault persists. The ONU after replacement and other ONUs still get online and offline frequently. Alarm Informatio ! EVENT WARNING 2008-05-21 14:22:49 ALARM NAME :ONU in do wn state alarm n: PARAMETERS :FrameID: 0, SlotID: 3, PortID: 3, ONUID: 2 ! EVENT WARNING 2008-05-21 14:22:49 ALARM NAME :ONU in up state alarm PARAMETERS :FrameID: 0, SlotID: 3, PortID: 3, ONUID: 2 Cause Analysi ONUs connected to other PON ports of the same GPBC board are normal and the fault s: is not caused by the optical path. Therefore, the possible causes of the fault are as follows: 1. The PON port is faulty. 2. The optical splitter is faulty. 3. The ONU is faulty. Handling Proces 1. Remove optical fibers that connect optical splitters of the first level to all optical s: splitters of the second level and directly connect the ONUs to the optical splitters of the first level. The ONUs go online normally and are stable. Confidential Information of Huawei. No Spreading without Permission
59
NGN Cases
Chapter 3 GPON FTTx Cases 2. Insert optical fibers that connect optical splitters of the first level to optical splitters of the second level. After the optical fiber that connects an optical splitter of the first level to an optical splitter of the second level is inserted, the fault recurs. 3. Check the ONUs connected to the optical splitter of the second level one after another. After the optical fiber that connects the optic al splitter to an ONU is removed, the fault is rectified.
Suggestions and No exception alarm is generated on such faulty ONU and the fault persists after an ONU Summary: is replaced. Therefore, the fault can be located only by excluding possible causes one after another.
3.22 FAQ-Can the ONT Register wi th th e OLT if th e ONT Connected to th e MA5680T Is Over 20 km Away fro m th e OLT
Title:
FAQ-Can the ONT Register with the OLT if the ONT Connect ed to the MA5680T Is Over 20 km Away from the OLT
ID: SE0000374358 Information Troubleshooting Cases Type : Product Family: Optical Access
Quality Level:
C
Product: MA5680T
Fault Type: EPON Access Service Keywords: Max distance Permission 01Huawei Engineers Permission Level: Phenomenon De Q: scription: Can the ONT register with the OLT if the ONT connected to the MA5680T is over 20 km away from the OLT?
Alarm Informatio Null n: Cause Analysi Null s: Handling Proces A: s: If the optical power is within the allowed range, the ONT can register with the OLT though the ONT is over 20 km away from the OLT. The maximum distance of the MA5680T, however, is 20 km by default, shown as follows: (config-if-epon-0/7)#display port info 2 -----------------------------------------F/S/P 0/7/2 Max distance(km) 20 Left bandwidth(kb) 989760 Autofind Enable Laser switch On Loopback status Disable Tag attribute tag-based-ont -----------------------------------------In the preceding information, Max distance indicates that if the ONT is over 20 km away from the OLT, the ONT cannot be discovered automatically t hough the optical power is within the allowed range. Therefore, run the following commands to modif y this parameter so that the ONT that is over 20 km away from the OLT can register with the OLT: (config-if-epon-0/7)#port 2 range 60
Confidential Information of Huawei. No Spreading without Permission
MSAN UA5000 Cases
Chapter 4 UA5000 Broadband Service
{ max-distance
Suggestions and Null Summary: Attachments:
Chapter 4
4.1
UA5000 Broadband Service
standard vlan cause the bad packet for multicast traffic
Title:
standard vlan cause the bad packet for multicast traffic
ID:
SE0000356941
Update time:
2008-11-19 10:35:11
Author:
Affandi Abdul Rahim
Product Family:
Integrated Acsess
Product:
Fault Type:
UA5000 Broadband Service
Keywords:
multicast bad packet on cascadded IPMD frame
Digest:
Vlan configuration
UA5000
Phenomenon Description:
The IGMP mode are in proxy. When tested directly from metro-ethernet, the multicast packet are okay but when cascade to other IPMD frame the board received bad packet from host IPMD fra me. We assumed that all physical are okay.
Alarm Information:
Null.
Cause Analysis:
The VLAN type in IPMD frame is standard. Usually all broadband services will use smart vlan. When execute "display multicast flow-statistic index 0" on the cascaded IPMD frame, the bandwi dth sometimes are not the same as the host IPMD frame.
Handling Process:
Change the host IPMD frame multicast vlan from standard to smart vlan. Now the multicast servi ce are the same between IPMD cascade frame and host frame.
Suggestions and summary:
Null.
Confidential Information of Huawei. No Spreading without Permission
61
NGN Cases
4.2
Chapter 4 UA5000 Broadband Service
ADSL Subscr ibers cannot be authentic ated due to high temperature
Title:
ADSL Subscribers cannot be authenticated due to high temperature
ID:
SE0000343846
Update time:
2008-11-25 14:04:19
Author:
00701219Khurram Abbasi
Product Family:
Integrated Acsess
Fault Type:
UA5000 Broadband Service
Keywords:
IPMA cannot ping BRAS due to EFS
Digest:
IPMA cannot ping BRAS due to EFS
Product:
UA5000
Phenomenon Description:
IPMA board can not connect to BRAS. Physical link connectivity is OK and port status is online. BRAS can not be accessed and all subscriber services are broken Service connectivity is as follows UA5000 (IPMA) --> EFS board, FE port (Metro1000 SDH) --> EFS board (Metro3000) --> EGS 2 board, GE port (Metro5000) --> BRAS (GE port)
Alarm Information:
SDH Alarms, ----------FAN Block Alarm at Merto1000 SDH Board Bad alarm at EFS card. BMS Alarm, --------------IPMA card is offline IPMA alarm, ---------------IPMA cannot ping to BRAS.
Cause Analysis:
Excess dust blockage caused SDH internal cooling fan faulty which was not timely reported and r esolved which resilts EFS card software hanged due to very high temperature.
Handling Process:
- Check the BRAS configuration by remote login and no issue found. - Check the cable connection between UA5000 and Metro1000V3 SDH. Found OK. - Check the configuration of UA5000. Found OK. - Check the port status of UA5000. Observed OK. - Ask Transmission engineer to check the transmission configuration. Transmission engineer repo rted that all service configuration is ok. - Physically checked the SDH and felt very high temperature of SDH and its cards panel. - Ask transmission engineer to check card health. High temperature alarm found at EFS card and SDH. - removed the SDH on transmission engineer instructions and removed the EFS card. - EFS card was extremly hot. We keep it under room temperature for half an hour and let its temp erature normalized. - Also removed the fans plate of SDH and cleaned. Reinstall the fan flate and found that 2 out of t hree fans started working. - Installed the EFS card when it cooled to normal temperature and ask Transmission engineer to c heck EFS card. He reported that card is normal. - Check the IPMA card and ping the BRAS, BRAS is successfully connected. - Check the subscribers state, subscribers are using ADSL service smoothly.
Suggestions and summary:
- SDH FAN alarms should not be neglected. It can be service effecting, if ignored. Also, it can da mage the cards as well. - Temperature alarms of equipments should also not ignored.
62
Confidential Information of Huawei. No Spreading without Permission
MSAN UA5000 Cases
4.3
Chapter 4 UA5000 Broadband Service
A UA5000 UA5000 Fails to Copy All Mult Mult icast Streams to All STBs STBs Because the Traffic Traffic Exceeds the Traffic Restriction of the UA5000
Title:
A UA5000 Fails to Copy All Multicast Streams to All STBs Because the Traffic Exceeds the Traffic Restriction of the UA5000
ID:
SE0000367345
Update time:
2008-12-31 18:41:07
Author:
k56606
Product Family:
Integrated Acsess
Fault Type:
UA5000 Broadband Service
Keywords:
Multicast, traffic restriction
Digest:
Multicast, traffic restriction
Product:
UA5000
Phenomenon Description:
two different problems were observed on SIP trunks 1.Call connects and the peer switch sends us SIP acknowedge request, but our switch do not accept it and the call drops after about ~33 seconds. 2.we send INVITE SDP and offers the codecs in responce the peer switch sends OK SDP (g711A)but our switch does not sends them ACK rather it sends 6 more INVITE messages & after 7 conteneous INVITE the session closed and call do not connected.
Alarm Information:
Null.
Cause Analysis:
Multicast streams are copied on logics. The total traffic of logics and chip 251 is restricted to 1 Gbit/s and 512 (16 x 32) subscribers can be connected to one chip 251.If all 461 subscribers are connected to one chip 251, the traffic is 2849.4 (5.4 x 461) Mbit/s, which is larger than the traffic restriction. As a result, packet loss and erratic display occur.
Handling Process:
If the program stream is 5.4 Mbit/s, a maximum of 185 subscribers connected to one chip 251 can watch the program normally. The system supports a maximum of 370 (185 x 2) subscribers who can watch the program normally. The maximum number of subscribers is (1000/bandwidth occupied by each program stream) x 2. Reduce the bandwidth of the program stream to 2 Mbit/s (1000/2 = 500 subscribers) and conduct a test. As a result, the multicast stream can be copied to all STBs.
Suggestions and summary:
The traffic of the UA5000 is restricted. In services with large traffic such as the open multicast, services may be affected when the traffic exceeds the total traffic restriction. This performance of the device helps test and troubleshooting in daily maintenance.
4.4
The Broadband Service of the UA500 UA5000 0 Fails because the VE on the BAS Is Not Configured with the MAC Address Address
Title:
The Broadband Service of the UA5000 Fails because the VE on the BAS Is Not Configured with the MAC Address
ID:
SE0000374570
Update time:
2009-02-20 09:25:06
Author:
w91527
Product Family:
Integrated Acsess
Product:
UA5000
Confidential Information of Huawei. Huawei. No Spreading without Permission
63
NGN Cases
Chapter 4 UA5000 Broadband Service
Fault Type:
UA5000 Broadband Service
Keywords:
UA5000, VE, MAC, service failure
Digest:
UA5000, VE, MAC, service failure
Phenomenon Description:
Networking: Networking: MA5200G(ATM)---MA510 MA5200G(ATM)---MA5100(LAND)---U 0(LAND)---UA5000 A5000 MA5200G version: 5200-2332 MA5100 version: V100R005B10D058 UA5000 version: UA5000IPMB V100R013C03B031 In the preceding networking mode, the inband NMS and services fail in the UA5000 office, while the inband NMS and services are normal in the MA5100 office.
Alarm Information:
Null.
Cause Analysis:
Possible causes are as follows: 1. The data configuration of the UA5000 is incorrect. 2. The data configuration of the MA5100 is incorrect. 3. The data configuration of the MA5200G is incorrect.
Handling Process:
1. Check the data configuration of the UA5000 and MA5100. The data configuration is correct. Check the data configuration of the MA5200G. The data is the same as that of terminating MA5100 and UA5000 services. 2. Perform port mirroring on the LAND board of the MA5100, ping the IP address of the MA5200G from the UA5000, ping the IP address of the UA5000 from the MA5200G, and capture packets during ping operations. 3. Analyze the capture packets and it is found that the original MAC address in the ICMP packets sent by the MA5200G is 00-00-00-00-00-00. The UA5000 regards the MAC address as being illegal, discards the packet, and does not send a response to the MA5200G. Thus, the service fails. 4. Confirm with MA5200G technical support engineers and know that the MAC address of all 0s is the MAC address of the VE interface of the MA5200G. Log in to the MA5200G and view related configuration of the VE interface. You can find that the VE interface is not configured with the MAC address. Set an MAC address that does not consist of all 0s for the VE interface of the MA5200G, and then ping the IP addresses of the MA5200G and UA5000. The ping operations succeed. 5. In the uplink direction, the UA5000 sends the message to the MA5200G through the MA5100, the inband NMS on the MA5200G adopts IPoEoA service encapsulation mode. Services are transmitted over PPPoEoA, and the VE interface must be bound to the MA5200G. The difference between the the UA5000 and and the MA5100 MA5100 is that the UA5000 UA5000 adds adds MAC address address anti-spoofing. anti-spoofing. Therefore, the services of the MA5100 are normal while those of the UA5000 fail.
Suggestions and summary:
When services fail, but data configuration is correct, capturing packets for analysis is the most effective way to locate the fault.
4.5
Error 678 678 Is Promp Promp ted Frequently Frequently During the Dialup of the UA500 UA5000 0 Broadband Subscriber because the Wire Sequence of the Uplink Straight Through Cable Is Incorrect
Title:
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
ID:
SE0000374596
Update time:
2009-02-20 14:01:29
Author:
z95429
Product Family: 64
Integrated Acsess
Product:
UA5000
Confidential Information of Huawei. Huawei. No Spreading without Permission
MSAN UA5000 Cases Fault Type:
Chapter 4 UA5000 Broadband Service
UA5000 Broadband Service
Keywords:
error 678
Digest:
error 678
Phenomenon Description:
The UA5000 version is UA5000IPMBV100R013C03B032SP02, the UA5000 is connected upstream through the FE port, and the path is IPMB - SDH - OSN3500 - 6650 - MA5200G. This office is already in service for half a year but the problem that error 678 is prompted during the dialup of all subscribers occurs at the interval of about one month. Reset the IPMB control board but the fault persists. persists. After the entire shelf is powered powered off, off, the dialup is normal sometimes. sometimes.
Alarm Information:
Error 678 is prompted during the dialup of all broadband subscribers.
Cause Analysis:
1. Because the dialup is normal after the entire shelf is powered off and the check at the moment shows that the IPMB uplink port is normal, the IPMB control board or O2FN daughter board may be faulty. 2. Because the upper-layer device needs to perform the flexible QinQ processing, the data of the upper-layer device may have problems.
Handling Process:
1. Because the dialup is normal after the entire shelf is powered off and the check at the moment shows that the IPMB uplink port is normal, the IPMB control board or O2FN daughter board may be faulty. Replace IPMB and the O2FN daughter board, and the dialup is normal for several minutes. After IPMB is powered off again, however, error 678 is prompted again during the dialup. This indicates that the UA5000 is normal. 2. The data of the upper-layer device may have problems. Use a switch to perform the test on site and the dialup is normal each time. This indicates that the upper layer is normal. 3. Check the networking for IPMB and the switch and it is found that only one cable is replaced. Then, check the uplink network cable of IPMB and it is found that the wire sequence of the network cable is incorrect. Replace the cable with another straight through cable and then test the service, and the service is normal. Then, power off IPMB, test the service, and the service is normal.
Suggestions and summary:
The wire sequence at both ends of the straight through cable is "white-orange-orange-white-green-green-white-blue-blue-white-blown-blown", which does not comply with the standard of the straight through cable. Because in this kind of problem, the number of upper-layer devices is large, the problem should be located one one segment segment by one segment. segment.
4.6
Downlo ad speed is too slow because of the wro ng cable cable conn ect between UA5000 UA5000 and S6500
Title:
Download speed is too slow because of the wrong cable connect between UA5000 and S6500
ID:
SE0000380844
Update time:
2009-03-26 13:45:52
Author:
Ma Ming
Product Family:
Integrated Acsess
Product:
Fault Type:
UA5000 Broadband Service
Keywords:
UA5000 S6500 packet loss download speed
Digest:
UA5000 S6500 packet loss download speed
Phenomenon
Version: UA5000IPMB V100R013C03B031SP06
UA5000
Confidential Information of Huawei. Huawei. No Spreading without Permission
65
NGN Cases
Chapter 4 UA5000 Broadband Service
Description:
Networking: UA5000-->S6500-->S8512-->MA5200G Phenomena: When tried to download some file from internet then got maximum near 155 KB/s and minimum 0KB/s ~0.3KB/s speed. When ping public IP from PC after conneting PPPoE then it has taken so many packet loss. When ping from MA5200G to S6500, there is no packet loss. but when ping from UA5000 to M A5200G or S6500, there is getting so many packet loss. Please check the attached.
Alarm Information:
NULL
Cause Analysis:
Problem analysis: 1. from the phenomena, there's problem between UA5000 and S6500. 2. negotiation mode is not matched. 3. traffic table has traffic suppress. 4. Vlan problem between UA5000 and S6500. 5. loop problem. 6. Virus/attack from S6500 or subscribers. 7. hardware/software problem.
Handling Process:
1. check the negotiation mode, they are both 100M/full, try to modify them to auto-negotiated, th e packet loss is sovled for some time, but happen again. 2. display traffic table and traffic suppress, it is all normal, try to modify to some value, no results . 3. check the vlan configuration in S6500 and UA5000 IPMB, try to forbid Vlan 1 transfer, no res ults. the rest configuration is OK. 4. try to check loop, make packet capture, though it is some broadcast packet, but it is normal. 5. check it out, no virus/attack happen. 6. upgrade the patch from IPMB V100R013C03B031SP04 to SP06, thought it would be the kno wn storm issue, no results. 7. by chance, we change the network cable between S6500 and UA5000 IPMB to cross, the origi nal is straight, the packet loss is solved, and down load speed is normal, we observed for some ti me, no happen again. problem is all solved.
Suggestions and summary:
Straight network cable is not OK with UA5000 IPMB and S6500 connected.
4.7
(IPTV servic e) VOD is worki ng norm ally but Live channel servi ce is not available
Title:
(IPTV service) VOD is working normally but Live channel service is not available
ID:
SE0000383336
Update time:
2009-04-17 15:29:51
Author:
Altaf Ahmed
Product Family:
Integrated Acsess
Product:
Fault Type:
UA5000 Broadband Service
Keywords:
Live channel not working in IPTV service
Digest:
Live channel not working in IPTV service
UA5000
Phenomenon Description:
Live channels are not available when VOD IS working normal.
Alarm Information:
No alarm found.
66
Confidential Information of Huawei. No Spreading without Permission
MSAN UA5000 Cases
Chapter 4 UA5000 Broadband Service
Cause Analysis:
VOD vlan was not configuered at 10G transmission equipment, becuase VOD vlan is bind with S TB, and for IPTV service we need to dial from STB for any user so if VOD vlan for said ONU w as not created at 10G transmission equipment which is connected with uplink (BRAS).
Handling Process:
I have checked all the configuration form ONU to 2.5G each and every thing was configuered ac cording to plan and there were no any alarm found in between, Finllay 10G service was remainin g at our part to check when I checked the serivce for said ONU at 10G, I found VOD vlan for sai d ONU was not created. Than I creat VOD vlan and checked service which was running normally and issue is resolved.
Suggestions and summary:
No
4.8
Packet loss to UA5000. When occ urri ng, the IPMB reports CPU occ upancy at 73
Title:
Packet loss to UA5000. When occurring, the IPMB reports CPU occupancy at 73
ID:
SE0000383242
Update time:
2009-04-17 15:29:58
Author:
Chee Kong Lau
Product Family:
Integrated Acsess
Product:
Fault Type:
UA5000 Broadband Service
Keywords:
UA5000 IPMB packet loss high cpu occupancy
Digest:
UA5000 IPMB packet loss high cpu occupancy
UA5000
Phenomenon Description:
Customer experienced severe packet loss to a UA5000 IPMB. A switch-over to the standby IPM B was performed, however the issue still existed. When looking at the CPU on the active IPMB, the CPU utilization got quite high – up to 70+%. It normally would sit at 25%. When they ping th e UA5000 from the local CX200, they got packet loss, also when they connected to the MSAN fr om their office, their sessions often stall. Their customers were saying they were getting dropout s too.
Alarm Information:
When occurring, the IPMB reports CPU at 73% ALARM 41340 RECOVERY MAJOR 0x0e22 0000 PROCESS ERROR 2008-08-25 12:05:25 ALARM NAME : CPU occupancy recovery alarm PARAMETERS : The current CPU occupancy is: 73% DESCRIPTION : CPU occupancy returns to normal value CAUSE : CPU occupancy returns to normal value ADVICE : No need to proceed"
Cause Analysis:
1. Telnet to affected UA5000. The cpu occupancy in slot 0/3 was sitting at 63% at one instance. Ping the vlanif IP from NMS has some packet loss. Telnet session got interrupted and need to rest art. The packet loss issue is intermittent. The disconnection experienced was due to the packet loss – there maybe a period of up to 1 minute where the UA5000 will not reply to any pings. 2. There were some transmitted multicast frames and oversized frames on the uplink GE port 0/3 /0 and the frames seem to be rather high. 3. There is also a duplicated mac-address accosiated with slot 3 and slot 6. The duplicated mac-a ddress is their BRAS mac-address. 4. If the BRAS mac-address has been learnt by the CPE port, this phenomena is not normal. It co uld cause mac-addresses "drifting" and create network instability. There are generally two conditions causing BRAS mac-address learnt by user CPE port: (1) Us er attack. User CPE attempts to send “attacking” packets with the upper-layer BRAS, (2) There e xists a “ring” or “loop” the customer network.
Handling
1. Modified the traffic-suppress mode for multicast and broadcast traffic on IPMB port 0/3/0 fro
Confidential Information of Huawei. No Spreading without Permission
67
NGN Cases Process:
Chapter 4 UA5000 Broadband Service m 7 to 4. UA5000(config-if-ipm-0/3)#traffic-suppress 0 multicast value 4 UA5000(config-if-ipm-0/3)#display traffic-suppress all Monitored the IPMB GE uplink port 0/3/0 for any traffic surge. UA5000(config-if-ipm-0/3)#display port traffic 0 --> When cpu 0/3 is normal (about 25%) and when cpu is high (>75%) 2. Configured MAC filtering. UA5000(config)#security mac-filter
Suggestions and summary:
4.9
Always apply mac filtering to all important upper-layer devices, such as BRAS, soft-switch, FTP/ Multicast servers, NMS server etc.
All PPPoE subscr ibers in two sites unable to connect to internet due to the uplink GE port lost the BRAS mac-address
Title:
All PPPoE subscribers in two sites unable to connect to internet due to the uplink GE port lost the BRAS mac-address
ID:
SE0000387974
Update time:
2009-04-30 10:03:59
Author:
58381zhoujun
Product Family: Fault Type:
Integrated Acsess
Product:
UA5000
UA5000 Broadband Service
Keywords: Digest: Phenomenon Description:
There were two sites lost the BRAS mac-addresses suddently. All subscribers in those two sites unable to connect to internet. After some time, all of the BRAS mac-addresses came back automatically
Alarm Information:
68
BRAS MAC ADDRESSES: 00e0-fcb7-396a 00e0-fcb7-406a 00e0-fcb7-416a 00e0-fcb7-426a 00e0-fcb7-3962 00e0-fcb7-4062 00e0-fcb7-3162 00e0-fcb7-4262 00e0-fcd5-3238 00e0-fcd5-3338 00e0-fcd5-3438 MAC ADDRESSES ON UA5000 UP LINK GE PORT: DAS_IPMB(config)#display mac-address ethernet 0/2/0 --------------------------------------------------------------------------Type MAC MAC Type F/S /P VPI VCI FLOWTYPE FLOWPARA VLANID --------------------------------------------------------------------------eth 0017-9594-4b81 dynamic 0/2 /0 - - 1 eth 000a-424b-2c08 dynamic 0/2 /0 - - 227
Confidential Information of Huawei. No Spreading without Permission
MSAN UA5000 Cases
Chapter 4 UA5000 Broadband Service
eth 0012-01c3-2a00 dynamic 0/2 /0 - - 227 eth 0017-9594-4b81 dynamic 0/2 /0 - - 660 eth 0018-7360-7c04 dynamic 0/2 /0 - - 860 eth 0018-7360-7c04 dynamic 0/2 /0 - - 660 ---------------------------------------------------------------------------
Cause Analysis:
1- Check the mac-address table on UA5000 ethernet port, there were no BRAS mac-address in th e PPP VLAN 362 and 985 2- Check the mac-address table on lan switch, there were no BRAS mac-address in the PPP VLA N 362 and 985 3- Check the log on the BRAS, PADI from VLAN 362 and 985 had been received, and PADO ha d been sent from the BRAS Obviously the PADO didn't hit the lan switch, because the source mac-address of PADO is the B RAS mac-address, if the PADO hit the lan switch, absolutely the lan switch can learn the BRAS mac-address Data section checked the IP/MPLS network and the BRAS mac-addresses came back.
Handling Process:
Check the IP/MPLS network to find out where the PADO lost
Suggestions and summary:
no
4.10 Improper Configuration of th e Switc h Causes Erratic Display to Two Communicating Video Terminals of the UA5000 Title:
Improper Configuration of the Switch Causes Erratic Display to Two Communicating Video Terminals of the UA5000
ID:
SE0000390223
Update time:
2009-05-11 10:42:29
Author:
t60027289
Product Family:
Integrated Acsess
Fault Type:
UA5000 Broadband Service
Keywords:
AMPB, video phone, erratic display
Digest:
AMPB, video phone, erratic display
Product:
UA5000
Phenomenon Description:
The host is IPMA. For details on the networking, see the attachment. Two video terminals, phone 1 and phone 2, are connected to two ADSL terminals respectively, which are connected to the upstream NE20 router through the APMB board. The services of the router go upstream to the IP network, to which video terminal phone 3 is connected directly. Phone 1 and phone 3 can communicate with each other successfully and the video display is smooth. Phone 2 and phone 3 can also communicate with each other successfully. The communication between phone 1 and phone 2, however, is abnormal. The screen usually freezes and erratic display occurs.
Alarm Information:
Error 678 is prompted during the dialup of all broadband subscribers.
Cause Analysis:
The possible causes may be: 1. The communication between the users of the same board is abnormal. 2. The configuration of IPMA is improper, which causes abnormal communication between the two users of IPMA. 3. The upstream ports of the users are not consistent. 4. The forwarding of the upper layer NE20 router is abnormal.
Confidential Information of Huawei. No Spreading without Permission
69
NGN Cases
Chapter 4 UA5000 Broadband Service
Handling Process:
1. Configure phone 1 and phone 2 on different ADSL service boards respectively and perform tests. The fault persists. 2. Check the upstream port configuration. It is confirmed that the bandwidth of the upstream port is sufficient. 3. Perform tests in the lab. The two IPMA users can communicate with each other normally. The fault in the field cannot be simulated in the lab. 4. Capture packets on the upstream port of IPMA for the normal communication and for the abnormal communication. It is found that the inbound and outbound packets of IPMA are normal in the case of normal communication. In the case of abnormal communication, however, the inbound packets of IPMA are intermittent, which indicates that the forwarding of the NE20 is abnormal. 5. Upon confirmation with the R&D department, it is found that only one interface is configured on the NE20 for connecting to IPMA. Under such a configuration, the forwarding efficiency is abnormal. Different interfaces should be configured for different VLANs for processing different traffic streams. 6. Modify the configuration on both the NE20 and IPMA and then perform tests. The problem is solved.
Suggestions and summary:
Certain problems that possibly seem to be caused by the UA5000 are actually not caused by the UA5000. In the case of such problems, the problem should be located by capturing packets on the upstream port or by performing certain tests. In this way, it can be determined more quickly whether the problem is caused by the UA5000 or by other devices.
4.11 The IPMB Fails to Commun icate with t he Upstr eam EP1A Through the Backpl ane Interface Because the Subboard of the IPMB Is Incorrect Title:
The IPMB Fails to Communicate with the Upstream EP1A Through the Backplane Interface Because the Subboard of the IPMB Is Incorrect
ID:
SE0000392287
Update time:
2009-05-27 16:50:01
Author:
q92670
Product Family:
Integrated Acsess
Fault Type:
UA5000 Broadband Service
Keywords:
EP1A, database, configuration file
Digest:
EP1A, database, configuration file
Product:
UA5000
Phenomenon Description:
The IPMB board communicates with the upstream MA5680T through the EP1A but the upstream port on the IPMB is always offline.
Alarm Information:
NO
Cause Analysis:
The IPMB upstream port can automatically communicate with the EP1A only when the port is an optical port or when no subboard is configured.
Handling Process:
1. Consult the configuration guide. The upstream communication of the IPMB through the EP1A is self-negotiated. No manual configuration is required. 2. Connect an Ethernet cable directly from the IPMB to the Ethernet port of the EP1A. Both the EP1A and IPMB ports are normal. 3. A backplane interface fault is suspected. But the same fault occurs to several UA5000 systems in the field. 4. Consult related engineers. It is found that if an electrical subboard is configured on the IPMB, the upstream communication goes only through an Ethernet port if in the default mode. The upstream services cannot go through the backplane interface.
70
Confidential Information of Huawei. No Spreading without Permission
MSAN UA5000 Cases
Chapter 4 UA5000 Broadband Service
5. Remove the subboard of the IPMB. Run the command ERASE FALSH DATA to empty the database. The upstream communication is normal after the board is registered.
Suggestions and summary:
NO
4.12 The Ethernet Port Fails t o Be Activ ated Because the Upstream Port Mode of th e IPMD Board Is Not Modified Title:
The Ethernet Port Fails to Be Activated Because the Upstream Port Mode of the IPMD Board Is Not Modified
ID:
SE0000392270
Update time:
2009-05-27 16:50:22
Author:
d92946
Product Family:
Integrated Acsess
Product:
Fault Type:
UA5000 Broadband Service
Keywords:
IPMD, electrical port, activate, Ethernet port
Digest:
IPMD, electrical port, activate, Ethernet port
UA5000
Phenomenon Description:
Networking: IPMD—Ethernet switch. IPMD version: V100R017C02B107. Fault description: A newly deployed UA5000 connects a switch directly through the ETH0 port on the IPMD board. After the port is connected, the port fails to be activated.
Alarm Information:
Error 678 is prompted during the dialup of all broadband subscribers.
Cause Analysis:
1. The Ethernet cable is damaged. 2. The peer Ethernet port is faulty. 3. The IPMD port configuration is incorrect or the IPMD board is faulty.
Handling Process:
1. Replace the straight-through Ethernet cable with a crossover cable. The port is still not activated. 2. Connect the Ethernet cable connected to the IPMD board directly to a PC. The port is activated. This indicates the peer end is normal. Connect the PC with the IPMD directly, the port is not activated. This indicates that the problem lies in the IPMD board. Because the IPMD board supports both electrical and optical upstream ports, a port configuration error is suspected. In the IPM mode, run the command display port state 0 to check the state of port 0: huawei(config-if-ipm-0/2)#display port state 0 ----------------------------------------------------------------------------Port Port Type
Native MDI
VLAN
Speed
Duplex
(Mbps) Control
State
Flow-
Active
Link
-----------------------------------------------------------------------------
Confidential Information of Huawei. No Spreading without Permission
71
NGN Cases
Chapter 5 UA5000 Narrow-band Service 0 GE-Optic
3
-
1000
full off
active
offline
Port 0 is incorrectly configured as an optical port. Run the command mode 0 GE-Electrical to modify the mode of port 0 to GE electrical. Test the port again. The port is still not activated. 4. Consult the switch side. The peer end is a 100M electrical port. In the IPM mode, run the following command: huawei(config-if-ipm-0/2)#speed { portid<0,15> }:0 { 10
By default, the upstream port of the IPMD board is a GE optical port. In practice, if a 100M optical port or electrical port is used for upstream communication, the port mode of the IPMD board must be modified.
Chapter 5
5.1
UA5000 Narrow-band Service
Retrans missi on of H.248 Packets Fails in the UA5000R17C02B107 Becaus e the Interface Attribut e Is Incorrect Title: ID: Update Time: Views: Author:
Product Family:
Retransmission of H.248 Packets Fails in the UA5000R17C02B107 Because the Interface Attribute Is Incorrect
SE0000392262 2009-05-27 16:51:14 2 q92670 Integrated Access
Fault Type:
Narrow-band Voice Service
Keywords:
H.248
Permission Level: Phenomenon De scription:
04Common Users Permission
Alarm Informati on: Cause Analysi
Null
72
Product:
UA5000
In a UA5000R17C02B107 site, captured packets show that the AG does not receive reply messages from the softswitch when packet loss occurs in the network. As a result, the AG does not retransmit the lost packets.
1. The transaction reliability parameter of the H.248 stack is set incorrectly.
Confidential Information of Huawei. No Spreading without Permission
MSAN UA5000 Cases s:
Chapter 5 UA5000 Narrow-band Service
2. The interface attribute parameter is incorrect.
Handling Proce ss:
1. Run the following command to check the transaction reliability parameters of the H.248 stack: huawei(config-if-h248-0)#h248stack tr The parameters are set correctly for H.248 retransmission. 2. Run the following command to check interface attributes: huawei(config-if-h248-0)#if-h248 attribute transfer A difference exists in this UA5000 version from earlier versions. In addition to TCP and UDP, the parameter alf/udp is added in this version. In this version, to enable H.248 retransmission, the alf/udp attribute must be selected, while in other versions, the conventional configuration is UDP where the retransmission mechanism is also effective. 3. Modify the interface attribute to alf/udp and reset the interface. The retransmission failure is rectified.
Suggestions and Null Summary:
5.2
The MG Interface Fails to Be Established Because of Incorrect H.248 Negotiation Version Title: ID:
Update Time: Views: Author: Product Family:
The MG Interface Fails to Be Established Because of Incorrect H.248 Negotiation Version
SE0000392209 2009-05-27 16:51:47 6 t60027289 Integrated Access
Fault Type:
Narrow-band Voice Service
Keywords:
Version, negotiation, establish
Permission Level: Phenomenon De scription:
04Common Users Permission
Alarm Informati on: Cause Analysi s:
Null
Handling Proce ss:
Product:
UA5000
A newly deployed UA5000 V100R013C05B051 attempts to communicate with a Huawei softswitch through the MG interface. The MG interface fails to be established but is always under negotiation.
1. Data configuration is incorrect. 2. Ping packets from the UA5000 cannot reach the softswitch. 3. The protocol version for negotiation with the softswitch is incorrect. 4. The UA5000 version is incorrect. 1. Check data configuration on the AG side. The configuration is correct. Check the MG interface status as follows: UA5000(config)#display if-h248 { all
Confidential Information of Huawei. No Spreading without Permission
73
NGN Cases
Chapter 5 UA5000 Narrow-band Service ---------------------------------------------------------------------------2. Send ping packets from the UA5000 to the softswitch. The ping operation is successful. UA5000(config)#ping 10.43.129.51 { -x
Suggestions and Summary:
5.3
An H.248 related problem can be handled by starting with signaling analysis. It is necessary to have certain knowledge of the H.248 protocol.
Servi ce Boards in the Enti re Slave Shelf of the UA5000 Fail to Regist er Because One DSL Board in th e Shelf Is Fault y Title: ID:
Update Time: Views: Author: Product Family:
SE0000392204 2009-05-27 16:52:59 7 l91530 Integrated Access
Fault Type:
Narrow-band Voice Service
Keywords:
UA5000, slave shelf, DSL, HWTB
Permission Level: Phenomenon De scription:
74
Service Boards in the Entire Slave Shelf of the UA5000 Fail to Register Because One DSL Board in the Shelf Is Faulty
Product:
UA5000
04Common Users Permission 1. Networking: UA5000—NGN bearer—SoftX3000 2. UA5000 version: PVMV100R011B02D087
Confidential Information of Huawei. No Spreading without Permission
MSAN UA5000 Cases
Chapter 5 UA5000 Narrow-band Service
3. The control board is PVMB. Version information is as follows: --------------------------------------Pcb Version: H601PVMB VER.C Base Bios Version: 336 Extend Bios Version: 335 Software Version: PVMV100R011 CPLD Version: 198 Logic Version: 304 NOD Version: 10a Encrypt Nios Version: 101 --------------------------------------SubBoard[0] : Miro Version: Exp_Huawei_16880_22161_1 Rev E - HP --------------------------------------SubBoard[1] : 4. ASL and DSL boards are installed in the slave shelf. All boards in the shelf fail to register normally. Alarm Informati on:
Cause Analysi s: Handling Proce ss:
1. Run the command display board 1. The system prompts all boards in the slave shelf are faulty. 2. On the board panel, all indicators of one DSL board are on. 3. Check alarm records. There are board error alarms. The earliest board alarm is a DSL board alarm.
1. The HWTB board or HW lines of the slave shelf is faulty. 2. The faulty DSL leads to the failure of other boards. 1. Replace the HWTB on the backplane of the slave shelf. The fault persists. Boards can be added in or deleted from the slave shelf before and after the replacement. The HWTB board and HW lines are normal. 2. Remove the faulty DSL board and check status of boards in the slave shelf. All the boards are Normal. Services are recovered.
Suggestions and Null Summary:
5.4
Servi ce Boards in the Enti re Slave Shelf of the UA5000 Fail to Regist er Because One DSL Board in th e Shelf Is Fault y Title: ID:
Update Time: Views: Author: Product Family:
Service Boards in the Entire Slave Shelf of the UA5000 Fail to Register Because One DSL Board in the Shelf Is Faulty
SE0000392204 2009-05-27 16:52:59 7 l91530 Integrated Access
Fault Type:
Narrow-band Voice Service
Keywords:
UA5000, slave shelf, DSL, HWTB
Permission Level: Phenomenon De scription:
Product:
UA5000
04Common Users Permission 1. Networking: UA5000—NGN bearer—SoftX3000 2. UA5000 version: PVMV100R011B02D087 3. The control board is PVMB. Version information is as follows:
Confidential Information of Huawei. No Spreading without Permission
75
NGN Cases
Chapter 5 UA5000 Narrow-band Service --------------------------------------Pcb Version: H601PVMB VER.C Base Bios Version: 336 Extend Bios Version: 335 Software Version: PVMV100R011 CPLD Version: 198 Logic Version: 304 NOD Version: 10a Encrypt Nios Version: 101 --------------------------------------SubBoard[0] : Miro Version: Exp_Huawei_16880_22161_1 Rev E - HP --------------------------------------SubBoard[1] : 4. ASL and DSL boards are installed in the slave shelf. All boards in the shelf fail to register normally.
Alarm Informati on:
Cause Analysi s: Handling Proce ss:
1. Run the command display board 1. The system prompts all boards in the slave shelf are faulty. 2. On the board panel, all indicators of one DSL board are on. 3. Check alarm records. There are board error alarms. The earliest board alarm is a DSL board alarm.
1. The HWTB board or HW lines of the slave shelf is faulty. 2. The faulty DSL leads to the failure of other boards. 1. Replace the HWTB on the backplane of the slave shelf. The fault persists. Boards can be added in or deleted from the slave shelf before and after the replacement. The HWTB board and HW lines are normal. 2. Remove the faulty DSL board and check status of boards in the slave shelf. All the boards are Normal. Services are recovered.
Suggestions and Null Summary:
5.5
Slow Reporting of Collected Digits due to Conflict Between the Long and Short Timers Title: ID:
Update Time: Views: Author: Product Family:
SE0000392264 2009-05-27 16:55:45 7 y94956 Integrated Access
Fault Type:
Narrow-band Voice Service
Keywords:
Digitmap, timer, slow reporting of collected digits
Permission Level: Phenomenon De scription:
76
Slow Reporting of Collected Digits due to Conflict Between the Long and Short Timers
Product:
UA5000
02Huawei Partners Permission Some subscribers under an AG feel the wait time is long after dial a number. It seems the short timer is not effective. After the long timer duration is modified shorter, the subscribers feel much better. The digitmap rule sent by the AG is: DM=dmap1{([2-8]xxxxxxx|013xxxxxxxxx|015xxxxxxxxx|13xxxxxxxxx|15xxxxxxxxx|15 [0124-8]|010xxxSxxxxx|02xxxxSxxxxx|0[3-9]xxxxxSxxxxSx|00xxSx.|9xxxx|1[01246-9]x |E|F|[EF][0-9][0-9E].F|[EF][EF].F|[EF][EF][0-9][0-9]|x.F|x.E|[0-9].L)}}}}
Confidential Information of Huawei. No Spreading without Permission
MSAN UA5000 Cases
Alarm Informati on: Cause Analysi s:
Handling Proce ss:
Chapter 5 UA5000 Narrow-band Service
Null 1. The subscriber perception may be biased. 2. Because the digitmap is not optimal, multiple matches exist during digit collection. When both long and short timers are set, the long timer takes precedence. 1. Capture lower layer messages using DSWIN when the number 010114 is dialed. It is found that the interval from when the last digit is received by the AG to when the AG reports the digits is 5s. This is the duration of the long timer. The short timer (3s) is not effective. 71: [021][15:04:27.620]H248_DMM: Phyterm index 1
Confidential Information of Huawei. No Spreading without Permission
77
NGN Cases
Suggestions and Summary:
5.6
Chapter 5 UA5000 Narrow-band Service
According to H.248, the long timer prevails when the long timer conflicts with the short timer. This must be taken into consideration when a logical digitmap is edited.
Act ivatio n Failu re of the IUA Link on the UA5000 Because the Correspond ing Port on the SoftSwitch Firewall Is Not Enabled Title: ID:
Update Time: Views: Author: Product Family:
Activation Failure of the IUA Link on the UA5000 Because the Corresponding Port on the SoftSwitch Firewall Is Not Enabled
SE0000394390 2009-06-24 14:10:59 2 l92907 Integrated Access
Fault Type:
Narrow-band Voice Service
Keywords:
ISDN, link, activation
Permission Level: Phenomenon De scription:
04Common Users Permission
Alarm Informati on: Cause Analysi s:
Null
Handling Proce ss:
Product:
UA5000
In an office, the UA5000 ISDN service is configured. After the IUA link set and IUA link are configured, the IUA link cannot be activated. The queried status is down.
1. The UA5000 MG interface is abnormal. 2. The data on the UA5000 is inconsistent with the data on the SoftSwitch. 3. The network device screen the port of the IUA link. 1. Check the status of the UA5000 MG interface. It is found that the interface is normal. 2. Check data on both the UA5000 and the SoftSwitch. It is found that the data is consistent. In addition, the port number and IP address correspond with each other. 3. The network device may screen the port of the IUA link. Check the configurations of the UA5000, SoftSwitch, and intermediate network device. It is found that the local port for the UA5000 IUA link is not enabled on the SoftSwitch firewall. Modify the configuration of the firewall. Then the problem is solved.
Suggestions and The IUA link and the MG interface use different ports to register with the SoftSwitch. The Summary: bearer network and the SoftSwitch should enable the port of the IUA link.
5.7
Bus y Tone Upon Off-hook Due to the Abno rmal Maximum Leak Rate After the UA5000 Is Upgraded Title: ID:
Update Time: Views: Author: Product Family: Fault Type:
78
Busy Tone Upon Off-hook Due to the Abnormal Maximum Leak Rate After the UA5000 Is Upgraded
SE0000394174 2009-06-24 14:11:44 6 h93689 Integrated Access
Product:
UA5000
Narrow-band Voice Service
Confidential Information of Huawei. No Spreading without Permission
MSAN UA5000 Cases Keywords:
Chapter 5 UA5000 Narrow-band Service
Maximum leak rate
Permission Level: Phenomenon De scription:
01Huawei Engineers Permission
Alarm Informati on: Cause Analysi s:
Null
In an office, after multiple UA5000s are upgraded to a new version, the busy tone upon off-hook occurs when the traffic is heavy. After off-hook for multiple times, the call can be successfully made and the callee is normal. (Target version: V100R013C05B051)
1. The configuration of the device is incorrect. 2. The hardware such as control board or cable is faulty. 3. The overload control parameters of the UA5000 are improper.
Handling Proce ss:
1. Check the attributes of the MG interface. It is found that the attributes are proper. The MG interface can register successfully and the system does not have abnormal alarm information. 2. Run the display runstat callInfo command to query the current call information in the system. It is found the off-hook quantity is 50 and the communication quantity is 5. The put-through rate is very low. 3. Check and replace the control board and its subboard (H601PVMC0+H602ETCN). The problem persists. 4. Run the display mgc-overload-control command to check the maximum leak rate. It is found that the value generated by the upgrade tool is 0.40. Change it to 40. The problem persists. 5. Run the DBWIN command to check the maximum leak rate that takes effect in the system (case attachment: How to Check the Valid Leak Rate of the UA5000). It is found that the parameter does not take effect. Reset the H248 interface and test the service again. It is found that the service is normal.
Suggestions and Summary:
Maximum leak rate is used to restrict the number of calls initiated per second. In the subsequent UA5000 R13C05 and R17 versions, this overload control parameter is added. This parameter may be abnormal if the upgrade tool is faulty. In the future, the upgrade tool will be updated to thoroughly solve this problem. Currently, manually change this overload control parameter after using the upgrade tool.
5.8
Voice Noise caused by PVMB ethernet port worki ng mode in half dupl ex Title: ID:
Update Time: Views: Author: Product Family:
Voice Noise caused by PVMB ethernet port working mode in half duplex
SE0000393188 2009-06-24 14:13:05 5 Jendoubi Mohamed Moez Integrated Access
Fault Type:
Narrow-band Voice Service
Keywords:
PVMB half duplex
Product:
UA5000
Permission 04Common Users Permission Level: Phenomenon Des Subscriber connected to UA5000 PVMBV100R011. cription: Voice has a lot of noice and frequent disconnection. PVMB is connected to IPMB throug eth interface and then connected to IP backbone Alarm Informati on: Cause Analysi s:
Loop delay=6ms Packet loss rate= 81% The voice noice is due to packet loss rate which is very hight. The hight packet loss rate is due to ip interface.
Confidential Information of Huawei. No Spreading without Permission
79
NGN Cases
Chapter 5 UA5000 Narrow-band Service
Handling Proces s:
we display the working mode of the PVM eth interface: 100M half duplex. we display the working mode of the IPMB eth interface 6 , : 100M full duplex. After changing the working mode of the PVMB eth interface to 100M full duplex, the packet loss rate is 0%.
Suggestions and Null Summary:
5.9
Household Alarm Working Abno rmally Due to the Large Packet Disassembly Duratio n Title: ID:
Update Time: Views: Author: Product Family:
Household Alarm Working Abnormally Due to the Large Packet Disassembly Duration
SE0000394396 2009-06-26 10:08:00 1 z58814 Integrated Access
UA5000
Fault Type:
Narrow-band Voice Service
Keywords:
Packet disassembly duration, voice channel delay, alarm, DTMF
Permission Level: Phenomenon De scription:
04Common Users Permission
Alarm Informati on: Cause Analysi s:
Null
Handling Proce ss:
80
Product:
BSIA of country Y turns to carrier C through OFCOM. The report says that after the services of carrier B are transferred to the lines of carrier C, the household alarm system cannot work in the normal state. The MSAN is suspected to be abnormal.
The household alarm system automatically dials the alarm center through the household telephone line, and transmits related instructions to the alarm center through the DTMF signals. In this manner, the automatic alarm function is implemented. After the phone carrier is replaced, the household alarm cannot work in the normal state. First, we should confirm in which phase the problem occurs: dialing phase, connection phase, or conversation phase. Then, we can determine which phase is abnormal. According to the standard document NICC1704 of country Y, the household alarm adopts the Fast Format Protocol and DTMF signals to transmit messages, which lays a high requirement on call channel delay. Carrier C, however, is a new carrier that provides the VoIP-based voice service. The call channel delay from the terminal user to the server on the PSTN network may be large. The call channel delay is suspected to some extent. After the problem recurs on site, use a recording pen to record the voice on the line. After analyzing the recorded voice, do as follows: 1) According to the recorded voice, the problem occurs in the conversation phase. 2) Use the Cooledit to view the waveform of the recorded voice, and compare it with the corresponding standard (see the attachment). It is found that when the problem occurs, the ACK message (1.4 kHz single audio) sent from the alarm has a large delay. As a result, the server considers that the ACK message is not received in time and considers the alarm failure. 3) In the MSAN, the adjustable parameters that affect the delay are jitter buffer and packet disassembly duration. In the current version, jitter buffer is dynamically adjusted according to the network quality. Changing jitter buffer may not make a difference. The packet assembly duration, however, is set by the softswitch. Currently, the packet assembly duration is set to 20 ms instead of 10 ms recommended by NICC. 4) Change jitter buffer to 20 ms. It is found that the problem persists. Restore jitter buffer to its default value and change the packet assembly duration from 20 ms to 10 ms. Then the alarm works in the normal state. According to the waveform, the protocol is complied with. 5) After tests for several times, it is confirmed that the packet assembly duration is the key factor that affects the alarm. After the packet assembly duration is changed from 20 ms to 10 ms, the problem is completely solved. For the related documents and record materials, see the attachment.
Confidential Information of Huawei. No Spreading without Permission
MSAN UA5000 Cases
Chapter 5 UA5000 Narrow-band Service
Suggestions and Null Summary:
5.10 Service Failur e Because the Upstream Port Mode of th e H601PVMD Is Not Modifi ed Title: ID: Update Time: Views: Author: Product Family:
Service Failure Because the Upstream Port Mode of the H601PVMD Is Not Modified
SE0000392289 2009-05-27 16:49:49 2 z93451 Integrated Access
Fault Type:
Narrow-band Voice Service
Keywords:
H601PVMD, up-linkport
Permission Level: Phenomenon De scription:
04Common Users Permission
Alarm Informati on: Cause Analysi s:
Null
Product:
UA5000
Networking: UA5000—transmission—NE40E—3528—SoftX3000. The control board of the UA5000 is H601PVMD. The UA5000 version is UA5000PVMV100R017C02B107. Services are transmitted over the ETH1 port of the H601PVMD board. When an Ethernet cable is connected to the ETH1 port, the port indicator is not on.
The upstream service port mode is not modified so that the Ethernet port is down and service communication fails.
Handling Proce ss:
Connect the Ethernet cable connected to the ETH1 port to the Ethernet port of a laptop. The port indicator is on. The Ethernet cable is normal. Log in and run the following command to check the state of the ETH1 port: UA5000(config)#display fe active eth1 link state:down mode:100M duplex Check the working mode of the PVMD board as follows: M200(config)#display working mode working mode:alone outband port:ETH port service port:GE optic port The service port of the board is a GE optical port. Run the following command to modify the upstream port mode: UA5000(config)#up-linkport set workmode eth1 ! RECOVERY MAJOR 2008-10-24 13:29:39 ALARM NAME :Up ETH1 port link recovery After the modification is complete, the port is normal and services are restored.
Suggestions and Summary:
When the H601PVMD is used, modify the upstream port mode according to the physical configuration.
5.11 No Tone upon Offhook f or Subscr ibers under the UA5000 Because the HSCI Board of the Soft X3000 Is Faulty Title: ID:
No Tone upon Offhook for Subscribers under the UA5000 Because the HSCI Board of the SoftX3000 Is Faulty
SE0000392272
Confidential Information of Huawei. No Spreading without Permission
81
NGN Cases Update Time: Views: Author: Product Family:
Chapter 5 UA5000 Narrow-band Service 2009-05-27 16:50:08 4 q92670 Integrated Access
Fault Type:
Narrow-band Voice Service
Keywords:
Packet loss, dtu
Permission Level: Phenomenon De scription:
04Common Users Permission
Alarm Informati on: Cause Analysi s:
Null
Product:
UA5000
A UA5000R13C02B032 is deployed under a softswitch. Subscribers often complain that no tone is displayed upon off hook.
1. The network quality is poor. 2. The softswitch does not send the dial tine event correctly. 3. The AG processes H.248 signaling incorrectly.
Handling Proce ss:
1. Send 1000 ping packet from the AG to the softswitch. No packet is lost and the delay is stable. 2. Capture packets on the softswitch and the AG simultaneously and compare the signaling messages. Signaling captured on the AG: When the fault occurs, the AG reports offhook and the softswitch sends a dial tone event as cg/dtu instead of cg/dt. Because cg/dtu is not an H.248 descriptor. The AG cannot identify it and therefore does not send the dial tone. Because no response is received from the AG, the softswitch sends five Modify messages to send the dial tone. Signaling on the softswitch: The softswitch sends five Modify message continuously to the AG to send the dial tone after a subscriber hooks off. The dial tone event is cg/dt. Because the AG does not respond, the softswitch starts the retransmission mechanism and stops sending messages after sending the message for five times. But why signaling captured on the softswitch is different from that captured on the AG. On the AG side, packets are captured by an Ethereal capturer and the dial tone event captured is cg/dtu. On the softswitch side, packets are captured by the network management application and the dial tone event captured is cg/dt. Because of modular design, different modules of the softswitch system accomplish different functions. The signaling capture on the softswitch is signaling of the protocol processing module. That this signaling is normal does not mean the signaling sent from the softswitch is normal. By tracing the Debug message, the softswitch engineer finds that the HSCI is faulty so that error packets are delivered. Replace the HSCI board. The fault is rectified. Detailed signaling and analysis are described in the attachment.
Suggestions and Summary:
For an inter-product fault (related to the softswitch and the bearer network), it is necessary to capture packets on both sides simultaneously to find which product is faulty.
5.12 FAQ-Voice Subboard Round Robin Mechanis m of the PVM Board Title: ID: Update Time: Views: Author: Product Family: Fault Type:
82
FAQ-Voice Subboard Round Robin Mechanism of the PVM Board
SE0000392267 2009-05-27 16:50:51 6 l92637 Integrated Access
Product:
UA5000
Narrow-band Voice Service
Confidential Information of Huawei. No Spreading without Permission
MSAN UA5000 Cases Keywords:
Chapter 6 iManager N2000 BMS Cases
Round robin, processing, mechanism
Permission Level: Phenomenon De scription:
04Common Users Permission
Alarm Informati on: Cause Analysi s: Handling Proce ss:
Null
Q: What is the voice subboard round robin mechanism of the PVM board?
Null A: TI: This round robin mode allocates 32 successive channels in an ascending order based on the n units planned inside the subboard. If two units are divided for a subboard, the first allocated is the DSP channel 0 in the first unit, the next allocated is the DSP channel 0 in the second unit, still the next allocated is the DSP channel 1 in the first unit, then the DSP channel 1 in the second unit, and so on. MIRO: This round robin mode is basically the same as the TI mode except that a unit in this mode includes 256 successive channels.
Suggestions and Null Summary:
Chapter 6
6.1
iManager N2000 BMS Cases
Failu re in Alarm Disp laying on the N2000 BMS Due to the Error of Setting the Sourc e IP Address o f t he Trap Packets on t he MA5680T Title: ID:
Update Time: Author: Product Family:
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
SE0000365191 2008-12-23 10:41:48 h93670 Access Network Management System
Fault Type:
Element Management
Keywords:
Alarm, trap, source
Phenomenon De scription:
Product:
iManager N2000 BMS
The BMS version is N2000 BMS V200R011C16B020CP001. The NE version is MA5680T V800R105C33B011. Networking: The MA5680T connects to the N2000 BMS through the MEth interface, and then communicates with the N2000 BMS in the upstream direction through the inband GICF board. The MA5680T can be managed on the N2000 BMS normally, but the alarms of the MA5680T fail to be displayed.
Alarm Informat ion: Cause Analysi s:
Null
Handling Proce ss:
1. Check the source IP address of the trap packets configured on the device. The source IP address is displayed as METH 0.
If the source IP address of the trap packets configured on the NE is different from that of the interface for connecting the MA5680T to the N2000 BMS, the alarms cannot be reported to the N2000 BMS.
Confidential Information of Huawei. No Spreading without Permission
83
NGN Cases
Chapter 6 iManager N2000 BMS Cases 2. The L3 interface of the N2000 BMS passes VLAN 31. Run the following command to modify the source IP address of the trap packets on the device to vlan31: huawei(config)#snmp-agent trap source vlanif 31 3. Query the alarms of the MA5680T on the N2000 BMS. The alarms are displayed.
Suggestions and Null Summary:
6.2
Unable to Telnet DSLAM From BMS Because of Devic e access Prox y Process Problem Title: ID:
Update Time: Author: Product Family:
Unable to Telnet DSLAM From BMS Because of Device access Proxy Process Problem
SE0000386443 2009-04-17 15:19:55 Hesham Emad Access Network Management System
Product:
Fault Type:
Element Management
Keywords:
telnet BMS DSLAM failed Device access Proxy Process
Phenomenon Des cription:
iManager N2000 BMS
The customer has BMS windows server, if he telnet to the DSLAM from the DOS prompet, telnet successed. If he try to telnet to the DSLAM from BMS platform, it fails. BMS version is V200R011C02B026.
Alarm Informati Null on: Cause Analysi Device access Proxy Process was disabled, which is responsible for the telnet process. s: Handling Proces From SysMonitor, start the Device access Proxy Process and make it Automatic to start by default every time the BMS s s: Suggestions and Null Summary:
6.3
NEs Are Detached from the N2000 BMS After the Ant i-ARP Attack Feature Is Enabled on the Uplink Switch Title: ID:
Update Time: Author: Product Family:
SE0000354169 2008-10-28 14:21:03 l93485 Access Network Management System
Fault Type:
Element Management
Keywords:
Detachment of NEs, BMS
Phenomenon De scription:
Alarm Informat ion: Cause Analysi s:
84
NEs Are Detached from the N2000 BMS After the Anti-ARP Attack Feature Is Enabled on the Uplink Switch
Product:
iManager N2000 BMS
Networking: N2000 BMS server ? 2403 switch ? 8505 switch ? DSLAM device Symptom: NEs are detached from the N2000 BMS. Ping the 8505 switch from the server and find that some packets are lost. Null 1. The network interface card of the BMS server has a hardware fault. 2. The BMS server is attacked or it is attacked by its own viruses. 3. The handling on the upstream switching device is abnormal.
Confidential Information of Huawei. No Spreading without Permission
MSAN UA5000 Cases
Handling Proce ss:
Chapter 6 iManager N2000 BMS Cases
1. Ping PCs at the same network segment from the server and find that no packets are lost. Therefore, the network adapter is running properly. 2. Scan viruses on the server and find no exception. 3. Log in to and check the uplink 8505 switch, and find the following alarm messages: 3 04:07:44 2008 ZH_XXZ_S8505_A DIAGCLI/5/LOG_WARN:Slot=6; Detect ARP attack from MAC 0011-43ba-c24f, VLAN: 993, GigabitEthernet6/2/4 ! Where, 0011-43ba-c24f is the MAC address of the N2000 BMS. It can be judged that the 8505 switch considers the N2000 BMS as an exceptional attack user by mistake (the N2000 BMS broadcasts a large number of ARP packets to obtain the MAC address of DSLAM device during the resynchronization with the 8505 switch). In this way, the 8505 switch does not forward the MAC address of the N2000 BMS, and places it into the black hole instead. As a result, all ARP packets are discarded by the 8505 switch. In this case, when you ping the 8505 switch from the N2000 BMS, the packets are lost and eventually the ping operation fails (however, you can ping through other PCs under the 2403 switch). Therefore, the N2000 BMS fails to control the device properly. Configure the anti-attach ARP exclude MAC address on the 8505 switch as follows: anti-attack arp exclude-mac mac-address (the MAC address of the N2000 BMS). Then the problem is solved.
Suggestions and To solve the problem of the detachment of NEs from the BMS server, you should consider the Summary: problem from the network perspective and capture packets.
6.4
Device Is Add ed and Then Disappears During the Synchr onizatio n Because of the License Issue Title: ID:
Update Time: Author: Product Family:
Device Is Added and Then Disappears During the Synchronization Because of the License Issue
SE0000363508 2008-12-16 20:20:32 w56146 Access Network Management System
Fault Type:
Element Management
Keywords:
License, device disappears
Phenomenon De scription:
Alarm Informat ion: Cause Analysi s:
Product:
iManager N2000 BMS
The BMS version of the N2000 BMS is V2R10C02B015SPC002. The MA5300 is added to the N2000 BMS and then disappears during data synchronization. If the operation is performed in time, the device panel can be displayed before the MA5300 disappears. Null 1. The problem can be traced to insufficient licenses. Query the licenses of the N2000 BMS on the client and it is found that no item is highlighted in red. 2. When the N2000 BMS is installed, a temporary license is used. Adding the MA5300 is successful and other operations can be performed on the MA5300. The problem occurs after the temporary license is replaced with the commercial license. Check the commercial license and the problem is located. The versions of the N2000 BMS later than V200R009 use the license file of V200R009. The license file contains the following four control items: 1> Feature COMMON Authorizes the validity period and the maximum number of the N2000 BMS clients that can log in. 2> Feature INSTALL Authorizes the installation components of the N2000 BMS. 3> Feature BMSWG Authorizes the service port and the lines.
Confidential Information of Huawei. No Spreading without Permission
85
NGN Cases
Chapter 6 iManager N2000 BMS Cases 4> Feature BMSNB Authorizes the types and number of northbound interfaces. Query the license of the faulty site and it is found that there are only the COMMON and INSTALL control items. No control item for port types and lines is detected. 3. Operations can be performed on devices that are added by using the temporary license, although the existing commercial license does not authorize ADSL ports. But the client keeps prompting the license error. 4. After the commercial license is used and the device is added, related modules communicate with the license center and obtain authorization during the data synchronization of the device. As the license does not authorize the port types and lines, the N2000 BMS deletes the device automatically, which causes the problem. 5. When the earlier and later licenses exist at the same time, the error of the license file can be located according to the following two situations: 1> Check whether the current N2000 BMS replaces the N2000 BMS of versions earlier than V200R009. If yes, it is possible that the license does not authorize the management capacity. Ensure that the later license is not used any more on the N2000 BMS. Then submit the later license to the Notes electronic workflow Platform License and upgrade it to the earlier license. Obtain the LAC from the electronic workflow, download the earlier license from the license website, and then consolidate the earlier license with the later one that does not authorize the management capacity of the device. 2> If the existing N2000 BMS is newly installed, contact the marketing representative and modify the contract to solve the problem.
Handling Proce ss:
If the problem is not caused by the license, collect and report the following information: 1. The debug information about the process of the related NE 2. N2000\server\conf\log\base_pserverID*.log 3. N2000\server\debug\process name*.log 4. N2000\server\log\process name*.log
Suggestions and Null Summary:
6.5
N2000 BMS Fails to Add an NE Because of the Deadloc k of the Acc ount on the Device Side Title: ID:
Update Time: Author: Product Family:
N2000 BMS Fails to Add an NE Because of the Deadlock of the Account on the Device Side
SE0000363500 2008-12-16 20:20:40 y96604 Access Network Management System
Fault Type:
Element Management
Keywords:
Fails to add an NE
Phenomenon De scription:
Product:
iManager N2000 BMS
When the MA5100 is added to the N2000 BMS, the N2000 BMS prompts the communication failure of the device. The MA5100 fails to be added.
Alarm Informat ion: Cause Analysi s:
The N2000 BMS prompts the communication failure of the device.
Handling Proce ss:
1. Ping the IP address of the MA5100. The operation is successful. Hence, the problem is not caused by the communication failure between the N2000 BMS and the MA5100. 2. Query the MA5100 process through the SysMonitor, and it is found that the MA5100 process runs normally. Add other NEs to the N2000 BMS. The operation is successful. Hence, the
86
After the analysis, the possible causes are as follows: 1. The MA5100 fails to communicate with the N2000 BMS. 2. The process of the MA5100 is faulty.
Confidential Information of Huawei. No Spreading without Permission
MSAN UA5000 Cases
Chapter 6 iManager N2000 BMS Cases
problem is not caused by the N2000 BMS. 3. Log in to the MA5100 manually, and it is found that the system prompts too many users. The problem is traced to too many accounts that log in to the MA5100 or the user account is deadlocked. After the users are disconnected automatically by the system, you can log in to the MA5100 and the MA5100 can be added. Suggestions and Null Summary:
6.6
N2000 BMS Server Is Shut Down Auto maticall y Because the Setting of th e Configuration File of Solaris OS Is Incorrect Title: ID:
Update Time: Author: Product Family:
N2000 BMS Server Is Shut Down Automatically Because the Setting of the Configuration File of Solaris OS Is Incorrect
SE0000394087 2009-06-02 14:04:12 h93856 Access Network Management System
Fault Type:
Operation system
Keywords:
Shut down automatically, Solaris
Phenomenon De scription:
Product:
iManager N2000 BMS
The N2000 BMS server is frequently shut down automatically. Then, the server runs in the normal state after it is restarted.
Alarm Informat ion: Cause Analysi s:
Null
Handling Proce ss:
1. Check the hardware and the system when the N2000 BMS server is running and it is found that both the hardware and the system are normal. That is, no alarm is reported, and the CPU usage and memory usage rates are low. 2. Test the power supply on site and it is found that the power supply is normal. The fault may be caused by incorrect setting of the configuration file. 3. Run the power.conf file and the following message is found: root@N2000Server # more /etc/power.conf device-dependency-property removable-media /dev/fb autopm default statefile //.CPR # Auto-Shutdown Idle(min) Start/Finish(hh:mm) Behavior autoshutdown 30 9:00 9:00 default
The possible causes are as follows: 1. The power supply or the hardware is abnormal. 2. The Solaris OS is abnormal. 3. Other settings are incorrect.
As shown in the preceding message, by default, the N2000 BMS server is automatically shut down after the system retains idle for 30 minutes. The cause of the fault is found. 4. Change the default value to noshutdown and then restart the system. Then the N2000 BMS server runs in the normal state and is not shut down automatically. Suggestions and Null Summary:
Confidential Information of Huawei. No Spreading without Permission
87
NGN Cases
6.7
Chapter 6 iManager N2000 BMS Cases
Logi n to the Xmanager Fails Because the Default Monitori ng Port of the dtlog in Process Is Port 0 Title: ID:
Update Time: Author: Product Family:
Login to the Xmanager Fails Because the Default Monitoring Port of the dtlogin Process Is Port 0
SE0000363517 2008-12-16 20:20:20 t60027289 Access Network Management System
Fault Type:
Operation system
Keywords:
Xmanager, dtlogin
Phenomenon De scription:
Product:
iManager N2000 BMS
The model of the server is SUN Fire V245. The operating system is Solaris 10 (08/07). The BMS version is N2000 BMS V200R011C015B012. After Solaris 10 is installed on the SUN Fire V245 (the server has no display adapter and cannot be connected to monitors), the login to the Xmanager fails. The system reports “connect xdmcp failed.” The ping, ftp, and telnet functions are normal.
Alarm Informat ion: Cause Analysi s:
The login to the Xmanager fails and the system reports “connect xdmcp failed.”
Handling Proce ss:
Solutions to the problem are as follows: 1. Start the dtlogin process in the daemon mode. Run the # /etc/init 。d/dtlogin stop # to disable the service. Run the # /usr/dt/bin/dtlogin -daemon & # command to change the daemon mode. 2. The specified dtlogin -udpPort 177 is displayed. Run the service management command svccfg to modify related parameters: # svccfg svc:> select application/graphical-login/cde-login svc:/application/graphical-login/cde-login> listprop dtlogin/args dtlogin/args astring “ -udpPort 0" svc:/application/graphical-login/cde-login> setprop dtlogin/args = “\ -udpPort 177" svc:/application/graphical-login/cde-login> listprop dtlogin/args dtlogin/args astring “ -udpPort 177" svc:/application/graphical-login/cde-login> quit # svcs | grep cde-login online 15:07:59 svc:/application/graphical-login/cde-login:default If disable is displayed in the preceding message, run the svcadm enable svc:/application/graphical-login/cde-login:default command to start the service: # svcadm restart cde-login Restart the Xmanager. After entering the CDE, run the ps command to query the dtlogin process. The -udpPort is modified to 177 and the problem is solved.
Suggestions and Summary:
In the case of the SUN servers that cannot be connected to monitors, the Xmanager is mandatory for installing the database and the N2000 BMS. When certain Solaris installation disks are used on certain servers, the preceding problem occurs and results in that the Xmanager cannot be used. To locate the problem, refer to this case.
88
Connect to the server in the Telnet mode. Run the netstat -an|grep 177 command and it is found that port 177 is disabled. Run the ps -ef|grep dtlogin command. The displayed message is /usr/dt/bin/dtlogin -daemon -udpPort 0. In normal conditions, if the dtlogin process is started, the displayed message should be /usr/dt/bin/dtlogin -daemon. Run the svcadm restart svc:/application/graphical-login/cde-login command to restart the dtlogin service. It is found that the display message still contains -udpPort 0. The system listens to the udpport 0 and fails to listen to the XDMCP request reported by port 177.
Confidential Information of Huawei. No Spreading without Permission
MSAN UA5000 Cases
6.8
Chapter 6 iManager N2000 BMS Cases
N2000 BMS Fails to Automati cally Detect Devices Because of the Auto -Negoti ation Error of the Network Card Title: ID:
Update Time: Author: Product Family:
N2000 BMS Fails to Automatically Detect Devices Because of the Auto-Negotiation Error of the Network Card
SE0000363387 2008-12-16 20:25:28 s92996 Access Network Management System
Fault Type:
Operation system
Keywords:
Network card, auto-negotiation
Phenomenon De scription:
Product:
iManager N2000 BMS
The networking mode is C6509 – Dell 6600 server. The N2000 BMS is configured to automatically detect devices when devices are added. The N2000 BMS, however, fails to detect devices sometimes and the devices cannot be found. Ping a large number of gateway addresses and network disconnection occurs. Disable the network card and then enable it, the system prompts that the connection fails. In this case, you must restart the N2000 BMS server to continue to add devices. This fault, however, reoccurs some time later.
Alarm Informat ion: Cause Analysi s:
Null
Handling Proce ss:
Select My Computer, right-click, and then choose Properties > Hardware > Device Manager > Network adapters. Select the working network card, right-click, and choose Properties. In the dialog box that is displayed, click the Advanced tab. In the Properties dialog box, select Speed & Duplex and set the value to 100Mb Full. Then restart the server. The fault does not reoccur.
Suggestions and Summary:
Dell engineers explain that this problem occurs because of the compatibility of C devices and the Dell server. It is recommended that you modify the network card of the server to Speed 100M & Duplex FULL.
6.9
The status of the C6509 port that connects the server is set to Speed 100M & Duplex FULL. After you query the status of the network card on the server, the network card is in the auto-negotiation and half-duplex mode when the gateway is disconnected. The network card, however, recovers to the auto-negotiation and full-duplex mode after you restart the server. After a period of time, the network card works in the auto-negotiation and half-duplex again. Hence, this fault may be caused by auto-negotiation error.
Standby Server Fails to Be Started Because the N2000 BMS HA System Is Powered Off Ab normall y Title: ID:
Update Time: Author: Product Family:
Standby Server Fails to Be Started Because the N2000 BMS HA System Is Powered Off Abnormally
SE0000365232 2008-12-23 10:40:01 c00104669 Access Network Management System
Fault Type:
Operation system
Keywords:
Standby server, fsck, comment out, mount
Phenomenon De scription:
Product:
iManager N2000 BMS
The N2000 BMS HA system of a certain office is powered off abnormally, and so the standby server can enter only the single-user mode. An error is displayed when the fsck-y command is run in this mode.
Confidential Information of Huawei. No Spreading without Permission
89
NGN Cases Alarm Informat ion:
Chapter 6 iManager N2000 BMS Cases When the fsck -y command is run in the single-user mode, the following alarm is displayed: ** /dev/vx/dsk/bootdg/opt ** Currently Mounted on /opt ** Phase 1 ... ** phase 2 ** phase 3 ** phase 4 ** phase 5 filesystem may still be inconsistent 7973 files........ *** please retun fsck on unmounted file systetm*** * /dev/vc/rdsk/n2kdg_N2000Primary/lv_license(NO WRITE) warning: error writing ufs log state warning: ufs log for /tmp/.rlg..daw.a/.rlg..daw.a changed state to error warning: please umount(1M) /tmp/.rlg..daw.a/.rlg..daw.a and run fsck(1M) can’t roll the log for /dev/vx/rdsk/n2kdg_N2000Primary/lv_license. discarding the log may discard pending transactions. discard the log and continue? no
Cause Analysi s:
The N2000 BMS of the office integrates the N2000 BMS and the License Server. Through alarm analysis of the fsck -y, the system fails to be started because the lv_licese volume of the License Server cannot be mounted. Two solutions are available for the problem: 1. Stop the control by the Veritas and make the Solaris start itself. This solution is impossible because you need to de-encapsulate and unmirror the disks. 2. When the system is started, it mounts the volumes in the /etc/vfstab path automatically. Therefore, comment out the lv_license volume that cannot be loaded successfully, and then the system can be started successfully.
Handling Proce ss:
To modify /etc/vfstab, comment out the following line: /dev/vx/dsk/n2kdg_N2000Primary/lv_license /dev/vx/rdsk/n2kdg_N2000Primary/ lv_license /opt/license ufs 2 yes logging Restart the system, and the standby server can enter the multiuser mode. Mount all the volumes manually, and synchronize the standby server with the active one. In this case, the N2000 BMS system can recover.
Suggestions and Null Summary:
6.10 Troub leshoot ing of the Abno rmal Replicati on Relation Between the Act ive and the Standby Servers of the N2000 BMS HA System Title: ID: Update Time: Author: Product Family:
SE0000365200 2008-12-23 10:41:04 l49455 Access Network Management System
Product:
Fault Type:
Operation system
Keywords:
BMS, Watchman, V200R011C02C026, HA system
Phenomenon De scription:
90
Troubleshooting of the Abnormal Replication Relation Between the Active and the Standby Servers of the N2000 BMS HA System
iManager N2000 BMS
1. The replication relation between the active and standby servers of the N2000 BMS HA system installed in representative office A is abnormal. 2. It is found from the Watchman that there are only two data lines between server A and server B and both data lines are red. 3. Red alarm information is displayed on both server A and server B.
Confidential Information of Huawei. No Spreading without Permission
MSAN UA5000 Cases
Chapter 6 iManager N2000 BMS Cases
4. The BMS version is N2000 BMS V200R011C02C026 and the server version is SUN Server V890. Alarm Informat ion: Cause Analysi s:
Null
Handling Proce ss:
1. After analyzing the fault information file that is generated by the WatchmanExplorerV1R2_conf.sh, R&D engineers confirm that the replication process and configuration on server A and server B are normal. 2. After the Quick Recover function of the Watchman is enabled on site, the replication relation between the active server and the standby server returns to normal. The problem is solved.
Suggestions and Summary:
The configuration and operation interface of the Watchman on the N2000 BMS V200R008B02D061 are greatly different from those on the N2000 BMS V200R011C02C026. Pay attention to the differences when using different BMS versions.
The onsite information is as follows: 1. In the standalone mode, both server A and server B work in the normal state. 2. The IP addresses of server A and server B are 10.101.2.205/24 and 10.101.2.206/24. Only one network port works on each server. 3. Run the WatchmanExplorerV1R2_conf.sh script in the /opt/watchman/server/bin directory to collect fault information. The fault information file is placed in the /tmp directory. Note: The WatchmanExplorerV1R2_conf.sh is a new tool on the N2000 BMS V200R011C02C026 for collecting fault information.
6.11 GPON ONT termin al upgrade func tio n isn't available on BMS N2000 Title: ID: Update Time: Author: Product Family:
GPON ONT terminal upgrade function isn't available on BMS N2000
SE0000348010 2008-09-26 09:59:02 Lin Yanhua Access Network Management System
Fault Type:
Service Management
Keywords:
GPON ONT Upgrade BMS
Phenomenon Des cription:
Product:
iManager N2000 BMS
ONT upgrade funciont is new feature of BMS,but I have failed serveral times to upgrade Ont on BMS. please referto "upgrade terminal isn't available.jpg"
Alarm Informati on: Cause Analysi s:
null
Handling Proces s:
1.Check the BMS xPON processing, it's running normally. check the ONT work normally through the CLI command method. 2.BMS can manage and config OLT and ONT normally. all other function is normal except for Upgrade terminal. 3. Change the configuration about the ONT vendor, ONT type, ONT software on N2000. Click the menu "modify", then configure correct VendorID, Terminal Type,Softwareversion etc. please refer to "select the correct ONU information.jpg" 4. Check and test again, the "Upgrade terminal" menu become normal. please refer to "Upgrade Terminal is available.jpg"
Suggestions and Summary:
null
1.BMS running abnormally 2.The ONT don't support terminal upgrade funciotn by BMS not all ONT can support the remote upgrade by BMS. only some type of ONT produced by Huawei or the ONT has been bested by Huawei.
Confidential Information of Huawei. No Spreading without Permission
91
NGN Cases
Chapter 6 iManager N2000 BMS Cases
6.12 Failu re in the Establis hment of the Replicati on Relation on the HA System (Watchman) Because of Inconsi stency of t he Name of the Replication L ink Title: ID: Update Time: Author: Product Family:
Failure in the Establishment of the Replication Relation on the HA System (Watchman) Because of Inconsistency of the Name of the Replication Link
SE0000365189 2008-12-23 10:42:00 z46041 Access Network Management System
Fault Type:
Network Management Platform
Keywords:
Watchman, rlink, replication relation
Phenomenon De scription:
Product:
iManager N2000 BMS
After the Force Active or Force Standby operation is performed, the replication relation of the HA system (Watchman) fails to be established.
Alarm Informat ion: Cause Analysi s:
Replication status is abnormal!
Handling Proce ss:
1. Query the alarms and logs and find that the rlk_10.0.0.20_wm_rvg file exists. The rlk_10.0.0.20_wm_rvg file is not created by the Watchman. The name of the replication link that is created by the Watchman should be a_to_b_rlk or b_to_a_rlk. 2. Check the name of the replication link in VEA. The name is displayed as rlk_10.0.0.20_wm_rvg. The problem is caused by inconsistency of the name of the replication link. After contacting the onsite engineer, it is confirmed that the replication link is established through VEA. 3. Set the name of the replication link in VEA to a_to_b_rlk or b_to_a_rlk. 4. Stop the application and run the following command to delete the replication link: #sh /etc/wmscript/stoprep 5. Setting up the replication link through the Force Active or Force Standby operation on the Watchman client is successful.
Suggestions and Summary:
In the Watchman HA system, use the Watchman to manage and perform operations, rather than through VEA.
The replication link is tried to be set up through VEA on site which causes that the name of the replication link in VEA is set to rlk_serverIP_wm_rvg. Therefore, the name of the replication link is inconsistent with that of the rlink on the HA system (Watchman).
6.13 Operatin g the N2000 BMS Throu gh the Monitor Fails Because of a Fault of th e Input and Output Modes Title: ID: Update Time: Author: Product Family:
SE0000390493 2009-05-14 16:15:50 g92532 Access Network Management System
Fault Type:
Network Management Platform
Keywords:
monitor, input, output
Permission Level:
92
Operating the N2000 BMS Through the Monitor Fails Because of a Fault of the Input and Output Modes
Product:
iManager N2000 BMS
04Common Users Permission
Confidential Information of Huawei. No Spreading without Permission
MSAN UA5000 Cases Phenomenon De scription:
Chapter 6 iManager N2000 BMS Cases
The N2000 BMS server is installed on the SUN 5220T. After the SUN 5220T is connected to a monitor, operations cannot be performed to the N2000 BMS through the monitor. The monitor displays a dark screen.
Alarm Informat ion: Cause Analysi s:
Null
Handling Proce ss:
1. Check each connection. The connections are good. 2. It is suspected that a hardware fault occurs. Use another monitor of the same model. The fault persists. 3. Log in to the N2000 BMS server through the serial port and perform the following operations: root@HWEPONN2000 # eeprom |grep put output-device=virtual-console input-device=virtual-console The input and output modes are incorrect. Change the input and output modes as follows: root@HWEPONN2000 # eeprom root@HWEPONN2000 # eeprom input-device=keyboard root@HWEPONN2000 # eeprom output-device=screen The input and output modes are changed to the keyboard and monitor respectively. Operations can be performed through a monitor and a keyboard. The problem is solved.
1. Hardware fault 2. Connection fault 3. Other faults
Suggestions and After a monitor is connected, you cannot log in to the N2000 BMS server through the serial Summary: port. To log in to the N2000 BMS server through the serial port, remove the keyboard and the mouse.
6.14 All t he Narrow band NEs Fall out of Management Aft er the N2000 BMS Server Is Restarted Title: ID: Update Time: Author: Product Family:
All the Narrowband NEs Fall out of Management After the N2000 BMS Server Is Restarted
SE0000390510 2009-05-14 16:16:06 l00138220 Access Network Management System
Fault Type:
Network Management Platform
Keywords:
N2000, restart, route
Product:
iManager N2000 BMS
Phenomenon De scription:
The N2000 BMS server manages both broadband and narrowband services. After the N2000 BMS server is restarted, broadband NEs can be managed normally, but the narrowband NEs such as the UA5000 fall out of management and their icons are dimmed. These narrowband NEs cannot be pinged. The N2000 BMS is in V200R011C03B008CP2005.
Alarm Informat ion:
Communication with the device fails. This alarm is generated on the UA5000 NE and is queried on the N2000 BMS.
Cause Analysi s:
Handling Proce ss:
1. The network card on the server is faulty. 2. The network connection is faulty. 3. The N2000 software on the server is faulty.4. The database is faulty. 1. Perform a dialing test. The services are all normal. 2. The alarm indicating a failure to communicate with the device occurs within seconds after the
Confidential Information of Huawei. No Spreading without Permission
93
NGN Cases
Chapter 6 iManager N2000 BMS Cases server is restarted. You can infer that the N2000 BMS is not connected after it is restarted. 3. The broadband devices are not affected by the restart. Therefore, you can start with the difference in the management mode of narrowband devices. Through consultation, you know that the server is configured in the same network segment as the broadband devices, and that the narrowband devices in another network segment are managed through static routes. 4. The static routes may be lost during the restart of the N2000 BMS. Configure the static routes again. The N2000 BMS resumes its management of the narrowband NEs.
Suggestions and Summary:
The N2000 BMS server can manage both the broadband service and the narrowband service in different network segments. In this case, the default network card on the server is configured with an IP address that is in the same network segment as the broadband service. To enable the server to manage the narrowband service, you should configure static routes from the narrowband NEs to the server. To prevent loss of routes during the restart of the system, add the static routes to the start items on the server as follows: 1. Write the following route starting script in the rc3 file in the path /etc on the SUN workstation: route add network address –netmask subnet mask gateway address. Example: #route add 192.168.10.0 -netmask 255.255.255.0 10.11.201.254 2. On Windows, write the configured routes mentioned above in a batch processing file (*.bat) and add them to the start items of the system.
6.15 While login the Database Backup Tool,it appears Fail to connect the server Title: ID: Update Time: Author: Product Family:
While login the Database Backup Tool,it appears Fail to connect the server
SE0000396249 2009-06-30 16:07:32 Yanzhikuan 00145384 Access Network Management System
Fault Type:
Network Management Platform
Keywords:
BMS DatabaseBackupTool
Phenomenon De scription:
Product:
iManager N2000 BMS
While login the Database Backup Tool,it appears "Fail to connect the server" Version Information: Network Managemant systemVersion:V200R011C02B026SPC003 Database system:SYBASE OS:Windows
Alarm Informat ion: Cause Analysi s:
"Fail to connect the server"
Handling Proce ss:
1. Stop the Database Backup Process in sysmonitor. 2. Move out the original LogInfo.cfg,then Create a new blank LogInfo.cfg # cd /opt/n2000/server/conf/dbback/ # mv LogInfo.cfg LogInfo.cfg.bk # touch LogInfo.cfg # chmod 777 LogInfo.cfg 3. Modify the file n2000/server/conf/dbback/CRCRecord.cfg,make the value of log num to 0? # vi CRCRecord.cfg [CRC_NOMBER] CRCNumber=0 4. start the Database Backup Process in sysmonitor
1. check the N2000 client and Sysmonitor whether can login normal; 2. check the Database Backup Process of Sysmonitor whether is normal; 3.check the file of n2000/server/conf/dbback/LogInfo.cfg whether is more than 32k; 4. LOG is more than 32k,it is too large.
Suggestions and NO
94
Confidential Information of Huawei. No Spreading without Permission
MSAN UA5000 Cases
Chapter 6 iManager N2000 BMS Cases
Summary:
6.16 FAQ-What is the compatib ili ty between BMS and Solaris Title: ID: Update Time: Author: Product Family:
FAQ-What is the compatibility between BMS and Solaris
SE0000380008 2009-03-26 13:46:09 GWX12025 Access Network Management System
Fault Type:
Operation system
Keywords:
SUN FIRE V890
Phenomenon Des cription:
Product:
iManager N2000 BMS
Q: Can BMS V200R008B02D061SP27 work on Solaris 10?
Alarm Informati on: Cause Analysi s:
Null
Handling Proces s:
A:
N2000 BMS V200R008B02D061SP27 can not run on Solaris 10.
The current N2000 BMS is V200R008B02D061SP27 and the server is a SUN FIRE V440 with solaris 8 and sybase 12.0 Customer needs to migrate this BMS on a SUN FIRE V890. SUN FIRE V890 server does not work with solaris 8 so, it is necessary to install Solaris 10 and Sybase 12.5 To install Solaris 8 on V890 check OS detail infromation in ".volume.inf" file in the disk because SUN FIRE V890 supports Solaris 8 just if the detail version is equal or later than Solaris 8 (02/04) and the CPU is 1050, 1200 or 1350 MHz . The OS detail informatin was checked in the disk and it was found right it is Solaris 8 (02/04). The CPU was checked and it is found that this server has a CPU 1500 MHZ so this new CPU does not support Solaris 8. Suggestions and Summary:
To get more details you can check the following document or visit SUN web site. Solaris 8 2/04 Release Notes Supplement for Sun Hardware document .
6.17 FAQ-How to handle sol aris prompt 'Device busy' when used 'eject command' to pop out the cdrom f ailed Title: ID: Update Time: Author: Product Family:
FAQ-How to handle solaris prompt 'Device busy' when used 'eject command' to pop out the cdrom failed
SE0000397146 2009-06-22 10:28:36 Zhou Feng Access Network Management System
Fault Type:
Operation system
Keywords:
device busy volmgt cdrom eject
Product:
iManager N2000 BMS
Confidential Information of Huawei. No Spreading without Permission
95
NGN Cases Phenomenon Des cription: Alarm Informati on: Cause Analysi s: Handling Proces s:
Chapter 6 iManager N2000 BMS Cases Q: How to handle solaris prompt 'Device busy' when used 'eject command' to pop out the cdrom failed? Device busy! Null A: Login with root user,and excute follow command: /etc/init.d/volmgt stop And then press the pop-out button on the cdrom ,take out the disk. Excute follow command to restore the cdrom: /etc/init.d/volmgt start
Suggestions and Null Summary:
6.18 FAQ-How to Mirro r Disk s on Solaris OS Title: ID: Update Time: Author: Product Family:
SE0000363497 2008-12-16 20:23:36 t93368 Access Network Management System
Fault Type:
Operation system
Keywords:
Solaris, disk mirroring
Phenomenon De scription: Alarm Informat ion: Cause Analysi s: Handling Proce ss:
96
FAQ-How to Mirror Disks on Solaris OS
Product:
iManager N2000 BMS
Q: How to mirror disks on Solaris OS? Null Null A: Background: In the operation manual, the chapter about disk mirroring of the N2000 BMS V200R008 only describes how to perform disk mirroring with two disks on Solaris 8 OS. It does not describe how to perform disk mirroring with four disks. The N2000 BMS V200R011 provides scripts for mirroring the first and second disks to the later two disks on Solaris 10 OS. But how can you mirror the first disk to the second one and the third disk to the fourth one? This case describes how to perform disk mirroring flexibly. Note: This case considers the SUN V440 as an example and describes how to perform disk mirroring with four disks to separately mirror the used disks (disks and ) to disks and . Close the N2000 BMS and the Sybase database, install the disk mirroring software — DiskSuite4.2.1, and then run the disk mirroring scripts. Section 1 Mirroring Partitions Run the root@N2000Server # df -k command to query partitions. The partitions are as follows. Filesystem kbytes used avail capacity Mounted on /dev/dsk/c1t0d0s0 37183076 18469581 18341665 51% / /dev/dsk/c1t0d0s3 10327372 6231083 3993016 61% /opt /dev/dsk/c1t1d0s6 20981641 2634691 18137134 13% /opt/n2000 /dev/dsk/c1t0d0s7 14783019 147 14635042 1% /export/home /dev/dsk/c1t1d0s5 49575232 13575128 35504352 28% /opt/sybase Note: The first disk has three partitions. Root partitions /, opt/, and /export/home are installed
Confidential Information of Huawei. No Spreading without Permission
MSAN UA5000 Cases
Chapter 6 iManager N2000 BMS Cases
separately in the partitions of the disk. The second disk has two partitions. The N2000 BMS and the Sybase database are installed separately in these two partitions. To synchronize the partitions of the third disk with the partitions of the first disk, run the following command: #prtvtoc /dev/rdsk/c0t0d0s2 | fmthard -s - /dev/rdsk/c0t2d0s2 In the preceding command, c0t0d0s2 indicates the existing disk and c0t2d0s2 indicates the mirrored disk. To synchronize the partitions of the fourth disk with the partitions of the second disk, run the following command: #prtvtoc /dev/rdsk/c0t1d0s2| fmthard -s - /dev/rdsk/c0t3d0s2 In the preceding command, c0t1d0s2 indicates the existing disk and c0t3d0s2 indicates the mirrored disk. Section 2 Mirroring Application Disks To mirror disk c1t1d0s2 (data disk) to disk c1t3d0s2, run the following commands: #d50 -m d51 d52 1 #d51 1 1 c1t1d0s5 #d52 1 1 c1t3d0s5 #d60 -m d61 d62 1 #d61 1 1 c1t1d0s6 #d62 1 1 c1t3d0s6 #metattach d50 d52 //Perform synchronization #metattach d60 d62 //Perform synchronization By running the metastat command, you can query the progress of the synchronizations. The synchronizations take about two hours. After the synchronizations are complete, you can perform operations in section 3. Section 3: Mirroring the System Disk To mirror disk c1t0d0s2 (system disk) to disk c1t2d0s2, run the following commands: #metainit -f d11 1 1 c1t0d0s0 #metainit -f d12 1 1 c1t2d0s0 #metainit d10 -m d11 #metaroot d10 //The preceding two commands must be mounted on the root partitions. #lockfs -fa #metainit -f d21 1 1 c1t0d0s1 #metainit -f d22 1 1 c1t2d0s1 #metainit d20 -m d21 #metainit -f d31 1 1 c1t0d0s3 #metainit -f d32 1 1 c1t2d0s3 #metainit d30 -m d31 #metainit -f d41 1 1 c1t0d0s7 #metainit -f d42 1 1 c1t2d0s7 #metainit d40 -m d41 After entering the commands, modify the /etc/vfstab file that is shown as follows: #device device mount FS fsck mount mount #to mount to fsck point type pass at boot options # #/dev/dsk/c1d0s2 /dev/rdsk/c1d0s2 /usr ufs 1 yes fd - /dev/fd fd - no /proc - /proc proc - no /dev/dsk/c1t0d0s1 - - swap - no /dev/md/dsk/d10 /dev/md/rdsk/d10 / ufs 1 no /dev/dsk/c1t0d0s7 /dev/rdsk/c1t0d0s7 /export/home ufs 2 yes /dev/dsk/c1t0d0s3 /dev/rdsk/c1t0d0s3 /opt ufs 2 yes /dev/dsk/c1t1d0s6 /dev/rdsk/c1t1d0s6 /opt/n2000 ufs 2 yes /dev/dsk/c1t1d0s5 /dev/rdsk/c1t1d0s5 /opt/sybase ufs 2 yes swap - /tmp tmpfs - yes The /etc/vfstab file should be modified as follows: #device device mount FS fsck mount mount #to mount to fsck point type pass at boot options # #/dev/dsk/c1d0s2 /dev/rdsk/c1d0s2 /usr ufs 1 yes -
Confidential Information of Huawei. No Spreading without Permission
97
NGN Cases
Chapter 6 iManager N2000 BMS Cases fd - /dev/fd fd - no /proc - /proc proc - no /dev/md/dsk/d20 - - swap - no /dev/md/dsk/d10 /dev/md/rdsk/d10 / ufs 1 no /dev/md/dsk/d40 /dev/md/rdsk/d40 /export/home ufs 2 yes /dev/md/dsk/d30 /dev/md/rdsk/d30 /opt ufs 2 yes /dev/md/dsk/d60 /dev/md/rdsk/d60 /opt/n2000 ufs 2 yes /dev/md/dsk/d50 /dev/md/rdsk/d50 /opt/sybase ufs 2 yes swap - /tmp tmpfs - yes To restart the SUN server, run the following commands: #sync;sync;sync;sync # shutdown –y –g0 –i6 After the SUN server is started, you can start the N2000 BMS normally. To synchronize disk c1t0d0s2 and disk c1t2d0s2, run the following commands: #metattach d10 d12 #metattach d20 d22 #metattach d30 d32 #metattach d40 d42 After the preceding operations are performed, the third disk becomes the mirrored disk of the first disk and the fourth disk becomes the mirrored disk of the second disk.
Suggestions and Null Summary:
6.19 FAQ-How to Enable the SSH and SFTP Functi ons on Solari s 10 Title: ID: Update Time: Author: Product Family:
SE0000365202 2008-12-23 10:40:54 y59742 Access Network Management System
Fault Type:
Service Management
Keywords:
Solaris 10, SSH, SFTP
Phenomenon De scription:
Alarm Informat ion: Cause Analysi s: Handling Proce ss:
98
FAQ-How to Enable the SSH and SFTP Functions on Solaris 10
Product:
iManager N2000 BMS
Q: How to use SFTP to transfer files to the server after logging in to the server through the SSH on the N2000 BMS client? Null Null A: By default, Solaris 10 supports the SSH startup and configuration functions. You need to modify related items of the /etc/ssh/sshd_config configuration file and use the ssh-keygen file on the SSH to generate a key. After restarting the SSHD service, you can log in to the SSH and use SFTP to transfer files if you pass the password authentication. 1. To check whether the SSH and the SFTP services are running, run the following command: #ps -ef | grep sshd If a process ID is displayed, it indicates that the process is running. 2. Modify the following items in the /etc/ssh/sshd_config file: PermitRootLogin yes //allows users to log in to the SSH as user root PasswordAuthentication yes //uses the password authentication mode 3. To restart the SSH service of the server, run the following command: # ps -ef |grep sshd The following message is displayed: root- 9280---- 1- 0-- Aug 08 ?------- 0:01 /usr/local/sbin/sshd root 11179 10028- 0 17:31:02 pts/8--- 0:00 grep sshd
Confidential Information of Huawei. No Spreading without Permission
MSAN UA5000 Cases
Chapter 6 iManager N2000 BMS Cases
To kill the process, run the following command: #kill -9 9280 To query the process again, run the following command: # ps -ef |grep sshd The following message is displayed: root- 4557---- 1- 0-- Aug 08 ?------- 0:01 /usr/local/sbin/sshd root 10004 14442- 0 17:31:02 pts/8--- 0:00 grep sshd The process ID is different from the previous one. It indicates that the process is restarted. 4. You can use the SSH to log in to the server as user root on the client. Suggestions and Summary:
By default, the SSH service is enabled. To disable the SSH service, run the svcadm disable svc:/network/ssh:default command. If the SSH service is disabled, run the svcadm enable svc:/network/ssh:default command to enable it. If the SSH service is enabled, then the SFTP service is enabled by default. To modify the /etc/ssh/sshd_config file to disable the SFTP service, do as follows: Delete the Subsystem sftp /usr/lib/ssh/sftp-server line, save the file, and then exit. Then run the svcadm refresh svc:/network/ssh:default command. If the SSH service is enabled, but the SFTP service is disabled, you need to enable the SFTP service. To enable the SFTP service, do as follows: Add the Subsystem sftp /usr/lib/ssh/sftp-server line to the /etc/ssh/sshd_config file, save the file, and then exit. Then run the svcadm refresh svc:/network/ssh:default command.
6.20 FAQ-The TFTP conf igur ation on Solaris system Title: ID: Update Time: Author: Product Family:
FAQ-The TFTP configuration on Solaris system
SE0000398714 2009-06-26 14:56:49 Wu Ziyu Access Network Management System
Fault Type:
Service Management
Keywords:
TFTP
Phenomenon Des cription: Alarm Informati on: Cause Analysi s: Handling Proces s:
Product:
iManager N2000 BMS
Q: Solaris system, How to start/stop TFTP? How to modify the default path of TFTP server? Null Null A: 1. How to start TFTP server 1) Login path /etc , to check that whether there is a character "#" at the beginning of following sentence in the file named #vi inetd.conf ...... tftp dgram udp6 wait root /usr/sbin/in.tftpd in.tftpd -s /tftpboot ...... If there is the character, please delete it, save and quit. Above is for Solaris 8, for Solaris 10, the file's path is /etc/inet/inetd.conf. 2) For Solaris 8, please start it by following: #cd /etc/init.d #./inetsvc start 3) For Solaris 10, please start it by following: #svcadm enable svc:/network/tftp/udp6:default If you meet following error:
Confidential Information of Huawei. No Spreading without Permission
99