DHCP Login Failure on a Base Station of a Vendor

Summary: An ATN device function as a DHCP relay agent, and base stations of two vendors are connected to different DHCP servers. A server or firewall discards packets sent by a base station of a specific vendor. As a result, users attached to the base station fail to get online. [Problem Description] Usage scenario: The login failure occurs only on a Layer 3 HVPN, not on a Layer 2+ Layer 3 L3VPN. Base stations of two or more vendors connected to the ATN device attempt to get online through different DHCP servers. Firewall rules are specified for private IP addresses on a wireless network management system (NMS) to drop packets with IP addresses that are not in the specified wireless network segment. Trigger conditions: The problem occurs if the following conditions are met: An HVPN is configured on an ATN device. Base stations of two or more vendors are connected to the ATN device. The base stations obtain IP addresses assigned by different DHCP servers. Firewall rules are specified for private IP addresses on at least one wireless NMS to drop packets with IP addresses that are not in the specified wireless network segment. Symptom: Users attached to a base station of a specific vendor can get online, and users attached to a base station of another vendor fail to get online. Identification method: Query the device version. Run the display version command in the user view. Check that DHCP relay is configured on an L3VPN interface.   Run the display interface GigabitEthernet 0/3/1.200 command in the user view.   In the preceding command, 0 indicates the slot number, 3 indicates the subcard number, 1 indicates the interface number, and 200 indicates the sub-interface number. Specify these figures based on real-world situations. Check that multiple L3VPN interfaces are configured on the ATN device. In addition, DHCP relay is enabled and different DHCP server IP addresses are specified on the interfaces.   Run the display interface GigabitEthernet 0/3/2.200 command in the user view. In the preceding command, 0 indicates the slot number, 3 indicates the subcard number, 2 indicates the interface number. and 200 indicates the sub-interface number. Specify these figures based on real-world situations. A DHCP login failure occurs Note that when users attached to a base station fail to get online using DHCP through an ATN device, the ATN device needs to be notified of the event from the wireless side. [Root Cause] No RFC defines which source IP address is added to a DHCP Request message to be forwarded by a DHCP relay agent. The ATN device automatically users the IP address of an outbound interface as the source IP address and adds it to a DHCP Request message in a VRF or native IP scenario. In an L3VPN scenario, an ATN device functioning as a DHCP relay agent sets the source IP address to the first valid private IP address in a VRF for all DHCP Request messages. The base station of each vendor is connected to a specific NMS that functions a DHCP server for the ATN device. NMS server hardware or firewall rules are specified for private IP addresses to drop packets with IP addresses that are not in the specified network segment. As a result, the DHCP Request message in which the source IP address should have been set to the second valid private IP address in a VRF carries the first valid private IP address in a VRF and therefore is dropped.… Read More »


NE Configuration Loss Due to Disabling of the Automatic and Periodic Database Backup Functions on MSTP Products

