2025-01-26 0

Huawei Switches-FAQ

Featured Image
FAQ Switch

1.How to confirm which switch the console is connected to when using stacked switches

Problem description

In a stacked scenario, how to confirm which switch the console is connected to when using multiple switches?

Solution

  1. Check the master and standby lights (MST lights)

For frame switches, the console port is connected to the main control board, which will have an ACT status light. Take a dual-control board dual-machine cluster as an example. The one that is always on is the main control board of the main device

The one that flashes slowly is the main control board of the backup device

The one that is not on is the backup control board of each device.

For box switches, there is also an ACT indicator on the left side of the switch, and the one that is always on is the main device.

  1. Check the interface with dis int brief and judge based on the actual wiring situation.
  2. Check the dis esn with the device sn number.

 

2.S6730Eth-trunk configuration error

Huawei S6736 and S9303 interfaces cannot negotiate

Problem description

Huawei S6736 and S9303 devices are connected. S6736 uses a 10G port to insert a Gigabit single-mode module, and S9303 uses a Gigabit port to insert a Gigabit single-mode module.

Alarm information

G1/0/0 port on the S6736 side is UP, the transmit and receive signals are normal, the eth-trunk protocol is normal, and the peer end cannot be pinged

Handling process.

Check the transmit and receive signals on the S6736, and they are all within the normal range. The LACP configurations at both ends are consistent, and the eth-trunk protocol is normal; check the ARP table entries, and find that there is no ARP table entry for the peer end, only a temporary table exists, which cannot be used for communication; turn off the auto-negotiation of the S6736, but communication still cannot be normal; turn off the auto-negotiation of the peer S9303, and communication can be normal after turning it off, and the ARP table entries are normal.

 

Root cause

The S67 series exchange uses a Gigabit module to automatically turn off auto-negotiation on the 10G port, and the peer device needs to turn off auto-negotiation synchronously.

Solution

  1. Check whether the transmission and reception are normal;
  2. Check whether the LACP configurations at both ends are consistent;
  3. Check whether the eth-trunk protocol is normal;
  4. Check the ARP table entries;

To sum up, the above check results locate the problem and confirm the solution according to the problem (auto-negotiation is turned off at both ends)

Suggestions and summary.

The S67 series switches use the Gigabit module to automatically turn off auto-negotiation on the 10G port, and the opposite device needs to turn off auto-negotiation synchronously.

Similarly, if other CE/S series switches encounter such problems in the future, they can follow the above ideas to troubleshoot and try to solve them.

 

The default route of the egress switch uplink is down and does not fail

This scenario is the network egress area of the HCS data center. The OSPF protocol runs between the egress switch and the egress firewall. The egress firewall configures the cloud summary network segment route to point to the cloud core switch and introduces it to OSPF. The egress switch configures the default route to point to the external egress router and issues the default route in the OSPF domain through the default-route advertise command.

In the normal scenario, when the uplink of the main egress switch fails, the traffic in the cloud reaches the main egress switch through the main firewall. Due to the failure of the uplink of the main egress switch, the next hop of the default route is unreachable and the route is not added to the table. The OSPF default route issued by the standby egress switch will be learned through the escape link interconnected with the standby egress switch, and the traffic will be forwarded to the standby egress switch.

Failure scenario: When the uplink of the main egress switch fails, the traffic in the cloud cannot go out. After the tracert command is used to trace the path, it is found that the data packet forms a loop between the main egress firewall and the main egress switch.

Processing process

In the failure scenario, when the uplink of the main egress switch fails, the traffic in the cloud cannot go out. After the tracert command is used to trace the path, it is found that the data packet forms a loop between the main egress firewall and the main egress switch.

After querying the routing table of the main egress switch, it was found that the default route was not invalid and the next hop was still reachable. When the dis ip routing-table x.x.x.x command was used to query the next hop matching route, it was found that the next hop address had undergone routing iteration. The iterated route was the summary route pointing to the cloud learned by the main egress firewall, resulting in the egress default route not being invalid. The data packet formed a loop between the main egress firewall and the main egress switch. After querying, it was found that the firewall pointed to the summary network segment in the cloud and included the device Internet segment, causing the failure phenomenon.

 

Root cause

The firewall pointed to the summary network segment in the cloud and included the device Internet segment, resulting in the egress switch uplink link down, and the default route next hop was routed iteratively and not invalid.

Solution

Solution 1: Configure BFD for the default route of the egress switch to detect the next hop;

Solution 2: The egress firewall points to the summary network segment in the cloud and excludes the device Internet segment.