Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:

BCMSN Exam Certification Guide

.pdf
Скачиваний:
64
Добавлен:
24.05.2014
Размер:
10.82 Mб
Скачать

476 Chapter 20: Securing with VLANs

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 20-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 20-1 Private VLAN Functionality Within a Switch

 

 

Secondary VLAN 10

 

 

1/1

(Community)

 

 

 

 

 

1/2

 

 

 

 

Secondary VLAN 30

2/1

Host Ports

1/3

(Isolated)

 

 

 

 

Primary VLAN

 

 

 

(Promiscuous)

 

1/4

 

 

 

1/5

 

 

 

 

Secondary VLAN 20

 

 

 

(Community)

 

Private VLANs 477

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 of its component secondary VLANs using the association keyword. If the primary VLAN has already 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 must also 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.

478 Chapter 20: Securing with VLANs

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 Configuring a static access VLAN on a switch port when the port is associated with private VLANs is not necessary. 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 the switch in Figure 20-1 is configured as in Example 20-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 20-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

Private VLANs 479

Example 20-2 Configuring Ports with Private VLANs (Continued)

Switch(config-vlan)# exit

Switch(config)# interface range fastethernet 1/1 – 1/2

Switch(config-if)# switchport private-vlan host-association 100 10

Switch(config)# interface range fastethernet 1/4 – 1/5

Switch(config-if)# switchport private-vlan host-association 100 20

Switch(config)# interface fastethernet 1/3

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 20-3.

Example 20-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 only good at 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 has already been configured for the primary VLAN SVI, you can add (add) or remove (remove) secondary VLAN mappings individually.

480 Chapter 20: Securing with VLANs

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

interface vlan 200

private-vlan mapping 40,50

Switch Port Monitoring

Suppose 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, 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 as well as 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 where the source is a VLAN rather than 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.

Switch Port Monitoring 481

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 are also copied into the destination port’s queue. Because the packets are merely copied, neither the original data nor its being forwarded is affected. Figure 20-2 demonstrates two cases where 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 20-2 Basic Local SPAN and VSPAN Operation

File Server

 

 

A: VSPAN

 

 

 

 

 

 

 

 

 

Server

 

PC

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

B: Source

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Source - VLAN 100

 

 

 

 

 

 

 

 

 

 

Port

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

B: Destination

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Port

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Network

 

 

 

 

 

 

 

 

 

 

 

Network

Analyzer

 

 

 

 

 

 

 

 

 

 

 

Analyzer

 

A

 

 

 

 

 

 

 

 

 

 

 

 

B

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

PC

What happens if a speed mismatch occurs between the SPAN source and destination ports? This could easily 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.

482 Chapter 20: Securing with VLANs

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 {interface type mod/num | vlan vlan-id} [rx | tx | both]

SPAN sessions must be uniquely numbered using the session parameter. The maximum number of supported sessions varies among Catalyst platforms. For example, a Catalyst 3550 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} | {analysis-module slot-number} | {data-port port-number}}

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, a Layer 2 VLAN (not a VLAN SVI interface), or a Network Analysis Module (NAM, Catalyst 6500 only).

You can narrow down 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-number 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.

Switch Port Monitoring 483

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 20-4. Here, two SPAN sessions are in use on a Catalyst 3550.

Example 20-4 Displaying the Currently Active SPAN Sessions

Switch# show monitor

Session 1

 

---------

 

Type

: Local Session

Source

Ports:

 

RX

Only:

None

TX

Only:

None

Both:

Fa0/7

Source

VLANs:

 

RX

Only:

None

TX

Only:

None

Both:

None

Source

RSPAN VLAN:

None

Destination Ports:

Fa0/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:

Gi0/1

Source

VLANs:

 

RX

Only:

None

TX

Only:

None

Both:

None

continues

484 Chapter 20: Securing with VLANs

Example 20-4 Displaying the Currently Active SPAN Sessions (Continued)

Source RSPAN VLAN: None

Destination Ports: Gi0/2

Encapsulation: Native

Ingress: Disabled

Reflector Port: None

Filter VLANs: None

Dest RSPAN VLAN: None

CAUTION After you finish using a SPAN session, you should always disable or delete it. Otherwise, someone might try to connect to the port that is configured as the SPAN destination at some later date. 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 is conveniently located at the switch nearest you.

Figure 20-3 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.

Switch Port Monitoring 485

Figure 20-3 Example of Remote SPAN Operation

Trunk

Trunk

Source

RSPAN

 

Port

Trunk

Destination

Port

Network

Analyzer

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 of 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; rather, 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.

Соседние файлы в предмете Сети и Телекоммуникации