Why cannot STP work in the 30 seconds after an interface is Up

2

STP slow convergence is performed at an interval of 30 seconds. Check whether this problem is caused by STP slow convergence.

Other related questions:
Why cannot an Up interface be selected as the working interface
The reason is that this interface works in half duplex mode. On a switch, if the rate of an interface is the same as that of member interfaces in an Eth-Trunk, this interface can be added to the Eth-Trunk. However, if this interface works in half duplex mode, the Eth-Trunk will not select it as the working interface.

Why does BGP attempt to establish connections over 30 seconds after the peer is configured
Compared with IGP configuration, BGP configuration is more complex. In addition to the peer and AS, the egress, multi-hop, timer, and various capabilities need to be specified. Currently, BGP does not support dynamic capability negotiation. Therefore, these parameters, after being modified, need to be renegotiated. To avoid frequent interruptions during the renegotiation, a proper time parameter is required to ensure that the relevant configurations are complete before the link establishment attempt. RFC4271 recommends 120s, whereas 32s is adopted by switch.

Clients pass 802.1x authentication on an S series switch, and are disconnected after 10 seconds
For S series switches except S1700 switches, if handshake with online 802.1x users is enabled on a switch, the switch sends handshake packets to a client after the client is authenticated. If the client does not respond to the handshake packets, the switch forces the client offline. The client goes offline 10 seconds after it is authenticated. This may be caused by a handshake failure. In this case, run the undo dot1x handshake command in the system view to disable the handshake function.

Is it normal if the VRRP preemption delay configured on an AR router is different from actual delay
Is it normal if the VRRP preemption delay configured on an AR router is different from actual delay? It is normal. The backup-to-master conversion procedure for VRRP devices is as follows: Backup device: If the backup device receives packets with priority being 0 (lower than the priority of its own packets), the timer is set to Skew_time (offset time). If the packet priority is not 0, the packets are discarded and the backup device changes to the master state immediately. Master device: The master device sends VRRP advertisement packets regularly, and publicizes its configuration information (priority, for example) and working state in the VRRP group. Based on the VRRP packets, the backup device determines whether the master device works normally. - If the master device drops its master state (for example, it quits the backup group), it sends an advertisement packet with priority set to 0, to enable the backup device to change to the master state quickly without waiting for the timer specified by Master_Down_Interval to expire. This switchover time is referred to as the skew time, and is calculated based on the formula: �?56 - Backup device priority)/256 (unit: second). - If the master device encounters a network fault and cannot send an advertisement packet, the backup device will not know the status of the master device immediately and is notified of the fault until the timer specified by Master_Down_Interval expires. In this case, the backup device considers that the master device cannot work normally and switches over to the master state. The value of Master_Down_Interval is calculated based on the formula: 3 x Advertisement_Interval + Skew_time (unit: second). Note: In a performance-unstable network, network congestion may result in a backup device failure to receive packets from the master device within the time specified by Master_Down_Interval. In this case, the backup device will automatically switch over to the master state. If the packets from the master device arrive then, the device switches back to the backup state. This is likely to cause frequent switchover between VRRP devices. To relieve this phenomenon, a preemption delay can be configured to enable the backup device to wait for the preemption delay time after the timer specified by Master_Down_Interval expires. Before this relay time expires, the backup device will not switch over to the master state even if it does not receive an advertisement packet.

The state of an interconnected SA interface cannot be Up
Problem description: The state of the physical interface and protocol of the SA card cannot be Up. Serial1/0/0 current state: DOWN Line protocol current state: DOWN Description: HUAWEI, AR Series, Serial1/0/0 Interface Route Port,The Maximum Transmit Unit is 1500, Hold timer is 10(sec) Internet Address is 172.20.18.22/30 Link layer protocol is nonstandard HDLC Last physical up time : 2012-08-09 16:04:29 Last physical down time : 2012-08-09 16:04:29 Current system time: 2012-08-09 16:32:47 Physical layer is synchronous, Virtualbaudrate is 64000 bps Interface is DTE, Cable type is V24, Clock mode is TC Last 300 seconds input rate 0 bytes/sec 0 bits/sec 0 packets/sec Last 300 seconds output rate 0 bytes/sec 0 bits/sec 0 packets/sec Handling process: 1. If the peer end does not receive the signal, run the following command to set the transmit clock signal of the serial interface in inversion synchronization mode: [Huawei-Serial1/0/0]invert transmit-clock 2. If the local end does not receive the signal, run the following command to set the receive clock signal of the serial interface in inversion synchronization mode. [Huawei-Serial1/0/0]invert receive-clock Note: Clock signals of the serial interface in inversion synchronization mode can be configured only when AR3200 is used as a DTE device. After the preceding steps, most of the problems that the state of the SA interface is not Up can be resolved or filtered out. Root cause: The clock phases of the peer devices connected through the SA interface are not consistent.

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