the road (switch)
TRANSCRIPT
P a g e | 1
P a g e | 2
Contents:
Chapter 1: Switch Operation.
Chapter 2: Switch Port Configuration.
Chapter 3: VLANs and Trunks.
Chapter 4: VLAN Trunking Protocol.
Chapter 5: Aggregating Switch Links.
Chapter 6: Traditional STP.
Chapter 7: STP Configuration.
Chapter 8: Protecting the STP Topology.
Chapter 9: Advanced STP.
Chapter 10: Multilayer Switching.
Chapter 11: Enterprise Campus Network Design.
Chapter 12: Layer 3 High Availability.
Chapter 13: IP Telephony.
Chapter 14: Integrating Wireless LANs.
Chapter 15: Securing Switch Access.
Chapter 16: Securing with VLANs.
Chapter 17: Logging Switch Activity.
Chapter 18: Managing Switch with SNMP.
Chapter 19: Monitoring Performance with IP SLA.
Chapter 20: Port Mirroring.
Chapter 21: Managing Switch Users.
P a g e | 3
Chapter 1 Switch Operation
(A) Layer 2 Switch Operation:
- Consider a simple network as shown in the figure that is built around many hosts that
all share the same available bandwidth.
Simple Network Shares the Same Bandwidth
- This is known as a shared media network and was used in early legacy LANs made up
of Ethernet Hubs.
- The Carrier Sense Multiple Access with Collision Detection (CSMA/CD) algorithm
determines when a device can transmit data on the shared LAN.
- When more than one host tries to talk (send) data at one time, a collision occurs, and
everyone must back off and wait to talk again.
- This forces every host to operate in the “half-duplex” mode.
- Half-Duplex A host can either talk (send) or listen (receive) at any given time.
- When one host sends a frame, all connected hosts hear it (receive it).
- When one host generates a frame with errors, all hosts hears that too.
- This type of LAN is a “Collision Domain” because all device transmissions are
susceptible to collisions.
- An Ethernet switch operates at OSI Layer 2, making decisions about forwarding
frames based on the destination MAC addresses found within the frames.
- This means that the Ethernet media is no longer shared among the connected devices.
P a g e | 4
A Layer 2 Ethernet Switch Network
- Instead, at its most basic level, an Ethernet Switch provides isolation between the
connected hosts in several ways:
The collision domain’s scope is severely limited. On each switch port, the
collision domain consists of the switch port itself and the device(s) directly
connected to that port (either a single host or if a shared-media hub is connected,
the set of hosts connected to the hub.
Host connections can operate in full-duplex mode because there is no contention
on the media.
- Full-Duplex mode Hosts can talk (send) and listen (receive) at the same time.
The bandwidth is no longer shared. Instead, each switch port offers a dedicated
bandwidth across a switching fabric to another switch port.
(These frame forwarding paths change dynamically)
Errors in frames are not propagated. Each frame received on a switch port is
checked for errors. Good frames are regenerated when they are forwarded or
transmitted. This in known as “store-and-forward” switching technology.
- Store-and-Forward Packets are received, stored for inspection and then forwarded.
You can limit broadcast traffic to a volume threshold.
Other types of intelligent filtering or forwarding became possible.
P a g e | 5
Transparent Bridging:
- A layer 2 switch is basically a multiport transparent bridge, where each switch port is
its own Ethernet LAN segment, isolated from the others.
- Frame forwarding decision is based completely on the MAC addresses contained in
each frame, such that the switch will not forward a frame unless it knows the
destination’s location.
- When the switch doesn’t know where the destination is, it makes some assumptions.
- The following figure shows the progression from a two-port to a multiport transparent
bridge, and then to a layer 2 switch.
5
6
4
7
8
1
2
3
9
10
11
15 12
13
14
15
16
1
2
3
4
5
6
7
8
P a g e | 6
- The previous figure shows a comparison of the Transparent Bridges and Switches.
- The entire process of forwarding Ethernet frames is about what MAC address connect
to which switch ports.
- A switch must be told either where hosts are located (static MAC learning) or must
learn this information by itself (dynamic MAC learning).
- You can configure MAC address location statically through the switch’s CLI, but this
quickly gets out of control when there are many hosts on the network or when hosts
move around.
- To dynamically learn about host locations, the switch listens to incoming frames and
keeps a table of address information.
- As a frame is received on a switch port, the switch inspects the source MAC address.
- If that address isn’t in the MAC address table already, the MAC address, switch port,
and the VLAN on which it arrived are recorded in the table.
- Learning the address locations of the incoming frames is easy and straightforward.
- Incoming frames also include the destination MAC address.
- Again, the switch looks up this address in the address table, hoping to find the switch
port and VLAN where the destination address is attached:
If it is found, the frame can be forwarded out that switch port.
If it isn’t found, the switch forward that frame in a “best effort” fashion by
flooding it out all switch ports assigned to the source VLAN. This is known as
“unknown unicast flooding” with the unicast destination location unknown.
- The following figure shows this process using only a single VLAN for simplification.
5
6
7
8
1
2
3
4
Packet to 0000.aaaa.aaaa
0000.aaaa.aaaa ?
P a g e | 7
Unknown Unicast Flooding
- In a similar manner, frames containing a broadcast or multicast destination address
also are flooding.
- You should have a basic understanding of the operations that a frame undergoes as it
passes through a layer 2 switch.
- The following figure shows a typical layer 2 catalyst switch and the decision processes
that take place to forward each frame.
Operations within a Layer 2 Catalyst Switch
- When a frame is received by a switch port, it is placed into one of the port’s ingress
queues.
- The queues each can contain frames to be forwarded, with each queue having a
different priority or service level.
- The switch port then can be fine-tuned so that important frames get processed and
forwarded before less-important frames.
- This can prevent time-critical data from being “lost in the shuffle” during a flurry of
incoming traffic.
Note: - As the ingress queues are serviced and a frame is pulled off, the switch must
figure out not only “Where” to forward the frame, but also “Whether” it
should be forwarded and “How”.
5
6
7
8
Packet to 0000.aaaa.aaaa
Packet to 0000.aaaa.aaaa
Packet to 0000.aaaa.aaaa
Packet to 0000.aaaa.aaaa
Packet to 0000.aaaa.aaaa 1
2
3
4
Packet to 0000.aaaa.aaaa
Packet to 0000.aaaa.aaaa
P a g e | 8
- Three fundamental decisions must be made:
1) Layer 2 Forwarding Table - The frame’s destination MAC Address is used as an
index to the Content Addressable Memory (CAM)
table (sometimes called the MAC address table).
- If the address is found, the egress switch port and the
appropriate VLAN ID are read from the table.
- If the address isn’t found, the frame is marked for
flooding so that it is forwarded out every switch port
in the VLAN.
2) Security ACLs - ACLs can be used to identify frames according to their:
MAC Addresses.
IP Addresses.
Protocols.
Layer 4 Port Numbers.
- The Ternary Content-Addressable Memory (TCAM) contains
ACLs in a compiled form so that a decision can be made on
“Whether” to forward a frame in a single table lookup.
3) QoS ACLs - Other ACLs can classify incoming frames according to Quality of
Service (QoS) parameters to police or control the rate of traffic
flows, and to mark QoS parameters in outbound frames.
- The (TCAM) also is used to make these decisions in a single table
lookup.
- After the (CAM) and (TCAM) table lookups have occurred, the frame is placed into
the appropriate egress queue on the appropriate outbound switch port.
- The egress queue is determined by QoS values either contained in the frame or passed
along with the frame.
- Like the ingress queues, the egress queues are serviced according to importance, time
criticality, and Priority.
P a g e | 9
(B) Multilayer Switch Operation:
- Catalyst switches (such as 3750, 4500, and 6500) can forward frames based on Layer 3
and 4 header information.
- This is known as Multilayer Switching (MLS).
- The Layer 2 switching is performed at the same time because the higher-layer
encapsulations still contained in the Ethernet frames.
- The Multilayer Switch is represented using the following symbol
Types of Multilayer Switching (MLS):
- Catalyst switches supported two basic generations or types of MLS:
Route Caching (The first generation of MLS).
Topology-based (The second generation of MLS).
Note: - Only the second generation of MLS is supported in the IOS based switch
families (such as 3750, 4500, and 6500).
a) Route Caching:
- Requires a Route Processor (RP) and Switch Engine (SE).
- The (RP) must process a traffic flow’s first packet to determine the destination.
- The (SE) listens to the first packet and to the resulting destination, and sets up a
“shortcut” entry in its MLS Cache.
- The (SE) forwards subsequent packets in the same traffic flow based on the shortcut
entry in its cache.
Note: - This type of MLS also known as:
Route once, switch many.
Netflow LAN Switching.
Flow-based or Demand-based Switching.
P a g e | 10
b) Topology-based:
- Utilizes specialized hardware.
- Layer 3 routing information builds and prepopulates a single database of the entire
network topology.
- This database, an efficient table lookup in the hardware, is consulted so that packets
can be found at higher rates.
- The longest match found in the database is used as the correct layer 3 destination.
- As the routing topology changes over time, the database contained in the hardware can
be updated dynamically with no performance penalty.
Note: - This type of MLS is known as Cisco Express Forwarding (CEF).
- A routing process running on the switch downloads the current routing table database
into the Forwarding Information Base (FIB) area of hardware.
Note: - (CEF) will be discussed in more details later on Chapter (10).
- The Path that a Layer 3 packet follows through a Multilayer Switch is similar to that a
Layer 2 Switch, with some means of making a Layer 3 forwarding decision must be
added.
- The following figure show a Multilayer Switch and the decision processes that occur.
Operations Within a Multilayer Catalyst Switch
- Packets arriving on a switch port are placed in the appropriate ingress queue, just as a
Layer 2 switch.
P a g e | 11
- Each frame is pulled off an ingress queue and inspected for both Layer 2 and Layer 3
destination addresses.
Note: - In a Multilayer Switch:
The decision of “Where” to forward the packet is based on two address tables
(CAM Table and FIB Table).
The decision of “How” to forward the packet and “Whether” to forward still
based on ACL results (Security ACLs and QoS ACLs).
- As in Layer 2 switching, all these Multilayer decisions are performed simultaneously
in hardware:
1) Layer 2 Forwarding Table - The destination MAC address is used as an index to
the CAM Table.
- If the frame contains a Layer 3 packet to be
forwarded, the destination MAC address inside the
frame is that of a Layer 3 port on the switch as it
default-gateway.
- In this case, the CAM table results are used only to
decide that the frame should be processed at Layer 3.
2) Layer 3 Forwarding Table - The destination IP address is used as an index to the
FIB table.
- If the longest match in the table is found (both subnet
number and mask), the resulting next-hop Layer 3 IP
address is obtained.
- The (FIB) also contains each next-hop entry’s Layer 2
MAC address, egress switch port, and VLAN ID so
that further table lookups are not necessary.
3) Security ACLs - Inbound and outbound ACLs are compiled into TCAM entries so
that decisions of “Whether” to forward a frame can be determined
as a single table lookup.
P a g e | 12
4) QoS ACLs - Frame classification, policing, and marking all can be performed as a
single table lookup in the QoS TCAM so that the decisions of “How”
to forward a frame can be determined.
- As with Layer 2 switching, the frame finally must be placed in the appropriate egress
queue on the appropriate egress switch port.
- However, recall that during the MLS process, the next-hop destination IP address was
obtained from the FIB table, just as a router would do.
- The Layer 3 address identified the next-hop and found its Layer 2 MAC address.
- Only the Layer 2 MAC address would be used, so that the Layer 2 frames could be
sent.
- The next-hop Layer 2 MAC address must be put into the frame in place of the original
destination MAC address of the Multilayer Switch.
- The frame’s Layer 2 source MAC address also must become that of the Multilayer
Switch before it is sent to the next hop.
- As any router must do, the Time-To-Live (TTL) value in the Layer 3 packet must be
decremented by one.
- Because the contents of the Layer 3 packet (the TTL value) have changed, the Layer 3
header checksum must be recalculated.
- Because both Layer 2 and Layer 3 contents have changed, the Layer 2 header
checksum must be recalculated.
- In other words, the entire Ethernet frame must be rewritten before it goes into the
egress queue, this is accomplished efficiently in hardware.
Switching Tables:
- Catalyst switches maintain several types of tables to be used in the switching process.
- The tables are tailored for Layer 2 switching and Multilayer switching and are kept in
very fast memory so that many fields within a frame or packet can be compared in
parallel.
- The tables used in the switching process are:
Content-Addressable Memory (CAM) Table.
Ternary Content-Addressable Memory (TCAM) Table.
P a g e | 13
1) Content-Addressable Memory (CAM) Table:
- All catalyst switch models use a CAM table for Layer 2 switching.
- As frames arrive on switch ports, the source MAC addresses are learned and recorded
in the CAM table.
- Also, the port of arrival and the VLAN ID both are recorded in the CAM table, along
with a time stamp.
- When a host’s source MAC address learned on one switch port has moved to a
different port in the same switch, the MAC address, VLAN ID, and time stamp are
recorded for the most recent arrival port. Then, the host’s original CAM table entry
would be aged out after 300 seconds (default).
- To change the default CAM table Aging-time, use the following command:
Switch(config)# mac address-table aging-time “seconds”
- Stale entries Addresses that haven’t been heard for a period of time.
- By default, idle CAM entries are kept for (300) seconds before they are deleted.
- This can cause a duplicate CAM table entries during these (300) seconds.
- To avoid having a duplicate CAM table entries, a switch purges any existing entries
for a MAC address that has just been learned on a different switch port.
- This safe assumption because MAC addresses are unique, and a single host should
never be seen on more than one switch port.
- If the switch notices that a MAC address is being learned on alternate switch ports (by
static MAC address configuration), the switch generates an error message that flags
the MAC address as “flapping” between interfaces.
- You can configure static CAM table entries that contain MAC addresses that might not
be learned otherwise.
- To configure a static CAM table entry (MAC address, Port, and VLAN ID), use the
following command:
Switch(config)# mac address-table static “mac-address” vlan “vlan-id” interface “type mod/num.”
- Here, the MAC address (in dotted triplet hex format, for example: 2FCD.B5CA.B549)
is identified with the switch interface (port) where it appears and the VLAN ID.
P a g e | 14
Note: - In some earlier IOS versions, the keyword “mac-address-table” was used
instead of the more recent one “mac address-table”.
- Many switch platforms supports both keywords to ease the transition.
- If a MAC address is found already present in the table for the correct arrival port, only
its time stamp is updated.
2) Ternary Content-Addressable Memory (TCAM) Table:
- ACLs can match, filter, or control specific traffic.
- ACLs are made up of one or more Access Control Entities (ACE) or matching
statements that are evaluated in sequential order.
- Evaluating an ACL can take up additional time, adding to the latency of forwarding
frames.
- TCAM allows a frame to be evaluated against an entire ACL in a single table lookup.
- All the matching process that ACLs provide is implemented in hardware.
- Most switches have multiple TCAMs so that both inbound and outbound security
ACLs and QoS ACLs can be evaluated simultaneously, or entirely in parallel with a
Layer 2 or Layer 3 forwarding decision.
- The Catalyst IOS has two components that are part of the TCAM operation:
Feature Manager (FM) - After an ACL has been configured, the Feature
Manager (FM) software compiles or merges the
ACEs into entries in the TCAM table.
- The TCAM then can be consulted at full frame
forwarding speed.
Switching Database Manager (SDM) - You can partition the TCAM on some
Catalyst switches into areas for different
functions.
- The SDM software configures or tunes
the TCAM partitions, if needed.
Note: - In some Catalyst switches (such as 4500 and 6500), the TCAM is fixed and
can’t be repartitioned.
P a g e | 15
TCAM Structure:
- The TCAM is an extension of the CAM table concept.
- Recall that a CAM table takes in a key value (usually MAC address) and looks up the
resulting value (usually a switch port or VLAN ID).
- Table lookup is fast and always based on an exact key match consisting of two input
values: 0 and 1 bits.
- TCAM also uses a table-lookup operation but it allows a more abstract operation.
- TCAM entries are composed of Value, Mask, and Result (VMR) combinations.
- Fields from frame and packet headers are fed into the TCAM, where they are matched
against the Value and Mask pairs to yield a Result.
Values - Are always 134-bit quantities, consisting of source and destination
addresses and other relevant information to be matched.
- Values in the TCAM come directly from any address, port, or other
protocol information given in an ACE.
- The following tables describe the components of the TCAM Values:
Access List Type Value Components (134-bits wide)
Ethernet Source MAC (48-bits), destination MAC (48-bits),
Ethertype (16-bits).
Extended IP using TCP/UDP
Source IP (32-bits), destination IP (32-bits), Protocol
(16-bits), IP ToS (8-bits), source port (16-bits),
source operator (4-bits), destination port (16-bits),
destination operator (4-bits).
Other IP Source IP (32-bits), destination IP (32-bits), protocol
(16-bits), IP ToS (8-bits).
Masks - Are also 134-bit quantities.
- Masks select only the “Value” bits of interest represented by 1s in the
mask and ignore bits represented by 0s in the mask.
P a g e | 16
Results - Are numeric values that represent what action to take after the
TCAM lookup occurs.
- Traditional ACLs offers only a “Permit” or “Deny” result.
- TCAM lookups offer a number of actions or results that can be
“Permit” or “Deny” decisions or an index value to a QoS policer.
- The TCAM is always organized by masks, where each unique mask has 8 “Value”
patterns associated with it.
- Those 8 “Value” patterns are: IP Protocol, IP ToS, Source IP, Source Port, S Port
LOU, Destination IP, Destination Port, and D Port LOU.
- the Catalyst 6500 has two TCAMs (one for Security ACLs and one for QoS ACLs).
- Each TCAM has up to 4096 Masks with 8 Value patterns associated with each Mask.
- Each of the Mask-Value pairs is evaluated simultaneously or in parallel, revealing the
best or longest match in a single table lookup.
Monitoring Switching Tables:
- You can display the switching tables contents to verify the information that the switch
has learned.
- As well, you might want to check the tables to find out on which switch port a specific
MAC address has been learned.
CAM Table Operation:
- To show the contents of the CAM Table, use the following command:
Switch# show mac address-table [dynamic | static] [address “mac-address” | interface “type mod/num.” | vlan “vlan-id”]
- static To show the static CAM table entries configured manually.
- dynamic To show the CAM table entries that have been learned dynamically.
- address To specify a single CAM entry using the MAC address.
- interface To specify CAM entries using a specific interface.
- vlan To specify CAM entries using a specific VLAN ID.
P a g e | 17
Example: - Consider the following small network:
- To configure static PC4’s MAC address manually on interface FastEthernet 0/4 and
VLAN 1, use the following command:
SW1(config)# mac address-table static 00d0.5e83.6f7a vlan 1 interface fastEthernet 0/4
- To show all the contents of the CAM Table (MAC address table) learned by the
switch, use the following “show” command:
SW1# show mac address-table
Mac Address Table
------------------------------------------------------------------
Vlan Mac Address Type Ports
------- ------------------- -------------- --------
1 00a0.2f4c.8b2d DYNAMIC Fa0/1
1 00b0.3c46.9e4c DYNAMIC Fa0/2
1 00c0.4c78.5c3f DYNAMIC Fa0/3
1 00d0.5e83.6f7a STATIC Fa0/4
Total Mac Addresses for this criterion: 4
P a g e | 18
Note: - Suppose that the “show” command produced no output and showing nothing
about the MAC addresses, interfaces, and VLANs where hosts are connected
on the switch, this means that either the hosts haven’t sent frames so the
switch can use for learning the CAM entries.
- To allow the switch learn the CAM entries, let hosts ping the IP addresses of
each other so they can send frames to the switch.
- However, suppose the same command is used and the output showed many
MAC addresses, all found on a single interface, this means that this interface
must be connected to another switch or another part of the network where
other devices are located.
- To show the CAM table entries that have been learned dynamically:
SW1# show mac address-table dynamic
Mac Address Table
------------------------------------------------------------------
Vlan Mac Address Type Ports
------- ------------------- -------------- --------
1 00a0.2f4c.8b2d DYNAMIC Fa0/1
1 00b0.3c46.9e4c DYNAMIC Fa0/2
1 00c0.4c78.5c3f DYNAMIC Fa0/3
Total Mac Addresses for this criterion: 3
- To show the CAM table entries that have been configured statically (manually):
SW1# show mac address-table Static
Mac Address Table
------------------------------------------------------------------
Vlan Mac Address Type Ports
------- ------------------- ----------- --------
1 00d0.5e83.6f7a STATIC Fa0/4 Total Mac Addresses for this criterion: 1
P a g e | 19
- To show the learned MAC address(es) on interface fastEthernet 0/2:
SW1# show mac address-table interface fastEthernet 0/2
Mac Address Table
------------------------------------------------------------------
Vlan Mac Address Type Ports
------- ------------------- -------------- --------
1 00b0.3c46.9e4c DYNAMIC Fa0/2
Total Mac Addresses for this criterion: 1
- To show on which interface and Vlan the MAC address (00c0.4c78.5c3f) is connected:
SW1# show mac address-table address 00c0.4c78.5c3f
Mac Address Table
------------------------------------------------------------------
Vlan Mac Address Type Ports
------- ------------------- -------------- --------
1 00c0.4c78.5c3f DYNAMIC Fa0/3
Total Mac Addresses for this criterion: 1
- To show the learned entries on VLAN 1:
SW1# show mac address-table vlan 1
Mac Address Table
------------------------------------------------------------------
Vlan Mac Address Type Ports
------- ------------------- -------------- --------
1 00a0.2f4c.8b2d DYNAMIC Fa0/1
1 00b0.3c46.9e4c DYNAMIC Fa0/2
1 00c0.4c78.5c3f DYNAMIC Fa0/3
1 00d0.5e83.6f7a STATIC Fa0/4
Total Mac Addresses for this criterion: 4
- To show the default MAC address Aging-time:
SW1#show mac-address-table aging-time Mac address aging time 300
P a g e | 20
- To change the default MAC address Aging-time to be (600) seconds instead of (300):
SW1(config)# mac address-table aging-time 600
SW1# show mac address-table aging-time Mac address aging time 600
- To show the CAM table size:
SW1# show mac address-table count
Mac Entries for Vlan: 1
----------------------------------
Dynamic Address Count : 3
Static Address Count : 1
Total Mac Addresses : 4
Total Mac address Space Available: 4810
- As shown from the output, the MAC address totals are shown for each active VLAN
on the switch (only VLAN 1 in this example), this can give you a good idea of the size
of the CAM table and how many hosts are using the network.
- To clear the entries of the CAM table manually:
SW1# clear mac address-table [dynamic | static] [address “mac-address”] [interface “type mod/num.”] [vlan “vlan-id”]
- To clear all the dynamically learned CAM table entries:
SW1# clear mac address-table dynamic SW1# show mac address-table Mac Address Table
------------------------------------------------------------------
Vlan Mac Address Type Ports
------- ------------------- ----------- --------
1 00d0.5e83.6f7a STATIC Fa0/4 Total Mac Addresses for this criterion: 1
P a g e | 21
- Frequently, you need to know where a user with a certain MAC address is connected.
- In large network, discerning at which switch and switch port a MAC address can be
found might be difficult.
- To do so, follow the following steps:
Step 1 Start at the network’s center (at the core switch as will be explained later in
Chapter 11), and display the CAM table entry for that specific MAC address.
Step 2 Look at the switch port shown in the entry and find the neighboring switch
connected to that port using CDP neighbor information.
Step 3 Move to that switch and repeat the CAM table process.
Step 4 Keep moving from switch to switch until you reach the edge of the network
where the MAC address is connected.
TCAM Table Operation:
- The TCAM in a switch is more or less self-sufficient.
- ACLs are compiled or merged automatically into the TCAM, so there is nothing to
configure.
- The only concept you need to be aware of is how the TCAM resources being used.
- TCAMS have a limited number of usable Mask, Value Patterns, and LOU entries.
- If ACLs grow to be large or many Layer 4 operations are needed, the TCAM tables
and registers can overflow.
- If that happens while you are configuring an ACL, the switch will generate syslog
messages that flag the TCAM overflow situation as it tries to compile the ACL into
the TCAM entries.
P a g e | 22
Chapter 2 Switch Port Configuration
Ethernet Concepts:
- Ethernet scales to support increasing bandwidths, the Ethernet medium should be
chosen to match the need at each point in the campus network.
- As network bandwidth requirements grow, you can scale the links between access
(edge), distribution, and core layers to match the load (These layers will be discussed
later in Chapter 11 Campus Network Design).
- Other network media technologies are available rather than Ethernet such as:
Fiber Distribution Data Interface (FDDI).
Copper Distribution Data Interface (CDDI).
Token Ring.
Asynchronous Transfer Mode (ATM).
- Although some networks still use these media, Ethernet has merged as the most
popular choice in installed networks.
- Ethernet is chosen because of its:
Low cost.
Market availability.
Scalability to higher bandwidths.
a) Ethernet (10 Mbps):
- Ethernet Is a LAN technology based on the Institute of Electrical and Electronics
Engineering (IEEE) 802.3 standard and is operating at speed of 10 Mbps.
- Ethernet in its most basic form is a shared media that becomes both a collision domain
and a broadcast domain.
P a g e | 23
Ethernet Network (Shared Media)
- As the number of users on the shared media increases, the probability that a user is
trying to transmit data at any given time also increases.
- When one user transmits at about the same time as another user, a “collision” occurs.
- In other words, both users cannot transmit data at the same time if they both are
sharing the same network media.
- Ethernet is based on the Carrier Sense Multiple Access with Collision Detection
(CSMA/CD) algorithm, which requires that the transmitting stations back off for a
random period of time when a collision occurs.
- If a host is waiting its turn to send data, it cannot send and receive at the same time,
this is called half duplex mode of operation.
- When the number of users increases on an Ethernet segment, the number of hosts
likely to be sending data at a given time increases, so the probability of collisions
increases.
- So, as an Ethernet segment becomes more crowded, it becomes more inefficient.
- Ethernet switching solves this problem by offering fully dedicated 10 Mbps bandwidth
to each of its ports.
- Because the switch offers dedicated bandwidth for connections between the end users
hosts (sometimes called devices or stations) connected to its ports, any host-to-host
traffic would see improved performance if compared to the shared media Ethernet.
- Because Ethernet switches can remove the possibility of collisions, hosts don’t have to
listen to each other to take a turn sending data on the wire.
P a g e | 24
- Instead, hosts can operate in full duplex mode of operation, where they can send and
receive data simultaneously.
Ethernet Switch Network
- Full duplex mode increases the network performance, with a net throughput of 10
Mbps in each direction, or 20 Mbps total throughput on each port.
- Throughput Is the ratio between the number of successfully transmitted packets to
the total number of packets transmitted.
- Another consideration when dealing with 10 Mbps Ethernet is the physical cabling.
- Ethernet cabling involves the use of Unshielded Twisted-Pair (UTP) wiring (10 Base-
T Ethernet).
- UTP cabling usually restricted to an end-to-end distance of 100 meters between active
devices, keeping the cable lengths as short as possible reduces noise and crosstalk
when many cables are bundled together.
- In a campus network environment, Ethernet can be found in the access layer, between
the end user devices (hosts) and the access-layer switch.
- However, in modern networks, faster generations of Ethernet are used instead.
- Ethernet typically is not used at either the distribution or the core layer due to its
relatively low bandwidth.
Note: - Ethernet types (such as 10BASE-2, 10BASE-5, 10BASE-F, and so on) uses
other cabling technologies (such as coaxial cables) but only 10 BASE-T with
UTP wiring is the most commonly used.
P a g e | 25
b) Fast Ethernet (100 Mbps):
- Fast Ethernet Is a LAN technology based on the IEEE 802.3u standard and is
operating at 100 Mbps.
- Fast Ethernet generally is used to connect end user hosts to the access-layer switch.
- The campus network can use Fast Ethernet to link access and distribution layer
switches.
- Cabling for Fast Ethernet can involve either UTP, STP, or fiber optic cables.
- The following table lists the cabling specifications for Fast Ethernet that define the
media types and distances.
Technology Wiring Type Pairs Maximum Distance
100BASE-TX EIA/TIA Category 5 (or higher). 2 100 m
100BASE-T2 EIA/TIA Category 3, 4, 5. 2 100 m
100BASE-T4 EIA/TIA Category 3, 4, 5. 4 100 m
100BASE-FX
Multi-mode Fiber (MMF): 62.5-µm
core, 125-µm outer cladding (62.5/125) 1
400 m half-duplex
2 km full-duplex
Single-mode Fiber (SMF): 8-micron
core. 1 10 km
- Fast Ethernet can provide up to 100 Mbps in each direction for 200 Mbps total
throughput in both directions (full duplex).
- The maximum throughput is possible only when one device (workstation, server,
router, or another switch) is connected directly to a switch port.
- In addition, the devices at each end of the link must both support full duplex operation,
allowing each to send data without collisions.
- Fast Ethernet specification also offers backward compatibility to support traditional 10
Mbps Ethernet.
- In the case of 100BASE-TX, switch ports are often called “10/100” ports.
- To provide this support, the switch port and the end user host of a network connection
should be configured both to operate at the 10 Mbps speed and same duplex.
P a g e | 26
- The link speed is determined by electrical signaling so that either end of a link can
determine what speed the other end is trying to use during auto-negotiation.
- When both ends of a link are configured to auto-negotiate, they will use the highest
speed that is common to them.
- A link’s duplex mode is also negotiated through an exchange of information.
- This means that for one end to successfully auto-negotiate the duplex mode, the other
end also must be set to auto-negotiate.
- Otherwise, one end of a link will never see duplex information from the other end and
will not be capable of determining the correct mode to use.
Note: - If duplex auto-negotiation fails, a switch port always falls back to its default
half-duplex setting.
- Be aware of the duplex mismatch when both ends of a link (the switch port
and the host) are not set for auto-negotiation.
- Most hosts are configured to default (auto-negotiation) for speed and duplex.
- During a mismatch, one host will use full-duplex while the other host will
use half-duplex.
- The result is that the half-duplex host will detect a collision when both ends
send data, then it will back off appropriately.
- The full-duplex host will assume that it has the right to transmit at any time,
it will not stop and wait for any reason, this cause errors on the link and poor
response times between the hosts.
- During the auto-negotiation process, the full-duplex mode is always has a higher
priority than the half-duplex if both devices can support more than one technology.
- So, 100BASE-TX full-duplex is higher than 100BASE-TX half-duplex, followed by
10BASE-T full-duplex then 10BASE-T half-duplex.
c) Gigabit Ethernet (1000 Mbps):
- Gigabit Ethernet Is a LAN technology based on the IEEE 802.3z (Gigabit over
fiber) and IEEE 802.3ab (Gigabit over copper) standards and is
operating at 1 Gbps (1000 Mbps) speed.
- The physical layer has been modified to increase data transmission speeds.
P a g e | 27
- Two technologies were merged to gain the benefits of each:
The IEEE 802.3 Ethernet standard.
The American National Standards Institute (ANSI) X3T11 FiberChannel.
- The IEEE 802.3 provided the foundation of frame format, full-duplex, and other
Ethernet characteristics.
- FiberChannel provided a base of high-speed ASICs, optimal components,
encoding/decoding, and serialization mechanisms.
- The resulting protocol is termed IEEE 802.3z Gigabit Ethernet.
- Gigabit Ethernet supports several cabling types (UTP, STP, MMF, and SMF) referred
to as 1000BASE-T or 1000BASE-X.
- The following table lists the cabling specifications for each type:
Gigabit Ethernet
Standard Cabling Type Pairs
Maximum
Distance
1000BASE-TX Shielded Twisted Pair (STP) 4 100 m
1000BASE-T EIA/TIA Category 5 (or higher) UTP 4 100 m
1000BASE-SX MMF with 62.5-µm core. 1 275 m
MMF with 50-µm core. 1 550 m
1000BASE-LX/LH
MMF with 62.5-µm core. 1 550 m
MMF with 50-µm core. 1 550 m
SMF with 9-µm core, 1300-nm laser. 1 10 km
1000BASE-ZX SMF with 9-µm core, 1550-nm laser. 1 70 km
SMF with 8-µm core, 1550-nm laser. 1 100 km
- In a campus network, you can use Gigabit Ethernet to:
Connect individual devices to a switch.
Connect two switches.
P a g e | 28
- The “Gigabit over copper” solution that the 1000BASE-T media provides is based on
the IEEE 802.3ab standard.
- Most Gigabit Ethernet switch ports used between switches are fixed at 1 Gbps.
- However, other switch ports can support a fallback to Fast Ethernet or Legacy Ethernet
speeds (10 Mbps, 100 Mbps, or 1000 Mbps).
- These ports are often called 10/100/1000 ports to denote the triple speed.
- Here, the auto-negotiation supports the same priority scheme as Fast Ethernet,
although 1000BASE-T full-duplex becomes the highest priority, followed by
1000BASE-T half-duplex.
Note: - Gigabit Ethernet’s port duplex mode always is set to full-duplex on Cisco
switches, so duplex auto-negotiation is not possible.
d) 10 Gigabit Ethernet (10 Gbps):
- 10 Gigabit Ethernet Is a LAN standard based on the IEEE 802.3ae standard and is
operating at 10 Gbps speed.
- To meet the demand for aggregating many Gigabit Ethernet links over a single
connection, 10 Gigabit Ethernet was developed.
- Again, the Layer 2 characteristics of Ethernet have been preserved, the familiar 802.3
frame format and size, along with the MAC protocol, remain unchanged.
- The 10 Gigabit Ethernet (also known as 10 GbE) and the IEEE 802.3ae standard differ
from their predecessors only at the physical layer (PHY), 10 GbE operates only at full-
duplex mode of operation.
- The standard defines several different transceivers that can be used as Physical Media
Dependent (PMD) interfaces, these are classified into the following:
LAN PHY Interconnects switches in a campus network, predominantly in the
core layer.
WAN PHY Interfaces with existing Synchronous Optical Network (SONET)
or Synchronous Digital Hierarchy (SDH) networks typically found
in the Metropolitan Area Networks (MAN).
P a g e | 29
- The PMD interfaces also have a common labeling scheme, much as Gigabit Ethernet.
- Gigabit Ethernet uses 1000BASE-X to indicate the media type, 10 Gigabit Ethernet
uses 10GBASE-X.
- The following table lists the different PMDs defined in the 10 GbE standard along
with the type of fiber optic cable and distance limitations.
PMD Type Fiber Medium Maximum
Distance
10GBASE-SR/SW
(850-nm serial)
MMF with 50-µm core. 66 m
MMF with 50-µm core (2GHz km model
bandwidth). 300 m
MMF with 62.5-µm core. 33 m
10GBASE-LR/LW
(1310-nm serial) SMF with 9-µm core. 10 km
10GBASE-ER/EW
(1550-nm serial) SMF with 9-µm core. 40 km
10GBASE-
LX4/LW4
(1310-nm WWDM)
MMF with 50-µm core. 300 m
MMF with 62.5-µm core. 300 m
SMF with 9-µm core. 10 km
10GBASE-CX4 Copper: CX4 with Infiniband connectors. 15 m
- All the fiber-optic PMDs can be used as either a LAN PHY or a WAN PHY, except
for the 10GBASE-LX4, which is only a LAN PHY.
- Be aware that the long-wavelength PMDs carry a significantly greater expense than
the others.
- Transceiver types are denoted by a two-letter suffix.
- The first letter specifies the wavelength used:
S Short wavelength.
L Long wavelength.
E Extra-long wavelength.
P a g e | 30
- The second letter specifies the PHY type:
R LAN PHY.
W WAN PHY.
- For LX4 and LW4:
L Refers to a long wavelength.
X Refers to the coding used, and (4) refers to the number of wavelengths
transmitted.
WWDM Wide-Wavelength Division Multiplexing.
- Cisco Catalyst switches supported 10 Gigabit Ethernet PMDs in the form of
XENPAK, X2, and SFP+ transceivers.
- Generally, the X2 form factor is smaller than the XENPAK, and the SFP+ is smaller
still, allowing more port density on a switch module.
Connecting Switches and Devices:
- Switch deployment in a network involves two steps:
Physical Connectivity.
Switch Configuration.
Fast Ethernet: Port Cables and Connectors:
- Catalyst switches support a variety of network connections, including all forms of
Ethernet.
- In addition, Catalyst switches support several types of cabling including:
Copper wires (UTP or STP).
Optical Fiber Cables.
P a g e | 31
- Fast Ethernet (100BASE-FX) ports use two-strands Multimode Fiber (MMF) with
MT-RJ or SC connectors to provide connectivity.
- The MT-RJ connectors are small and modular, each containing a pair of fiber-optic
strands.
- The connector snaps into position, but you must press a tab to remove it.
- The SC connectors snap in and out of the switch port connector as the connector is
pushed in or pulled out.
- One fiber strand is used as a transmit path and the other strand as a receive path.
- The transmit fiber on one switch should connect to the receive fiber on the other end.
- All Catalyst switch families support 10/100 autosensing (using Fast Ethernet auto-
negotiation) and 10/100/1000 autosensing for Gigabit Ethernet.
- These ports use RJ-45 connectors on Category 5 (or
higher) UTP or STP cabling to complete the connections.
- These ports can connect to other Ethernet autosensing
devices.
- UTP cabling is arranged so that RJ-45 pins 1,2 and 3,6 form
two twisted pairs.
- These pairs connect straight-through to the far end host.
- The pinout standard used here is EIA/TIA T568B.
- STP cabling has a layer of shielded insulation to be more
immune to noise and reduce the electromagnetic interference
(EMI).
P a g e | 32
- To connect two 10/100 switch ports back to back, as in an
access-layer to distribution-layer link, you must use a
crossover cable.
- In this case, the RJ-45 pins 1,2 on one end connects to 3,6 on
the other end, and 3,6 on one end connects to 1,2 on the other
end.
Note: - UTP and STP connections use only pairs 1,2 and 3,6.
- It is not a good practice to connect only 2 pairs.
- To be compatible with the new IEEE 802.3ab standard for Gigabit Ethernet
over copper (1000BASE-T), you must use all four pairs end-to-end.
Gigabit Ethernet: Port Cables and Connectors:
- Gigabit Ethernet connections take a different approach by providing modular
connectivity options.
- Catalyst switches with Gigabit Ethernet ports have standardized rectangular openings
that can accept:
Gigabit Interface Converter (GBIC).
Or
Small Form Factor Pluggable (SFP).
- The (GBIC) and (SFP) modules provide the media personality for the port so that
various cable media can connect.
- In this way, the switch chassis is completely modular and requires no major change to
accept a new media type.
- Instead, the appropriate module is hot-swappable and is plugged into the switch to
support the new media.
- (GBIC) modules can use:
SC fiber-optic connectors.
RJ-45 copper wire connectors.
P a g e | 33
- (GBIC) and (SFP) modules are available for the following Gigabit Ethernet media:
1000BASE-SX Short-wavelength connectivity using SC fiber connectors and
MMF for distance up to 550 m.
1000BASE-LX/LH - Long-wavelength/long-haul connectivity using SC fiber
connectors and either MMF or SMF.
- MMF can be used for distances up to 550 m.
- SMF can be used to distances up to 10 km.
- MMF requires a special mode-conditioning cable for fiber
distances less than 100 m or greater than 300 m.
- This keeps the (GBIC) from overdriving the far-end
receiver on a short cable and lessens the effect of
differential mode delay on a long cable.
1000BASE-ZX - Extended-distance connectivity using SC fiber connectors and
SMF.
- Works for distance up to 70 km and even to 100 km when
used with premium-grade SMF.
P a g e | 34
GigaStack - Uses a proprietary connector with a high-data-rate copper cable
with enhanced signal integrity and electromagnetic interference
(EMI) performance; provides a GBIC-to-GBIC connection
between stacking Catalyst switches or between any two Gigabit
switch ports over a short distance.
- The connection is full-duplex if only one of the two stacking
connectors is used, if both are used, they each become half-duplex
over a shared bus.
1000BASE-T - Supports an RJ-45 connector for four-pair UTP or STP cabling,
works for distances up to 100 m.
Note: - You must use a four-pair Category 5 (or higher) UTP or STP Cross-over
cable to connect two (1000BASE-T) switch ports back to back.
- In this case, RJ-45 pins 1,2, 3,6, 4,5, and 7,8 on one end are connecting to
pins 3,6, 1,2, 7,8, and 4,5 respectively on the other end.
Caution: - The fiber-based modules always have the receive fiber on the left
connector and the transmit fiber on the right connector, as you face the
connectors.
- These modules could produce invisible laser radiation from the transmit
connector. Therefore, always keep unused connectors covered with the
rubber plugs, and don’t ever look directly into the connectors.
P a g e | 35
Switch Port Configuration:
1) Selecting Ports to Configure:
- You can configure individual port or a group of ports on a switch with various
information and settings.
- Before you can modify port settings, you must select one or more switch ports.
- Catalyst switches running Cisco IOS refers to the switch ports as “interfaces”.
- To select a single switch port to configure, use the following command:
Switch(config)# interface “type module/number”
- “type” The port is identified by one of its Ethernet type:
fastEthernet.
gigabitEthernet.
tengigabitEthernet.
vlan.
- “module/number” - The physical module were the port is located, and the port
number within the module.
Note: - Some switches, such as Catalyst 2960 and 3560, don’t have multiple
modules.
- For those models, ports have a module number of 0 (zero).
- To select the Fast Ethernet 0/12 interface for configuration, use the following
command:
Switch(config)# interface fastEthernet 0/12
- The Catalyst 3750 switch is also a fixed-configuration switch, but it can be stacked
with other switches in the 3750 family.
- Interfaces are referenced by the stack number, module number, and port number.
- For example, port 24 on the switch at position (2) in the stack can be referenced as
Fast Ethernet 2/0/24.
P a g e | 36
- The Catalyst IOS also allows multiple interfaces to be selected in a single pass through
the following command:
Switch(config)# interface range “type mod/num.” [, “type mod/num.” , …….]
- After you select the range, any interface configuration commands entered are applied
to each of the interfaces in the range.
- For example, to select interfaces Fast Ethernet 1/0/3, 1/0/7, 1/0/9, and 1/0/48 for
configuration, use the following command:
Switch(config)# interface range fastEthernet 1/0/3 , fastEthernet 1/0/7 , fast Ethernet 1/0/9 , fastEthernet 1/0/48
- You also can select a continuous range of ports, from beginning interface to an ending
interface.
- Enter the interface type and module, followed by the beginning and ending port
number separated by a dash with spaces:
Switch(config)# interface range “type module/first-num. – last-num.”
- For example, you can select all 48 Fast Ethernet interfaces at the position (1) in the
stack using the following command:
Switch(config)# interface range fastEthernet 1/0/1 - 48
- Finally, sometimes you need to make configuration to several groups or ranges of
ports at the same time.
- You can define a macro that contains a list of interfaces or ranges of interfaces or both.
- Then, you can invoke the “interface-range” macro just before configuring the port
settings.
- This applies the port settings to each interface that is identified by the macro.
- The steps for defining and applying this macro are as follows:
Step 1 Define the macro name and specify as many lists and ranges of interfaces as
needed.
P a g e | 37
Switch(config)# define interface-range “macro-name” “type mod/num.” [, “type mod/num.” …. ] [“type mod/first-num. – last-num.”] [……]
Step 2 Invoke the macro called “macro-name” just as you would with a regular
interface, just before entering any interface-configuration commands:
Switch(config)# interface range macro “macro-name”
- For example, suppose that you need to configure the following interfaces:
Gigabit Ethernet 2/0/1, 2/0/3 through 2/0/5, 3/0/1, 3/0/10, and 3/0/32 through
3/0/48 with a set of identical configurations.
- You can use the following commands to define and apply a macro, respectively:
Switch(config)# define interface-range MyGroup gig 2/0/1 , gig 2/0/3 – 5 , gig 3/0/1 , gig 3/0/10 , gig 3/0/32 – 48
Switch (config)# interface range macro MyGroup
Note: - Remember to surround any commas and hyphens with spaces when you
enter either “interface range” or “define interface-range” commands.
2) Identifying Ports:
- You can add a text describing a switch port to identify it.
- The port description is included when showing the switch configuration and interface
information.
- To assign a description or a comment to a switch port, use the following interface
configuration command:
Switch(config-if)# description “text”
- “text” Can have embedded spaces between words, if needed.
- To remove a description from a switch port, use the following command:
Switch(config-if)# no description “text”
P a g e | 38
- For example, add a description to the interface Fast Ethernet 1/0/10:
Switch(config)# interface fastEthernet 1/0/10 Switch(config-if)# description The CEO Port, Room 10
3) Port Speed:
- You can assign a specific speed to switch ports through an interface configuration
command.
- Fast Ethernet 10/100 ports can be set to speeds of:
10 Mbps.
100 Mbps.
Auto (the default) for auto-negotiation mode.
- Gigabit Ethernet GBIC ports always are set to a speed of 1000 Mbps.
- 1000BASE-T ports can be set to speeds of:
10 Mbps.
100 Mbps.
1000 Mbps.
Auto (the default).
Note: - If a 10/100 or 10/100/1000 port is assigned a speed of Auto, both its speed and
duplex mode will be negotiated.
- To configure a specific speed on a particular switch Ethernet port, use the following
interface configuration command:
Switch(config-if)# speed {10 | 100 | 1000 | auto}
4) Port Duplex Mode:
- You can also assign a specific link mode to Ethernet-based switch ports
P a g e | 39
- Therefore, the port can operate in:
Half-duplex.
Full-duplex.
Auto (for auto-negotiation).
- Auto-negotiation is allowed only on RJ-45 Fast Ethernet and Gigabit Ethernet ports.
- In this mode, the port participates in a negotiation by attempting full-duplex operation
first, and then half-duplex operation if full-duplex is not successful.
- The auto-negotiation process repeats whenever the link status changes.
Note: - A 10 Mbps Ethernet (fixed speed) link defaults to half duplex mode.
- A 100 Mbps Fast Ethernet (dual speed 10/100) link defaults to full-duplex
mode.
- To configure the link mode of operation on a switch port, use the following command:
Switch(config-if)# duplex {auto | full | half}
Note: - It is recommended to use the default auto-negotiation for speed and duplex
mode.
- If you are going to configure speed and duplex (no auto-negotiation), be
aware that both ends of a link must be configured for the same speed and
duplex mode. Otherwise, a mismatch will occur.
- For example, configure the following:
The 10/100/100 interface Gigabit Ethernet 3/1 for auto-negotiation for the speed
and speed and duplex mode (to back to the default configuration).
The 10/100/1000 interface Gigabit Ethernet 3/2 for speed 100 Mbps and full-
duplex.
Switch(config)# interface gig 3/1 Switch(config-if)# speed auto Switch(config-if)# duplex auto
P a g e | 40
Switch(config)# interface gig 3/2 Switch(config-if)# speed 100 Switch(config-if)# duplex full
Enable and Verify Switch Ports:
- If a port is not enabled or activated automatically, use the following command:
Switch(config-if)# no shutdown
- To show a specific port’s current speed and duplex state, use the following command:
Switch# show interfaces “type mod/num.”
- To show a brief summary of all interfaces status, use the following command:
Switch# show interfaces status
Troubleshooting Port Connectivity:
- To troubleshoot problems with a switch port, use the following troubleshooting
techniques:
a) Looking for the Port State:
- For example, to show information about the Fast Ethernet 0/10:
Switch# show interfaces fastEthernet 0/10 FastEthernet0/10 is up, line protocol is up (connected) Hardware is Lance, address is 0007.ec78.570a (bia 0007.ec78.570a) BW 100000 Kbit, DLY 1000 usec, reliability 255/255, txload 1/255, rxload 1/255 !Lines are omitted for brevity
P a g e | 41
- The port’s current state is given in the first line as marked in output of the previous
show command.
- The first “up” Shows the state of the port’s physical link.
Note: - If this is shown as “down”, the link is physically disconnected or a link can’t
be detected.
- The second “up” Shows the Layer 2 status.
Note: - If the state is given “errdisable”, the switch has detected an error condition
on this port and has automatically disabled it.
b) Looking for Speed and Duplex Mismatch:
- If a user noticed slow response time or low throughput on a 10/100 or 10/100/1000
switch port, the problem could be a mismatch of the port speed or duplex mode
between the switch and the host NIC.
- This is particularly common when one end of the link is set to auto-negotiate the link
settings and the other end is not.
- Use the following “show” command for interface Fast Ethernet 0/10 (for example) and
look for any error counts that are greater than 0:
Switch# show interfaces fastEthernet 0/10 FastEthernet0/10 is up, line protocol is up (connected) Hardware is Lance, address is 0007.ec78.570a (bia 0007.ec78.570a) MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation ARPA, loopback not set Keepalive set (10 sec) Auto-duplex (Half), Auto Speed (100), 100BASETX/FX ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:08, output 00:00:05, output hang never Last clearing of "show interface" counters never Queueing strategy: fifo Output queue :0/40 (size/max) 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 73201 bits/sec, 43 packets/sec 956 packets input, 193351 bytes, 0 no buffer
P a g e | 42
Received 11534 broadcasts, 249765 runts, 0 giants, 0 throttles 249765 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 0 watchdog, 0 multicast, 0 pause input 0 input packets with dribble condition detected 23573457 packets output, 26354390 bytes, 0 underruns 0 output errors, 0 collisions, 10 interface resets 0 babbles, 0 late collision, 0 deferred 0 lost carrier, 0 no carrier 0 output buffer failures, 0 output buffers swapped out
- The switch port is set to auto-negotiate the speed and duplex mode.
- It has decided to use speed 100 Mbps and half duplex mode.
- Notice that, there are many “runts” (packets that were truncated before they were fully
received) and “input errors”.
- These are the symptoms that a setting mismatch exists between the two ends of the
link.
- Because this port is auto-negotiating the link speed, it must have detected an electrical
signal that indicated 100 Mbps in common with the host.
- However, the host most likely was configured for 100 Mbps speed and full-duplex
mode (no its default auto-negotiation).
- The switch was incapable of exchanging duplex information, so it fell back to its
default of “half-duplex”.
Note: - Always make sure that both ends of a link are set to the same speed and
duplex if auto-negotiation will not be used.
Managing Error Conditions on a Switch Port:
- A network-management application can be used to detect an error condition on a
switch port.
- A switch can be pulled periodically so that its port error counters can be examined to
see whether an error condition has occurred.
- If so, an alert can be issued so that someone can take action to correct the problem.
- Catalyst switches can detect error conditions automatically, without any further help.
- If a serious error occurs on a switch port, that port can be shutdown automatically until
someone manually enables the port again or until a predetermined time has elapsed.
P a g e | 43
Detecting Error Conditions:
- By default, a Catalyst switch detects an error condition on every switch port for every
possible cause.
- If an error condition is detected, the switch port is put into the “errdisable” state and is
disabled.
- You can tune this behavior on a global basis so that only certain causes trigger any
port being disabled.
- Use the following command, where the “no” keyword is added to disable the specified
cause:
Switch(config)# [no] errdisable detect cause [all | “cause-name”]
- You can repeat this command to enable (without adding “no” keyword) or disable
(with adding “no” keyword) more than one cause.
Note: - You will understand every errdisable cause in details in later chapters.
- One of the following triggers the errdisable state:
All Detects every possible cause.
arp-inspection Detects errors with dynamic ARP inspection.
bpduguard Detects when a spanning-tree bridge protocol data unit (BPDU)
is received on a port configured for STP PortFast.
channel-misconfig Detects an error with an EtherChannel bundle.
dhcp-rate-limit Detects an error with DHCP snooping.
dtp-flap Detects when trunking encapsulation is changing from one type
to another.
gbic-invalid Detects the presence of an invalid GBIC or SFP module.
ilpower Detects an error with offering inline power.
l2ptguard Detects an error with Layer 2 Protocol Tunneling.
link-flap Detects when the port link state is “flapping” between the up
and down states.
loopback Detects when an interface has been looped back.
pagp-flap Detects when an EtherChannel bundle’s ports no longer have
consistent configurations.
P a g e | 44
psecurity-violation Detects conditions that trigger port security configured on a
port.
rootguard Detects when an STP BPDU is received from the root bridge on
an unexpected port.
security-violation Detects errors related to port security.
storm-control Detects when a storm control threshold has been exceeded on a
port.
udld Detects when a link is seen to be unidirectional (data passing in
only one direction).
unicast-flood Detects conditions that trigger unicast flood blocking on a port
vmps Detects errors when assigning a port to a dynamic VLAN
through VLAN membership policy server (VMPS).
Automatically Recover from Error Conditions:
- By default, ports put into the “errdisable” state must be re-enabled manually.
- This is done by issuing the following commands on an interface:
Switch(config-if)# shutdown Switch(config-if)# no shutdown
Note: - Before you re-enable a port from the “errdisable” condition, you always
should determine the cause of the problem so that the “errdisable” condition
doesn’t occur again.
- You can decide to have a switch automatically re-enable an “errdisable” port if it is
more important to keep the link up until the problem can be resolved.
- To automatically re-enable an “errdisable” port, you first must specify the “errdisable”
causes that can be re-enabled.
- Use the following command with a “cause-name” from the preceding table:
Switch(config)# errdisable recovery cause [all | “cause-name”]
- If any “errdisable” causes are configured for automatic recovery, the “errdisable” port
stays down for 300 seconds, by default.
- To change the recovery timer, use the following global configuration command:
Switch(config)# errdisable recovery interval “seconds”
P a g e | 45
Note: - You can set the interval from 30 to 86,400 seconds (24-hours).
- For example, to configure all switch ports to be re-enabled automatically in 1 hour
after a port security violation has been detected:
Switch(config)# errdisable recovery cause psecurity-violation Switch(config)# errdisable recovery interval 3600
Note: - Remember that the errdisable causes and automatic recovery are configured
globally, means that the settings apply to all switch ports.
P a g e | 46
Chapter 3 VLANs and Trunks
Virtual LANs (VLANs):
- Consider a network design that consists of Layer 2 devices only.
- For example, this design could be:
Ethernet switch with many ports.
Network with several interconnected Ethernet switches.
Flat Network Topology
- Flat Network Topology A full Layer 2 only switched network.
- A flat network is a single broadcast domain, such that every connected host sees every
broadcast frame that is transmitted.
- As the number of hosts on the network increases, the number of broadcasts also
increases.
- A switched environment offers the technology to overcome flat network limitations.
- Switched networks can be subdivided into VLANs.
- VLAN Is a single broadcast domain where hosts can communicate using L2 frames.
P a g e | 47
- All hosts connected to a VLAN, receive broadcasts sent by other VLAN members.
- However, hosts connected to a different VLAN, will not receive those broadcasts.
- Naturally, VLAN members can receive unicast packets directed toward them from the
same VLAN other members.
- A VLAN consists of hosts defined as members, communicating as a logical network
segment.
- A VLAN can have connected members located anywhere in the campus network, as
long as VLAN connectivity is provided among all members.
- Layer 2 switches are configured with a VLAN mapping and provide the logical
connectivity among the VLAN members.
- The following figure shows how a VLAN can provide logical connectivity between
switch ports.
- One host connected to Switch-A is assigned to VLAN 1, whereas another host is
assigned to VLAN 100.
- In this case, no communication can occur between VLAN 1 and VLAN 100.
- Both ends of the link between switches are assigned to VLAN 1.
- One host connected to Switch-B also assigned to VLAN 1.
- Because there is end-to-end connectivity of VLAN 1, any of the VLAN 1 member
hosts can communicate as if they were connected to a physical network segment, the
same with VLAN 100.
P a g e | 48
VLAN Membership:
- When a VLAN is provided at a switch, the end-user must have some means of gaining
membership to that VLAN.
- Two membership methods exist on Cisco Catalyst switches:
Static VLANs assignment.
Dynamic VLANs assignment.
a) Static VLANs assignment:
- Static VLANs offer “port-based” membership, in which switch ports are assigned to
specific VLANs.
- End-user hosts can become members is a VLAN based on the physical switch port to
which they are connected.
- No handshaking or unique VLAN membership protocol is needed for the end-user,
they automatically assume VLAN connectivity when they connect to a switch port.
- Normally, the end-user host is not even aware that the VLAN exists.
- The switch port and its VLAN simply are viewed and used as any other network
segment, with other “locally attached” members on the wire.
- Switch ports are assigned to VLANs by the manual intervention of the network
administrator, hence the static nature.
- Each port receives a Port VLAN ID (PVID) that associates it with a VLAN number.
- The ports on a single switch can be assigned and grouped into many VLANs.
- Even though two hosts are connected to the same switch, traffic will not pass between
them if they are connected to ports on two different VLANs.
- To perform this function, you could use a Layer 3 device (a router or multilayer
switch) to route packets between the two different VLANs.
- The static Port-to-VLAN membership normally is handled in the hardware with
Application-Specific Integrated Circuits (ASIC) in the switch.
- This membership provides good performance because all port mappings are done at
the hardware level, with no complex table lookups needed.
P a g e | 49
Configuring Static VLANs:
- By default, all switch ports are assigned to VLAN 1 are set to be a VLAN type of
Ethernet, and have a Maximum Transmission Unit (MTU) size of 1500 bytes.
- First, the VLAN must be created on the switch, if it doesn’t already exist.
- Then, the VLAN must be assigned to specific switch ports.
- VLANs always are referenced by a VLAN ID (sometimes called VLAN number),
which can range from 1 to 1005.
- VLANs 1 and 1002-1005 automatically are created and are set aside for special uses.
Note: - VLAN 1 is the default VLAN for every switch port.
- VLANs 1002 to 1005 are reserved for legacy functions related to Token
Ring and FDDI switching.
- Catalyst IOS switches can also support extended-range VLANs, in which the
VLAN ID can be 1 to 4094, for compatibility with IEEE 802.1Q standard.
- To configure static VLANs, begin by defining the VLAN using the following
configuration commands:
Switch(config)# vlan “vlan-id” Switch(config-vlan)# name “vlan-name”
- The “vlan-id” is immediately created and stored in the database, along with a
descriptive text string defined by “vlan-name” (up to 32 characters with no embedded
spaces).
- The “name” command is optional, means that if it is not used, the default VLAN name
is of the form VLAN xxx, where xxx represents the VLAN ID.
Note: - If you need to include spaces to separate words in the VLAN name, use
underscore or dash characters instead.
- For example, to create VLAN 10 with the name “Engineering-Department-VLAN”,
use the following commands:
Switch(config)# vlan 10 Switch(config-vlan)# name Engineering-Department-VLAN
P a g e | 50
- To delete VLAN 10 from the switch configuration, use the following command:
Switch(config)# no vlan 10
- Next, you should assign one or more switch ports to the VLAN by using the following
commands:
Switch(config)# interface “type mod/num.” Switch(config-if)# switchport mode access Switch(config-if)# switchport access vlan “vlan-id”
- Access Switch Ports Are switch ports that are connected to end-user hosts.
- For example, to assign VLAN 10 to switch interface Fast Ethernet 0/5, use the
following commands:
Switch(config)# interface fastEthernet 0/5 Switch(config-if)# switchport mode access Switch(config-if)# switchport access vlan 10
Verifying Static VLANs:
- To verify the VLAN configuration, use the following command to show a list of all
VLANs defined in a switch, along with ports that are assigned to each VLAN:
Switch# show vlan VLAN Name Status Ports --------- -------------------------------- --------- ------------------------------- 1 default active Fa0/1, Fa0/2, Fa0/3, Fa0/4 Fa0/6, Fa0/7, Fa0/8, Fa0/9 Fa0/10, Fa0/11, Fa0/12, Fa0/13 Fa0/14, Fa0/15, Fa0/16, Fa0/17 Fa0/18, Fa0/19, Fa0/20, Fa0/21 Fa0/22, Fa0/23, Fa0/24, Gig0/1 Gig0/2 10 Engineering-Department-VLAN active Fa0/5 1002 fddi-default act/unsup 1003 token-ring-default act/unsup 1004 fddinet-default act/unsup 1005 trnet-default act/unsup
P a g e | 51
b) Dynamic VLANs assignment:
- Dynamic VLANs provide membership based on the MAC address of an end-user host.
- A network administrator must assign the host’s MAC address to a VLAN in the
database of a VLAN Membership Policy Server (VMPS).
- When a device is connected to a switch port, the switch must query a database to
establish VLAN membership.
- With Cisco switches, dynamic VLANs are created and managed using network-
management tools such as Cisco Works.
- Dynamic VLANS allows a great deal of flexibility and mobility for end-user hosts, but
requires more administrative overhead.
Note: - Configuring Dynamic VLANs are not covered in this book.
Deploying VLANs:
- To implement VLANs, you must consider the number of VLANs you need and how
best to place them.
- The number of VLANs depends on traffic patterns, application types, segmentation of
the network, and network-management requirements.
Note: - An important factor to consider is the relationship between VLANs and the
IP addressing schemes used.
- It is recommended to use a one-to-one correspondence between VLANs and
IP subnets.
- This means that if a subnet with 24-bit mask (255.255.255.0) is used for a
VLAN, no more than 254 hosts should be members in this VLAN.
- Note that, a single switch port can support more than one IP subnet for the devices
attached to it.
- For example, consider the following figure where a shared Ethernet hub is connected
to a single switch port.
P a g e | 52
- One host connected to the hub might be configured for 192.168.1.1/24, whereas
another host is assigned to 192.168.5.1/24.
- Although, these subnets (192.168.1.0/24 and 192.168.5.0/24) are discontiguous and
unique, both are communicating on one switch port, they can’t be considered separate
VLANs.
- In this case, the switch port supports one VLAN (VLAN 2), but multiple subnets can
exist on that single VLAN.
VLAN Trunks:
- End-user hosts connect to access switch ports that provide simple connectivity to a
single VLAN each.
- The attached hosts are unaware of any VLAN structure and simply attach to what
appears to be a normal physical network segment.
- Remember, sending information from one VLAN to another is not possible without
the intervention of a Layer 3 router or multilayer switch.
- A “trunk link” can support more than one VLAN traffic to pass through it through a
single switch port (called trunk port).
- Trunk Switch Ports Are switch ports that can be connected to another switch or
router.
P a g e | 53
- Trunk links are most beneficial when switches are connected to other switches, or
switches are connected to routers.
- A trunk switch port is not assigned to a specific VLAN.
- Instead, one, many, or all active VLANs can be transported between switches using a
single physical trunk link.
- Connecting two switches with separate links for each VLAN is possible, as shown in
the following figure.
- The following figure shows one trunk link replacing many individual VLAN links.
P a g e | 54
- Cisco switches supports trunking on both Fast Ethernet and Gigabit Ethernet ports.
- To distinguish between traffic belonging to different VLANs on a trunk link, the
switch must have a method to tag or identify each frame with the appropriate VLAN.
- The switches on each end of a trunk link, both must have the same method for
correlating frames with VLAN IDs.
VLAN Frame Tagging:
- Because a trunk link can carry and transport many VLANs, a switch must tag or
identify frames with their respective VLANs as they are sent and received over a trunk
link.
- Frame tagging assigns a VLAN ID to each frame transported on a trunk link.
- As each switch along the way receives these tagged frames, it is examined to which
VLAN the frames belong then is removed.
- If frames will be transported out another trunk link, the VLAN ID is added back into
the frame header.
- Otherwise, if frames are destined out an access port, the switch removes the VLAN ID
before transmitting frames to the host.
- Therefore, all traces of VLAN association are hidden from the connected hosts.
- VLAN frame tagging can be performed using two methods, each uses a different
frame tagging mechanisms:
IEEE 802.1Q Protocol.
Inter-Switch Link (ISL) Protocol.
1) IEEE 802.1Q Protocol:
- IEEE 802.1Q Protocol Is a standard method for preserving the VLAN tagging of
frames passing over a trunk link.
- This frame tagging method is standardized, allowing VLAN trunks to exist and
operate between equipment from multiple vendors.
- IEEE 802.1Q embeds its VLAN tagging information within each Layer 2 frame.
- This method is referred to a “single tagging” or “internal tagging”.
P a g e | 55
- 802.1Q introduces the concept of “native” VLAN on a trunk link.
- Frames belonging to this VLAN aren’t encapsulated with any VLAN tagging
information.
- If an end host is connected to an 802.1Q trunk port, the host can understand only the
native VLAN frames.
- 802.1Q adds a 4-bytes tag just after the source address field as shown in the following
figure:
IEEE 802.1Q Frame-Tagging Standard
- The first 2-bytes are used as a Tag Protocol Identifier (TPID) and always have a value
of 0x8100 to signify an 802.1Q tag.
- The remaining 2-bytes are used as a Tag Control Information (TCI) field.
- The TCI information contains a 3-bit Priority field, which is used to implement Class-
of-Service (CoS) functions in the accompanying 802.1Q/802.1P prioritization
standard.
- One bit of the TCI is a Canonical Format Indicator (CFI), flagging whether the MAC
addresses are in Ethernet or Token Ring format (this is also known as “canonical
format” or “little-endian” or “big-endian” format).
- The last 12-bits are used as the VLAN ID to indicate the source VLAN for the frame.
- The VLAN ID can have values from 0 to 4095, but VLANs 0, 1, and 4095 are
reserved.
P a g e | 56
2) Inter-Switch Link (ISL) Protocol:
- Inter-Switch Link (ISL) Protocol Is a Cisco proprietary method for preserving the
source VLAN tagging of frames passing over a
trunk link.
- ISL performs frame tagging in Layer 2 by encapsulating each frame with the VLAN
ID.
- Any Cisco switch or router configured with ISL, can process and understand the ISL
VLAN ID.
- ISL primarily is used for Ethernet media, although Cisco has included provisions to
carry FDDI, Token Ring, and ATM frames over Ethernet ISL (a Frame-Type field is
the ISL header indicates the source frame type).
- When a frame is destined out a trunk link to another switch or router, ISL adds a 26-
bytes header and a 4-bytes trailer to the frame.
- The source VLAN is identified with a 15-bit VLAN ID field in the header.
- The trailer contains a Cyclic Redundancy Check (CRC) value to ensure the data
integrity of the new encapsulated frame.
- The following figure shows how Ethernet frames are encapsulated and forwarded out a
trunk link.
ISL Frame Tagging
- Because tagging information is added at the beginning and end of each frame, ISL
sometimes is referred to as “double tagging”.
- If the frame is destined for an access link, the ISL encapsulation ISL header and trailer
are removed.
P a g e | 57
Note: - The ISL method of VLAN tagging is no longer supported across all Cisco
Catalyst switch platforms.
- Even so, you should still be familiar with it and know how it compares to the
standard-based IEEE 802.1Q method.
Note: - Both 802.1Q and ISL frame tagging methods have one implication that they
add to the length of the Ethernet frame.
- 802.1Q adds 4-bytes to each frame.
- ISL adds 30-bytes to each frame.
- Because Ethernet frames can’t exceed 1518 bytes, the additional VLAN
tagging information can cause the frame to become too large.
- Frames that barely exceed the MTU size are called “baby giant” frames.
- Switches usually report these frames as Ethernet errors or oversize frames.
Note: - Baby giant or oversize frames can exceed the frame size set in various
standards.
- To properly handle and forward them anyway, Catalyst switches use
proprietary hardware with the ISL encapsulation method.
- In case of 802.1Q encapsulation, switches can comply with the IEEE
802.1ac standard, which extends the maximum frame length to 1522 bytes.
Dynamic Trunking Protocol (DTP):
- You can manually configure trunk links on Catalyst switches for either 802.1Q or ISL.
- In addition, Cisco has implemented a proprietary, point-to-point protocol called
Dynamic Trunking Protocol (DTP) that negotiates a common trunking mode between
two switches.
- The negotiation covers the encapsulation (802.1Q and ISL) and whether the link
becomes a trunk at all.
- This allows trunk links to be used without a great deal of manual configuration or
administration.
Note: - You should disable DTP negotiation if a switch has a trunk link connected to
a non-trunking router or firewall interface because these devices can’t
participate in DTP negotiation.
P a g e | 58
VLAN Trunking Configuration:
- By default, all switch ports operate as access ports.
- Specifically, ports actively try to become trunk ports as long as the far end agrees.
- In that case, a common encapsulation is chosen, favoring ISL if both support it.
- To configure a specific switch port to be a trunk port, use the following commands:
Switch(config)# interface “type mod/num.” Switch(config-if)# switchport mode {trunk | dynamic {desirable | auto}} Switch(config-if)# switchport trunk encapsulation {dot1q | isl | negotiate} Switch(config-if)# switchport trunk native vlan “vlan-id” Switch(config-if)# switchport trunk allowed vlan {vlan-list | all | {add | except | remove}
vlan-list}
- A switch port must be in Layer 2 mode before it can support a trunk if the switch used
is a multilayer switch.
- To accomplish this, you should use the “switchport” command with no other keywords
in the beginning of the interface configuration.
- In the “switchport mode” command, you can set the trunking mode to any of the
following:
dynamic auto (The default) - The port can be converted into a trunk port, but
only if the far-end switch actively requests it.
- Therefore, if the far-end switch port is
configured to trunk or dynamic desirable
modes, trunking is negotiated.
- Because of the passive negotiation behavior, the
link never becomes a trunk if both ends of the
link are left to the default dynamic auto mode.
dynamic desirable - The port actively attempts to convert the link into
trunking mode.
- In other words, it “asks” the far-end switch to bring up a
trunk.
P a g e | 59
- If the far-end switch port is configured to trunk, dynamic
desirable, or dynamic auto modes, trunking is negotiated
successfully.
trunk - This setting places the port in permanent trunking mode.
- DTP is still operational, so if the far-end switch port is configured to
trunk, dynamic desirable, or dynamic auto modes, trunking will be
negotiated successfully.
- The trunk mode is usually used to establish an unconditional trunk.
Therefore, the corresponding switch port at the other end of the link
should be configured similarly.
- In this way, both switches always expect the trunk link to be
operational without negotiation.
- You also should manually configure the encapsulation mode to
eliminate its negotiation.
- Used directly when connecting a switch to a router.
- The following table summarizes the cases of configuring a trunk link:
Near-End Far-End Link Mode
dynamic auto dynamic auto Not-trunking
dynamic auto dynamic desirable or trunk Trunking
dynamic desirable Dynamic auto, dynamic desirable, or trunk Trunking
trunk Dynamic auto, dynamic desirable, or trunk Trunking
Note: - You cannot move from the default “dynamic auto” directly to “trunk” mode,
if connecting two switches. First, you have to move to “dynamic desirable”
mode then to “trunk” mode.
- You can use “trunk” mode directly if connecting a switch to a router.
P a g e | 60
- In all these modes, DTP frames are sent out every 30 seconds to keep neighboring
switch ports informed of the link’s mode.
- On critical trunk links in a network, manually configuring the trunking mode on both
ends is best so that the link can never be negotiated to any other state.
- If you decided to configure both ends of a trunk link as a fixed trunk using the
“switchport mode trunk” command, you can disable DTP completely so that these
frames are not exchanged.
- To disable DTP, add the following command to the interface configuration:
Switch(config-if)# switchport nonnegotiate
- Be aware that after DTP frames are disabled, no future negotiation is possible until this
configuration is reversed by adding the “no” keyword.
- To show the trunking status on a switch port, use the following show command:
Switch# show interface “type mod/num.” trunk
Note: - The “interface(s)” keyword can be with or without the “s” letter.
- dot1q Frame tagging method will be done by using the IEEE 802.1Q standard.
- isl Frame tagging method will be done by using the Cisco ISL protocol.
Note: - In case of an IEEE 802.1Q trunk, you should configure the native VLAN
using the “switchport trunk native vlan” command, identifying the untagged
or native VLAN ID (1 to 4094).
- By default, an 802.1Q trunk uses VLAN 1 as the native VLAN.
- In the case of an ISL trunk, using this command has no effect because ISL
doesn’t support an untagged VLAN.
- negotiate (The default) The encapsulation is negotiated to select either IEEE
802.1Q or ISL.
- The following command “switchport trunk allowed vlan”, defines which VLANs are
allowed to be transported over the trunk link.
- By default, a switch allows transporting all active VLANs (1 to 4094) over the trunk.
P a g e | 61
- Active VLAN Is the VLAN that has been defined on the switch and has ports
assigned to that VLAN.
- There might be time when the trunk link shouldn’t carry all VLANs.
- For example, broadcasts are forwarded to every switch port on a VLAN, including the
trunk link because it is too a member of the VLAN.
- If the VLAN doesn’t extend past the far-end of a trunk link, propagating broadcasts
across the trunk makes no sense.
- You can tailor the list of allowed VLANs on the trunk port by using the “switchport
trunk allowed vlan” command with one of the following:
vlan-list An explicit list of VLAN IDs separated by commas or dashes.
add vlan-list A list of VLAN IDs will be added to the already configured list;
this is a shortcut to keep from typing a long list of IDs.
except vlan-list All VLANs (1 to 4094) will be allowed except for the VLAN
IDs listed, this is a shortcut to keep typing a long list of IDs.
remove vlan-list A list of VLAN IDs will be removed from the already
configured list, this is a shortcut to keep from typing a long list
of IDs
Example: - Consider the following small network:
P a g e | 62
Requirements:
Configure Switch-A to actively negotiate a trunk with the far-end Switch-B.
The trunk link should use 802.1Q encapsulation, with VLAN 100 as the native
VLAN.
The trunk link should carry only VLAN IDs from 100 to 102.
- First, to configure Switch-A, use the following commands:
Switch-A(config)# interface gig 1/1 Switch-A(config-if)# switchport mode dynamic desirable Switch-A(config-if)# switchport trunk encapsulation dot1q Switch-A(config-if)# switchport trunk native vlan 100 Switch-A(config-if)# switchport allowed vlan 100-102
- At this point, the trunk link between the two switches is configured correctly, because
Switch-A is configured to use “dynamic desirable” trunking mode, and Switch-B is at
the default trunking “dynamic auto” mode, resulting in a trunking link.
Note: - At this point, there is a native VLAN mismatch because Switch-B still not
yet configured to use VLAN 100 as its 802.1Q native VLAN.
- To show the trunk status, use the following command:
Switch-A# show interface gigabitethernet 1/1 trunk Port Mode Encapsulation Status Native vlan Gig1/1 desirable 802.1q trunking 100 Port Vlans allowed on trunk Gig1/1 100-102 Port Vlans allowed and active in management domain Gig1/1 100,101,102 Port Vlans in spanning tree forwarding state and not pruned Gig1/1 100,101,102
P a g e | 63
- To show the trunk status using another command:
Switch-A# show interface gigabitethernet 1/1 switchport
Name: Gig1/1
Switchport: Enabled
Administrative Mode: dynamic desirable
Operational Mode: trunk
Administrative Trunking Encapsulation: dot1q
Operational Trunking Encapsulation: dot1q
Negotiation of Trunking: On
Access Mode VLAN: 1 (default)
Trunking Native Mode VLAN: 100 (Vlan-100)
!Lines are omitted for brevity
Note: - If Switch-B Gigabit Ethernet Interface 1/1 was configured manually to be an
access port using the “switchport mode access” command, and Switch-A
Gigabit Ethernet Interface 1/1 still configured with “switchport mode
dynamic desirable” command, the link will not work in the trunking mode
(not-trunking), because “dynamic desirable” mode negotiate a trunk only
with all other trunking modes.
- To configure Switch-B, use the following commands:
Switch-B(config)# interface gigabitethernet 1/1 Switch-B(config-if)# switchport trunk encapsulation dot1q Switch-B(config-if)# switchport trunk native vlan 100 Switch-B(config-if)# switchport trunk allowed vlan 100-102
- To verify the physical link is up, use the following command:
Switch-A# show interface status Port Name Status Vlan Duplex Speed Type Gig1/1 connected 100 full 1000 1000BaseT
- Now, consider that you realize that VLAN 101 shouldn’t be passed over the trunk link
between the two switches.
P a g e | 64
- You can use the following command on both switches to remove VLAN 101:
Switch-A(config-if)# switchport trunk allowed vlan remove 101
Switch-B(config-if)# switchport trunk allowed vlan remove 101
- In this case, the range of VLANs 100-102 is kept in the configuration, and only VLAN
101 is removed from the list.
Note: - When you manually remove VLANs from being allowed on a trunk link, the
same configuration should be performed at both ends of the trunk.
- Otherwise, one of the two switches still could flood broadcasts from that
VLAN over the trunk, making unnecessary bandwidth in only one direction.
Troubleshooting VLANs and Trunks:
- If a host (for example, PC-3) on one location cannot communicate with another host
(for example, PC-6) in another location, where both are assigned to the same IP
subnet, make sure that both of their switch ports are configured for the same access
VLAN ID.
- If they are, examine the trunk between the two switches and check if that VLAN is
carried over the trunk using the following command:
Switch-A# show interface gigabitethernet 1/1 trunk Port Mode Encapsulation Status Native vlan Gig1/1 auto 802.1q not-trunking 100 Port Vlans allowed on trunk Gig1/1 100-102 Port Vlans allowed and active in management domain Gig1/1 100,101,102 Port Vlans in spanning tree forwarding state and not pruned Gig1/1 100,101,102
- Because the mode is back to default on both switches, the link status is “not-trunking”.
P a g e | 65
- Use also the following command to show information of how a switch port is
configured for trunking:
Switch-A# show interface gigabitethernet 1/1 switchport
Name: Gig1/1
Switchport: Enabled
Administrative Mode: dynamic auto
Operational Mode: static access
Administrative Trunking Encapsulation: dot1q
Operational Trunking Encapsulation: dot1q
Negotiation of Trunking: On
Access Mode VLAN: 1 (default)
Trunking Native Mode VLAN: 100 (Vlan-100)
!Lines are omitted for brevity
- Look for the “Administrative Mode” versus the “Operational Mode”, to see whether
the trunk is working the way you configured it.
Note: - You can bring up a trunk with different native VLANs on each end.
- However, both switches will log error messages about the mismatch, and the
potential exists that traffic will not pass correctly between the two native
VLANs.
- The native VLAN is configured independently on both trunk links, so it is
possible to have a native VLAN mismatch between the trunk ends.
- To show whether and how DTP is being used on a switch, use the following
command:
Switch-A# show dtp Global DTP information Sending DTP Hello packets every 30 seconds Dynamic Trunk timeout is 300 seconds 1 interfaces using DTP
- The following command shows the DTP activity in greater details:
Switch-A# show dtp [interface “type mod/num.”]
P a g e | 66
Chapter 4 VLAN Trunking Protocol
VLAN Trunking Protocol (VTP):
- Campus network environments usually consists of many interconnected switches.
- Configuring and managing a large number of VLANs, and VLAN trunks quickly can
get out of control.
- Cisco has developed a method to manage VLANs across the campus network.
- The VLAN Trunking Protocol (VTP) uses Layer 2 trunk frames to communicate
VLAN information among a group of switches.
- VTP manages the addition, renaming, deletion of VLANs across the network from a
central point of control (VTP Server).
- Any switch participating in a VTP domain is aware of and can use any VLAN that
VTP manages.
VTP Domains:
- VTP is organized into “VTP management domains”, or areas with common VLAN
requirements.
- A switch can belong to only one VTP domain, in addition to sharing VLAN
information with other switches in the domain.
- Switches in different VTP domains do not share VTP information.
- Switches in a VTP domain advertise several attributes to their domain neighbors.
- Each VTP advertisement contains information about:
VLANs.
VTP domain name.
VTP revision number.
Specific VLAN parameters.
P a g e | 67
- When a VLAN is added to a switch in a VTP domain, other switches in the same VTP
domain are notified of the new added VLAN through VTP advertisements.
- In this case, all switches in a VTP domain can prepare to receive traffic on their trunk
ports using the new VLAN.
VTP Modes:
- To participate in a VTP domain, each switch must operate in one of several modes.
- The VTP mode determines how a switch processes and advertises VTP information.
- VTP modes are:
Server mode (The default) - VTP server switches have full control over VLAN
creation, modification, and deletion for their VTP
domain.
- All VTP information is advertised to other switches
in the VTP domain and all received VTP
information is synchronized with other switches.
Note: - Each VTP domain must have at least one VTP server switch.
Client mode - VTP client switches do not allow the administrator to create,
rename, or delete any VLANs.
- Instead, they listen to VTP advertisements from other switches
and modify their VLAN database accordingly.
- Received VTP information is forwarded out trunk links to
neighboring switches in the VTP domain, so the switch also acts
as a VTP relay.
Transparent mode - VTP transparent switches acts as a VTP relay only and
doesn’t participate in VTP.
- VTP transparent switches doesn’t advertise its own VLAN
configuration, and doesn’t synchronize its VLAN database
with the received advertisements, these advertisements are
relayed only to other switches in the VTP domain.
P a g e | 68
Note: - A VTP transparent mode switch doesn’t relay VTP advertisements it
receives out of its trunk links to other switches unless its VTP domain name
and VTP version numbers match those of the other switches.
- While a switch is in VTP transparent mode, it can create and delete VLANs
that are local only to itself.
- These VLAN changes are not propagated to any other switches.
VTP Advertisements:
- Each Cisco switch participating in VTP advertises VLANs (only 1 to 1005), VTP
domain name, VTP revision number, and VLAN parameters on its trunk ports to
notify other switches in the VTP domain.
- VTP advertisements are sent as multicast frames.
- The switch intercepts frames sent to the VTP multicast address and processes them
with its supervisory processor.
- VTP frames are forwarded out trunk links as a special case.
- Because all switches in a VTP domain learn of new VLAN configuration changes, a
VLAN must be created only on VTP server switches in the VTP domain.
- By default, VTP domains are set to use non-secure VTP advertisements without a
password.
- You can add a VTP password to set the VTP domain to secure mode.
Note: - The same VTP password must be configured on every switch in the domain
so that all switches exchanging VTP information use identical encryption
methods.
- VTP switches uses an index called the “VTP configuration revision number” to keep
track of the most recent information.
- Every switch in a VTP domain stores the configuration revision number that it last
heard from a VTP advertisement.
- The VTP advertisement process always starts with configuration revision number 0
(zero) stored in NVRAM and is not altered by a power cycle of the switch.
- When subsequent changes are made on a VTP server switch, the revision number is
incremented before advertisements are sent.
P a g e | 69
- When listening switches receives an advertisement with a greater revision number than
its locally stored one, the advertisement overwrites any stored VLAN information.
- Because of this, it is important to always force any newly added network switches to
the VTP domain to have revision number (0) before being attached to the network.
- Otherwise, a switch might have stored a revision number that is greater than the value
currently in use in the VTP domain.
- Therefore, the revision number can be initiated to (0) only by using one of the
following methods:
Change the switch’s VTP mode to transparent and then change the mode back to
server.
Change the switch’s VTP domain name to a bogus name (a non-existing VTP
domain name), and then change the VTP domain name back to the original name.
- If the VTP revision number of a switch is not reset to (0) before joining a VTP
domain, the switch might enter the network as a VTP server and have a pre-existing
revision number (from previous configuration) that is higher than in previous
legitimate advertisements.
- The new switch’s VTP information would be seen as a more recent, so all other
switches in the VTP domain would accept its VLAN database and overwrite their
good VLAN database.
- In other words, a new VTP server switch might inadvertently cause every other
working switch to flush all records of every VLAN in production.
- The VLANs would be deleted from the switches, causing any switch port assigned to
them to become inactive.
- This is referred to as a VTP “synchronization problem”.
- VTP advertisements can originate as requests from VTP client switches that want to
learn about the VTP database at boot.
- Advertisements also can originate from VTP server switches as VLAN configuration
changes occur.
P a g e | 70
- VTP advertisements can occur in three forms:
Summary advertisements - VTP server switches send summary advertisements
every 300 seconds and every time a VLAN
database change occurs.
- The summary advertisement lists information about
the VTP domain, including VTP version number,
domain name, configuration revision number, time
stamp, MD5 encryption hash code, and the number
of subset advertisements to follow.
- For VLAN configuration changes, summary
advertisements are followed by one or more subset
advertisements with more specific VLAN
configuration data.
Subset advertisements - VTP server switches send subset advertisements after a
VLAN database change occurs.
- These advertisements list the specific changes that have
been performed, such as creating, renaming, or
deleting a VLAN and changing a VLAN’s Maximum
Transmission Unit (MTU).
- Subset advertisements can list the following VLAN
parameters:
Status of the VLAN.
VLAN type (such as Ethernet or Token Ring).
MTU.
VLAN name.
VLAN number.
Security Association Identifier (SAID) value.
Length of VLAN name.
P a g e | 71
Advertisement request - A VTP client switch can request any VLAN
from clients information it lacks.
- For example, a client switch might be reset and have
its VLAN database cleared, and its VTP domain
membership might be changed, or it might hear a VTP
summary advertisement with a higher revision number
than it currently has.
- After a client switch’s advertisement request, the VTP
server switches respond with summary and subset
advertisements to bring it up to date.
- VTP switches store VTP information separately from
the switch configuration in NVRAM.
- VLAN and VTP data are saved in the vlan.dat file on
the switch’s flash memory file system.
- All VTP information, including the VTP configuration
revision number, is retained even when the switch port
is off.
- In this manner, a switch can recover the last known
VLAN configuration from its VTP database after it
reboots.
Note: - Do not assume that a VTP client switch will start with a clean state when it
powers up.
VTP Configuration:
- By default, every switch operates in the VTP version 1, VTP server mode, VTP
domain NULL (a blank string), with no password or secure mode.
- If the switch hears a VTP summary advertisement on a trunk port from any other
switch in the same VTP domain (other than NULL), it automatically learns the
VLANs and the configuration revision number it hears.
- This makes it easy to bring up a new switch in an existing VTP domain.
P a g e | 72
- However, be aware that a new switch starts in the default VTP server mode, something
that might not be desirable.
Note: - You should get into the habit of double-checking the VTP configuration of
any switch before you add it into your network.
- Make sure that the VTP configuration revision number is set to (0).
- To show the default VTP information, use the following command:
Switch# show vtp status
VTP Version : 2
Configuration Revision : 0
Maximum VLANs supported locally : 255
Number of existing VLANs : 5
VTP Operating Mode : Server
VTP Domain Name :
VTP Pruning Mode : Disabled
VTP V2 Mode : Disabled
VTP Traps Generation : Disabled
MD5 digest : 0x7D 0x5A 0xA6 0x0E 0x9A 0x72 0xA0 0x3A
Configuration last modified by 0.0.0.0 at 0-0-00 00:00:00
Local updater ID is 0.0.0.0 (no valid interface found)
Note: - The VTP version is determined by enabling or disabling the VTP V2 mode
on the switch, so if the VTP V2 mode is “Disabled”, means that the switch is
operating in VTP version 1 mode, if “Enabled”, means that the switch is
operating in VTP version 2 mode.
Configuring the VTP Domain:
- Before a switch is added into a network, the VTP domain should be identified.
- If this switch is the first one on the network, a new VTP domain name must be created.
- To configure a switch to a VTP domain, use the following command:
Switch(config)# vtp domain “domain-name”
- “domain-name” Is a text string up to 32 characters long with a default value NULL.
P a g e | 73
Configuring the VTP Mode:
- To configure the VTP mode on a switch, use the following command:
Switch(config)# vtp mode {server | client | transparent}
- Each VTP domain should have at least one VTP server switch.
- Multiple VTP server switches can coexist in a VTP domain, this is recommended for
redundancy.
- If one VTP server switch is configured with a new VLAN or VTP parameter, it
advertises the changes to the rest of the VTP domain.
- All other VTP server switches synchronize their VTP databases to this advertisement,
just as any VTP client would.
- If other switches are in the VTP domain, you should configure a new switch for VTP
client mode.
- In this way, the switch is forced to learn any existing VTP information from a reliable
existing VTP server switch.
- After the switch has learned the current VTP information, you can reconfigure it for
VTP server mode if it will be used as a redundant VTP server switch.
- The VTP transparent mode switch is used if a switch will not share the VLAN
information with any other switch in the network.
- VLANs still can be created, modified, and deleted locally on the VTP transparent
switch.
- However, they are not advertised to other neighboring switches.
- VTP advertisements received by a VTP transparent switch are relayed to other
switches on trunk links.
Securing the VTP Domain:
- If the VTP domain requires security, a password can be defined:
- To configure a VTP password, use the following command:
Switch(config)# vtp password “password”
P a g e | 74
Note: - The password can be configured only on VTP server and client switches.
- The password itself is not sent; instead, an MD5 hash code is computed and sent in
VTP advertisements (by VTP server switches) and is used to validate received
advertisements (by VTP client switches).
- The password is a string of 1 to 32 characters (case sensitive).
Note: - If secure VTP is implemented using a password, begin configuring a
password on the VTP server switches.
- The client switches retain the last-known VTP information but cannot
process received advertisements until the same password is configured on
them too.
Configuring the VTP Version:
- To configure the VTP version, use the following command:
Switch(config)# vtp version {1 | 2}
- By default, the switch uses VTP version 1 (VTP V2 Mode is Disabled).
- Two version of VTP are available for use in a VTP domain.
- Catalyst switches are capable of running either VTP version 1 or VTP version 2.
- Within a VTP domain, the two versions are not interoperable.
- Therefore, the same VTP version must be configured on every switch in a VTP
domain.
- If a switch is capable of running VTP version 2, this switch can coexist with other
version 1 switches, as long as its VTP version 2 is not enabled.
- This situation becomes important if you want to use VTP version 2 in a VTP domain.
- Then only one VTP server mode switch needs to have a VTP version 2 enabled.
- The new VTP version number is propagated to all other version-2 capable switches in
the VTP domain, causing them all to automatically enable VTP version 2 for use.
P a g e | 75
Note: - A third version of VTP addresses some of the traditional shortcomings.
- For example, VTP version 3 supports extended VLAN numbers (1 to 4095)
that are compatible with the IEEE 802.1Q trunking standard.
- VTP version 3 is available only on Cisco Catalyst platforms running the
CatOS (non-IOS) operating system.
- Therefore, only VTP version 1 and 2 are covered in this book.
- The two versions of VTP differ in the features they support.
- VTP version 2 offers the following additional features over version 1:
Version-dependent transparent mode - In transparent mode, VTP version 2
forwards the VTP messages without
checking the version number.
Consistency checks - VTP version 2 performs consistency checks on the VTP
and VLAN parameters entered from the CLI or by SNMP.
- This checking helps prevent errors in such things as
VLAN names and numbers from being propagated to
other switches in the VTP domain.
- However, no consistency checks are performed on VTP
messages that are received on trunk links or on
configuration and database that is read from NVRAM.
Token Ring support - VTP version 2 supports the use of Token Ring switching
and Token Ring VLANs (If Token Ring switching is
used, VTP version 2 must be enabled).
Unrecognized Type-Length-Value - VTP version 2 switches propagates received
(TLV) support configuration change messages out other
trunk links, even if the switch supervisor
cannot parse or understand the message.
- For example, a VTP advertisement contains a Type field to denote what type of VTP
messages is being sent.
- VTP messages type 1 is a summary advertisement, and VTP message type 2 is a subset
advertisement.
P a g e | 76
- An extension to VTP that utilizes other message types and other message length values
could be in use.
- Instead of dropping the unrecognized VTP message, version 2 still propagates the
information and keeps a copy in NVRAM.
Example: - Consider the following connected switches:
- Switch-A has 4 VLANs configured in its VLAN database (VLANs 2, 3, 4, and 5).
- Trunk links are configured between all switches using IEEE 802.1Q trunking links.
Requirements:
Configure all switches to use the VTP domain “The-Road”.
Configure all switches to use the VTP version 2.
Configure Switch-A to be a VTP sever mode switch.
Configure Switch-B to be a VTP transparent mode switch.
Configure Switch-C to be a VTP client mode switch.
Configure a secure VTP domain using the password “Secret”.
- First, to configure all switches, use the following commands:
Switch-A(config)# vtp domain The-Road Switch-A(config)# vtp version 2 Switch-A(config)# vtp password Secret
Switch-B(config)# vtp domain The-Road Switch-B(config)# vtp mode transparent
Switch-C(config)# vtp domain The-Road Switch-C(config)# vtp mode client Switch-C(config)# vtp password Secret
P a g e | 77
- To check the VTP information on Switch-C, use the following command:
Switch-C# show vtp status
VTP Version : 2
Configuration Revision : 11
Maximum VLANs supported locally : 255
Number of existing VLANs : 9
VTP Operating Mode : Client
VTP Domain Name : The-Road
VTP Pruning Mode : Disabled
VTP V2 Mode : Enabled
VTP Traps Generation : Disabled
MD5 digest : 0x00 0x6F 0x6E 0x71 0x55 0xB3 0xCB 0x85
Configuration last modified by 0.0.0.0 at 3-1-93 02:01:12
Local updater ID is 0.0.0.0 (no valid interface found)
- To show the learned VLANs, use the following command:
Switch-C# show vlan brief
VLAN Name Status Ports
-------- -------------------------------- --------- -------------------------------
1 default active Fa0/1, Fa0/2, Fa0/3, Fa0/4
Fa0/5, Fa0/6, Fa0/7, Fa0/8
Fa0/9, Fa0/10, Fa0/11, Fa0/12
Fa0/13, Fa0/14, Fa0/15, Fa0/16
Fa0/17, Fa0/18, Fa0/19, Fa0/20
Fa0/21, Fa0/22, Fa0/23, Fa0/24
Gig0/1, Gig0/2
2 VLAN-2 active
3 VLAN-3 active
4 VLAN-4 active
5 VLAN-5 active
1002 fddi-default active
1003 token-ring-default active
1004 fddinet-default active
1005 trnet-default active
P a g e | 78
- VTP messages and error counters can also be displayed using the following command:
Switch-C# show vtp counters
VTP statistics:
Summary advertisements received : 52
Subset advertisements received : 19
Request advertisements received : 4
Summary advertisements transmitted : 45
Subset advertisements transmitted : 11
Request advertisements transmitted : 4
Number of config revision errors : 0
Number of config digest errors : 0
Number of V1 summary errors : 0
VTP pruning statistics:
Trunk Join Transmitted Join Received Summary advts received from
non-pruning-capable device
-------------- ----------------------- -------------------- -------------------------------------------
- You can use this command for basic VTP troubleshooting to see whether the switch is
interacting with other VTP switches in the VTP domain.
VTP Pruning:
- Recall that, by definition, a switch must forward broadcast frames out all available
ports in the broadcast domain.
- Unless forwarded by more intelligent means, multicast frames follow the same pattern.
- In addition, frames destined for an address that the switch has not yet learned or has
forgotten (the MAC address has aged out of the address table) must be forwarded out
all ports in an attempt to find the destination.
- These frames are referred to as “unknown unicast”.
- When forwarding frames out all ports in a broadcast domain or VLAN, trunk ports are
included if they transport that VLAN.
P a g e | 79
- By default, a trunk link transports traffic from all VLANs, unless specific VLANs are
removed from the trunk.
- Generally, in a network with several switches, trunk links are enabled between
switches, and VTP is used to manage the propagation of VLAN information.
- This scenario causes the trunk links between switches to carry traffic from all VLANs,
not just from the specific VLANs created.
- Consider the network shown in the following figure:
Flooding in a Catalyst Switch Network
- When an end user Host PC in VLAN 3 sends a broadcast, Switch-C forwards the
frame out all VLAN 3 ports, including the trunk link to Switch-A.
- Switch-A, in turn, forwards the broadcast on to Switch-B and Switch-D over those
trunk links.
- Switch-B and Switch-D forward the broadcast out only their access links that have
been configured for VLAN 3.
- If Switch-B and Switch-D don’t have any active users in VLAN 3, forwarding that
broadcast frame to them would consume bandwidth on the trunk links and processor
resources in both switches, only to have Switch-B and Switch-D discard the frames.
P a g e | 80
- VTP pruning makes more efficient use of trunk bandwidth by reducing unnecessary
flooded traffic.
- Broadcast and unknown unicast frames on a VLAN are forwarded over a trunk link
only if the switch on the receiving end of the trunk has ports in that VLAN.
- VTP pruning occurs as an extension to VTP version 1, using an additional VTP
message type.
- When a switch has a port associated with a VLAN, the switch sends an advertisement
to its neighbor switches that it has active ports on that VLAN.
- The neighbors keep this information, enabling them to decide whether flooded traffic
from a VLAN should use a trunk port.
- The following figure shows the previous figure with VTP pruning enabled:
Flooding in a Switched Network Using VTP Pruning
- Because Switch-B has not advertised its use of VLAN 3, Switch-A will prune VLAN
3 from the trunk to Switch-B and will choose not to flood VLAN 3 traffic to Switch-B
over the trunk link.
- Switch-D has advertised the need for VLAN 3, so traffic will be flooded to it.
P a g e | 81
Enabling VTP Pruning:
- By default, VTP pruning is disabled on IOS-based switches.
- To enable VTP pruning, use the following command:
Switch(config)# vtp pruning
Note: - If you configured this command on a VTP server switch, it also advertises
that pruning needs to be enabled for the entire VTP domain.
- All other switches listening to that advertisement will also enable pruning.
- When pruning is enabled, all general-purpose VLANs become eligible for pruning on
all trunk links, if needed.
- However, you can modify the default list of pruning eligibility using the following
interface-configuration command on every trunk port:
Switch(config-if)# switchport trunk pruning vlan {{{add | except | remove} “vlan-list”} | none}
- By default, VLANs 2 through 1001 are eligible or “enabled” for potential pruning on
every trunk.
- Use one of the following keywords with the command to tailor the list:
vlan-list An explicit list of eligible VLAN numbers (anything from 2 to 1001),
separated by commas or dashes.
add “vlan-list” A list of VLAN numbers (anything from 2 to 1001) is added to
the already configured list.
except “vlan-list” All VLANs are eligible except for the VLAN numbers listed
(anything from 2 to 1001).
remove “vlan-list” A list of VLAN numbers (anything from 2 to 1001) is
removed from the already configured list.
none No VLAN will be eligible for pruning.
P a g e | 82
Note: - VTP pruning has no effect on switches in the VTP transparent mode.
Instead, those switches must be configured manually to “prune” VLANs
from trunk links.
- In this case, pruning is always configured on the upstream side of a trunk (the
downstream side switch doesn’t have any ports that belong to the pruned VLAN, so
there is no need to prune from that end).
- By default, VLANs 2 to 1001 are eligible for pruning.
- VLAN 1 has a special meaning because it sometimes is used for control traffic and is
the default access VLAN on switch ports, because of these reasons, VLAN 1 is never
eligible for pruning.
- In addition, VLANs 1002 through 1005 are reserved for Token Ring and FDDI
VLANs and are never eligible for pruning.
Troubleshooting VTP:
- If a switch does not seem to be receiving updated information from a VTP server,
consider these possible causes:
The link toward the VTP server is not in trunking mode, VTP advertisements are
sent only over trunks.
The switch is configured for VTP transparent mode, so incoming VTP
advertisements are not processed, they are relayed only to other switches in the
VTP domain.
Make sure that the VTP domain name is configured correctly to match that of the
VTP server switch.
Make sure that the VTP version is the same on all switches in the VTP domain.
Make sure that the VTP password matches other switches in the VTP domain.
Make sure that at least there must be one VTP server switch.
P a g e | 83
- The following are the VTP troubleshooting commands:
To show the current VTP parameters, including the last advertising server:
Switch# show vtp status
To show the VTP advertisements and pruning statistics:
Switch# show vtp counters
To show the defined VLANs:
Switch# show vlan brief
To show the trunk port status , including pruning eligibility:
Switch# show interface “type mod/num.” switchport
To show the VTP pruning state:
Switch# show interface “type mod/num.” pruning
P a g e | 84
Chapter 5 Aggregating Switch Links
Switch Port Aggregation with EtherChannel:
- Switch ports can use Ethernet, Fast Ethernet, Gigabit Ethernet, or 10 Gigabit Ethernet
to scale link speeds by a factor of ten.
- EtherChannel Is a technology offered by Cisco for another method of scaling link
bandwidth by aggregating or bundling parallel links.
- (2 to 8) links of either Fast Ethernet (FE), Gigabit Ethernet (GE), or 10 Gigabit
Ethernet (10 GE) are bundled as one logical link of Fast EtherChannel (FEC), Gigabit
EtherChannel (GEC), or 10 Gigabit EtherChannel (10 GBE) respectively.
- This bundle provides a full-duplex bandwidth of up to 1600 Mbps (8-links of Fast
Ethernet), 16 Gbps (8-links of Gigabit Ethernet), or 160 Gbps (8-links of 10 Gigabit
Ethernet).
- EtherChannel provides an easy means to grow or expand a link’s capacity, without
having to continually purchase hardware for the next magnitude of throughput.
- For example, a single Fast Ethernet link (200 Mbps throughput) can be incrementally
expanded up to 8-Fast Ethernet links (1600 Mbps) as a single Fast EtherChannel.
- If the traffic load grows beyond that, the growth process can begin again with a single
Gigabit Ethernet link (2 Gbps throughput), which can be expanded up to 8-Gigabit
Ethernet links as a Gigabit EtherChannel (16 Gbps).
- The process repeats again by moving to a single 10 Gigabit Ethernet link, and so on.
- EtherChannel aggregates parallel links into a single logical link, which can act as
either a trunk link or an access link.
- Switches or devices on each end of the EtherChannel link must understand and use the
EtherChannel technology for proper operation.
P a g e | 85
- Although an EtherChannel link is seen as a single logical link, the link does not
necessarily have an inherent total bandwidth equal to the sum of its component
physical link.
- For example, suppose that a Fast EtherChannel (FEC) link (also called Port Channel)
is made up of 4-100 Mbps full-duplex Fast Ethernet links.
- Although it is possible for the FEC link to carry a total throughput of 800 Mbps (if
each link becomes full loaded), the single resulting FEC bundle does not operate at
this speed.
- Instead, traffic is distributed across the individual links within the EtherChannel.
- Each of these links operates at its inherent speed (200 Mbps full-duplex for FE) but
carries only the frames placed on it by the EtherChannel hardware.
- If one link within the bundle is favored by the load-distribution algorithm, that link
will carry a disproportionate amount of traffic.
- In other words, the load is not distributed equally among the individual links.
- EtherChannel also provides redundancy with several bundled physical links.
- If one of the links within the bundle fails, traffic sent through that link automatically is
moved to an adjacent link.
- Failover occurs in less than a few milliseconds and is transparent to the end user.
- As more links fail, more traffic is moved to further adjacent links.
P a g e | 86
- Likewise, as links are restored, the load automatically is redistributed among the active
links.
Building Ports with EtherChannel:
- EtherChannel bundles can consist of up to 8-physical ports of the same Ethernet media
type and speed.
- Some configuration restrictions exist to ensure that only similarly configured links are
bundled.
- Generally, all bundled ports first must be either in trunking mode if used as a trunk
link with the same native VLAN and pass the same set of VLANs, or in access mode
if used as an access link with the same VLAN assigned.
- Each of the ports should have the same speed and duplex settings before being bundled
(meaning identical ports).
- To configure a range of switch ports simultaneously, use the “interface range”
command.
Distributing Traffic in EtherChannel:
- Traffic in an EtherChannel bundle is distributed across the individual bundled links in
a deterministic fashion.
- However, the load is not necessarily balanced equally across all the links.
- Instead, frames are forwarded on a specific link as a result of a hashing algorithm.
- The algorithm can use source IP address, destination IP address, or a combination of
source and destination IP addresses, source MAC address, destination MAC address,
or a combination of source and destination MAC addresses or TCP/UDP port
numbers.
- The hash algorithm computes a binary pattern “index” that selects a link number in the
bundle to carry each frame.
- For example, suppose that there are two pairs of hosts (PC-1/PC-3 and PC-2/PC-4)
talking across a two-link EtherChannel, and each pair of addresses (if for example, the
source and destination IP addresses “src-dst-ip” are used by the hash algorithm) results
in a unique link index.
P a g e | 87
- This means, frames from one pair of hosts (PC-1/PC-3) always travel over one link in
the channel, whereas frames from the other pair (PC-2/PC-4) always travel over the
other link.
- The links are both used as a result of the hash algorithm, so the load is distributed
across every link in the channel.
- However, if one pair of hosts has a much greater volume of traffic than the other pair,
one link in the EtherChannel will be used much more than the other.
- This still created a load imbalance.
- To remedy this condition, you should consider other methods of hashing algorithms
for the channel.
- For example, a method that combines the source and destination TCP or UDP port
numbers “src-dst-port” can distribute traffic much differently.
- Then frames are placed on links within the bundle based on the application (port
numbers) used within conversations between two hosts.
Configuring EtherChannel Load Distribution:
- To configure load distribution for all EtherChannel switch links, use the following
command:
Switch(config)# port-channel load-balance “method”
Note: - The load distribution method is set with a global configuration command, so
you must set the method globally for the switch not on a per-port basis.
P a g e | 88
- The following table lists the possible values for the load distribution “method” variable
and some supporting switch models:
“method” Value Hash input Switch Model
src-ip Source IP address All models
dst-ip Destination IP address All models
src-dst-ip Source and Destination IP addresses All models
src-mac
(The default) Source MAC address All models
dst-mac Destination MAC address All models
src-dst-mac Source and Destination MAC addresses All models
src-port Source port number 6500, 4500
dst-port Destination port number 6500, 4500
src-dst-port Source and Destination Ports 6500, 4500
- To show the switch configured load distribution method, use the following command:
Switch# show etherchannel load-balance
EtherChannel Load-Balancing Operational State (src-mac): Non-IP: Source MAC address IPv4: Source MAC address IPv6: Source MAC address
- To configure a different switch load distribution method, use the following command:
Switch(config)# port-channel load-balance src-dst-ip
P a g e | 89
- To show the new configured switch load distribution method:
Switch# show etherchannel load-balance
EtherChannel Load-Balancing Operational State (src-dst-ip):
Non-IP: Source XOR Destination MAC address
IPv4: Source XOR Destination IP address
IPv6: Source XOR Destination IP address
- Normally, the default action should result in a statistical distribution of frames;
however, you should determine whether the EtherChannel is imbalanced according to
the traffic patterns present.
- To verify how effectively a configured load distribution method is performing:
Switch# show etherchannel port-channel
- Each link in the EtherChannel bundle is displayed, along with a hex “load” value.
- Although this information is not intuitive, you can use the hex values to get an idea of
each link’s traffic loads relative to the other links.
- You should use the load distribution method that provides the greatest distribution
when the EtherChannel links are indexed.
Note: - A special case results when a router is connected to an EtherChannel.
- Recall that a router always uses its burned-in MAC address in Ethernet
frames, even though it is forwarding packets to and from many different IP
addresses.
- In other words, many end-user hosts send frames to their local router address
with the router’s MAC address as the destination.
- This means that the destination MAC address is the same for all frames
destined through the router.
- Usually, this will not present a problem because the source MAC addresses
are all different.
P a g e | 90
EtherChannel Negotiation Protocols:
- EtherChannels can be negotiated between two switches to provide some dynamic link
configuration.
- Two protocols are available to negotiate bundled links in Catalyst switches:
Port Aggregation Protocol (PAgP) Is a Cisco proprietary solution.
Link Aggregation Control Protocol (LACP) Is a Standard-based protocol.
a) Port Aggregation Protocol (PAgP):
- PAgP is used to provide automatic EtherChannel configuration and negotiation
between switches.
- PAgP packets are exchanged between switches over EtherChannel-capable ports.
- Neighbors are identified and port group capabilities are learned and compared with the
local switch capabilities.
- Ports that have the same neighbor device ID and port group capability are bundled
together as a bidirectional, point-to-point EtherChannel link.
- PAgP forms an EtherChannel only on ports that are configured for either identical
trunking encapsulation or static VLANs.
- PAgP also dynamically modifies parameters of the EtherChannel if one of the bundled
ports is modified.
- For example, if the configured trunk encapsulation, duplex mode, or speed of a port in
an established EtherChannel bundle is changed, PAgP reconfigures that parameter for
all ports in the bundle.
- PAgP can be configured in one of the following modes:
On Is the mode in which a switch does not send or receive PAgP packets.
Auto Is the mode in which a switch negotiates an EtherChannel only if the far
end initiates it.
Desirable Is the mode in which a switch is actively asks a far end switch to
negotiate an EtherChannel.
P a g e | 91
b) Link Aggregation Control Protocol (LACP):
- LACP is a standard-based protocol defined in IEEE 802.3ad (also known as IEEE
802.3 Clause 43, “Link Aggregation”).
- LACP packets are exchanged between switches over EtherChannel-capable ports.
- Neighbors are identified and port group capabilities are learned and compared with the
local switch capabilities.
- However, LACP also assigns roles to the EtherChannel’s end point.
- The switch with the lowest “system priority” is allowed to make decisions about what
ports actively are participating in the EtherChannel at a given time.
- System Priority Is a 2-byte priority followed by a 6-byte switch MAC address.
- Ports are selected and become active according to their “port priority” value, where a
low value indicates a higher priority.
- Port Priority Is a 2-byte priority followed by a 2-byte port number.
- A set of up to 16 potential links can be defined for each EtherChannel.
- Through LACP, a switch selects up to 8 of these ports having the lowest port priorities
as active EtherChannel links at any given time.
- The other links are placed in a standby state and will be enabled in the EtherChannel if
one of the active links goes down.
- LACP can be configured in one of the following modes:
On Is the mode in which a switch does not send or receive LACP packets.
Passive Is the mode in which a switch negotiates an EtherChannel only if the
far end initiates it.
Active Is the mode in which a switch actively asks a far end switch to negotiate
an EtherChannel.
P a g e | 92
- The following tables summarizes the EtherChannel negotiation protocols:
Negotiation Mode Negotiation Packets
sent? Characteristics
PAgP LACP
on on No All ports are channeling.
auto passive Yes Waits until asked to form a channel.
desirable active Yes Actively asks to form a channel.
- If you find that an EtherChannel is having problems, remember that the whole concept
is based on consistent configurations on “both” ends of the Channel.
- Here are some points about EtherChannel operation and interaction:
EtherChannel “on” mode does not send or receive PAgP or LACP packets.
Therefore, both ends should be set to “on” mode before the channel can form.
EtherChannel “auto” (PAgP) or “passive” (LACP) modes participates in the
channel protocol, but only if the far end asks for participation. Therefore, two
switches in the “auto” (PAgP) or “passive” (LACP) modes will not form an
EtherChannel.
EtherChannel “desirable” (PAgP) attempts to ask the far end to bring up a
channel. Therefore, the other end must be set to either “desirable” (PAgP) or
“auto” (PAgP) modes.
EtherChannel “active” (LACP) attempts to ask the far end to bring up a channel.
Therefore, the other end must be set to either “active” (LACP) or “passive”
(LACP) modes.
PAgP “desirable” and “auto” modes defaults to the “silent” submode, in which
no PAgP traffic is expected from the far end. If ports are set to “non-silent”
submode, PAgP traffic must be received before a channel will be formed.
P a g e | 93
EtherChannel Configuration:
- For each EtherChannel on a switch, you must choose the EtherChannel negotiation
protocol and assign range of switch ports to the EtherChannel.
- As switch ports are configured to be members of an EtherChannel, the switch
automatically creates a logical port-channel interface, this interface represents the
channel as a whole.
a) Configuring a PAgP EtherChannel:
- To configure switch ports for PAgP negotiation, use the following commands:
Switch(config)# interface range “type mod/num.” , “type mod/num.” , …. Switch(config-if-range)# channel-protocol PAgP Switch(config-if-range)# channel-group “number” mode {on | {{auto | desirable} [non-silent]}}
Note: - On all Cisco IOS-based Catalyst switch models, you can select between
PAgP and LACP as a channel negotiation protocol.
- Some older models offer only PAgP, so the “channel-protocol” command is
not available.
- All interfaces included in a single EtherChannel bundle must be assigned to the same
unique channel group number (1 to 64).
- Channel negotiation must be set to either “desirable”, “auto”, or “on” modes.
- By default, the “desirable” and “auto” PAgP modes operates in the silent mode, and
allow ports to be added to an EtherChannel even if the other end of the link is silent
and never transmits PAgP packets.
- The key is in the phrase “if the other end is silent”, the silent submode listens for any
PAgP packets from the far end, looking to negotiate a channel.
- If none is received, silent submode assumes that a channel should be built anyway, so
no more PAgP packets are expected from the far end.
- This allows a switch to form an EtherChannel on access ports where a host such as a
server is connected and does not participates in PAgP negotiation.
P a g e | 94
- If you expect a PAgP-capable switch to be in the far end, you should add the “non-
silent” keyword to the “desirable” or “auto” modes.
- This requires each port to receive PAgP packets before adding them to a channel.
- If PAgP is not 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.
Example: - Consider the following two switches are connecting using 4-Fast Ethernet
ports (0/1, 0/2, 0/3, and 0/4).
Requirements:
Configure an EtherChannel load-balancing hash of both source and destination IP
addresses.
Configure a Fast EtherChannel (FEC) between the 4 interfaces of each switch.
Configure Switches to actively negotiating a PAgP channel.
- To accomplish these requirements, use the following commands:
Switch-A(config)# port-channel load-balancing src-dst-ip Switch-A(config)# interface range fastEthernet 0/1 - 4 Switch-A(config-if-range)# channel-protocol pagp Switch-A(config-if-range)# channel-group 1 mode desirable non-silent Switch-A(config)# interface port-channel 1 Switch-A(config-if)# switchport mode dynamic desirable Switch-A(config-if)# switchport trunk native vlan 100
Switch-B(config)# port-channel load-balancing src-dst-ip Switch-B(config)# interface range fastEthernet 0/1 - 4 Switch-B(config-if-range)# channel-protocol pagp Switch-B(config-if-range)# channel-group 2 mode desirable non-silent Switch-B(config)# interface port-channel 2 Switch-B(config-if)# switchport trunk native vlan 100
Note: - Configure the Port-channel interface as any other interface with the same
commands used.
P a g e | 95
b) Configuring a LACP EtherChannel:
- To configure switch ports for LACP negotiation, use the following commands:
Switch(config)# lacp system-priority “priority” Switch(config)# interface range “type mod/num.” , “type mod/num.” , ….. Switch(config-if-range)# channel-protocol lacp Switch(config-if-range)# channel-group “number” mode {on | passive | active} Switch(config-if-range)# lacp port-priority “priority”
- First, the switch should have its LACP system priority defined (1 to 65,535 default
value is 32,768).
- If desired, One switch should be assigned a lower system priority than the other so that
it can make decisions about the EtherChannel’s makeup.
- Otherwise, both switches will have the same system priority (32,768) and the one with
the lower MAC address will become the decision maker.
- All interfaces included in a single EtherChannel bundle must be assigned to the same
unique channel group number (1 to 64).
- Channel negotiation must be set to either “on”, “passive”, or “active” modes.
Note: - You can configure more interfaces in the same channel-group number than
are allowed to be active in the channel.
- This prepares extra standby interfaces to replace failed active ones.
- Use the “lacp port-priority” command to configure a lower port priority (1 to 65,535)
and default is (32,768) for any interfaces that must be active, and the higher priority
for interfaces that might be held in the standby state.
- Otherwise, just use the default scenario, in which all ports default to (32,768) and the
lower port numbers (in interface number order) are used to select the active ports.
P a g e | 96
Example: - Consider the following two switches are connecting using 10-Fast
Ethernet ports (from 0/1 to 0/10).
Requirements:
Configure an EtherChannel load-balancing hash of both source and destination
MAC addresses.
Configure a Fast EtherChannel (FEC) between 8 interfaces and 2 standby
interfaces.
Configure Switches to actively negotiating a LACP channel.
- To accomplish these requirements, use the following commands:
Switch-A(config)# port-channel load-balancing src-dst-ip Switch-A(config)# lacp system-priority 100 Switch-A(config)# interface range fastEthernet 0/1 - 8 Switch-A(config-if-range)# channel-protocol lacp Switch-A(config-if-range)# channel-group 1 mode active Switch-A(config-if-range)# lacp port-priority 100 Switch-A(config)# interface range fastEthernet 0/9 - 10 Switch-A(config-if-range)# channel-protocol lacp Switch-A(config-if-range)# channel-group 1 mode active Switch-A(config)# interface port-channel 1 Switch-A(config-if)# switchport mode dynamic desirable Switch-A(config-if)# switchport trunk native vlan 100
Switch-B(config)# port-channel load-balancing src-dst-ip Switch-B(config)# interface range fastEthernet 0/1 - 8 Switch-B(config-if-range)# channel-protocol lacp Switch-B(config-if-range)# channel-group 1 mode active Switch-B(config-if-range)# lacp port-priority 100 Switch-B(config)# interface range fastEthernet 0/9 - 10 Switch-B(config-if-range)# channel-protocol lacp Switch-B(config-if-range)# channel-group 1 mode active Switch-B(config)# interface port-channel 1 Switch-B(config-if)# switchport trunk native vlan 100
P a g e | 97
Troubleshooting an EtherChannel:
- To verify the EtherChannel state, use the following command:
Switch-A# show etherchannel summary
Flags: D - down P - in port-channel
I - stand-alone s - suspended
H - Hot-standby (LACP only)
R - Layer3 S - Layer2
U - in use f - failed to allocate aggregator
u - unsuitable for bundling
w - waiting to be aggregated
d - default port
Number of channel-groups in use: 1
Number of aggregators: 1
Group Port-channel Protocol Ports
---------+--------------------+--------------+--------------------------------------------------------------
1 Po1(SU) PAgP Fa0/1(P) Fa0/2(P) Fa0/3(P) Fa0/4(P)
- Each port in the channel is shown, along with flags indicating the port’s state.
- The status of the port channel shows the EtherChannel logical interface as a whole.
- This should show SU (Layer 2 Channel, in use) if the channel is operational.
- You can also, examine the status of each port within the channel.
- Most of the EtherChannel ports have flags (P), indicating that they are active in the
port-channel.
Note: - If a port is physically not connected or down, that port will not have the flag
(P) shown in the output.
- If a port is connected but not bundled in the channel, it will have an
independent or (I) flag.
P a g e | 98
- To verify the EtherChannel negotiation mode, use the following command:
Switch-A# show etherchannel port
Channel-group listing:
-----------------------------
Group: 1
------------
Ports in the group:
--------------------------
Port: Fa0/1
---------------
Port state = Up Mstr In-Bndl
Channel group = 1 Mode = Desirbale-S1 Gcchange = 0
Port-channel = Po1 GC = 0x00010001 Pseudo port-channel = Po1
Port index = 0 Load = 0x00 Protocol = PAgP
Age of the port in the current state: 00d:00h:01m:53s
Port: Fa0/2
---------------
Port state = Up Mstr In-Bndl
Channel group = 1 Mode = Desirbale-S1 Gcchange = 0
Port-channel = Po1 GC = 0x00010001 Pseudo port-channel = Po1
Port index = 1 Load = 0x00 Protocol = PAgP
Age of the port in the current state: 00d:00h:01m:53s
!Lines are omitted for brevity
Local information:
Hello Partner PAgP Learning Group
Port Flags State Timers Interval Count Priority Method Ifindex
Fa0/1 SC U6/S7 H 30s 1 128 Any 55
Partner’s information:
Partner Partner Partner Partner Group
Port Name Device ID Port Age Flags Cap.
Fa0/1 FarEnd 00E0.A320.8253 0/1 19s SAC 11
- The local switch is shown using “desirable” mode with PAgP (Desirable-SI is
desirable silent mode).
P a g e | 99
Note: - You can see the far end’s negotiation mode under the Partner Flags heading,
as A, or auto mode (if Switch-B is configured as “auto silent” mode)
- Within a switch, an Etherchannel cannot form unless each of the member ports are
configured consistently.
- Each must have the same switch mode (access or trunk), native VLAN, trunked
VLANs, port speed, port duplex mode, and so on.
- To show all active EtherChannel parameters for a single interface:
Switch-A# show interface fastEthernet 0/1 etherchannel Port state = Up Mstr In-Bndl Channel group = 1 Mode = Desirbale-S1 Gcchange = 0 Port-channel = Po1 GC = 0x00010001 Pseudo port-channel = Po1 Port index = 0 Load = 0x00 Protocol = PAgP Age of the port in the current state: 00d:00h:24m:52s
Note: - If you configure a port inconsistently with others for an EtherChannel, you
will see error messages from the switch.
- Some messages from the switch might look like errors but are part of the normal
EtherChannel process.
- For example, as a new port is configured as a member of an existing EtherChannel,
you might see this message:
00:15:34: %EC-5-L3DONTBNDL2: FastEthernet0/6 suspended: incompatible partner port with
FastEthernet0/7
- When the port first is added to the EtherChannel, it is incompatible because the STP
runs on the channel and the new port.
- After STP takes the new port through its progression of states, the port is automatically
added into the EtherChannel.
- Other messages do indicate a port-compatibility error.
- In these cases, the cause of the error is shown.
- For example, the following message tells that Fast Ethernet0/6 has a different duplex
mode than the other ports in the EtherChannel:
00:17:17: %EC-5-CANNOT_BUNDLE2: FastEthernet0/6 is not compatible with FastEthernet0/7 and
will be suspended (duplex of Fa0/6 is full, Fa0/7 is half)
P a g e | 100
- To verify the EtherChannel load distribution or hashing algorithm:
Switch-A# show etherchannel load-balance
EtherChannel Load-Balancing Operational State (src-dst-ip):
Non-IP: Source XOR Destination MAC address
IPv4: Source XOR Destination IP address
IPv6: Source XOR Destination IP address
Note: - The switches on either end of an EtherChannel can have different load
distribution methods.
- The only draw back to this is that the load distribution will be asymmetric in
the two directions across the channel.
- To show the current EtherChannel status of each member port:
Switch# show etherchannel summary
Switch# show etherchannel port
- To show the time stamps of EtherChannel changes and load distribution port index
used by the has algorithm:
Switch# show etherchannel port-channel
- To show detailed status about each EtherChannel component:
Switch# show etherchannel detail
- To show the LACP system ID:
Switch# show lacp sys-id
- To show the EtherChannel neighbors on each port:
Switch# show {pagp | lacp} neighbor
P a g e | 101
Chapter 6 Traditional Spanning Tree Protocol
Bridging Loops:
- The following figure shows a simple Layer 2 switched network forwarding frames
between two end hosts.
Layer 2 Switched Network with No Redundant Links
- This network design offers no additional links or paths for redundancy if one of the
links fails.
- In that case, the two end hosts on either side of the network would become isolated
from each other.
- To add some redundancy, you can add a third switch (Switch-C) with redundant links
added to the existing network as shown in the following figure.
Layer 2 Switched Network with Redundant Links
P a g e | 102
- In this case, a single link can fail without causing end-to-end connectivity to fail.
- Now, lets examine how this redundancy will affect the network.
- Consider what happens when PC-1 sends a frame to PC-2.
a) For now, assume that both PC-1 and PC-2 are known to the switches and are in their
CAM tables (MAC address tables).
- When PC-1 sends a frame to PC-2, because PC-2 is already known to Switch-A, the
frame is forwarded out port 1/2 to Switch-B.
- Switch-B the forward the frame out of port 1/3 to PC-2.
b) Now, consider that no switches knows anything about the location of PC-1 and PC-2.
- When PC-1 sends a frame to PC-2 by sending it to Switch-A.
- Because the MAC address of PC-1 has not yet been seen or recorded, Switch-A
records PC-1’s MAC address in its MAC address table along with the receiving port
number 1/3.
- Because the location of PC-2 is unknown, Switch-A correctly decide to flood the
frame out all available ports (this is unknown unicast condition).
- Switch-A floods the frame out of ports 1/2 and 1/1.
- Switch-B and Switch-C both receives the frame on their ports 1/1 and 1/1 respectively.
- Switch-B has no entries for PC-2 in its MAC address table , so it decide to flood the
frame out of ports 1/2 and 1/3 to Switch-C and PC-2 respectively and learn that PC-1
can be reached through port 1/1.
- Switch-C has no entries for PC-2 in its MAC address table, so it decide to flood the
frame out of port 1/2 to Switch-B and learn that PC-1 can be reached through port 1/1.
P a g e | 103
- Now, Switch-B hears the new frame forwarded by Switch-C, and Switch-C hears the
new frame forwarded by Switch-B.
- Switch-B sees that the “new” frame is from PC-1, Switch-B previously learned that
PC-1 was on port 1/1, so Switch-B must relearn the location of PC-1 with the most
recent information, which is now incorrectly assumes to be port 1/2.
- Switch-C follows the same procedure, based on the “new” frame from Switch-B.
- Switch-A receives the “new” frame from both Switch-B and Switch-C, making
Switch-A keeps relearning the location of the directly attached host PC-1 one time at
port 1/2 and one time at port 1/1 and then reflood the frame because no entry for PC-2
is in its MAC address table.
- Now, all switches keep relearning the location of PC-1 then the entire process repeats.
- Bridging Loops Is the process of forwarding a single frame around and around
between switches.
- For now, nothing can stop the frame from being forwarded forever in this fashion.
- Notice how the learned location of PC-1 keeps changing as frames get looped, and
each switch’s MAC address table is repeatedly corrupted with incorrect data.
- This type of broadcast storm can easily saturate the network and bring every host to a
halt.
- The only way to end the loop is to run the Spanning-Tree Protocol (STP).
P a g e | 104
Spanning-Tree Protocol (STP):
- STP Is defined in the IEEE 802.1D standard and was developed to prevent the
bridging loops so that redundant links and switches can be used in the
network.
- Basically, the STP enables switches to become aware of each other so they can
negotiate a loop-free path through the network.
- Loops are discovered before they are made available for use, and redundant links are
effectively blocked to prevent loops from being formed.
- In the case of redundant links, switches can be made aware that a blocked link for loop
prevention should be brought up quickly in case of a link failure (this process is called
Convergence).
- STP is communicated among all connected switches on a network.
- Each switch executes the spanning-tree protocol based on information received from
other neighboring switches.
- STP chooses a reference point (root bridge) in the network and calculates all the
redundant paths to that reference point.
- When redundant paths are found, the STP picks one path by which to forward frames
and blocks forwarding on the other redundant paths.
- As its name implies, STP computes a tree structure that spans all switches in a subnet
(VLAN) or network.
- Redundant paths are placed in a Blocking (or standby) state to stop frame forwarding
to prevent loops from being formed.
- The switched network is then in a loop-free condition.
- However, when a forwarding port fails or becomes disconnected, the STP recomputes
the spanning-tree topology so that the appropriate blocked ports can be reactivated.
STP Communication:
a) Bridge Protocol Data Unit (BPDU):
- BPDUs Are the STP data messages that are exchanged between switches during the
communication between each other.
P a g e | 105
- A switch sends a BPDU frame out a port using the unique MAC address of the port
itself as a source address.
- The switch is unaware of other switches around it, so BPDU frames are sent with a
destination MAC address of the STP well-known multicast address.
(0180-c200-0000).
- There are two types of BPDUs exists:
Configuration BPDUs Are used for the STP computation.
Topology Change Notification (TCN) BPDUs Are used to announce changes in
the network topology.
- The configuration BPDU message contents are shown in the following table:
Field Description Number of Bytes
Protocol ID (always 0) 2
Version (0) (for STP 802.1D)
and (2) (for RSTP 802.1w) 1
Message Type (Configuration BPDU) 1
Flags 1
Root Bridge ID 8
Root Path Cost 4
Sender Bridge ID 8
Port ID 2
Message Age 2
Maximum Age 2
Hello Time 2
Forward Delay 2
P a g e | 106
Note: - The TCN BPDU message contents will be discussed later in this chapter.
- The exchange of BPDU messages works toward the goal of electing a reference point
as foundation for a stable STP topology.
- Loops can be identified and removed by placing specific redundant ports in a Blocking
state.
- Several key fields in the BPDU are related to bridge (or switch) identification, path
costs and time values.
Note: - By default, BPDUs are sent out all switch ports every 2 seconds so that the
current topology information is exchanged and loops are identified quickly.
b) Electing a Root Bridge:
- Root Bridge A switch with the lowest bridge ID.
- For all switches in a network to agree on a loop-free topology, a reference point must
exist to be used as a guide.
- This reference point is called the “Root Bridge”.
Note: - The term “bridge” continues to be used even in a switched environment
because STP was developed for use in bridges. Therefore, when you see
“bridge”, think switch.
- An election process among all connected switches chooses the root bridge.
- Each switch has a unique Bridge ID (BID) that identifies it to other switches.
- The Bridge ID is 8-bytes value consisting of:
Bridge Priority (2-bytes) - The priority of a switch in relation to all other
(Default 32,768) switches.
- The priority field can have a value of 0 to 65,535 and
defaults to 32,768 (or 800000 hex) on every Catalyst
Switch.
P a g e | 107
Switch MAC Address (6-bytes) - The MAC address used by the switch can
come from the supervisor module, the
backplane, or a pool of 1024 addresses that are
assigned to every supervisor or backplane
depending on the switch model.
- In any event, this address is hard-coded and
unique, and the user cannot change it.
- When a switch first powers up, it has a narrow view of its surroundings and assumes
that it is the root bridge itself.
- This notion probably will change as other switches check in and enter the election
process.
- The election process then proceeds as follows:
Step 1 Every switch begins by sending out BPDUs with a root bridge ID equal to its
own bridge ID and a sender bridge ID that is its own bridge ID.
Note: - The sender bridge ID simply tells other switches who is the actual sender of
the BPDU message.
Step 2 Received BPDU messages are analyzed by every switch to see if a “better”
root bridge is being announced.
Note: - A root bridge is considered better if the root bridge ID value is lower than
another.
- If two switches have equal bridge priority values (tie), the lower MAC address
(tie-breaker) makes the bridge ID better.
Step 3 When a switch hears of a better root bridge, it replaces its own root bridge ID
field with the root bridge ID announced in the BPDU.
P a g e | 108
Step 4 The switch then is required to advertise the new root bridge ID in its own
BPDU messages, although it still identifies itself as the sender bridge ID.
Step 5 Sooner or later, all switches agrees on the notion that one of them is the root
bridge (reference point).
Note: - As might be expected, if a new switch with a lower bridge ID powers up, all
the switches soon reconsider and record it as the new root bridge.
- The root bridge election process is an ongoing process, triggered by root
bridge ID changes in the BPDUs every 2 seconds.
- For example, consider the Layer 2 switched network used earlier with the following
switches’ MAC addresses:
Switch-A MAC Address a293.52f0.c348.
Switch-B MAC Address b384.3782.56f3.
Switch-C MAC Address b286.3842.57ab.
- All the switches have the default bridge priority of (32,768).
- All switches are interconnected using Fast Ethernet links.
- The election of the root bridge determines the switch with the lowest bridge ID,
because they all have the same default bridge priority, the switch with the lowest
MAC address will be elected the root bridge, which in this example is Switch-A (the
first hex digit is “a” which is less than “b” and “b” of the other switches).
P a g e | 109
c) Electing Root Ports:
- Root Port Is the only one port on every nonroot switch that has the lowest “root
path cost” (the best path to the root bridge).
- Now that a root bridge has been elected for the entire switched network, each nonroot
switch must figure out where it is in relation to the root bridge.
- This action can be performed by selecting only one root port on each nonroot switch.
- If two ports on one switch tied (same root path cost toward the root bridge) the Port ID
is used as a tie- breaker (The Port ID will be explained in Chapter 7).
- STP uses the concept of “Cost” to determine many things.
- Selecting a root port involves evaluating the “root path cost”.
- Root Path Cost Is the cumulative cost of all links leading to the root bridge.
- A particular switch link also has a cost associated with it, called the path “cost”.
Note: - Only the “root path cost” is carried inside the BPDU.
- As the “root path cost” travels along, other switches can modify its value to
make it cumulative.
- The path “cost” is not contained in the BPDU.
- The path “cost” is only known to the local switch where the port (or “path”
to a neighboring switch) resides.
- The path “cost” is a 1-byte value, with the default values show in the following table:
Link Bandwidth STP Cost
10 Mbps 100
100 Mbps 19
1 Gbps 4
10 Gbps 2
- The higher the bandwidth of a link, the lower the cost of transporting data across it.
P a g e | 110
- The root path cost is determined in the following manner:
Step 1 The root bridge sends out a BPDU with a root path cost value of 0 because its
ports sit directly on the root bridge.
Step 2 When the next-closet neighbor receives the BPDU, it adds the path cost of its
own port where the BPDU “arrived” (this is done as the BPDU is “received”).
Step 3 The received neighbor sends out BPDU out other ports with this root path
cost.
Step 4 The root path cost is incremented by the ingress port’s path cost as the BPDU
is received by other neighbors.
Note: - Notice the emphasis on incrementing the root path cost as the BPDU are
received.
- When computing the STP manually, remember to compute a new root path
cost as BPDUs come in to a switch port, not as they go out.
Step 5 When a switch receives BPDUs with different values for the root path cost,
the switch chooses the BPDU with the lowest root path cost and elect it as the
root port.
- The switch has now determined which of its ports has the best path to the root bridge,
which is the root port.
P a g e | 111
- In the previous example, Switch-B selects its port 1/1 to be the root port, and Switch-C
selects its port 1/1 to be the root port with a root path cost equal to (0+19).
- Port 1/2 is not chosen by Switch-B as root port because its root path cost is 0 (BPDU
from Switch-A) plus 19 (path cost of A-C link) plus 19 (path cost of C-B link) of a
total of 38, which is higher than 19 root path cost of Switch-B port 1/1.
- Port 1/2 is not chosen by Switch-C as root port because its root path cost is 0 (BPDU
from Switch-A) plus 19 (path cost of A-B link) plus 19 (path cost of B-C link) of a
total of 38, which is higher than 19 root path cost of Switch-C port 1/1.
d) Electing Designated Ports:
- Designated Port The only one port on a link between switches that have the lowest
root path cost and should forward traffic.
- At this point, all links still are connected and could be active, leaving loops.
- To prevent loops, STP makes a final computation to identify one designated port on
each link between switches.
- Only one port on a link between switches should forward traffic, that selected port is
the designated port.
- The other port on the same link should be in the STP Blocking state to prevent loops
because it is neither a root port nor a designated port.
- Switches chooses a designated port based on the lowest cumulative root path cost to
the root bridge, if tied, then the port on the switch with the lowest sender bridge ID.
- In each determination process of the designated port, two ports of a link might have
identical root path costs.
- This result in a tie condition, unless other factor is considered as a tie-breaker.
- The tie-breaker is based on the following:
The lowest Sender bridge ID (the local switch bridge ID).
Note: - By definition, all the root bridge ports are designated ports.
- The root bridge has no root ports.
P a g e | 112
- From the previous example, to determine the choices of the designated ports.
- The three switches have chosen their designated ports for the following reason:
Switch-A Because this switch is the root bridge, all its active ports are
designated ports.
Switch-C The port 1/2 is the designated port on the link C-B, because ports on
this link have the same root path costs (38), but Switch-C has a lower
bridge ID (because of its lower MAC address “b2” than Switch-B’s
MAC address “b3”). Therefore, Switch-C port 1/2 is the link’s
designated port.
Switch-B The port 1/2 is neither a root port nor a designated port, so any port
that is neither a root port nor a designated port enters the Blocking
state.
- When blocking Switch-B’s port 1/2, loops are prevented in the switched network.
STP Port States (Sts):
- To participate in STP, each port of a switch must progress several states.
- A port begins its life in a Disabled state (not STP state), moving through several
passive states, and finally, into an active state if allowed to forward traffic.
P a g e | 113
- The STP port states are as follows:
Blocking - After a port initializes, it begins in the “Blocking” state so that no
(BLK) bridging loops can form.
- In the Blocking state:
A port cannot send or receive data frames.
A port cannot learn MAC addresses to add to its CAM table.
A port can only receive BPDUs.
Listening - A port is moved from Blocking to Listening if the switch thinks that
(LIS) the port can be selected as a root port or designated port.
- In the Listening state:
A port cannot send or receive data frames.
A port cannot learn MAC addresses to add to its CAM table.
A port can send and receive BPDUs.
- If the port loses its root port or designated port status, it returns to
the Blocking state.
Learning - After a period of time called the “Forward Delay” in the listening
(LRN) state, the port is allowed to move into the learning state.
- In the Learning state:
A port cannot send or receive data frames.
A port can learn MAC addresses to add to its CAM table.
A port can send and receive BPDUs.
Forwarding - After another “Forward Delay” in the Learning state, the port is
(FWD) allowed to move into the Forwarding state.
- In the Forwarding state:
A port can send and receive data frames.
A port can learn MAC addresses to add to its CAM table.
A port can send and receive BPDUs.
- The port is now fully functioning with the STP.
Forward Delay
(15 Seconds)
Forward Delay
(15 Seconds)
P a g e | 114
Note: - A switch is allowed into the Forwarding state only if no loops are detected
and if the port is a root port or a designated port.
- To show the output from the three switches to see the STP port states (Sts), port roles
(Role), path cost (Cost), and switch’s bridge ID, use the following commands:
Switch-A# show spanning-tree
VLAN0001
Spanning tree enabled protocol ieee
Root ID Priority 32768
Address A293.52F0.C348
This bridge is the root
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 32768
Address A293.52F0.C348
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 20
Interface Role Sts Cost Prio.Nbr Type
-------------------- ------ ----- ------------ ----------- --------------------------------
Fa1/2 Desg FWD 19 128.2 P2p
Fa1/1 Desg FWD 19 128.1 P2p
Switch-B# show spanning-tree
VLAN0001
Spanning tree enabled protocol ieee
Root ID Priority 32768
Address A293.52F0.C348
Cost 19
Port 1 (FastEthernet1/1)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 32768
Address B384.3782.56F3
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 20
Interface Role Sts Cost Prio.Nbr Type
------------------- ------ ----- ---------- ----------- ---------------------------------
Fa1/2 Altn BLK 19 128.2 P2p
Fa1/1 Root FWD 19 128.1 P2p
P a g e | 115
Switch-C# show spanning-tree
VLAN0001
Spanning tree enabled protocol ieee
Root ID Priority 32768
Address A293.52F0.C348
Cost 19
Port 1 (FastEthernet1/1)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 32768
Address B286.3842.579A
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 20
Interface Role Sts Cost Prio.Nbr Type
------------------ ---- ---- --------- ----------- --------------------------------
Fa1/1 Root FWD 19 128.1 P2p
Fa1/2 Desg FWD 19 128.2 P2p
- STP switch ports are assigned one of the following port roles:
Root Port (Root) Works in the Forwarding (FWD) state.
Designated Port (Desg) Works in the Forwarding (FWD) state.
Alternate Port (Altn) Holds in the Blocking (BLK) state as a backup root port.
STP Timers:
- STP operates as switches send BPDUs to each other to form a loop-free topology.
- The BPDUs take a finite amount of time to travel from switch to switch.
- In addition, news of a topology change (such as a link or root bridge failure) can suffer
from propagation delays as the announcement travels from one side of a network to
the other.
- Because of the possibility of these delays, keeping the spanning-tree topology from
settling out or converging until all switches have had time to receive accurate
information is important.
- STP uses 3 timers to make sure that a network converges properly before a bridging
loop can form.
P a g e | 116
- The STP timers are:
STP Timer Function
Hello Timer
(Default 2 Seconds) - Is the time interval between sending BPDUs.
Forward Delay
(Default 15 Seconds)
- Is the time interval that a switch port spends in both the
Listening and Learning states.
Max Age
(Default 20 Seconds)
- Is the maximum length of time a switch can store a BPDU
without receiving an update.
Note: - The timer values shouldn’t be changed from the defaults without careful
consideration.
- The timer values can be changed only on the root bridge.
- The root bridge ensures that the timer values propagated to all other switches
as they are advertised in fields within the BPDU.
- The default STP timer values are based on some assumptions about the size of the
network and the length of the Hello Timer.
- A reference model of a network having a diameter of 7 switches derives these values.
- The diameter is measured from the root bridge outward (including the root bridge).
- In other words, if you draw the STP topology, the diameter is the number of switches
connected in series from the root bridge out to the end of any branch in the tree.
- The Hello Timer is based on the time it takes for a BPDU to travel from the root
bridge to a point 7 switches away.
- This computation uses a Hello Timer of 2 seconds.
- The network diameter can be configured on the root bridge to more accurately reflect
the true size of the physical network.
- Making that value more accurate reduces the total STP convergence time during a
topology change.
- It is highly recommended that if changes needs to be made, only the network diameter
value should be modified on the root bridge (more details in the next chapter).
- When the diameter is configured for a different value, the switch calculates new values
for all the three timers automatically.
P a g e | 117
Topology Changes:
- To announce a change in the active network topology, switches send a TCN BPDUs.
- The TCN BPDU message contents are shown in the following table:
Field Description Number of Bytes
Protocol ID (always 0) 2
Version (0) (for STP 802.1D)
and (2) (for RSTP 802.1w) 1
Message Type (TCN BPDU) 1
- A topology change occurs when a switch either moves a port into the Forwarding state
or moves a port into the Blocking state.
- In other words, a port on an active switch comes up or goes down.
- The switch sends a TCN BPDU out its root port so that the root bridge receives news
of the topology change.
Note: - The TCN BPDU carries no data about the change but informs recipients only
that a change has occurred.
- The switch will not send TCN BPDUs if the port has been configured with PortFast
enabled.
- The switch continues sending TCN BPDUs every Hello Timer interval until it gets an
acknowledgment from its upstream neighbor.
- A the upstream neighbors receive the TCN BPDU, they propagate it toward the root
bridge and send their own acknowledgments.
- When the root bridge receives the TCN BPDU, it also sends out an acknowledgment.
- The root bridge sets the Topology Change Flag in its Configuration BPDU, which is
relayed to every other switch in the network.
- This is done to signal the topology change and cause all other switches to shorten their
MAC address table Aging Time from the default (300 seconds) to the Max Age value
(20 seconds).
P a g e | 118
- This condition causes the learned locations of MAC addresses to be flushed out much
sooner than they normally would, easing the MAC address table computation that
might occur because of the change in topology that could make a loop.
- This condition lasts for the sum of the Max Age (20 seconds) and the Forward Delay
(15 seconds).
- Any hosts that are actively communicating during this time are kept in the MAC
address table, because only stale entries will be flushed after the 20 seconds of the
Max Age timer.
- The following examples gives some different types of topology changes along with the
sequence of STP events.
- Each type has a different cause and a different effect.
- To provide continuity as the STP concepts are presented, the same network previously
shown is used in each of these examples.
a) Direct Topology Changes:
- A direct topology change is one that can be detected on a switch interface.
- For example, if a trunk suddenly goes down, the switch on each end of the link can
immediately detect a link failure.
- The following figure shows a network that has converged into a stable STP topology.
Effects of a Direct Topology Change
P a g e | 119
- Only switch-B port 1/2 is in the Blocking state.
- This network has just suffered a link failure between Switch-A and B, the following is
the sequence of events:
1) Switch-A detects a link down on its port 1/2 and Switch-B detects a link down on its
port 1/1.
2) - Switch-B removes the previous “best” BPDU it had received over port 1/1.
- Normally, Switch-B would try to send a TCN BPDU out its root port, to reach the
root bridge, but here the root port is broken, so that is not possible.
Note: - Without an advanced feature such as STP UplinkFast, Switch-B is not yet
aware that another path exists to the root bridge (UplinkFast will be
discussed later in Chapter 7).
3) The root bridge, Switch-A, sends a Configuration BPDU with the TCN flag bit set
out its port 1/1, informing each switch of the topology change.
4) - Switch-C and Switch-B receives the Configuration BPDU message, the only
reaction these switches take is to shorten their MAC address table Aging timer to
the Max Age timer (20 seconds).
- At this point, they don’t know how the topology has changed, they only know to
force their recent MAC address table entries to age out.
5) - Switch-B basically just sits and waits to hear from the root bridge again.
- The Configuration BPDU TCN message received on port 1/2 which is in the
Blocking state. This BPDU becomes the “best” one received from the root, so port
1/2 becomes the new root port.
- Switch-B can now progress port 1/2 from Blocking through the Listening, Learning,
and Forwarding states.
- As a result of a direct link failure, the topology has changed and STP has converged
again.
P a g e | 120
Note: - Only Switch-B has undergone any real effects from the failure.
- Switch-A and C heard the news of the topology change but did not have to
move any links through the STP states.
- In other words, the whole network did not go through a massive STP
convergence.
- The total time that host on Switch-B lost connectivity is the time that port 1/2 spent in
the Listening and Learning states.
- With the default STP timers, this amounts to about 2 times the Forward Delay period
which is 30 seconds.
b) Indirect Topology Changes:
- The following figure show the same network but this time the link failure indirectly
involves Switch-A and Switch-B.
Effects of an Indirect Topology Change
- The link status between Switch-A and Switch-B stays up, but something between them
is filtering traffic.
- As a result, no data (including BPDUs) can pass between those switches.
- STP can detect and recover from indirect failures, thanks to the timer mechanisms.
P a g e | 121
- The sequence of events are as follows:
1) Switch-A and Switch-B both show a link up condition, data begins to be filtered
elsewhere on the link.
2) No link failure is detected, so no TCN BPDUs are sent.
3) - Switch-B already has stored the “best” BPDU it had received from the root over
port 1/1.
- No further BPDUs are received from the root bridge over that port.
- After the Max Age timer expires, no other BPDU is available to refresh the “best”
entry, so it is flushed.
- Switch-B now must wait to hear from the root bridge again on any of its ports.
4) - The next configuration BPDU from the root is heard on Switch-B port 1/2.
- This BPDU becomes the new “best” BPDU with the lowest “root path cost” to the
root bridge, so port 1/2 becomes the root port.
- Now the port is progressed from Blocking through the Listening, Learning, and
finally the Forwarding state.
- As a result of the indirect link failure, and the absence of BPDUs from the root bridge,
causes the Max Age timer to expires and Switch-B take some actions.
- Because this type of failure relies on STP timer activity, it generally takes longer to
detect and mitigate.
- In this example, the total time that uses on Switch-B lost connectivity is the same time
until the Max Age timer expires (20 seconds), plus the time until the next
Configuration BPDU is received (2 seconds) on port 1/2, plus the time that port 1/2
spent in the Listening (15 seconds) and Learning (15 seconds) states.
- In other words, 52 seconds elapse if the default timer values are used.
P a g e | 122
c) Insignificant Topology Changes:
- The following figure shows the same previous network topology with the addition of a
user PC on access port on Switch-B.
Effects of an Insignificant Topology Change
- The host’s switch port 1/12 is just another link as far as the switch is concerned.
- If the link status goes up or down, the switch must view that as a topology change and
inform the root bridge.
- Obviously, user ports are expected to go up and down as the users reboot their PCs,
turn them on or off and so on.
- Regardless, TCN BPDUs are sent by the switch, just as if a trunk link between
switches had changed state.
- To see what effect this has on the STP topology and the network, consider the
following sequence:
1) The host PC on Switch-B port 1/12 is turned off, the switch detects the link status
going down.
P a g e | 123
2) Switch-B begins sending TCN BPDUs toward the root, over its root port 1/1.
3) - The root bridge sends a TCN acknowledgment back to switch B and then sends a
Configuration BPDU with the TCN bit set to all down stream switches.
- This done to inform every switch of a topology change somewhere in the network.
4) - The TCN flag is received from the root and both switches B and C shorten their
MAC address table Aging timers.
- This causes recently idle entries to be flushed, leaving only the actively transmitting
stations in the MAC address table.
- The Aging timer stays short for the duration of the Forward Delay and Max Age
timers.
Note: - This type of topology change is mostly cosmetic, no actual topology change
occurred because none of the switches had to change port states to reach the
root bridge.
- Instead, powering of a host PC caused all switches to age out entries from
their MAC address table much sooner than normal.
- This doesn’t seem like a major problem because the PC link state affects only the
contents of the MAC address table.
- If the MAC address table contents are flushed as a result, they probably will be learned
again.
- Remember that when a switch doesn’t have a MAC address table entry, for a
destination, the packet must be flooded out all of its ports.
- Flushed MAC addresses tables means more “unknown unicasts”, which means more
broadcasts or flooded packets through the network.
- Catalyst switches have a feature that can designate a port as a special case, you can
enable the STP PortFast feature on an access port with a single attached host.
- As a result, TCN BPDUs aren’t seen when the access port changes state, and the port
is brought right into the Forwarding state when the link comes up.
P a g e | 124
Types of STP:
- STP was originally developed to operate in a bridged environment, basically
supporting a single LAN (or one VLAN) as explained in this chapter.
- Implementing STP into a switched environment has required additional consideration
and modification to support multiple VLANs.
- This section reviews the three additional types of STP that are encountered in switched
networks and how they relate to one another.
a) Common Spanning Tree (CST):
- CST Is one instance of STP over the native VLAN (IEEE 802.1Q-based).
- The IEEE 802.1Q standard specifies how VLANs are to be trunked between switches.
- It also specifies only a single instance of STP that encompasses all VLANs.
- This instance is referred to as the Common Spanning Tree (CST).
- All CST BPDUs are transmitted over trunk links using the native VLAN with
untagged frames.
- Having a single STP for many VLANs simplifies switch configuration and reduces
switch CPU load during STP calculations.
- However, having only one STP instance can cause limitations, too.
- Redundant links between switches will be blocked with no capability for load
balancing.
- Conditions also can occur that would cause CST to mistakenly enable forwarding on a
link that doesn’t carry a specific VLAN, whereas other links would be blocked.
b) Per-VLAN Spanning Tree (PVST):
- PVST Is a one instance of STP per VLAN (Cisco proprietary).
- PVST operates a separate instance of STP for each individual VLAN.
- This allows the STP on each VLAN to be configured independently, offering better
performance and tuning for specific conditions.
P a g e | 125
- Multiple instances of spanning-trees makes load balancing possible over redundant
links when the links are assigned to different VLANs, whereas one link might forward
one set of VLANs, while another redundant link might forward a different set of
VLANs.
- Because of its proprietary nature, PVST requires the use of Cisco Inter-Switch Link
(ISL) trunking encapsulation between switches.
- In networks where PVST and CST coexist, interoperability problems occur, whereas
each of them requires a different trunking method, so BPDUs are never exchanged
between STP types.
c) Per-VLAN Spanning Tree Plus (PVST+):
- PVST+ Allows interoperability between CST and PVST, whereas it operates over
(The default) both 802.1Q and ISL (Cisco proprietary).
- PVST+ effectively supports 3 groups of STP operating in the same campus network:
Switches running CST over 802.1Q.
Catalyst switches running PVST over ISL.
Catalyst switches running PVST+.
- To do this, PVST+ acts as a translator between groups of CST switches and groups of
PVST switches.
- PVST+ can communicate directly with PVST by using ISL trunks.
- PVST+ can communicate directly with CST by exchanging BPDUs as untagged
frames over 802.1Q trunks.
- BPDUs from other instances of STP (other VLANs) are propagated across the CST
portions of the network by tunneling.
- PVST+ sends these BPDUs by using a unique multicast address so that the CST
switches forward them on to downstream neighbors without interpreting them first.
- Finally, the tunneled BPDUs reach other PVST+ switches where they are understood.
Note: - The IEEE has produced additional standard for STP enhancements called
“Rapid STP” and will be discussed later in Chapter 9.
P a g e | 126
Chapter 7 Spanning Tree Protocol Configuration
STP Root Bridge:
- You can make adjustments to the spanning-tree operation to control its behavior.
- The location of the root bridge should be determined as part of the design process.
Note: - The STP default on most Catalyst switches is PVST+ and is enabled for all
active VLANs and on all ports of a switch.
Root Bridge Placement:
- Although STP is wonderfully automatic with its default values and election processes,
the resulting tree structure might perform quite differently in some areas of the
topology than expected.
- If the root bridge election is left to its default state, several things can occur to result in
a poor root bridge choice.
- The “slowest” switch can be elected as the root bridge, so if heavy traffic loads are
expected to pass through the root bridge, the slowest switch is not the ideal candidate.
- A second factor to consider relates to redundancy.
- If all switches are left at their default states, only one root bridge (primary) is elected,
with no clear choice for a backup (secondary root bridge).
- If the root bridge fails, another root bridge election occurs, but again the choice might
not be the ideal switch or the ideal location.
- The final consideration is the location of the root bridge.
- An election with default switch values could place the root bridge in an unexpected
location in the network.
- An inefficient spanning-tree structure can result traffic from a large portion of the
network to take a long and winding path just to pass through the root bridge.
P a g e | 127
- Consider the following Layer 2 switched campus network (the hierarchy of the campus
network will be explained in more details in Chapter 11):
Campus Layer 2 Switched Network
Note: - Most of the switches use redundant links to other layers of the hierarchy.
- For this example, only Switch-B have a single connection into the
distribution layer for the purpose of showing the effect of the root bridge
location.
- Using the default configuration, Switch-A will be elected to be the root bridge because
of its lowest MAC address among other switches MAC addresses.
- For the purpose of this discussion, the root ports and designated ports are simply
shown in the following network diagram:
P a g e | 128
- As an exercise, you should work through the spanning-tree process yourself.
- Finally, the following figure shows the same network with the blocking links removed.
- Now, you can see the true structure of the final spanning-tree.
- Hosts (PCs) on Switch-A can reach hosts (Servers) on Switch-E by crossing through
Switch-C.
(A ----> C ----> E)
- Hosts (PCs) on Switch-B can reach hosts (Servers) on Switch-E by crossing through
Switch-D back into Switch-A then into Switch-C, and finally to Switch-E.
(B ----> D ----> A ----> C ----> E)
- This action is obviously inefficient.
- Now, consider Switch-C to be the root bridge.
P a g e | 129
- The following figure shows the same network with the blocking links removed.
- Here, hosts (PCs) on Switch-B can reach hosts (Servers) on Switch-E by passing
through Switch-D then Switch-C, which is a less traveled path than when Switch-A
was the root bridge.
(B ----> D ----> C ----> E)
- So, the root bridge should be placed near the center of the Layer 2 network.
Root Bridge Configuration:
- You can configure a switch to become the root bridge by using one of two methods:
Manually configure the bridge priority.
Configure a switch to be a root bridge.
- First, a Catalyst switch can be configured to use one of the following formats for its
STP Bridge ID:
Traditional 802.1D bridge priority value (2-bytes) followed by the unique switch
MAC address.
P a g e | 130
The 802.1t extended system ID (16-bits) priority multiplier + (12-bits) VLAN ID
followed by the unique switch MAC address for the VLAN.
Note: - The extended system ID is always enabled by default if the switch uses
PVST+ by default.
- The traditional method is enabled by default if the switch uses CST by
default.
- To use the extended system ID method (if it is not used by default), use the following
command:
Switch(config)# spanning-tree extend system-id
- To begin using the traditional method, use the following command:
Switch(config)# no spanning-tree extend system-id
a) Manually Configure the Bridge Priority:
- To manually configure the bridge priority of a switch, use the following command:
Switch(config)# spanning-tree priority “bridge-priority”
- If the traditional method is enabled, the “bridge priority” value default is (32,768) for
all active VLANs on the switch.
Switch(config)# spanning-tree vlan “vlan-list” priority “priority-multiplier”
P a g e | 131
- If the extended system ID is enabled, the “priority-multiplier” value default is
(32,768), and the bridge priority will be the “priority-multiplier” plus the VLAN ID,
and the “vlan-list” can include one VLAN ID or a list of VLAN IDs.
- If the “priority-multiplier” is configured, the value of the “priority-multiplier”
configured can range from 0 to 61,440 but only as multiples of 4096.
- Bridge Priority = configured “priority-multiplier” (16-bits) + VLAN ID (12-bits).
- The 16 possible “priority-multiplier” that can be configured are:
0 0000|000000000000
4096 0001|000000000000
8192 0010|000000000000
12288 0011|000000000000
16384 0100|000000000000
20480 0101|000000000000
24576 0110|000000000000
28672 0111|000000000000
32768 1000|000000000000
36864 1001|000000000000
40960 1010|000000000000
… …………
61440 1111|000000000000
Note: - The configured “priority-multiplier” is without adding the VLAN ID.
- The Catalyst switches run one instance of STP for each VLAN (PVST+), so
the VLAN ID must always be given.
- You should designate an appropriate root bridge for every VLAN.
- From the previous campus Layer 2 switched network, to configure Switch-C to be the
root bridge for VLANs 1, 5, 6, 7, and 100, use the following command:
Switch-C(config)# spanning-tree vlan 1,5-7,100 priority 4096
P a g e | 132
a) Configure a Switch to be a Root Bridge:
- To make a switch choose its own bridge priority and be the root bridge in the network,
use the following command:
Switch(config)# spanning-tree vlan “vlan-list” root {primary | secondary}
- The result of this command is a more direct and automatic way to force one switch to
become the primary root bridge and another switch to be the secondary Root Bridge.
Note: - The actual bridge priorities are not given in the command. Instead, the
switch modifies its STP values according to the current values in use within
the active network.
- These values are modified only once, when the command is issued.
- Use the “primary” keyword to make the switch to become the primary root bridge.
- This command modifies the switch’s bridge priority value to become less than the
bridge priority of the current root bridge.
- If the current root bridge "priority-multiplier” is more than (24,576), the local switch
sets its “priority-multiplier” to (24,576).
- If the current root bridge “priority-multiplier” is (24,576), the local switch sets its
“priority-multiplier” to (20480) which is the lower possible “priority-multiplier”, and
so on until reaching to (0).
Note: - If another switch configured with the “spanning-tree … root primary”
command, and both switches configured with the same “priority-multiplier”,
the switch with the lower MAC address becomes the primary root bridge.
- Use the “secondary” keyword to make the switch become the secondary root bridge
(meaning, to be elected as the root bridge if the recent primary root bridge failed).
- The “priority-multiplier” is set to a value of (28,672), which is the next possible
“priority-multiplier” that can be configured.
P a g e | 133
- From the previous campus Layer 2 switched network, to show Switch-D STP bridge
priority values for VLAN 100, use the following commands:
Switch-D# show spanning-tree vlan 100
VLAN0100
Spanning tree enabled protocol ieee
Root ID Priority 4196
Address 0007.EC8E.DCDD
Cost 4
Port 25 (GigabitEthernet0/1)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 32868 (priority 32768 sys-id-ext 100)
Address 000D.BD2C.149B
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 20
Interface Role Sts Cost Prio.Nbr Type
-------------------- ------- ----- --------- ----------- --------------------------------
Fa1/1 Desg FWD 19 128.1 P2p
Fa1/2 Desg FWD 19 128.2 P2p
Gi0/1 Root FWD 4 128.25 P2p
Gi0/2 Desg FWD 4 128.26 P2p
- As shown from the output, the root bridge is Switch-C with bridge priority value of
4196 (which is the summation of the “priority-multiplier” value of 4096 and the
VLAN ID 100).
- The local Switch-D has a higher bridge priority with value of 32868 (32768 “priority-
multiplier” + 100 “VLAN ID”).
- Now, the automatic method is used to attempt to make Switch-D become the primary
root bridge for VLAN 100:
Switch-D(config)# spanning-tree vlan 100 root primary
- To check again Switch-D to show what has changed after this command has been
configured:
P a g e | 134
Switch-D# show spanning-tree vlan 100
VLAN0100
Spanning tree enabled protocol ieee
Root ID Priority 100
Address 000D.BD2C.149B
This bridge is the root
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 100 (priority 0 sys-id-ext 100)
Address 000D.BD2C.149B
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 20
Interface Role Sts Cost Prio.Nbr Type
-------------------- ------- ----- --------- ----------- --------------------------------
Fa1/1 Desg FWD 19 128.1 P2p
Fa1/2 Desg FWD 19 128.2 P2p
Gi0/1 Desg FWD 4 128.25 P2p
Gi0/2 Desg FWD 4 128.26 P2p
- If another switch configured to be the primary root bridge using the “spanning-tree
vlan 100 root primary” command, this switch will choose “priority-multiplier” of (0)
and if it has a lower MAC address than Switch-D, this other switch will be the primary
root bridge, if its MAC address is higher than Switch-D MAC address, then Switch-D
will remain the primary root bridge.
Spanning-Tree Customization:
- The most important decision you can make when designing your spanning-tree
topology is the placement of the root bridge.
- Other decisions, such as the exact loop-free path structure, will occur automatically as
a result of the STP.
- Only the automatic STP computation has been discussed, using the default switch port
“cost” to make specific path decisions.
- The following sections discuss ways you can influence the exact topology that results.
P a g e | 135
a) Tuning the Root Path Cost:
- The root path cost for each active port of a switch is determined by the cumulative cost
as a BPDU travels along.
- As a switch “receives” a BPDU, the port “cost” of the receiving port is added to the
root path cost in the BPDU.
- The port “cost” or path “cost” is inversely proportional to the port’s bandwidth.
- If desired, a port’s “cost” can be modified from the default value, using the following
interface command:
Switch(config-if)# spanning-tree [vlan “vlan-list”] cost “cost”
- The port “cost” is modified for the port as a whole (all active VLANs) or only for a
specified VLAN.
- The “cost” value can range from 1 to 65,535).
- The following table shows the default STP port “cost” values that correspond to port
bandwidth:
Link Bandwidth STP Cost
10 Mbps 100
100 Mbps 19
1 Gbps 4
10 Gbps 2
- For example, a Gigabit Ethernet interface 0/2 of Switch-E has a default port cost of 4,
you can change it using the following command to value 2 for only VLAN 100:
Switch-E(config)# interface gigabitethernet 0/2 Switch-E(config-if)# spanning-tree vlan 100 cost 2
- To show the port “cost” of an interface, use the following command:
Switch-E# show spanning-tree interface “type mod/num.” [cost]
P a g e | 136
- To show Switch-E interface Gigabit Ethernet 0/2 port cost:
Switch-E# show spanning-tree interface gigabitethernet 0/2
Vlan Role Sts Cost Prio.Nbr Type
---------------- ---- ---- --------- ------------ --------------------------------
VLAN0001 Altn BLK 4 128.26 P2p
VLAN0100 Root FWD 2 128.26 P2p
b) Tuning the Port ID:
- A switch can use its port ID value as a tie-breaker between two ports with the same
root path cost to choose only one of them to be the “root port” using the lowest Port ID
value (tuning a port’s port ID is used when choosing a root port for a nonroot switch).
- The Port ID value that a switch uses is a 16-bits value, 8-bits for the port priority and
8-bits for the port number.
- Port Priority Is a value from 0 to 255 and defaults to 128 for all ports.
- Port Number Is a value from 0 to 255 and represents the port’s actual physical
mapping.
- Port Numbers begin with 1 at port 0/1 and increment across each module (The
numbers might not be consecutive because each module is assigned a particular range
of numbers).
- For example, notice how Switch-E interface Gigabit Ethernet 0/2 is also known as Port
Number 26 in the output of the following show command:
Switch-E# show spanning-tree interface gigabitethernet 0/2
Vlan Role Sts Cost Prio.Nbr Type
---------------- ---- ---- --------- ------------ --------------------------------
VLAN0001 Altn BLK 4 128.26 P2p
VLAN0100 Root FWD 2 128.26 P2p
P a g e | 137
- The entire port ID consists of the port priority (128) followed by the port number (26).
- The port ID in this output is (128.26).
Note: - Ports that are bundled into an EtherChannel (Port Channel interface) always
have a higher port ID than they would if they were not bundled.
- Obviously, a switch port’s port number is fixed because it is based only on its
hardware location.
- The port ID can be modified by configuring the port priority using the following
interface configuration command:
Switch(config-if)# spanning-tree [vlan “vlan-list”] port-priority “port-priority”
- You can modify the port priority for one or more VLANs by using the “vlan”
keyword.
- Otherwise, the port priority is set for the port as a whole (all active VLANs).
Note: - A lower port priority value indicates a more preferred path toward the root
bridge.
- For example, to modify the port priority of Switch-E interface Gigabit Ethernet 0/2 to
be 48 for only VLAN 100, use the following command:
Switch-E(config-if)# spanning-tree vlan 100 port-priority 48
- To confirm the modification, use the following command:
Switch-E# show spanning-tree interface gigabitethernet 0/2 Vlan Role Sts Cost Prio.Nbr Type
---------------- ---- ---- --------- ------------ --------------------------------
VLAN0001 Altn BLK 4 128.26 P2p
VLAN0100 Root FWD 2 48.26 P2p
Note: - The port priority value configured should be in increments of 16.
P a g e | 138
Tuning Spanning-Tree Convergence:
- STP uses three timers, a sequence of states that ports must move through, and specific
topology change conditions to prevent bridging loops from forming.
- Each of these parameters is based on certain default values for a typical network size
and function.
- In small networks, the default STP can cause network access to be delayed while
timers expire and while preventing loops on links where loops are not possible.
- In these small networks, waiting until the default timer values expire might not make
sense when they could be safely set to shorter values.
- In situations like this, you can safely make adjustments to the STP convergence
process for more efficiency.
- The three STP timers (Hello, Forward Delay, and Max Age timers) can be adjusted
using two methods:
Automatically configure the STP timers.
Manually configure the STP timers.
Note: - Remember that the timers need to be modified only on the root bridge
because the root bridge propagates all three timer values throughout the
network as fields in the configuration BPDU.
a) Automatically Configure the STP timers:
- STP timer values are basically dependent on the Hello timer and the switched
network’s diameter, in terms of switch hops (by default 7 hops).
- To change the STP timer values in a more controlled fashion, use the following
command:
Switch(config)# spanning-tree vlan “vlan-list” root {primary | secondary} [diameter “diameter” [hello-time “hello-time”]]
- Here, STP timers will be modified according to the formulas specified in the 802.1D
standard by configuring only the network’s diameter and an optional hello-time.
P a g e | 139
- Network diameter The maximum number of switches that traffic will traverse
across a Layer 2 network.
Note: - If you didn’t configure a “hello-time” value, the default value of 2 seconds is
assumed.
- This command can be used only on a per-VLAN basis to modify the timers
for a particular VLAN’s spanning-tree instance.
- The network “diameter” can be a value from 1 to 7 switch hops (default is 7).
- Because this command makes a switch become the root bridge, all the modified timer
values resulting from this command will be propagated to other switches through the
Configuration BPDU.
- As an example, suppose that a small network consisting of 3 switches connected in a
triangle fashion.
- The following command shows the current (default) STP timer values that are in use
for VLAN 100:
Switch-nonroot# show spanning-tree vlan 100
VLAN0100
Spanning tree enabled protocol ieee
Root ID Priority 100
Address 000D.BD2C.149B
Cost 19
Port 26 (FastEthernet 0/1)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 32868 (priority 32768 sys-id-ext 100)
Address 0007.EC8E.DCDD
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 20
!Lines are omitted for brevity
- The longest path that a packet can take through the sample network is 3 switches.
- This is considerably less than the default diameter of 7 that is used to calculate the
default timer values.
P a g e | 140
- Therefore, you can safely assume that this network diameter is 3, provided that no
additional switches will be added to lengthen the longest path.
- Suppose that a Hello of 1 second is also desired, to shorten the time needed to detect a
dead neighbor.
- The following command can be configured to make the local switch become the root
bridge and automatically adjusts the STP timers:
Switch-root(config)# spanning-tree vlan 100 root primary diameter 3 hello-time 1
- You can confirm the new timer values using the following command:
Switch-nonroot# show spanning-tree vlan 100
VLAN0100
Spanning tree enabled protocol ieee
Root ID Priority 100
Address 000D.BD2C.149B
Cost 19
Port 26 (FastEthernet 0/1)
Hello Time 1 sec Max Age 7 sec Forward Delay 5 sec
Bridge ID Priority 32868 (priority 32768 sys-id-ext 100)
Address 0007.EC8E.DCDD
Hello Time 1 sec Max Age 7 sec Forward Delay 5 sec
Aging Time 20
!Lines are omitted for brevity
a) Manually Configure the STP timers:
- Use one or more of the following global commands to modify the STP timers (this
method is not recommended):
Switch(config)# spanning-tree [vlan “vlan-list”] hello-time “seconds” Switch(config)# spanning-tree [vlan “vlan-list”] forward-time “seconds” Switch(config)# spanning-tree [vlan “vlan-list”] max-age “seconds”
Note: - If you omit the “vlan” keyword, the timer values are configured for “all”
instances (all active VLANs) of STP on the switch.
P a g e | 141
- The Hello timer can be configured to a value from 1 to 10 seconds.
- The Forward Delay timer can be configured to a value from 4 to 30 seconds.
- The Max Age timer can be configured to a value from 6 to 40 seconds.
Redundant Link Convergence:
- Some additional methods allows faster STP convergence if a link failure occurs:
PortFast Enables fast connectivity to be established on the access-layer switch
ports to hosts (PCs) that are booting.
UplinkFast Enables fast-uplink failover on an access-layer switch when dual
up-links are connected into the distribution-layer.
BackboneFast Enables fast convergence in the network backbone or core-layer
switches after a spanning-tree topology change occurs.
- Uplink Is the link that connects the access-layer switch to the distribution-layer
switch.
- These methods are Cisco-proprietary extensions and all work by controlling
convergence on specifically located ports within the network hierarchy.
Note: - The STP has been enhanced to allow instantaneous topology changes instead
of having to rely on these three Cisco-proprietary extensions.
- This enhancement is called “Rapid STP” or 802.1w and will be covered in
Chapter (9).
a) PortFast:
- An end-user host is usually connected to an access switch port in the access-layer.
- If the host is turned off and then turned on, the switch will sense that the port link
status has gone down and back up.
- The port will not be in a usable state until STP cycles the port from the Blocking state
to the Forwarding state.
P a g e | 142
- With the default STP timers, this transition takes at least 30 seconds (15 seconds for
Listening to learning and 15 seconds for Learning to Forwarding).
- Therefore, the hosts cannot transmit or receive any useful data until the Forwarding
state finally is reached on the port.
- An access switch ports that connect only to single hosts, bridging loops never should
be possible.
- Catalyst switches offer the PortFast feature, which shortens the Listening and Learning
states to a negligible amount of time.
- When a host comes up, the switch immediately moves the PortFast port into the
Forwarding state.
- One other benefit of PortFast is that Topology Change Notification (TCN) BPDUs are
not sent when a switch port in the PortFast mode goes up or down.
- This simplifies the TCN transmission on a large network when end-user hosts are
coming up or down.
- By default, PortFast is disabled on all switch ports.
- You can configure PortFast as a global default, enabling PortFast automatically on all
access switch ports with only one command.
- To enable PortFast as the default on all access switch ports:
Switch(config)# spanning-tree portfast default
- To enable or disable the PortFast feature on a specific access switch port:
Switch(config-if)# [no] spanning-tree portfast
- Obviously, on a trunk switch port that is connected to another switch, you shouldn’t
enable PortFast because bridging loops could form.
- You can also use a macro configuration command to force a switch port to support a
single host.
P a g e | 143
- The following command sets the port to access mode, enables STP PortFast, and
disables PAgP (to prevent the port from participating in an EtherChannel:
Switch(config-if)# switchport host
- You should assign the port to a VLAN as this command does not do that.
- To show the current PortFast status, use the following command:
Switch# show spanning-tree interface “type mod/num.” portfast
- For example, the following output shows that port Fast Ethernet 0/1 supports only
access VLAN 10 and has PortFast enabled:
Switch# show spanning-tree interface fastethernet 0/1 portfast VLAN0010 enabled
b) Uplink Fast:
- Consider the following access-layer Switch-A and Switch-B that have redundant
uplink connections to two distribution-layer switches as shown in the figure:
- Normally, one uplink would be in the Forwarding state and the other would be in the
Blocking state (if Switch-C is configured to be a Primary Root Bridge and Switch-D to
be a Secondary Root Bridge.
P a g e | 144
- If the primary uplink (in the Forwarding state) went down, up to 50 seconds could
elapse before the redundant uplink (in the Blocking state) could be used.
- The UplinkFast feature on Catalyst switches enables access-layer switches (switches at
the ends of the spanning-tree branches) to have a functioning root port while keeping
the other redundant port in the Blocking state.
- When the primary root port (primary uplink) fails, another root port (redundant uplink)
immediately can be brought up for use.
Note: - If more than one uplink used to the root bridge, UplinkFast keeps a record of
all parallel paths to the root bridge and only one uplink is kept in the
Forwarding state and all the other uplinks are kept in the Blocking state.
- If the primary uplink (root port) fails, the uplink with the next-lowest root
path cost is used immediately without delay.
- If two ports ties, the port ID is used as a tie-breaker.
- To enable the UplinkFast feature, use the following global configuration command (on
both Switch-A and Switch-B):
Switch(config)# spanning-tree uplinkfast [max-update-rate “pkts-per-second”]
- When UplinkFast is enabled, it is enabled for the entire switch an all VLANs.
Note: - UplinkFast works by keeping track of possible path to the root bridge, so this
command is not allowed on the root bridge.
- UplinkFast also make some modifications to the local switch to ensure that it doesn’t
become the root bridge and that the switch is not used as a transit switch to get to the
root bridge.
- In other words, the goal is to keep UplinkFast limited to the switches at the ends of the
spanning-tree branches that are farthest from the root bridge.
- First, the switch’s bridge priority is raised from the default (32,768) to (49,152),
making it unlikely that the switch will be elected to the root bridge status.
P a g e | 145
- When an uplink on a switch goes down, UplinkFast makes it easy for the local switch
to update its MAC address table to point to the new uplink.
- UplinkFast also provides a mechanism for the access switch to notify other upstream
switches that hosts within the access layer can be reached over the new uplink.
- The switch accomplishes this by sending dummy multicast frames to destination
(0100-0ccd-cdcd) on behalf of the hosts contained in its MAC address table.
- The MAC addresses are used as the source addresses in the dummy frames as if hosts
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.
- These multicast frames are sent out at a rate specified by the “max-update-rate”
parameter in packets per second.
- This limits the amount of bandwidth used for the dummy multicasts if the MAC
address table is quit large.
- The default is 150 packets per second, but the rate can range from 0 to 65,535 pkts/sec.
- To show the current status of STP UplinkFast, use the following command:
Switch-access# show spanning-tree uplinkfast UplinkFast is enabled Stations update rate set to 150 packets/sec. UplinkFast statistics Number of transitions via UplinkFast (all VLANs) :2 Number of proxy multicast addresses transmitted (all VLANs) :52 Name Interface List ----------------------------------- ----------------------------------- VLAN0001 Gi0/1 (fwd) VLAN0100 Gi0/1 (fwd)
c) BackboneFast:
- In the network core layer (backbone), a different method is used to shorten the STP
convergence.
- BackboneFast works by having a switch actively determines whether alternative paths
exist to the root bridge, in case of the switch detects an “indirect link failure”.
P a g e | 146
- Indirect link failure Occur when a link that is not directly connected to a switch
fails.
- 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. (Inferior BPDUs are sent
from a designated bridge that has lost its connection to the root bridge, making it
announce itself as the new root.)
- 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.
- Detecting alternative paths to the root bridge also involves an interactive process with
other bridges.
- 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.
P a g e | 147
- 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.
- Where PortFast and UplinkFast enable immediate transitions, BackboneFast can
reduce the maximum convergence delay only from 50 to 30 seconds.
- To configure BackboneFast, use the following global configuration command:
Switch(config)# spanning-tree backbonefast
Note: - 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.
- The RLQ protocol is actively only when the BackboneFast is enabled on a
switch.
- By default, BackboneFast is disabled.
- You can verify the current BackboneFast state using the following command:
Switch# show spanning-tree backbonefast BackboneFast is enabled
Monitoring STP:
- You can display information about many aspects of STP from the Catalyst switch.
- To show all possible STP parameters for all VLANs (port information is summarized):
Switch# show spanning-tree
P a g e | 148
- To show all possible STP parameters for all VLANs (port information is detailed):
Switch# show spanning-tree detail
- To show the total number of switch ports currently in each of the STP states:
Switch# show spanning-tree [vlan “vlan-id”] summary
- To find the root bridge ID, the root port, and the root path cost:
Switch# show spanning-tree [vlan “vlan-id”] root
- To show the bridge ID and STP timers for the local switch:
Switch# show spanning-tree [vlan “vlan-id”] bridge
- To show the STP activity on a specific interface:
Switch# show spanning-tree interface “type mod/num.”
P a g e | 149
Chapter 8 Protecting the STP Topology
Protecting Against Unexpected BPDUs:
- STP uses BPDUs to communicate between switches.
- After a root bridge has been elected, BPDUs are generated by the root bridge and are
relayed down through the spanning-tree topology.
- Eventually, all switches running STP receives the root’s BPDUs so that the network
converges and a stable loop-free topology forms.
- A foreign or rogue switch can be connected to the network, and that switch can be the
root bridge (if has the lowest bridge ID) and generate BPDUs.
- Cisco added 3 STP features that help prevent the unexpected BPDUs in the network.
- These three STP features are:
Root Guard.
BPDU Guard.
BPDU Filtering.
a) Root Guard:
- Suppose that a rogue switch is introduced into the network with a bridge ID lower than
the recent root bridge.
- The rogue switch then would become the root bridge and the STP topology might
converge to a new STP topology.
- Root Guard Is used to control where root bridges can never be expected to be found
on a network.
- Basically, a switch learns the current root bridge’s bridge ID.
- If a rogue switch advertises a “superior” BPDU on a port where Root Guard is
enabled, the local switch will not allow the rogue switch to become the root bridge.
P a g e | 150
- This local switch received the superior BPDUs on one of it ports where Root Guard is
enabled, will put that receiving port in a “root-inconsistent” STP state.
- As long as the superior BPDUs are still being received on that port, the port will be
kept in the “root-inconsistent” STP state.
- Once the superior BPDUs are no longer received on that port, the “root-inconsistent”
state will be removed and the port is cycled through the normal STP states to return to
normal use.
Note: - When the rogue switch stops sending superior BPDUs, it will be considered
as a normal switch on the network, so another protection feature should be
applied as will be explained later in this chapter.
- Root Guard enabled on a switch port designates that the port can forward or relay
BPDUs, but cannot be used to receive BPDUs.
- Root Guard can enabled only on a per-port basis.
- By default, Root Guard is disabled on all switch ports.
- To enable Root Guard on a switch port, use the following interface configuration
command:
Switch(config-if)# spanning-tree guard root
- Use Root Guard on switch ports where you never expect to find the root bridge for all
VLANs.
- When a superior BPDU is received on the port where Root Guard is enabled, that port
in effect become on the STP Listening (LSN) state.
- To show the switch ports that Root Guard has put into the “root-inconsistent” state,
use the following command:
Switch# show spanning-tree inconsistentports
P a g e | 151
Example: - Consider the following network:
- Switch-A non-connected ports are all configured to enable Root Guard and not
expecting a superior BPDUs to be received from a candidate root bridge to be elected
as the root bridge instead of Switch-C.
- Now, consider a rogue switch with the lowest “priority-multiplier” is connected to
Switch-A port Fast Ethernet 0/10 where Root Guard is enabled.
Switch(config)# interface FastEthernet 0/10 Switch(config-if)# spanning-tree guard root
- Switch-A will report the following message when the rogue switch is connected:
%SPANTREE-2-ROOTGUARDBLOCK: Port 0/10 tried to become non-designated in VLAN-1. Moved to root-inconsistent state
P a g e | 152
- To show the switch ports that Root Guard has put into the root-inconsistent state:
Switch-A# show spanning-tree inconsistentports Name Interface Inconsistency -------------------- ------------------------- ------------------ VLAN0001 FastEthernet0/10 Root Inconsistent Number of inconsistent ports (segments) in the system : 1
b) BPDU Guard:
- The BPDU Guard feature was developed to further protect the integrity of switch
ports.
- If any BPDU (whether a superior or not) is received on a switch port where BPDU
Guard is enabled, that port immediately is put into the “errdisable” state.
- The port is shutdown in an error condition and must be either manually re-enabled or
automatically recovered through the errdisable timeout function.
- By default, BPDU Guard is disabled on all switch ports.
- To configure BPDU Guard as a global default, affecting all switch ports, use the
following command:
Switch(config)# spanning-tree portfast bpduguard default
Note: - The “default” keyword indicates that BPDU Guard will be enabled
automatically on all ports that have PortFast enabled.
- If PortFast is disabled on a port, then BPDU Guard will not be enabled there.
- To enable or disable BPDU Guard on a per-port basis, use the following command:
Switch(config-if)# spanning-tree bpduguard {enable | disable}
Note: - When the BPDUs are no longer received, the port remains in the errdisable
state.
P a g e | 153
- To recover from the errdisable state use the “shutdown” and “no shutdown” interface
configuration commands after disabling BPDU Guard.
- To recover from the errdisable state after automatically after 10 minutes, use the
following commands:
Switch(config)# errdisable detect cause bpduguard Switch(config)# errdisable recovery cause bpduguard Switch(config)# errdisable recovery interval 600
- Using BPDU Guard on a switch port, prevents any possibility that a switch will be
added to the port, either intentionally or by mistake.
Note: - An obvious application for BPDU Guard is on access switch ports where
BPDUs wouldn’t be expected there and would be detected if a switch is
connected.
- You never should enable BPDU Guard on any switch uplink where the root
bridge is located.
- If BPDU Guard is enabled on an uplink port, BPDUs will be detected and
the uplink will be put into the errdisable state, this will preclude that uplink
port from being used as an uplink into the network.
c) BPDU Filtering:
- In some cases, you will need to disable STP on a port by preventing BPDUs from
being sent or received, at the same time allowing data to be transferred normally
without shutdown the port.
- You can use the BPDU Filtering feature to effectively disable STP on the port.
- By default, BPDU Filtering is disabled on all switch ports.
- To configure BPDU Filtering as a global default, affecting all switch ports, use the
following command:
Switch(config)# spanning-tree portfast bpdufilter default
Note: - The “default” keyword indicates that BPDU Filtering will be enabled
automatically on all ports that have PortFast enabled.
- If PortFast is disabled on a port, then BPDU Filtering will not be enabled
there.
P a g e | 154
- To enable or disable BPDU Filtering on specific switch ports, use the following
interface configuration command:
Switch(config-if)# spanning-tree bpdufilter {enable | disable}
Protecting Against Unexpected BPDUs:
- STP BPDUs must be sent by the root bridge and must be relayed by every other switch
in the network.
- If a switch doesn’t receives BPDUs, means that a switch or a link is dead, and the
topology must have changed, so some ports in the Blocking state can move to the
Forwarding state.
- If the absence of BPDUs is actually a mistake, and BPDUs are not received even
though there is no topology change, then bridging loops can form.
- Cisco has added two STP features that help detect or prevent the unexpected loss of
BPDUs:
Unidirectional Link Detection (UDLD).
Loop Guard.
a) Unidirectional Link Detection (UDLD):
- In a campus network, switches are connected by bidirectional links, where traffic can
flow in two directions.
- Clearly, if a link has a physical layer problem, the two switches it connects detect a
problem, and the link is shown as not connected.
- For example, when using fiber-optic cables, one strand is used for transmit and the
other strand for receive.
- When one strand fails, the two switches still might see a functional bidirectional link,
although traffic would be delivered in only one direction, this is known as a
“unidirectional link”.
P a g e | 155
Note: - Twisted-pair media does not suffer from the unidirectional link to form.
- When a unidirectional link is present in a network, BPDUs will not be received on one
end of the link.
- If that end of the link normally is in the Blocking state (Alternative role), it will not be
that way for long.
- A switch interprets the absence of BPDU to mean that the port can be moved safely
through the STP states so that traffic can be forwarded.
- If this is done on a unidirectional link, a bridging loop forms and the switch never
realizes the mistake.
- UDLD STP feature (is a Cisco Proprietary) can be used to prevent this situation.
- When UDLD is enabled, it interactively monitors a port to see whether the link is truly
bidirectional.
- A switch sends special Layer 2 UDLD frames identifying its switch port at regular
intervals.
- UDLD expects the far-end switch to echo those frames back across the same link, with
the far-end switch port’s identification added.
- If a UDLD frame is received in return and both neighboring ports are identified in the
frame, the link must be bidirectional.
- If the echoed frames are not seen, the link must be unidirectional.
Note: - An echo process requires “both ends” of the link to be configured for UDLD.
- Otherwise, one end of the link will not echo the frames back to the
originator.
- UDLD messages are sent at regular intervals (15 seconds by default), as long as the
link is active.
- 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 Forwarding Delay timer (20+15+15 = 50 seconds).
Note: - UDLD can detect a unidirectional link after about three times the UDLD
message interval (total 45 seconds, using the default 15 seconds).
P a g e | 156
- UDLD has two modes of operation:
Normal mode - When a unidirectional link condition is detected, the port is
allowed to continue its operation.
- UDLD marks the port as having an undetermined state and
generates a syslog message.
Aggressive mode - When a unidirectional link condition is detected, the switch
takes action to reestablish the link.
- UDLD messages are sent out once a second for 8 seconds.
- If none of those messages is echoed back, the port is placed
in the errdisable state so that it cannot be used.
- UDLD can be configured on a per-port basis or you can enable it globally for all fiber
optic switch ports.
- By default, UDLD is disabled on all switch ports.
- To enable UDLD globally, affecting all switch ports, use the following command:
Switch(config)# udld {enable | aggressive} [message-time “seconds”]
- “enable” For normal mode.
- “aggressive” For aggressive mode.
- “message-time” To set the UDLD message interval (a value from 7 to 90 seconds,
the default value is 15 seconds for Catalyst 4500 and 6500, and the
default value is 7 seconds for Catalyst 3550).
- To enable or disable UDLD on individual switch ports, use the following command:
Switch(config-if)# udld {enable | aggressive | disable} [message-time “seconds”]
- “disable” For disabling UDLD on an interface.
- To re-enable ports that UDLD aggressive mode has errdisabled:
Switch# udld reset
P a g e | 157
Note: - If two neighbors have a mismatched UDLD message time values, UDLD
still works correctly.
- This is because each of the two neighbors simply echoes UDLD messages
back as they are received, without knowledge of their neighbor’s own time
interval.
- The time interval is used only to decide when to send UDLD messages and
as a basis for detecting a unidirectional link from the absence of echoed
messages.
- If you decided to change the default message-time value, make sure that
UDLD still can detect a fault “before” STP decides to move a link to the
Forwarding state.
- You safely can enable UDLD on all switch ports, and the switch will globally enables
UDLD only on ports that uses fiber-optic cables.
- When configuring UDLD for first time, it will not disable the working link before you
can get the far-end configured, the reason because when UDLD is enabled on a link
for the first time, it makes some intelligent assumptions.
- It starts sending out messages, hoping that a neighboring switch will hear them and
echo them back.
- Obviously, the device at the far-end also must support UDLD so that the messages will
be echoed back.
- If the neighboring switch does not yet have UDLD enabled, no messages will be
echoed.
- UDLD will keep trying “indefinitely” to detect a neighbor and will not disable the
link.
- After that neighbor has UDLD configured also, both switches become aware of each
other and the bidirectional state of the link through their UDLD message exchanges.
- From then on, if messages are not echoed, the link can accurately be labeled as
unidirectional.
- Finally, in an EtherChannel bundle, if one link within the channel becomes
unidirectional, UDLD flags or disables only the offending link in the bundle, not the
entire EtherChannel.
- UDLD sends and echoes its messages on each link within an EtherChannel bundle
independently.
P a g e | 158
b) Loop Guard:
- Suppose that a switch port is receiving BPDUs and the switch port is in the Blocking
state (Alternative role).
- The Alternative port makes up a redundant path (it is blocking because it is neither a
root port nor a designated port, and it will remain in the Blocking state as long as a
steady flow of BPDUs is received).
- If BPDUs are being sent over a link but the flow of BPDUs stops for some reason, the
last known BPDU is kept until the Max Age timer expires, then that BPDU is flushed,
and the switch thinks there is no longer a need to block the port.
- After all, if no BPDUs are received, there must not be another switch connected there.
- The switch then moves the port through the STP states until it begins to forward traffic
and a bridging loop will be formed.
- finally, the port will become a designated port where it begins to relay or send BPDUs,
when it actually should be receiving BPDUs.
- Loop Guard is used to prevent this situation.
- When loop Guard is enabled, Loop Guard moves the port into the “loop-inconsistent”
state if no BPDUs are received and the Max Age timer expired.
- The port is effectively in the Blocking state at this point to prevent a loop from
forming .
- When BPDUs are received on the port again, Loop Guard allows the port to move
through the normal STP states and become an “alternative” port again.
- In this way, Loop Guard automatically governs port without the need for manual
intervention.
- By default, Loop Guard is disabled on all switch ports.
- To enable Loop Guard as a global default, affecting all switch ports in the STP
Blocking state (alternative role), use the following command:
Switch(config)# spanning-tree loopguard default
P a g e | 159
- To enable or disable Loop Guard on a specific switch port, use the following interface
configuration command:
Switch(config-if)# [no] spanning-tree guard loop
- Although Loop Guard can be configured on a switch port, its corrective blocking
action is taken on a per-VLAN basis.
- In other words, Loop Guard does not block the entire port, only the offending VLANs
are blocked.
Note: - You can enable Loop Guard on all switch ports, regardless of their functions.
- The switch figure out which ports are in the “alternative” role and monitors
the BPDU activity to keep them in the Blocking state.
Troubleshooting STP Protection:
- To list the ports that have been labeled in an inconsistent state:
Switch# show spanning-tree inconsistentports
- To show detailed reasons for inconsistencies:
Switch# show spanning-tree interface “type mod/num.” [detail]
- To show the global BPDU Guard, BPDU Filter, and Loops Guard states:
Switch# show spanning-tree summary
- To show the UDLD status on one or all ports:
Switch# show udld “type mod/num.”
- To re-enable ports that UDLD aggressive mode has errdisabled:
Switch# udld reset
P a g e | 160
- The following figure shows where the STP protection features can be configured on a
campus network:
Guidelines for Applying STP Protection Features in a Network
- All switch-to-switch links are fiber-based Gigabit Ethernet.
- Switch-C is a primary Root Bridge and Switch-D is a secondary Root Bridge for
VLAN 1.
- UDLD must be enabled on both ends of a link (all links in blue color).
P a g e | 161
Chapter 9 Advanced Spanning Tree Protocol
Rapid Spanning-Tree Protocol (RSTP) (IEEE 802.1w):
- The traditional STP (IEEE 802.1D) was designed to keep a switched network loop
free, with adjustments made to the network topology dynamically.
- A topology change typically takes 30 seconds, with a port moving from the Blocking
state to the Forwarding state after two intervals of the Forward Delay timer.
- As technology has improved, 30 seconds has become an unbearable length of time to
wait for a production network to failover or heal itself during a problem.
- The Rapid STP (RSTP) (IEEE 802.1w) standard was developed to use 802.1D’s
principal concepts and make the resulting convergence much faster.
- RSTP Is defined in the IEEE 802.1w standard and it defines how switches interact
with each others to keep the network topology loop free in a very efficient
manner.
- As with the traditional STP (802.1D), RSTP’s basic functionality can be applied as a
single instance (RSTP) or multiple instances (RPVST+).
- This can be done by using RSTP as the underlying mechanism for the Cisco-
proprietary PVST+.
- The resulting combination is called Rapid PVST+ (RPVST+).
Switch Ports in RSTP:
- Recall that in 802.1D, each port is assigned a “role” and a “state” at any given time.
- The switch port in STP can take one of the following roles:
Root Port.
Designated Port.
Alternate Port.
P a g e | 162
- The switch port in STP is assigned one of the following states:
Blocking.
Listening.
Learning.
Forwarding.
Note: - The “Disable” state when the switch port is “Shutdown” administratively or
physically cannot be considered one of the STP states.
- RSTP achieves its rapid nature by letting each switch interact with its neighbor
switches through each port.
- The interaction is performed based on a port’s role, not strictly on the BPDUs that are
relayed from the root bridge.
- After the role is determined, each port can be given a state that determines what it does
with the incoming data frames (Only the Forwarding state allows data frames to be
sent and received).
- The root bridge in a network using RSTP is elected just as with 802.1D (by the lowest
bridge ID)
- After all switches elect the root bridge, the following port roles are determined
(identical to 802.1D):
Root Port.
Designated Port.
Alternate Port.
- RSTP defines port states only according to what the port does with incoming frames.
- The switch port in RSTP can be assigned one of the following port states:
Blocking (Discarding) - Incoming frames simply are dropped and no MAC
addresses are learned to be added to the MAC address
table.
P a g e | 163
- This state combines the 802.1D Blocking and Listening
states because both do not effectively forward
anything.
Note: - In RSTP, the Listening state is not needed because RSTP quickly can
negotiate a state change without listening for BPDUs first.
Learning Incoming frames are dropped, but MAC addresses are learned.
Forwarding Incoming frames are forwarded according to MAC addresses that
have been (and are being) learned.
BPDUs in RSTP:
- In 802.1D STP, BPDUs basically originate from the root bridge and are relayed by all
switches down through the tree.
- Because of this propagation of BPDUs, 802.1D convergence must wait for a steady-
state conditions before proceeding.
- RSTP uses the same BPDU format for backward compatibility.
- However, some previously unused bits in the Message Type field are used.
- The sending switch port identifies itself by its RSTP role and state.
- The BPDU version also is set to a value to distinguish between RSTP BPDUs (version
2) and the traditional STP BPDUs (version 0).
- In addition, RSTP uses an interactive process so that two neighboring switches can
negotiate state changes.
- Some BPDU bits are used to flag messages during this negotiation.
- BPDUs are sent out every switch port at Hello Time intervals, regardless of whether
BPDUs are received from the root bridge.
- In this way, any switch anywhere in the network can play an active role in maintaining
topology.
- Switches also can expect to receive regular BPDUs from their neighbors.
- When three BPDUs are missed in a row, that neighbor is presumed to be down, and all
information related to the port leading to the neighbor immediately is aged out.
P a g e | 164
- This means that a switch can detect a neighbor failure in three Hello Time intervals
(default 2*3 = 6 seconds), versus the Max Age timer interval for 802.1D (default 20
seconds).
- Because RSTP distinguishes its BPDUs from 802.1D BPDUs, it can coexist with
switches still using 802.1D.
- Each port attempts to operate according to the version that is received in the BPDU.
- For example, when an 802.1D BPDU (version 0) is received on a port, that port begins
to operate according to the 802.1D rules.
- However, each port has a measure that locks the protocol in use, in case BPDUs from
both 802.1D and RSTP are received within a short time frame.
- This can occur if the switches in a network are being migrated from one STP type to
another.
- Instead of flapping or toggling the STP type during a migration, the switch holds the
protocol type for the duration of a migration delay timer.
- After this timer expires, the port is free to change protocols if needed.
RSTP Convergence:
- The convergence of STP in a network is the process that takes all switches from a state
of independence (each think it must be the STP root) to one of uniformity.
- Convergence can be thought as a two stage process:
One root bridge must be “elected”, and all other switches must know about it.
The state of every switch port in the network must be brought from a Blocking
state to the appropriate state to prevent loops.
- RSTP takes a different approach than the traditional STP (802.1D) when a switch
needs to decide how to participate in the tree topology.
- When a switch first joins the topology or has detected a failure in the existing
topology, RSTP requires it to base its forwarding decisions on the type of port.
P a g e | 165
RSTP Port Types:
- Every switch port can be considered one of the following types:
Point-to-point (P2p) - Any port that connects to another switch.
- A quick handshake with neighboring switch rather than a
timer expiration, decides the port state.
- BPDUs are exchanged back and forth in the form of a
“proposal” and an “agreement”.
- One switch proposes that its port become a designated
port, if the other switch agrees, it replies with an
agreement message.
Shared (Shr) - Any port that connects to multiple neighboring switches.
- Point-to-point (P2p) and shared (Shr) ports automatically are determined by the duplex
mode in use.
- Full-duplex ports are considered point-to-point because only two switches can be
present on the link.
- STP convergence can occur quickly over a point-to-point link through the RSTP
handshake messages.
- Half-duplex ports are considered shared-medium ports with possibly more than two
switches present.
- STP convergence on a half-duplex port must occur between several directly connected
switches (for example, through a hub).
- Therefore, the traditional 802.1D style convergence must be used.
- This results in a slower response because the shared-medium ports must go through
the fixed Listening and Learning state time periods.
- RSTP handles the complete STP convergence of the network as a propagation of
handshakes over point-to-point links.
P a g e | 166
- When a switch needs to make an STP decision, a handshake is made with the nearest
neighbor switch.
- When that handshake is successful, the handshake sequence is moved to the next
switch and then the next switch, as an ever-expanding wave moving toward the
network’s edges.
- During each handshake sequence, a switch must take measures to completely ensure
that it will not introduce a bridging loop before moving the handshake outward.
- This is done through a synchronization process.
RSTP Synchronization Process:
- To participate in RSTP convergence, a switch must decide the state of each of its
ports.
- All ports begin in the Blocking (Discarding) state (except those configured with
PortFast, also sometimes called Edge ports).
- After BPDUs are exchanged between the switch and its neighbors, the root bridge can
be elected.
- If a port receives a superior BPDU from a neighbor, that port becomes the root port.
- For each port (except those configured with PortFast), the switch exchanges a
proposal-agreement handshake to decide the state of each end of the link.
- Each switch assumes that its port should become the designated port for the link, and a
proposal message (a Configuration BPDU) is sent to the neighbor suggesting this.
- When a switch receives a proposal message on a port, the following sequence of
events occurs:
P a g e | 167
1) (Switch-A) sends a proposal message to (Switch-B), if the proposal’s sender (Switch-
A) has a superior BPDU, Switch-B realizes that Switch-A should be the root bridge
(having the designated port) and that its own port must become the new root port.
2) Before Switch-B agrees to anything, it must synchronize itself with the topology.
3) All Switch-B ports immediately are moved into the Blocking (Discarding) state so
that no bridging loops can form.
4) An agreement message (a Configuration BPDU) is sent back to Switch-A, indicating
that the switch agreed to have its port as the root port and Switch-A port as the
designated port. This also tells Switch-A that Switch-B is in the process of
synchronizing itself.
5) Switch-B root port immediately is moved to the Forwarding state and Switch-A
designated port also immediately is moved to the Forwarding state.
6) At Switch-B, for each port is currently in the Blocking state, a proposal message is
sent to the respective neighbor (Switch-C).
7) An agreement message is expected and received from the neighbor (Switch-C).
8) The result of the agreement is that Switch-C port is a designated port and be in the
Forwarding state, and Switch-B port will be in the Blocking (Discarding) state.
- Notice that the RSTP convergence begins with a switch sending a proposal message.
- The recipient switch of the proposal message must synchronize itself by effectively
isolating itself from the rest of the topology.
- All other ports (except those with PortFast enabled) are blocked until a proposal
message can be sent, causing the nearest neighbors to synchronize themselves.
- This creates a moving “wave” of synchronizing switches, which quickly can decide to
start forwarding on their links only if their neighbor agree (choosing a designated port
on a link between two switches).
- Isolating the switches along the traveling wave inherently prevents bridging loops.
- The entire convergence process happens quickly, at the speed of a BPDU transmission,
without the use of any timers.
- However, the port that sends a proposal message, might not receive any agreement
message reply.
- Suppose that the neighboring switch does not understand RSTP or has a problem
replying.
P a g e | 168
- The sending switch then must become overly cautious and must begin playing the
802.1D rules.
- The port must be moved through the legacy Listening and Learning states (using the
Forward Delay timer) before moving to the Forwarding state.
Topology Changes and RSTP:
- Recall that when an 802.1D switch detects a port state change (either up or down), it
sends a TCN BPDUs to the root bridge.
- The root bridge, in turn, must signal the topology change by sending out a
Configuration BPDU with the TCN bit is set and is relayed to all switches in the
network.
- When a topology change is detected, a switch must propagate news of the change to
other switches in the network so that they can correct their MAC address tables too.
- This news of change are Configuration BPDUs with TC flag bit is set and sent out all
ports (except with PortFast enabled).
- This is done until the TC timer expires, after two intervals of the Hello time.
- This notifies neighboring switches of the topology change.
- All MAC addresses associated with the ports (except those with PortFast enabled) are
flushed from the MAC address table.
- This forces the addresses to be re-learned after the change, in case host now appear on
a different link.
- All neighboring switches that receive the TC messages also must flush the MAC
addresses learned on all ports except the one that received the TC message.
- Those switches then must send TC messages out their ports (except those with
PortFast enabled), and so on.
RSTP Configuration:
- By default, a switch operates in PVST+ mode using the traditional 802.1D STP.
- RSTP cannot be used until a different spanning-tree mode (example, RSTP) is
enabled.
P a g e | 169
- Remember that RSTP is just the underlying mechanism that a spanning-tree mode can
use to detect topology changes and converge a network into a loop-free topology.
- To improve the efficiency of each STP instance, you can configure a switch to begin
using RSTP instead.
- This means that each VLAN will have its own independent instance of RSTP running
on the switch.
- This mode is knows as Rapid PVST+ (RPVST+).
- There is one configuration step to change the spanning-tree mode and begin using
RPVST+.
- To enable RPVST+ spanning-tree mode, use the following command:
Switch(config)# spanning-tree mode rapid-pvst
Note: - Be careful when you use this command on a production network because any
spanning-tree process that is currently running must be restarted.
- To revert back to the default PVST+ mode and use the traditional 802.1D STP, use the
following command:
Switch(config)# spanning-tree mode pvst
Note: - After you enable the PVST+ mode, the switch must begin supporting both
RSTP and 802.1D neighbors.
- The switch can detect the neighbor’s STP type by the BPDU version that is
received.
- The only configuration changes related to RSTP affect the link type.
- The link type is used to determine how a switch negotiates topology information with
its neighbors.
- By default, RSTP automatically decides that a port is a point-to-point (P2p) link type if
it is operating in full-duplex mode.
- Ports connecting to other switches are usually full-duplex because there are only two
switches on the link.
P a g e | 170
- If the switch port is connecting to multiple switches through a hub, RSTP
automatically decides that a port is a shared (Shr) link type if it is operating in half
duplex mode.
- To force the port to act as a point-to-point or shared link “type”, use the following
command:
Switch(config-if)# spanning-tree link-type {point-to-point | shared}
- To show the neighbor type, use the following command:
Switch# show spanning-tree vlan “vlan-id”
- If you see “P2p Peer” (STP), the port is a point-to-point type but the neighboring
device is running the traditional 802.1D STP.
- If you see “Shr”, the port is a shared type and the neighboring device can be a hub
connecting to multiple number of switches.
P a g e | 171
Chapter 10 Multilayer Switching
(A) InterVLAN Routing:
- VLANs essentially are separate broadcast domains and they are isolated from each
other so that frames in one VLAN cannot cross into another VLAN.
- To allow communication (transport frames) between VLANs, you must use a Layer 3
device (router or a multilayer switch).
- InterVLAN Routing Is to allow communication (forward frames) between VLANs.
- InterVLAN Routing can be performed by using on of the following three methods:
a) Using an external router that connects to each of the VLANs on a switch:
- A separate physical connection (access link) is used for each VLAN between the Layer
2 switch and the router.
- To configure Switch-A, use the following commands:
Switch-A(config)# vlan 10 Switch-A(config-vlan)# name VLAN-10 Switch-A(config)# vlan 20 Switch-A(config-vlan)# name VLAN-20 Switch-A(config)# interface range fastEthernet 0/1 , fastEthernet 0/10
P a g e | 172
Switch-A(config-if-range)# switchport mode access Switch-A(config-if-range)# switchport access vlan 10 Switch-A(config)# interface range fastEthernet 0/2 , fastEthernet 0/20 Switch-A(config-if-range)# switchport mode access Switch-A(config-if-range)# switchport access vlan 20
- To configure Router-A, use the following commands:
Router-A(config)# interface fastEthernet 0/0 Router-A(config-if)# ip address 192.168.1.1 255.255.255.0 Router-A(config-if)# no shutdown Router-A(config)# interface fastEthernet 0/1 Router-A(config-if)# ip address 172.16.1.1 255.255.0.0 Router-A(config-if)# no shutdown
b) Using Router on a Stick (One-armed Router):
- External router that connects to the switch through a single trunk link, allowing all the
necessary VLANs.
Router on a Stick
- To configure Switch-A, use the following commands:
Switch-A(config)# vlan 10 Switch-A(config-vlan)# name VLAN-10 Switch-A(config)# vlan 20 Switch-A(config-vlan)# name VLAN-20 Switch-A(config)# interface fastEthernet 0/10 Switch-A(config-if)# switchport mode access Switch-A(config-if)# switchport access vlan 10 Switch-A(config)# interface fastEthernet 0/20
P a g e | 173
Switch-A(config-if)# switchport mode access Switch-A(config-if)# switchport access vlan 20 Switch-A(config)# interface fastEthernet 0/1 Switch-A(config-if)# switchport mode trunk
- To configure Router-A, use the following commands:
Router-A(config)# interface fastEthernet 0/1 Router-A(config-if)# no ip address Router-A(config-if)# no shutdown Router-A(config)# interface fastEthernet 0/1.10 Router-A(config-subif)# encapsulation dot1q 10 Router-A(config-subif)# ip address 192.168.1.1 255.255.255.0 Router-A(config)# interface fastEthernet 0/1.20 Router-A(config-subif)# encapsulation dot1q 20 Router-A(config-subif)# ip address 172.16.1.1 255.255.0.0
c) Using a Multilayer Switch:
- The routing and switching function is combined into one device.
Multilayer Switch
- To configure Multilayer-Switch-A, use the following commands:
Multilayer-Switch-A(config)# ip routing Multilayer-Switch-A(config)# vlan 10 Multilayer-Switch-A(config-vlan)# name VLAN-10 Multilayer-Switch-A(config)# vlan 20 Multilayer-Switch-A(config-vlan)# name VLAN-20 Multilayer-Switch-A(config)# interface fastEthernet 0/10 Multilayer-Switch-A(config-if)# switchport mode access
P a g e | 174
Multilayer-Switch-A(config-if)# switchport access vlan 10 Multilayer-Switch-A(config)# interface fastEthernet 0/20 Multilayer-Switch-A(config-if)# switchport mode access Multilayer-Switch-A(config-if)# switchport access vlan 20 Multilayer-Switch-A(config)# interface vlan 10 Multilayer-Switch-A(config-if)# ip address 192.168.1.1 255.255.255.0 Multilayer-Switch-A(config)# interface vlan 20 Multilayer-Switch-A(config-if)# ip address 172.16.1.1 255.255.0.0
Note: - Both Multilayer Switches and Routers can perform the routing function.
- The difference between them is that Routers have physical WAN interfaces
but Multilayer Switches have not.
- The “ip routing” command is used to enable the Layer 3 routing function on
the multilayer switch.
Multilayer Switch Interfaces:
- The Multilayer Switch interfaces can be one of the following:
Physical Layer 2 Interface.
Physical Layer 3 Interface.
Switch Virtual Interface (SVI) Layer 3 Interface.
- Switch Virtual Interface (SVI) Is the virtual (logical) interface inside the multilayer
switch that can be assigned a Layer 3 address (IP
address) to represent an entire VLAN.
- Multilayer Switches can perform both Layer 2 switching and Layer 3 routing.
- Layer 2 switching occurs between interfaces that are assigned to Layer 2 access
VLANs or Layer 2 trunks (access and trunk ports).
- Layer 3 routing occurs between interfaces that are assigned to Layer 3 routing and
have Layer 3 address (IP address) assigned to each of the Layer 3 interfaces (physical
interface or SVI).
- As with a router, a multilayer switch can assign a Layer 3 address (IP address) to a
physical interface.
- Also, a multilayer switch can assign a Layer 3 address (IP address) to a SVI that
represents and entire VLAN.
P a g e | 175
- Keep in mind that the Layer 3 address you configure becomes the default gateway for
any host that is connected to an interface and assigned to a VLAN.
- The hosts will use the Layer 3 address as their default gateway to communicate outside
of their local VLAN.
Configuring Multilayer Switch Interfaces:
- First, InterVLAN routing requires that Layer 3 routing function be enabled on the
multilayer switch (by default, the Layer 3 routing is disabled).
- To enable Layer 3 routing on a multilayer switch, use the following command:
Multilayer-Switch(config)# ip routing
Note: - The Layer 3 Routing function can be performed by the multilayer switch for
both IPv4 and IPv6 Layer 3 addresses, these topics are covered fully in The
Road (Route) book.
- “ip” is used for Layer 3 IPv4 routing.
- “ipv6” is used for Layer 3 IPv6 routing.
- By default, every multilayer switch port on most Catalyst switch platforms is in Layer
2 mode.
Note: - Some multilayer switches (such as Catalyst 6500) has its ports by default in
Layer 3 mode.
- If an interface needs to operate in a different layer mode, you must configure it.
- A multilayer switch interface is either in Layer 2 mode or Layer 3 mode, but not both.
a) Physical Layer 2 Interface Configuration:
- If a multilayer switch physical interface is in Layer 3 mode and you need to configure
it for Layer 2 mode instead, use the following command.
Multilayer-Switch(config)# interface “type mod/num.” Multilayer-Switch(config-if)# switchport
P a g e | 176
- The “switchport” command puts the port in Layer 2 mode.
- Then you can use other “switchport” command keywords to configure trunking or
access VLANs.
b) Physical Layer 3 Interface Configuration:
- If a multilayer switch physical interface is in Layer 2 mode and you need to configure
it for Layer 3 mode instead, use the following command:
Multilayer-Switch(config)# interface “type mod/num.” Multilayer-Switch(config-if)# no switchport Multilayer-Switch(config-if)# ip address “ip-address” “subnet-mask”
- The “no switchport” command puts the port in Layer 3 mode.
- The you can assign a Layer 3 address (IP address) to the port, as you would do the a
router interface.
Note: - If several interfaces are bundled as an EtherChannel, the EtherChannel can
also become a Layer 3 interface.
- In that case, the IP address is assigned to the Port Channel interface, not to
the individual physical links within the channel.
c) Switch Virtual Interface (SVI) Layer 3 Configuration:
- On a multilayer switch, you can enable the Layer 3 functionality for the entire VLAN.
- This allows an IP address to be assigned to a virtual interface that of the VLAN itself.
- This is useful when the switch has many physical ports assigned to different VLANs
and communication is needed between these different VLANs.
Note: - The SVI itself has no physical connection to the outside world.
- The virtual (logical) Layer 3 interface is known as the SVI.
- When SVI is configured, it uses the interface name (vlan “vlan-id”), as if the VLAN
itself is a physical interface.
P a g e | 177
- To configure a SVI, use the following command:
Multilayer-Switch(config)# interface vlan “vlan-id” Multilayer-Switch(config-if)# ip address “ip-address” “subnet-mask”
Note: - The VLAN must be defined first and be active on the multilayer switch
before the SVI can be used.
- Make sure that the new VLAN interface is enabled on the multilayer switch
by using the “no shutdown” interface configuration command.
Verifying InterVLAN Routing:
- To verify a multilayer switch port’s mode, use the following command:
Multilayer-Switch# show interface “type mod/num.” switchport
- If the “switchport” line output shown as “Enabled”, the port is in Layer 2 mode.
- If the “switchport” line output shown as “Disabled”, the port is in Layer 3 mode.
- For example, to verify the Layer 2 mode of interface fastEthernet 0/10:
Multilayer-Switch-A# show interface fastEthernet 0/10 switchport
Name: Fa0/10
Switchport: Enabled
!Lines are omitted for brevity
- To verify the configuration of a SVI, use the following command:
Multilayer-Switch# show interface vlan “vlan-id”
- For example, to verify the configuration of the SVIs on a multilayer switch:
Multilayer-Switch-A# show interface vlan 10
Vlan10 is up, line protocol is up
Hardware is CPU Interface, address is 0060.47cc.921e (bia 0060.47cc.921e)
Internet address is 192.168.1.1/24
!Lines are omitted for brevity
P a g e | 178
- The VLAN interface should be up, with the line protocol also up.
- To show a list of the configured VLANs, use the following command:
Multilayer-Switch# show vlan
- For example, to show the list of configured VLANS on a multilayer switch:
Multilayer-Switch-A# show vlan
VLAN Name Status Ports
-------- -------------------------------- --------- -------------------------------
1 default active Fa0/1, Fa0/2, Fa0/3, Fa0/4
Fa0/5, Fa0/6, Fa0/7, Fa0/8
Fa0/9, Fa0/11, Fa0/12, Fa0/13
Fa0/14, Fa0/15, Fa0/16, Fa0/17
Fa0/18, Fa0/19, Fa0/21, Fa0/22
Fa0/23, Fa0/24, Gig0/1, Gig0/2
2 VLAN-10 active Fa0/10
3 VLAN-20 active Fa0/20
!Lines are omitted for brevity
- To show a summary listing of IP addresses associated with Layer 3 interfaces:
Multilayer-Switch# show ip interface brief
- For example, to show the summary listing of IP addresses associated with Layer 3
interfaces on a multilayer switch:
Multilayer-Switch-A# show ip interface brief
Interface IP-Address OK? Method Status Protocol
!Lines are omitted for brevity
FastEthernet0/10 unassigned YES unset up up
FastEthernet0/20 unassigned YES unset up up
!Lines are omitted for brevity
Vlan10 192.168.1.1 YES manual up up
Vlan20 172.16.1.1 YES manual up up
P a g e | 179
(B) Multilayer Switching with CEF:
- Catalyst Multilayer Switches can use several methods to forward packets based on
Layer 3 information.
- Catalyst Multilayer Switches uses the efficient Cisco Express Forwarding (CEF)
method.
- Although CEF is easy to be configured and used, the underlying switching
mechanisms are more involved and should be understood.
Traditional Multilayer Switching Overview:
- Multilayer Switching (MLS) began as a dual effort between a Route Processor (RP)
and a Switch Engine (SE).
- The basic idea is to “route once and switch many”.
- The RP receives the first packet of a new traffic flow between two hosts.
- The RP make a routing decision and “route” the packet toward the destination.
- The SE then can listen to the first packet going to the router and also going away from
the router.
- If the SE can “switch” the packet in both directions, it can learn a “shortcut path” so
that subsequent packets of the same flow can be switched directly to the destination
port without passing through the RP.
- This technique is also known as “NetFlow Switching” or “Route Cache Switching”.
- Traditionally, NetFlow Switching was performed on Cisco hardware.
- Basically, the hardware consisted of an independent RP component and a NetFlow-
Capable SE component.
CEF Overview:
- Cisco developed CEF for its line of routers, offering high performance packet
forwarding through the use of dynamic lookup tables.
- Cisco has carried over CEF to the Catalyst Multilayer Switches as well.
P a g e | 180
- The following platforms all perform CEF in hardware:
Catalyst 6500 Supervisor 720 (with an integrated MSFC3).
Catalyst 6500 Supervisor 2/MSFC2 combination.
Catalyst 4500 Supervisor III, IV, V and 6-E.
Fixed-configuration switches (such as the Catalyst 3750, 3560, and 3550).
- CEF is running by default on all CEF-Capable Catalyst switches, taking advantage of
the specialized hardware.
- The Catalyst 6500 (with a Supervisor 720 and its integrated MSFC3, or a Supervisor 2
and MSFC2 combination) runs CEF inherently, so CEF can never be disabled.
- Some Catalyst switches has CEF is disabled by default, to enable CEF:
Multilayer-Switch(config)# ip cef distributed
Multilayer-Switch(config-if)# ip route-cache cef
- A CEF-based multilayer switch consists of two basic functional blocks as shown in the
following figure:
Packet Flow Through CEF-Based Multilayer Switch
- The Layer 3 Engine is involved in building routing information that the Layer 3
Forwarding Engine can use to switch packets in the hardware.
P a g e | 181
Forwarding Information Base (FIB) Table:
- FIB Table A reformatted routing table into an ordered list with the most specific
route first for each destination IP subnet (prefix) in the routing table.
- The Layer 3 Engine (essentially a Router) maintains routing information, whether
from static routes or dynamic routing protocols (full details about the routing protocols
is covered in The Road “Route” book).
- The routing table is reformatted into an ordered list with the most specific route first,
for each destination IP subnet in the routing table.
- This new format is called the Forwarding Information Base (FIB) and contains routing
or forwarding information that the subnet can reference.
- In other words, a route to 172.16.1.0/24 might be considered in the FIB table a long
with routes to 172.16.1.128/25 and 172.16.1.4/30, if those subnets are existing.
- Notice that these examples are increasingly more specific subnets, as designated by the
longer subnet masks.
- In the FIB table, these would be ordered with the most specific, or longest match, first,
followed by less specific subnets.
- When the Multilayer Switch receives a packet, it easily can examine the destination
address and find the longest-match destination route entry in the FIB table.
- The FIB table also contains the next-hop address for each entry.
- When a longest-match entry is found in the FIB table, the Layer 3 next-hop address is
found too.
- FIB also contains direct host routes (with subnet mas 255.255.255.255) entries.
- Host routes are maintained in the FIB for the most efficient routing lookup to directly
connected hosts.
- As with the routing table, the FIB table is dynamic in nature.
- When the Layer 3 Engine sees a change in the routing topology, it sends an update to
the FIB.
- Any time the routing table receives a change to a route subnet or the next-hop address,
the FIB table receives the same change.
P a g e | 182
- Also, if a next-hop address is changed or aged out of the Address Resolution Protocol
(ARP) table, the FIB table must reflect the same change.
- To show the FIB table entries related to a specific interface or VLAN, use the
following command:
Multilayer-Switch# show ip cef [“type mod/num.” | vlan “vlan-id”] [detail]
- You can also show the FIB table entries by specifying an IP subnet number (prefix)
and subnet-mask using the following command:
Multilayer-Switch# show ip cef [“subnet” “mask”] [longer-prefixes] [detail]
- Normally, only an exact match of the subnet number and mask will be displayed if it
exists in the CEF table.
- To show other longer match entries, you can add the “longer-prefixes” keyword.
- You can use the “detail” keyword to see more information about each FIB table entry.
- After the FIB table is built, packets can be forwarded along the bottom dashed path in
the previous figure (Packet Flow Through CEF-Based Multilayer Switch).
- This follows the hardware switching process in which no time consuming operations
are needed.
- Sometimes a packet cannot be switched in hardware, according to the FIB table, this
packet then is marked as “CEF Punt” and immediately is sent to the Layer 3 Engine
for further processing, as shown in the top dashed path in the previous figure (Packet
Flow Through CEF-Based Multilayer Switch).
- Some of the conditions that can cause this are as follows:
An entry cannot be located in the FIB table.
The FIB table is full.
The IP Time-To-Live (TTL) has expired.
The MTU is exceeded, and the packet must be fragmented.
The encapsulation type is not supported.
Packets are tunneled, requiring a compression or encryption operation.
A NAT operation must be performed (except on the Catalyst 6500 Supervisor
720, which can handle NAT in hardware.
P a g e | 183
- CEF operations can be handled on a single hardware platform (such as the Catalyst
3560 and 3750 switches).
- CEF also can be optimized through the use of specialized forwarding hardware, using
the following techniques:
Accelerated CEF (aCEF).
Distributed CEF (dCEF).
a) Accelerated CEF (aCEF):
- CEF is distributed across multiple Layer 3 Forwarding Engines, typically located in
Catalyst 6500 line cards.
- These Layer 3 Forwarding Engines do not have capability to store and use the FIB
table, so only a portion of the FIB table is downloaded to them at any time.
- This functions as an FIB “Cache”, containing entries that likely to be used again.
- If the FIB entries are not found in the cache, requests are sent to the Layer 3 Engine
for more FIB information.
- The net result is that CEF is accelerated on the line cards, but not necessarily at a
sustained wire-speed rate.
b) Distributed CEF (dCEF):
- CEF can be distributed completely among multiple Layer 3 Forwarding Engines for
even greater performance.
- Because the FIB is self-contained for complete Layer 3 forwarding, it can be replicated
across any number of independent Layer 3 Forwarding Engines.
- The Catalyst 6500 has line cards that support dCEF, each with its own FIB table and
Layer 3 Forwarding Engine.
- A central Layer 3 Engine (for example, the MSFC3) maintains the routing table and
generates the FIB, which is then dynamically downloaded in full to each of the line
cards.
P a g e | 184
Adjacency Table:
- Adjacency Table A portion of the FIB table that has corresponding Layer 2
information (the MAC addresses of hosts that can be reached in a
single Layer 2 hop) for every next-hop entry to streamline packet
forwarding.
- A router normally maintains a routing table (containing Layer 3 subnet and next-hop
IP address) and an ARP table containing Layer 3 and Layer 2 address mapping.
- The routing table and the ARP table are kept independently.
- Recall that the FIB table keeps the Layer 3 next-hop address for each entry.
- To streamline packet forwarding even more, the FIB table has corresponding Layer 2
information for every next-hop entry.
- This portion of the FIB table is called the “adjacency table”, consisting of the MAC
addresses of nodes that can be reached in a single Layer 2 hop.
- To show the adjacency table’s contents, use the following command:
Multilayer-Switch# show adjacency [“type mod/num.” | vlan “vlan-id”] [detail | summary]
- For example, to show the adjacency table contents of VLAN 20 of a multilayer switch:
Multilayer-Switch-A# show adjacency vlan 20 detail
Protocol Interface Address
IP Vlan20 172.16.1.2
0 packets, 0 bytes
0000603E30B283006047CC920800
ARP 04:43:55
epoch 0
- The adjacency table entries include both the Layer 3 IP address and the Layer 2 MAC
address of the directly connected hosts.
P a g e | 185
- The host MAC address is shown as the first six octets of the long string of hex digits or
on a line by itself.
- The second six octets of hex digits contains the MAC address of the Layer 3 Engine’s
interface (corresponding to the VLAN20 interface in the example) followed by the
EtherType value (last two octets, where 0800 denotes IP).
- The adjacency table information is built from the ARP table.
- As a next-hop address receives a valid ARP entry, the adjacency table is updated.
- If an ARP entry does not exist, the FIB entry is marked as “CEF glean”, this means
that the Layer 3 Forwarding Engine cannot forward the packet in hardware because of
the missing Layer 2 next-hop MAC address.
- The packet is sent to the Layer 3 Engine so that it can generate an ARP request and
receive an ARP reply.
- This is knows as “CEF glean” state, in which the Layer 3 Engine must glean the next-
hop destination’s MAC address.
- To show the adjacencies in the “CEF glean” state, use the following commands:
Multilayer-Switch# show ip cef adjacency glean
Multilayer-Switch# show ip cef “ip-address” “mask” detail
- For example, to show the adjacencies in the “CEF glean” state on a multilayer switch:
Multilayer-Switch-A# show ip cef adjacency glean Prefix Next Hop Interface 10.1.1.2/32 attached VLAN30 !Lines are omitted for brevity
Multilayer-Switch-A# show ip cef 10.1.1.2 255.255.255.255 detail 10.1.1.2/32, version 688, epoch 0, attached, connected 0 packets, 0 bytes Via VLAN30, 0 dependencies Valid glean adjacency
P a g e | 186
- The following show command shows that there is no valid ARP entry for the IP
address (10.1.1.2):
Multilayer-Switch-A# show ip arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 172.16.1.1 - 0060.47CC.921E ARPA Vlan20
Internet 172.16.1.2 30 0060.3E30.B283 ARPA Vlan20
Internet 192.168.1.1 - 0060.47CC.921E ARPA Vlan10
Internet 192.168.1.2 30 0001.C9B4.6B01 ARPA Vlan10
- During the time that an FIB entry is in the “CEF glean” state, waiting for the ARP
resolution, subsequent packets to that host are immediately dropped so that the input
queues do not fill and the Layer 3 Engine does not become too busy worrying about
the need for duplicate ARP requests.
- This called “ARP Throttling” or “throttling adjacency”.
- If an ARP reply is not received in 2 seconds, the throttling is released so that another
ARP request can be triggered.
- Otherwise, after an ARP reply is received, the throttling is released, the FIB entry can
be completed, and packets can be forwarded completely in the hardware (Layer 3
Forwarding Engine).
- The adjacency table also can contain other types of entries so that packets can be
handled efficiently.
- You might see these adjacency types:
Null Adjacency Used to switch packets destined for the null interface.
Note: - The null interface represents a logical interface that absorbs packets without
actually forwarding them.
Drop Adjacency Used to switch packets that cannot be forwarded normally.
- In effect, these packets are dropped without being forwarded.
- Packets can be dropped because of an encapsulation failure, an unresolved address, an
unsupported protocol, no valid route present, no valid adjacency, or a checksum error.
P a g e | 187
- You can show the drop adjacency activity with the following command:
Multilayer-Switch-A# Show cef drop CEF Drop Statistics Slot Encap_fail unresolved unsupported No_route No_adj ChkSum_Err RP 4537602 1 37320 4262397 32 0
Discard Adjacency Used when packets must be discarded because of an access
list or other policy action.
Punt Adjacency Used when packets must be sent to the Layer 3 Engine for
further processing.
- You can show the CEF punt activity by looking at the various punt adjacency reasons
using the following command:
Multilayer-Switch-A# show cef not-cef-switched Slot No_adj No_encap Unsupp’ted Redirect Receive Options Access Frag RP 2526806 0 0 0 51607896 0 0 0
- The reasons shown are as follows:
No_adj An incomplete adjacency.
No_encap An incomplete ARP resolution.
Unsupp’ted Unsupported packet feature.
Redirect ICMP redirect.
Receive Layer 3 Engine interfaces; include packets destined for IP addresses
that are assigned to interface on the Layer 3 Engine, IP network
addresses, and IP broadcast addresses.
Options IP options present.
Access Access list evaluation failure.
Frag Fragmentation failure.
P a g e | 188
Packet Rewrite:
- When a multilayer switch finds valid entries in the FIB and adjacency tables, a packet
is almost ready to be forwarded.
- The multilayer switch has an additional functional block that perform a packet rewrite
in real time.
- The packet still has the original destination MAC address of the switch itself.
- The IP header also must be adjusted, as if a router had done the forwarding.
- The packet rewrite engine makes the following changes to the packet just before
forwarding:
Layer 2 destination address Changed to the next-hop device’s MAC address.
Layer 2 source address Changed to the outbound Layer 3 switch interface’s
MAC address.
Layer 3 IP TTL Decremented by one because one router hop has just occurred.
Layer 3 IP checksum Recalculated to include changes to the IP header.
Layer 2 frame checksum Recalculated to include changes to the Layer 2 and
Layer 3 headers.
Configuring CEF:
- In some Catalyst switches , CEF is not enabled by default, to enable CEF:
Multilayer-Switch(config)# ip cef distributed
- Multilayer switches (such as the Catalyst 3750 and 4500 run CEF by default, but you
can disable CEF on a per-interface basis.
- To enable or disable CEF on the Catalyst 3750 on an interface:
Multilayer-Switch(config)# [no] ip route-cache cef
- To enable or disable CEF on the Catalyst 4500 on an interface:
Multilayer-Switch(config)# [no] ip cef
P a g e | 189
Note: - To allow communication on Layer 3, a Routing Protocol (EIGRP or OSPF)
MUST be configured on all Multilayer Switches, these topics are covered
fully in The Road (Route) book.
- To verify CEF, you can show the entire FIB table contents using the following
command:
Multilayer-Switch# show ip cef
- To show the complete FIB table information for a specific interface:
Multilayer-Switch# show ip cef “type mod/num.” [detail]
Using DHCP with Multilayer Switches:
- Hosts can be configured manually to use the following static TCP/IP configuration:
Static IP address.
Subnet mask.
Default gateway.
DNS.
- Static configuration can be appropriate for servers, but not for a large number of PCs
in a network, because this will require a huge administrative efforts.
- To dynamically assign hosts TCP/IP configurations, Dynamic Host Configuration
Protocol (DHCP) is used.
- DHCP Is a service that is used to assign automatic TCP/IP configuration for large
number of hosts connected to a network.
- DHCP is defined in RFC 2131 and is built around a client/server model.
- Hosts uses DHCP Client to request TCP/IP configuration from a DHCP Server.
P a g e | 190
- The communication between a DHCP Client and DHCP Server follows these 4 steps:
DHCP Client/Server Communication
1) The client send a “DHCP Discover” message as a broadcast:
- Even without a valid source address, the client can send the broadcast address to
discover any DHCP server that might be listening.
- The client’s MAC address is included in the broadcast message.
2) A DHCP server replies with a “DHCP Offer” message:
- The offer contains an IP address, subnet mask, default gateway, and DNS.
- The server includes its own IP address to identify who is making the offer incase of
more than one DHCP server existing in the network.
- Because the client does not yet have a valid IP address, the server must broadcast the
offer message so the client can receive it.
3) The client sends a “DHCP Request” message:
- If the client is satisfied by the offer, it formally requests the use of the offered address.
- A record of the offer is included so that only the server that sent the offer will set aside
the requested IP address.
- The request is sent as a broadcast because the client has not officially started using a
valid address.
4) The DHCP server replies with a “DHCP ACK” message:
- The IP address and all other parameters of the TCP/IP configuration are returned to the
client as a formal approval to begin using the address.
- The ACK message is sent as a broadcast.
P a g e | 191
- Because DHCP is a dynamic mechanism, IP addresses are offered on a leased basis.
- Before the offered lease time expires, the client must try to renew its address lease,
otherwise, that address may be offered to a different client.
- The DHCP is designed to work within a broadcast domain, most of the DHCP
messages are sent as broadcasts.
- On this basis, the DHCP server would need to be located in the same broadcast domain
as the client, in other words, in the same subnet (VLAN).
- In this scenario, you should have a dedicated DHCP server connected to the same
subnet (VLAN) as the client.
Note: - You can use a dedicated Server hardware with OS installed as a DHCP
server in large networks.
- This design requires one DHCP server for each broadcast domain (VLAN) on the
network, something that is not practical at all.
- You can get around this by configuring a multilayer switch as a DHCP Relay to relay
the DHCP communication messages between the DHCP client and server in two
different VLANs.
Configuring a Multilayer Switch as a DHCP Relay:
- If a DHCP Server is centrally located in a network, you can configure the multilayer
switch to relay DHCP messages between clients and the server, even if they are
located on different subnets (VLANs).
- To configure a multilayer switch to relay DHCP messages for every VLAN, use the
following command:
Multilayer-Switch(config)# interface vlan “vlan-id” Multilayer-Switch(config-if)# ip helper-address “dhcp-server-address”
- As a DHCP relay, the multilayer switch will intercept the broadcast DHCP messages
from the client and will forward them to the DHCP server address as unicast
messages.
P a g e | 192
- The multilayer switch keeps track of the subnet where the client messages arrived so
that it can relay the DHCP server responses back appropriately.
- You can configure more than one DHCP server address by the repeating the “ip
helper-address” command in case of more than one DHCP server exists in the
network.
- In this case, the switch will relay the DHCP discover message from a client to each of
the DHCP servers configured in the helper addresses simultaneously.
- If more than one DHCP server replies, each reply will be relayed back to the client,
and the client will have to choose one offer and reply with a DHCP request.
Example: - Consider the following network:
Connecting one DHCP to a Network with multiple subnets
- First, do not configure the hosts (PC-1 and PC-2) using static TCP/IP configuration,
and configure them to learn it dynamically via a DHCP server
- Configure a physical server to the DHCP server role (for example, configure the
DHCP server role on Microsoft Windows Server) with two scopes as mentioned in the
figure.
- Connect the DHCP server to the network and configure it with static TCP/IP
configuration as mentioned in the figure.
P a g e | 193
- To configure the Multilayer-Switch-A, use the following commands:
Multilayer-Switch-A(config)# ip routing Multilayer-Switch-A(config)# ip cef distributed Multilayer-Switch-A(config)# vlan 10 Multilayer-Switch-A(config-vlan)# name VLAN-10 Multilayer-Switch-A(config)# vlan 20 Multilayer-Switch-A(config-vlan)# name VLAN-20 Multilayer-Switch-A(config)# interface fastEthernet 0/10 Multilayer-Switch-A(config-if)# switchport mode access Multilayer-Switch-A(config-if)# switchport access vlan 10 Multilayer-Switch-A(config)# interface fastEthernet 0/20 Multilayer-Switch-A(config-if)# switchport mode access Multilayer-Switch-A(config-if)# switchport access vlan 20 Multilayer-Switch-A(config)# interface vlan 10 Multilayer-Switch-A(config-if)# ip address 192.168.1.1 255.255.255.0 Multilayer-Switch-A(config-if)# ip helper-address 100.1.1.2 Multilayer-Switch-A(config)# interface vlan 20 Multilayer-Switch-A(config-if)# ip address 172.16.1.1 255.255.0.0 Multilayer-Switch-A(config-if)# ip helper-address 100.1.1.2 Multilayer-Switch-A(config)# interface gigabitethernet 0/1 Multilayer-Switch-A(config-if)# no switchport Multilayer-Switch-A(config-if)# ip address 20.1.1.1 255.255.255.252 Multilayer-Switch-A(config)# router eigrp 1 Multilayer-Switch-A(config-router)# network 192.168.1.0 Multilayer-Switch-A(config-router)# network 172.16.0.0 Multilayer-Switch-A(config-router)# network 20.0.0.0
- To configure the Multilayer-Switch-B, use the following commands:
Multilayer-Switch-B(config)# ip routing Multilayer-Switch-B(config)# ip cef distributed Multilayer-Switch-B(config)# vlan 5 Multilayer-Switch-B(config-vlan)# name VLAN-5 Multilayer-Switch-B(config)# interface vlan 5 Multilayer-Switch-B(config-if)# ip address 100.1.1.1 255.255.255.0 Multilayer-Switch-B(config)# interface gigabitethernet 0/1 Multilayer-Switch-B(config-if)# no switchport Multilayer-Switch-B(config-if)# ip address 20.1.1.2 255.255.255.252 Multilayer-Switch-B(config)# router eigrp 1 Multilayer-Switch-B(config-router)# network 20.0.0.0 Multilayer-Switch-B(config-router)# network 100.0.0.0
- Now you can check the hosts (PC-1 and PC-2) to see the automatic TCP/IP
configuration assigned to each one of them.
P a g e | 194
Configuring a Multilayer Switch as a DHCP Server:
- You can configure a DHCP server that runs natively on a multilayer or a router.
- The multilayer switch will reply to the DHCP Discover broadcast messages from
clients within a VLAN and offer clients TCP/IP configurations.
- To configure a DHCP server on a multilayer switch, use the following commands:
Multilayer-Switch(config)# ip dhcp pool “pool-name” Multilayer-Switch(dhcp-config)# network “subnet” “mask” Multilayer-Switch(dhcp-config)# default-router “gateway-ip-address” Multilayer-Switch(dhcp-config)# dns-server “dns-ip-address” Multilayer-Switch(dhcp-config)# lease {infinite | “days” “hours” “minutes”} Multilayer-Switch(dhcp-config)# option “option-code” ip “ip-address” Multilayer-Switch(config)# ip dhcp excluded-address “start-ip” “end-ip”
- “ip dhcp pool” Defines a name to the pool or scope of addresses that will be
offered.
- “network” Identifies the range of IP addresses that the DHCP will assign to clients.
- “default-router” Identifies the default gateway that the clients will use.
- “dns-server” Identifies the DNS server that the clients will use to resolve names
into IP addresses and vice versa.
- “lease” Defines the period of time a client can have the offered TCP/IP
configuration.
Note: - By default, leases are offered with a 1 day limit.
- “ip dhcp excluded-address” Defines the IP addresses that will be excluded from
the scope or pool range of addresses defined in the
“network” command.
- You can monitor the DHCP server address leases using the following command:
Multilayer-Switch# show ip dhcp binding
P a g e | 195
Chapter 11 Enterprise Campus Network Design
Hierarchical Network Design:
- Campus Network Is an Enterprise network consisting of many VLANs in one or
more buildings, all connected and all usually in the same
geographic area and owned by a company or organization.
- Campus networks commonly consists of wired Ethernet LANs running at speeds of up
to 10 Gbps and shared Wireless LANs.
- Understanding the traffic flow is a vital part of the campus network design.
- The emphasis should be on providing an overall design that is tuned to studied or
predicted traffic flows.
- The network traffic then can be effectively managed, and you can scale the campus
network to support future needs.
- Consider the simple network shown in the following figure:
Simple Ethernet Layer 2 Switched Network
- A collection of PCs, Printers, and Servers are all connected to the same network subnet
(VLAN) and use the subnet number (192.168.1.0/24).
- All devices in this VLAN are members of the same broadcast domain.
P a g e | 196
- A VLAN with 6 connected hosts might not seem crowded.
- Suppose a VLAN contains hundreds of hosts instead, broadcasts may overload the
network.
- Through network segmentation into multiple of VLANs, you can reduce the broadcast
domains, by providing a barrier at the edge of each VLAN, so that broadcasts cannot
pass outward.
- You can add Layer 2 VLANs as shown in the following figure:
Simple Ethernet Switched Network with two VLANs
- The difference between segmenting broadcast domains using a Layer 2 switch and a
multilayer switch, is that by using a Layer 2 switch, there will be no communication
between different VLANs.
- By using a multilayer switch, communication between different VLANs can be
configured at Layer 3 routing, but still the multilayer switch will not forward
broadcasts between different VLANs.
- The network might continue to grow as more hosts are added to it.
- The switch has a limited number of ports, so as the number of hosts grow, the switch
ports will not be enough for the new added hosts.
- Instead, the network can be grown by adding a new switch to the network as shown in
the following figure:
P a g e | 197
A Network with two Layer 2 Switches and a Multilayer Switch with 4 VLANs
- As the network keep growing, new switches will be needed to be added as shown in
the following figure:
P a g e | 198
Predictable Network Model:
- As the campus network keep growing, you should design a network with a predictable
behavior in mind and to offer redundancy, scalability, and high availability.
- A campus network needs to recover from failures quickly and in a predetermined
manner through redundancy.
- Also, the campus network should be scalable to support future expansions.
- Something else, the campus network should provide high availability for the used
gateways so that VLANs keep connected incase of a gateway failure.
- Ideally, the campus network should be arranged so that all end users are located at a
consistent distance from the resources they need to use.
- For example, if one user at one corner of the network passes through two switches to
reach an E-mail server, any other user at any other location in the network should also
require two switches hops for the E-mail server.
- Cisco has refined a hierarchical network design to organize the network into distinct
layers of devices.
- The resulting network is efficient, redundant, scalable, highly available, and easily
managed.
- The following figure shows two layers of network design that became apparent as
network grows:
Two-Layers Network Hierarchy
P a g e | 199
- The two layers are:
Access Layer Where end user hosts are connected.
Distribution Layer Where access-layer switches are aggregated.
- As the network continues to grow, with more buildings, more floors, and larger groups
of users, the number off access switches increases.
- As a result, the number of distribution switches increases.
- Now, things have scaled to the point where the distribution switches need the be
aggregated.
- This is done by adding a third layer to the hierarchy, the core layer, as shown in the
following figure:
Three-Layers Network Hierarchy
- Core Layer Where distribution-layer switches are aggregated.
- Traffic paths can be easily described, regardless of where the user is located, the traffic
paths begins at the access-layer and progresses into the distribution-layer and perhaps
into the core-layer.
- Even a path between two users at opposite ends of the network becomes a consistent
and predictable.
Access Distribution Core Distribution Access
P a g e | 200
Access Layer:
- The access-layer switches are present where the end user hosts are connected to the
network.
- Access switches usually provide Layer 2 connectivity between end users.
- Access switches should have the following capabilities:
Scalable and redundant uplinks to the distribution layer.
Low Cost.
User access functions (such as VLAN membership, quality of service (QoS),
traffic and protocol filtering.
Distribution Layer:
- The distribution-layer switches provides interconnection between the campus
network’s access-layer switches and core-layer switches.
- Distribution switches should have the following capabilities:
Scalable and redundant high-speed uplinks to the core-layer switches.
Aggregation of multiple access-layer switches.
High Layer 3 throughput for packet handling.
Security and Policy-based connectivity functions through ACLs.
- The distribution-layer switches must be capable of processing the total volume of
traffic from all connected switches.
- The distribution-layer switches should have a high port density of high-speed links to
support the collection of access-layer switches.
- Also, The distribution-layer switches must be capable of performing multilayer
switching with high throughput.
- The distribution-layer switches usually are multilayer switches providing a Layer 3
boundary, where routing meets the VLANs of the access-layer.
P a g e | 201
Core Layer:
- The core-layer switches provides interconnection between the campus network’s
distribution-layer switches.
- The core layer sometimes referred to as the “backbone layer”.
- The core-layer switches must be capable of switching traffic as efficiently as possible.
- The core-layer switches should have the following capabilities:
Very high throughput at Layer 3.
Advanced quality of service (QoS).
- Campus network’s core-layer switches should be optimized for high performance
switching and must handle large amounts of campus wide traffic.
- Small or medium-size campus networks might not have the size, multilayer switching,
or volume requirements that would require the functions of all three layers.
- In this case, you can combine the distribution and core layers for simplicity and cost
savings.
- When the distribution and core layers are combined into a single layer of switches, a
“collapsed core” network results.
Modular Network Design:
Predictable Network Design
P a g e | 202
- Designing a new campus network that has a hierarchical 3 layers is straightforward.
- You can also migrate an existing network into a hierarchical design.
- As shown in the previous figure, a simple predictable hierarchical design with three
layers offers “Scalability” but does not address other best practices like “Redundancy”
or “High-Availability”.
- In case of a switch or link fails, a big portion of the network will be disconnected.
- To mitigate a potential distribution switch failure, you can add a second redundant
distribution switch.
- To mitigate a potential link failure, you can add a redundant link from each access-
layer switch to each distribution-layer switch.
- Also, redundant links should be added between the distribution-layer switches and the
core-layer switches as shown in the following figure:
Fully Redundant Hierarchical Network Design
- When the redundant switches and redundant links are added into the design, network
growth can become confusing.
- To maintain the campus network design simple and predictable without confusion, you
can use the modular network design approach.
P a g e | 203
- You can divide the Enterprise campus network into the following basic elements:
Switch Block - A group of access-layer switches, together with their
distribution-layer switches.
- This is shown in the dashed rectangle in the previous figure.
Core Block The campus network’s backbone.
a) Switch Block:
- The switch block contains switches from the access and distribution layers.
- All switch blocks then connect into the core block, providing end-to-end connectivity,
scalability, redundancy, and high-availability across the campus network.
Typical Switch Block Design
- Switch blocks contain a balanced mix of Layer 2 and Layer 3 functionality, as might
be present in the access and distribution layers.
- Layer 2 switches located in the access layer to connect end-users to the campus
network.
- With one end user per switch port, each user receives dedicated bandwidth access.
P a g e | 204
- Layer 3 functionality also can be provided in the form of routing and other networking
services (High availability, QoS, and so on).
- Therefore, a distribution-layer device should be a multilayer switch.
- The distribution layer also shields the switch block certain failures or conditions in
other parts of the network.
- For example, broadcasts are not propagated from the switch block into the core and
other switch blocks.
- Therefore, the STP is confined to each switch block, where a VLAN is bounded,
keeping the spanning-tree topology well defined and controlled.
- Access-layer switches can support VLANs by assigning individual ports to specific
VLAN numbers.
- In this way, hosts connected to the same VLAN can share the same Layer 3 subnet.
Note: - In this network design model, you should not extend VLANs beyond the
distribution-layer switches.
- The distribution-layer always should be the boundary of VLANs and
broadcasts.
- Although Layer 2 access switches can extend VLANs to the other access
switches in another switch block, this activity is discouraged.
- VLAN traffic should not travers the network core layer.
- For example, consider the following two switch blocks connecting with a core switch.
P a g e | 205
- VLAN-10 broadcasts will be transferred from Switch Block-A to Switch Block-B
through the core-layer switch, which is a discouraged activity.
- The distribution layer always should be the boundary of VLANs and broadcasts.
Sizing a Switch Block:
- The range of available switches makes the switch block size very flexible.
- At the access-layer, switch selection usually is based on the number of connected
users.
- The distribution layer must be sized according to the number of access-layer switches
that are brought into a distribution multilayer switch.
- When sizing the distribution layer, consider the following factors:
Number of users connected to the access-layer switches.
Traffic types and patterns.
Geographic boundaries of subnets (VLANs).
- Generally, a switch block is too large if the following conditions are observed:
- The multilayer switches at the distribution layer become traffic bottlenecks.
- This congestion can be because of the volume of InterVLAN traffic, intensive
CPU processing, or switching times required by policy or security functions
(ACLs, queuing, and so on).
- Broadcast or multicast traffic slows the switches in the switch block.
- Broadcast and multicast traffic must be forwarded out many ports.
- This process requires some overhead in the multilayer switch, which can
become too great if significant traffic volumes are present.
P a g e | 206
Switch Block Redundancy:
- Access-layer switches can have one or more redundant uplinks to the distribution-layer
switches.
- This situation provides redundancy in which access layer connectivity is preserved on
a secondary uplink if the primary uplink fails.
- Because multilayer switches are used in the distribution layer, traffic can be load-
balanced across both redundant uplinks using redundant gateways.
- Also, failover gateway can be performed between the distribution layer multilayer
switches.
Note: - Failover and load-balancing Layer 3 High Availability will be discussed in
Chapter 12 (Layer 3 High Availability).
- The following figure shows a typical switch block that has two VLANs that spans
multiple access-layer switches:
Typical Switch Block Design
- A switch block consists of two distribution switches (multilayer switches) that
aggregate two or more access layer switches (L2 switches or multilayer switches).
- Each access-layer switch have two uplinks, one connecting to each distribution switch.
VLAN A
VLAN B
VLAN A
VLAN B
P a g e | 207
- Consider the following switch block design:
All Layer 2 links Switch Block Design
- The two VLANs (VLAN-A and VLAN-B) spans across every switch (both access and
distribution switches) and across every trunk link connecting the switches.
- This is necessary for the VLAN to be present on both access-layer switches and to
have redundant uplinks for redundancy.
- In this design, Switch-C is a primary root bridge for VLAN-A and Switch-D is a
secondary root bridge for VLAN-A.
- Switch-D can be a primary root bridge for VLAN-B and Switch-C can be a secondary
root bridge for VLAN-B.
- The figure shows only STP for VLAN-A to show the blocked uplinks.
- It is recommended to use RSTP in this switch block design to improve the
convergence time.
- As a best practice, the link between the two distribution switches can be a L3 link:
Best Practice for a Switch Block Design
P a g e | 208
- Using this design, both VLANs (VLAN-A and VLAN-B) spans multiple access
switches (Switch-A and Switch-B).
- Both uplinks on each switch can be used in the STP topology, and for faster
convergence, RSTP can be used.
- The Layer 3 link (with IP addresses) between the distribution switches in needed to
carry routing updates to the upper core layer (routing protocols are covered fully in
The Road “Route” Book).
- Switch-C is configured as the primary root bridge for VLAN-A and Switch-D as the
secondary root bridge for VLAN-A.
- Switch-D can be configured as the primary root bridge for VLAN-B and Switch-C as
the secondary root bridge for VLAN-B.
- The following switch block design shows multilayers switches used in the access
layer, with all links between the distribution and access layers are Layer 3 links.
All Layer 3 Links Switch Block Design
- Here, VLANs do not span across switches at all.
- Each VLAN is contained within a single access-layer switch.
- This design offers no dependence on STP convergence.
- A routing protocol should be configured between all multilayer switches, network
stability is offered through the fast convergence of the routing protocol (EIGRP or
OSPF).
P a g e | 209
Core Block:
- A core block is required to connect two or more switch blocks in a campus network.
- Two basic core block designs are presented:
Dual Core Design.
Collapsed Core Design.
a) Dual Core Design:
Dual Core Design
- The dual core design connects two or more switch block in a redundant fashion.
- The core layer is scalable when more switch blocks are added.
- The core layer is the campus network’s basic foundation and must be as efficient as
possible because it carries much more traffic than any other block.
- Both distribution and core layer switches are multilayers switches.
- The links between the distribution and core layer switches can be either Layer 3 or
Layer 2 links.
P a g e | 210
- If all Layer 3 links are used, a routing protocol should be configured on all distribution
and core layer switches and bridging loops is not an issue.
- When using all Layer 3 links, a one VLAN cannot exist in two different switch blocks,
and access VLANs terminate at the distribution layer switches.
- Also, the routing protocol used between the distribution and core layer switches can
route traffic across both links in a load-sharing fashion, utilizing both bandwidths.
- If all Layer 2 trunk links are used, spanning-tree topology should be designed and you
can choose the core layer switches as the primary and secondary root bridges for all
STP instances to obtains a loop-free topology and to benefit from the high speed links
between the distribution and core layer switches, and you can use RSTP for faster
convergence.
- When using all Layer 2 trunk links, a one VLAN can exist in two different switch
blocks, but this is not recommended , as all VLAN broadcast traffic will flow across
the core layer switches.
- One final dual core design point is to scale the core switches to match the incoming
load.
- At minimum, each core switch must handle switching each of its incoming distribution
links at 100 percent capacity.
b) Collapsed Core Design:
Collapsed Core Design
P a g e | 211
- A collapsed core design is one in which the hierarchy’s core layer is collapsed into the
distribution layer.
- Here, both the distribution and core functions are provided within the same
distribution layer switches.
Note: - The collapsed core design can be found in small or medium-size campus
networks.
P a g e | 212
Chapter 12 Layer 3 High Availability
Gateway High Availability in Multilayer Switching:
- Multilayer switches can act as IP gateways for connected hosts by providing gateway
addresses at VLAN SVIs.
- These multilayer switches can use routing protocols just as traditional routers.
- For high availability, multilayer switches should offer a means of preventing one
gateway (multilayer switch) failure from isolating an entire VLAN.
- There are two types of gateway high availability:
Failover.
Load Balancing.
Note: - “Redundancy” term sometimes used instead of the “High Availability” term.
Failover:
- Two or more gateways can be used to provide high availability.
- One gateway is in “active” mode and other gateways are in “standby” mode, incoming
traffic will be forwarded only to the active gateway.
- If the active gateway will fail, one of the standby gateways will take over and be the
active gateway.
- Two protocols are used to provide gateway failover high availability:
Hot Standby Router Protocol (HSRP).
Virtual Router Redundancy Protocol (VRRP).
Load Balancing:
- Two or more gateways can be used to provide high availability.
- All gateways are in “active” forwarding mode, incoming traffic will be forwarded in a
balanced fashion between all active gateways.
P a g e | 213
- If one gateway will fail, the incoming traffic load will be balanced between the other
active gateways in the group.
- The traffic forwarded to the failed gateway will be handled by another active gateway.
- One protocol is used to provide load balancing high availability:
Gateway Load Balancing Protocol (GLBP).
Hot Standby Router Protocol (HSRP):
- HSRP Is a Cisco-proprietary protocol developed to allow several gateways to
appear as a single gateway IP address.
- Basically, each of the gateways that provides high availability for a given gateway IP
address is assigned to a common HSRP group.
- One gateway will be elected as the “active” HSRP gateway, and another gateway in
the same HSRP group will be elected as the “standby” HSRP gateway, and all other
remaining gateways (if more than 2 gateways are used) will remain in the “listen”
HSRP state.
- The active gateway sends HSRP hello messages at regular intervals (default 3 seconds)
so that the standby gateway in the HSRP group can remain aware of the existence of
the active gateway.
- An active HSRP gateway sends hello messages to the multicast destination IP address
(224.0.0.2) “all gateways” using UDP port 1985.
- An HSRP group can be assigned a number from 0 to 255.
- If you configure HSRP groups on several VLAN interfaces, it can be “handy” to make
the group number the same as the VLAN number.
- However, most Catalyst multilayer switches support only up to 16 unique HSRP group
numbers.
- If you have more than 16 VLANs, you will quickly run out of group numbers.
- An alternative is to make the group number the same (that is, 1) for every VLAN
interface.
- For example, HSRP group 1 on interface VLAN 10 is unique and independent from
HSRP Group 1 on interface VLAN 11.
P a g e | 214
HSRP Active Gateway Election:
- HSRP active gateway election is based on a priority value (0 to 255) that is configured
on each gateway in the HSRP group.
- By default, the priority value is 100, and the highest priority value is 255.
- The gateway with the highest priority value in the HSRP group will be elected as the
“active” gateway.
- If the highest priority ties between two or more gateways, the gateway with the highest
IP address on the VLAN interface becomes the active gateway.
- The gateway with the second highest priority value in the HSRP group will be elected
as the “standby” gateway.
- To configure the gateway priority value, use the following commands:
Multilayer-Switch(config)# interface vlan “vlan-id” Multilayer-Switch(config)# standby “group” priority “priority-value”
- When HSRP is configured on a SVI, the gateway progresses through a series of states
before becoming in either active, standby, or listen states.
- This forces a gateway to listen for the other gateways in the HSRP group and see
where it fits in the pecking order.
- Gateways in an HSRP group must progresses their VLAN interfaces through the
following state sequence:
Disabled.
Init.
Listen.
Speak.
Standby.
Active.
- Only the standby gateway monitors the HSRP hellos sent by the active gateway.
- By default, hello messages are sent by the active gateway every 3 seconds.
- If hello messages are missed for the duration of the “holdtime” timer (default 10
seconds), the active gateway is considered to be down.
P a g e | 215
- The standby gateway is then becomes the active gateway.
- At that point, if other gateways are sitting in the “listen” state, the next-highest priority
gateway is allowed to become the new standby gateway.
- If you need to adjust the timer values on a gateway, use the following VLAN interface
subcommand:
Multilayer-Switch(config)# standby “group” timers [msec] “hello” [msec] “holdtime”
Note: - If you decided to change the HSRP timers on a gateway, you should change
them identically on all gateways in the HSRP group.
- The “hello” and “holdtime” values can be given in seconds or in milliseconds.
- If the “msec” keyword is used, then the configured value is in milliseconds
- If the “msec” keyword is omitted, then the configured value is in seconds.
- The “hello” value can range from 1 to 254 seconds, or from 15 to 999 mseconds.
- The “holdtime” value can range from 1 to 255 seconds, or from 50 to 3,000 mseconds.
- The “holdtime” value should be configured at least three times the “hello” value.
Note: - Be aware that decreasing the HSRP “hello” value allows a gateway failure to
be detected more quickly.
- At the same time, HSRP hello messages will be sent more often, increasing
the amount of traffic.
- Normally, after the active gateway fails and the standby gateway becomes active, the
original active gateway cannot immediately become active when it is restored until the
current active gateway fails, even if its priority is higher than that of the current active
gateway.
- Also, an interesting case arises when gateways are just being powered up or added to a
network.
- The first gateway to bring up its interface, becomes the HSRP active gateway, even if
it has the lowest priority of all.
- You can configure a gateway to “preempt” or immediately take over the active role if
its priority is the highest “at any time”.
- To allow preemption on a gateway, use the following command:
P a g e | 216
Multilayer-Switch(config-if)# standby “group” preempt [delay [minimum “seconds”] [reload “seconds”]]
- Without configuring “delay” and “reload” values, the local gateway immediately can
preempt another active gateway.
- To delay the preemption, use the “delay” keyword followed by one or both of the
following parameters:
- “minimum” - Used to force the gateway to wait for some time (0 to 3,600 seconds)
before attempting to overthrow an active gateway with a lower
priority.
- This delay time begins as soon as the gateway is capable of assuming
the active role, such as after an interface comes up or after HSRP is
configured.
- “reload” - Used to force the gateway for some time (0 to 3,600 seconds) after it has
been reloaded or rebooted.
- This is handy if there are routing protocols that need time to converge.
- The local gateway should not become the active gateway before its
routing table is fully populated, otherwise, it might not be capable of
routing traffic properly.
HSRP Authentication:
- HSRP can use an authentication method to prevent unexpected gateways from
spoofing or participating in HSRP.
- All gateways in the same HSRP group must have an identical authentication method
and key.
- You can use one of the following HSRP authentication methods:
Plain-text Authentication.
MD5 Authentication.
P a g e | 217
a) Plain-text Authentication:
- HSRP messages are sent with a plain-text key string (not encrypted key and up to 8
characters) as a simple method to authenticate HSRP peers.
- If the key string sent with a message matches the key configured on an HSRP peer, the
message is accepted.
- To configure a plain-text authentication key for the HSRP group, use the following
command:
Multilayer-Switch(config-if)# standby “group” authentication text “string”
b) MD5 Authentication:
- A Message Digest (MD5) hash is computed from each HSRP message and a secret key
known only to legitimate HSRP group peers.
Secret key
Message hash value
MD5 Authentication
- The MD5 hash value is sent along with HSRP messages.
- As a message is received, the peer re-computes the hash value using the message
contents and its own secret key.
- If the hash value is identical with the one received with the message, the message is
accepted.
- MD5 authentication is more secure than plain-text authentication because the hash
value attached with the HSRP message is extremely difficult to reverse.
- The hash value is used only to validate the message contents.
- To configure MD5 authentication with a key-string for an HSRP group, use the
following command:
Multilayer-Switch(config-if)# standby “group” authentication md5 key-string [0 | 7] “string”
One-way
function
P a g e | 218
- The key “string” (up to 64 characters).
- By default, the key “string” is entered as plain-text in the command, the same as
specifying “0” keyword in the command.
- You can also copy and paste an encrypted key “string” value into the command by
preceding the string with the “7” keyword.
Note: - All gateways in the same HSRP group must be configured with the same key
“string”.
HSRP Gateway Addressing:
- Each gateway in an HSRP group has its own unique IP address assigned to a SVI.
- In addition, each gateway has a common group IP address called the “virtual gateway
address”, which is kept alive by HSRP.
- Hosts can point to that virtual gateway address as their default gateway.
Note: - The actual SVI address and the HSRP virtual gateway address must be
configured to be in the same subnet.
- To configure the HSRP group virtual gateway address, use the following command:
Multilayer-Switch(config-if)# standby “group” ip “ip-address”
- Naturally, each gateway keeps a unique MAC address for its interface.
- This MAC address is always associated with the unique IP address configured on the
interface.
- For the virtual gateway address, HSRP defines a special MAC address of the form
0000.0C07.ACXX, where XX represents the HSRP group number as a two-digit hex
value.
- For example, HSRP group 1 appears as 0000.0C07.AC01, HSRP group 15 appears as
0000.0C07.AC0F, and so on.
- The following figure shows a simple network in which two multilayer switches use
HSRP group 1 to provide a virtual gateway address 192.168.1.1.
P a g e | 219
- Traffic sent by hosts (PC1 and PC2) will be processed only by Switch-C which will
perform the routing function because it is the active gateway in the HSRP group.
- To configure Switch-C, use the following commands:
Switch-C(config)# interface vlan 50 Switch-C(config-if)# ip address 192.168.1.10 255.255.255.0 Switch-C(config-if)# standby 1 priority 200 Switch-C(config-if)# standby 1 preempt Switch-C(config-if)# standby 1 ip 192.168.1.1 Switch-C(config-if)# standby 1 authentication md5 key-string 0 secret
- To configure Switch-D, use the following commands:
Switch-D(config)# interface vlan 50 Switch-D(config-if)# ip address 192.168.1.20 255.255.255.0 Switch-D(config-if)# standby 1 ip 192.168.1.1 Switch-D(config-if)# standby 1 authentication md5 key-string 0 secret
- To show information about the status of HSRP groups, use the following commands:
Multilayer-Switch# show standby [vlan “vlan-id”] [brief]
P a g e | 220
- To verify the HSRP gateway status of Switch-C:
Switch-C# show standby vlan 50 brief
P indicates configured to preempt.
|
Interface Grp Prio P State Active Standby Virtual IP
Vl50 1 200 P Active local 192.168.1.20 192.168.1.1
Switch-C# show standby vlan 50
Vlan50 – Group 1
Local state is Active, priority 200, may preempt
Hellotime 3 sec, holdtime 10 sec
Next hello sent in 2.248
Virtual IP address is 192.168.1.1 configured
Active router is local
Standby router is 192.168.1.11 expires in 9.860
Virtual mac address is 0000.0c07.ac01
Authentication md5 “0832494D1B1C11”
2 state changes, last state change 00:5:34
IP redundancy name is “hsrp-Vl50-1” (default)
- To verify the HSRP gateway status of Switch-D:
Switch-D# show standby vlan 50 brief
P indicates configured to preempt.
|
Interface Grp Prio P State Active Standby Virtual IP
Vl50 1 100 Standby 192.168.1.10 local 192.168.1.1
Conceding the Election:
- Consider an active gateway in an HSRP group where a group of hosts sends packets to
it for forwarding as their default gateway, and it has one or more links to the rest of the
network.
- If one of those links fails, the gateway remains active.
- If all of those links are failed, the gateway still remains active, but the path to the rest
of the network is either clipped or removed, and packets from hosts no longer can be
forwarded.
P a g e | 221
- HSRP has a mechanism for detecting link failures and swaying the election, giving
another gateway an opportunity to take over the active role.
- When a specific interface is tracked, HSRP reduces the gateway’s priority by a
configurable amount as soon as the interface goes down.
- If more than one interface are tracked, the priority is reduced even more with each
failed interface.
- The priority is incremented by the same amount as interfaces come back up.
- To configure interface tracking, use the following command:
Multilayer-Switch(config-if)# standby “group” track “type mod/num.” [“decrement-value”]
- By default, the “decrement-value” for an interface is 10 and its configured value can
range from 1 to 255.
- Keep in mind that interface tracking does not involve the state of the HSRP interface
itself.
- Instead, the state of other specific interfaces affects the usefulness of the local
multilayer switch as a gateway.
- You should also be aware that the only way another gateway can take over the active
role after interface tracking reduces the priority is if the following two conditions are
met:
Another gateway now has a higher HSRP priority.
That same gateway is using “preempt” in its HSRP configuration.
- Without preemption, the active role cannot be given to any other gateway.
Load Balancing with HSRP:
- As HSRP is typically a failover high availability protocol, you can use it to do the load
balancing concept with some more configuration applied.
- Consider a network in which HSRP is used on two distribution switches to provide
gateway failover high availability for the gateway address used by access-layer users.
- Only one of the two distribution switches becomes the active HSRP gateway, the other
gateway remains in standby.
P a g e | 222
- All the access-layer hosts send their traffic to the active gateway over the uplink.
- The standby gateway and its uplink essentially sit idle until a gateway failure occurs.
- To use HSRP for the load balancing concept, you can use two HSRP groups on both
multilayer switches, with one HSRP group assigns one multilayer switch as the active
gateway.
- In other words, each gateway is active for one HSRP group and standby for the other
HSRP group.
- In this way, two different virtual gateway addresses can be used simultaneously.
- The host must have their default gateway addresses configured as one of the two
HSRP group addresses.
- The following figure shows how to use HSRP for load balancing:
- After configuring this scenario, Switch-C is not only active gateway for HSRP group 1
(192.168.1.1), but it also the standby gateway for HSRP group 2 (192.168.1.2).
- Switch-D is configured similarly, but with its roles reversed.
- The remaining step is to configure half of hosts (PC1 and PC3) with the HSRP group 1
virtual gateway IP address (192.168.1.1), and the other half of hosts (PC2 and PC4)
with the HSRP group 2 virtual gateway IP address (192.168.1.2).
P a g e | 223
- This makes the load balancing possible, where each half of hosts uses one multilayer
switch as its gateway over one uplink.
- To configure Switch-C, use the following commands:
Switch-C(config)# interface vlan 50 Switch-C(config)# ip address 192.168.1.10 255.255.255.0 Switch-C(config)# standby 1 priority 200 Switch-C(config)# standby 1 preempt Switch-C(config)# standby 1 ip 192.168.1.1 Switch-C(config)# standby 2 ip 192.168.1.2
- To configure Switch-D, use the following commands:
Switch-D(config)# interface vlan 50 Switch-D(config)# ip address 192.168.1.20 255.255.255.0 Switch-D(config)# standby 1 ip 192.168.1.1 Switch-D(config)# standby 2 priority 200 Switch-D(config)# standby 2 ip preempt Switch-D(config)# standby 2 ip 192.168.1.2
- To show information about the status of the HSRP groups configured on Switch-C:
Switch-C# show standby vlan 50 brief
P indicates configured to preempt.
|
Interface Grp Prio P State Active Standby Virtual IP
Vl50 1 200 P Active local 192.168.1.20 192.168.1.1
Vl50 2 100 Standby 192.168.1.20 local 192.168.1.2
- To show information about the status of the HSRP groups configured on Switch-D:
Switch-D# show standby vlan 50 brief
P indicates configured to preempt.
|
Interface Grp Prio P State Active Standby Virtual IP
Vl50 1 100 Standby 192.168.1.10 local 192.168.1.1
Vl50 2 200 P Active local 192.168.1.10 192.168.1.2
P a g e | 224
Virtual Router Redundancy Protocol (VRRP):
- VRRP Is a standard-based alternative to HSRP to allow several gateways
(multilayer switches or routers) to appear as a single gateway IP address.
- VRRP is defined in IETF standard RFC 2338.
- VRRP is so similar to HSRP that you need to learn only slightly different terminology
and a couple of slight functional differences.
Note: - When you understand HSRP operation and configuration, you will also
understand VRRP.
- VRRP provides one “master” gateway (active in HSRP) from a group of gateways,
whereas all other gateways in the VRRP group are in the “backup” state (standby in
HSRP).
- VRRP group numbers range from 0 to 255.
- Gateway priority range from 1 to 254 (default is 100, and the highest priority is 254).
- The virtual gateway MAC address is of the form 0000.5E00.01XX, where XX is a
two-digit hex VRRP group number.
- VRRP advertisements (hello messages in HSRP) are sent at 1 second intervals to the
multicast address 224.0.0.18 and IP protocol 112.
- By default, backup gateways (optionally) can learn the advertisement interval from the
master gateway.
Note: - In HSRP, if you decided to change the HSRP timers on a gateway, you
should change them identically on all gateways in the HSRP group.
- By default, all VRRP gateways are configured to preempt the current master gateway
if their priorities are greater.
Note: - In HSRP, preemption is enabled by default.
- VRRP has no mechanism for tracking interfaces to allow more capable gateways to
take over the master role in case the master gateway interfaces are disconnected.
P a g e | 225
Note: - VRRP is available now only for the Catalyst 4500 (Cisco IOS Release
12.2(31)SG), Catalyst 6500 Supervisor 2 (Cisco IOS Release 12.2(9)ZA or later, and
Catalyst 6500 Supervisor 720 (Cisco IOS Release 12.2(179)SX4 or later).
VRRP Configuration Commands:
- To assign a VRRP gateway priority (default priority value is 100):
Multilayer-Switch(config-if)# vrrp “group” priority “priority-value”
- To configure the VRRP advertisement interval on the master gateway:
Multilayer-Switch(config-if)# vrrp “group” timers advertise [msec] “interval”
- To configure a gateway to learn the VRRP advertisement interval from the master
gateway:
Multilayer-Switch(config-if)# vrrp “group” timers learn
- To disable preempting on a gateway (default is to preempt):
Multilayer-Switch(config-if)# no vrrp “group” preempt
- To change the preempt delay (default 0 seconds):
Multilayer-Switch(config-if)# vrrp “group” preempt [delay “seconds”]
- To use authentication for advertisements:
Multilayer-Switch(config-if)# vrrp “group” authentication “string”
- To assign a VRRP gateway a virtual gateway IP address:
Multilayer-Switch(config-if)# vrrp “group” ip “ip-address”
P a g e | 226
Example: - Configure VRRP failover between the multilayer switches shown in the
following figure:
- To configure Switch-C, use the following commands:
Switch-C(config)# interface vlan 50 Switch-C(config-if)# ip address 192.168.1.10 255.255.255.0 Switch-C(config-if)# vrrp 1 priority 200 Switch-C(config-if)# vrrp 1 ip address 192.168.1.1 Switch-C(config-if)# vrrp 1 authentication key-1
- To configure Switch-D, use the following commands:
Switch-D(config)# interface vlan 50 Switch-D(config-if)# ip address 192.168.1.20 255.255.255.0 Switch-D(config-if)# no vrrp 1 preempt Switch-D(config-if)# vrrp 1 ip address 192.168.1.1 Switch-D(config-if)# vrrp 1 authentication key-1
- Then, configure hosts to use (192.168.1.1) as their default gateway.
- To show information about the VRRP status on a multilayer switch, use the following
command:
Multilayer-Switch# show vrrp [brief]
P a g e | 227
- To show information about the VRRP status on Switch-C:
Switch-C# show vrrp brief
Interface Grp Prio Time Own Pre State Master addr Group addr
Vl50 1 200 3218 Y Master 192.168.1.10 192.168.1.1
- To show information about the VRRP status on Switch-D:
Switch-D# show vrrp brief
Interface Grp Prio Time Own Pre State Master addr Group addr
Vl50 1 100 3609 Backup 192.168.1.10 192.168.1.1
Packet Forwarding Review:
- When a host communicate with another host on its local subnet (VLAN), it generate
an Address Resolution Protocol (ARP) request, asking for the destination MAC
address, wait for the ARP reply, and then forward packets directly.
- If the other host is located on a different subnet, the host must rely on a gateway (a
multilayer switch or a router) to send and receive packets from that subnet.
- A host has a default gateway configured and identified by its IP address.
- That host sends all packets destined for different subnets than its own local one to the
gateway MAC address rather than the destination host MAC address.
- Therefore, the host first sends an ARP request to find the gateway’s MAC address,
then packets are sent to the gateway directly without having to look for ARP entries
for individual destinations.
P a g e | 228
Gateway Load Balancing Protocol (GLBP):
- You can accomplish load balancing by configuring only multiple HSRP or VRRP
groups to have multiple virtual gateway addresses, but more manual configuration is
needed so that hosts are divided among the virtual gateways addresses.
- This makes load balancing having a static behavior.
- The GLBP is a Cisco-proprietary protocol designed to overcome the limitations of the
load balancing done by the failover protocols (HSRP and VRRP).
- With GLBP, the load balancing concept is the same as with HSRP and VRRP, but the
terminology is different, and the behavior is much more dynamic and robust.
Note: - GLBP is available only for the Catalyst 6500 Supervisor 2 with IOS Release
12.2(14)SY4 or later, and Supervisor 720 with IOS Release 12.2(179)SX4
switch platforms.
- With load balancing, two or more gateway are assigned to the same GLBP group to
provide one virtual gateway IP address.
- All gateways in the same GLBP group can participate in forwarding, and traffic can be
balanced between gateways by forwarding a portion of the overall incoming traffic.
- The advantage is that not all of the clients has to be pointed toward different virtual
gateway addresses, they all can have the same default gateway address set to the
virtual gateway IP address of the GLBP group.
- Load balancing is provided completely through the use of virtual gateway MAC
addresses in ARP replies returned to hosts.
- As a host sends an ARP request looking for its gateway MAC address, GLBP sends
back an ARP reply with the virtual gateway MAC address of a selected gateway in the
GLBP group.
- The result is that all hosts uses the same default gateway IP address but have different
virtual MAC addresses for it.
P a g e | 229
Active Virtual Gateway (AVG):
- In the GLBP group, one gateway is elected as the Active Virtual Gateway (AVG).
- The gateway has the highest priority value is elected as the Active AVG, if tied, then
with the highest actual IP address in the GLBP group.
- The gateway with the second highest priority value is elected as the Standby AVG.
- The AVG answers all ARP requests asking for the virtual gateway MAC address.
- Which virtual gateway MAC address the AVG returns in the ARP reply depends on
which load balancing algorithm it is configured to use.
- In any event, the virtual gateway MAC address of one of the gateways in the GLBP
group is returned.
- The AVG also assigns the necessary virtual gateway MAC addresses to each of the
gateways participating in the GLBP group.
- Up to four gateways can be used in any GLBP group.
- Each of these gateways in the GLBP group is referred to as an Active Virtual
Forwarder (AVF), forwarding traffic received on its virtual MAC address.
Note: - The AVG can also be an AVF in the GLBP group.
- Any of the AVFs in the GLBP group can take two roles as AVF in case one AVF fails.
- This means that, one AVF can be assigned two virtual gateway MAC addresses at the
same time for a period of time.
- Hosts sending traffic to the virtual MAC address of the failed AVF will not notice this
failure, because another AVF assigned that Virtual MAC address of the failed AVF.
- To configure a GLBP priority for a gateway, use the following command:
Multilayer-Switch(config-if)# glbp “group” priority “priority-value”
- GLBP group numbers range from 0 to 1023.
- The gateway priority can range from 1 to 255 (default priority value is 100, and the
highest is 255).
- By default, GLBP does not allow a gateway to preempt and become the AVG if it has
a higher priority than the current AVG.
P a g e | 230
- To enable preemption and to set a time delay before preempting begins:
Multilayer-Switch(config-if)# glbp “group” preempt [delay minimum “seconds”]
- Gateways participating in GLBP must monitor each other’s presence so that another
gateway can assume the role a failed gateway.
- The AVG sends periodic hello messages to each of the other GLBP peers (AVFs).
- In addition, it expects to receive hello messages from each of them.
- By default, hello messages are sent every 3 seconds using the “hellotime” interval.
- If hello messages are not received from a GLBP peer with a “holdtime” interval (by
default 10 seconds), that GLBP peer is considered to be failed.
- To adjust the GLBP timers, use the following command on the AVG:
Multilayer-Switch(config-if)# glbp “group” timers [msec] “hellotime” [msec] “holdtime”
- Normally, timer values are configured in seconds without the “msec” keyword.
- If the “msec” keyword is added, then values are configured in milliseconds.
- The “hellotime” value can range from 1 to 60 seconds, or from 50 to 60,000 mseconds.
- The “holdtime” value must be greater than the “hellotime” and can be configured from
180 to 1800 seconds.
Note: - You always should make the “holdtime” at least three times greater than the
“hellotime” to give some tolerance to missed or delayed hellos from a
functional GLBP peer.
- The timer values can be configured only on the AVG which will advertise
the timer values it is using to every other peer to learn if they have already
been explicitly set.
Active Virtual Forwarder (AVF):
- Each gateway participating in the GLBP group is an AVF, if the AVG assigns it that
role, along with a virtual MAC address.
- The virtual MAC addresses assigned by the AVG always have the form
0007.B40X.XXYY.
P a g e | 231
- The 12-bits value denoted by X.XX represents two zero bits followed by 10-bits
GLBP group number.
- The 8-bits YY value is the virtual forwarder number.
- By default, GLBP uses the periodic hello messages to detect AVF failures.
- Each gateway within a GLBP group must send hellos to every other GLBP peer.
- Hellos also are expected from every other GLBP peer.
- For example, if hellos from the AVF are not received by the AVG until its holdtime
timer expires, the AVG assumes that the current AVF has failed.
- The AVG then assigns the failed AVF role to another AVF by assigning it additional
virtual MAC address of the failed AVF.
- The AVF now has two different virtual MAC addresses to support two AVF functions,
but it does not make much sense to continue doing that for a long period of time.
- The AVG has two timers that help resolve this condition:
- The “redirect” timer is used to determine when the AVG will stop using the old virtual
MAC address in ARP replies.
- When the “timeout” timer expires, the old virtual MAC address and the currently AVF
using it are flushed from the AVG.
- At this point, hosts will refresh the entry in their ARP caches to obtain the new virtual
MAC address.
- The “redirect” timer defaults to 600 seconds (10 minutes) and can have a value from 0
to 3600 seconds (1 hour).
- The “timeout” timer defaults to 14,400 seconds (4 hours) and can have a value from
700 to 64,800 seconds (18 hours).
- To adjust the redirect and timeout timers, use the following command on the AVG:
Multilayer-Switch(config-if)# glbp “group” timers redirect “seconds” timeout “seconds”
- GLBP can use a weighting function to determine if a gateway can become an AVF for
a virtual MAC address in a GLBP group and whether it can forward incoming traffic.
- Each gateway can have a weight value from 1 to 254 (default weight value is 100).
P a g e | 232
- As a specific interface connecting the gateway to the rest of the network goes down,
the weight value is decreased by a configured amount.
- GLBP uses thresholds to determine when a gateway can and cannot be an AVF.
- If the weight value falls below the “lower” threshold, the gateway must give up its
AVF role.
- When the weight rises above the “upper” threshold, the gateway can resume its AVF
role (by default, the upper threshold is the same as the weight value).
- If you want to make a dynamic weighting adjustment, GLBP must know which
interfaces to track and how to adjust the weight value.
- First, you must define an interface as a tracked object with an object number using the
following global configuration command:
Multilayer-Switch(config)# track “object-number” interface “type mod/num.” {line-protocol | ip routing}
- “object-number” Is an arbitrary index (1 to 500) that is used to define an interface
for weight adjustment.
- The condition that triggers a weight adjustment can be:
line-protocol The interface line protocol is up.
ip routing IP routing is enabled, the interface has IP address, and the interface
is up
Note: - The “ip routing” keyword sometimes referred to “ip” in the command.
- Next, you must define the weighting thresholds for the interface using the following
VLAN interface configuration command:
Multilayer-Switch(config-if)# glbp “group” weighting “weight-value” [lower “lower-value”] [upper “upper-value”]
- “weight-value” A value that can range from 1 to 254 (default value is 100).
- “lower-value” Define when the gateway cannot be an AVF (default value is 1).
- “upper-value” Define when the gateway can be an AVF (default value is 100).
P a g e | 233
- Finally, you must configure GLBP to know which objects (interfaces) to track so that
the weighting value can be adjusted using the following command:
Multilayer-Switch(config-if)# glbp “group” weighting track “object-number” [decrement “decrement-value”]
- When the tracked object fails, the weighting value is decremented by a “decrement-
value”.
- “decrement-value” A value that can range from 1 to 254 (default value is 10).
GLBP Load Balancing:
- The AVG establishes load balancing by handing out virtual gateway MAC addresses
to hosts in a deterministic fashion.
- Naturally, the AVG first must inform the AVFs in the GLBP group of the virtual MAC
address that each should use.
- Up to four virtual MAC addresses assigned in sequential order can be used in a GLBP
group.
- You can use one of the following load-balancing methods in a GLBP group:
a) Round robin:
- Each new ARP request for the virtual gateway MAC address receives the next
available virtual MAC address in reply.
- Traffic load is distributed evenly across all gateways participating as an AVF in the
GLBP group, assuming each of the hosts sends and receives the same amount of
traffic.
Note: - Round robin is the default load balancing GLBP method.
b) Weighted:
- The GLBP group interface’s weighting value determines the proportion of traffic that
should be sent to that AVF.
P a g e | 234
- A higher weighting results in more frequent ARP replies containing the virtual MAC
address of that gateway.
- If interface tracking is not configured, the “weighting-value” configured is used to set
the relative proportions among AVFs.
c) Host dependent:
- Each host that generates an ARP request for the virtual gateway address always
receives the same virtual MAC address in reply.
- This method is used if hosts have a need for a consistent virtual gateway MAC
address.
- To configure the GLBP load balancing method on the AVG, use the following
command:
Multilayer-Switch(config-if)# glbp “group” load-balancing [round-robin | weighted | host-dependent]
GLBP Gateway Addressing:
- To enable GLBP, you must assign a virtual gateway IP address to the GLBP group by
using the following command:
Multilayer-Switch(config-if)# glbp “group” ip “ip-address”
P a g e | 235
Example: - Consider the following network:
Multilayer Switches in a GLBP Group
- The figure shows a network in which three multilayer switches are participating in a
common GLBP group (group 1).
- Switch-A is elected as the AVG (highest priority 200), and configured with a virtual
gateway IP address of (192.168.1.1).
- Switch-B is elected as the standby AVG (second highest priority 150).
- The AVG has identified itself, Switch-B, and Switch-C as AVFs for the GLBP group.
- Round robin is the used load balancing method.
- To configure Switch-A, use the following commands:
Switch-A(config)# interface vlan 50 Switch-A(config)# ip address 192.168.1.10 255.255.255.0 Switch-A(config)# glbp 1 priority 200 Switch-A(config)# glbp 1 preempt Switch-A(config)# glbp 1 ip 192.168.1.1
P a g e | 236
- To configure Switch-Band Switch-C, use the following commands:
Switch-B(config)# interface vlan 50 Switch-B(config-if)# ip address 192.168.1.20 255.255.255.0 Switch-B(config-if)# glbp 1 priority 150 Switch-B(config-if)# glbp 1 preempt Switch-B(config-if)# glbp 1 ip 192.168.1.1
Switch-C(config)# interface vlan 50 Switch-C(config-if)# ip address 192.168.1.30 255.255.255.0 Switch-C(config-if)# glbp 1 ip 192.168.1.1
- You can verify the GLBP operation using the following command:
Multilayer-Switch# show glbp [“group”] [brief]
- To verify the GLBP operation on Switch-A, Switch-B, and Switch-C:
Switch-A# show glbp brief
Interface Grp Fwd Pri State Address Active router Standby router
Vl50 1 - 200 Active 192.168.1.1 Local 192.168.1.20
Vl50 1 1 7 Active 0007.b400.0101 Local -
Vl50 1 2 7 Listen 0007.b400.0102 192.168.1.20 -
Vl50 1 3 7 Listen 0007.b400.0103 192.168.1.30 -
Switch-B# show glbp brief
Interface Grp Fwd Pri State Address Active router Standby router
Vl50 1 - 150 Standby 192.168.1.1 192.168.1.10 Local
Vl50 1 1 7 Listen 0007.b400.0101 192.168.1.10 -
Vl50 1 2 7 Active 0007.b400.0102 Local -
Vl50 1 3 7 Listen 0007.b400.0103 192.168.1.30 -
Switch-C# show glbp brief
Interface Grp Fwd Pri State Address Active router Standby router
Vl50 1 - 100 Listen 192.168.1.1 192.168.1.10 192.168.1.20
Vl50 1 1 7 Listen 0007.b400.0101 192.168.1.10 -
Vl50 1 2 7 Listen 0007.b400.0102 192.168.1.20 -
Vl50 1 3 7 Active 0007.b400.0103 Local -
P a g e | 237
- Switch-A is shown to be the active AVG because it has a dash (-) in the Fwd column
and is in the Active state.
- It also is acting as AVF1.
- Because the GLBP group has three gateways, there are three virtual forwarders and
virtual MAC addresses.
- Switch-A is in the Listen state for AVF2 and AVF3, waiting to be given an active role
in case one of those AVFs fails.
- Switch-B is the Standby AVG, waiting to take over in case the active AVG fails.
- Switch-B is the AVF2 and is in the Listen state for AVF1 and AVF3, waiting to be
given an active role in case one of those AVFs fails.
- Finally, Switch-C has the lowest GLBP priority, so it stays in the Listen state, waiting
for the active or standby AVG to fail.
- Switch-C is also the AVF3 and is in the Listen state for AVF1 and AVF2, waiting to
be given an active role in case of one of those AVFs fails.
- The following figure shows the same network but this time Switch has failed:
P a g e | 238
- This figure shows how GLBP reacts to a component failure (Switch-A).
- Before Switch-A fails, it was the active AVG because of its highest GLBP priority.
- After Switch-A fails, Switch-B become the Active AVG, answering ARP requests
with the appropriate virtual gateway MAC address for gateway 192.168.1.1.
- Switch-A also had been acting as an AVF, participating in the gateway load balancing.
- Switch-B picks up its responsibility, by using Switch-A virtual MAC address
0007.B400.0101 along with its own virtual MAC address 0007.B400.0102.
- Therefore, any hosts that still caches the virtual MAC of the failed Switch-A, still can
reach a live gateway or AVF.
- To show a detailed information about the GLBP status, use the following command on
the AVG:
Multilayer-Switch# show glbp
Supervisor and Route Processor Redundancy:
- The gateway high availability protocols (HSRP, VRRP, and GLBP) can provide high
availability only for the default gateway IP address used by hosts.
- In case of a failed switching engine or routing engine of a gateway, packets will not
get routed and interfaces will go down.
- Some Cisco multilayer switches have the capability to provide failover high
availability (redundancy) for the supervisor module itself.
- This is accomplished by having redundant hardware in place within a multilayer
switch chassis, ready to take over during a failure.
- Also, if the switch power supply (with a single power cord) will fail (or the power cord
is accidently unplugged), the whole switch will fail.
- Some switch platforms can have multiple power supplies, if one power supply fails,
another immediately takes over the load.
P a g e | 239
Redundant Switch Supervisors:
- Modular switch platforms such as the Catalyst 4500R and 6500 can accept two
supervisor modules installed in a single chassis.
- The first supervisor module to successfully boot becomes the “active” supervisor for
the chassis.
- The other supervisor module remains in a “standby” role, waiting for the active
supervisor to fail.
- The active supervisor module is always allowed to boot up and become fully
initialized and operational.
- All switch functions are provided by the active supervisor module.
- However, the standby supervisor is allowed to boot up and initialize only to a certain
level.
- When the active supervisor module fails, the standby supervisor module can proceed
to initialize any remaining functions and take over the active role.
- Redundant supervisor modules can be configured in several failover modes.
- The failover mode affects how the two supervisors handshake and synchronize
information.
- In addition, the mode limits the standby supervisor’s state of readiness.
- The more ready the standby module is allowed to become, the less initialization and
failover time will be required.
- You can use the following failover modes on Catalyst switches:
a) Route Processor Redundancy (RPR):
- The standby supervisor module is only partially booted and initialized.
- When the active supervisor module fails, the standby supervisor module must reload
every other module in the switch and then initialize all the supervisor functions.
P a g e | 240
b) Route Processor Redundancy Plus (RPR+):
- The standby supervisor module is booted, allowing the supervisor and route engine to
initialize.
- No Layer 2 or Layer 3 functions are started.
- When the active supervisor module fails, the standby supervisor module finishes
initializing without reloading other switch modules.
- This allows switch ports to retain their states.
c) Stateful Switchover (SSO):
- The standby supervisor module is fully booted and initialized.
- Both the startup and running configuration contents are synchronized between the
active and standby supervisor modules.
- Layer 2 information is maintained on both supervisor modules.
- The state of the switch interfaces is also maintained on both supervisor modules so that
links do not flap during a failover.
- In addition to the supervisor modules failover using either RPR, RPR+, or SSO, you
might see the following modes per supervisor:
a) Single-router mode (SRM):
- Two route processors integrated into each supervisor module are being used, but only
one of them is active at any time (failover high availability).
b) Dual-router mode (DRM):
- Two route processors integrated into each supervisor module are being used, but both
route processors are active at all times (load balanced high availability).
Note: - SRM is not compatible with RPR or RPR+.
- SRM is compatible with SSO.
P a g e | 241
Configuring the Redundancy Mode:
- The failover modes can be configured on the following supported multilayer switch
platforms as shown in the following table:
Redundancy
Mode Supported Platforms Failover Time
RPR - Catalyst 6500 Supervisors 2 and 720.
- Catalyst 4500R Supervisors IV and V. Good (>2 minutes)
RPR+ - Catalyst 6500 Supervisors 2 and 720. Better (>3 seconds)
SSO - Catalyst 6500 Supervisor 720.
- Catalyst 4500R Supervisors IV and V Best (>1 second)
- The following figure shows how the supervisor failover modes compare with respect
to the functions they perform:
Supervisor Bootstrap Image Loaded
Supervisor Bootstrap Image
Loaded
Supervisor Bootstrap Image
Loaded
IOS Image Loaded IOS Image Loaded IOS Image Loaded
Sync Startup-Config Sync Startup-Config Sync Startup-
Config
Supervisor Diagnostics Supervisor Diagnostics
Supervisor Diagnostics
All Switch Modules Reloaded
Route Engine Initialized
Route Engine Initialized
Route Engine Initialized
Layer 2 Protocols Initialized
Layer 2 Protocols Initialized
Layer 2 Protocols Initialized
FIB Table
Synchronized
Layer 3 Protocols Initialized
Layer 3 Protocols Initialized
Layer 3 Protocols Initialized
Routing Protocols Converge
Routing Protocols Converge
Routing Protocols Converge
FIB Table Flushed and Re-Created
FIB Table Flushed and Re-Created
FIB Table Flushed and Re-Created
RPR RPR+ SSO
Standby Supervisor Readiness as a Function of Redundancy Mode.
P a g e | 242
- The shaded functions are performed as the standby supervisor initializes and then
waits for the active supervisor module to fail.
- When a failure is detected, the remaining un-shaded functions must be performed in
sequence before the standby supervisor can become fully active.
- Notice how the redundancy modes get progressively more initialized and ready to
become active.
- To configure the supervisor failover (redundancy) mode, use the following commands:
Multilayer-Switch(config)# redundancy Multilayer-Switch(config-red)# mode {rpr | rpr-plus | sso}
Note: - If you are configuring failover (redundancy) between supervisors for the first
time on the multilayer switch, you must configure the previous commands
on both supervisor modules.
- When the failover mode is enabled, you will make all configuration changes
on the active supervisor only.
- The running configuration is synchronized automatically from the active to
the standby supervisor module.
Note: - If you configure RPR+ using the “rpr-plus” keyword, the supervisor
attempts to bring up RPR+ with its peer module.
- The IOS images must be of exactly the same release before RPR+ will work.
- If the images differ, the supervisor module automatically falls back to RPR
mode instead.
- To verify the failover (redundancy) mode and state of the supervisor modules, use the
following command:
Multilayer-Switch# show redundancy states
- The following output shows that the switch is using RPR+ and that the second
supervisor module (denoted by unit ID 2 and “my state”) holds the active role.
- The other supervisor module is in standby state and is HOT, meaning that it has
initialized as far as the redundancy mode will allow.
P a g e | 243
Multilayer-Switch# show redundancy states my state = 13 -ACTIVE peer state = 8 -STANDBY HOT Mode = Duplex Unit = Secondary Unit ID = 2 Redundancy Mode (Operational) = Route Processor Redundancy Plus Redundancy Mode (Configured) = Route Processor Redundancy Plus Split Mode = Disabled Manual Swact = Enabled Communications = Up client count = 11 client_notification_TMR = 30000 milliseconds keep_alive TMR = 9000 milliseconds keep_alive count = 1 keep_alive threshold = 18 RF debug mask = 0x0
Configuring Supervisor Synchronization:
- By default, the active supervisor synchronizes its startup configuration and
configuration register values with the standby supervisor.
- You also can specify other information that should be synchronized.
- First, use the following commands to enter the main-CPU configuration mode:
Multilayer-Switch(config)# redundancy Multilayer-Switch(config-red)# main-CPU
- The, use the following command to specify the information that will be synchronized:
Multilayer-Switch(config-r-mc)# auto-sync {startup-config | config-register | bootvar}
Note: - You can repeat the command if you need to use more than one of the
keywords.
- To return to the default, use the following command:
Multilayer-Switch(config-r-mc)# auto-sync standard
P a g e | 244
Nonstop Forwarding (NSF):
- You can enable a redundancy feature along with the Stateful Switchover (SSO) on the
Catalyst 4500R ad 6500 (supervisor 720 only).
- NSF Is an interactive method that focuses on quickly rebuilding the Routing
Information Base (RIB) table after a supervisor switchover.
- The RIB is used to generate the FIB table for CEF, which is downloaded to any switch
modules or hardware that can perform CEF.
- Instead of waiting on any configured Layer 3 routing protocols to converge and
rebuild the FIB, a multilayer switch can use NSF to get assistance from other NSF-
aware neighbors.
- The neighbors can then provide routing information to the standby supervisor,
allowing the routing tables to be assembled quickly.
- In a nutshell, the Cisco-proprietary NSF functions must be built in to the routing
protocols and the multilayer switch that will provide assistance.
- NSF is supported by the following routing protocols:
Enhanced Interior Gateway Routing Protocol (EIGRP).
Open Shortest Path First (OSPF).
- NSF is available on the Catalyst 6500 Supervisor 720 (with the integrated MSFC3)
and on the Catalyst 4500R Supervisor III, IV, and V running IOS Release
12.2(20)EWA or later.
- To configure NSF, you must add the following commands to the routing protocols
configured on the multilayer switch:
If EIGRP is the routing protocol configured, use the following commands:
P a g e | 245
Multilayer-Switch(config)# router eigrp “asn” Multilayer-Switch(config-router)# nsf
If OSPF is the routing protocol configured, use the following commands:
Multilayer-Switch(config)# router ospf “process-id” Multilayer-Switch(config-router)# nsf
Note: - The routing protocols (EIGRP, OSPF, and BGP) are fully covered in The
Road (Route) book in details.
P a g e | 246
Chapter 13 IP Telephony
IP Phone Power Sources:
- The IP Phone is like any other node on the network, it must have power to operate.
- The IP Phone power can come from two sources:
External AC adapter.
Power over Ethernet (PoE).
a) External AC Adapter:
Power offered by an External AC Adapter
- The external AC adapter plugs into a normal AC wall outlet and provides 48V DC to
the IP Phone.
- These adapters, commonly called “wall warts” are handy if no other power source is
available.
- However, if there is no available outlet near the phone, or a power failure occurs to the
room outlet where the adapter is located, the IP Phone will not work or fail
respectively.
P a g e | 247
b) Power over Ethernet (PoE):
Power over Ethernet (PoE)
- A more elegant solution is available as “Inline Power” or “Power over Ethernet”.
- Here, the same 48V DC supply is provided to an IP Phone through the switch port
over the same copper twisted-pair network cable that is used for Ethernet connectivity.
- The DC power’s source is the Catalyst switch itself.
- No other power source is needed, unless an external AC adapter is required as a
redundant source.
- PoE can be offered to an IP Phone or a wireless access point.
- PoE is not limited to Cisco IP Phones, any device that can request and use PoE in a
compatible manner can be used.
- Otherwise, if a non-powered device such as a normal PC is plugged into the same
switch port, the switch will not offer power to it.
Power over Ethernet (PoE) Methods:
- A Catalyst switch can offer PoE ports only if it is designed to do so.
- A Catalyst switch must have one or more power supplies that are rated for the
additional load that will be offered to the connected devices.
- PoE is available on many platforms, including the Catalyst 2900, Catalyst 3750,
Catalyst 4500, and Catalyst 6500.
- Two methods can provide PoE to the connected devices:
IEEE 802.3af A standard-based method that offers vendor interoperability.
Cisco Inline Power (ILP) A Cisco-proprietary method.
P a g e | 248
- The switch always keeps the power disabled when a switch port is down.
- However, the switch must continually try to detect whether a powered device is
connected to a port.
- If a powered device is connected, the switch must begin providing power so that the
device can initialize and become operational, only then will the Ethernet link be
established.
- Because there are two PoE methods, a Catalyst switch tries both methods to detect a
powered device.
a) IEEE 802.3af method:
- For IEEE 802.3af, the switch begins by supplying a small voltage across the transmit
and receive pairs of the copper twisted-pair Ethernet cable connection.
- It then can measure the resistance across the pairs to detect whether current is being
drown by the device.
- If 25k ohm resistance is measured, a power device is indeed present.
- The switch can also apply several predetermined voltages to test for corresponding
resistance values.
- These values are applied by the powered device to indicate which of the five IEEE
802.3af power classes it belongs to.
- Knowing this, the switch can begin allocating the appropriate maximum power needed
by the device.
- The following table defines the IEEE 802.3af power classes:
Power Class Maximum Power Offered at 48V DC Notes
0 15.4 watt Default Class
1 4 watt Optional Class
2 7 watt Optional Class
3 15.4 watt Optional Class
4 Up to 50 watt Optional Class
- The default power class 0 is used if either the switch or the powered device does not
support or does not attempt the optional power class discovery.
P a g e | 249
- The power class 4 is available under IEEE 802.3at and called PoE plus, as up to 50
watt per connected device.
- Some Cisco Catalyst switches (such as the Catalyst 3750-E series) offers up to 20 watt
of “enhanced PoE” power.
b) Cisco Inline Power (ILP):
- Cisco inline power device discovery takes a totally different approach than IEEE
802.3af.
- Instead of offering voltage and checking resistance, the switch sends out a 340 kHz
test tone on the transmit pair of the copper twisted-pair Ethernet cable connection.
- A tone is transmitted instead of DC power because the switch first must detect an
inline power-capable device before offering it power.
- A powered device such as a Cisco IP Phone loops the transmit and receive pairs of its
Ethernet connection while it is powered off.
- When it is connected to an inline power switch port, the switch can “hear” its test tone
looped back.
- Then, it safely assumes that a powered device is present, and power can be applied to
it.
Supplying PoE to a Device:
- A switch first offers a default power allocation to the powered device.
- Power can be supplied in two methods:
IEEE 802.3af Power can be provided over data pairs 2 and 3 (RJ-45 pins 1,2 an
3,6) or over pairs 1 and 4 (RJ-45 pins 4,5 and 7,8) at 48V DC.
Cisco Inline Power (ILP) Inline power is provided over data pairs 2 and 3 (RJ-
45 pins 1,2 and 3,6) at 48V DC.
- For IEEE 802.3af, the power budget can be changed by detecting the device’s power
class.
P a g e | 250
Note: - The power budget offered to the device can be changed from the default to a
more appropriate value.
- This can help prevent the switch from wasting its total power budget on
devices that use far less power than the per-port default.
- For Cisco Inline Power (ILP), the switch can attempt a Cisco Discovery Protocol
(CDP) message exchange with the device.
- If CDP information is returned, the switch can discover the device type (for example,
Cisco IP Phone) and the device’s actual power requirements.
- The switch then can reduce the inline power to the amount requested by the device.
Configuring PoE:
- Configuring Cisco Inline Power is simple.
- Each switch port can automatically detect the presence of an inline power-capable
device before applying power, or the feature can be disabled to ensure that the port can
never detect or offer inline power.
- To change this behavior, use the following interface configuration command:
Switch(config-if)# power inline {auto [max “milli-watts”] | static [max “milli-watts”] | never}
- “auto” (Default) Every switch port is configured for “auto” mode, where the
device and power budget automatically is discovered.
Note: - The default maximum offered power per port is 15.4 watt.
- “max” You can change the maximum offered power by adding this keyword
followed by the maximum value offered (a value that range from 4000 to
15400).
- “static” - You can configure a static offered power by a switch port to a powered
device, if the powered device cannot interact with either of the powered
device discovery methods.
- Again, you can set the maximum power offered to the device using the
“max” keyword and a value in milli-watts (Otherwise, 15.4 watt is used).
- “never” Is used to disable PoE on a switch port.
P a g e | 251
Verifying PoE:
- To show the PoE status for a switch port, use the following command:
Switch# show power inline [“type mod/num.”]
- The following example shows the PoE status for switch ports:
Switch# show power inline
Available: 370.0(w) Used: 39.0(w) Remaining: 331.0(w)
Interface Admin Oper Power Device Class Max
(Watts)
------------ -------- ------- --------- -------------------------- ------- ------
Fa0/1 auto off 6.5 AIR-AP1231G-A-K9 n/a 15.4
Fa0/2 auto off 6.3 IP Phone 7940 n/a 15.4
Fa0/3 auto off 6.3 IP Phone 7940 n/a 15.4
Fa0/4 auto off 15.4 Ieee PD 0 15.4
Fa0/5 auto off 4.5 Ieee PD 1 15.4
Fa0/6 static off 15.4 n/a n/a 15.4
Fa0/7 auto off 0.0 n/a n/a 15.4
!Lines are omitted for brevity
Fa0/24 auto off 0.0 n/a n/a 15.4
- As shown, the total “Available” power budget offered by the switch is 370 watt.
- The “Used” power is the summation of powers used by the connected devices.
- One static power is configured for a port but no available device is connected.
Note: - If the “class” is shown as “n/a”, Cisco ILP has been used to supply power.
- Otherwise, the IEEE 802.3af power class (0 through 4) is used.
Voice VLANs:
- An IP Phone and a user’s PC can be connected to a single access switch port.
- The IP Phone can control some aspects of how traffic (voice and data) are presented to
the switch.
P a g e | 252
- IP Phones contains an internal three-ports switch, connecting to the upstream switch,
the IP Phone internally, and the PC as shown in the following figure:
Internal IP Phone Connectivity
- The Switch access port has two sources of traffic:
The IP Phone voice traffic.
The PC data traffic.
- The link between the IP Phone and the switch can be configured to use an access link,
where the voice and data traffic can pass on the same link but with two different
VLANs (Voice VLAN and Data VLAN).
Voice VLAN Configuration:
- The switch instructs the IP Phone to learn the tagging mode configured on the switch.
- The voice traffic must be carried over a unique voice VLAN (i.e. different VLAN than
the one used for the data VLAN) with a Voice VLAN ID (VVID).
- This separation between voice and data traffic is done to be able to apply Quality of
Service (QoS) on the voice traffic as will explained later in this chapter.
- To configure the access switch port with a voice VLAN, use the following interface
configuration command:
Switch(config-if)# switchport voice vlan {“vlan-id” | dot1p | untagged | none}
P a g e | 253
- “vlan-id” The voice traffic is tagged with a VLAN ID.
- “dot1p” The voice traffic is tagged with a VLAN ID 0.
- “untagged” The voice traffic is untagged.
- “none” (Default) The voice traffic is untagged.
- The internal three-ports switch used inside the IP Phone learns the tagging mode from
the upstream switch, then that internal switch can either tag the voice traffic with a
voice VLAN ID, voice VLAN 0, or send it untagged (native) according to what it
learned from the upstream switch port configuration.
- If the voice traffic is untagged, he switch will not be able to differentiate between the
voice and data traffic, therefore, no QoS can be applied to the voice traffic in this case.
- It is recommended to tag the voice traffic with a VLAN ID (VVID) or VLAN 0.
- Once the voice traffic is tagged by the internal three-ports switch inside the IP Phone,
a special 802.1Q trunk link is performed to carry both the voice tagged traffic and the
data untagged traffic as shown in the following figure:
Special 802.1Q Trunk for the IP Phone Voice Traffic
- The native VLAN, means that this VLAN traffic will not be tagged by the switch with
any VLAN ID.
- The IP Phone internal three-ports switch tag the voice traffic as learned from the
upstream switch, and the upstream switch tag the data traffic when forwarding data
over trunk links.
- The switch port access VLAN is used to tag the data traffic with an access VLAN ID.
- The switch port voice VLAN is used to instruct the IP Phone internal switch to tag the
voice traffic with any of the VLAN cases configured on the command.
- When the IP Phone is removed, the special 802.1Q trunk is no longer enabled, and the
PC still operating and sending traffic over the access link.
P a g e | 254
Voice VLAN Verification:
- To verify a voice VLAN configuration on a switch port, use the following command:
Switch# show interface “type mod/num.” switchport
Example: - Consider the following small network:
Requirements:
- Configure Switch-A to provide auto PoE to the IP Phones (assuming it is disabled).
- Configure data VLAN 10 and 20.
- Configure voice VLAN 50.
- To configure Switch-A, use the following commands:
Switch-A(config)# interface fastEthernet 0/1 Switch-A(config-if)# switchport mode access Switch-A(config-if)# switchport access vlan 10 Switch-A(config-if)# switchport voice vlan 50 Switch-A(config-if)# power inline auto Switch-A(config)# interface fastEthernet 0/2 Switch-A(config-if)# switchport mode access Switch-A(config-if)# switchport access vlan 20 Switch-A(config-if)# switchport voice vlan 50 Switch-A(config-if)# power inline auto
P a g e | 255
- To verify the data and voice VLANs on FastEthernet 0/1:
Switch-A# show interface fastEthernet 0/1 switchport
Name: Fa0/1
Switchport: Enabled
Administrative Mode: static access
Operational Mode: static access
Administrative Trunking Encapsulation: dot1q
Operational Trunking Encapsulation: native
Negotiation of Trunking: Off
Access Mode VLAN: 10 (VLAN-10)
Trunking Native Mode VLAN: 1 (default)
Voice VLAN: 50
! Lines are omitted for brevity
Voice QoS:
- Quality of Service (QoS) Is the overall method used in a network to prioritize the
important or time-critical traffic.
- On a quiet network (not congested), a switch generally can forward frames as soon as
they are received.
- However, if the network is congested, frames cannot always be delivered in a timely
manner.
- Traditionally, network congestion has been handled by increasing link bandwidths and
switching hardware performance, but this does not address a lot to how one type of
traffic can be preferred or delivered ahead of another.
- Voice traffic must be preferred over data traffic because voice is a real time
application, meaning it should be delivered as fast as possible.
- The most important aspect of transporting voice traffic across a switched campus
network is maintaining the proper QoS level.
- Voice traffic must be delivered in the most timely fashion possible, with little delay,
little jitter, and little loss.
P a g e | 256
- Three basic things can happen to frames as they are sent from one host to another
across a network:
Delay.
Jitter.
Loss.
a) Delay:
- As a frame is sent from one host to another, its delivery is delayed by some amount of
time.
- This delay results from the time required to send frames serially across a wire, the time
required for a switch or a router to perform table lookups or make decisions.
- The total delay from start to finish is called the “latency”.
b) Jitter:
- Some applications involve the delivery of a stream of related traffic (such as voice).
- As these frames are delivered, variations can occur in the amount of delay so that all
frames do not arrive at predictable times.
- The variation in delay is called “jitter”.
- Voice stream is susceptible to jitter, which can lead to choppy sounds.
c) Loss:
- Frames that enter a congested or error-pane port of the network are simply dropped
without delivery.
- Some amount of frame loss is acceptable and recoverable by applications that use
reliable, connection-oriented protocol such as TCP.
- Other application protocols cannot recover dropped frames, which mean there is a data
loss.
- QoS works toward making policies to improve frame delivery from a sender to a
receiver.
P a g e | 257
- To address these conditions, a network can apply two types of QoS:
Integrated Services (IntServ) Model.
Differentiated Services (DiffServ) Model.
- A network that just forwards frames in the order they were received has no real QoS.
- Switches and routers then make their “best effort” to deliver frames as quickly as
possible, with no regard for the type of traffic or the need for priority service.
- To understand how QoS operates in a network, consider a fire truck trying to quickly
work its way through a crowded city roads.
- The lights are flashing and the siren is sounding to signal that this is a “priority”
vehicle needing to get through ahead of every one else.
- The priority vehicle does not need to obey normal traffic rules.
- However, the best effort delivery says that the fire trunk must stay within the normal
flow of traffic, it may arrive on time or too late depending on the road status.
a) Integrated Services (IntServ) Model:
- One approach to QoS is the IntServ model.
- The basic idea is to pre-arrange a path for priority traffic along the complete path, from
a source to a destination.
- Beginning with the Resource Reservation Protocol (RSVP) that was developed as the
mechanism for scheduling and reserving adequate path bandwidth for an application.
- The source application itself is involved by requesting QoS parameters through RSVP.
- Each network device along the way must check to see whether it can support the
request.
- When a complete path meeting the minimum requirements is made, the source is
signaled with a confirmation, then the source application can begin using the path.
- Applying the fire truck example to the IntServ model, the fire truck will contact the
nearest police station at the nearest intersection before it leave the firehouse.
P a g e | 258
- Police stations at each intersection will contact each other in turn to announce that the
fire truck will come and to assess the traffic condition.
- The police will reserve a special lane so that the fire truck can move at full speed
toward the destination, regardless of the presence of the other traffic.
b) Differentiated Services (DiffServ) Model:
- The DiffServ model permits each network device to handle frames on an individual
basis.
- Each switch or router can be configured with QoS policies to follow, and forwarding
decisions are made accordingly.
- DiffServ requires no advance reservations, QoS is handled dynamically in a distributed
fashion.
- In other words, IntServ applies QoS on a per-flow basis, but DiffServ applies QoS on a
per-hop basis to a whole group of similar flows.
- DiffServ also bases its QoS decisions on the information contained on each frame and
packet headers.
- Continuing with the fire truck example, here the police stations are located at every
intersection as before, but none of them knows that a fire truck is coming until they
see the lights or hear the siren.
- At each police station, a decision is made as how to handle the coming fire truck.
- Other traffic can be held back, if needed, so that the fire truck can go right through.
- Voice traffic focuses almost entirely on the DiffServ model.
DiffServ QoS:
- DiffServ is a per-hop behavior, with each switch or router inspecting each frame or
packet header to decide “how” to make a forwarding decision.
- All the information needed for this decision is carried along with each frame or packet
in the header, and it presents some flags, classifications, or markings that can be used
to make a forwarding decision based on QoS policies that are configured into each
switch or router along the path.
P a g e | 259
a) Layer 2 QoS Classification:
- Layer 2 frames themselves have no mechanism to indicate the priority or importance
of their contents, one frame looks just as important as another.
- Therefore, a layer 2 switch can forward frames only according to a best-effort delivery.
- When frames are carried from switch to switch over trunk links, an opportunity for
classification occurs.
- recall that a trunk is used to carry frames from multiple VLANs between switches.
- The trunk does this by encapsulating the frames and adding a tag indicating the source
VLAN number.
- The encapsulation also includes a field that can mark the Class of Service (CoS) of
each frame, and this can be used at switch boundaries to make some QoS decisions.
- After the trunk de-encapsulate the added header to the frame at the far-end switch, the
Cos information is removed and lost.
- The two trunking protocols encapsulates CoS differently as follows:
IEEE 802.1Q - Each frame is tagged with a 12-bit VLAN-ID and a User field.
- The User field contains three 802.1p priority bits that indicate
the frame CoS, a unitless value ranging from 0 (lowest-
priority delivery) to 7 (highest priority delivery).
- Frames from the native VLAN are not tagged (i.e. no VLAN
ID or User field), so they receive a default CoS that is
configured on the receiving switch.
Inter-Switch Link (ISL) - Each frame is tagged with a 15-bit VLAN ID and a
4-bit User field next to the frame Type field.
- The lower 3 bits of the User field are used as a CoS
value.
- Although ISL is not a standard-based protocol,
Catalyst switches make CoS seamless by copying
the 802.1p CoS bits from an 802.1Q trunk into the
User CoS bits of an ISL trunk, this allows CoS
information to propagate along trunks of differing
encapsulation.
P a g e | 260
b) Layer 3 QoS Classification:
- From the beginning, IP packets have always has a type of service (ToS) byte that can
be used to mark packets.
- This byte is divided into a 3-bit IP Precedence value and a 4-bit ToS value.
- Only the 3-bit of IP Precedence are used to describe the per-hop QoS behavior, and
this offers a limited mechanism for QoS.
- The DiffServ model keeps the existing IP ToS byte but uses it differently.
- This byte is called the Differentiated Services (DS) byte with a different format.
- The 6-bit used value is known as the Differentiated Service Codepoint (DSCP) and is
the one value that is examined by any DiffServ network device.
Note: - Do not be confused by the dual QoS terminology, the ToS and DS bytes are
the same, occupying the same location in the IP header.
- The DSCP bits have arranged to be backward compatible with the IP Precedence bits
so that a non-DiffServ device still can interpret some QoS information.
- The DSCP value is divided into a 3-bit Class Selector and a 3-bit Drop Precedence
value.
P a g e | 261
- The following table shows how the IP Precedence , DSCP per-hop behavior, and
DSCP Codepoint names and numbers relate:
IP Precedence (3-bits) DSCP (6-bits)
Name Bits Per-Hop
Behavior
Class
Selector
Drop
Precedence
Codepoint
Name
DSCP bits
(Decimal)
Routine 000 Default 000 (0) 000 Default 000 000 (0)
Priority 001 AF 001 (1)
1: Low (010)
2: Medium
3: High
AF11
AF12
AF13
001 010 (10)
001 100 (12)
001 110 (14)
Immediate 010 AF 010 (2)
1: Low
2: Medium
3: High
AF21
AF22
AF23
010 010 (18)
010 100 (12)
010 110 (14)
Flash 011 AF 011 (3)
1: Low
2: Medium
3: High
AF31
AF32
AF33
011 010 (26)
011 100 (28)
011 110 (30)
Flash Override 100 AF 100 (4)
1: Low
2: Medium
3: High
AF41
AF42
AF43
100 010 (34)
100 100 (36)
100 110 (38)
Critical 101 EF 101 (5)
1: Low
2: Medium
3: High
EF51
EF52
EF53
101 010 (42)
101 100 (44)
101 110 (46)
Internetwork
Control 110 110 (6) (48-55)
Network
Control 111 111 (7) (56-63)
- The three class selector bits (DS5, DS4, and DS3) classify packets into one of eight
classes:
Class 0 (Default) - Offers only best-effort forwarding (no QoS applied).
P a g e | 262
Class 1-4 - Are called the Assured Forwarding (AF) service levels.
- Higher AF class numbers indicate the presence of higher priority
traffic.
- Packets in the AF classes can be dropped, if necessary, with the
lower-class numbers the most likely to be dropped.
- For example, packets with AF Class 4 will be delivered in
preference to packets with AF Class 3.
Class 5 - Is known as Expedited Forwarding (EF), with those packets given
premium service.
Class 6 and 7 - Are called the internetwork control and network control
respectively, and are set aside for network control traffic.
- Usually, switches and routers use these classes for things such
as the STP and routing protocols.
- This ensures timely delivery of the packets that keep the
network stable and operational.
- Each class represented in the DSCP has also three levels of drop precedence (DS2,
DS1, and DS0) (DS0 is always 0):
(1) Low (010).
(2) Medium (100).
(3) High (110).
- Within a class, packets marked with a higher drop precedence have the potential for
being dropped before those with a lower value.
- In other words, a lower drop precedence value, gives better service.
- This gives finer granularity to the decision of what packets to drop when necessary.
- The DSCP value can be given as a Codepoint name, with the class selector providing
the two letters and a number followed by the drop precedence number.
P a g e | 263
- For example, Class AF Level 2 with drop precedence 1 (low) is written as AF21.
- The DSCP binary value is (010 010) but commonly is given as a decimal value.
- For AF21, the decimal value is 18.
- You should try to remember a few Codepoint names and numbers.
- Some common values are EF (46) and most of the classes with low drop precedence:
AF41 (34).
AF31 (26).
AF21 (18).
AF11 (10).
- Naturally, the default DSCP has no name (0).
Implementing Voice QoS:
- IP packets carry a ToS or DSCP value within their headers as they travel around a
network.
- Frames on a trunk also can have CoS values associated with them.
- A network device (a Layer 2 switch or multilayer switch) then can decide whether to
trust the CoS, IP Precedence, or DSCP values.
- If the network device trust any of these values, the values are carried over and used to
make QoS decisions.
- If the QoS values are not trusted, they can be overwritten with a certain value.
- This prevents non-priority users in the network from falsely setting the ToS or DSCP
values of their packets to inflated levels so that they receive priority service.
- Every network device must decide whether to trust incoming QoS information.
- Generally, an organization should be able to trust QoS information anywhere inside its
own network.
- At the boundary with another organization or service provider, QoS typically should
not be trusted.
- The QoS values produced by the end users should not be trusted until the network can
verify or overwrite them.
P a g e | 264
- The perimeter formed by the network devices that does not trust incoming QoS is
called the “trust boundary”.
- The following figure shows a simple network in which the trust boundary is defined at
the edges, where the network connects to end users and public network.
Example of QoS Trust Boundary
- On Switch-B, port Gigabit Ethernet 0/1 is configured to consider inbound traffic as
untrusted.
- Switch-A port Fast Ethernet 0/1 connects to a PC that also is untrusted.
- The IP Phone connected on Switch-A port Fast Ethernet 0/2 is a special case because it
supports its own voice traffic and a PC.
Note: - In some cases, a PC can be considered as part of the trusted boundary when
it runs a trusted application (such as a Softphone) and requests a certain QoS
value.
P a g e | 265
Configuring a Trust Boundary:
- By default, QoS is disabled globally on a switch and all QoS information is allowed to
pass from one switch port to another.
- To enable QoS on a switch, use the following command:
Switch(config)# mls qos
- When QoS is enabled, all switch ports are configured as untrusted, and all QoS values
will not be allowed to pass from all switch ports.
- To define the QoS parameter that will be trusted on an interface, use the following
interface configuration command:
Switch(config-if)# mls qos trust {cos | ip-precedence | dscp | device cisco-phone}
- You can choose to trust the CoS, IP Precedence, or DSCP values of incoming traffic
on the switch port.
Note: - A special QoS trust can be configured for Cisco IP Phones using the “device
cisco-phone” keyword.
- Then, you can instruct the IP Phone on how to extend the trust boundary to the
connected PC (in case the PC is using for example a Softphone and request QoS):
Switch(config-if)# switchport priority extend {cos “value” | trust}
- By default, the QoS information from a PC connected to an IP Phone is not trusted.
- This is because the PC’s applications may try to spoof CoS or DSCP settings to gain
premium network service.
- In this case, you can use the “CoS” keyword so that the CoS bits sent by the PC are
overwritten to a “value” by the IP Phone as packets are forwarded to the switch.
- In other cases, the PC can be running a trusted application (such as a Softphone) and is
requesting QoS, you can extend the trust to the PC using the “trust” keyword, allowing
the CoS bits to be forwarded by the IP Phone without any modification.
P a g e | 266
- By default, the switch instructs an attached IP Phone to consider the PC port as
untrusted.
- The IP Phone will overwrite the CoS values to 0.
- Switch uplinks should be configured as trusted ports, as long as they connect to other
trusted devices that are within the QoS trusted boundary.
- To configure a switch uplink port to be trusted, use the following command:
Switch(config-if)# mls qos trust cos
- The switch will trust only the CoS values that are found in the incoming frames.
- QoS parameters are trusted or overwritten at the network edge, as packets enter the
trusted domain.
- After that, every switch inside the trusted boundary can implicitly trust and use the
QoS parameters in any frame passing through.
- A Cisco switch also has a CoS-to-DSCP map that is used to convert inbound CoS
values to DSCP values.
- The CoS values is useful only on trunk interfaces because it can be carried within the
trunk encapsulation.
- CoS must be converted to DSCP or IP Precedence, which can be carried along in the
IP packet headers on any type of connection.
- By default, switches uses CoS-to-DSCP mapping, which can be configured or changed
but this is beyond the scope of this book.
Configuring Auto-QoS:
- To reduce complexity when configuring QoS, Cisco introduced the Auto-QoS feature
on most switch platforms.
- Auto-QoS is handled by a macro-command, which in turn enters many other
configuration commands as if they were entered from the CLI.
- Because of this, Auto-QoS is best used on a switch that still has the default QoS
configurations.
P a g e | 267
- Auto-QoS handles the following types of QoS configuration:
Enable QoS.
Establish an interface QoS trust boundary.
CoS-to-DSCP mapping.
Tuning the ingress and egress queues.
Strict priority queues for egress voice traffic.
- To configure Auto-QoS, use the following interface configuration command:
Switch(config-if)# auto qos voip {cisco-phone | cisco-softphone | trust}
- “cisco-phone” - Used if the switch port is connected to a Cisco IP Phone.
- After that has been enabled, the switch will trust the QoS
parameters presented by the IP Phone, if an IP Phone is detected by
CDP.
- If no IP Phone is connected, the port is configured untrusted.
- “cisco-softphone” - Used if a PC running a trusted Softphone application.
- Frames that are received with DSCP values of 24, 26, or 46
will be trusted.
- Frames with any other value will have their DSCP values set to
0.
- “trust” - Used on trunk switch ports connecting to another switch.
- All frames received on that port will be trusted, and QoS parameters will
be left intact.
- Auto-QoS should be configured on the access-layer switches.
- If you have already configured Auto-QoS on an interface by using either of the three
keywords, you will not be allowed to use the “auto qos voip” command again on the
same interface.
- Instead, first remove any existing Auto-QoS by entering the “no auto qos voip”
command, then use the “auto qos voip” command with the desired keyword to enable
Auto-QoS.
P a g e | 268
Verifying Voice QoS:
- To verify how voice QoS trust is configured on an interface:
Switch# show mls qos interface “type mod/num.”
- If the port is trusted, all traffic forwarded by the IP Phone is accepted with the QoS
information left intact.
- If the port is untrusted, the switch will overwrite the voice traffic QoS information.
- Consider the following figure:
- To configure Switch-A Fast Ethernet 0/1, use the following commands:
Switch-A(config)# interface fastEthernet 0/1 Switch-A(config-if)# switchport mode access Switch-A(config-if)# switchport access vlan 10 Switch-A(config-if)# switchport voice vlan 50 Switch-A(config-if)# mls qos trust device cisco-phone Switch-A(config-if)# mls qos trust cos Switch-A(config-if)# mls qos trust dscp Switch-A(config-if)# no mdix auto
- To show the QoS trust configured on the switch port Fast Ethernet 0/1:
Switch-A# show mls qos interface fastethernet 0/1
FastEthernet0/1
trust state: trust cos
trusted mode: trust cos
trust enabled flag: ena
COS override: dis
default COS: 0
DSCP Mutation Map: Default DSCP Mutation Map
Trust device: cisco-phone
qos mode: port-based
Fa 0/1
Switch-A
P a g e | 269
- Next, you can verify how the IP Phone has been instructed by the switch to treat
incoming QoS information from its attached PC using the following command:
Switch# show interface “type mod/num.” switchport
- To verify the switch port Fast Ethernet 0/1:
Switch-A# show interface fastethernet 0/1 switchport
Switchport: Enabled
Administrative Mode: static access
Operational Mode: static access
Administrative Trunking Encapsulation: dot1q
Operational Trunking Encapsulation: native
Negotiation of Trunking: Off
Access Mode VLAN: 10 (VLAN-10)
Trunking Native Mode VLAN: 1 (default)
Voice VLAN: 50
! Lines are omitted for brevity
Appliance trust: none
- To configure Auto-QoS instead, use the following commands:
Switch-A(config)# interface fastEthernet 0/1 Switch-A(config-if)# auto qos voip cisco-phone
- If Auto-QoS is configured on a switch port, you can use the following command to
view the interface status:
Switch# show auto qos interface “type mod/num.”
- To show the Auto-QoS configured on Fast Ethernet 0/1:
Switch-A# show auto qos interface fastethernet 0/1
FastEthernet0/1
Auto qos voip cisco-phone
P a g e | 270
Chapter 14 Integrating Wireless LANs
Wireless LAN (WLAN) Basics:
- The major difference between the wired and wireless LANs is in the physical layer.
- A traditional Ethernet network is defined by the IEEE 802.3 standards.
- Wireless LAN (WLAN) is defined by the IEEE 802.11 standards.
- In WLANs, the wireless medium itself is challenging to control.
- When a host uses a wireless network, it shares the transmission medium (air) with
other hosts, so the wireless LAN is a shared network between a number of hosts.
- Collisions are a fact in a wireless LAN because of the shared medium and every
wireless connection is in half-duplex mode.
Note: - IEEE 802.11 WLANs are always half-duplex because transmitting and
receiving hosts use the same frequency.
- Only one host can transmit at any time; otherwise, collisions occur.
- To achieve full-duplex mode, transmitting should have a frequency that is
different than the receiving frequency for all wireless hosts.
- The 802.11 standards do not permit full-duplex operation.
Avoiding Collisions in a WLAN:
- When two or more wireless hosts transmit at the same time over the same frequency,
their wireless signals can have a collision (frequency interference).
- The receiving host or device can see the result as garbled data, noise, or errors.
- No clear-cut way exists to determine whether a collision has occurred.
- Even the transmitting host will not detect or realize the collision because its receiver
must be turned off while it is transmitting.
- As a basic feedback mechanism, whenever a wireless host transmits a frame, the
receiving wireless host or device must send an acknowledgment frame back to confirm
that the original frame is received free of errors.
- If no acknowledgment is sent back, the sending host must send that frame again.
P a g e | 271
- Acknowledgment frames serve as a collision detection tool; however, it does not work
to prevent collisions from occurring.
- The IEEE 802.11 WLAN standards uses the Carrier Sense Multiple Access with
Collision Avoidance (CSMA/CA), or sometimes called the Distributed Coordination
Function (DCF), trying to avoid collisions.
- When a wireless host has a frame that needs to be sent, one of the following two
conditions occurs:
No Other host is transmitting - The sending host transmit its frame
immediately.
- The receiving host or device must send an
acknowledgment frame to confirm that the
original frame arrived intact and error-free.
Another host is already transmitting - The sending host must wait until the
frame in progress has completed, then
must wait a short amount of time called
DIFS announced with the frame in
progress, then it must wait a random
amount of time (backoff time) before
transmitting its own frame.
- The IEEE 802.11 standard requires all wireless hosts to wait a short amount of time,
called the DCF Interframe Space (DIFS) after a frame is transmitted to receive an
acknowledgment frame back.
- Frames that are sent by the wireless hosts can vary in size.
- Transmitting hosts can provide an estimate of the amount of time needed to send a
frame by including a duration value within the 802.11 frame header.
- The duration contains the number of timeslots (typically in microseconds) needed for
the size of frame being sent.
P a g e | 272
- Other wireless hosts can listen and look at the duration value and wait that length of
time before considering their own transmission.
- The following figure shows three wireless hosts each have a frame to send:
DCF Process
- The following sequence of events occurs:
Host A listens and determines that no other host is sending, so Host A sends its
frame and also advertising the frame duration contained in the frame header.
Host B and C both have a frame to transmit, but both have to wait until Host A’s
frame is sent and acknowledgment frame is back.
Host B and C both wait a random backoff time before attempting to transmit to
avoid collisions.
Note: - Because the backoff time is random, the possibility of choosing the
same values is small, consequently, the possibility of collision is small.
Host C random backoff time is shorter than Host B random backoff time.
Host C listens and determines that no other host is sending, so Host C sends its
frame and also advertising the frame duration contained in the frame header.
Host B waits until Host C’s frame is sent and acknowledgment frame is back.
Host B immediately starts to send its frame without additional backoff time.
P a g e | 273
Note: - If another host (for example, Host A) has a frame to send during Host
C’s frame transmission, it must wait a random backoff time.
Wireless Networks:
- In IEEE 802.11 standards, any group of wireless hosts is known as a service set.
- The wireless hosts must share a common Service Set ID (SSID).
- SSID Is a text string included in every frame sent in the wireless medium and is
used to associate wireless hosts to a WLAN.
- If the SSIDs match across a sender and a receiver, both can communicate.
- The Wireless LAN hosts can be laptops, smartphones or tablets.
Note: - For a PC to be a wireless LAN host, it must have a wireless NIC and
software that interacts with the wireless standards.
- The 802.11 WLAN standards are IEEE 802.11 a/b/g/n/ac, and these standards
determines the data rate of the wireless connection.
- The 802.11 WLAN standards allow two or more wireless hosts to communicate
directly with each other, with no other means of network connectivity, and this is
known as an Ad Hoc wireless network or an Independent Basic Service Set (IBSS) as
shown in the following figure:
Ad Hoc or IBSS Wireless Network
P a g e | 274
- No inherent control exists over the number of hosts that can transmit and receive
frames over a wireless medium (air).
- Many variables exist that can affect whether a wireless host can transmit or receive
from other hosts in the wireless network, this makes providing a reliable wireless
access to all hosts is difficult.
- The 802.11 WLAN standards allow two or more wireless hosts to communicate
through a controlled wireless Access Point (AP) as the hub of the service set, this is
called Basic Service Set (BSS) as shown in the following figure:
Basic Service Set (BSS) Wireless Network
- Any wireless host attempting to use the wireless network must first arrange a
membership with the AP.
- Membership with the AP is called “association”.
- The AP can require any of the following criteria before allowing a host to join:
A matching SSID.
Authentication credentials.
Compatible security and encryption types.
A compatible wireless data rate (i.e. the same IEEE 802.11 standard).
- The wireless host must send an “association request” message, and the AP grants or
denies the request by sending an “association reply” message.
P a g e | 275
- When associated, all communications to and from the wireless hosts must pass through
the AP, and these wireless hosts cannot communicate directly as in Ad Hoc WLAN.
Note: - Frames sent over the wireless medium (air) are available to anyone who is
within the coverage area to receive them.
- To protect these frames, an encryption is used to secure the wireless traffic.
- An AP manages the centralized wireless network, advertises its own SSID(s) so that
hosts within the coverage area can associate and controls the communication process.
- The AP is responsible for sending frames over the wireless medium.
Note: - A BSS involves a single AP and no explicit connection into a regular
Ethernet network.
- In that setting, the AP and its associated hosts make a standalone network.
- An AP can also have uplink into an Ethernet wired network because it has both
wireless and wired capabilities.
- If two or more APs are placed at different geographic locations, they can all be
interconnected by a switched infrastructure, and this is called an Extended Service Set
(ESS) as shown in the following figure:
Extended Service Set (ESS) Wireless Network
- In an ESS, a wireless host can associate with one AP located physically near it.
P a g e | 276
- If the wireless host moved to a different location, it can associate with a different
nearby AP and access the same network.
Access Point Operation:
- The Access Point (AP) has two modes of operation:
Client mode.
Bridge mode.
a) Autonomous (Client) mode AP:
- Used to connect wireless hosts (clients) to each other and to a wired network.
- An AP can accept associations from a number of wireless hosts so that they become
members of the LAN, as if the same hosts were using wired connections
Client mode AP
- An AP acts as the central point of access controlling host access to the WLAN.
P a g e | 277
- Any host attempting to use the WLAN, must first establish an association with an AP.
- The AP can allow “open” access so that any host can associate, or it can tighten
control by requiring specific security measures (such as security type, encryption type,
encryption key) before allowing association.
b) Bridge mode AP:
- Used to connect two separate LANs through a wireless link.
- In that case, an AP is needed on each end of the wireless link.
- A line-of-sight (AP-to-AP) links are commonly used for connectivity between LANs
as shown in the following figure:
Bridge mode AP
- The AP is in charge of mapping a VLAN to an SSID as shown in the following figure:
Mapping VLANs to SSIDs using Client Mode APs
P a g e | 278
- VLAN 10 on the wired network is being extended to the AP over a switch port in
access mode (as shown in the left portion of the previous figure).
- The AP maps VLAN 10 to the wireless LAN using SSID “Sales”.
- Hosts associated with the “Sales” SSID will appear to be connected to VLAN 10.
- This concept can be extended so that multiple VLANs are mapped to multiple SSIDs
(as shown in the right portion of the previous figure).
- The AP must be connected to the switch by a trunk link that carries the VLANs.
- VLAN 10 and VLAN 20 are both trunked to the AP.
- The AP uses the 802.1Q trunk to map the VLAN numbers to SSIDs.
- For example, VLAN 10 is mapped to SSID “Sales”, whereas VLAN 20 is mapped to
SSID “HR”.
- When AP uses multiple SSIDs, it is trunking VLANs over the air to the wireless hosts.
- The wireless hosts must use the appropriate SSID that has been mapped to their
respective VLAN.
Note: - To support more than one VLAN on the Wireless LAN, the AP must support
more than one SSID.
Wireless LAN Cells:
- An AP can provide connectivity to only hosts or APs within its coverage area.
- The signal coverage area is defined by the AP’s antenna radiation pattern.
- Using an omnidirectional antenna, the radiation pattern takes a spherical shape
surrounding the antenna in all directions as shown in the following figure:
Omnidirectional Antenna Radiation Pattern
P a g e | 279
- Using a directional antenna, the radiation pattern takes the shape shown in the
following figure:
Directional Antenna Radiation Pattern
- The AP’s location must be carefully planned so that its range matches up with the
coverage area that is needed.
- Although the AP’s location will remain fixed, the wireless hosts will change their
locations quite frequently.
- The best approach to design the AP’s location and coverage area is to perform a site
survey.
- A test AP is placed in a desirable location while a testing hosts moves around, taking
live measurements of the signal strength and quality.
- The idea is to plot the AP’s range using the actual environment into which it will be
placed, with the actual obstacles that might interfere with the host’s operation.
- Cell Is the AP coverage area.
- Consider an omnidirectional antenna is used and hosts within its cell can associate
with the AP and use the wireless LAN except one host, which is outside the cell range
as shown in the following figure:
P a g e | 280
Wireless Hosts inside an AP Cell
- Suppose that an indoor omnidirectional antenna AP cell has a radius of 25 meter.
- Host can move around within that cell and use the WLAN from any location within
the 25 meter radius cell.
- To expand the overall WLAN coverage area, other APs can be used to provide
additional cells.
- The idea is to place the APs so that their cells cover every area where hosts are likely
to be located.
- In fact, the cell areas should overlap to a small percentage as shown in the following
figure:
AP Cells Arranged for Seamless Coverage
P a g e | 281
- When AP cells overlap, adjacent APs cannot use identical frequency channels.
- If two neighboring APs did use the same frequency, they would interfere with each
other, and this is called frequency interference.
- Instead, AP frequencies must be alternated across the whole coverage area.
- When a host associates with one AP, it can freely move about.
- As the host moves from one AP’s cell into another, the host’s association is also
passed from one AP to another with the APs uses the same SSID.
- Roaming Means that a host can move freely from one AP cell to another AP cell
without losing association.
- As well, any data that the host was sending just prior to the roaming condition is also
relayed from the old AP to the new AP.
- In this way, any host connects to the WLAN through only one AP at a time.
- This also minimizes the chance that any data being sent or received while roaming is
lost.
Note: - When a host moves from one AP to another, its association must be
established with the new AP, if the two APs have different SSID.
- If the host maintains its same IP address as it roams between APs, it undergoes “Layer
2 Roaming”.
- If the host roams between APs located in different IP subnets, it undergoes “Layer 3
Roaming”.
- When you design a wireless LAN, you should try to cover the most area possible with
each AP.
- You can run each AP at its maximum transmit power to make the most of its range,
this also can be done by determining the type of antenna used.
- Doing so will reduce the number of APs necessary to cover an area, which would in
turn reduce the overall cost.
- However, you should consider the amount of available bandwidth.
P a g e | 282
- When an AP is configured to provide a large coverage area, it also opens the potential
for overcrowding.
- Remember that an AP cell is essentially a half-duplex shared medium that all hosts
must share.
- As the number of hosts goes up, the amount of available bandwidth and airtime goes
down.
- Instead, consider reducing the cell size (by reducing the transmit power) so that only
hosts in close proximity to the AP can associate and use bandwidth.
- The AP can also assist in controlling the number of hosts that associates at any given
time.
- This becomes important for time-critical or bandwidth-intensive traffic such as voice
and video.
- When cell sizes are reduced, they are often called “microcells”.
- This concept can be further extended for extremely controlled environments.
- In this case, the AP power and cell size are minimized and the cells are called
“picocells”.
Wireless Architecture:
- There are two types of WLAN architecture that are discussed in this book:
Traditional WLAN Architecture.
Cisco Unified Wireless Network Architecture.
a) Traditional WLAN Architecture:
- Traditional WLAN architecture centers around the wireless access point.
- Each AP serves as the central hub of its own BSS, where hosts located within the AP
cell gain an association.
- The traffic to and from each client has to pass through the AP to reach any other part
of the network.
P a g e | 283
Note: - Each AP must be configured individually and operates independently.
- The AP handles its own Radio Frequency (RF) channels, host associate with
the AP directly, the AP security policies, and so on.
- Each AP is standalone or autonomous within the larger network, and Cisco
calls this an “autonomous” AP.
- Managing the RF operation of many APs is important to avoid frequency interference.
- You should be careful in selecting and configuring AP channels when APs are near
each others.
- You should also manage things such as AP output power to ensure the wireless
coverage area is sufficient.
- Consider the traffic pattern in an autonomous AP as shown in the following figure:
Traffic Pattern Through an Autonomous AP
- All traffic from and to the wireless hosts must pass through the AP.
- Traffic from host-A (Laptop-A) to some the rest of the network passes through the AP.
- Also, traffic between wireless hosts cannot travel directly over the air, it must first pass
through the AP and back out to the other host.
P a g e | 284
- Recall that an AP should support multiple SSIDs if multiple VLANs are extended to it
over a trunk link.
- This means that the switched network must carry the VLANs to each and every AP
that needs them as shown in the following figure:
Mapping VLANs to SSIDs over Multiple Autonomous APs
- SSIDs “Sales” and “HR” are offered on both autonomous APs individually.
- The two SSIDs “Sales” and “HR” correspond to VLAN 10 and VLAN 20 respectively.
- The APs must be connected to a common switched network that extends VLAN 10
and 20 at Layer 2.
- This is done by carrying VLAN 10 and 20 over a trunk link to each AP.
Note: - The SSID and its VLAN should be extended where the host can possibly
roam.
P a g e | 285
b) Cisco Unified Wireless Network Architecture:
- Cisco has collected a complete set of functions that are integral to WLANs and called
them the Cisco Unified Wireless Network.
- This architecture offers the following capabilities:
WLAN Management.
WLAN Control.
WLAN Deployment.
WLAN Security.
- To centralize these aspects of a WLAN, many of the functions found within
autonomous APs have to be shifted toward some central location.
- The following figure lists most of the functions performed by an autonomous AP:
Traditional Wireless Network versus Cisco Unified Wireless Network
- The functions performed by the autonomous AP have been grouped into:
Real-time functions on the left.
Management functions on the right.
P a g e | 286
- The real-time functions involves sending and receiving 802.11 frames, data encryption
handled on a per-packet basis, AP beacons, and probe messages.
- The AP must interact with wireless hosts at the MAC layer.
- These functions must stay with the AP hardware, closest to the hosts.
- The management functions handles things that should be centrally managed or
administered.
- Therefore, these management functions are moved to a centrally located platform
away from the AP.
- In the Cisco Unified Wireless Network, the real-time 802.11 functions are performed
only by the Lightweight Access Point (LAP).
- The LAP gets its name because the local intelligence is stripped down or lightweight if
compared to the traditional autonomous AP.
- The management functions are performed by the Wireless LAN Controller (WLC),
which is centralized and common to many LAPs.
- The LAP is left with functions in Layer 1 and 2, where frames are moved into and out
of the RF wireless domain.
- The LAP becomes totally dependent on the WLC for every other WLAN function,
such as authenticating users, managing security policies, and even selecting RF
channels and output power.
- The WLC becomes the central hub that supports a number of LAPs scattered in the
switched network.
- Split-MAC Architecture - The normal MAC operations are pulled apart into two
distinct locations.
- This occurs for every LAP in the network, where every
AP must bind itself to a WLC to boot up and support
wireless hosts.
- To allow a LAP to bind with a WLC to form a complete working access point, the two
devices must bring up a tunnel between them to carry 802.11 related messages and
also host data.
P a g e | 287
- The LAP and WLC can be located either on the same VLAN or in two different
VLANs with two entirely different locations.
- The tunnel makes this possible by encapsulating the data between the LAP and WLC
inside new IP packets, so the tunneled data can then be switched or routed across the
campus network as shown in the following figure:
Linking an LAP with WLC through a LWAPP or CAPWAP Tunnel
- The LAP and WLC pair uses one of the following tunneling mechanisms:
Lightweight Access Point Protocol (LWAPP) (developed by Cisco).
Control and Provisioning Wireless Access Point (CAPWAP) (Standard-based).
- These two tunneling mechanisms consists of the following two tunnels:
Control Messages - Messages that are exchanged between the LAP and WLC
and used to configure the LAP and manage it operation.
- The control messages are authenticated and encrypted so
that the LAP is securely controlled by only the WLC.
Data - Packets to and from wireless hosts associated with the LAP.
- The data is encapsulated within the LWAPP or CAPWAP protocols
but is not encrypted.
Control
Messages Data
P a g e | 288
Note: - Although Cisco developed LWAPP, it submitted LWAPP as an IETF draft.
- The result is the CAPWAP standard defined in RFC 4118.
- LWAPP uses UDP destination ports 12222 and 12223 on the WLC end.
- CAPWAP uses UDP ports 5246 and 5247.
- Every LAP and WLC must also authenticate each other using digital certificates.
- An X.509 certificate is preinstalled in each device when it is purchased.
- By using certificates, every device is authenticated before becoming part of the Cisco
Unified Wireless Network.
- This process helps ensure that no rogue LAP or WLC (or devices posing as LAP or
WLC) can be introduced into the network.
WLC Functions:
- When LWAPP or CAPWAP tunnels are built from a WLC to one or more LAPs, the
WLC can begin offering a variety of additional functions.
- The following are the WLC functions:
Dynamic Channel Assignment - The WLC chooses and configures the RF
channel used by each LAP based on other
active APs in the area.
Transmit Power Optimization - The WLC sets the transmit power of each
LAP based on the coverage area needed.
- Transmit power is automatically adjusted
periodically.
Self-healing wireless coverage - If an LAP dies, the coverage hole is “healed”
by increasing the transmit power of
surrounding LAPs automatically.
Flexible host roaming - Hosts can roam at either Layer 2 or Layer 3 with every
fast roaming times.
Dynamic host load balancing - If two or more LAPs are positioned to cover the
same geographic area, the WLC can associate
hosts with the least used LAP.
- This distributes the host load across the LAPs.
P a g e | 289
RF monitoring - The WLC manages each LAP so that it scans channels to
monitor the RF usage.
- By listening to a channel, the WLC can remotely gather
information about RF interference, noise, signals from
surrounding LAPs, and signals from rogue APs or Ad Hoc
hosts.
Security management - The WLC can require wireless hosts to obtain an IP
address from a trusted DHCP server before allowing
them to associate and access the WLAN.
Note: - Think of the traditional WLAN architecture as well as you read over the
previous list of WLC functions.
- Cisco WLCs are available in several platforms, differing mainly in the number of
managed LAPs as shown in the following table:
Model Interface Attribute
2100 8 10/100 TX Handles up to 6, 12, or 25 LAPs.
4402 2 Gigabit Ethernet Handles up to 12, 25, or 50 LAPs.
4404 4 Gigabit Ethernet Handles up to 100 LAPs.
5500 8 Gigabit Ethernet Handles up to 12, 25, 50, 100, or 250
LAPs
WiSM
4 Gigabit Ethernet bundled in
an EtherChannel for each
controller
- Catalyst 6500 module with two WLCs.
- Handles up to 300 LAPs (150 per
controller).
- Handles up to 5 WiSMs in a single
chassis.
WLC module
for ISR routers
Can be integrated in 2800 and
3800 routers. Handles up to 6, 8, 12, or 25 LAPs
Catalyst 3750G
integrated WLC
N/A (integrated in 24-port
10/100/1000 TX switch)
Handles up to 50 LAPs per switch, up to
200 LAPs per switch stack.
- You can also deploy several WLCs in a network to handle a large number of LAPs.
P a g e | 290
- In addition, multiple WLCs offer some redundancy so that LAPs can recover from a
WLC failure.
- Managing several WLCs can require a significant effort, due to the number of LAPs
and hosts to be managed and monitored.
- The Cisco Wireless Control System (WCS) is an optional server platform that can be
used as a single GUI front-end to all the WLCs in a network.
- From the WCS, you can perform any WLAN management or configuration task, as
well as RF planning and wireless use tracking.
- The WCS uses building floor plans to display dynamic representations of wireless
coverage.
- It can also be fed information about the building construction to improve its concept of
RF signal propagation.
- Once this is done, the WCS can locate a wireless client to within a few meters by
triangulating the client’s signal as received by multiple LAPs.
- The WCS can be teamed with the Cisco Wireless Location Appliance to track the
location of thousands of wireless clients.
- You can even deploy active 802.11 RFID tags to track objects as they move around in
the wireless coverage area.
- Tracking objects by their MAC addresses can be handy when you need to locate a
rogue or malicious wireless client, or when you need to track corporate assets that tend
to move around within a building.
LAP Functions:
- The LAP is designed to be a “zero touch” configuration.
- The LAP must find a WLC and obtain all of its configuration parameters, so you never
have to configure it through its console port or over the network.
- The following steps detail the bootstrap process that an LAP must complete before it
becomes active:
P a g e | 291
Step 1 - The LAP obtains an IP address (From a DHCP or static configuration).
Step 2 - The LAP learns the IP addresses of any available WLCs.
Step 3 - The LAP sends a join request to the first WLC in its list of addresses.
- If that one fails to answer, the next WLC is tried.
- When a WLC accepts the LAP, it sends a join reply back to the LAP,
effectively binding the two devices.
Step 4 - The WLC compares the LAP’s code image release to the code release stored
locally.
- If they differ, the LAP downloads the code image stored on the WLC and
reboots itself.
Note: - You can upgrade all the LAPs code image release from the WLC.
Step 5 - The WLC and LAP build a secure LWAPP or CAPWAP tunnel for
management traffic and an LWAPP or CAPWAP tunnel (not encrypted) for
wireless host data.
- In Step 2, the LAP can find the WLCs IP addresses using any of these methods:
A DHCP Server that adds option 43 to its reply containing a list of WLC
addresses.
With the IP subnet broadcast option, the LAP broadcasts a join request message,
hoping that a WLC is also connected to the same local subnet (VLAN), this
method works only if the LAP and WLC are Layer 2-adjacent.
- An LAP is always joined or bound to one WLC at any time.
- However, the LAP can maintain a list of up to three WLCs (primary, secondary, and
tertiary).
- As the LAP boots, it tries to contact each WLC address in the list in sequential order.
- If it cannot find a responding WLC at all, the LAP tries an IP subnet broadcast to find
any available WLC.
- Suppose that the LAP has booted up and has successfully joined a WLC.
P a g e | 292
- If that WLC fails for some reason, the LAP will no longer be able to forward traffic or
to maintain host association.
- Therefore, when the LAP realizes its WLC is no longer responding, it reboots and
begins the process of searching for live WLCs again.
- This means any host associations will be dropped while the LAP reboots and joins a
different controller.
- When an LAP is cutoff from a WLC, host associations are normally dropped and no
data can pass over the WLAN between hosts.
- Cisco Hybrid Remote Edge Access Point (HREAP) is a special case for remote sites
where the LAPs are separated from the WLC by a WAN link.
- With HREAP, the remote LAPs can keep operating even while the WAN link is down
and their WLC is not available, much like an autonomous AP would do.
- This allows wireless hosts to keep communicating within the remote site until the link
(and WLC) is restored.
Traffic Pattern in a Cisco Unified Wireless Network:
Traffic Pattern Through an LAP linked with a WLC
To the Rest
Of the Network
Host-A Host-B SSID “Wireless”
P a g e | 293
- Because the LAPs connects to the WLC through a logical LWAPP or CAPWAP
tunnel through a switched network, the traffic patterns into and out of the WLAN are
different than the traditional wireless networks.
- The previous figure shows two wireless hosts that are associated with the WLAN that
is formed by the LAP and WLC combination.
- Traffic from host-A to a host somewhere in the network travels through the LAP,
through the tunnel to the WLC, and then out onto the switched campus network as
shown in red-dashed line in the previous figure.
- Traffic between two wireless hosts (host-A and host-B) must go from host-A through
the LAP, through the tunnel to the WLC, back through tunnel to the LAP, and then to
host-B as shown in the black-dashed line in the previous figure.
- This illustrates what a vital role the WLC plays in the Cisco unified wireless network.
- Even though all traffic into and out of the WLAN must pass through the LWAPP or
CAPWAP tunnel and the WLC, not all traffic operations are applied end-to-end across
the tunnel.
- For example, wireless encryption still be used to secure data over the air, as with
traditional WLANs.
- However, the encrypted data doesn’t pass through the LWAPP or CAPWAP tunnel at
all.
- Packets are encrypted as they leave the wireless host and unencrypted when they
arrive on the LAP.
- The same is true for packet authentication, if it is used.
- All the packet authentication and encryption functions remain within the LAP
hardware and are not distributed to the WLC at all.
- When autonomous APs are used in a network, the access VLANs serving the wireless
hosts must be trunked all the way out to touch the APs, this is not true for LAP.
- The following figure shows a simple network with two VLANs (10 and 20) are used to
carry the wireless host traffic that is associated to SSIDs A and B respectively:
P a g e | 294
Mapping VLANs to SSIDs in a Cisco Unified Wireless Network
- VLANs 10 and 20 exist on the trunk link between the WLC and Switch-A.
- The LAP is connected by access VLAN 30, something that is totally isolated from
access VLANs 10 and 20.
- VLANs 10 and 20 are carried over the tunnel so that they logically touch the LAP
where the wireless hosts resides.
Configuring Switch Ports for WLAN Use:
- To configure a wireless LAN, both switches and access points must be configured.
Note: - The Road (Switch) covers only the design and configuration of the LAN
switches to support WLAN.
- The AP (autonomous and lightweight) and WLC configuration will be
covered in another book discussing “wireless” topics in more details.
- Therefore, the following sections discusses only the configuration of switch
ports where wireless devices are connected.
P a g e | 295
a) Configuring Support for Autonomous APs:
- Consider the following WLAN where autonomous AP is connected into a network:
- Autonomous APs are normally positioned in the access layer of the network.
- Each SSID that is supported by the AP is mapped to a VLAN.
- When multiple SSIDs are offered, multiple VLANs must touch the AP.
- Therefore, you should configure the switch port connecting to the AP as a trunk link.
- To configure Switch-A port Gigabit Ethernet 0/1, use the following command:
Switch-A(config)# interface gigabitethernet 0/1 Switch-A(config-if)# switchport mode trunk Switch-A(config-if)# switchport trunk allowed vlan 10, 20, 30 Switch-A(config-if)# spanning-tree portfast trunk
P a g e | 296
b) Configuring Support for LAP and WLCs:
- Cisco LAPs are designed to be “zero-touch” devices, which can be installed and used
with little or no manual intervention.
- The WLC can manage every aspect of LAP operation, so almost no information needs
to be primed or preconfigured in the LAP itself.
- Consider the following WLAN where LAP and WLC are used:
- The LAP requires to be connected to an access switch port.
- The only VLAN needed at the LAP is one where the LAP can get an IP address and
reach the WLC.
- Any VLAN that is mapped to an SSID is transported over the LWAPP or CAPWAP
tunnel from the LAP to the WLC (the tunnel configuration on LAP and WLC is
outside the scope of this book).
P a g e | 297
- To configure Switch-A, use the following commands:
Switch-A(config)# interface gigabitethernet 0/1 Switch-A(config-if)# switchport mode trunk Switch-A(config-if)# switchport trunk allowed vlan 10, 20, 30 Switch-A(config-if)# spanning-tree portfast trunk Switch-A(config)# interface gigabitethernet 0/2 Switch-A(config-if)# switchport mode access Switch-A(config-if)# switchport access vlan 100 Switch-A(config-if)# spanning-tree portfast Switch-A(config-if)# power inline auto
- Here, the WLC needs direct connectivity to any VLANs that will be tunneled to the
LAP(s) where the wireless hosts are located.
- The switch interface feeding a WLC should be configured as a trunk link.
- If EtherChannel needed to be configured between the WLC and the switch, the
member interface should always be configured as an unconditional EtherChannel
because WLC cannot negotiate one with the switch.
Switch-A(config-if)# channel-group “group” mode on
P a g e | 298
Chapter 15 Securing Switch Access
Port Security:
- In some environments, a network must be secured by controlling which host can gain
access to the network based on its MAC address.
- If hosts are stationary, their MAC addresses always can be expected to connect to the
same access-layer switch ports.
- If hosts are mobile, their MAC addresses can be learned dynamically and added to a
list of addresses to expect on a switch port.
- Catalyst switches offer the port security feature to control the switch port access based
on the connect hosts unique MAC addresses.
- To configure port security on an access-layer switch port, begin by enabling it on a
per-port basis by using the following configuration command:
Switch(config-if)# switchport port-security
- Next, you must identify the maximum number of allowed MAC addresses so that the
switch port can grant them access using the following command:
Switch(config-if)# switchport port-security maximum “max-number”
- “max-number” A value that can range from 1 to 1024 (default is 1).
- By default, port security allows only one MAC address to connect to a switch port.
- By default, each switch port that uses port security dynamically learns MAC addresses
and expect these addresses to appear on that port in the future.
- These dynamically learned MAC addresses are called “Sticky” MAC addresses.
- Also, MAC addresses can be statically configured on a switch port and any of these
MAC addresses are allowed to access the network through that port.
P a g e | 299
- To configure sticky or static MAC addresses use the following command:
Switch(config-if)# switchport port-security mac-address {sticky | “mac-address”}
- If static MAC addresses are used, only one MAC address is configured per command
and is given in a dotted-triplet format (ex. 00C2.5F2D.0108).
- To add more static MAC addresses, repeat this command with each MAC address.
- If the number of static MAC addresses configured is less than the maximum number of
allowed MAC addresses on a port, the remaining addresses are learned dynamically.
- Be sure to set the “max-number” appropriately.
- Learned MAC addresses can be aged out if those hosts are silent for a period of time.
- By default, no aging occurs.
- To configure MAC address aging, use the following command:
Switch(config-if)# switchport port-security aging time “value”
- “value” A value in minutes and can range from 1 to 1440.
- Finally, you must define how the switch port that uses port security should react if a
different MAC address is connected to the switch port other than the dynamically
learned or statically configured MAC addresses.
- To configure port security violation mode, use the following command:
Switch(config-if)# switchport port-security violation {shutdown | restrict | protect}
- A violation occurs if more than the maximum number of allowed MAC addresses are
learned or if an unknown (no statically configured) MAC address attempts to transmit
on the switch port.
- The switch port takes one of the following actions when a violation is detected:
Shutdown - The switch port immediately is put into the “Errdisable” state,
which effectively shuts the port down.
- The switch port must be re-enabled manually or through Errdisable
recovery to be used again
P a g e | 300
Restrict - The switch port is allowed to stay up for allowed MAC addresses,
and only frames from violating MAC addresses are dropped.
- The switch keeps a running count of the number of violating frames
and can send an SNMP trap and a syslog message as an alert of the
violation.
Protect - The switch port is allowed to stay up for allowed MAC addresses, and
only frames from violating MAC addresses are dropped.
- No record of the violation is kept.
Note: - If a switch port is undergoing the “shutdown”, “restrict”, or “protect”
condition, you might need to clear the learned MAC addresses (if sticky
MAC addresses are used) so that a specific host can use the switch port.
- To clear a MAC address or the complete port cache on a switch port, use the following
command:
Switch# clear port-security dynamic [address “mac-address” | interface “type mod/num.”]
Example: - Consider the following small network:
- Port security will be configured to secure access on Switch-A port Fast Ethernet 0/1.
- Maximum of 2 MAC addresses are allowed to be learned on that port.
P a g e | 301
- If using the default “sticky” MAC addresses, the two MAC addresses of PC-1 and IP
Phone-1 will be learned on the port and will be the only two allowed MAC addresses.
- If using “static” MAC addresses, you have to configure the MAC addresses manually.
- A port security “restrict” violation mode will be configured on that switch port.
- To configure Switch-A port Fast Ethernet 0/1 for port security, use the following
commands:
Switch-A(config)# interface fastEthernet 0/1 Switch-A(config-if)# switchport port-security Switch-A(config-if)# switchport port-security maximum 2 Switch-A(config-if)# switchport port-security mac-address sticky Switch-A(config-if)# switchport port-security violation restrict
- To show the port security status for Fast Ethernet 0/1, use the following command:
Switch-A# show port-security interface fastEthernet 0/1
Port Security : Enabled
Port Status : Secure-up
Violation Mode : Restrict
Aging Time : 0 mins
Aging Type : Absolute
SecureStatic Address Aging : Disabled
Maximum MAC Addresses : 2
Total MAC Addresses : 2
Configured MAC Addresses : 0
Sticky MAC Addresses : 2
Last Source Address:Vlan : 0001.6381.B501:1
Security Violation Count : 0
- To show a summary of the port security status, use the following command:
Switch-A# show port-security
Secure Port MaxSecureAddr CurrentAddr SecurityViolation Security Action
(Count) (Count) (Count)
-------------------------------------------------------------------------------------------------------------
Fa0/1 2 2 0 Restrict
-------------------------------------------------------------------------------------------------------------
P a g e | 302
- Now, consider PC-2 will replace PC-1, a violation occurs and this will be shown by
the following syslog message:
Nov 26 17:10:7 EDT: %PORT-SECURITY -2-PSECURE-VIOLATION: Security violation occurred,
caused by MAC address 0001.C7B7.B641 on port Fast Ethernet 0/1.
- To show port security status of Fast Ethernet 0/1 after the violation:
Switch-A# show port-security interface fastEthernet 0/1
Port Security : Enabled
Port Status : Secure-up
Violation Mode : Restrict
Aging Time : 0 mins
Aging Type : Absolute
SecureStatic Address Aging : Disabled
Maximum MAC Addresses : 2
Total MAC Addresses : 2
Configured MAC Addresses : 0
Sticky MAC Addresses : 2
Last Source Address:Vlan : 0001.6381.B501:1
Security Violation Count : 4
- If the “shutdown” port security violation mode is used instead of “restrict”, the output
would be as follows:
Switch-A# show port-security interface fastEthernet 0/1
Port Security : Enabled
Port Status : Secure-shutdown
Violation Mode : Shutdown
Aging Time : 0 mins
Aging Type : Absolute
SecureStatic Address Aging : Disabled
Maximum MAC Addresses : 2
Total MAC Addresses : 2
Configured MAC Addresses : 0
Sticky MAC Addresses : 2
Last Source Address:Vlan : 0001.C7B7.B641:1
Security Violation Count : 1
P a g e | 303
- To show the status of the port Fast Ethernet 0/1:
Switch-A# show interface fastEthernet 0/1
FastEthernet0/1 is down, line protocol is down (err-disabled)
! Lines are omitted for brevity
- To show the reason of putting the port in the “err-disabled” state:
Switch-A# show interfaces status err-disabled
Port Name Status Reason
Fa0/1 Fast Ethernet 0/1 err-disabled psecure-violation
- When a port is moved to the err-disable state, you must either manually cycle it using
the “shutdown” then “no shutdown” commands or configure the switch to
automatically re-enable ports in err-disabled state because of port security violation
after a prescribed delay.
Port-Based Authentication:
- Cisco Catalyst switches can support port-based authentication, this feature is based on
the IEEE 802.1x standard.
- When the 802.1x is enabled, a switch port will not pass any traffic until a user
authenticates using his own credentials.
- If the authentication is successful, the user can use the switch port normally.
- For port-based authentication, both the end user host and the switch must support the
802.1x standard using the Extensible Authentication Protocol over LANs (EAPoL).
- The 802.1x standard is a cooperative effort between the host and the switch.
- The 802.1x EAPoL is a layer 2 protocol.
- At the point that a switch detects the presence of a host on a port, the port remains in
the “unauthorized” state.
- Therefore, the host cannot communicate with anything other than the switch by using
EAPoL, until authenticating successfully, and then use the switch port normally.
P a g e | 304
- If the host is not already has an IP address (by static configuration), it cannot discover
a DHCP to obtain an IP address because the switch port is in the “unauthorized” state.
- The host also has no knowledge of the switch or its IP address, so any means other
than a Layer 2 protocol is not possible.
Note: - The host must have an 802.1x-capable application or software.
- For example, the host can be a PC or an IP Phone with 802.1x capability.
- An 802.1x switch port begins in the “unauthorized” state so that no data other than the
802.1x protocol itself is allowed through the port.
Note: - This happens if the configured state on the 802.1x port is “auto” as will be
explained in the 802.1x configuration section.
- The host must provide correct credentials for a successful authentication process to be
able to use the switch port after it is moved to the “authorized” state.
- The “authorized” state of the port ends when the user logs out, causing the 802.1x host
to inform the switch to revert back to the “unauthorized” state.
- The switch can also time out the user’s authorized session.
- If this happened, the host must re-authenticate to continue using the switch port.
802.1x Configuration:
- Port-based authentication can be handled by an external Remote Authentication Dial-
In User Service (RADIUS) server (more than one server can be used).
IEEE 802.1x Port-Based Authentication
Note: - Only RADIUS is supported for 802.1x on Cisco switch platforms.
- The RADIUS authentication method must be configured first, followed by 802.1x.
P a g e | 305
- To configure 802.1x on a switch, use the following steps:
Step 1 Enable AAA on the switch:
Switch(config)# aaa new model
- By default, AAA is disabled on a switch.
- AAA is an application that can be installed on a server to provide the following
services:
Authentication (using RADIUS).
Authorization.
Accounting.
Step 2 Define external RADIUS server(s):
Switch(config)# radius-server host {“ip-address” | “hostname”} [key “string”]
- “string” A secret shared password known only to the switch and the server, and
provides a key for encrypting the authentication session.
Note: - This command can be repeated to define additional RADIUS servers.
Step 3 Define the authentication method for 802.1x:
Switch(config)# aaa authentication dot1x default group radius
- This command causes the RADIUS server(s) defined on the switch on step 2 to be
used for 802.1x authentication.
Step 4 Enable 802.1x on the switch:
Switch(config)# dot1x system-auth-control
P a g e | 306
Step 5 Configure each switch port that will use 802.1x port-based authentication:
Switch(config)# interface “type mod/num.” Switch(config-if)# dot1x port-control {force-authorized | force-unauthorized | auto}
- The 802.1x configured state can be one of the following:
Force-authorized - The port is forced to always authorize any connected host.
(Default) - No authentication is necessary.
Force-unauthorized - The port is forced to never authorize any connected host.
- As a result, the port cannot move to the “authorized”
state even if the user provided correct credentials.
Auto - The port uses an 802.1x exchange to move from the “unauthorized” to
the “authorized” state, if the credentials provided by the user are
correct.
- This requires an 802.1x-capable application or software installed on the
host.
- After 802.1x is globally enabled on a switch, all switch ports default to the “force-
authorized” state.
- This means that any host will connect to any switch port can access the network.
- Therefore, you should configure each port to use the “auto” state so that the connected
hosts can provide credentials for authentication through the 802.1x exchange.
Step 6 Allow multiple hosts on a switch port:
Switch(config-if)# dot1x host-mode multi-host
- Used when the switch is expected to find multiple hosts present on the switch port
(such as a PC and an IP Phone).
- To verify the 802.1x operation on each switch port, use the following command:
Switch# show dot1x all
P a g e | 307
Example: - Consider the following small network:
- We need to configure only Switch-A port Fast Ethernet 0/1 for port-based
authentication.
Note: - The RADIUS server configuration depends on the type of software used on
the server.
- The 802.1x-capable software must be installed on both hosts.
- To configure Switch-A, use the following commands:
Switch-A(config)# aaa new model Switch-A(config)# radius-server host 10.1.1.100 key BigSecret Switch-A(config)# aaa authentication dot1x default group radius Switch-A(config)# dot1x system-auth-control Switch-A(config)# interface fastEthernet 0/1 Switch-A(config)# dot1x port-control auto Switch-A(config)# dot1x host-mode multi-host
Mitigating Spoofing Attacks:
- Attackers sometimes can send spoofed information to trick hosts to use a rogue default
gateway.
- The attacker’s goal is to let hosts send packets to it as if it were a router, so the attacker
can glean information from these packets.
- To mitigate the spoofing attacks, the following Cisco Catalyst features can be used:
DHCP Snooping.
IP Source Guard.
Dynamic ARP Inspection.
P a g e | 308
a) DHCP Snooping:
- A DHCP server normally provides all the TCP/IP configuration a host needs to operate
on a network (such as IP address, subnet mask, default gateway, and DNS).
- Suppose that an attacker added a rogue DHCP server in the same subnet as the host.
- Now when the host broadcasts its DHCP discover message, the rogue DHCP server
can send a DHCP offer message before the legitimate DHCP server on the network.
- The host then can make a DHCP request and the rogue DHCP server can acknowledge
with its own IP address as the default gateway.
- The host now has false information, so any data destined outside the host local subnet
will be sent to the attacker.
- The attacker can forward packets to the correct destination, but at the same time, it can
examine every packet that it intercepts.
- In effect, this can be considered as a type of man-in-the-middle attack, the attacker is
wedged into the path and the host does not realize it as shown in the following figure:
Attacker uses a Rogue DHCP Server
Note: - For example, the attacker can use a virtual machine on PC-2 acting as a
DHCP server providing false TCP/IP information for the hosts.
- Usually, the legitimate DHCP server is in a different subnet than hosts, so
the rogue DHCP server will respond before the legitimate DHCP server.
P a g e | 309
- Cisco Catalyst switches can use the DHCP Snooping feature to mitigate this type of
attack.
- When DHCP Snooping is enabled, switch ports are categorized as:
Trusted ports.
Untrusted ports.
- Legitimate DHCP servers and trusted hosts can be found on “trusted” ports, whereas
all other untrusted hosts sit behind “untrusted” ports.
- A switch intercepts all DHCP traffic coming from an “untrusted” port and discards
them if they passed a certain limit of sending DHCP traffic because they must have
come from a rogue DHCP server.
- In addition, that “untrusted” port that sent the DHCP traffic will be shutdown
automatically by the switch and move to the “Err-disabled” state.
- For example, the following error message will appear on the switch when an
“untrusted” port (Fast Ethernet 0/2) starts sending DHCP packets:
00:09:32: %DHCP_SNOOPING-4-DHCP_SNOOPING_ERRDISABLE_WARNING: DHCP Snooping received 1 DHCP packets on interface Fa0/2 00:09:32: %PM-4-ERR_DISABLE: dhcp-rate-limit error detected on Fa0/2, putting Fa0/2 in err-disable state
- DHCP Snooping also keeps track of the completed DHCP bindings as hosts receive
legitimate DHCP TCP/IP configuration.
- This database contains the host’s MAC address, offered IP address, lease time, and so
on.
- To configure DHCP Snooping, first you have to enable it globally on a switch:
Switch(config)# ip dhcp snooping
- Next, identify the VLANs where DHCP Snooping should be implemented:
Switch(config)# ip dhcp snooping vlan “vlan-range”
P a g e | 310
- You can give a single VLAN ID or a range of VLAN IDs by adding a first number
dash last number, for example, “1,5-7,9-12”.
- When DHCP Snooping is enabled, by default all the switch ports will be “untrusted”
ports.
- Therefore, you should identify the ports where the legitimate DHCP servers and
DHCP Clients are located and make them “trusted” ports using the following
commands:
Switch(config)# interface “type mod/num.” Switch(config-if)# ip dhcp snooping trust
- For “untrusted” ports, no DHCP traffic is allowed by default.
- You can limit the rate of the DHCP traffic (packets sent per second) on an “untrusted”
port using the following command:
Switch(config-if)# ip dhcp snooping limit rate “rate”
- “rate” A value that can range from 1 to 2048 DHCP packets per second (pps).
- Usually, if a host is connected to an “untrusted” port, it sends a little number of DHCP
packets/sec. (usually 2) to get its TCP/IP configuration by a legitimate DHCP server.
- If a rogue DHCP server is connected to an “untrusted” port, it sends more DHCP
packets per second as a reply to all DHCP discover messages sent in the local subnet.
Note: - For “untrusted” ports, the “rate” of DHCP traffic should be limited to a
number (for example, 3 packets per second) that can allow a host to request
TCP/IP configuration from a legitimate DHCP server.
- When DHCP Snooping is configured, you can display its status using the following
command:
Switch# show ip dhcp snooping [binding]
- You can use the “binding” keyword to display all the known DHCP bindings that have
been overhead, the switch maintains these bindings in the DHCP Snooping database.
P a g e | 311
- If the “binding” keyword is omitted, only the switch ports that are trusted or that have
a rate limiting applied are listed.
- You can configure the multilayer switch to use DHCP Option-82, the DHCP Relay
Agent option.
- When a DHCP discover message (broadcast) is intercepted by a multilayer switch, the
switch adds its own MAC address and the switch port identifier into the option-82
field of the DHCP discover message.
- The DHCP discover message then is forwarded (unicast) so that it can reach a
legitimate DHCP server identified on the multilayer switch.
- Adding option-82 provides more information about the actual host that generated the
DHCP discover message.
- In addition, the DHCP offer back with the option-82 information.
- The access-layer switch intercepts the DHCP offer reply and compares the option-82
data to confirm that the DHCP discover message came from a valid port on itself.
- This feature is enabled by default.
- You can enable or disable option-82 globally using the following command:
Switch(config)# [no] ip dhcp snooping information option
Example: - Consider the following small network:
P a g e | 312
- DHCP Snooping is needed to be enabled on Switch-A and Switch-B.
- Switch-A Fast Ethernet 0/1 should be configured as a “trusted” port.
- Switch-A Fast Ethernet 0/2 should be limited to a rate of 3 DHCP packets per second.
- Switch-B Gigabit Ethernet 0/1 should be configured as a “trusted” port.
- To configure Switch-A and Switch-B, use the following commands:
Switch-A(config)# ip dhcp snooping Switch-A(config)# ip dhcp snooping vlan 10 Switch-A(config)# interface fastEthernet 0/1 Switch-A(config-if)# ip dhcp snooping trust Switch-A(config)# interface fastEthernet 0/2 Switch-A(config-if)# ip dhcp snooping limit rate 3
Switch-B(config)# ip dhcp snooping Switch-B(config)# ip dhcp snooping vlan 10,20 Switch-B(config)# interface gigabitethernet 0/1 Switch-B(config-if)# ip dhcp snooping trust
- To show the resulting DHCP Snooping status on both Switch-A and Switch-B:
Switch-A# show ip dhcp snooping
Switch DHCP snooping is enabled
DHCP snooping is configured on following VLANs:
10
Insertion of option 82 is enabled
Option 82 on untrusted port is not allowed
Interface Trusted Rate limit (pps)
----------------------- ------- ---------------------
FastEthernet0/2 no 3
FastEthernet0/1 yes unlimited
Switch-B# show ip dhcp snooping
Switch DHCP snooping is enabled
DHCP snooping is configured on following VLANs:
10,20
Insertion of option 82 is enabled
Option 82 on untrusted port is not allowed
DHCP snooping trust/rate is configured on the following Interfaces:
Interface Trusted Allow Option Rate limit (pps)
----------------------- ------- ----------------- ---------------------
GigabitEthernet0/1 yes yes unlimited
P a g e | 313
- To show all the known DHCP bindings on Switch-A:
Switch-A# show ip dhcp snooping binding
MacAddress IpAddress Lease(sec) Type VLAN Interface
------------------------- --------------- ---------- ------------- -------- -------------------
-------------
00:01:2C:08:5E:B2 10.1.1.2 28800 dhcp-snooping 10
FastEthernet0/1
00:0B:BE:70:89:76 10.1.1.3 28800 dhcp-snooping 10
FastEthernet0/2
Total number of bindings: 2
Note: - As shown in output, PC-2 connected to Fast Ethernet 0/2 on Switch-A can
only be assigned TCP/IP configuration by a legitimate DHCP server.
- If that host tried to be a rogue DHCP server and send more DHCP packets
per second (more than 3 pps), the switch will immediately shutdown the port
and move it to the “Err-disabled” state.
b) IP Source Guard:
- Address spoofing is one type of attack that can be difficult to mitigate.
- Normally, an original host is assigned an IP address (by DHCP or statically
configured) and is expected to use that address in all the traffic it sends out.
- A rogue host can use a spoofed IP address pretending to be the original host.
- Consider the following small network:
Using a Spoofed Address Within a VLAN (Subnet)
P a g e | 314
- The attacker can disconnect PC-1 and connect the rogue PC-3 using the same IP
address.
- Using IP Source Guard, the switch will drop frames with different source IP-MAC
address binding other than the expected one configured on the switch.
- Cisco Catalyst switches can use the IP Source Guard feature to “detect” spoofed
addresses with the same VLAN (subnet).
- IP Source Guard does this by making use of the DHCP Snooping database or static IP
source binding entries.
- If DHCP Snooping is enabled, the switch learns the MAC and IP addresses of hosts
that use DHCP.
- To show all the known DHCP bindings on a switch as shown previously, use the
following command:
Switch# show ip dhcp snooping binding
- Frames arriving on a switch port can be tested for one of the following two conditions:
- The source IP address must be identical to the IP address learned by DHCP
snooping or a static binding entry.
- A dynamic ACL is used to filter traffic.
- The switch automatically creates this ACL, adds the learned source IP address to
the ACL, and applies the ACL to the interface where the address is learned.
- The source MAC address must be identical to the MAC address learned on the
switch port and by DHCP snooping.
- Port Security is used to control access based on the source MAC address.
Note: - If the address is something other than the one learned or statically
configured, the switch “drops” the frame.
- To configure IP Source Guard, first enable DHCP Snooping:
Switch(config)# ip dhcp snooping
Switch(config)# ip dhcp snooping vlan “vlan-id”
P a g e | 315
- For the hosts that do not use DHCP, you can configure a static source IP-MAC binding
using the following command:
Switch(config)# ip source binding “mac-address” vlan “vlan-id” “ip-address”
interface “type mod/num.”
- Here, the host’s MAC address is bounded to a specific IP address, VLAN, and specific
switch port.
- Next, enable IP Source Guard on one or more switch ports using the following
commands:
Switch(config)# interface “type mod/num.”
Switch(config-if)# ip verify source [port security]
- The “ip verify source” command only inspects the source IP address only.
- The “ip verify source port security” command inspects the source IP-MAC binding.
- To verify the IP Source Guard status, use the following command:
Switch# show ip verify source [interface “type mod/num.”]
- If you need to verify the information contained in the source IP-MAC binding
database that is either learned or statically configured, use the following command:
Switch# show ip source binding [“ip-address”] [“mac-address”] [dhcp-snooping | static]
[interface “type mod/num.”] [vlan “vlan-id”]
c) Dynamic ARP Inspection (DAI):
- Hosts normally use the Address Resolution Protocol (ARP) to resolve an unknown
MAC address when the IP address is known.
- If a MAC address is needed so that a frame can be forwarded at Layer 2, a sender host
broadcasts an ARP request that contains the IP address of the target in question.
P a g e | 316
- The host using that IP address responds with an ARP reply containing its MAC
address.
- The ARP process works well among well-behaved users.
- However, an attacker can send its own ARP reply when it hears an ARP request being
broadcasted.
- The attacker’s ARP reply contains its own MAC address, causing the original
requester to think that it is bound to the IP address in question.
- The requester then will add the bogus ARP entry into its own ARP cache, only to
begin forwarding frames to the spoofed MAC address.
- In effect, this places the attacker’s right in the middle, and frames will be sent to the
attacker instead of another host or the default gateway.
- The attacker can interpret frames and examine the frame contents before forwarding it.
- This attack is known as ARP “poisoning” or ARP “spoofing”, and it is considered a
type of man-in-the-middle attack.
- The attacker wedges into the normal forwarding path, transparent to the end-user host.
- Cisco Catalyst switches can use the Dynamic ARP Inspection (DAI) feature to help
mitigate this type of attack.
- DAI works much like DHCP Snooping.
- All switch ports are classified as “trusted” or “untrusted”.
- The switch intercepts and inspects all ARP packets that arrive on an “untrusted” port.
Note: - No inspection is done on “trusted” ports.
- When an ARP reply is received on an “untrusted” port, the switch checks the MAC
and IP addresses reported in the ARP reply against trusted values on the switch.
- A switch can gather these trusted ARP information from statically configured entries
or from dynamic entries in the DHCP Snooping database.
Note: - DHCP Snooping must be enabled before enabling DAI.
P a g e | 317
- If an ARP reply contains spoofed (invalid) information that conflict with entries in the
trusted database, it is dropped and a log message is generated.
- This action prevents spoofed ARP entries from being sent and added to the other
hosts’ ARP caches.
- To enable DAI on one or more VLANs, use the following command:
Switch(config)# ip arp inspection vlan “vlan-range”
- You can give a single VLAN ID or a range of VLAN IDs by adding a first number
dash last number, for example, “1,5-7,9-12”.
- By default, all switch ports associated with the VLAN range are considered
“untrusted” ports.
- You should identify “trusted” ports as those that connect to other switches.
- In other words, the local switch will not inspect ARP packets arriving on “trusted”
ports, it will assume that the neighboring switch also is performing DAI on all of its
ports in that VLAN.
- To configure a switch port as a “trusted” port, use the following commands:
Switch(config)# interface “type mod/num.” Switch(config-if)# ip arp inspection trust
- If you have hosts with statically configured TCP/IP configuration, there will be no
entry in the DHCP Snooping database.
- Instead, you have to define static IP-MAC address binding that is permitted using an
ARP access list.
- To configure an ARP access list with one or more static entries, use the following
commands:
Switch(config)# arp access-list “arp-acl-name” Switch(config-acl)# permit ip host “sender-ip” mac host “sender-mac” [log]
Note: - Repeat the last command for every host with static TCP/IP configuration in
the VLAN.
P a g e | 318
- Now the ARP access list must be applied to DAI using the following command:
Switch(config)# ip arp inspection filter “arp-acl-name” vlan “vlan-range” [static]
- When ARP replies are intercepted by the switch, their contents are matched against the
entry configured in the ARP access list.
- If no match is found, the DHCP Snooping bindings database is checked next.
Note: - You can add the “static” keyword to prevent the DHCP bindings database
from being checked at all.
- In effect, this creates an implicit deny statement at the end of the ARP access list,
meaning if no match is found in the ARP access list, the ARP reply is considered a
spoofed (invalid) ARP reply.
- Finally, you can specify further validations on the contents of the ARP reply packets.
- By default, only the MAC and IP addresses contained within the ARP reply are
validated.
Note: - The ARP reply contains the target MAC address requested by the host.
- This does not take the actual MAC addresses contained in the Ethernet frame header of
the ARP reply.
- To validate that an ARP reply packet is really coming from the address listed inside it,
you can enable DAI validation using the following command:
Switch(config)# ip arp inspection validate {[src-mac] [dst-mac] [ip]}
- Be sure to specify at least one of the options:
src-mac Check the source MAC address in the Ethernet frame header against
the sender MAC address in the ARP reply.
dst-mac Check the destination MAC address in the Ethernet frame header
against the target MAC address in the ARP reply.
ip Check the sender’s IP address in all ARP requests against the target IP
address in all ARP replies.
P a g e | 319
Example: - Consider the following small network:
- DHCP Snooping is enabled with IP-MAC bindings database.
- DAI is enabled for all switch ports associated with VLAN 10 on an access-layer
switch (Switch-A).
- The uplink port (Gigabit Ethernet 0/1) to the distribution switch (Switch-B) is
considered a “trusted” port, and the same for Switch-B Gigabit Ethernet 0/1.
- To configure Switch-A, use the following command:
Switch-A(config)# ip arp inspection vlan 10 Switch-A(config)# arp access-list StaticARP Switch-A(config-acl)# permit ip host 10.1.1.1 mac host 0001.2C37.3A2D Switch-A(config)# ip arp inspection filter StaticARP vlan 10 Switch-A(config)# interface gigabitethernet 0/1 Switch-A(config-if)# ip arp inspection trust
- To show the DAI status information, use the following command:
Switch# show ip arp inspection
P a g e | 320
Best Practices for Securing Switches:
Configuring Secure Passwords:
- To configure an enable password to be used when entering the privileged mode on a
switch, use the following command:
Switch(config)# enable password “string”
- This password will be required to enter the privileged mode as shown:
Switch>enable Password:
- If you will show the running configuration on the switch, the password string
configured will appear as a clear text, which is not recommended.
- To automatically encrypt “all” password strings that are stored in the switch
configuration, use the following command:
Switch(config)# service password-encryption
- Alternatively, you should use the enable secret password and the enable password only
will appear as an encrypted text using the following command:
Switch(config)# enable secret {0 | 5 | level “value”} “string
- “0” The provided password string should be in clear text (unencrypted).
- “5” The provided password string should be in an encrypted format.
- To configure a username and password locally on a switch:
Switch(config)# username “name” password “string”
- If the “service password-encryption” is configured, the password string will appear as
an encrypted text in the switch running configuration.
P a g e | 321
- Alternatively, you should use external AAA servers to authenticate administrative
users and assign levels of execution for each user, the level can range from 1 to 15.
- The usernames and passwords are maintained externally, so they are not stored or
managed directly on the switch.
- In addition, having a centralized user management is much more scalable than
configuring and changing user credentials on every individual switch.
Configuring System Banners:
- When accessing a switch, some information can be displayed before users are
prompted to provide their credentials to access the switch.
- This information is called “system banners” or message of the day “motd” and can be
used to warn unauthorized users (if they gain a remote access) that their activities
could be grounds for prosecution or they are unwelcome.
- Also, systems banners can be used for the authenticated users to display information
about the organization of this specific switch before they actually log in.
Note: - Do not add extra information about your network that malicious users can
use.
- To configure system banners, use the following command followed by character ‘c’:
Switch(config)# banner motd c Enter TEXT message. End with the character ‘c’ **************************** THE ROAD NETWORK **************************** c
- Now, try to log out of the switch and connect again to check the text you added.
Securing the Web Interface:
- You can use the web browser to remotely connect to a switch web interface over
HTTP or HTTPS instead of using CLI over Telnet or SSH.
- If you decided to use the web interface, be sure to use the HTTPS, if it is supported on
the switch.
P a g e | 322
- The difference between using HTTP and HTTPS is that HTTPS sends data encrypted
and secured.
- By default, the web interface is disabled, to enable the HTTPS web interface, use the
following command:
Switch(config)# ip http secure server
- To enable the standard HTTP web interface, use the following command:
Switch(config)# ip http server
- In addition, try to limit the source IP addresses that can connect to the web interface
through the web browser.
- To do so, first create an access list that permits only approved source IP addresses,
then apply the access list to the web interface.
- To configure a web interface with limited source IP addresses:
Switch(config)# ip http secure server Switch(config)# access list 1 permit 10.10.10.0 0.0.0.255 Switch(config)# ip http access-class 1
- Now, only hosts with IP address within the (10.10.10.0/24) subnet are allowed to
connect to the switch web interface when typing the switch IP address in the web
browser.
- Then, only those host are allowed to connect and provide the user credentials to access
the switch web interface.
Securing the Switch Console:
- In many environments, switches are locked away where physical security (using racks)
is used to keep people away from connecting to the switch console port.
- Even so, you always must configure user authentication on any switch console port.
- To configure user authentication on the switch console port:
Switch(config)# line console 0 Switch(config-line)# login local
P a g e | 323
Securing the Virtual Terminal Access:
- You must configure user authentication on “all” the vty lines on a switch.
- In addition, you should use access lists to limit the source IP addresses of potential
administrative users who try to use Telnet or Secure Shell (SSH) to access a switch.
- To configure virtual terminal access with limited number of source IP addresses, use
the following command:
Switch(config)# access-list 2 permit 10.10.20.0 0.0.0.255 Switch(config)# line vty 0 15 Switch(config-line)# login local Switch(config-line)# access-class 2 in
Note: - Be sure to apply the access list to all the “line vty” entries in the switch
configuration.
- Many times the vty lines are separated into groups in the configuration.
- To show every possible line that can be used to access a switch:
Switch# show user all
Using SSH:
- Although Telnet access is easy to configure and use, Telnet is not secure.
- Every character you type is a Telnet session is sent to a switch in clear text.
- Therefore, it is very easy to eavesdrop on Telnet sessions to overhears usernames and
passwords.
- Instead, you should use SSH whenever possible.
- SSH uses strong encryption to secure session data.
- Therefore, you need a strong-encryption IOS image running on a switch before SSH
can be configured and used.
- You should use the highest SSH version that is available on a switch.
- The early SSHv1 and SSHv1.5 have some weaknesses, so you should choose SSHv2
whenever possible.
P a g e | 324
Securing SNMP Access:
- To prevent unauthorized users from making changes to a switch configuration, you
should disable any read-write SNMP access using the following command:
Switch(config)# no snmp-server community “string” rw
- Instead, you should have only read-only configuration using the following command:
Switch(config)# snmp-server community “string” ro
Note: - Do not depend on the SNMP community strings for security because they
are passed in clear text in SNMP packets.
Securing Unused Switch Ports:
- Every unused switch port should be disabled so that unexpected users cannot connect
and use them without your knowledge.
- To disable the usage of a switch port, use the following interface configuration
command:
Switch(config-if)# shutdown
- In addition, you should configure every user port as an access port using the following
macro command:
Switch(config-if)# switchport host
- This macro do the following:
Switchport mode will be set to access.
Spanning-tree portfast will be enabled.
Channel group will be disabled.
- If ports are not configured as access ports, a malicious user might connect and attempt
to negotiate trunking mode on a port.
P a g e | 325
- You also should consider associating every unused access port with an isolated
VLAN.
- If an unexpected user does gain access to a port, he will have access only to a VLAN
that is isolated from every other resource in your network.
Securing STP Operation:
- You always should enable the BPDU Filtering feature so that access switch ports
automatically filter unexpected BPDUs received.
Securing the Use of CDP:
- By default, CDP advertisements are sent on “every” switch port at 60-seconds interval.
- Although CDP is a very handy tool for discovering neighboring Cisco devices, you
should not allow CDP to advertise unnecessary information about your switch to
listening attackers.
- For example, the following information is sent in a CDP advertisement in clear text.
- An attacker might use the device ID to physically locate the switch, its IP address to
target Telnet or SNMP attacks, or the native VLAN switch port ID to attempt a VLAN
hopping attack.
CDP - Cisco Discovery Protocol Version: 2 Time to live: 180 seconds Checksum: 0xD0AE Device ID: BldgA-Rm110 Version: Cisco Internetwork Operating System Software .IOS (tm) C3750 Software (C3750-I9-M), Version 12.2(20)SE4, RELEASE SOFTWARE (fc1).Copyright 1986-2005 by cisco Systems, Inc..Compiled Tu 28-Nov-14 00:09 by antonino Platform: cisco WS-C3750-48P IP Address: 192.168.1.10 Port ID: FastEthernet1/0/1 Capabilities: 0x00000028 Switch IGMP VTP Domain: DomainName Native VLAN: 10 Duplex: 0x01 Full
P a g e | 326
- CDP should be enabled only on switch ports that connect to other trusted Cisco
devices.
Note: - Do not forget that CDP must be enabled on access switch ports where Cisco
IP Phones are connected.
- When the CDP messages reach the IP Phone, they will not be relayed on to a PC
connected to the IP Phone’s PC port.
- You can disable CDP on a port-by-port basis using the following command:
Switch(config-if)# no cdp enable
P a g e | 327
Chapter 16 Securing With VLANs
VLAN Access Control Lists (VACLs):
- VACLs can filter Layer 2 frames “within” a VLAN based on their MAC addresses.
- VACLs are merged into the TCAM and they can permit “forward”, deny “drop”, or
“redirect” frames that are matched.
- VACLs are configured as a VLAN access map in the same format as a route map.
- A VLAN access map consists of one or more statements, each having a common map
name.
VACL Configuration :
- First, define a MAC access list using the following commands:
Switch(config)# mac access-list extended “acl-name” Switch(config-ext-macl)# permit host “source-mac-addr.” {host “dest.-mac-addr.” | any}
- Next, define a VLAN access map globally using the following command:
Switch(config)# vlan access-map “map-name” “sequence-number”
- Access map statements are evaluated in sequence according to the “sequence-number”
(a number that can range from 0 to 65,535).
- Each access map statement can contain one or more matching conditions, followed by
an action.
- To define a matching condition that identify the frames to be filtered and the action to
be taken, use the following commands:
Switch(config-access-map)# match mac address “acl-name” Switch(config-access-map)# action {drop | forward | redirect “type mod/num.”}
- The TCAM performs the entire VACL match and action as frames are switched within
a VLAN.
P a g e | 328
- Finally, you must apply the VACL to a VLAN using the following command:
Switch(config)# vlan filter “map-name” vlan-list {“vlan-id” | all}
Example: - Consider the following small network:
- We need to filter PC2 traffic within VLAN 10, so that PC2 is not allowed to send
frames to any other host in the local VLAN (subnet).
- To configure Switch-A, use the following commands:
Switch-A(config)# mac access-list extended block-pc2-mac Switch-A(config-ext-macl)# permit host 0001.2d3a.873e any Switch-A(config)# vlan access-map block-pc2-traffic 5 Switch-A(config-access-map)# match mac address block-pc2-mac Switch-A(config-access-map)# action drop Switch-A(config)# vlan access-map block-pc2-traffic 15 Switch-A(config-access-map)# action forward Switch-A(config)# vlan filter block-pc2-traffic vlan-list 10
P a g e | 329
Private VLANs (PVLANs):
- Normally, traffic is allowed to move unrestricted within a VLAN.
- Frames sent from one host to another (unicast frames), are heard only by the
destination host because of the nature of Layer 2 switching.
- However, if one host broadcasts a frame, all hosts on the same VLAN will receive the
frame.
- Sometimes it would be nice to have the capability to segment traffic within a single
VLAN, without having to use multiple VLANs and a Layer 3 device.
- For example, in a single VLAN server farm, all servers should be capable of
communicating with the gateway, but the servers should not have to listen to each
other’s broadcast traffic.
- Taking this a step further, suppose each server belongs to a separate organization.
- Now, each server should be isolated from the other servers but still be capable of
reaching the gateway to find hosts not on the local network.
- Also, the servers do not need to communicate with each other.
- Private VLANs (PVLANs) solve this problem on Catalyst switches.
- There are two types of VLANs:
Primary VLAN (normal) Is the head of the structure of the VLAN, all the
secondary VLANs are associated to the primary
VLAN.
Secondary VLAN Allow hosts to communicate with ports on the primary
VLAN (a multilayer switch, for example), but does not
allows hosts to communicate with another secondary VLAN.
- A secondary VLAN is configured as one of the following types:
Isolated VLAN - Any switch port associated with an isolated VLAN can
communicate with the primary VLAN but not with any other
secondary VLAN.
- In addition, hosts associated with the same isolated VLAN
cannot communicate with each other.
P a g e | 330
Note: - Hosts in an isolated VLAN are isolated from anything except the primary
VLAN.
Community VLAN - Any switch port associated with a community VLAN can
communicate with the primary VLAN but not with any
other secondary VLAN.
- In addition, hosts associated with the same community
VLAN can communicate with each other.
Note: - All secondary VLANs must be associated with one primary VLAN to set up
the uni-directional relationship.
Primary VLAN-A
Secondary VLAN-A Secondary VLAN-B Secondary VLAN-C
Isolated Community
VLAN VLAN
Isolated VLAN Community VLAN
Can communicate with the primary VLAN. Can communicate with the primary VLAN.
Cannot communicate with any other
secondary VLAN.
Cannot communicate with any other
secondary VLAN.
Hosts cannot communicate with each other. Hosts can communicate with each other.
Connects to a “host” switch port. Connects to a “host” switch port.
- Private VLANs are configured using special cases of regular VLANs.
- However, the VLAN Trunking Protocol (VTP) does not pass any information about
the Private VLAN (PVLAN) configuration.
- Therefore, PVLANs are only locally significant to a switch.
- Each of the private VLANs must be configured locally on each switch that
interconnects them.
P a g e | 331
- You must configure each switch port that uses a PVLAN with one of the following
two modes:
Host mode port The switch port connects to a regular host that resides on a
secondary VLAN (isolated or community VLAN).
Promiscuous mode port - The switch port connects to a gateway device
(multilayer switch, router, or firewall).
- This port can communicate with anything else
connected to the primary or any secondary VLAN
and will receive all traffic going outside of the local
subnet.
- The following figure shows the basic PVLAN operation:
Private VLAN (PVLAN) Operation
- Switch-A and Switch-B ports Gigabit Ethernet 0/1 are promiscuous ports connecting
to the gateway (Switch-C).
- Some hosts (PC3, PC4, PC7, and PC8) connect to a secondary Community VLAN 10.
- Some hosts (PC5 and PC6) connects to a secondary Isolated VLAN 20, and so on.
- All secondary VLANs are associated with a primary VLAN 100.
P a g e | 332
PVLAN Configuration:
- To configure a PVLAN, begin by defining all secondary VLANs that are needed using
the following commands:
Switch(config)# vlan “vlan-id” Switch(config-vlan)# private-vlan {isolated | community}
- Then, define the primary VLAN with all its component secondary VLANs using the
following command:
Switch(config)# vlan “vlan-id” Switch(config-vlan)# private-vlan primary Switch(config-vlan)# private-vlan association “secondary-vlan-list”
- If the primary VLAN has been already configured, you can “add” or “remove”
secondary VLAN association using the following commands:
Switch(config)# vlan “vlan-id” Switch(config-vlan)# private-vlan primary Switch(config-vlan)# private-vlan association {add “secondary-vlan-list” | remove
“secondary-vlan-list”}
- Then, you must associate the individual switch ports with their respective secondary
VLANs using the following interface configuration command:
Switch(config-if)# switchport mode private-vlan {host | promiscuous}
- For “host” ports, you must associate the switch port with the appropriate primary and
secondary VLANs using the following command:
Switch(config-if)# switchport private-vlan host-association “primary-vlan-id” “secondary-vlan-id”
- When a switch port is associated with private VLANs, you do not have to configure a
static access VLAN.
- Instead, the switch port takes membership in the primary and secondary VLANs
simultaneously.
P a g e | 333
- This does not mean that the port has a fully functional assignment to multiple VLANs.
- Instead, it takes only the unidirectional behavior between the secondary and primary
VLANs.
- For “promiscuous” port, you must map the port to primary and secondary VLANs
using the following command:
Switch(config-if)# switchport private-vlan mapping “primary-vlan-id” “secondary-vlan-list”
- If the promiscuous port mapping is already exist, you can add or remove secondary
VLAN list using the following command:
Switch(config-if)# switchport private-vlan mapping “primary-vlan-id” {add “secondary-vlan-list” | remove “secondary-vlan-list”}
Example: - Consider the following small network:
- We need to configure the PVLANs as shown in the previous figure.
- To configure Switch-A, use the following commands:
Switch-A(config)# vlan 10 Switch-A(config-vlan)# private-vlan community Switch-A(config)# vlan 40 Switch-A(config-vlan)# private-vlan isolated
P a g e | 334
Switch-A(config)# vlan 100 Switch-A(config-vlan)# private-vlan primary Switch-A(config-vlan)# private-vlan association 10,40 Switch-A(config)# interface range fastEthernet 0/1 – 2 Switch-A(config-range-if)# switchport mode private-vlan host Switch-A(config-range-if)# switchport private-vlan host-association 100 40 Switch-A(config)# interface range fastEthernet 0/3 – 4 Switch-A(config-range-if)# switchport mode private-vlan host Switch-A(config-range-if)# switchport private-vlan host-association 100 10 Switch-A(config)# interface gigabitethernet 0/1 Switch-A(config-if)# switchport mode private-vlan promiscuous Switch-A(config-if)# switchport private-vlan mapping 100 10,40
- To configure Switch-B, use the following commands:
Switch-A(config)# vlan 10 Switch-A(config-vlan)# private-vlan community Switch-A(config)# vlan 20 Switch-A(config-vlan)# private-vlan isolated Switch-A(config)# vlan 30 Switch-A(config-vlan)# private-vlan community Switch-A(config)# vlan 100 Switch-A(config-vlan)# private-vlan primary Switch-A(config-vlan)# private-vlan association 10,20,30 Switch-A(config)# interface range fastEthernet 0/1 – 2 Switch-A(config-range-if)# switchport mode private-vlan host Switch-A(config-range-if)# switchport private-vlan host-association 100 20 Switch-A(config)# interface range fastEthernet 0/3 – 4 Switch-A(config-range-if)# switchport mode private-vlan host Switch-A(config-range-if)# switchport private-vlan host-association 100 10 Switch-A(config)# interface range fastEthernet 0/5 – 6 Switch-A(config-range-if)# switchport mode private-vlan host Switch-A(config-range-if)# switchport private-vlan host-association 100 30 Switch-A(config)# interface gigabitethernet 0/1 Switch-A(config-if)# switchport mode private-vlan promiscuous Switch-A(config-if)# switchport private-vlan mapping 100 10,20,30
- To verify that all PVLANs are created and active, use the following commands:
Switch# show vlan private-vlan
Switch# show vlan private-vlan type
Switch# show vlan id “vlan-id”
P a g e | 335
Associate Secondary VLANs to a Primary VLAN SVI:
- On switched Virtual Interfaces (SVI) or VLAN interfaces configured with Layer 3
addresses, you should configure some additional private VLAN (PVLAN) mappings.
Example: - Consider the following example:
- Primary VLANs 100 and 200 can forward traffic between each other at Layer 3, but
secondary VLANs associated with each one should be mapped to each primary VLAN
SVI using the following command:
Switch(config)# interface vlan “vlan-id” Switch(config-if)# private-vlan mapping “secondary-vlan-list”
- The primary VLAN SVI function should be extended to the secondary VLANs.
- If some mapping already has been configured for the primary VLAN SVI, you can
“add” or “remove” secondary VLAN mappings individually using the following
command:
P a g e | 336
Switch(config-if)# private-vlan mapping {add “secondary-vlan-list” | remove “secondary-vlan-list”}
- From the previous example, to map the secondary VLANs to the primary VLAN SVI
configured on Switch-C, use the following commands:
Switch-C(config)# interface vlan 100 Switch-C(config-if)# ip address 10.1.1.1 255.0.0.0 Switch-C(config-if)# private-vlan mapping 10,20 Switch-C(config)# interface vlan 200 Switch-C(config-if)# ip address 192.168.1.0 255.255.255.0 Switch-C(config-if)# private-vlan mapping 30,40
Securing VLAN Trunks:
- Trunk links can be formed between two switches.
- Each end of the trunk is connected to a switch that is under your control, and VLANs
carried over the trunk remain isolated.
- Some attacks can be leveraged to gain access to a trunk link or to the VLANs that are
carried over the trunk.
- Therefore, you should become familiar with how the attacks work and what steps you
can take to prevent them in the first place.
Switch Spoofing:
- Recall that two switches can be connected by a common trunk link that can carry
traffic from multiple VLANs.
- The switches dynamically can negotiate a trunk link and its encapsulation mode by
exchanging Dynamic Trunking Protocol (DTP) messages.
- Although DTP can make switch administration easier, it also can expose switch ports
to be compromised.
- Suppose that a switch port is left to its default configuration, in which the trunking
mode is “dynamic auto”.
P a g e | 337
- Normally, the switch port would wait to be asked by another switch in the “dynamic
desirable” mode to become a trunk.
- Now, suppose that an end user connected a switch to that switch port as shown in the
following figure:
An Example of Switch Spoofing To Gain Access To a Trunk
- After the trunk link is negotiated between Switch-A and the attacker’s rogue Switch,
the attacker can connect a rogue PC to the rogue switch and assign it an access port
configured with VLAN 10.
- The attacker can have access to the VLAN 20, where a server resides, through the
trunk link between Switch-A and Switch-B that carry both VLANs 10 and 20.
- The solution to this situation is to configure “every” unused switch port to have an
expected and controlled behavior.
- So, instead of leaving the end-user unused switch ports set to use the default
configuration, configure them all to a be in static access mode and assigned to a
specific VLAN using the following commands:
P a g e | 338
Switch(config)# interface “type mod/num.” Switch(config-if)# switchport mode access Switch(config-if)# switchport access vlan “vlan-id”
- This way, the end-user host never will be able to negotiate a trunk.
- In addition, you might be wise to disable any unused switch ports to prevent someone
from discovering a live port using the following commands:
Switch(config)# interface “type mod/num.” Switch(config-if)# shutdown
P a g e | 339
Chapter 17 Logging Switch Activity
Syslog Messages:
- You should leverage the logging system available in each switch so that you can
collect messages as they are generated.
- This will allow you to monitor the network, detect failures, and gather information
about switch activity.
- Catalyst switches can be configured to generate an audit trail of messages describing
important events that have occurred.
- These system log (syslog) messages can then be collected and analyzed to determine
what has happened, when it happened, and how severe the event was.
- When syslog messages are generated, they always appear in a consistent format as
shown in the following figure:
Catalyst Switch Syslog Message Format
- For example, the following syslog message tells that Fast Ethernet 0/6 has a different
duplex mode than other ports in the EtherChannel bundle:
27w5d: %EC-5-CANNOT_BUNDLE2: FastEthernet0/6 is not compatible with FastEthernet0/7 and
will be suspended (duplex of Fa0/6 is full, Fa0/7 is half)
- Each syslog message contains the following fields:
Time Stamp - The date and time from the internal switch clock.
- By default, the amount of time that the switch has been up is used
in the time stamp, if the internal switch clock is set, then it will be
used instead.
- The time stamp in the previous example is (27w5d).
P a g e | 340
Facility Code - A system identifier that categorizes the switch function or
module that has generated the message.
- The facility code always begins with a percent sign %.
- The facility code in the previous example is (%EC), meaning
EtherChannel.
Severity - A number from 0 to 7 that indicates how important or severe the
event is.
- A lower severity means the event is more critical.
- The severity level in the previous example is (5).
Mnemonic - A short text string that categorizes the event within the facility
code.
- The mnemonic in the previous example is (CANNOT_BUNDLE2),
meaning one physical port cannot be bundled within an existing
EtherChannel bundle.
Message Text - A detailed description of the event or condition that triggered the
syslog message.
- The message text in the previous example is (FastEthernet0/6 is
not compatible with FastEthernet0/7 and will be suspended
(duplex of Fa0/6 is full, Fa0/7 is half))
Note: - You should configure a switch to generate syslog messages that are
occurring at or above a certain level (threshold) of importance.
- Otherwise, you may collect too much information from a switch that log
absolutely everything or too little information that logs almost nothing.
- You can use the severity level to define that threshold.
- The following table shows each of the syslog severity levels, along with a general list
of the types of messages that are generated:
P a g e | 341
Severity Level Importance or Severity Syslog Message Types
Debugging (7) Low
High
- Debug Output.
Informational (6)
- VTP.
- STP.
- UDLD.
- Port Security.
- Dynamic ARP Inspection.
- Stack Events.
- Hardware Diagnostics.
Notifications (5)
- STP.
- EtherChannel.
- Inline Power.
- 802.1x.
- DTP.
- Interface Line Protocol.
Warnings (4) - DHCP Snooping.
Errors (3)
- ACL Issues.
- TCAM Issues.
- PAgP Problems.
- Ethernet Controller.
- Interface up/down.
Critical (2)
- Hardware Issues.
- STP.
- Port Security.
Alerts (1) - Platform Errors.
Emergencies (0) - Crashes.
- Stopped Processes.
Note: - When you configure the severity level threshold on a switch, that switch will
only generate syslog messages that occur at that level or at any other level
“below” it.
P a g e | 342
- For example, if the syslog severity level is set to Critical (severity level 2), the switch
will generate syslog messages in the following levels as well:
Critical (Level 2).
Alerts (Level 1).
Emergencies (Level 0).
- The severity levels are numbered such that the most urgent events are reported at level
(0) and the least urgent at level (7).
- Syslog messages can be sent to:
a) The switch console.
b) The internal memory buffer.
c) A remote syslog server.
a) Logging to the Switch Console:
- By default, syslog messages are sent to the switch console port at the “Debugging”
Severity Level (7).
- To change the console severity level, use the following command:
Switch(config)# logging console “severity-level”
- “severity-level” Can be either a severity level keyword (such as Notifications) or
the corresponding numeric value (0 to 7).
- The switch console is not a very efficient way to collect and view syslog messages
because of its low throughput.
- If you are connected to a switch through a Telnet or Secure Shell (SSH) session, you
can redirect the console syslog messages to your remote session by using the
following command:
Switch# terminal monitor
P a g e | 343
b) Logging to the Internal Buffer:
- Every Catalyst switch has an internal memory buffer where syslog messages can be
collected.
- The internal buffer is an efficient way to collect messages over time.
- As long as the switch is powered up, the syslog buffer is available.
- By default, logging to the internal buffer is disabled.
- To enable logging to the internal buffer, use the following command:
Switch(config)# logging buffered “severity-level”
- “Severity-level” Can be either a severity level keyword (such as Notifications), or
the corresponding numeric value (0 to 7).
- The logging internal buffer has a finite size and operates in a circular fashion.
- If the buffer fills, the oldest messages roll off as new ones arrive.
- By default, the logging internal buffer is 4096 bytes or characters long, which is
enough space to collect 50 lines of full-length text.
- To increase the size of the logging internal buffer, use the following command:
Switch(config)# logging buffered “size”
- “size” A value from 4096 to 2147483647 bytes (Default is 4096).
Note: - Be careful not to set the size too big because the switch reserves the logging
buffer space from the memory it might need for other operations.
- To review the logging internal buffer at any time, use the following command:
Switch# show logging
P a g e | 344
c) Logging to a Remote Syslog Server:
- Logging to remote syslog server(s) is the most robust method of collecting syslog
messages.
- Syslog messages are sent from a switch to a remote syslog server(s) over the network
using UDP port 514.
Note: - UDP is not a reliable means of communication because it is not connection-
oriented like TCP.
- Therefore, syslog messages sent by the switch to a remote syslog server are
not acknowledged, they are just sent toward a syslog server on a best effort
basis.
- A syslog server can collect syslog messages from many different devices (switches or
routers) simultaneously and can archive the syslog messages for a long period of time.
- To identify a syslog server and begin sending syslog messages to it, use the following
commands:
Switch(config)# logging host “ip-address | host-name” Switch(config)# logging trap “severity-level”
Note: - You can enter the “logging host” command more than once if you have more
than one syslog server collecting the syslog messages for redundancy.
- Each of the syslog message destination syslog servers have the same
“severity-level” configured.
Note: - You can use more than one logging method on the same switch each with a
unique severity level configured.
- By default, a switch will generate a syslog message every time it detects an interface
going up or down.
- That sound a good thing, until you realize that the syslog server will be receiving
syslog messages of every user powering their PC on and off each day.
- Each link state change will generate a message at the Errors (3) severity level, in
addition to a line protocol state change at the Notifications (5) severity level.
P a g e | 345
- To prevent this from happening with access-layer switch interfaces where end users
are connected, use the following interface configuration command:
Switch(config-if)# no logging event link-status
Adding the Switch Clock to the Syslog Messages Time Stamps:
- By default, Catalyst switches add a simple “uptime” time stamp to syslog messages.
- This is the cumulative counter that shows the hours, minutes and seconds since the
switch has been booted.
Note: - With the “uptime” time stamp, you will have to backtrack and compute the
time of the event based on how long the switch has been operating.
- Even worse, as time goes on, the “uptime” time stamps becomes more coarse
and difficult to interpret, as timestamps will appear as weeks and days (such
as, 27w5d).
- Instead of using the default “uptime” time stamp, you can configure the switch to use
the switch clock as an accurate time stamp for syslog messages.
- To begin adding the switch clock to the syslog messages time stamps, use the
following command:
Switch(config)# service timestamps log datetime [localtime] [show-timezone] [msec] [year]
- “datetime” Times stamps with date and time.
Note: - The default is “uptime”, where time stamps are with system uptime.
- “localtime” To use the local time zone configured on the switch; otherwise,
coordinated Universal time (UTC) is assumed.
- “show-timezone” To add the time zone name to the time stamps.
- “msec” To add milliseconds to the time stamps.
- “year” To add the year to the time stamps.
P a g e | 346
- In the following example, the local time zone and milliseconds have been added to the
time stamps of the syslog messages shown:
Switch(config)# service timestamps log datetime localtime show-timezone msec
- To show the result time stamps in the syslog messages, use the following command:
Switch# show logging *Feb 4 09:55:57.139 EDT: %SYS-5-CONFIG_I: Configured from console by console
Setting the Internal System Clock:
- The devices (Switches, routers, and firewalls) internal system clock can be adjusted
using two methods:
a) Locally on each device.
b) Using Network Time Protocol (NTP) Server.
a) Setting the internal system clock locally on each switch:
- Each switch has an internal time clock that runs continuously without any intervention.
- However, do not assume that a switch already has its internal clock set to the correct
date and time.
- To show the switch clock, use the following command:
Switch# show clock
- The default switch clock time is Mon Mar 1 1993.
- To adjust the switch clock locally, use the following command:
Switch# clock set “hh:mm:ss” “day” “month” “year”
P a g e | 347
- To define the time zone, use the following command:
Switch(config)# clock timezone “name” “offset-hours”
- To define the summer time (daylight savings), use the following command:
Switch(config)# clock summer-time “name” date “start-month” “date” “year” “hh:mm” “end-month” “day” “year” “hh:mm”
Or
Switch(config)# clock summer-time “name” recurring “start-week” “day” “month” “hh:mm” “end-week” “day” “month” “hh:mm”
- For example, to set the clock to 05:37 PM and the date to 4th of February, 2015 and the
time zone to GMT+02:00, use the following commands:
Switch# clock set 17:37:00 4 February 2015 Switch(config)# clock timezone GMT+2 2 Switch(config)# clock summer-time GMT recurring
Note: - If no other parameters are given with the “clock summer-time recurring”
command, the U.S. daylight savings time is assumed.
b) Using NTP Server:
- To synchronize clocks across multiple switches in your network from common and
trusted time sources, you can use the Network Time Protocol (NTP) server(s).
- Each switch still maintains its own internal clock, but each periodically synchronizes
its clock with one or more external time sources (NTP servers).
- The goal is to synchronize clocks with some level of implied trust that the time is
accurate across all switches.
- NTP can also cope with the delay that occurs from the time the NTP server transmits
its current time until a switch receives the message.
- NTP servers can be arranged in a hierarchical fashion with each layer of time servers
synchronizing with other NTP servers in a higher layer.
P a g e | 348
Note: - It often is not practical or scalable to point every device in your network
toward one NTP server.
- Each layer of the hierarchy is known as a “stratum”.
- The stratum number indicates the number of hops needed to reach the top NTP Server
with the authoritative time source (clock) as shown in the following figure:
NTP Hierarchy
- The authoritative time sources are located in stratum 1.
- NTP clients that synchronize with stratum 1 NTP servers are designated as stratum 2.
Note: - You can configure all of your devices (switches, routers, and firewalls) to
synchronize their clock with your stratum 1 NTP server.
- For a more scalable solution, you can configure a few centrally located
switches as NTP servers (stratum 2) serving stratum 3 NTP clients (peers).
- The NTP stratum numbers also can serve as an indicator of time accuracy.
- For instance, if a device has a choice of synchronizing with a stratum 3 NTP server or
a stratum 4 NTP server, it will prefer the stratum 3 server because it is ultimately
better synchronized with an authoritative source.
- The NTP modes that a switch can use are:
Server The switch synchronizes with NTP server and provides time
synchronization for NTP clients.
Client (peer) The switch synchronizes its clock with an NTP server.
P a g e | 349
- To configure a switch to synchronize with NTP server(s), use the following command:
Switch(config)# ntp server “ip-address” [prefer] [version {3 | 4}]
- “ip-address” IP address of the NTP server.
Note: - You can repeat the “ntp server” command to specify more than one NTP
server to use.
- In that case, you can add the “prefer” keyword to identify which server to
prefer over others.
- By default, NTP version 3 is used, whereas NTP version 4 adds IPv6 capability.
- To configure a switch to synchronize NTP client (peer), use the following command:
Switch(config)# ntp peer “ip-address” [prefer] [version {3 | 4}]
- “ip-address” IP address of the NTP client.
- After NTP is configured, you can verify that the switch clock is synchronized to the
NTP server using the following command:
Switch# show ntp status
- To show a summary of all NTP servers a switch is associated to, use the following
command:
Switch# show ntp association
Note: - The NTP server does not provide a time zone, so you should use the “clock
timezone” command to configure a switch to reference the NTP time to its
local settings.
- To show the clock after it is synchronized with the NTP server, use the following
command:
Switch# show clock
P a g e | 350
NTP Authentication:
- The NTP configurations in the preceding section reference only the IP address of the
NTP server, implying that time synchronization is open for any device to use.
- Without NTP authentication, an NTP client can synchronize its clock with an attacker
posing as an NTP server.
- To configure NTP authentication in your network, do the following steps:
Step 1 Define an authentication key and specify the authentication key number.
Switch(config)# ntp authentication-key “key-number” md5 “string”
Step 2 Enable NTP authentication on both the NTP server and NTP client. To enable
NTP authentication on the NTP client (switch).
Switch(config)# ntp authenticate
Step 3 Trust the authentication key number.
Switch(config)# ntp trusted-key “key-number”
Step 4 Specify the authentication key number on both the NTP server and client
(switch).
Switch(config)# ntp server “ip-address” key “key-number”
Example: - Consider the following small network:
P a g e | 351
- To configure Switch-A, use the following commands:
Switch-A(config)# ntp authentication-key 1 md5 secret Switch-A(config)# ntp authenticate Switch-A(config)# ntp trusted-key 1 Switch-A(config)# ntp server 10.1.1.100 key 1 Switch-A(config)# ntp peer 10.1.1.2 key 1
- To configure Switch-B, use the following commands:
Switch-B(config)# ntp authentication-key 1 md5 secret Switch-B(config)# ntp authenticate Switch-B(config)# ntp trusted-key 1 Switch-B(config)# ntp peer 10.1.1.1 key 1
Note: - You must enable NTP authentication on the NTP server as well and provide
the same key number and key string (password).
- NTP authentication only provides a means to validate the server.
Simplified Network Time Protocol (SNTP):
- The “ntp server” command enables NTP so that a switch can synchronize its clock
with a specified NTP server.
- The “ntp server” command enables also the NTP service on every configured Layer 3
interface so that the switch becomes an NTP server for any other device that tries to
synchronize time with it.
- As its name implies, the SNTP offers a reduced set of NTP functions.
- When a switch is configured for SNTP, it operates as an NTP client only.
- In other words, the switch can synchronize its clock with an NTP server, but it cannot
allow other devices to synchronize from its own clock.
- To configure SNTP, use the typical NTP commands and substitute “sntp” instead of
“ntp” keyword as shown:
Switch-B(config)# sntp authentication-key 1 md5 secret Switch-B(config)# sntp authenticate Switch-B(config)# sntp trusted-key 1 Switch-B(config)# sntp server 10.1.1.1 key 1
P a g e | 352
Chapter 18 Managing Switches with SNMP
SNMP Overview:
- The Simple Network Management Protocol (SNMP) can be used to manage switches
and other network devices remotely.
- The SNMP enables a network device to share information about itself and its
activities.
- A complete SNMP system consists of the following:
SNMP Manager - A network management system that uses SNMP to poll and
receive data from any number of network devices.
- The SNMP manager usually is an application that runs in a
central location.
SNMP Agent - A process that runs on the network device being monitored.
- All types of data gathered by the monitored device itself are
stored in a local database.
- The SNMP agent can then respond to the SNMP manager polls
and queries with information from the database, and it can send
unsolicited alerts or traps to the SNMP manager as well.
- In the case of Catalyst switches in the network, each switch automatically collects data
about itself, its resources, and each of its interfaces.
- This collected data is stored in a Management Information Base (MIB) database in
memory and is updated in real time.
- An SNMP manager can use the following mechanisms to communicate with an SNMP
agent, all over UDP port 161:
Get request The value of one specific MIB variable is needed.
Get next request The next or subsequent value following an initial get request
is needed.
P a g e | 353
Get bulk request Whole tables or lists of values in a MIB variable are needed.
Set request A specific MIB variable needs to be set to a value.
- SNMP polls or requests are usually sent by the SNMP manager at periodic intervals.
- This makes real-time monitoring difficult because changing variables will not be
noticed until the next poll cycle.
- However, SNMP agents can send unsolicited alerts to notify the SNMP manager of
rea-time events at any time.
- Alerts can be sent using the following mechanisms over UDP port 162:
SNMP trap News of an event (interface state change, device failure, and so on)
is sent by the SNMP agent without any acknowledgment that the
trap has been received by the SNMP manager.
Inform request News of an event is sent to an SNMP manager, and the SNMP
manager is required to acknowledge receipt by echoing the
request back to the SNMP agent.
- A network management has evolved, SNMP has developed into three distinct versions:
SNMP Version 1 (SNMPv1) Is defined in RFC 1157.
SNMP Version 2c (SNMPv2c) Is defined in RFC 1901.
SNMP Version 3 (SNMPv3) Is defined in RFCs 3410 through 3415.
- The following table lists a comparison between SNMP versions and features:
Version Authentication Data Protection Unique features
SNMPv1 Community string None - 32-bit counters.
SNMPv2c Community string None
- Adds bulk request and
inform request
message types.
- 64-bit counters.
SNMPv3 Username
- Hash-based MAC
(SHA or MD5).
- DES, 3DES, and AES
(128, 192, and 256
bits) encryption.
- Adds user
authentication, data
integrity, and
encryption.
- Add restricted views.
P a g e | 354
- As a best practice, you should use SNMPv3 to leverage its superior security features
whenever possible.
- If you must use SNMPv1 for a device, you should configure the switch to limit SNMP
access because the simple community string authentication can be exploited to make
unexpected changes to a switch configuration.
- Catalyst switches offer one additional means of limiting SNMP access which is an
ACL that can be configured to permit only specific SNMP manager IP addresses.
Note: - You should configure and apply an ACL to your SNMP configurations
whenever possible.
SNMP Configuration:
- SNMP is normally available in three versions.
- As best practice, you should use SNMPv3.
a) SNMPv1 Configuration:
- To configure SNMPv1 on a switch, use the following steps:
Step 1 Define an IP ACL (standard or extended) that permit hosts that can access the
switch via SNMPv1.
Switch(config)# access-list “acl-number” permit “ip-address”
Step 2 Apply that ACL to the SNMPv1 community string.
Switch(config)# snmp-server community “community-string” [ro | rw] [“acl-number”]
- “ro” To allow read-only access by the SNMP manager.
- “rw” To allow read-write access by the SNMP manager.
P a g e | 355
Step 3 Identify the SNMP manager that will receive the traps.
Switch(config)# snmp-server host “ip-address” “community-string” [“trap-type”]
- By default, all types of traps are sent.
Note: - You can use the “?” key in place of “trap-type” to see a list of the available
trap types.
Example: - Consider the following small network:
- Switch-A should be configured to allow SNMP polling sent by the SNMP managers
installed at 10.1.1.5 and 192.168.1.9 only.
- The community string “Monitoring” is used to authenticate the SNMP requests.
- “All” possible SNMP traps are sent by the SNMP agent to 10.1.1.5 only.
- To configure Switch-A, use the following commands:
Switch-A(config)# access-list 5 permit 10.1.1.5 Switch-A(config)# access-list 5 permit 192.168.1.9 Switch-A(config)# snmp-server community Monitoring ro 5 Switch-A(config)# snmp-server host 10.1.1.5 Monitoring
b) SNMPv2c Configuration:
- Configuring SNMPv2c is similar to configuring SNMPv1.
- The only difference is with SNMP trap or inform configuration.
P a g e | 356
- To configure SNMPv2c on a switch, use the following commands:
Switch(config)# access-list “acl-number” permit “ip-address” Switch(config)# snmp-server community “community-string” [ro | rw] “acl-number” Switch(config)# snmp-server host “ip-address” [informs] version 2c “community-string”
- In the “snmp-server host” command, use the “version 2c” keywords to identify
SNMPv2c operation.
- By default, regular SNMP traps are sent.
- To use inform requests instead, add the “inform” keyword.
c) SNMPv3 Configuration:
- SNMPv3 configuration is a bit more involved than versions 1 or 2c, due mainly to the
additional security features.
- To configure SNMPv3 on a switch, use the following steps:
Step 1 Define an IP ACL (standard or extended) that permits hosts that can access
the switch via SNMPv3.
Switch(config)# access-list “acl-number” permit “ip-address”
Step 2 Define a specific view for the users using the following command:
Switch(config)# snmp-server view “view-name” “oid-tree”
Note: - Only the MIB variables located under the OID name given as “oid-tree” will
be visible to the user group.
- For example, if “AdminStatus” contains the interface administrative status, if “Descr”
contains the interface description, and so on, you can repeat the “snmp-server view”
command to add additional OID names to the view.
Note: - If no view is configured, all MIB variables are visible to the users.
P a g e | 357
Step 3 Configure a group name that will set the security level policies for SNMPv3
users that are assigned to the group.
Switch(config)# snmp-server group “group-name” v3 {noauth | auth | priv} [read “read-view”] [write “write-view”] [notify “notify-view”] [access “access-list”]
- “v3” Configures the group to use SNMPv3.
- The security level is defined by:
“noauth” No packet authentication or encryption.
“auth” Packets are authenticated but not encrypted.
“priv” Packets are both encrypted and encrypted.
Note: - Only the security policy is defined in the group; no passwords or keys are
required yet.
- The SNMPv3 “priv” keyword and packet encryption can be used only if the
switch is running a cryptographic version of its Cisco IOS Software image.
- The “auth” keyword and packet authentication can be used regardless.
- If you configured a view, you can use the “read”, “write”, and “notify” keywords to
limit access to read, write, or notification operations.
- If you configured an access list, you can apply it to the group with the “access”
keyword.
Step 4 Define a username that an SNMP manager will use to communicate with the
switch and associate it with the SNMPv3 “group-name”.
Switch(config)# snmp-server user “user-name” “group-name” v3 auth {md5 | sha} “auth-password” priv {des | 3des | aes} {128 | 192 | 256} “priv-password” [“acl-number”]
- The SNMPv3 user must also have some specifics added to its security policy.
- “auth” Defines the authentication method [Message Digest 5 (MD5) or Secure
Hash Algorithm (SHA)], along with the “auth-password” text string that
will be used in the authentication process.
P a g e | 358
- “priv” Defines the encryption method (DES, 3DES, or AES) and encryption keys
(128, 192, or 256 bits), along with the “priv-password” text string that will
be used in the encryption algorithm.
- DES Data Encryption Standard.
- 3DES Triple-Data Encryption Standard.
- AES Advanced Encryption Standard.
Note: - The same SNMPv3 username, authentication method and password, and
encryption method and password must also be defined on the SNMP
manager so it can successfully communicate with the switch.
Step 5 Identify the SNMP manager that will receive either the traps or informs.
Switch(config)# snmp-server host “ip-address” [informs] version 3 {noauth | auth | priv} “username” [“trap-type”]
Note: - The switch can use SNMPv3 to send traps and informs, using the security
parameters that are defined for the SNMPv3 username.
Example: - Consider the following small network:
- Switch-A should be configured to allow SNMPv3 polling sent by the SNMP managers
installed at 10.1.1.5 and 192.168.1.9 only.
- SNMPv3 access is defined for a group named “Operations” using the priv
(authentication and encryption) security level.
P a g e | 359
- On SNMPv3, a user named “User-1” is defined; the SNMP manager will use that
username when it polls the switch for information.
- The username will require SHA packet authentication and AES-128 encryption, using
the “secret-1” and “secret-2” passwords, respectively.
- Finally, SNMPv3 informs will be used to send alerts to host 10.1.1.5 only using the
priv security level and username “User-1”.
- To configure Switch-A, use the following commands:
Switch-A(config)# access-list 5 permit 10.1.1.5 Switch-A(config)# access-list 5 permit 192.168.1.9 Switch-A(config)# snmp-server group Operations v3 priv Switch-A(config)# snmp-server user User-1 Operations v3 auth sha secret-1 priv aes 128
secret-2 5 Switch-A(config)# snmp-server host 10.1.1.5 informs version 3 priv User-1
P a g e | 360
Chapter 19 Monitoring Performance with IP SLA
IP SLA Overview:
- The IOS IP Service Level Agreement (IP SLA) feature enables you to gather realistic
information about how specific types of traffic are being handled end to end across a
network.
- To do this, an IP SLA device (switch or router) runs a preconfigured test and generates
traffic that is destined for a far end device.
- As the far end device responds with packets that are received back at the source, IP
SLA gathers data about what happened along the way.
- IP SLA can be configured to perform a variety of tests.
- The simplest test involves Internet Control Message Protocol (ICMP) echo packets
that are sent toward a target address as shown in the following figure:
IP SLA ICMP Echo Test Operation
- For the ICMP echo test, IP SLA can use any live device at the far end and it will reply
when it is pinged.
- IOS is needed only at the source of the IP SLA test because the far end is simply
responding to ordinary request packets.
P a g e | 361
- IP SLA can also test some other network protocols as listed in the following table:
Test Type Description IP SLA required
on Target?
icmp-echo ICMP echo response time No
Path-echo Hop-by-hop and end-to-end response times over
path discovered from ICMP echo No
path-jitter Hop-by-hop jitter over ICMP echo path Yes
dns DNS query response time No
dhcp DHCP IP address request response time No
ftp FTP file-retrieval response time No
http Web page-retrieval response time No
udp-echo End-to-end response time of UDP echo No
udp-jitter
Round-trip delay, one-way delay, one-way jitter,
one-way packet loss, and connectivity using UDP
packets
Yes
tcp-connect Response time to build a TCP connection with a
host No
- To leverage its full capabilities, IOS SLA must be available on both the source and the
target devices as shown in the following figure:
IP SLA UDP Jitter Test Operation
P a g e | 362
IP SLA Operation:
- IP SLA source device handles the test scheduling and sets up each test over a special
IP SLA control connection with the target device.
- The IP SLA source generates the traffic involved in a test operation and analyzes the
results as packets return from the target.
- The target end has a simpler role which is to respond to the incoming test packets.
- This target device is called an IP SLA responder.
- The IP SLA responder must also add time stamps to the packets it sends, to flag the
time a test packet arrived and the time it left the responder.
- The idea is to account for any latency incurred while the responder is processing the
test packets.
- For this to work accurately, both the IP SLA source and responder must synchronize
their clocks through NTP.
- An IP SLA source device can schedule and keep track of multiple test operations.
- Each test runs independently, at a configured frequency and duration.
Note: - To set up an IP SLA operation, the IP SLA source device begins by opening
a control connection to the IP SLA responder over UDP port 1967.
- The IP SLA source device uses control connection to inform the responder to
begin listening on an additional port where the actual IP SLA test operation
will take place.
- IP SLA is more useful to be used in routing than switching as will be
discussed in The Road (ROUTE) book.
- IP SLA can be somehow a useful tool in a switched campus network.
- To run live tests and take useful measurements without IP SLA provided by the ISO,
you would need to place some sort of probe devices at various locations in the
network, all managed from a central system.
- With IP SLA provided by the IOS, you do not need probes at all, wherever you have a
Catalyst switch or router, you already have an IP SLA probe.
P a g e | 363
- By leveraging IP SLA test operations, you can take advantage of some fancy features:
Generate SNMP traps when certain test thresholds are exceeded.
Schedule further IP SLA tests automatically when test thresholds are crossed.
Track an IP SLA test to trigger a next-hop gateway redundancy protocol, such as
HSRP.
Gather voice quality measurements from all over a network.
IP SLA Configuration:
- To define an IP SLA operation, you must configure both the IP SLA source device
(such as switches) and identify the IP SLA target device.
- Some IP SLA test types (such as ICMP echo) can use any IP SLA target device that
can reply to the simple test requests.
- In that case, you do not need to configure anything on the target device.
- Other IP SLA types (such as UDP Jitter) require a target that can negotiate an IP SLA
test, keep time stamps during the test, and respond to protocols that do not necessarily
require a response.
- In that cases, the target must be an IP SLA-capable switch or router.
- You must enable the IP SLA responder on the target device so that it can communicate
with the source.
- You should also make sure that both switches are configured to use Network Time
Protocol (NTP) to synchronize their time clocks with a common accurate source.
- To configure IP SLA on the target switch, just enable the IP SLA responder using the
following command:
Switch(config)# ip sla responder
- Configuring IP SLA on the source switch in a bit more involved.
- To define and run an IP SLA test operation on the source switch, use the following
steps:
P a g e | 364
Step 1 Define a new IP SLA operation on the IP SLA source switch.
Switch(config)# ip sla “operation-number”
- “operation-number” An arbitrary index that uniquely identifies the test and can
range from 1 to a very large number.
Step 2 Select the type of test operation to perform.
Switch(config-ip-sla)# “test-type” “parameters” …
- Some of the possible “test-type” values are the following:
a) dhcp. b) dns. c) ethernet. d) ftp. e) http. f) icmp-echo. g) mpls. h) path-echo.
i) path-jitter. j) slm. k) tcp-connect. l) udp-echo. m) udp-jitter.
- The list of “parameters” following the “test-type” varies according to the test
operation.
- For example, consider the following “icmp-echo” operation syntax:
Switch(config-ip-sla)# icmp-echo “dest-ip-address” [“source-ip-address”]
- “dest-ip-address” A destination address to ping.
- “source-ip-address” A source address that can be used to ping the destination ip
address if the switch has several Layer 3 interfaces, you can
specify which one of their IP addresses to use as the source of
the test packets.
- As another example, consider the following “udp-jitter” operation syntax:
Switch(config-ip-sla)# udp-jitter “dest-ip-address” “dest-udp-port” [source-ip “source-ip-address”] [source-port “source-udp-port”] [num-packets “number-of-packets”] [internal “packet-interval”]
- “udp-jitter” Is useful for testing time-critical traffic path through a switched
network.
P a g e | 365
- You can define the source and destination port numbers that will be used for the
packet stream.
- You also can override the default number of packets (10 pkts) sent at the default
interval (20 msec) using the “num-packets” and “interval” keywords respectively.
- As an alternative, you can configure the “udp-jitter codec” operation to test Voice over
IP (VoIP) call quality by defining the UDP jitter codec using the following command:
Switch(config-ip-sla)# udp-jitter “dest-ip-address” “dest-udp-port” codec {g711a1aw | g711u1aw | g729a}
- The IP SLA operation will simulate a real-time stream of voice traffic using a specific
code.
- In this way, you can tailor the test to fit the type of calls that are actually being used in
the network.
Note: - There are other keywords and parameters you can add to the command, but
those are beyond the scope of this book.
- By default, 1000 packets are sent every 20 msec time interval.
Step 3 Set the frequency of operation.
Switch(config-ip-sla)# frequency “seconds”
- By default, IP SLA operations run at a regular 60 seconds interval for the lifetime of
the test.
Step 4 Schedule the test operation.
Switch(config)# ip sla schedule “operation-number” [life {forever | “seconds”}] [start-time {hh:mm[:ss] [“month” “day” | “day” “month”] | pending | now | after hh:mm:ss}] [ageout “seconds”] [recurring]
- The “ip sla schedule” command tells the switch when to start the test, how long to let
it run, and for how long to keep the data is collected.
P a g e | 366
- “life” Used to set the life time.
- “forever” Means the operation will keep running forever, until you manually
remove it; Otherwise, specify how many seconds it will run.
- By default, an IP SLA scheduled operation will run for 3600 seconds (1 hour).
- “start-time” Used to set the start time.
- You can define the “start-time” as a specific time or date, after a delay with the “after”
keyword, or right now using the “now” keyword.
- “ageout” Used to specify how many seconds elapse before the data is aged out.
- By default, the test statistics are collected and held in memory indefinitely.
- “recurring” Can be used to schedule the test operation to run at the same time each
day, as long as you have defined the starting time using “hh:mm:ss”
IP SLA Verification:
- After you have configured an IP SLA operation, you can verify the configuration using
the following command:
Switch# show ip sla configuration “operation-number”
- By default, the most recent test results are shown.
- To show the IP SLA test analysis, use the following command:
Switch# show ip sla statistics [aggregated] [“operation-number”]
- “aggregated” Used to show a summary of the data gathered over the life of the
operation.
P a g e | 367
Example: - Consider the following small network:
- To define IP SLA operation 50 for an ICMP echo test that pings the target 10.1.1.20
every 5 seconds, use the following commands on the IP SLA source Switch-A:
Switch-A(config)# ip sla 50 Switch-A(config-ip-sla)# icmp-echo 10.1.1.20 Switch-A(config-ip-sla)# frequency 5 Switch-A(config)# ip sla schedule 50 life forever start-time now
- To show the current IP SLA configuration, use the following command:
Switch-A# show ip sla configuration
IP SLAs, Infrastructure Engine-II
Entry number: 50
Owner:
Tag:
Type of operation to perform: echo
Target address: 10.1.1.20
Source address: 0.0.0.0
Request size (ARR data portion): 28
Operation timeout (milliseconds): 5000
Type Of Service parameters: 0x0
Verify data: No
Operation frequency (seconds): 5
Next Scheduled Start Time: Start Time already passed
!Lines are omitted for brevity
P a g e | 368
- To show the IP SLA test analysis:
Switch-A# show ip sla statistics 50 Round Trip Time (RTT) for Index 50
Latest RTT: 1 ms
Latest operation start time: 19:37:07.333 EDT Sat Feb 7 2015
Latest operation return code: OK
Number of successes: 17
Number of failures: 0
Operation time to live: Forever
Switch-A# show ip sla statistics 50
Round Trip Time (RTT) for Index 50
Type of operation: icmp-echo
Start Time Index: 19:37:07.333 EDT Sat Feb 7 2015
RTT Values
Number Of RTT: 35
RTT Min/Avg/Max: 1/1/4 ms
Number of successes: 35
Number of failures: 0
- You can also use an IP SLA operation to make some other switch features change
behavior automatically, without any other intervention.
- For example, HSRP can track the status of an IP SLA operation to automatically
decrement the priority value when the target device stops answering ICMP echo
packets.
- To do this, define a unique track object-number index that will be bound to the IP SLA
operation number, using the following command:
Switch(config)# track “object-number” ip sla “operation-number” {state | reachability}
- “state” Used to track the return code or state of the IP SLA operation.
- The state is up if the IP SLA test was successful or down if it was not.
- “reachability” The result is up if the SLA operation is successful or has risen above
a threshold; otherwise, the reachability is down.
P a g e | 369
- To configure the HSRP standby group to use the tracked object to control the priority
decrement value, use the following command:
Switch(config)# interface vlan “vlan-id” Switch(config-if)# standby “group” track “object-number” decrement “decrement-value”
- As long as the tracked object (the IP SLA operation) is up or successful, the HSRP
priority stays unchanged.
- If the tracked object is down, the HSRP priority is decremented by “decrement-value”
(default 10).
Example: - Consider the following small network:
- Switch-A is configured to ping an upstream router at 192.168.70.1 every 5 seconds, if
that router does not respond, Switch-A will decrement its HSRP priority by 30,
permitting Switch-B to take cover.
- To configure Switch-A, use the following commands:
Switch(config)# ip sla 10 Switch(config-ip-sla)# icmp-echo 192.168.70.1 Switch(config-ip-sla)# frequency 5 Switch(config)# ip sla schedule 10 life forever start-time now Switch(config)# track 1 ip sla 10 reachability Switch(config)# interface vlan 2 Switch(config-if)# ip address 192.168.1.3 255.255.255.0 Switch(config-if)# standby 1 priority 120 Switch(config-if)# standby 1 track 1 decrement 30 Switch(config-if)# standby preempt
P a g e | 370
Note: - You can leverage a network management application that can setup and
monitor IP SLA tests automatically, instead of the manual configuration and
monitoring of many IP SLA operations.
- To do this, the network management application needs SNMP read and write
access to each switch that will use IP SLA.
- Tests are configured by writing to the IP SLA MIB and results are gathered
by reading the MIB.
P a g e | 371
Chapter 20 Port Mirroring
- Sometimes the network traffic should be monitored for analysis purposes or
troubleshooting.
- You cannot simply connect to a switch and monitor interesting traffic flow.
- Catalyst switches can mirror traffic passing through switch ports or VLANs onto other
ports so that a network analyzer (sniffer) can capture interesting traffic.
- Switch Port Analysis (SPAN) A feature that is used to mirror (copy) traffic (frames)
between switch ports.
- SPAN is also known as “Port Mirroring”.
- The SPAN feature is used to mirror traffic from one SPAN source switch’s physical
interface or VLAN to a SPAN destination switch’s physical interface.
Note: - The SPAN source can be one or more switch interfaces or VLANs.
- This allows a network analyzer (such as Wireshark) to capture traffic for monitoring
and analysis.
- When the traffic arrive on the SPAN source switch interface or VLAN, they are
marked so that they can be copied to the SPAN destination switch interface.
- In this way, the network analyzer can receive an capture an exact copy of the traffic
that are being forwarded to and from the SPAN source (switch interface or VLAN).
- SPAN is available in two different forms:
Local SPAN (LSPAN) Both the SPAN source and destination are located on the
same local switch.
Remote SPAN (RSPAN) The SPAN source and destination are located on
different switches.
P a g e | 372
a) Local SPAN (LSPAN):
- A local SPAN session exists only on one switch.
- A local SPAN session can monitor the following:
The transmitted traffic sent by the SPAN source.
The received traffic by the SPAN source.
Both the transmitted and received traffic by the SPAN source.
- The following figure shows how the Local SPAN works:
Local SPAN (LSPAN)
- The SPAN source can be identified as one or more physical switch ports on the local
switch.
- These physical switch ports can belong to the same VLAN or different VLANs.
- A trunk switch port can be used as a SPAN source, causing traffic from all active
VLANs on the trunk to be mirrored to the SPAN destination.
- You can apply a VLAN filter to the SPAN source traffic to limit which VLANs will be
mirrored to the SPAN destination.
- A SPAN source can also be a switch port that is a member of an EtherChannel.
- In this case, only traffic passing over that physical port in the EtherChannel bundle
will be mirrored to the SPAN destination, allowing you to monitor a single traffic
passing across an entire EtherChannel bundle.
P a g e | 373
Note: - To monitor all traffic passing across an entire EtherChannel bundle, you can
identify a Port-Channel interface as the SPAN source.
- A SPAN source can also be one or more VLANs on the local switch, so you can
monitor traffic passing within one or more VLANs.
- This is often called VLAN-based SPAN (VSPAN).
- All switch ports that are active on a source VLAN become SPAN sources themselves.
- The SPAN destination in case of LSPAN is identified as a physical port located on the
same local switch and a network analyzer is connected to that physical port.
Note: - Because the SPAN source traffic (frames) is mirrored to the SPAN
destination, the SPAN source original data is not effected and is still
forwarded normally.
- If the SPAN source and destination ports are operating at different speeds, the
mirrored traffic is copied into the destination port’s egress queue, as if normal Layer 2
switching had decided to forward them there.
- If the destination port becomes congested, the mirrored traffic might be dropped from
the queue and not transmitted to the destination port.
- Therefore, if the bandwidth of the SPAN source traffic exceeds that of the SPAN
destination port, some mirrored traffic might not be seen at the SPAN destination port.
LSPAN Configuration:
- You can configure one or more simultaneous SPAN sessions on a Catalyst switch.
- The number of supported SPAN sessions depends on the switch model.
- For example, a Catalyst 2750-x can support two sessions, whereas a Catalyst 6500 can
support up to 64.
- Each SPAN session is completely independent because there is no interaction between
the mirroring processes of each one.
P a g e | 374
- To configure a LSPAN session, follow these steps:
Step 1 Define the SPAN source of the session.
Switch(config)# monitor session “session-number” source {interface “type mod/num.” | vlan “vlan-id”} [rx | tx | both]
- “session-number” A unique number that represents the SPAN session.
- interface “type mod/num.” Used to define the SPAN source port.
- vlan “vlan-id” Used to define the SPAN source VLAN.
- rx To mirror only the received traffic on the SPAN source.
- tx To mirror only the transmitted traffic from the SPAN source.
- both (the default) To mirror both the transmitted and received traffic by the SPAN
source.
Note: - If multiple SPAN sessions are needed, you can repeat this command, with
each session must have a unique “session-number”.
Step 2 Define the SPAN destination of the session.
Switch(config)# monitor session “session-number” destination interface “type mod/num.” [encapsulation replicate]
Note: - Be sure to enter the same “session-number”, so that the SPAN destination
gets bound to the corresponding source.
- You can define only one destination for each session.
- In addition, different SPAN sessions cannot share a common destination.
- The SPAN destination can only be a physical switch interface.
- SPAN normally copies traffic to the SPAN destination without any VLAN trunk tags.
- SPAN also does not normally copy Layer 2 protocols that are sent by the switch itself
(such as STP BPDUs, CDP, VTP, DTP, LACP, and PAgP).
- encapsulation replicate Used to mirror any VLAN tagging information or the Layer
2 protocol information.
P a g e | 375
Step 3 If the SPAN source is a trunk port, you can mirror only traffic from specified
VLANs on the trunk by specifying the list of VLANs to be filtered when
mirroring, using the following command.
Switch(config)# monitor session “session-number” filter vlan “vlan-range”
Step 4 (Optional) Allow the mirrored traffic to be received and forwarded from the
destination interface by adding the following syntax to the
command used in step 2.
Switch(config)# monitor session “session-number” destination interface “type mod/num.” [encapsulation replicate] [ingress {dot1q “vlan-id” | isl | untagged vlan “vlan-id”}]
Example: - Consider the following small network:
- We need to mirror only the transmitted traffic by PC1 using a network analyzer
installed on PC2.
- To configure Switch-A, use the following commands:
Switch-A(config)# monitor session 1 source interface fastEthernet 0/1 tx Switch-A(config)# monitor session 1 destination interface fastEthernet 0/2
b) Remote SPAN (RSPAN):
- In a large switched network, the SPAN source and destination can be connected to
different remote switches.
P a g e | 376
- The RSPAN feature can mirror traffic from the SPAN source to the SPAN destination,
and the SPAN source is located on a different switch than the SPAN destination.
- RSPAN will carry only the mirrored traffic over a special purpose VLAN across trunk
links and intermediate switches between the SPAN source and destination as shown in
the following figure:
Remote SPAN (RSPAN)
Note: - Every switch along the way between the SPAN source and destination must
be RSPAN capable.
- At the source switch, the SPAN source traffic (frames) is mirrored to the SPAN
destination over the RSPAN VLAN.
- At the destination switch, traffic is pulled off the RSPAN VLAN and copied to the
RSPAN destination port.
- The RSPAN VLAN has some important differences from a regular VLAN.
- First, MAC address learning is disabled on the RSPAN VLAN.
- This to prevent intermediate switches that transport the RSPAN VLAN from trying to
forward the mirrored traffic to their real destination MAC addresses.
Note: - The purpose of the LSPAN and RSPAN is simply to mirror interesting
traffic, not to forward them normally.
P a g e | 377
- The RSPAN-capable switch also floods the RSPAN traffic (frames) out all its ports
belonging to the RSPAN VLAN, in an effort to send them toward the SPAN
destination.
- The RSPAN VLAN should be allowed on trunks between switches, but should not be
assigned to any other switch ports along the path.
RSPAN Configuration:
- To configure RSPAN follow these steps:
Step 1 Define the special-purpose RSPAN VLAN.
Switch(config)# vlan “vlan-id” Switch(config-vlan)# remote-span
- If you are not using VTP, be sure to configure this VLAN for RSPAN explicitly on
each intermediate switch. Otherwise, the RSPAN traffic will not be delivered
correctly.
- If you are using VTP, configure the RSPAN VLAN on a VTP server, then VTP
correctly propagates it to other intermediate switches.
- In addition, if VTP pruning is in use, the RSPAN VLAN will be pruned from
unnecessary trunks, limiting the traffic impact in unrelated areas of the network.
- You should define one RSPAN VLAN for each RSPAN session that will be used.
- Do not allow any normal hosts to join an RSPAN VLAN.
Step 2 Define the SPAN source and destination on the switch where the SPAN
source is connected.
Switch(config)# monitor session “session-number” source {interface “type mod/num.” | vlan “vlan-id”} [rx | tx | both]
- The RSPAN source is either a physical switch port or a Layer 2 VLAN (not a SVI).
Switch(config)# monitor session “session-number” destination remote vlan “rspan-vlan-id”
P a g e | 378
- The SPAN destination is simply the RSPAN VLAN.
- This allows the mirrored traffic to be copied into the RSPAN-VLAN and sent on their
way toward the final SPAN destination.
Step 3 If the SPAN source is a trunk port, you can mirror only traffic from specified
VLANs on the trunk by specifying the list of VLANs to be filtered when
mirroring, using the following command.
Switch(config)# monitor session “session-number” filter vlan “vlan-range”
Step 4 Define the SPAN source and destination on the destination switch where the
SPAN destination is connected.
Switch(config)# monitor session “session-number” source remote vlan “rspan-vlan-id”
Switch(config)# monitor session “session-number” destination interface “type mod/num.” [encapsulation replicate]
- encapsulation replicate Used to mirror any VLAN tagging information or the Layer
2 protocol information.
Step 5 (Optional) Allow the mirrored traffic to be received and forwarded from the
destination interface by adding a syntax to the command in step 4
of defining the SPAN destination interface.
Switch(config)# monitor session “session-number” destination interface “type mod/num.” [encapsulation replicate] [ingress {dot1q “vlan-id” | isl | untagged vlan “vlan-id”}]
- RSPAN must allow the STP to run on the RSPAN VLAN to prevent bridging loops
from forming.
- As a result, STP BPDUs normally are sent and received on the VLAN.
- You cannot monitor BPDUs with RSPAN.
P a g e | 379
Example: - Consider the following network:
- The RSPAN VLAN is VLAN 100.
- We need to mirror the transmitted and received traffic of PC1 using the network
analyzer.
- To configure Switch-A, use the following commands:
Switch-A(config)# vlan 100 Switch-A(config-vlan)# remote-span Switch-A(config)# monitor session 1 source interface fastEthernet 0/1 both Switch-A(config)# monitor session 1 destination remote vlan 100
- To configure Switch-B, use the following commands:
Switch-B(config)# vlan 100 Switch-B(config-vlan)# remote-span
- To configure Switch-C, use the following commands:
Switch-C(config)# vlan 100 Switch-C(config-vlan)# remote-span Switch-C(config)# monitor session 1 source remote vlan 100 Switch-C(config)# monitor session 1 destination interface fastEthernet 0/2
P a g e | 380
Managing SPAN Sessions:
- To show information about currently active SPAN sessions, use the following
command:
Switch# show monitor [session {“session-number” | local | all | range “range-list” | remote}] [detail]
- By default, all active sessions are displayed.
- you can use the “session” keyword to limit the output to a specific “session-number”,
only “local” sessions, “all” local or remote sessions, a “range” of sessions, or only
“remote” sessions.
- The following output shows the currently active SPAN sessions on a switch:
Switch-A# show monitor
Session 1
----------
Type : Local Session
Source Ports : Fa0/1
Both :
Destination Ports : Fa0/2
Encapsulation : Native
Ingress : Disabled
Session 2
----------
Type : Remote Source Session
Source Ports : Fa0/2
Both :
Dest RSPAN VLAN : 100
- You can delete a SPAN session after the traffic analysis is complete.
- SPAN sessions are numbered, so you can delete them by referencing the session
number using the following command:
Switch(config)# no monitor session {“session-number” | range “range-list” | local | all | }
P a g e | 381
- Session numbers can be given as an individual “session-number“, a “range” of
sessions, all “local” SPAN sessions, or “all” local or remote sessions.
- When you finish using a SPAN session, you always should disable or delete it;
otherwise, someone might try to connect to the port that is configured as the SPAN
destination.
- You could spend a good bit of time troubleshooting that user’s connectivity problem
only to find that you left a SPAN session active there.
P a g e | 382
Chapter 21 Managing Switch Users
- Catalyst switches (and also routers) have a variety of methods that can secure and
control user access.
- Users can be authenticated as they connect to or through a switch.
- Users can be authorized to perform certain actions on a switch.
- Users access can be recorded as switch accounting information.
Note: - Users means the network administrative staff only.
- You can manage user activity to and through a switch with Authentication,
Authorization, and Accounting (AAA) server.
- You can think of AAA in the following manner:
Authentication Who is the user?
Authorization What is the user allowed to do?
Accounting What did the user do?
Authentication:
- User authentication can be handled by several methods:
Usernames and passwords configured locally on every switch in the network.
One or more external Remote Authentication Dial-In User Service (RADIUS)
servers.
One or more external Terminal Access Controller Access Control System+
(TACACS+) servers.
Note: - Any combination of these methods can be used.
- In fact, authentication must be defined by grouping the desired methods into a
method list.
- The list contains the types or protocols that will be used in sequential order
that they will be tried.
P a g e | 383
- You can use the “username … password” global configuration command to configure
individual usernames and passwords on the switch.
- This will solve the user anonymity problem, but if the network consists of many
administrative network users and many switches, that will be difficult to manage.
- A more scalable solution is to use AAA server that is centralized, standardized,
resilient, and flexible.
- Catalyst switches can use the following two protocols to communicate with AAA
servers:
RADIUS A standard-based protocol that combines Authentication,
Authorization, and Accounting into a single AAA server;
communication uses UDP ports 1812 (for authentication and
authorization) and 1813 (for accounting) but is not completely
secure.
TACACS+ A Cisco-proprietary protocol that separates each of the AAA
functions; communication is secured and encrypted over TCP port
49.
- Both RADIUS and TACACS+ are arranged as a client/server model, where a switch
acts as a client communicating with a AAA server as shown in the following figure:
AAA Client/Server Model
- In the AAA client role, a switch is often called a Network Access Device (NAD).
- Switch access can be granted only after a user’s identity has been validated.
- User authentication is commonly used on switches to permit remote access.
P a g e | 384
- In this case, when a user uses Telnet or Secure Shell (SSH) to log in to a switch, that
user is challenged to provide a username and password.
- If the user provided correct credentials, the AAA server returns an “accept” message to
the switch.
- If the user provided incorrect credentials, the AAA server returns a “reject” message to
the switch.
Note: - Cisco implements AAA services in its Identity Services Engine (ISE) and
Cisco Secure Access Control Server (ACS).
- There are many other applications that provide AAA services.
Authentication Configuration:
- To use authentication on a Catalyst switch, you must configure the following steps in
order:
Step 1 Enable AAA on the switch (by default, AAA is disabled).
Switch(config)# aaa new-model
- “new-model” - Refers to the use of the method list, by which authentication
methods can be grouped or organized.
- The new model is much more scalable than the “old model”, in which the
authentication method was explicitly configured.
Step 2 Define the source of authentication.
Note: - You can compare user credentials against locally configured usernames and
passwords, or against a database managed by external RADIUS or
TACACS+ servers.
- Use locally configured usernames and passwords as a last resort, when no
other authentication servers are reachable or in use on the network.
- To define a local username and password, use the following command:
Switch(config)# username “username” password {0 | 7 } “password”
P a g e | 385
- “0” Means to provide an unencrypted password.
- “7” Means to provide an encrypted password.
- RADIUS or TACACS+ servers are defined in groups.
- First, define each server along with its secret shared password using the following
command:
Switch(config)# radius-server host “ip-address” [key “string”]
Switch(config)# tacacs-server host “ip-address” [key “string”]
“ip-address” The IP address of either the RADIUS or TACACS+ servers.
- “string” Is known only to the switch and the AAA server, and it is used as a key to
provide encryption for the authentication session.
- Then, define a group name “group-name” that will contain a list of servers using the
following command:
Switch(config)# aaa group server {radius | tacacs+} “group-name”
- Then, define each server of the group using the following server-group configuration
command:
Switch(config-sg)# server “ip-address”
Note: - You can define multiple RADIUS or TACACS+ servers by repeating the
commands in this step.
Step 3 Define a list of authentication methods to try.
Switch(config)# aaa authentication login {default | “list-name”} “method-1” [“method-2” …]
- You can list switch login authentication methods by giving the method a descriptive
name “list-name” or using the unnamed “default” method.
- List each method in the order it should be tried.
P a g e | 386
- If none of the servers for the first method responds, the switch will try the servers in
the next method listed.
- Here, the methods refer to the following keywords:
“radius” Each of the RADIUS servers configured on the switch is tried, in the
order that it was configured.
“tacacs+” Each of the TACACS+ servers configured on the switch is tried, in
the order that it was configured.
“local” The user’s credentials are compared against all the “username”
commands configured on the local switch.
“line” The line passwords authenticate any connected user. No usernames can
be used.
Note: - Be sure to add either the “local” or “line” methods at the end of the list, as a
last resort.
- This way, if all the RADIUS or TACACS+ servers are unavailable or the
switch is completely isolated from the rest of the network, a locally
configured authentication method will eventually be used.
- Otherwise, you will never be able to access the switch until at least one of
the servers comes back online.
Step 4 - Apply a method list to a switch line.
- First, select a line (console or vty for Telnet/SSH access) using the
following command:
Switch(config)# line {console 0 | vty “range”}
- Then, trigger the user authentication on that line to use an AAA method list using the
following command:
Switch(config-line)# login authentication {default | “list-name”}
- You can identify the method with a descriptive name (list-name) if you are configuring
more than one list.
- Otherwise, a single unnamed list is called the “default” list.
P a g e | 387
Note: - After Authentication is configured on a switch, it is a good idea to stay
logged in on one session so that the authentication can be tested.
- If you exit the configuration session, you will not be able to log in again if
the authentication is misconfigured.
- While you stay logged in on the original session, bring up a new Telnet
session to the switch.
- If you can authenticate successfully, everything is configured properly.
Example: - Consider the following small network:
- The AAA servers are (192.168.1.10) and (192.168.1.20), also known as the AAA
servers group names “auth-servers”.
- The AAA Authentication group “auth-group” is configured to try the TACACS+
server group; if none of the servers is available, local authentication will be used
instead.
- A username “Local-User” is configured as a last resort for that case.
- Finally, “auth-group” method is used to authenticate users on lines vty 0 through 15
for Telnet and SSH access.
- To configure Switch-A, use the following commands:
P a g e | 388
Switch-A(config)# aaa new-model Switch-A(config)# username Local-User password 0 mysecret-1 Switch-A(config)# tacacs-server host 192.168.1.10 key mysecret-2 Switch-A(config)# tacacs-server host 192.168.1.20 key mysecret-3 Switch-A(config)# aaa group server tacacs+ auth-servers Switch-A(config-sg)# server 192.168.1.10 Switch-A(config-sg)# server 192.168.1.20 Switch-A(config)# aaa authentication login auth-group group auth-servers local Switch-A(config)# line vty 0 15 Switch-A(config-line)# login authentication auth-group
Authorization Configuration:
- After a user is authenticated, the switch allows access to certain services or switch
commands based on the user’s privilege level.
- By default, authenticated users are put at the EXEC level.
- Certain commands, such as “show interface”, are available at the EXEC level.
- Other commands, such as “configure terminal”, are accessible only if the user is able
to move into the privileged EXEC or enable mode.
- Authorization provides a means of granting specific users the ability to perform certain
tasks.
- As with authentication, authorization is performed by querying external RADIUS or
TACACS+ servers.
- If the authorization server has an entry for a user and a service or command, the switch
allows the user to perform that task.
- To configure Authorization follow these steps in sequence:
Step 1 Define any RADIUS or TACACS+ servers that will be used.
- These normally are defined as part of the authentication configuration and do not need
to be redefined for authorization.
Step 2 Define a method list of authorization methods that will be tried in sequence.
Switch(config)# aaa authorization {commands | config-commands | configuration | exec | network | reverse-access} {default | “list-name”} “method-1” [“method-2”..]
P a g e | 389
- Here, you specify the function or service needing authorization with one of the
following keywords:
commands The server must return permission to use any switch command at
any privilege level.
config-commands The server must return permission to use any switch
configuration command.
configuration The server must return permission to enter the switch
configuration mode.
exec - The server must return permission for the user to run a switch EXEC
session.
- The server also can return the privilege level for the user so that the user
immediately can be put into the privileged EXEC (enable) mode without
having to type in the enable command.
network The server must return permission to use network-related services.
reverse-access The server must return permission for the user to access a
reverse Telnet session on the switch.
- You can identify the method with a descriptive name (list-name) if you are configuring
more than one list.
- Otherwise, a single unnamed list is called the “default” list.
- Each authorization method then is listed in the order it will be tried.
- The methods can be any of the following values:
group “group-name” Requests are sent to the servers in a specific group.
group {radius | tacacs+} Requests are sent to all servers of this type.
if-authenticated Requests are granted if the user already is authenticated.
none No external authorization is used; every user is authorized successfully.
Note: - Only TACACS+ servers can authorize users with permission to use specific
commands.
- RADIUS servers offer more of an all-or-nothing approach.
Step 3 Apply an authorization method list to a specific line on the switch.
Switch(config-line)# authorization {commands “level” | exec | reverse-access} {default | “list-name”}
P a g e | 390
- Users accessing the switch through that line will be subject to authorization.
- If you do not use this command, the default group is used for all lines.
- To configure a switch to use AAA authorization for all lines, use the following
command:
Switch(config)# aaa authorization exec default group “group-name” none
Accounting Configuration:
- Catalyst switches also support the capability to use AAA for producing accounting
information of user activity.
- This accounting information can be collected by RADIUS and TACACS+ servers.
- To configure accounting, follow these steps in order:
Step 1 The RADIUS and TACACS+ servers must already be configured and
grouped as part of the authentication configuration.
Step 2 Define a method list giving a sequence of accounting methods.
Switch(config)# aaa accounting {system | exec | commands “level”} {default | “list-name”} {start-stop | stop-only | wait-start | none} “method-1” [“method-2” …]
- The function triggering the accounting can be one of the following keywords:
system Major switch events such as a reload are recorded.
exec User authentication into an EXEC session is recorded, along with
information about the user’s address and the time and duration of the
session.
commands “level” Information about any command running at a specific
privilege level is recorded, along with the user who issued the
command.
- You can specify that certain types of accounting records be sent to the accounting
server using the following keywords:
start-stop Events are recorded when they start and stop.
P a g e | 391
stop-only Events are recorded only when they stop.
none No events are recorded.
Step 3 Apply an accounting method list to a specific line (console or vty) on the
switch.
Switch(config-line)# accounting {commands “level” | connection | exec}
{default | “list-name”}
- Users accessing the switch through that line will have their activity recorded.
- If you do not use this command, the default group will be used for all lines.