Foundation Topics

VLAN Access Lists

Access lists can manage or control traffic as it passes through a switch. When normal access lists are configured on a Catalyst switch, they filter traffic through the use of the Ternary Content Addressable Memory (TCAM). Recall from Chapter 3, "Switch Operation," that access lists (also known as router access lists, or RACLs) are merged or compiled into the TCAM. Each ACL is applied to an interface according to the direction of trafficinbound or outbound. Packets then can be filtered in hardware with no switching performance penalty. However, only packets that pass between VLANs can be filtered this way.

Packets that stay in the same VLAN do not cross a VLAN or interface boundary and do not necessarily have a direction in relation to an interface. These packets also might be non-IP, non-IPX, or completely bridged; therefore, they never pass through the multilayer switching mechanism. VLAN access lists (VACLs) are filters that directly can affect how packets are handled within a VLAN.

VACLs are somewhat different from RACLs or traditional access control lists. Although they, too, are merged into the TCAM, they can permit, deny, or redirect packets as they are matched. VACLs also are configured in a route map fashion, with a series of matching conditions and actions to take.

VACL Configuration

VACLs are configured as a VLAN access map, in much the same format as a route map. A VLAN access map consists of one or more statements, each having a common map name. First, you define the VACL with the following global configuration command:

Switch(config)# vlan access-map map-name [sequence-number]

Access map statements are evaluated in sequence, according to the sequence-number. Each statement can contain one or more matching conditions, followed by an action.

Next, define the matching conditions that identify the traffic to be filtered. Matching is performed by access lists (IP, IPX, or MAC address ACLs), which you must configure independently. Configure a matching condition with one of the following access map configuration commands:

Switch(config-access-map)# match ip address {acl-number | acl-name} Switch(config-access-map)# match ipx address {acl-number | acl-name} Switch(config-access-map)# match mac address acl-name

You can repeat these commands to define several matching conditions; the first match encountered triggers an action to take. Define the action with the following access map configuration command:

Switch(config-access-map)# action {drop | forward [capture] | redirect type mod/num}

A VACL can either drop a matching packet, forward it, or redirect it to another interface. The TCAM performs the entire VACL match and action, as packets are switched or bridged within a VLAN, or routed into or out of a VLAN.

Finally, you must apply the VACL to a VLAN using the following global configuration command:

Switch(config)# vlan filter map-name vlan-list vlan-list

Notice that the VACL is applied globally to one or more VLANs listed and not to a VLAN interface (SVI). Recall that VLANs can be present in a switch as explicit interfaces or as inherent Layer 2 entities. The VLAN interface is the point where packets enter or leave a VLAN, so it does not make sense to apply a VACL there. Instead, the VACL needs to function within the VLAN itself, where there is no inbound or outbound direction.

For example, suppose you need to filter traffic within VLAN 99 so that host 192.168.99.17 is not allowed to contact any other host on its local subnet. Access list local-17 is created to identify traffic between this host and anything else on its local subnet. Then a VLAN access map is defined: If the local-17 access list permits the IP address, the packet is dropped; otherwise, the packet is forwarded. Example 18-1 shows the commands necessary for this example.

Example 18-1. Filtering Traffic Within the Local Subnet

Switch(config)# ip access-list extended local-17 Switch(config-acl)# permit ip host 192.168.99.17 192.168.99.0 0.0.0.255 Switch(config-acl)# exit Switch(config)# vlan access-map block-17 10 Switch(config-access-map)# match ip address local-17 Switch(config-access-map)# action drop Switch(config-access-map)# vlan access-map block-17 20 Switch(config-access-map)# action forward Switch(config-access-map)# exit Switch(config)# vlan filter block-17 vlan-list 99

Private VLANs

Normally, traffic is allowed to move unrestricted within a VLAN. Packets sent from one host to another normally are heard only by the destination host because of the nature of Layer 2 switching.

However, if one host broadcasts a packet, all hosts on the VLAN must listen. You can use a VACL to filter packets between a source and destination in a VLAN if both connect to the local switch.

Sometimes it would be nice to have the capability to segment traffic within a single VLAN, without having to use multiple VLANs and a router. For example, in a single-VLAN server farm, all servers should be capable of communicating with the router or 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 others but still be capable of reaching the gateway to find clients not on the local network.

