PAgP has 2 modes: auto (passive) and desirable (active).
LACP has modes active and passive
In active/desirable switch actively trying to form etherchannel and in auto/passive mode switch waits for the other side to negotiate.
If PAgP configured for a silent auto mode, the link will eventually come up (after bundling it to a port-channel) even without device configured for an etherchannel on the other end of the link. However, the link won't join Port-channel. It will be up, but not as a part of a channel. If the link was configured with silent desirable mode, it will form a channel without hearing any PAgP packet from the opposite side. It allows to form a channel with not a PAgP capable devices like servers etc.
If non-silent command was configured in Switch(config-if)# channel-group number mode {on | {{auto | desirable} [non-silent]}} then it will be required for each port to receive PAgP packets before adding them to a channel. If PAgP isn’t heard on an active port, the port remains in the up state, but PAgP reports to the Spanning Tree Protocol (STP) that the port is down.
If show commands, then show ETHERCHANNEL
If interface command, then int PORT-CHANNEL
If configuration commands, then CHANNEL-XXXX
Spanning Tree Protocol
Catalyst switches offer the PortFast feature, which shortens the Listening and Learning states to a negligible amount of time. When a workstation link comes up, the switch immediately moves the PortFast port into the Forwarding state. Spanning-tree loop detection is still in operation, however, and the port moves into the Blocking state if a loop is ever detected on the port. We can configure PortFast as a global default, affecting all switch ports with a single command. All ports that are configured for access mode (nontrunking) will have PortFast automatically enabled.
The UplinkFast feature on Catalyst switches enables leaf-node switches or switches at the ends of the spanning-tree branches to have a functioning root port while keeping one or more redundant or potential root ports in Blocking mode. When the primary root port uplink fails, another blocked uplink immediately can be brought up for use. UplinkFast works by keeping track of possible paths to the root bridge. Therefore, the command is not allowed on the root bridge switch. The goal is to keep UplinkFast limited to leaf-node switches that are farthest from the root. First, the switch’s bridge priority is raised to 49,152, making it unlikely that the switch will be elected to root bridge status. The port cost of all local switch ports is incremented by 3000, making the ports undesirable as paths to the root for any downstream switches.
When an uplink on a switch goes down, UplinkFast makes it easy for the local switch to update its bridging table of MAC addresses to point to the new uplink. However, UplinkFast also provides a mechanism for the local switch to notify other upstream switches that stations downstream (or within the access layer) can be reached over the newly activated uplink. The switch accomplishes this by sending dummy multicast frames to destination 0100.0ccd.cdcd on behalf of the stations contained in its Content-Addressable Memory (CAM) table. The MAC addresses are used as the source addresses in the dummy frames, as if the stations actually had sent them. The idea is to quickly send the multicast frames over the new uplink, giving upstream hosts a chance to receive the frames and learn of the new path to those source addresses.
BackboneFast works by having a switch actively determine whether alternative paths exist to the root bridge, in case the switch detects an indirect link failure. A switch detects an indirect link failure when it receives inferior BPDUs from its designated bridge on either its root port or a blocked port.
Normally, a switch must wait for the Max Age timer to expire before responding to the inferior BPDUs. However, BackboneFast begins to determine whether other alternative paths to the root bridge exist according to the following port types that received the inferior BPDU:
■ If the inferior BPDU arrives on a port in the Blocking state, the switch considers the root port and all other blocked ports to be alternative paths to the root bridge.
■ If the inferior BPDU arrives on the root port itself, the switch considers all blocked ports to be alternative paths to the root bridge.
■ If the inferior BPDU arrives on the root port and no ports are blocked, however, the switch assumes that it has lost connectivity with the root bridge. In this case, the switch assumes that it has become the root bridge, and BackboneFast allows it to do so before the Max Age timer expires.
If the local switch has blocked ports, BackboneFast begins to use the Root Link Query (RLQ) protocol to see whether upstream switches have stable connections to the root bridge. First, RLQRequests are sent out. If a switch receives an RLQRequest and either is the root bridge or has lost connection to the root, it sends an RLQ Reply. Otherwise, the RLQ Request is propagated on to other switches until an RLQ Reply can be generated. On the local switch, if an RLQ Reply is received on its current root port, the path to the root bridge is intact and stable. If it is received on a nonroot port, an alternative root path must be chosen. The Max Age timer immediately is expired so that a new root port can be found. BackboneFast is simple to configure and operates by short-circuiting the Max Age timer when needed. Although this function shortens the time a switch waits to detect a root path failure, ports still must go through full-length Forward Delay timer intervals during the Listening and Learning states.
When used, BackboneFast should be enabled on all switches in the network because BackboneFast requires the use of the RLQ Request and Reply mechanism to inform switches of Root Path stability.
Root Guard
The Root Guard feature was developed as a means to control where candidate root bridges can be connected and found on a network. Basically, a switch learns the current root bridge’s bridge ID. If another switch advertises a superior BPDU, or one with a better bridge ID, on a port where Root Guard is enabled, the local switch will not allow the new switch to become the root. As long as the superior BPDUs are being received on the port, the port will be kept in the root-inconsistent STP state.When the superior BPDUs no longer are received, the port is cycled through the normal STP states to return to normal use.
BPDU Guard should be used along with PortFast feature, to prevent inadvertent connection of bridging devices to an access port. However, BPDU Guard won't prevent loops, if non-STP capable device is connected to a port. BPDU Guard feature puts port to a err-disable state, if BPDU is received on a port.
The UplinkFast feature on Catalyst switches enables leaf-node switches or switches at the ends of the spanning-tree branches to have a functioning root port while keeping one or more redundant or potential root ports in Blocking mode. When the primary root port uplink fails, another blocked uplink immediately can be brought up for use. UplinkFast works by keeping track of possible paths to the root bridge. Therefore, the command is not allowed on the root bridge switch. The goal is to keep UplinkFast limited to leaf-node switches that are farthest from the root. First, the switch’s bridge priority is raised to 49,152, making it unlikely that the switch will be elected to root bridge status. The port cost of all local switch ports is incremented by 3000, making the ports undesirable as paths to the root for any downstream switches.
When an uplink on a switch goes down, UplinkFast makes it easy for the local switch to update its bridging table of MAC addresses to point to the new uplink. However, UplinkFast also provides a mechanism for the local switch to notify other upstream switches that stations downstream (or within the access layer) can be reached over the newly activated uplink. The switch accomplishes this by sending dummy multicast frames to destination 0100.0ccd.cdcd on behalf of the stations contained in its Content-Addressable Memory (CAM) table. The MAC addresses are used as the source addresses in the dummy frames, as if the stations actually had sent them. The idea is to quickly send the multicast frames over the new uplink, giving upstream hosts a chance to receive the frames and learn of the new path to those source addresses.
BackboneFast works by having a switch actively determine whether alternative paths exist to the root bridge, in case the switch detects an indirect link failure. A switch detects an indirect link failure when it receives inferior BPDUs from its designated bridge on either its root port or a blocked port.
Normally, a switch must wait for the Max Age timer to expire before responding to the inferior BPDUs. However, BackboneFast begins to determine whether other alternative paths to the root bridge exist according to the following port types that received the inferior BPDU:
■ If the inferior BPDU arrives on a port in the Blocking state, the switch considers the root port and all other blocked ports to be alternative paths to the root bridge.
■ If the inferior BPDU arrives on the root port itself, the switch considers all blocked ports to be alternative paths to the root bridge.
■ If the inferior BPDU arrives on the root port and no ports are blocked, however, the switch assumes that it has lost connectivity with the root bridge. In this case, the switch assumes that it has become the root bridge, and BackboneFast allows it to do so before the Max Age timer expires.
If the local switch has blocked ports, BackboneFast begins to use the Root Link Query (RLQ) protocol to see whether upstream switches have stable connections to the root bridge. First, RLQRequests are sent out. If a switch receives an RLQRequest and either is the root bridge or has lost connection to the root, it sends an RLQ Reply. Otherwise, the RLQ Request is propagated on to other switches until an RLQ Reply can be generated. On the local switch, if an RLQ Reply is received on its current root port, the path to the root bridge is intact and stable. If it is received on a nonroot port, an alternative root path must be chosen. The Max Age timer immediately is expired so that a new root port can be found. BackboneFast is simple to configure and operates by short-circuiting the Max Age timer when needed. Although this function shortens the time a switch waits to detect a root path failure, ports still must go through full-length Forward Delay timer intervals during the Listening and Learning states.
When used, BackboneFast should be enabled on all switches in the network because BackboneFast requires the use of the RLQ Request and Reply mechanism to inform switches of Root Path stability.
Root Guard
The Root Guard feature was developed as a means to control where candidate root bridges can be connected and found on a network. Basically, a switch learns the current root bridge’s bridge ID. If another switch advertises a superior BPDU, or one with a better bridge ID, on a port where Root Guard is enabled, the local switch will not allow the new switch to become the root. As long as the superior BPDUs are being received on the port, the port will be kept in the root-inconsistent STP state.When the superior BPDUs no longer are received, the port is cycled through the normal STP states to return to normal use.
BPDU Guard should be used along with PortFast feature, to prevent inadvertent connection of bridging devices to an access port. However, BPDU Guard won't prevent loops, if non-STP capable device is connected to a port. BPDU Guard feature puts port to a err-disable state, if BPDU is received on a port.
Why is it so terrifying to get a bridge or switch on a Portfast enabled port? It is because port will transition from a blocking to a forwarding state without any delay (forward delay, max age etc), so a bridging loop might occur. That's why Portfast enabled ports should be "guarded" by a BPDU Guard feature (Guard enables on a port as soon as Portfast is enabled). When the BPDUs no longer are received, the port still remains in the errdisable state.
UDLD and LoopGuard. Suppose, the switch port is in Blocking state and it receives BPDU's from a designated port on a segment. If, BPDU's stop arrive, then switch assumes, that there is no STP device on that segment (like PC is connected), so it can safely move it to Forwarding state and make it designated on this segment. However, suppose, that something filtering BPDU's on their way to the switch, but there is still a device actively sending them on the opposite side of the link. This means, that switch should NOT transit port from a blocking to a forwarding state, however it will happen if LoopGuard feature isn't enabled on this port.
When enabled, LoopGuard keeps track of the BPDU activity on nondesignated ports. This feature will move port to a loop-inconsistent state if BPDU's go missing (effectively preventing loops to occur). After BPDU's are received on a port again, Loop Guard allows to port to move through the normal STP states and become active.
UDLD works like pings on fiber-optic links where link can become partly damaged and become unidirectional. So on the one side switch could stop to receive BPDU's, however it can send data across the link. A unidirectional link poses a potential danger to STP topologies because BPDUs will not be received on one end of the link. If that end of the link normally would be in the Blocking state, it will not be that way for long. A switch interprets the absence of BPDUs to mean that the port can be moved safely through the STP states so that traffic can be forwarded. However, if that is done on a unidirectional link, a bridging loop forms and the switch never realizes the mistake.
The objective behind UDLD is to detect a unidirectional link condition before STP has time to move a blocked port into the Forwarding state. To do this, the target time must be less than the Max Age timer plus two intervals of the Forward Delay timer, or 50 seconds. UDLD can detect a unidirectional link after about three times the UDLD message interval (45 seconds total, using the default). If none of those messages is echoed back, the port is placed in the Errdisable state so that it cannot be used (in case of aggressive mode, otherwise syslog message is generated).
HSRP/VRRP/GLBP
HSRP. Only the standby (the one with the second-highest priority) router monitors the hello messages from the active router.
HSRP mac address 0000.0c07.acxx, where xx represents the HSRP group number as a two-digit hex value. HSRP sends its hello messages to the multicast destination 224.0.0.2 (“all routers”) using UDP port 1985. Priority and group numbers:
GLBP MAC addresses always have the form 0007.b4xx.xxyy. The 16-bit value denoted by xx.xx represents six zero bits followed by a 10-bit GLBP group number. The 8-bit yy value is the virtual forwarder number. Priority and group numbers
UDLD and LoopGuard. Suppose, the switch port is in Blocking state and it receives BPDU's from a designated port on a segment. If, BPDU's stop arrive, then switch assumes, that there is no STP device on that segment (like PC is connected), so it can safely move it to Forwarding state and make it designated on this segment. However, suppose, that something filtering BPDU's on their way to the switch, but there is still a device actively sending them on the opposite side of the link. This means, that switch should NOT transit port from a blocking to a forwarding state, however it will happen if LoopGuard feature isn't enabled on this port.
When enabled, LoopGuard keeps track of the BPDU activity on nondesignated ports. This feature will move port to a loop-inconsistent state if BPDU's go missing (effectively preventing loops to occur). After BPDU's are received on a port again, Loop Guard allows to port to move through the normal STP states and become active.
UDLD works like pings on fiber-optic links where link can become partly damaged and become unidirectional. So on the one side switch could stop to receive BPDU's, however it can send data across the link. A unidirectional link poses a potential danger to STP topologies because BPDUs will not be received on one end of the link. If that end of the link normally would be in the Blocking state, it will not be that way for long. A switch interprets the absence of BPDUs to mean that the port can be moved safely through the STP states so that traffic can be forwarded. However, if that is done on a unidirectional link, a bridging loop forms and the switch never realizes the mistake.
The objective behind UDLD is to detect a unidirectional link condition before STP has time to move a blocked port into the Forwarding state. To do this, the target time must be less than the Max Age timer plus two intervals of the Forward Delay timer, or 50 seconds. UDLD can detect a unidirectional link after about three times the UDLD message interval (45 seconds total, using the default). If none of those messages is echoed back, the port is placed in the Errdisable state so that it cannot be used (in case of aggressive mode, otherwise syslog message is generated).
HSRP. Only the standby (the one with the second-highest priority) router monitors the hello messages from the active router.
HSRP mac address 0000.0c07.acxx, where xx represents the HSRP group number as a two-digit hex value. HSRP sends its hello messages to the multicast destination 224.0.0.2 (“all routers”) using UDP port 1985. Priority and group numbers:
- 0 to 255
- group numbers range from 0 to 255; priorities range from 1 to 254.
GLBP MAC addresses always have the form 0007.b4xx.xxyy. The 16-bit value denoted by xx.xx represents six zero bits followed by a 10-bit GLBP group number. The 8-bit yy value is the virtual forwarder number. Priority and group numbers
- group numbers range from 0 to 1023. Priority can be 1 to 255
- The maximum weight can range from 1 to 254 (default 100).