Summary:If the automatic and periodic database backup functions of an MSTP NE are disabled, NE configurations may be lost after the system control board is warm or cold reset, active and standby system control boards switch over, or the NE is restarted. [Problem Description] Trigger conditions: This problem occurs if the following conditions are met: Automatic and periodic database backup functions of the NE are disabled. After automatic and periodic database backup functions of the NE are disabled, modifications such as service configuration or ASON rerouting are made to the NE. The system control board is warm or cold reset, active and standby system control boards switch over, or the NE is restarted. Fault symptoms: After the system control board is warm or cold rest or active and standby system control boards switch over, some configurations modified after automatic and periodic database backup functions of the NE are disabled may be lost. In this case, a service board reset will result in complete or incomplete service interruption. After the NE is restarted, some configurations modified after automatic and periodic database backup functions of the NE are disabled may be lost, resulting in complete or incomplete service interruption. Identification method: This problem can be identified using the inspection tool or commands. Problem identification using the inspection tool For OptiX OSN 5X0 (except OptiX OSN 580) of versions earlier than V100R006C00, OptiX OSN 2000, OptiX OSN 1500/2500/2500REG/3500/3500II/3580/7500/7500II of V100R010 and TDM versions earlier than V100R010, OptiX OSN 9500, and OptiX OSN 9560, run the check item selected in the following figure. For OptiX OSN 5X0 (except OptiX OSN 580) of V100R006C00 and later versions, and OptiX OSN 1500/2500/2500REG/3500/3500II/3580/7500/7500II of V100R009C03, V200R011, and packet versions later than V200R011, run the check item selected in the following figure.   For OptiX OSN 580, run the check item selected in the following figure. For OptiX Metro 1000 V300, run the check item selected in the following figure. For OptiX Metro 3000, run the check item selected in the following figure.     If the check results meet the analysis result shown in the following figure, the automatic and periodic database backup functions are disabled.   Problem identification using commands Whether automatic and periodic database backup functions are enabled cannot be queried using the NMS. Periodic database backup Run the :dbms-get-cyclebackup command. If the returned result is disable, periodic database backup is disabled. The following figure shows an example.     Automatic database backup Run the :dbms-get-autobackup command. If the returned result is disable, automatic database backup is disabled. The following figure shows an example.   [Root Cause] After automatic and periodic database backup functions of the NE are disabled, new configurations or configuration modifications cannot be saved to the database.… Read More »

How to Troubleshoot Synchronous Ethernet Clocks For Huawei SDH

OptiX OSN 7500 II/7500/ OptiX OSN 3500/ OptiX OSN 1500 Troubleshooting: How to Troubleshoot Synchronous Ethernet Clocks The common faults regarding the synchronous Ethernet clock are as follows: A clock source cannot be properly switched and the quality of clock is low. Possible Causes l The connection at the port fails. l An alarm associated with the synchronous Ethernet clock function occurs on the network. Figure 1 Flow chart for handling a synchronous Ethernet clock fault   Procedure Step 1 Cause 1: The connection at the port fails. 1. Check whether the ETH_LOS or ETH_LINK_DOWN alarm occurs at the port. 2. If yes, clear the alarm and then check whether the fault is rectified. For details on how to clear the alarm, see the Alarms and Performance Events Reference. Step 2 Cause 2: An alarm associated with the synchronous Ethernet clock occurs on the network. 1. Check whether any alarm associated with the synchronous Ethernet clock occurs on the network. For details, see Relevant Alarms. 2. If yes, clear the alarm. For details on how to clear the alarm, see the Alarms and Performance Events Reference. Step 3 If the fault persists, contact Huawei technical support engineers to handle the fault. —-End

Electrical-Layer ASON Service Failures upon the Interconnections of New- and Old-Model Boards on ASON Networks of WDM Products

Summary: After new boards are added on an electrical-layer ASON network or a static network is upgraded to an electrical-layer ASON network, ASON services fail to use OCh trail resources if the board models on two ends of the OCh trail are different, for example, one end uses old boards or old board models such as TN54NS2 or TN53NS2(COMP) and the other end uses new board modules such as TN53NS2 (STND). Consequently, operations such as creating, optimizing, rerouting, and reverting electrical-layer ASON services and upgrading static services fail. Product Line: Transport network product line    Product Family: WDM products Product Model: OptiX OSN 6800, Optix OSN 8800   Keywords: ASON network   [Problem Description] Trigger conditions: One end of an OCh trail on an electrical-layer ASON network uses old boards or old board models and the other end uses new board models. Symptom: Operations such as creating, optimizing, rerouting, and reverting electrical-layer ASON services and upgrading static services fail. An OTU_TEL_MM alarm is reported. Identification method: The problem occurs if either of the following conditions is met: An OTU_TEL_MM alarm is reported on the network. One end of an OCh trail uses old boards or old board models and the other end uses new board models. You can check the OCh trail configuration as follows: Export a board list from the U2000 and save it. The following figure shows the export path on the U2000.     Open the WDM trail management window, and search for the OCh trails whose Level is OCh. In the exported board list, check each OCh trail based on the slot numbers, and determine whether the source and sink OTU board models at the two ends of the OCh trail are the same. If the models of the source and sink OTU boards are different, for example, the model at one end is TN54NS2 or TN53NS2 (COMP) and at the other end is TN53NS2 (STND), the problem is prone to occur.     [Root Cause] For electrical-layer ASON services, the links with inconsistent configurations at the two ends (for example,the board model at one end is old and at the other end is new) will be filtered out during intelligent trail search.   [Impact and Risk] Creating, optimizing, rerouting, and reverting electrical-layer ASON services fail. In addition, upgrading static services also fails.   [Measures and Solutions] Recovery measures: Apply for a maintenance window. Record information about all the services on the OCh trail, and switch these services. (For ASON services, optimize them. For non-ASON services, switch them in SNCP mode.) Record and then delete the fiber connections of the OTU boards. Remove the logical boards for the OTU boards. Change the board models at the two ends of the OCh trail to the same. If both ends support the STND mode,… Read More »