Another application is a service provider network. Here, the provider might want to use a single VLAN to connect to several customer networks. Each customer needs to be able to contact the provider's gateway on the VLAN. Clearly, the customer sites do not need to interact with each other.

Private VLANs (PVLANs) solve this problem on Catalyst switches. In a nutshell, a normal, or primary, VLAN can be logically associated with special unidirectional, or secondary, VLANs. Hosts associated with a secondary VLAN can communicate with ports on the primary VLAN (a router, for example), but not with another secondary VLAN. A secondary VLAN is configured as one of the following types:

• Isolated Any switch ports associated with an isolated VLAN can reach the primary VLAN but not any other secondary VLAN. In addition, hosts associated with the same isolated VLAN cannot reach each other. They are, in effect, isolated from everything except the primary VLAN.

• Community Any switch ports associated with a common community VLAN can communicate with each other and with the primary VLAN but not with any other secondary VLAN. This provides the basis for server farms and workgroups within an organization, while giving isolation between organizations.

All secondary VLANs must be associated with one primary VLAN to set up the unidirectional relationship. 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 configuration. Therefore, private VLANs are only locally significant to a switch. Each of the private VLANs must be configured locally on each switch that interconnects them.

You must configure each physical switch port that uses a private VLAN with a VLAN association. You also must define the port with one of the following modes:

• Promiscuous The switch port connects to a router, firewall, or other common gateway device. This port can communicate with anything else connected to the primary or any secondary VLAN. In other words, the port is in promiscuous mode, in which the rules of private VLANs are ignored.

• Host The switch port connects to a regular host that resides on an isolated or community VLAN. The port communicates only with a promiscuous port or ports on the same community VLAN.

Figure 18-1 shows the basic private VLAN operation. Some host PCs connect to a secondary community VLAN. The two community VLANs associate with a primary VLAN, where the router connects. The router connects to a promiscuous port on the primary VLAN. A single host PC connects to a secondary isolated VLAN, so it can communicate only with the router's promiscuous port.

Figure 18-1. Private VLAN Functionality Within a Switch

Private VLAN Configuration

Defining a private VLAN involves several configuration steps. These steps are described in the sections that follow so you can use them.

Configure the Private VLANs

To configure a private VLAN, begin by defining any secondary VLANs that are needed for isolation using the following configuration commands:

Switch(config)# vlan vlan-id Switch(config-vlan)# private-vlan {isolated | community}

The secondary VLAN can be an isolated VLAN (no connectivity between isolated ports) or a community VLAN (connectivity between member ports).

Now define the primary VLAN that will provide the underlying private VLAN connectivity using the following configuration commands:

Switch(config)# vlan vlan-id Switch(config-vlan)# private-vlan primary Switch(config-vlan)# private-vlan association {secondary-vlan-list | add secondary- vlan-list | remove secondary-vlan-list}

Be sure to associate the primary VLAN with all its component secondary VLANs using the association keyword. If the primary VLAN already has been configured, you can add (add) or remove (remove) secondary VLAN associations individually.

These VLAN configuration commands set up only the mechanisms for unidirectional connectivity from the secondary VLANs to the primary VLAN. You also must associate the individual switch ports with their respective private VLANs.

Associate Ports with Private VLANs

First, define the function of the port that will participate on a private VLAN using the following configuration command:

Switch(config-if)# switchport mode private-vlan {host | promiscuous}

If the host connected to this port is a router, firewall, or common gateway for the VLAN, use the promiscuous keyword. This allows the host to reach all other promiscuous, isolated, or community ports associated with the primary VLAN. Otherwise, any isolated or community port must receive the host keyword.

For a nonpromiscuous port (using the switchport mode private-vlan host command), you must associate the switch port with the appropriate primary and secondary VLANs. Remember, only the private VLANs themselves have been configured until now. The switch port must know how to interact with the various VLANs using the following interface-configuration command:

Switch(config-if)# switchport private-vlan host-association primary-vlan-id secondary-vlan-id

Note

When a switch port is associated with private VLANs, you don't have to configure a static access VLAN. Instead, the port takes on membership in the primary and secondary VLANs simultaneously. This does not mean that the port has a fully functional assignment to multiple VLANs. Instead, it takes on only the unidirectional behavior between the secondary and primary VLANs.

