Why does traffic forwarding fail when an S series switch is connected to another device through Eth-Trunk

9

After Eth-Trunk link aggregation is configured for an S series switch (except the S1700), the Eth-Trunk works in manual load balancing mode by default. If Eth-Trunk link aggregation is also configured for the peer device, the Eth-Trunk works in LACP mode by default. The two ends of the Eth-Trunk work in different default modes, resulting in forward traffic failure. To ensure normal traffic forwarding, you must configure the same working mode for the two ends.

Other related questions:
Why does traffic forwarding fail when the switch is connected to another device through an Eth-Trunk
After an Eth-Trunk is configured on the switch, the manual load balancing mode is adopted on the Eth-Trunk by default. If the device connected to the switch uses the static LACP mode after link aggregation is configured, the two devices use different working modes at two ends of the Eth-Trunk. As a result, traffic cannot be transmitted on the Eth-Trunk. To ensure traffic transmission on the Eth-Trunk, you need to set the same working mode on the two devices.

Traffic is not forwarded through all member interfaces of an Eth-Trunk in a stack. Why
When a stack device forwards traffic, an Eth-Trunk may select a member interface of another stack device through the hash algorithm, which occupies bandwidth resources between stack devices and reduces the traffic forwarding efficiency. To address the preceding problem, run the local-preference enable command to enable the Eth-Trunk to preferentially forward local traffic. That is, traffic arriving at the local device is preferentially forwarded through member interfaces of the local device. If the local device has no member interface, the member interface of another stack device is used to forward traffic. This saves bandwidth resources between stack devices and improves the traffic forwarding efficiency. By default, an Eth-Trunk is enabled to preferentially forward local traffic. Before configuring an Eth-Trunk to preferentially forward local traffic, ensure that the outbound bandwidth of Eth-Trunk member interfaces is sufficient for forwarding local traffic. If the outbound interface bandwidth is insufficient, some packets are dropped.

Does STP need to be configured when an interface on an S series switch that functions as an L3 interface is connected to another device
If an interface of an S series switch (except the S1700) functions as an L3 interface, disable STP on the interface. If the interface connects to terminals, configure the interface as an edge interface. To use this interface as an L2 interface after STP is disabled on this interface, enable STP again. Otherwise, loops cannot be prevented.

Why does an S series switch as a server fail to negotiate a Listening port with another device
For S series switches (except the S1700), the reason why a server fails to negotiate a Listening port with another device is as follows: The prerequisite for a server to negotiate a Listening port with another device is that the server receives a Hello message from the peer and finds that it is the destination server based on the transport address carried in the Hello message. Therefore, if the server does not negotiate a Listening port with another device, check whether the Hello message is received and check the transport address in the received Hello message.

If you have more questions, you can seek help from following ways:
To iKnow To Live Chat
Scroll to top