MA5600T Reset Problem Triggered by ping -v

Summary: A running MA5600T may reset after the ping -v command is executed. Sub-Product Line: Access network    Product Family: Optical access [Problem Description] Trigger conditions: The gateway returns an ICMP Destination Unreachable message after the ping -v IP address command is executed on an MA5600T. Fault symptom: The program instruction is abnormal and the MA5600T resets. See the following example: MA5600T(config)#ping -v PING 56  data bytes, press CTRL_C to break   ======================== Exception Info Begin ========================   Exception Time       : 2011-02-10  16:26:51 Exception VosTick    : 10636031 Exception CpuTick    : 0×00000674 8b463a54 Exception Type       : PROGRAM EXCEPTION Exception Vector Num : 0×700 Exception Task       : Co0 (ID = 98, OsalID = 0x783c020) Exception PID        : -1 Exception CPUID      : -1 Dopra Version        : DOPRA V100R006C08SPC070 Application Version  : UnConfig   Task Stack Base      : 0×7914000 Task Stack End       : 0x790a000 Task Stack Max Size  : 0xa000 Task Stack Cur Size  : 0 Task Stack High      : 0x2d10 Task Stack Margin   : 0x72f0 Identification method: The MA5600T resets immediately the ping -v IP address command is executed. [Root Cause] ping -v requires the domain name server (DNS) to parse the domain name corresponding to the IP address of the ICMP Destination Unreachable message returned. During the domain name parsing, the hook function is not associated. As a result, the MA5600T invokes an empty hook function, causing a system reset. [Impact and Risks] All services of the reset MA5600T will be interrupted and the configurations that are not saved before the reset will be lost. [Measures and Solutions] Recovery measures: N/A Workarounds: Do not add the parameter -v when running a ping command. Solutions: The problem will be resolved in the following commercial patches: V800R006C02SPC124, to be released at the end of March 2011 V800R007C00SPC313, to be released at the end of March 2011 V800R008C01SPC104, to be released at the end of April 2011 [Rectification Scope and Time Requirements] N/A [Notice Expiration] This notice automatically expires after related patches are loaded.

The IN_PWR_HIGH Alarm Indicating Source Optical Module Faults

Summary: An OTU board reports the IN_PWR_HIGH alarm indicating that a resistor fails in the Source optical module. Constantly reporting the alarm does not affect services, but is perceivable. Product Line: Transport                     Product Family: WDM Product Model:  OptiX OSN 1800 OptiX OSN 6800 OptiX Metro 6100 [Problem Description] Trigger conditions: There is a low probability that an OTU board reports the IN_PWR_HIGH alarm after it has been running with an 80-km CWDM Source optical module for over a year. Symptom: An OTU board reports the IN_PWR_HIGH alarm while services are running properly. The maximum receive optical power is –7.x dBm, where x is a digit. Identification method: Verify that the following conditions are met: The OTU board is installed on the OptiX OSN 1800, OptiX Metro 6100, or OptiX OSN 6800. The model type of the optical module on the OTU board contains the “6128C-SL80″ or “6128C-L80″ field. The model type of the optical module can be determined by viewing the manufacturing information. Figure 1 shows the manufacturing information of an example optical module with the Navigator Command (cfg-get-bdinfo:),. Manufacturing information of an example optical module The model type of the optical module with blue label is 6128C-SL8055G, which contains the “6128C-SL80″ field. [Root Cause] A resistor fails in the 80-km CWDM Source optical module. This increases the resistance from 3000 ohm to over 1000,000 ohm and the voltage to the saturation voltage. As a result, the receive optical power exceeds the specified threshold.   [Impact and Risk] This issue may occur on the equipment in and outside China. Constantly reporting the alarm does not affect services, but is perceivable.   [Measures and Solutions] Recovery measures: N/A Workarounds: Replace the optical module. Preventive measures: Replace the optical module. Optical modules provided by Source Photonics are CWDM optical modules, which correspond to eight BOM numbers. The following table describes the mapping between the BOM numbers and wavelengths. Material handling after replacement: The replaced optical module is scrapped.   [Rectification Scope and Time Requirements] N/A