For a promiscuous port (using the switchport mode private-vlan promiscuous command), you must map the port to primary and secondary VLANs. Notice that promiscuous-mode ports, or ports that can communicate with any other private VLAN device, are mapped, while other secondary VLAN ports are associated. One (promiscuous-mode port) exhibits bidirectional behavior, while the other (secondary VLAN ports) exhibits unidirectional or logical behavior.

Use the following interface-configuration command to map promiscuous-mode ports to primary and secondary VLANs:

Switch(config-if)# switchport private-vlan mapping {primary-vlan-id} {secondary-vlan- list} | {add secondary-vlan-list} | {remove secondary-vlan-list}

As an example, assume that the switch in Figure 18-1 is configured as in Example 18-2. Host PCs on ports FastEthernet 1/1 and 1/2 are in community VLAN 10, hosts on ports FastEthernet 1/4 and 1/5 are in community VLAN 20, and the host on port FastEthernet 1/3 is in isolated VLAN 30. The router on port FastEthernet 2/1 is in promiscuous mode on primary VLAN 100. Each VLAN is assigned a role, and the primary VLAN is associated with its secondary VLANs. Then each interface is associated with a primary and secondary VLAN (if a host is attached) or mapped to the primary and secondary VLANs (if a promiscuous host is attached).

Example 18-2. Configuring Ports with Private VLANs

Switch(config)# vlan 10 Switch(config-vlan)# private-vlan community Switch(config)# vlan 20 Switch(config-vlan)# private-vlan community Switch(config)# vlan 30 Switch(config-vlan)# private-vlan isolated Switch(config)# vlan 100 Switch(config-vlan)# private-vlan primary Switch(config-vlan)# private-vlan association 10,20,30 Switch(config-vlan)# exit Switch(config)# interface range fastethernet 1/1 1/2 Switchconfig# switchport private-vlan host Switch(config-if)# switchport private-vlan host-association 100 10 Switch(config)# interface range fastethernet 1/4 1/5 Switchconfig# switchport private-vlan host Switch(config-if)# switchport private-vlan host-association 100 20 Switch(config)# interface fastethernet 1/3 Switchconfig# switchport private-vlan host Switch(config-if)# switchport private-vlan host-association 100 30 Switch(config)# interface fastethernet 2/1 Switch(config-if)# switchport mode private-vlan promiscuous Switch(config-if)# switchport private-vlan mapping 100 10,20,30

Associate Secondary VLANs to a Primary VLAN SVI

On switched virtual interfaces (SVIs), or VLAN interfaces configured with Layer 3 addresses, you must configure some additional private VLAN mapping. Consider the SVI for the primary VLAN, VLAN 100, that has an IP address and participates in routing traffic. Secondary VLANs 40 (an isolated VLAN) and 50 (a community VLAN) are associated at Layer 2 with primary VLAN 100 using the configuration in Example 18-3.

Example 18-3. Associating Secondary VLANs to a Primary VLAN

vlan 40      private-vlan isolated vlan 50      private-vlan community vlan 200      private-vlan primary      private-vlan association 40,50 interface vlan 200      ip address 192.168.199.1 255.255.255.0

Primary VLAN 200 can forward traffic at Layer 3, but the secondary VLAN associations with it are good at only Layer 2. To allow Layer 3 traffic switching coming from the secondary VLANs as well, you must add a private VLAN mapping to the primary VLAN (SVI) interface, using the following interface-configuration command:

Switch(config-if)# private-vlan mapping {secondary-vlan-list | add secondary-vlan-list | remove secondary-vlan-list}

The primary VLAN SVI function is extended to the secondary VLANs instead of requiring SVIs for each of them. If some mapping already has been configured for the primary VLAN SVI, you can add (add) or remove (remove) secondary VLAN mappings individually.

For the example, you would map the private VLAN with the following command:

interface vlan 200       private-vlan mapping 40,50

Securing VLAN Trunks

Because trunk links usually are bounded between two switches, you might think that they are more or less secure. Each end of the trunk is connected to a device that is under your control, VLANs carried over the trunk remain isolated, and so on.

Some attacks or exploits can be leveraged to gain access to a trunk or to the VLANs carried over a 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 from Chapter 6, "VLANs and Trunks," that two switches can be connected by a common trunk link that can carry traffic from multiple VLANs. The trunk doesn't have to exist all the time. The switches dynamically can negotiate its use 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 auto. Normally, the switch port would wait to be asked by another switch in the auto or on mode to become a trunk.

