Chinese
English
What is the concept of HWECC
HWECC transmits the data of the HWECC protocol in the DCC, which is a private communication protocol developed by Huawei for DCN networking of optical network equipment, and is mainly used for the formation of DCNs between Huawei's transmission equipment.When planning for DCNs formed by using HWECC, in addition to following the basic planning principles, you must also follow the planning principles of the network element IDs, IPs, and network management network elements. Principle. When planning a DCN that uses HWECC, you need to follow the following basic principles: For a network that uses OptiX OSN series devices as gateways, each HWECC subnet should not have more than 200 network elements, and it is recommended that it not have more than 100. Each gateway network element should manage no more than 100 network elements, and it is recommended to manage up to 50 network elements.
Determine whether there are abnormal alarms and performance events
On the network management or use the alm-get-curdata command to query whether there are LOS, LOF, MSRDI, MSREI, and other alarms on the connected network elements with the off-pipe network elements; if there are optical path abnormal alarms such as problems with the optical path connection and the veneer boards, then exclude the relevant alarms first.
Check whether the cross board is in position and working normally, and ensure that the cross board is working normally.
If there are no abnormal alarms, check the performance of the network element to see if there is a large amount of data reported. If there are a large number of performance events reported, it is possible that the master control is unable to handle them, blocking the ECC channel, and it is necessary to investigate the root cause of the abnormal events reported.
Whether the signal rate level of the fiber directly connected to the optical board matches, for example, STM-1 and STM-4 cannot be docked, if there is a mismatch in the signal rate level, please solve it.
Check whether the DCN network size is too large.
Check the number of core routing tables:
Execute the command :cm-get-coreroute to query whether the number of core routing tables exceeds the number of DCN specifications.
If the DCN size is too large, you need to divide the DCN subnet and split it into multiple DCN subnets.
Note: For networks using OptiX OSN series devices as gateways, the maximum number of network elements per HWECC subnet should not exceed 200, and it is recommended not to exceed 100. Each gateway network element should not manage more than 100 network elements at most, and it is recommended to manage 50 network elements.
Determine whether the number of neighboring network elements exceeds the specification
Procedure
Queries how many neighboring network elements there are for the off-pipe network element:
Execute the command :cm-get-maccon to query how many neighboring network elements this network element has HWECC connections with:
:cm-get-maccon
MAC-CONNECT
dst-id board-id fiber-id mode scc-no
0x00a8001a 13 1 auto 26
0x00a8001b 12 1 auto 27
Total records :1
As above, there are two records indicating that the network element has 2 neighboring network elements for the HWECC protocol.
Compare the number of neighbors obtained from the query with the corresponding number of neighbors in the DCN specification list, if the actual value is greater than the specification value, the specification is exceeded. At this point, you need to connect the excess number of neighbors to other network elements to reduce the number of neighbors in this network element.
Note: Based on the fact that the DCN neighbor network elements (number of directions) of all network elements in the subnet do not exceed 10. if the number of DCN directions in the actual networking exceeds 10, it is recommended to close the DCN channels in some directions.
Determining whether there is a NEID conflict in the HWECC network
Close the DCN channel that connects the decontrolled network element to the upstream undecontrolled network element, and isolate the decontrolled network element from the DCN network.
Execute the command :cm-get-coreroute to query the core routing table:
Check whether routes to the decontrolled network elements still exist in the core routing table. If it still exists, a NEID conflict exists.
You can log in to the network element and modify its NEID to another value that does not conflict.
Try to see if you can log in to the offline network element through navigator. If navigator can already log in to the network element, but the network administrator still cannot log in, contact the network administrator to locate it.
Confirm that the HWECC DCNs at both ends of the DCN link are configured correctly.
Procedure
Execute the command :cm-get-maccon to query the MAC connection on the network element.
As shown in the figure above: the column DST-ID shows the IDs of the network elements that have established MAC connections with this network element. if you can find the NEID of the offline network element from it, it means that this network element has established MAC connections with the offline network element.
Explanation:
BOARD-ID indicates the board number where the channel of this device is located.
FIBER-ID indicates the port number where the channel of this device is located.
SCC-NO indicates the channel number of the channel of this device.
If there is no MAC connection, you need to determine whether the HWECC DCN configuration at both ends of the DCN link is correct.
The diagram of the ungateway network element decontrol is shown in the figure above. As shown in the figure. the de-regulated NE is the de-regulated network element and NE1 is the non-de-regulated network element. a DCC channel group is used between NE1 and the de-regulated network element. port 5-1 of NE1 is connected to port 6-1 of the de-regulated network element.
Execute :cm-get-newbdinfo on NE1 and the off-pipe network element respectively to query the configuration information of the corresponding channel, and the return result is as follows.
Explanation:
BID, PORT: Indicates the optical board information of the assigned channel, where the optical board number and the optical port number are counted from 1.
PORT-STATE: current optical port enable status. port-enable, port_disable, ECC communication is possible only when this optical port is port-enable.
DCC-TPYE: Rate and D byte used by the optical port.
LINK-CHAN: Channel number occupied by this optical port.
INIT-STACK: corresponds to the ECC protocol type.
CHAN-STATE: channel status. ok is send/receive normal, rx_f is receive failure, tx_f is transmit failure, rx_ns is receive unstable.
Follow the returned results to troubleshoot item by item, and the steps are as follows (take NE1 as an example):
Check whether the BID (optical board number) is 5 and whether the PORT (optical port number) is 1 in the command return.
The presence of 5 in the BID and 1 in the PORT indicates that the board is detected.
No, please make sure the board is firmly inserted, if not, then re-insert or replace the board.
If you still can't detect the single board, please check whether the mother board has inverted pins.
Check whether the optical port connected to the opposite end network element allows DCC access (i.e., whether the corresponding item PORT-STATE is enabled, if not, please set it to enable in the network management).
Check whether the use of D byte is consistent with that of the opposite end. If the D byte is not consistent, set it in the network management.
Check the channel number (LINK-CHAN) assigned to the query optical port, the optical port channel number is automatically assigned by the CPU. If it is 255, it means that the channel is not assigned, then try to solve the problem by unplugging, replacing the single board and resetting the master control, if it still can't be solved, please check whether the motherboard is inverted or not.
Check the status of the channel assigned to the optical port (CHAN-STATE): rx_f: reception failure; tx_f: transmission failure; rx_ns: unstable reception; Ok: normal sending and receiving.
Determine whether ECC routing is correct
Query the current routing information of the network element through :cm-get-eccroute, the command is shown as follows, assuming that the network element is connected as follows:A-B-C......H-J.
Check whether the route for network element J (that is, the destination network element, corresponding to the DST-ID) exists. If it exists, see if the forwarding network element (corresponding to DXC-ID) is B. If it is not (joined with network element T) and the LEVEL item is equal to 5 or 6 (the priority of manual route is 5 or 6), it means that the wrong manual route has been set up, please click the network element in the Network Element Manager, and then select "Communication > Network Element ECC Link Management" in the Function Tree to remove the wrong manual route. Please click the network element in the Network Element Manager and select "Communication > Network Element ECC Link Management" in the function tree to delete the wrong manual route.
Explanation:
DST-ID: Destination network element ID.
DXC-ID: Forwarding network element ID, the data from this network element to the destination network element must be sent to this network element first, and then forwarded by this network element. The network element identified by this item must be directly connected to this network element (or through a HUB or router, but no other network element in between).
DISTANCE: the distance (number of hops) between the path from this network element to the destination network element, there are n other network elements, the distance (hops) is n.
LEVEL: routing priority, automatic routing priority is 4, manual routing is 5 or 6.
MODE: manual route or automatic route (auto).
SCC-NO: to the destination network element to send through this channel, that is, the channel used to connect this network element and the network element identified by DXC-ID.