Packet Loss or Bit Errors on an IP RAN-20120401-A

Abstract: When packet loss or bit errors occur on an IP RAN, alarms are reported but no protection switching is triggered. Sub-product Line: Network Solutions Dept.   Product Type: ATN 910/950, CX600 series   [Problem Description] On the wireless base stations: 3G base stations become unreachable to the NMS and some E1 channels are unavailable on 2G base stations. At the same time, On the IP RAN: alarms indicating abnormal optical power and CRC bit error threshold-crossing are reported, and BFD status jitters occur. Trigger conditions: This problem occurs in either of the following conditions: On the IP RAN, packet loss occurs on links or bit errors occur on optical ports. Packet loss or bit errors occur on an ME network or WDM network that the IP RAN traverses. Fault symptoms: On the wireless base stations: The voice service quality decreases (the call drop rate increases), some E1 channels are unavailable, and base stations become unreachable to the NMS (especially when management channels are provided by TDM ports). On the IP RAN: alarms indicating abnormal optical power(optical module errors) and CRC bit error threshold-crossing(CRC error alarm notification) are reported, and BFD status jitters occur. Judgment methods: This problem occurs if alarms indicating abnormal optical power and CRC bit error threshold-crossing are reported, and BFD status jitters occur. [Root Cause] On the ATN/CX600, alarms related to bit errors or packet loss are reported but do not trigger protection switching. [Impact and Risks] On the wireless base stations: The voice service quality decreases (the call drop rate increases), some E1 channels are unavailable, and base stations become unreachable to the NMS (especially when management channels are provided by TDM ports). [Measures and Solutions] Recovery Measure: When the protection link is functional, disable the faulty port on the working link to trigger protection switching. Solution: Protection against packet loss (based on end-to-end detection) and protection against port bit errors (based on port detection) will be provided in ATN/CX600 versions to be released in 2012Q2.

Flash Space Exhaustion Caused by a License Defect-20120207-A

Summary: When an OptiX PTN 950 NE is configured with two system control boards (active and standby), the license modules on the system control boards accumulate the board debugging information. The accumulated debugging information exhausts the space of the flash memory, leading to a failure to save the configuration data and back up the NE database. Product Family: PTN                                                  Product Model: OptiX PTN 950 [Problem Description] Trigger conditions: The OptiX PTN 950 NE uses two system control boards which run the V100R002C01SPC100 NE software.   Symptom: The standby system control board exhausts the flash memory space at a speed two times faster than the active system control board. Therefore, the fault first occurs on the standby system control board. During the periodical backup of the NE database, if the flash memory has insufficient free space, the system control board reports a DBMS_ERROR alarm. And also lead to memory leaks, if the memory leak reaches the threshold, then reported MEM_OVER alarm. Incremental files are generated when configuration data is delivered or when dynamic services are configured. If the flash space becomes insufficient during the process of generating incremental files, the system control board may fail to generate these incremental files. When this occurs, the NE is reset. During an NE upgrade, when the NE detects that the free space on the flash memory is insufficient to save the new software, the NE upgrade fails.… Read More »