Now suppose that an end user's PC is connected to that port. A well-behaved end user would not use DTP at all, so the port would come up in access mode with a single-access VLAN. A malicious user, however, might exploit the use of DTP and attempt to negotiate a trunk with the switch port. This makes the PC appear to be another switch; in effect, the PC is spoofing a switch.

After the trunk is negotiated, the attacker has access to any VLAN that is permitted to pass over the trunk. If the switch port has been left to its default configuration, all VLANs configured on the switch are allowed onto the trunk. This scenario is shown in Figure 18-2. The attacker can receive any traffic being sent over the trunk on any VLAN. In addition, he can send traffic into any VLAN of his choice.

Figure 18-2. An Example of Switch Spoofing to Gain Access to a Trunk

To demonstrate this further, consider the output in Example 18-4, which shows the default access switch port configuration. Notice that trunking is possible because the port is set to dynamic auto mode, awaiting DTP negotiation from a connected device. If a trunk is negotiated, all VLANs are permitted to be carried over it.

Example 18-4. Displaying the Default Switch Port Configuration

Switch# show interfaces fastethernet 1/0/46 switchport Name: Fa1/0/46 Switchport: Enabled Administrative Mode: dynamic auto Operational Mode: trunk Administrative Trunking Encapsulation: negotiate Negotiation of Trunking: On Access Mode VLAN: 1 (default) Trunking Native Mode VLAN: 1 (default) Administrative Native VLAN tagging: enabled Voice VLAN: none Administrative private-vlan host-association: none Administrative private-vlan mapping: none Administrative private-vlan trunk native VLAN: none Administrative private-vlan trunk Native VLAN tagging: enabled Administrative private-vlan trunk encapsulation: dot1q Administrative private-vlan trunk normal VLANs: none Administrative private-vlan trunk private VLANs: none Operational private-vlan: none Trunking VLANs Enabled: ALL Pruning VLANs Enabled: 2-1001 Capture Mode Disabled Capture VLANs Allowed: ALL Protected: false Unknown unicast blocked: disabled Unknown multicast blocked: disabled Appliance trust: none Switch#

The solution to this situation is to configure every switch port to have an expected and controlled behavior. For example, instead of leaving an end-user switch port set to use DTP in auto mode, configure it to static access mode with the following commands:

Switch(config)# interface type mod/num Switch(config-if)# switchport access vlan vlan-id Switch(config-if)# switchport mode access

This way, an end user never will be able to send any type of spoofed traffic that will make the switch port begin trunking.

In addition, you might be wise to disable any unused switch ports to prevent someone from discovering a live port that might be exploited.

VLAN Hopping

When securing VLAN trunks, also consider the potential for an exploit called VLAN hopping. Here, an attacker positioned on one access VLAN can craft and send frames with spoofed 802.1Q tags so that the packet payloads ultimately appear on a totally different VLAN, all without the use of a router.

For this exploit to work, the following conditions must exist in the network configuration:

• The attacker is connected to an access switch port.

• The same switch must have an 802.1Q trunk.

• The trunk must have the attacker's access VLAN as its native VLAN.

Figure 18-3 shows how VLAN hopping works. The attacker, situated on VLAN 10, sends frames that are doubly tagged as if an 802.1Q trunk is being used. Naturally, the attacker is not connected to a trunk; he is spoofing the trunk encapsulation to trick the switch into making the frames hop over to another VLAN.

Figure 18-3. VLAN Hopping Attack Process

The regular frameor malicious payload, in this casefirst is given an 802.1Q tag with the VLAN ID of the target VLAN. Then a second bogus 802.1Q tag is added with the attacker's access VLAN ID.

When the local switch Catalyst A receives a doubly tagged frame, it decides to forward it out the trunk interface. Because the first (outermost) tag has the same VLAN ID as the trunk's native VLAN, that tag is removed as the frame is sent on the trunk. The switch believes that the native VLAN should be untagged, as it should. Now the second (innermost) tag is exposed on the trunk.

When Catalyst B receives the frame, it examines any 802.1Q tag it finds. The spoofed tag for VLAN 20 is found, so the tag is removed and the frame is forwarded onto VLAN 20. Now the attacker successfully has sent a frame on VLAN 10 and gotten the frame injected onto VLAN 20all through Layer 2 switching.

