Compare commits
5 Commits
c5fa59b6e0
...
main
| Author | SHA1 | Date | |
|---|---|---|---|
|
4d24fca821 | ||
|
|
fd0887a683 | ||
|
|
172db956a3 | ||
|
|
994cb382cb | ||
|
|
6c2b3ce357 |
@@ -29,3 +29,10 @@ tags:
|
|||||||
[[VLAN (Part 2)]]
|
[[VLAN (Part 2)]]
|
||||||
[[VLAN (Part 3)]]
|
[[VLAN (Part 3)]]
|
||||||
[[DTP - VTP]]
|
[[DTP - VTP]]
|
||||||
|
[[Protocole Spanning Tree (part1)]]
|
||||||
|
[[Protocole Spanning Tree (part2)]]
|
||||||
|
[[PortFast (STP Toolkit)]]
|
||||||
|
[[BPDU Guard & BPDU Filter (STP Toolkit)]]
|
||||||
|
[[Root Guard (STP Toolkit)]]
|
||||||
|
[[Rapid Spanning Tree Protocol]]
|
||||||
|
[[EtherChannel]]
|
||||||
|
|||||||
140
20. Protocole Spanning Tree (part1).md
Normal file
140
20. Protocole Spanning Tree (part1).md
Normal file
@@ -0,0 +1,140 @@
|
|||||||
|
---
|
||||||
|
id: 20. Protocole Spanning Tree
|
||||||
|
aliases: []
|
||||||
|
tags: []
|
||||||
|
---
|
||||||
|
|
||||||
|
# Protocole Spanning Tree
|
||||||
|
|
||||||
|
## Networks Redundancy
|
||||||
|
|
||||||
|
- Redundandy is an essential part of network design.
|
||||||
|
- Modern networks are expected to run 24/7/365
|
||||||
|
- if one network component fails, you must ensure that other components will take over
|
||||||
|
with little or no downtime
|
||||||
|
- As much as possible, you must implement redundancy at every possible point in the network
|
||||||
|
|
||||||
|
note: Most PCs only have a single network interface card [[NIC]], so they can only be plugged
|
||||||
|
into a single switch. However, important servers typically have multiple NICs, so they can be
|
||||||
|
plugged into multiple switches for redundancy
|
||||||
|
|
||||||
|
The [[Ethernet header]] doesn't have a [[TTL]] field. These broadcast frames will loop around
|
||||||
|
the network indefinitely, if enough of these looped broadcasts accumulate in the network, the
|
||||||
|
network will be too congested for legitimate traffic to use the network. This is called
|
||||||
|
[[Broadcast Storm]]
|
||||||
|
|
||||||
|
Network congestion isn't the only problem. each time a frame arrives on a switchport, the switch
|
||||||
|
uses the source [[MAC]] address field to learn the MAC address and update its MAC address table.
|
||||||
|
When a frames with the same source MAC address repeatedly arrive on different interfaces,
|
||||||
|
the switch is continously updating the interface in its MAC address table. this is known as
|
||||||
|
[[MAC Address Flapping]]
|
||||||
|
|
||||||
|
## Spanning Tree protocol
|
||||||
|
|
||||||
|
- Classic Spanning Tree Protocol is **IEEE 802.1D**
|
||||||
|
- Switches from all vendors run STP by default.
|
||||||
|
- STP prevents Layer 2 loops by placing redundant ports in a blocking state, essentially disabling
|
||||||
|
the interface.
|
||||||
|
- These interfaces act as backups that can enter a forwarding state if an active (=currently forwarding)
|
||||||
|
interface fails
|
||||||
|
- Interfaces in a frowarding state behave normally. They send and receive all normal traffic.
|
||||||
|
- Interfaces in a blocking state only send or receive STP messages (called **[[BPDU]]s**)
|
||||||
|
Bridge Protocol Data Units
|
||||||
|
|
||||||
|
note: Spanning Tree Protocol still use the term [[Bridge]]. However, when we use the term
|
||||||
|
bridge, we really mean [[Switch]]. Bridges are not used in modern networks.
|
||||||
|
|
||||||
|
- By selecting which ports are forwarding and which ports are blocking, STP creates a single path to/from
|
||||||
|
each point in the network. This prevents Layer 2 loops.
|
||||||
|
- There us a set process that STP uses to determine which ports should be forwartding and which should
|
||||||
|
be blocking
|
||||||
|
- STP-enanbled switches send/receive Hello BPDUs out of all interfaces, the default timer is
|
||||||
|
2 seconds (the switch will send a Hello BPDU out of every interface, once every 2 secong)
|
||||||
|
- If a switch receives a Hello BPDUs on an interface, it knows that interface is connected to another
|
||||||
|
switch (routers, PCs, etc. do not use STP, so they do not send Hello BPDUs)
|
||||||
|
|
||||||
|
- Switches use one field in the STP BPDU, the Bridge ID field, to elect a root bridge for the network
|
||||||
|
- The switch with the lowest Bridge ID becomes the root bridge.
|
||||||
|
- ALL ports on the root bridge are put in a forwarding state,and other switches in the topology
|
||||||
|
must have a path to reach the root bridge
|
||||||
|
|
||||||
|
+---------------------------------+
|
||||||
|
| Bridge ID |
|
||||||
|
|------------------+--------------|
|
||||||
|
| Bridge Priority | Mac address |
|
||||||
|
| 16 bits | 48 bits |
|
||||||
|
+---------------------------------+
|
||||||
|
|
||||||
|
The default bridge priority is 32768 on all switches, so by default the MAC address is used
|
||||||
|
as the tie-breaker (lowest MAC address becomes the root bridge)
|
||||||
|
|
||||||
|
**The Bridge Priority is compared first. if they tie, the MAC address is then compared**
|
||||||
|
|
||||||
|
Howerver the Bride ID have been updated
|
||||||
|
|
||||||
|
+---------------------------------+
|
||||||
|
| Bridge ID |
|
||||||
|
|------------------+--------------|
|
||||||
|
| Bridge Priority | Mac address |
|
||||||
|
| 16 bits | 48 bits |
|
||||||
|
+---------------------------------+
|
||||||
|
|
|
||||||
|
+----------------------------+
|
||||||
|
| Bridge | Extended System ID|
|
||||||
|
|Priority| (VLAN ID) |
|
||||||
|
| 4bits | 12 bits |
|
||||||
|
+----------------------------+
|
||||||
|
|
||||||
|
Cisco switches use a version of STP called PVST (per-VLAN Spanning Tree).
|
||||||
|
PVST runs a separate STP instance in each VLAN, so in each VLAN different interfaces
|
||||||
|
can be forwarding/blocking
|
||||||
|
|
||||||
|
in the default VLAN of 1, the default bridge priority is actually 32769 (32768 + 1)
|
||||||
|
|
||||||
|
The STP bridge priority can only be changed in units of 4096
|
||||||
|
|
||||||
|
All interface on the root bridge are **designated ports**. designated ports are in a forwarding state
|
||||||
|
|
||||||
|
Whe a switch is powered on, it assumes it is the root bridge.
|
||||||
|
it will only give up its position if it receives a superior BPDU (lower bridge ID)
|
||||||
|
|
||||||
|
Once the topology has converged and all switches agree on the root bridge, only the root bridge sends BPDUs
|
||||||
|
Other switches in the network will forward these BPDUs, but will not generate their own original BPDUs
|
||||||
|
|
||||||
|
### STP Cost
|
||||||
|
|
||||||
|
| Speed | STP Cost |
|
||||||
|
| -------------- | --------------- |
|
||||||
|
| 10Mbps | 100 |
|
||||||
|
| 100Mbps | 19 |
|
||||||
|
| 100Gbps | 4 |
|
||||||
|
| 10Gbps | 2 |
|
||||||
|
|
||||||
|
The ports connected to another switch's root port MUST be designated. Because the root port is the switch's path to the root bridge
|
||||||
|
another switch must not block it
|
||||||
|
|
||||||
|
### Port ID
|
||||||
|
|
||||||
|
STP Port ID = port priority (default 128) + port number
|
||||||
|
|
||||||
|
Every collision domain has a single STP designated port
|
||||||
|
|
||||||
|
### Steps
|
||||||
|
|
||||||
|
1) The switch with the lowest bridge ID is elected as the root bridge. All ports on the root bridge are designated ports (forwarding state).
|
||||||
|
2) Each remaining switch will select ONE of its interfaces to be its root port. The interface with the lowest root cost will
|
||||||
|
be the root port. Root ports are also in a forwarding state
|
||||||
|
Root port selection:
|
||||||
|
- lowest root cost
|
||||||
|
- lowest neighbor bridge ID
|
||||||
|
- lowest neighbor port ID
|
||||||
|
3) Each remaining collision domain will select ONE interface to be a designated port (forwarding state). THe other port in the
|
||||||
|
collision domain will be non-designated (blocking)
|
||||||
|
Designated port selection:
|
||||||
|
- Interface on switch wih lowest root cost
|
||||||
|
- Interface on switch wih lowest bridge ID
|
||||||
|
|
||||||
|
## Review
|
||||||
|
|
||||||
|
- Redundancy in networks
|
||||||
|
- STP (Spanning Tree Protocol)
|
||||||
167
21. BPDU Guard & BPDU Filter (STP Toolkit).md
Normal file
167
21. BPDU Guard & BPDU Filter (STP Toolkit).md
Normal file
@@ -0,0 +1,167 @@
|
|||||||
|
---
|
||||||
|
id: 1779916771-SNCX
|
||||||
|
aliases:
|
||||||
|
- BPDU Guard & BPDU Filter (STP Toolkit)
|
||||||
|
tags: []
|
||||||
|
---
|
||||||
|
|
||||||
|
# BPDU Guard & BPDU Filter (STP Toolkit)
|
||||||
|
|
||||||
|
PortFast makes a port start in the Forwarding state when it is connected, but it doesn't disable STP
|
||||||
|
on the port.
|
||||||
|
- The port will continue to send BPDUs every 2 seconds.
|
||||||
|
|
||||||
|
Because end hosts don't run STP and send BPDUs, a PortFast enabled port shouldn't receive BPDUs
|
||||||
|
- But what if it does?
|
||||||
|
|
||||||
|
If a PortFast-enabled port receives an STP BPDU, it will revert to acting like a regular STP port
|
||||||
|
(without PortFast)
|
||||||
|
|
||||||
|
## BPDU Guard
|
||||||
|
|
||||||
|
### The problem
|
||||||
|
|
||||||
|
PortFast should only be enabled on ports connected to non-switch devices (end osts, routers).
|
||||||
|
- A PortFast-enabled port still sends BPDUs and will operate like a regular STP port if it
|
||||||
|
receives VPDUs from a neighbor.
|
||||||
|
- If an end user carelessly connects a switch to a port meant for end hosts,, it could affect the
|
||||||
|
STP topology.
|
||||||
|
- *BPDU Guard* acts as a safeguard against this.
|
||||||
|
|
||||||
|
### The Solution
|
||||||
|
|
||||||
|
BPDU Guard protects the network from unauthorized switches being connected to ports intended for end hosts.
|
||||||
|
It can be configured separately from [[PortFast]] but both features are usually used together.
|
||||||
|
They both enhance STP's functionality on ports inteded for end hosts.
|
||||||
|
|
||||||
|
A BPDU Guard-enabled port contibues to send BPDUs, but if it receives a BPDU it enters the error-disabled state.
|
||||||
|
- In effect, this disbales the port.
|
||||||
|
|
||||||
|
### Configuration
|
||||||
|
|
||||||
|
Like PorFast, BPDU Guard can be configured in two ways:
|
||||||
|
|
||||||
|
per-port:
|
||||||
|
```Cisco
|
||||||
|
SW3(config-if)# spanning-tree bpduguard enable
|
||||||
|
```
|
||||||
|
|
||||||
|
default
|
||||||
|
```Cisco
|
||||||
|
SW3(config)# spanning-tree portfast bpduguard default
|
||||||
|
```
|
||||||
|
|
||||||
|
When enabled by default *BPDU Guard* is activated on **All Portfast-enabled ports**.
|
||||||
|
|
||||||
|
disableing it
|
||||||
|
```Cisco
|
||||||
|
SW3(config)# spanning-tree bpduguard disable
|
||||||
|
```
|
||||||
|
|
||||||
|
### Errdisable
|
||||||
|
|
||||||
|
ErrDiable is a [[Cisco]] switch feature that disables a port under certain conditions, such as BPDU
|
||||||
|
Guard violation.
|
||||||
|
More examples are
|
||||||
|
- Power Policing violations
|
||||||
|
- Port Security violations
|
||||||
|
- DAI (Dynamic ARP inspection) violations
|
||||||
|
|
||||||
|
to re-enable an err-disabled port, *first solve the underlying issue*
|
||||||
|
- if you re0enable the port without fixing the issue, it will just be err-disabled again.
|
||||||
|
|
||||||
|
You can re-enable an err-disabled port in two ways:
|
||||||
|
1. Manual: use *shutdown* and *no shutdown* to reset the disabled port.
|
||||||
|
2. Automatic: *ErrDisable Recovery*
|
||||||
|
|
||||||
|
#### ErrDisable Recovery
|
||||||
|
|
||||||
|
ErrDisable Recovery is a feature that automatically re-enables err disabled ports after a certain period of time
|
||||||
|
|
||||||
|
ErrDisable Recovery is disabled by default
|
||||||
|
|
||||||
|
to view it status use
|
||||||
|
|
||||||
|
```Cisco
|
||||||
|
SW1# show errdisable recovery
|
||||||
|
```
|
||||||
|
|
||||||
|
The default recovery timer is 300 seconds (5minutes).
|
||||||
|
- err-disabled interfaces will be automatically re-enabled after 5 minutes
|
||||||
|
|
||||||
|
command to modify the interval is
|
||||||
|
```Cisco
|
||||||
|
SW1# errdisable recovery interval *seconds*
|
||||||
|
```
|
||||||
|
|
||||||
|
to enable ErrDisable Recovery for ports disabled by a particular cause use
|
||||||
|
```Cisco
|
||||||
|
SW1(config)# errdisble recovery cause *cause*
|
||||||
|
```
|
||||||
|
|
||||||
|
## BPDU Filter
|
||||||
|
|
||||||
|
### The Problem
|
||||||
|
|
||||||
|
A switch port connected to an end host contnues sending BPDUs every 2 seconds.
|
||||||
|
- regardless of whether PortFast and/or BPDU GUard are enabled
|
||||||
|
If the port doeen't connect to a switch, sending BPDUs is unnecessary and undesirable for a
|
||||||
|
coupe of reasons
|
||||||
|
1. Sendig BPDUs uses some bandwidth and processing power on the witch (althrough it's minimal).
|
||||||
|
2. BPDUs contain information about the LAN's STP topology
|
||||||
|
- If maximum security is a concern, you should avoid sending this info to user devices.
|
||||||
|
|
||||||
|
Bpdu Filter solves this by preventing a port from sending BPDUs
|
||||||
|
|
||||||
|
### The Solution
|
||||||
|
|
||||||
|
BPDU FIlter stops a port fro sending BPDUs
|
||||||
|
- Unlike BPDU Guard, it does not disable the port if it receives a BPDU
|
||||||
|
BPDU filter can be enabled in two ways:
|
||||||
|
|
||||||
|
per-port:
|
||||||
|
```Cisco
|
||||||
|
SW3(config-if)# spanning-tree bpdufilter enable
|
||||||
|
```
|
||||||
|
The port will not send BPDUs
|
||||||
|
The port will ignore any BPDUs it receives.
|
||||||
|
In effect this disables [[STP]] on the port. *Use with caution!*
|
||||||
|
|
||||||
|
default
|
||||||
|
```Cisco
|
||||||
|
SW3(config)# spanning-tree portfast bpdufilter default
|
||||||
|
```
|
||||||
|
BPDU Filter will be activated on all *PortFast-enabled ports*.
|
||||||
|
You can use spanning-tree bpdufilter disable to disable it on specific ports.
|
||||||
|
The port will not send BPDUs
|
||||||
|
If the port receives a BPDU, PortFast and BPDU Filter are disabled, and it operates as a normal STP Port.
|
||||||
|
|
||||||
|
## Recommandation
|
||||||
|
|
||||||
|
Enable PortFast and BPDU Guard however you prefer (per-port or by default)
|
||||||
|
- Only enable BPDU Filter by default (global config mode).
|
||||||
|
- Unless you have a very good reason to enable it per-port
|
||||||
|
|
||||||
|
*BPDU Guard* and *BPDU Filter* can be enabled on the same port at the same time:
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
If BPDU Filter is enabled in global-confg mode and the port receives a BPDU:
|
||||||
|
1. BPDU Filter will be disabled
|
||||||
|
2. BPDU Guard will be triggered (and err-disable the interface)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
If BPDU Fileter is enabled in interface config mode and the port receives a BPDU:
|
||||||
|
- The BPDU will be ignored
|
||||||
|
- BPDU Guard will *not* be triggered
|
||||||
|
|
||||||
|
## Review
|
||||||
|
|
||||||
|
### BPDU Guard
|
||||||
|
Automatically disables a port if it receives a BPDU, protecting the STP topology by preventing
|
||||||
|
unauthorized devices from becoming part of the network
|
||||||
|
|
||||||
|
|
||||||
|
### BPDU Filter
|
||||||
|
Stops a port from sending BPDUs or processing received BPDUs
|
||||||
126
21. PortFast (STP Toolkit).md
Normal file
126
21. PortFast (STP Toolkit).md
Normal file
@@ -0,0 +1,126 @@
|
|||||||
|
---
|
||||||
|
id: 1779884291-BCDN
|
||||||
|
aliases:
|
||||||
|
- PortFast (STP Toolkit)
|
||||||
|
tags: []
|
||||||
|
---
|
||||||
|
|
||||||
|
# PortFast (STP Toolkit)
|
||||||
|
|
||||||
|
ex:
|
||||||
|
Switch <-> PC
|
||||||
|
|
||||||
|
Listening
|
||||||
|
| 15sec
|
||||||
|
Learning
|
||||||
|
| 15sec
|
||||||
|
Forwarding
|
||||||
|
|
||||||
|
When an end host connects to a switch port, the port becomes up/up but can't send/receive data yet.
|
||||||
|
- It is a *Designated port* but will take 30 seconds before it enters the Forwarding state:
|
||||||
|
- 15 seconds in Listening
|
||||||
|
- 15 seconds in Learning
|
||||||
|
This lead to poor user experience
|
||||||
|
- the user probably doesn't even know [[STP]] exists.
|
||||||
|
- They just know "the internet doesn't work" for 30 seconds when they connect their computer.
|
||||||
|
- This wait is unnecessary, because there is no risk of a Layer 2 loop occuring between a switch/PC
|
||||||
|
|
||||||
|
## The solution
|
||||||
|
|
||||||
|
When portFast is configured on a port, the port immediately enters the Forwardin state when connected
|
||||||
|
to another device.
|
||||||
|
It bypasses Listening/Learning and can send/receive data right away
|
||||||
|
|
||||||
|
You can configure PortFast in two ways
|
||||||
|
|
||||||
|
1. Interface config mode
|
||||||
|
|
||||||
|
```Cisco
|
||||||
|
SW1(config-if)# spanning-tree portfast
|
||||||
|
```
|
||||||
|
|
||||||
|
This enables PortFast only on the individual interface.
|
||||||
|
|
||||||
|
*Even if you configure spanning-tree porfast on a trunk port, it won't be active.*
|
||||||
|
|
||||||
|
2. Global config mode:
|
||||||
|
|
||||||
|
```Cisco
|
||||||
|
SW1(config)# spanning-tree portfast default
|
||||||
|
```
|
||||||
|
|
||||||
|
This enables PorFast on all access ports.
|
||||||
|
|
||||||
|
Connections between switches are almost always trunk links.
|
||||||
|
Connections to end hosts are almost always access links.
|
||||||
|
|
||||||
|
**PortFast should NOT be configured on ports connected to switches or temporary Layer 2
|
||||||
|
loops can occur.**
|
||||||
|
|
||||||
|
## showing result
|
||||||
|
|
||||||
|
```Cisco
|
||||||
|
SW1(config)# show spanning-tree interface g0/1 detail
|
||||||
|
```
|
||||||
|
|
||||||
|
## diabling portfast
|
||||||
|
|
||||||
|
```Cisco
|
||||||
|
SW1(config-if)# spanning-tree portfast disable
|
||||||
|
```
|
||||||
|
|
||||||
|
## Configurating Portfast on trunk port
|
||||||
|
|
||||||
|
In some cases, you might want to enable PortFast on a trunk port:
|
||||||
|
- A port connected to a virtualization server with virtual machines (VMs) in different VLANs.
|
||||||
|
- A port connected to a [[router]] via router on a stick [[ROAS]].
|
||||||
|
|
||||||
|
This can only be cofigured per-port in interface config mode:
|
||||||
|
|
||||||
|
```Cisco
|
||||||
|
SW1(config-if)# spanning tree portfast trunk
|
||||||
|
```
|
||||||
|
|
||||||
|
## PortFast Edge
|
||||||
|
|
||||||
|
In modern Cisco switches, if you use the commands covered in this lecture, the device will automatically
|
||||||
|
add the edge keyword to the configuration.
|
||||||
|
|
||||||
|
```Cisco
|
||||||
|
SW1(config-if)# spanning-tree portfast
|
||||||
|
running-config
|
||||||
|
spanning-tree portfast edge
|
||||||
|
```
|
||||||
|
|
||||||
|
```Cisco
|
||||||
|
SW1(config-if)# spanning tree portfast trunk
|
||||||
|
running-config
|
||||||
|
spanning-tree portfast edge trunk
|
||||||
|
```
|
||||||
|
|
||||||
|
```Cisco
|
||||||
|
SW1(config)# spanning-tree portfast default
|
||||||
|
running-config
|
||||||
|
spanning-tree portfast edge default
|
||||||
|
```
|
||||||
|
|
||||||
|
You can use either version of the commands when configuring PortFast.
|
||||||
|
|
||||||
|
The end result is the same: edge will always be added in the configuraion.
|
||||||
|
|
||||||
|
spanning-tree portfast disable doesn't use the *edge* keyword.
|
||||||
|
|
||||||
|
|
||||||
|
## two kind of Portfast
|
||||||
|
|
||||||
|
There are two kinds of PortFast:
|
||||||
|
- edge
|
||||||
|
- edge is the kind we are covering in this video
|
||||||
|
- network
|
||||||
|
- network is used for a feature called Bridge Assurance (not a CCNA topic)
|
||||||
|
|
||||||
|
## Review
|
||||||
|
|
||||||
|
### PortFast:
|
||||||
|
Allows switchs ports connected to end hosts to immediately enter the STP Forwarding state.
|
||||||
|
Bypassing Linstening and Learning
|
||||||
226
21. Protocole Spanning Tree (part2).md
Normal file
226
21. Protocole Spanning Tree (part2).md
Normal file
@@ -0,0 +1,226 @@
|
|||||||
|
---
|
||||||
|
id: 1778913634-WEMK
|
||||||
|
aliases:
|
||||||
|
- Protocole Spanning Tree (part2)
|
||||||
|
tags: []
|
||||||
|
---
|
||||||
|
|
||||||
|
# Protocole Spanning Tree (part2)
|
||||||
|
|
||||||
|
## Spanning Tree Port State
|
||||||
|
|
||||||
|
| STP Port State | Stable/Transitional |
|
||||||
|
| -------------- | --------------- |
|
||||||
|
| Blocking | Statble |
|
||||||
|
| Listening | Transitional |
|
||||||
|
| Learning | Transitional |
|
||||||
|
| Forwarding | Stable |
|
||||||
|
| Disabled | Stable |
|
||||||
|
|
||||||
|
- Root/Designated ports remain stab;e in Forwarding state.
|
||||||
|
- Non-designated ports remain stabl in a Blocking state.
|
||||||
|
- Listening and Learning are transitional states which are passed through when an interface is
|
||||||
|
activated, or when a *Blocking* port must transition to a Forwarding state due to a change in the
|
||||||
|
network topology
|
||||||
|
|
||||||
|
### Blocking state
|
||||||
|
|
||||||
|
- Non designated ports are in a Blocking state
|
||||||
|
- Interfaces in a Blocking state are effectively disabed to prevent loops.
|
||||||
|
- Interfaces in a Blocking stae do not send/receive regular naetwork traffic.
|
||||||
|
- Interfaces in a Blocking state receive STP BPDUs.
|
||||||
|
- Interfaces in a Blocing state do NOT forward STP BPDUs.
|
||||||
|
- Interfaces in a Blocking state do NOT learn [[MAC]] addresses.
|
||||||
|
|
||||||
|
### Listening state
|
||||||
|
|
||||||
|
- After the Blocking state interfaces with the Designated or Root role enter Listening state.
|
||||||
|
- Only Designated or Root ports enter the Listening state (Non-designated ports are always Blocking)
|
||||||
|
- The Listening state is 15 seconds long by default. This is determined by the *orward delay* timer.
|
||||||
|
- An interface in the listening state ONLY forwards/receives STP BPDUs.
|
||||||
|
- An interface in the Listening state does NOT send/receive regular traffic
|
||||||
|
- An interface in the Listening state does NOT Learn MAC addresses from regular traffic that
|
||||||
|
arrives on the interface
|
||||||
|
|
||||||
|
### Learning state
|
||||||
|
|
||||||
|
- After the Listeing state, a Designated or ROOT port will enter Learning state.
|
||||||
|
- The Learning state is 15 seconds long by default. This is determined by the Forward delay
|
||||||
|
timer ( the same timer is used for both the Listening and Learning states).
|
||||||
|
- An interface in the Learning state ONLY sends/receives STP BPDUs.
|
||||||
|
- An interface in the Learning state learns MAC addresses from regular traffic that arrives on
|
||||||
|
the interface.
|
||||||
|
|
||||||
|
### Forwarding state
|
||||||
|
|
||||||
|
- Root and designated ports are in a Forwarding state.
|
||||||
|
- A port in the Forwarding state operate as normal
|
||||||
|
- A port in the Forwarding state sends/receives BPDUs.
|
||||||
|
- A port in the Forwarding state sends/receives normal traffic.
|
||||||
|
- A port in the Forwarding state learns MAC addresses.
|
||||||
|
|
||||||
|
### summary
|
||||||
|
|
||||||
|
|
||||||
|
| STP Port State |Send/Receive BPDUs | Frame forwarding | Mac address learning| Stable/Transitional |
|
||||||
|
| -------------- |----|----|----| --------------- |
|
||||||
|
| Blocking | No/Yes| NO | NO | Statble |
|
||||||
|
| Listening | Yes/Yes| NO | NO | Transitional |
|
||||||
|
| Learning | Yes/Yes| NO | Yes | Transitional |
|
||||||
|
| Forwarding | Yes/Yes| Yes | Yes | Stable |
|
||||||
|
| Disabled | NO/NO| NO | NO | Stable |
|
||||||
|
|
||||||
|
|
||||||
|
note: Switches do not forward the BPDUs out of their root ports and non-designated ports,
|
||||||
|
only their designated ports
|
||||||
|
|
||||||
|
## STP timers
|
||||||
|
|
||||||
|
### Hello
|
||||||
|
|
||||||
|
How often the root bridge sends hello BPDUs
|
||||||
|
duration: 2 sec
|
||||||
|
|
||||||
|
### Forward delay
|
||||||
|
|
||||||
|
How long the switch will stay in the Listening and Learning states (each stae is 15 seconds
|
||||||
|
= total 30 seconds)
|
||||||
|
duration: 15sec
|
||||||
|
|
||||||
|
### Max Age
|
||||||
|
|
||||||
|
How long an interface will wait after ceasing to receive Hello BDPUs to change the STP topology
|
||||||
|
duration: 20 sec (10*hello)
|
||||||
|
|
||||||
|
- If another BPDU i received before the max age timer counts down to 0, the time will reset to 20
|
||||||
|
seconds and no changes will ocur.
|
||||||
|
|
||||||
|
- If another BPDU is not received the max age timer counts down to 0 and the switch will
|
||||||
|
reevaluate its STP choices, including root bridge, and local root, designated, and non-designated ports
|
||||||
|
|
||||||
|
- if a non-designated port is selected to become a designated or root port, it will transition
|
||||||
|
from the blocking state to the listening state (15 seconds), learning state (15 seconds),
|
||||||
|
and then finally the forwarding state. So it can take a total of 50 seconds for a blocking
|
||||||
|
interface to transition to forwarding
|
||||||
|
|
||||||
|
- These timers and transitional states are to make sure that loops aren't accidentally created
|
||||||
|
by interface moving to forwarding state too soon.
|
||||||
|
|
||||||
|
note: A forwarding interface can move directly to a blocking state (there is no worry
|
||||||
|
about creating a loop by blocking an interface).
|
||||||
|
A blocking interface cannot move directly to forwarding state, it must go through the
|
||||||
|
listening and learning states.
|
||||||
|
|
||||||
|
```Wireshark
|
||||||
|
Dst: PVST+ (01:00:0c:cc:cc:cd)
|
||||||
|
```
|
||||||
|
|
||||||
|
PVST = Only ISL trunk enquapsulation
|
||||||
|
PVST+ = Supports [[802.1Q]]
|
||||||
|
|
||||||
|
Regular STP (not Cisco's PVST+)
|
||||||
|
uses a destination MAC address of 0180.c200.0000
|
||||||
|
|
||||||
|
The STP timers on the root bridge determine the STP timers for th entire network.
|
||||||
|
|
||||||
|
## Spanning Tree Optional Features (STP Toolkit)
|
||||||
|
|
||||||
|
### Portfast
|
||||||
|
|
||||||
|
Portfast allows a port to move imediately to the Forwarding state,
|
||||||
|
bypassing *Listening* and *Learning*.
|
||||||
|
|
||||||
|
If used, it must be enabled *only on ports connected to end hosts,*
|
||||||
|
if enabled on a port connected to another switch it could cause a Layer 2 loop.
|
||||||
|
|
||||||
|
```Cisco
|
||||||
|
SW1(config)#interface g0/2
|
||||||
|
SW1(config-if)#spanning-tree portfast
|
||||||
|
```
|
||||||
|
|
||||||
|
You can also enable portfast with the command:
|
||||||
|
|
||||||
|
```Cisco
|
||||||
|
SW1(config)#spanning-tree portfast default
|
||||||
|
```
|
||||||
|
|
||||||
|
This enables portfast on all access ports (not trunk ports).
|
||||||
|
|
||||||
|
### BPDU Guard
|
||||||
|
|
||||||
|
if an interface with BPDU Guard enabled receives a BPDU from another switch,
|
||||||
|
the interface will be shut down to prevent a loop from forming.
|
||||||
|
|
||||||
|
```Cisco
|
||||||
|
SW1(config)#interface g0/2
|
||||||
|
SW1(config-if)#spanning-tree bpduguard enable
|
||||||
|
```
|
||||||
|
|
||||||
|
You can also enable portfast with the command:
|
||||||
|
|
||||||
|
```Cisco
|
||||||
|
SW1(config)#spanning-tree portfast bpduguard default
|
||||||
|
```
|
||||||
|
|
||||||
|
### Root Guard
|
||||||
|
|
||||||
|
If you enable root guard on an interface, even if it receives a superior BPDU (lower bridge ID)
|
||||||
|
on that interface , the switch will not accept the new switch as the root bridge.
|
||||||
|
the interface will be disabled.
|
||||||
|
|
||||||
|
### Loop Guard
|
||||||
|
|
||||||
|
If you enable loop guard on an interface, even if the interface stops receiving BPDUs, it`will not
|
||||||
|
start forwarding. The interface will be disabled.
|
||||||
|
|
||||||
|
## Spanning Tree Configuration
|
||||||
|
|
||||||
|
|
||||||
|
### Spanning Tree mode
|
||||||
|
|
||||||
|
```Cisco
|
||||||
|
SW1(config)#spanning-tree mode ?
|
||||||
|
mst multiple spanning tree mode
|
||||||
|
pvst Per-Vlan spanning tree mode
|
||||||
|
rapid-pvst Per-Vlan rapid spanning tree mode //default
|
||||||
|
|
||||||
|
SW1(config)#spanning-tree mode pvst
|
||||||
|
```
|
||||||
|
|
||||||
|
### Primary Root Bridge
|
||||||
|
|
||||||
|
```Cisco
|
||||||
|
SW1(config)#spanning-tree vlan 1 root primary
|
||||||
|
|
||||||
|
SW1(config)#do show spanning-tree
|
||||||
|
```
|
||||||
|
|
||||||
|
The *spanning-tree vlan (vlan-number) root primary* command sets the STP priority to 24576.
|
||||||
|
if another switch already has a priority lower than 24576, it sets this switch's priority
|
||||||
|
to 4096 less than the other switch's priority.
|
||||||
|
|
||||||
|
### Secondary Root Bridge
|
||||||
|
|
||||||
|
```Cisco
|
||||||
|
SW1(config)#spanning-tree vlan 1 root secondary
|
||||||
|
|
||||||
|
SW1(config)#do show spanning-tree
|
||||||
|
```
|
||||||
|
|
||||||
|
The *spanning-tree vlan (vlan-number) root secondary* command sets the STP priority to 28672.
|
||||||
|
|
||||||
|
### STP Port Setting
|
||||||
|
|
||||||
|
```Cisco
|
||||||
|
SW1(config)#spanning-tree vlan 1 cost 200
|
||||||
|
SW1(config)#spanning-tree vlan 1 port-priority 32
|
||||||
|
|
||||||
|
```
|
||||||
|
|
||||||
|
## Review
|
||||||
|
|
||||||
|
|
||||||
|
- STP state/timers
|
||||||
|
- STP BPDU
|
||||||
|
- STP optional features
|
||||||
|
- STP configuration
|
||||||
72
21. Root Guard (STP Toolkit).md
Normal file
72
21. Root Guard (STP Toolkit).md
Normal file
@@ -0,0 +1,72 @@
|
|||||||
|
---
|
||||||
|
id: 1779981231-AJMV
|
||||||
|
aliases:
|
||||||
|
- Root Guard (STP Toolkit)
|
||||||
|
tags: []
|
||||||
|
---
|
||||||
|
|
||||||
|
# Root Guard (STP Toolkit)
|
||||||
|
|
||||||
|
STP prevents loops by electing a root bridge and ensuring that each other switch has only *one valid path* to reach it.
|
||||||
|
|
||||||
|
YOu shouldn't randomly select the root bridge. Some things you should consider include:
|
||||||
|
- Optimal traffic flow
|
||||||
|
- minimize latency
|
||||||
|
- minimize congestion
|
||||||
|
- Stability and reliability
|
||||||
|
|
||||||
|
## The Problem
|
||||||
|
|
||||||
|
Within your own [[LAN]], you can easily control the root brdige by setting its priority to 0.
|
||||||
|
- But there are cases where you might connect your LAN to other switches outside of your direct control:
|
||||||
|
- A service provider offering Metro Ethernet service to customers
|
||||||
|
- Often used to connect sites within a [[MAN]]
|
||||||
|
- Even if you set your root bridge's priority to 0, its role can be taken by another switch with a lower
|
||||||
|
[[MAC address]] .
|
||||||
|
|
||||||
|
## The solution
|
||||||
|
|
||||||
|
- *Root Guard* can be configured to protect your [[STP]] topology by preventing your switches from
|
||||||
|
accepting superior [[BPDU]]s from switches outside of your control.
|
||||||
|
- Superior BPDUs = a BPDU that is superior in the STP algorith (e.g Claiming a better root bridge ID).
|
||||||
|
If you want to ensure that the root bridge rmains in your [[LAN]], you can configure Root Guard on the ports connected
|
||||||
|
to switches outside of your control
|
||||||
|
|
||||||
|
To enable root Guard on a port
|
||||||
|
|
||||||
|
```Cisco
|
||||||
|
SW1(config-if) spanning-tree guard root
|
||||||
|
```
|
||||||
|
|
||||||
|
There is no command to enable it by default from global config mode
|
||||||
|
|
||||||
|
If a Root Guard-enabled port receives a BPDU, it will enter the *Broken* (Root inconsistent) state
|
||||||
|
effectively disabling it
|
||||||
|
- The port will not able to forward data frames and will discard any frames it receives.
|
||||||
|
|
||||||
|
To re-enable a port disabled by Root Guard, you must solve the issue that disabled the port
|
||||||
|
- the disabled port must stop receiving superior BDPUs.
|
||||||
|
- tell the customer to increase the priority value of their switch.
|
||||||
|
|
||||||
|
Once teh superior BPDUs received age out, the ports will automatically be re-enabled.
|
||||||
|
- A BPDU's Max Age is 20 seconds by default.
|
||||||
|
|
||||||
|
To see the Root guard
|
||||||
|
|
||||||
|
```Cisco
|
||||||
|
SW1(config-if)# do show spanning-tree
|
||||||
|
|
||||||
|
## if it's broken
|
||||||
|
Gi0/1 Desg BKN*4 128.3 P2p *ROOT_Inc
|
||||||
|
|
||||||
|
BKN = Broken
|
||||||
|
ROOT_Inc = Root inconsistent
|
||||||
|
|
||||||
|
## if it's Work
|
||||||
|
Gi0/1 Desg FWD 4 128.3 P2p
|
||||||
|
```
|
||||||
|
|
||||||
|
## Review
|
||||||
|
|
||||||
|
Prevents a port from becoming a Root Port by disabling it if superior BPDUs are received,
|
||||||
|
Thereby enforcing the current [[Root Bridge]]
|
||||||
185
22 Rapid Spanning Tree Protocol.md
Normal file
185
22 Rapid Spanning Tree Protocol.md
Normal file
@@ -0,0 +1,185 @@
|
|||||||
|
---
|
||||||
|
id: 22 Rapid Spanning Tree Protocol
|
||||||
|
aliases: []
|
||||||
|
tags:
|
||||||
|
- CCNA
|
||||||
|
---
|
||||||
|
|
||||||
|
# Rapid Spanning Tree Protocol
|
||||||
|
|
||||||
|
## Spanning Tree Version
|
||||||
|
|
||||||
|
### Industry standards (IEEE)
|
||||||
|
|
||||||
|
Spanning Tree Protocol (802.1D)
|
||||||
|
- The original STP
|
||||||
|
- ALl VLANs share one STP instance.
|
||||||
|
- Therefore, cannot load balance.
|
||||||
|
|
||||||
|
Rapid spanning Tree Protocol (802.1w)
|
||||||
|
- Much faster at converging/adaptating to network changes than 802.1D
|
||||||
|
- All VLANs share one STP instance.
|
||||||
|
- Therefore, cannot load balance
|
||||||
|
|
||||||
|
Multiple Spanning Tree Protocol (802.1s)
|
||||||
|
- Uses modified RSTP mechanics.
|
||||||
|
- Can group multiple VLANs into different instacnces (ie. VLANs 1-5 instance 1, VLANs 6-10 in instance
|
||||||
|
2 ) to perform load balancing
|
||||||
|
|
||||||
|
### CISCO Versions
|
||||||
|
|
||||||
|
Per-VLAN Spanning Tree Plus (PVST+)
|
||||||
|
- Cisco's upgrade to 802.1D
|
||||||
|
- Each VLAN has its own STP instance.
|
||||||
|
- Can load balance by blocking different ports in each VLAN.
|
||||||
|
|
||||||
|
Rapid Per-VLAN Spanning Tree Plus (Rapid PVST+)
|
||||||
|
- Cisco's upgrade to 802.1w
|
||||||
|
- Each VLAN has its own STP instance
|
||||||
|
- Can load balance by blocking different ports in each VLAN
|
||||||
|
|
||||||
|
## Rapid spanning Tree Protocol
|
||||||
|
|
||||||
|
Cisco's summary:
|
||||||
|
"RSTP is not a timer-based spanning tree algorithm like 802.1D. therefore, RSTP offers an improvement
|
||||||
|
over the 30 seconds or more that 902.1d takes to move a link to forwarding. the heart of
|
||||||
|
the protocol is new bridge-bridge handshake mechanism, which allows ports to move directly to forwarding."
|
||||||
|
|
||||||
|
### Similarities between STP and RSTP:
|
||||||
|
|
||||||
|
RSTP serves the same purpoe as STP, blocking specific ports to prevent Layer2 loops.
|
||||||
|
- RSTP elect a root bridge with same rules as STP
|
||||||
|
- RSTP elects root ports with the same rules as STP.
|
||||||
|
- RSTP elects designated ports with the same rules as STP
|
||||||
|
|
||||||
|
### Differences
|
||||||
|
|
||||||
|
#### COST
|
||||||
|
|
||||||
|
| speed | STP COST | STP COST |
|
||||||
|
| -------------- | --------------- | --------------- |
|
||||||
|
| 10 Mbps | 100 | 2,000,000 |
|
||||||
|
| 100 Mbps | 19 | 200,000 |
|
||||||
|
| 1 Gbps | 4 | 20,000 |
|
||||||
|
| 10 Gbps | 2 | 2,000 |
|
||||||
|
| 100 Gbps | x | 200 |
|
||||||
|
| 1 Tbps | x | 20 |
|
||||||
|
|
||||||
|
|
||||||
|
#### Port State
|
||||||
|
|
||||||
|
| STP Port State | Send/Receive BPDUs | Frame Forwarding | MAC Learning | Stable/Transitional |
|
||||||
|
| ------------- | -------------- | -------------- | -------------- | -------------- |
|
||||||
|
| Discarding | NO/YES | NO | NO | Stable |
|
||||||
|
| Learing | YES/YES | NO | YES | Tranisitional |
|
||||||
|
| Forwarding | YES/YES | YES | YES | Stable |
|
||||||
|
|
||||||
|
|
||||||
|
- if a port is administratively disabled (shutdown command) = discarding state
|
||||||
|
- if a port is enabled but blocking traffic to prevent Layer 2 loops = discarding state
|
||||||
|
|
||||||
|
#### Port Roles
|
||||||
|
|
||||||
|
*The root port role remains unchanged in RSTP.*
|
||||||
|
- The port wthat is closet to the root bridge becomes the root port for the switch.
|
||||||
|
- The root bridge is the only switch that doesn't have a root port.
|
||||||
|
|
||||||
|
*The designated port role remains unchanged in RSTP.*
|
||||||
|
- The port on a segment (collision domain) that sends the best BPDU is that
|
||||||
|
segment's designated port (only one per segment)
|
||||||
|
|
||||||
|
- *The non designated port role is split into two separate roles in RSTP*:
|
||||||
|
- The alternate port role
|
||||||
|
- the backup port role
|
||||||
|
|
||||||
|
##### Alternate port Role
|
||||||
|
|
||||||
|
The RSTP alternate port role is discarding port that receives a superior BPDU from another switch.
|
||||||
|
- This is the same as what you've learned about *blocking* ports in classic STP.
|
||||||
|
- Functions as a backup to the root port.
|
||||||
|
- If the root port fails, the switch can immediately move its best alternate port to forwarding
|
||||||
|
|
||||||
|
This immediate move to fowarding state functions like a classic STP optional feature called
|
||||||
|
UplinkFast. Because it is built into RSTP, you do not need to activate UplinkFast when using
|
||||||
|
RSTP/Rapid PVST+
|
||||||
|
|
||||||
|
One more STP optional feature that was built into RSTP is BackboneFast.
|
||||||
|
Backbone Fast allows SW3 to expire the made age timers on its interface and rapidly forward the superior
|
||||||
|
BPDUs to SW2.
|
||||||
|
This functionality is built into RSTP, so it does not need to be configured
|
||||||
|
|
||||||
|
##### Backup port role
|
||||||
|
|
||||||
|
The RSTP backup port role is a discarding port that receives a superior BPDU from another
|
||||||
|
interface on the same switch.
|
||||||
|
- This only happnes when two interfaces are connected to the same collision domain (via a hub)
|
||||||
|
- Hubs are not used in modern networks, so you will probably not encounter an RSTP backup port.
|
||||||
|
- Function as backup for a designated port
|
||||||
|
- The interface with the lowest port ID will be selected as the designated port and the other will be the
|
||||||
|
backup port
|
||||||
|
|
||||||
|
### BPDU
|
||||||
|
|
||||||
|
In classic [[STP]], only the root bridge originated BPDUs, and other switches just forwarded the BPDUs
|
||||||
|
they received.
|
||||||
|
In Rapid STP, all Switches originate and send their own BPDUs from their designated ports
|
||||||
|
|
||||||
|
All switches running Rapid STP send their own BPDUs every hello time (2 seconds).
|
||||||
|
- Switches 'age' the BPDU information much more quickly, in classic STP a switch waits 10 hello intervales
|
||||||
|
(20 seconds). In rapid STP, a switch considers a neighbor lost if it misses 3 BPDUs (6 seconds)
|
||||||
|
It will the 'Flush' All MAV addresses learned on that interface
|
||||||
|
|
||||||
|
## RSTP Link Types
|
||||||
|
|
||||||
|
RSTP distiguishes between three different 'link types'
|
||||||
|
- Edge: a port that is connected to an end host. Moves directly to forwarding without negotiation.
|
||||||
|
- Point-to-point: a direct connection between two switches
|
||||||
|
- Shared a connection to a [[hub]]. Must operate in half-duplex mode.
|
||||||
|
|
||||||
|
### Edge
|
||||||
|
|
||||||
|
Edge ports are connected to end hosts.
|
||||||
|
- Because ther is no risk of creating a loop, they can move stright to the forwarding state without the
|
||||||
|
negotiation process.
|
||||||
|
- They function like a classic STP port with PortFast enabled
|
||||||
|
|
||||||
|
```Cisco
|
||||||
|
SW1(config-if)# spanning-tree portfast
|
||||||
|
```
|
||||||
|
|
||||||
|
### Point-to-Point
|
||||||
|
|
||||||
|
Point-to-point ports connect directly to another switch
|
||||||
|
- They function in full-duplex
|
||||||
|
- you don't need to configure the interface as point-to-point (it should be detected)
|
||||||
|
|
||||||
|
```Cisco
|
||||||
|
SW1(config-if)# spanning-tree link-type point-to-point
|
||||||
|
```
|
||||||
|
|
||||||
|
|
||||||
|
### Shared
|
||||||
|
|
||||||
|
shared Ports connect to another switch (or switches) via a hub.
|
||||||
|
- They function in half-duplex
|
||||||
|
- You don't need to configure the interface as shared (it should be detected)
|
||||||
|
|
||||||
|
```Cisco
|
||||||
|
SW1(config-if)# spanning-tree link-type shared
|
||||||
|
```
|
||||||
|
|
||||||
|
### Configuration
|
||||||
|
|
||||||
|
|
||||||
|
```Cisco
|
||||||
|
SW3(config)# spanning-tree mode rapid-pvst
|
||||||
|
|
||||||
|
SW3(config)# do show spanning-tree
|
||||||
|
```
|
||||||
|
|
||||||
|
|
||||||
|
## Review
|
||||||
|
|
||||||
|
Comparison of [[STP]] versions (standard vs [[Cisco]])
|
||||||
|
|
||||||
|
Rapid PVST+
|
||||||
128
23. EtherChannel.md
Normal file
128
23. EtherChannel.md
Normal file
@@ -0,0 +1,128 @@
|
|||||||
|
---
|
||||||
|
id: 23. EtherChannel
|
||||||
|
aliases: []
|
||||||
|
tags: []
|
||||||
|
---
|
||||||
|
|
||||||
|
# EtherChannel
|
||||||
|
|
||||||
|
multiple host -- ASW1 -- DSW1
|
||||||
|
|
||||||
|
ASW = Access layer Switch, a switch that end hosts connect to
|
||||||
|
DSW = Distribution layer switch, a switch that access layer switches connect to
|
||||||
|
|
||||||
|
When the bandwith of the interfaces connected to end hosts is greater than the bandwidth of the
|
||||||
|
connection to the distribution switch(es), this is called *oversubscription*.
|
||||||
|
Some oversubscription is acceptable, but too much will cause congestion.
|
||||||
|
|
||||||
|
- if you connect two switchs together with multiple links, all except one will be disabled by
|
||||||
|
[[spanning tree]]
|
||||||
|
- if all of ASW1's interfaces were forwarding, Layer 2 loops would form between ASW1 and DSW1,
|
||||||
|
leading to [[broadcast storms]].
|
||||||
|
- Other links will be unused unless the active link fails. in that case one of the inactive
|
||||||
|
links will start forwarding
|
||||||
|
- EtherChannel groups multiple interfaces together to act as a single interface.
|
||||||
|
- STP will treat this group as a single interface
|
||||||
|
|
||||||
|
Traffic using the EtherChannel wil be load balanced among the physical interfaces in the group.
|
||||||
|
An [[algorithm]] is used to determine which traffic will use which physical interface.
|
||||||
|
|
||||||
|
Some other names for an EtherChannel are:
|
||||||
|
- Port Channel
|
||||||
|
- LAG (Link aggregaton Group)
|
||||||
|
|
||||||
|
## Load Balancing
|
||||||
|
|
||||||
|
- EtherChannel load balances based on flows
|
||||||
|
- A flow is a communication between two nodes in the network
|
||||||
|
- Frames in the same flow will be forwarded using the same physicial interface.
|
||||||
|
- If frames in the same flow were forwarded using different physical interfaces, some frames
|
||||||
|
may arrive at the destination out of order, which can cause problems
|
||||||
|
- You can change the inputs used in the interface selection calculation.
|
||||||
|
- Inputs that can be used:
|
||||||
|
- Source [[MAC]]
|
||||||
|
- Destination MAC
|
||||||
|
- Source and Destination MAC
|
||||||
|
- Source [[IP]]
|
||||||
|
- Destination IP
|
||||||
|
- Source and Destination IP
|
||||||
|
|
||||||
|
### Commands
|
||||||
|
|
||||||
|
|
||||||
|
see current configuration
|
||||||
|
```Cisco
|
||||||
|
ASW1#show etherchannel load-balance
|
||||||
|
### default will be set to src-dst-ip
|
||||||
|
```
|
||||||
|
|
||||||
|
for configuring load balance configuration
|
||||||
|
```Cisco
|
||||||
|
ASW1(config)#port-channel load-balance src-dst-mac
|
||||||
|
|
||||||
|
## to see other method
|
||||||
|
ASW1(config)#port-channel load-balance ?
|
||||||
|
```
|
||||||
|
|
||||||
|
## EtherChannel Configuration
|
||||||
|
|
||||||
|
There are three methods of EtherChannel configuration on Cisco switches:
|
||||||
|
- PAgP (Port Aggregation Protocol)
|
||||||
|
- Cisco proprietary protocol
|
||||||
|
- Dynamically negotiates the creation/maintenance of the EtherChannel.
|
||||||
|
(like DTP does for trunks)
|
||||||
|
- LACP (Link Aggregation Control Protocol)
|
||||||
|
- Industry standard protocol (IEEE 802.3ad)
|
||||||
|
- Dynamically negotiate the creation/maintenance of the EtherChannel.
|
||||||
|
(like DTP does for trunks)
|
||||||
|
- Static EtherChannel
|
||||||
|
- A protocol isn't used to determine if an EtherChannel should be formed.
|
||||||
|
- Interfaces are statically configured to form an EtherChannel
|
||||||
|
|
||||||
|
Up to *8 interfaces* can be formed into a single EtherChannel (LACP allows up to 16, but only
|
||||||
|
8 will be active, the other 8 will be in standby mode, waiting for an active interface to fail)
|
||||||
|
|
||||||
|
```Cisco
|
||||||
|
ASW1(config)#inteface range g0/0 - 3
|
||||||
|
## to see all methods
|
||||||
|
ASW1(config-if-range)#channel-group 1 mode ?
|
||||||
|
## for PAgP
|
||||||
|
ASW1(config-if-range)#channel-group 1 mode desirable
|
||||||
|
```
|
||||||
|
|
||||||
|
note: The channel-group number has to match for member interfaces on the same switch.
|
||||||
|
However, it doesn't have to match the channel-group number on the other switch.
|
||||||
|
(channel-group 1 on ASW1 can form an EhterChannel with channel-group 2 on DSW1)
|
||||||
|
|
||||||
|
Member intefaces must have matching configurations.
|
||||||
|
- Same duplex (full/half)
|
||||||
|
- Same speed
|
||||||
|
- Same switchport mode (access/trunk)
|
||||||
|
- Same allowed VLANs/native VLAN (for trunk interfaces)
|
||||||
|
|
||||||
|
If an interface's configurations do not match the others, it will be excluded from the EtherChannel
|
||||||
|
|
||||||
|
to see running configuration of the EtherChannel
|
||||||
|
|
||||||
|
```Cisco
|
||||||
|
ASW1#show etherchannel summary
|
||||||
|
## less utilise command
|
||||||
|
ASW1#show etherchannel port-channel
|
||||||
|
```
|
||||||
|
|
||||||
|
## Layer 3 EtherChannel
|
||||||
|
|
||||||
|
```Cisco
|
||||||
|
ASW1(config)#int range g0/0 - 3
|
||||||
|
ASW1(config-if-range)#no switchport
|
||||||
|
ASW1(config-if-range)#channel-group 1 mode active
|
||||||
|
|
||||||
|
|
||||||
|
ASW1(config-if-range)#int po1
|
||||||
|
ASW1(config-if)#ip address 10.0.0.1 255.255.255.252
|
||||||
|
```
|
||||||
|
|
||||||
|
## Review
|
||||||
|
|
||||||
|
- What is EtherChannel? what problems does it solve?
|
||||||
|
- Configuring Layer 2/Layer 3 EtherChannel
|
||||||
Reference in New Issue
Block a user