Some Abnormal OLT GPON CLASS B+ Optical Modules at High Temperature- 20130627-A

Abstract: Some OLT GPON CLASS B+ optical modules provided by SOURCE PHOTONICS may rarely become faulty after long-term working at high temperature, resulting in unstable transmit optical power, and ONUs being offline. Product Line: Access network             Product Family: OLT Product Model: MA5600T, MA5603T, MA5680T, and MA5683T [Problem Description] Trigger conditions: Optical modules have been working at the temperature higher than 60 degrees for a long term. Optical modules are OLT GPON CLASS B+ optical modules of the SPS4348HHPCDE model provided by SOURCE PHOTONICS. When the above conditions are met, 0.143% of the optical modules may have unstable transmit optical power, resulting in offline ONUs. Symptoms: Optical modules have unstable transmit optical power, resulting in offline ONUs. Identification methods: Method 1 If the ONU that connects to the PON port on a GPBD board is offline, perform the following steps to check whether the cause is the involved optical module in the warning. Check whether the optical module is working at high temperature and belongs to the SPS4348HHPCDE model. Run the command to check whether the optical module has been working at high temperature for a long term. Temperature(C)         60    —-Enclosure temperature of the involved optical module in the warning exceeds 60 degrees. Run the command or query the label on the top side of the optical module to check whether the optical module is the SPS4348HHPCDE model. Query using the command Related optical module information in the query result is as follows: Vendor PN            SPS4348HHPCDE       —-involved vendor PN Vendor name          SOURCEPHOTONICS     —-involved vendor name Query the label on the top side of the optical module. The involved information is in red blocks on the label on the top side of the optical module, as shown in Figure 1. Label on the top side of the optical module   Check whether the optical module is the involved optical module in the warning based on the transmit optical power. If the transmit optical power not in the range from 1.5 dBm to 5 dBm after multiple queries (using commands), the optical module is the involved optical module in the warning. TX power(dBm)                -10.61    —-The transmit optical power of the involved optical module is generally less than 1.5 dBm and a negative number. Query command: :display port state [ponid] MA5600T(config)#interface gpon 0/2… Read More »

Precaution About PTN3900&3900-8&PTN1900&PTN960&PTN950&PTN910 Service Interruption Caused by VPLS Loop Configuration-20130829-A

Abstract: When deploying VPLS service, E-LAN loop will cause broadcast storm, MAC address flapping, at last it cause service interruption. Product Line: Carrier IP                       Product Family: PTN Product Model: PTN3900&3900-8&PTN1900&PTN960&PTN950&PTN910 Trigger conditions: When Deploying VPLS services, we must avoid loop, such as PW , UNI interface and external device. PW logical loop in a single VPLS. When two parallel homologous and homoclinic PWs are added into VPLS without Split Horizon Group configured, it will certainly cause a loop.     Loop is generated by VPLS and other service or other device.   VPLS UNI loopback. For example, when two UNI connects to each other, or go to the same switch/OLT ELAN, or port loopback, loop will be generated.   Fault appearance: When a large amount of broadcast traffic occurs on link of VPLS, causing broadcast storm, link congestion, or MAC address flapping and finally cause service interruption.   Judgment method: Where the link of VPLS goes far beyond the usual flow of broadcast packets. In normal situation, broadcast and multicast traffic are relatively low. When the problem happens, you can see lots broadcast traffic through the port RMON performance, such as 1MB or more on FE. Checking method is as the figure below.     Traffic congestion occurs. Alarm like FLOW_OVER, ETH_TX_FLOW_OVER, ETH_RX_FLOW_OVER ETH etc are reported MAC address flapping appears. PW or UNI learn the wrong MAC address. When continue query the MAC address self-learning table, it can be found that a MAC address learned from different interface (PW/UNI) from time to time.   Root Cause: When loop is generated in VPLS, the broadcast traffic will be numerously copied and cause broadcast storm. Meanwhile, it will cause MAC address flapping. Impact and Risk: Broadcast storm will generate congestion on link and cause other service interruption, MAC address flapping will affects the service itself