Clearly, the key to this type of attack revolves around the use of untagged native VLANs. Therefore, to thwart VLAN hopping, you always should carefully configure trunk links with the following steps:

Step 1.	Set the native VLAN of a trunk to a bogus or unused VLAN ID.
Step 2.	Prune the native VLAN off both ends of the trunk.

For example, suppose that an 802.1Q trunk should carry only VLANs 10 and 20. You should set the native VLAN to an unused value, such as 800. Then you should remove VLAN 800 from the trunk so that it is confined to the trunk link itself. Example 18-5 demonstrates how to accomplish this.

Example 18-5. Configuring the 802.1Q Trunk to Carry Only VLANs 10 and 20

Switch(config)# vlan 800 Switch(config-vlan)# name bogus_native Switch(config-vlan)# exit Switch(config)# interface gigabitethernet 1/1 Switch(config-if)# switchport trunk encapsulation dot1q Switch(config-if)# switchport trunk native vlan 800 Switch(config-if)# switchport trunk allowed vlan remove 800 Switch(config-if)# switchport mode trunk

Tip

Although maintenance protocols such as CDP, PAgP, and DTP normally are carried over the native VLAN of a trunk, they will not be affected if the native VLAN is pruned from the trunk. They still will be sent and received on the native VLAN as a special case even if the native VLAN ID is not in the list of allowed VLANs.

One alternative is to force all 802.1Q trunks to add tags to frames for the native VLAN, too. The double-tagged VLAN hopping attack won't work because the switch won't remove the first tag with the native VLAN ID (VLAN 10 in the example). Instead, that tag will remain on the spoofed frame as it enters the trunk. At the far end of the trunk, the same tag will be examined, and the frame will stay on the original access VLAN (VLAN 10).

To force a switch to tag the native VLAN on all its 802.1Q trunks, you can use the following command:

Switch(config)# vlan  dot1q tag native

Switch Port Monitoring

Suppose that a problem exists on your switched network and you want to use a network analyzer to gather data. Of interest is a conversation between two hosts connected to the switch, one on interface FastEthernet 1/1 and the other on FastEthernet 4/7. Both ports are assigned to VLAN 100. If you connect your analyzer to another port on VLAN 100, what will your packet capture show?

Recall that, by definition, switches learn where MAC addresses are located and forward packets directly to those ports. The only time a packet is flooded to ports other than the specific destination is when the destination MAC address has not already been located or when the packet is destined for a broadcast or multicast address. Therefore, your packet capture shows only the broadcast and multicast packets that were flooded to the analyzer's port. None of the interesting conversation will be overheard.

Catalyst switches can use the Switched Port Analyzer (SPAN) feature to mirror traffic from one source switch port or VLAN to a destination port. This allows a monitoring device, such as a network analyzer or an intrusion-detection system (IDS) sensor, to be attached to the destination port for capturing traffic.

When packets arrive on the source port or VLAN, they are specially marked so that they can be copied to the SPAN destination port along with the true destination port. In this way, the packet capture receives an exact copy of the packets that are being forwarded from the source.

SPAN is available in several different forms:

• Local SPAN Both the SPAN source and destination are located on the local switch. The source is one or more switch ports.

• VLAN-based SPAN (VSPAN) A variation of local SPAN in which the source is a VLAN instead of a physical port.

• Remote SPAN (RSPAN) The SPAN source and destination are located on different switches. Mirrored traffic is copied over a special-purpose VLAN across trunks between switches from the source to the destination.

The sections that follow describe each of these SPAN forms in more detail.

Local SPAN and VSPAN

The SPAN source can be identified as one or more physical switch ports, a trunk, or a VLAN. Packets that are being forwarded from the destination also are copied into the destination port's queue. Because the packets are merely copied, neither the original data nor its being forwarded is affected. Figure 18-4 demonstrates two cases in which a network analyzer on the SPAN destination port is receiving frames that SPAN has copied from the source port. Here, SPAN session A monitors all communication on VLAN 100. SPAN session B uses a normal access-mode source port to monitor communication between a server and its client PCs.

Figure 18-4. Basic Local SPAN and VSPAN Operation

What happens if a speed mismatch occurs between the SPAN source and destination ports? This easily could happen if the source is a VLAN with many hosts, or if the source is a GigabitEthernet port and the destination is a FastEthernet port.

Packets are copied only into the destination port's egress queue. If the destination port becomes congested, the SPAN packets are dropped from the queue and are not seen at the destination port. Therefore, if the bandwidth of source traffic exceeds the destination port speed, some packets might not be seen at the destination port. Then traffic from the SPAN source is not affected by any congestion at the SPAN destination.

Local SPAN and VSPAN Configuration

You can configure one or more simultaneous SPAN sessions on a Catalyst switch. These sessions are completely independent because no interaction occurs between the packet mirroring of each.

To configure a SPAN session, start by defining the source of the SPAN session data, using the following global configuration command:

Switch(config)# monitor session session source {innterface type mod/num | vlan vlan-id} [rx | tx | both]

SPAN sessions must be numbered uniquely using the session parameter. The maximum number of supported sessions varies among Catalyst platforms. For example, a Catalyst 3750 can support two sessions, whereas a Catalyst 6500 can support up to 64. If multiple sources are needed, you can repeat this command. The SPAN source can be a physical switch interface or a Layer 2 VLAN (not a logical VLAN interface or SVI).

Traffic can be selected for mirroring based on the direction it is traveling through the SPAN source. For example, you can select only traffic received on the source (rx), only traffic transmitted from the source (tx), or traffic in both directions (both). By default, both directions are used.

Next, identify the SPAN destination. You must assign the SPAN source and destination ports to the same VLAN within the switch; otherwise, the switch cannot copy frames from one VLAN to another. Use the following global configuration command to identify the SPAN destination:

Switch(config)# monitor session session destination {interface type mod/num | vlan vlan-id}

The session number here must match the one configured for the SPAN source. You can define only one destination port for each SPAN session. In addition, SPAN sessions cannot share a destination port. The destination can be a physical interface (interface) or a Layer 2 VLAN (vlan, not a VLAN SVI interface).

Tip

If the source interface is a trunk, the destination interface also should be configured as an unconditional trunk.

You can narrow the data copied over from the source, if necessary. If the source is a trunk port, you can mirror only traffic from specific VLANs on the trunk with the following global configuration command:

Switch(config)# monitor session session filter vlan vlan-range

Also, if using a VACL, you can identify and mark interesting traffic for SPAN capture. In this case, use the capture keyword in the VACL action statement.

You can delete a SPAN session after the packet analysis is complete. SPAN sessions are numbered, so you can delete them by referencing the number. Use the following global configuration command to delete one or more sessions:

Switch(config)# no monitor session {{range session-range} | local |all | session}

Session numbers can be given as an individual session, a range of sessions, all local SPAN sessions, or all sessions (local or remote). To see the list of currently active SPAN sessions, use the show monitor EXEC command, as shown in Example 18-6. Here, two SPAN sessions are in use on a Catalyst 3750.

Example 18-6. Displaying the Currently Active SPAN Sessions

Switch# show monitor Session 1 ---------  Type       : Local Session Source Ports:     RX Only:        None     TX Only:        None     Both:           Fa1/0/7 Source VLANs:     RX Only:        None     TX Only:        None     Both:           None Source RSPAN VLAN:  None Destination Ports:  Fa1/0/47     Encapsulation:  Native           Ingress:  Disabled Reflector Port:     None Filter VLANs:       None Dest RSPAN VLAN:    None Session 2 ---------  Type       : Local Session Source Ports:     RX Only:        None     TX Only:        None     Both:           Gi1/0/1 Source VLANs:     RX Only:        None     TX Only:        None     Both:           None Source RSPAN VLAN:  None Destination Ports:  Gi1/0/2     Encapsulation:  Native           Ingress:  Disabled Reflector Port:     None Filter VLANs:       None Dest RSPAN VLAN:    None

Caution

When you finish using a SPAN session, you always should disable or delete it. Otherwise, someone later 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.

Note

When local SPAN or VSPAN is enabled, the Spanning Tree Protocol (STP) is disabled on the destination port. This allows STP BPDUs to be captured and monitored but also allows the possibility for a bridging loop to form. Never connect a SPAN session's destination port back into an active network. If the monitored packets need to be sent toward another switch, use RSPAN instead.

Remote SPAN

In a large switched network or one that is geographically separated, it might not always be convenient to take a network analysis to the switch where a SPAN source is located. To make SPAN more extensible, Cisco developed the Remote SPAN (RSPAN) feature. With RSPAN, the source and destination can be located on different switches in different locations.

The RSPAN source is identified on one switch, just as with local SPAN. The RSPAN destination is identified on its local switch. Then RSPAN can carry only the mirrored data over a special-purpose VLAN across trunk links and intermediate switches. As long as every switch along the way is RSPAN capable, the source can be located at the far-end switch, while the network analyzer conveniently is located at the switch nearest you.

Figure 18-5 shows an example network using RSPAN where the packets from the file server (source port) on one switch are copied and transported over the RSPAN VLAN on trunk links. At the destination switch, packets are pulled off the RSPAN VLAN and copied to the network analyzer (destination port). The file server and network analyzer are stationed in geographically separate locations.

Figure 18-5. Example of Remote SPAN Operation

The RSPAN VLAN has some important differences from a regular VLAN. First, MAC address learning is disabled on the RSPAN VLAN. This is to prevent intermediate switches that transport the RSPAN VLAN from trying to forward the mirrored packets to their real destination MAC addresses. After all, the purpose of SPAN or RSPAN is to simply mirror or copy interesting frames, not forward them normally.

An RSPAN-capable switch also floods the RSPAN packets out all its ports belonging to the RSPAN VLAN, in an effort to send them toward the RSPAN destination. Intermediate switches have no knowledge of the RSPAN source or destination; they know only of the RSPAN VLAN itself.

Remote SPAN Configuration

RSPAN configuration begins with the definition of the special-purpose RSPAN VLAN. If you configure the RSPAN VLAN on a VTP server, VTP correctly propagates it to other intermediate switches. If not using VTP, be sure to configure this VLAN for RSPAN explicitly on each intermediate switch. Otherwise, the RSPAN packets will not be delivered correctly.

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.

Create and maintain one or more RSPAN VLANs for the special monitoring purpose only. Set aside one RSPAN VLAN for each RSPAN session that will be used. Don't allow any normal hosts to join an RSPAN VLAN. Define an RSPAN VLAN on each switch between the source and destination with the following configuration commands:

Switch(config)# vlan vlan-id Switch(config-vlan)# remote-span

Next, you must identify the RSPAN source and destination on the two switches where the source and destination are connected. At the source switch, identify the source and destination with the following global configuration commands:

Switch(config)# monitor session session source {interface type mod/num | vlan vlan-id} [rx | tx | both] Switch(config)# monitor session session destination remote vlan rspan-vlan-id

Here, the source is either a physical switch interface or a Layer 2 VLAN (not a VLAN SVI interface). Notice that the command syntax is identical to the local SPAN source command. The RSPAN destination is simply the RSPAN VLAN. This allows the mirrored packets to be copied into the special VLAN and sent on their way toward the final RSPAN destination.

At the destination switch, you again must identify the RSPAN source and destination by using the following global configuration commands:

Switch(config)# monitor session session source remote vlan rspan-vlan-id Switch(config)# monitor session session destination {interface type mod/num | vlan vlan-id}

Here the roles are reversed. RSPAN packets are pulled from the RSPAN VLAN and placed onto the destination, which is either a physical switch interface or a Layer 2 VLAN.

Note

Be aware that RSPAN traffic can increase the traffic load on a trunk, even though RSPAN is restricted to one special VLAN within the trunk. If the additional load is significant, the normal production and the monitored traffic contend with each other for available bandwidth. As a result, both types of traffic could suffer.

Also, 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.

In Example 18-7, RSPAN is configured on all three switches shown in Figure 18-5. The source is connected to Catalyst A port FastEthernet 1/1. The destination is a network analyzer connected to port FastEthernet 4/48 on Catalyst C. Catalyst B simply passes the RSPAN session traffic over VLAN 999, transported by trunk links.

Example 18-7. Configuring RSPAN on the Catalyst Switches in Figure 18-5

Catalyst A vlan 999       remote-span monitor session 1 source interface fastethernet 1/1 both monitor session 1 destination remote vlan 999 ______________________________________________________ Catalyst B vlan 999       remote-span ______________________________________________________ Catalyst C vlan 999       remote-span monitor session 1 source remote vlan 999 monitor session 1 destination interface fastethernet 4/48