Switch Security Best Practices for Unused and User Ports

The first three items in the list of best practices for unused and user ports are mostly covered in earlier chapters. For a brief review, Example 18-7 shows an example configuration on a Cisco 3550 switch, with each of these items configured and noted. In this example, fa0/1 is a currently unused port. CDP has been disabled on the interface, but it remains enabled globally, on the presumption that some ports still need CDP enabled. DTP has been disabled as well, and STP Root Guard and BPDU Guard are enabled.

Example 18-7 Disabling CDP and DTP and Enabling Root Guard and BPDU Guard

! The cdp run command keeps CDP enabled globally, but it has been disabled on ! fa0/1, the unused port. cdp run int fa0/0 no cdp enable

! The switchport mode access interface subcommand prevents the port from trunking, and the switchport nonegotiate command prevents any DTP messages from being sent or processed.

switchport mode access switchport nonegotiate

The last two interface commands enable Root Guard and BPDU Guard, per interface, respectively. BPDU Guard can also be enabled for all ports with PortFast enabled by configuring the spanning-tree portfast bpduguard enable global command, spanning-tree guard root spanning-tree bpduguard enable

Port Security

Switch port security monitors a port to restrict the number of MAC addresses associated with that port in the Layer 2 switching table. It can also enforce a restriction for only certain MAC addresses to be reachable out the port.

To implement port security, the switch adds more logic to its normal process of examining incoming frames. Instead of automatically adding a Layer 2 switching table entry for the source MAC and port number, the switch considers the port security configuration and whether it allows that entry. By preventing MACs from being added to the switch table, port security can prevent the switch from forwarding frames to those MACs on a port.

Port security supports the following key features:

.— ■ Limiting the number of MACs that can be associated with the port

Key Topic

■ Limiting the actual MAC addresses associated with the port, based on three methods:

— Static configuration of the allowed MAC addresses

— Dynamic learning of MAC addresses, up to the defined maximum, where dynamic entries are lost upon reload

— Dynamically learning but with the switch saving those entries in the configuration (called sticky learning)

Port security protects against a couple of types of attacks. Once a switch's forwarding table fills, the switch times out older entries. When the switch receives frames destined for those MACs that are no longer in the table, the switch floods the frames out all ports. An attacker could cause the switch to fill its switching table by sending lots of frames, each with a different source MAC, forcing the switch to time out the entries for most or all of the legitimate hosts. As a result, the switch floods legitimate frames because the destination MACs are no longer in the CAM, allowing the attacker to see all the frames.

An attacker could also claim to be the same MAC address as a legitimate user by simply sending a frame with that same MAC address. As a result, the switch would update its switching table, and send frames to the attacker, as shown in Figure 18-2.

Figure 18-2 Claiming to Use Another Host's MAC Address i Key \ Topic

PC-A

IP-A

MAC-A

Figure 18-2 Claiming to Use Another Host's MAC Address

PC-A

IP-A

MAC-A

PC-B

IP-B

MAC-B

1. Attacker sources frame using PC-B's actual MAC.

2. SW1 updates its MAC address table.

3. Another frame is sent to destination MAC-B.

4. SW1 forwards frame to attacker.

PC-B

IP-B

MAC-B

1. Attacker sources frame using PC-B's actual MAC.

2. SW1 updates its MAC address table.

3. Another frame is sent to destination MAC-B.

4. SW1 forwards frame to attacker.

Port security prevents both styles of these attacks by limiting the number of MAC addresses and by limiting MACs to particular ports. Port security configuration requires just a few configuration steps, all in interface mode. The commands are summarized in Table 18-4.

Table 18-4 Port Security Configuration Commands

Table 18-4 Port Security Configuration Commands

Command

Purpose

switchport mode {access 1 trunk}

Port security requires that the port be statically set as either access or trunking

switchport port-security [maximum value]

Enables port security on an interface, and optionally defines the number of allowed MAC addresses on the port (default 1)

switchport port-security mac-address mac-address [vlan {vlan-id 1 {access 1 voice}}

Statically defines an allowed MAC address, for a particular VLAN (if trunking), and for either the access or voice VLAN

Table 18-4 Port Security Configuration Commands (Continued)

Command

Purpose

switchport port-security mac-

address sticky

Tells the switch to remember the dynamically learned MAC addresses

switchport port-security [aging] [violation {protect 1 restrict 1 shutdown}]

Defines the Aging timer and actions taken when a violation occurs

Of the commands in Table 18-4, only the first two are required for port security. With just those two commands, a port allows the first-learned MAC address to be used, but no others. If that MAC address times out of the CAM, another MAC address may be learned on that port, but only one is allowed at a time.

The next two commands in the table allow for the definition of MAC addresses. The third command statically defines the permitted MAC addresses, and the fourth command allows for sticky learning. Sticky learning tells the switch to learn the MACs dynamically, but then add the MACs to the running configuration. This allows port security to be enabled and existing MAC addresses to be learned, but then have them locked into the configuration as static entries simply by saving the running configuration. (Note that the switchport port-security maximum x command would be required to allow more than one MAC address, with x being the maximum number.)

The last command in the table tells the switch what to do when violations occur. The protect option simply tells the switch to perform port security. The restrict option tells it to also send SNMP traps and issue log messages regarding the violation. Finally, the shutdown option puts the port in a err-disabled state, and requires a shutdown/no shutdown combination on the port to recover the port's forwarding state.

Example 18-8 shows a sample configuration, based on Figure 18-3. In the figure, Server 1 and Server 2 are the only devices that should ever be connected to interfaces Fast Ethernet 0/1 and 0/2, respectively. In this case, a rogue device has attempted to connect to fa0/1.

Figure 18-3 Port Security Configuration Example

;

-' 0200.1111.1111

Fa0/2 Server 2

' 0200.2222.2222

Fa0/3 Company - Comptroller

Fa0/4 User1

Example 18-8 Using Port Security to Define Correct MAC Addresses Connected to Particular Interfaces

! FA0/1 has been configured to use a static MAC address, defaulting to allow ! only one MAC address, interface FastEthernet0/1 switchport mode access switchport port-security switchport port-security mac-address 0200.1111.1111

! FA0/2 has been configured to use a sticky-learned MAC address, defaulting to ! allow only one MAC address. interface FastEthernet0/2 switchport mode access switchport port-security switchport port-security mac-address sticky FA0/1 shows as err-disabled, as a device that was not 0200.1111.1111 tried to connect. The default violation mode is shutdown, as shown. It also lists the fact that a single MAC address is configured, that the maximum number of MAC addresses is 1, and that there are 0 sticky-learned MACs. fred# show port-security interface fastEthernet 0/1 Port Security : Enabled Port status : Err-Disabled Violation mode : Shutdown Maximum MAC Addresses : 1 Total MAC Addresses : 1 Configured MAC Addresses : 1 Sticky MAC Addresses : 0 Aging time : 0 mins Aging type : Absolute SecureStatic address aging : Disabled Security Violation count : 1

FA0/2 shows as SecureUp, meaning that port security has not seen any violations on this port. Note also at the end of the stanza that the security violations count is 0. It lists the fact that one sticky MAC address has been learned. fred# show port-security interface fastEthernet 0/2 Port Security : Enabled Port status : SecureUp Violation mode : Shutdown Maximum MAC Addresses : 1 Total MAC Addresses : 1 Configured MAC Addresses : 0 Sticky MAC Addresses : 1 Aging time : 0 mins Aging type : Absolute SecureStatic address aging : Disabled Security Violation count : 0

! Note the updated configuration in the switch. Due to the sticky option, the ! switch added the last shown configuration command.

Example 18-8 Using Port Security to Define Correct MAC Addresses Connected to Particular Interfaces (Continued)

Fred# show running-config

(Lines omitted for brevity)

interface FastEthernet0/2

switchport mode access

switchport port-security

switchport port-security mac

address

sticky

switchport port-security mac

address

sticky 0200.2222.2222

The final part of the example shows that sticky learning updated the running configuration. The MAC address is stored in the running configuration, but it is stored in a command that also uses the sticky keyword, differentiating it from a truly statically configured MAC. Note that the switch does not automatically save the configuration in the startup-config file.

Dynamic ARP Inspection

A switch can use DAI to prevent certain types of attacks that leverage the use of IP ARP messages. To appreciate just how those attacks work, you need to keep in mind several detailed points about the contents of ARP messages. Figure 18-4 shows a simple example with the appropriate usage of ARP messages, with PC-A finding PC-B's MAC address.

Figure 18-4 Normal Use of ARP, Including Ethernet Addresses and ARP Fields

\ Topic

ARP Request Eth. Header ARP Message

ARP Reply

Eth. Header ARP Message

ARP Request Eth. Header ARP Message

ARP Reply

Eth. Header ARP Message

SRC

= MAC-A

SRC

= MAC-A, SRC = IP-A

SRC

= MAC-B

SRC

= MAC-B, SRC

= IP-B

DST

= b'cast

TRG

= ???, TRG = IP-B

©

DST

= MAC-A

TRG

= MAC-A, TRG

IP-A

MAC-A

PC-B

IP-B

MAC-B

Fa0/2

PC-A

IP-A

MAC-A

PC-B

IP-B

MAC-B

Attacker

PC-C

MAC-C

1. PC-A Sends ARP Broadcast Looking for IP-B's MAC Address (Target MAC)

2. PC-B Sends LAN Unicast ARP Reply

Fa0/2

Fa0/3

The ARP message itself does not include an IP header. However, it does include four important addressing fields: the source MAC and IP address of the sender of the message, and the target MAC and IP address. For an ARP request, the target IP lists the IP address whose MAC needs to be found, and the target MAC Address field is empty, as that is the missing information. Note that the ARP reply (a LAN unicast) uses the source MAC field to imply the MAC address value—for example, PC-B sets the source MAC inside the ARP message to its own MAC address, and the source IP to its own IP address.

An attacker can form a man-in-the-middle attack in a LAN by creative use of gratuitous ARPs. A gratuitous ARP occurs when a host sends an ARP reply, without even seeing an ARP request, and with a broadcast destination Ethernet address. The more typical ARP reply in Figure 18-4 shows the ARP reply as a unicast, meaning that only the host that sent the request will learn an ARP entry; by broadcasting the gratuitous ARP, all hosts on the LAN will learn an ARP entry.

While gratuitous ARPs can be used to good effect, they can also be used by an attacker. The attacker can send a gratuitous ARP, claiming to be an IP address of a legitimate host. All the hosts in the subnet (including routers and switches) update their ARP tables, pointing to the attacker's MAC address—and then later sending frames to the attacker instead of to the true host. Figure 18-5 depicts the process.

Figure 18-5 Man-in-the-Middle Attack Using Gratuitous ARPs

Topic

PC-A ARP Table

SW1 Forwarding Table

PC-A ARP Table

IP Address

MAC

IP-B

MAC-B MAC-C

SW1 Forwarding Table

Address

Port

MAC-B

Fa0/2

MAC-C

MAC-C

MAC-C

IP-B

Attacker

PC-C

MAC-C

© ARP Reply (Gratuitous) Eth. Header ARP Message

Attacker

PC-C

MAC-C

© ARP Reply (Gratuitous) Eth. Header ARP Message

SRC =

MAC-C

SRC

= MAC-C, SRC

= IP-B

DST =

B'cast

TRG

= MAC-A, TRG

Fa0/3

The steps shown in Figure 18-5 can be explained as follows:

1. The attacker broadcasts gratuitous ARP listing IP-B, but with MAC-C as the source IP and MAC.

2. PC-A updates its ARP table to list IP-B's associated address as MAC-C.

3. PC-A sends a frame to IP-B, but with destination MAC MAC-C.

4. SW1 forwards the frame to MAC-C, which is the attacker.

The attack results in other hosts, like PC-A, sending frames meant for IP-B to MAC address MAC-C—the attacker's PC. The attacker then simply forwards another copy of each frame to

PC-B, becoming a man in the middle. As a result, the user can continue to work, and the attacker can gain a much larger amount of data.

Switches use DAI to defeat ARP attacks by examining the ARP messages and then filtering inappropriate messages. DAI considers each switch port to be either untrusted (the default) or trusted, performing DAI messages only on untrusted ports. DAI examines each ARP request or reply (on untrusted ports) to decide if it is inappropriate; if inappropriate, the switch filters the ARP message. DAI determines if an ARP message is inappropriate by using the following logic:

1. If an ARP reply lists a source IP address that was not DHCP-assigned to a device off that port, DAI filters the ARP reply.

2. DAI uses additional logic like Step 1, but uses a list of statically defined IP/MAC address combinations for comparison.

3. For a received ARP reply, DAI compares the source MAC address in the Ethernet header to the source MAC address in the ARP message. These MACs should be equal in normal ARP replies; if they are not, DAI filters the ARP message.

4. Like Step 3, but DAI compares the destination Ethernet MAC and the target MAC listed in the ARP body.

5. DAI checks for unexpected IP addresses listed in the ARP message, such as 0.0.0.0, 255.255.255.255, multicasts, and so on.

Table 18-5 lists the key Cisco 3550 switch commands used to enable DAI. DAI must first be enabled globally. At that point, all ports are considered to be untrusted by DAI. Some ports, particularly ports connected to devices in secure areas (ports connecting servers, other switches, and so on), need to be explicitly configured as trusted. Then, additional configuration is required to enable the different logic options. For example, DHCP snooping needs to be enabled before DAI can use the DHCP snooping binding database to perform the logic in Step 1 in the preceding list. Optionally, you can configure static IP addresses, or perform additional validation (per the last three points in the preceding list) using the ip arp inspection validate command.

Table 18-5 Cisco IOS Switch Dynamic ARP Inspection Commands

Table 18-5 Cisco IOS Switch Dynamic ARP Inspection Commands

Command

Purpose

ip arp inspection vlan vlan-range

Global command to enable DAI on this switch for the specified VLANs.

[no] ip arp inspection trust

Interface subcommand that enables (with no option) or disables DAI on the interface. Defaults to enabled once the ip arp inspection global command has been configured.

ip arp inspection filter arp-acl-name vlan vlan-range [static]

Global command to refer to an ARP ACL that defines static IP/MAC addresses to be checked by DAI for that VLAN (Step 2 in the preceding list).

Table 18-5 Cisco IOS Switch Dynamic ARP Inspection Commands (Continued)

Command

Purpose

ip arp inspection validate {[src-mac] [dst-mac] [ip]}

Enables additional optional checking of ARP messages (per Steps 3-5 in the preceding list).

ip arp inspection limit {rate pps [burst interval seconds] 1 none}

Limits the ARP message rate to prevent DoS attacks carried out by sending a large number or ARPs.

Because DAI causes the switch to perform more work, an attacker could attempt a DoS attack on a switch by sending large numbers of ARP messages. DAI automatically sets a limit of 15 ARP messages per port per second to mitigate that risk; the settings can be changed using the ip arp inspection limit interface subcommand.

DHCP Snooping

DHCP snooping prevents the damage inflicted by several attacks that use DHCP. DHCP snooping causes a switch to examine DHCP messages and filter those considered to be inappropriate. DHCP snooping also builds a table of IP address and port mappings, based on legitimate DHCP messages, called the DHCP snooping binding table. The DHCP snooping binding table can then be used by DAI and by the IP Source Guard feature.

Figure 18-6 shows a man-in-the-middle attack that leverages DHCP. The legitimate DHCP server sits at the main site, whereas the attacker sits on the local LAN, acting as a DHCP server.

Figure 18-6 Man-in-the-Middle Attack Using DHCP

Topic

Web Server DHCP Server

-DHCP Message

---Data Message

, DHCP Request

DHCP Reply: Use IP-B, Gateway 10.1.1.2

Attacker

Acting as DHCP Server 10.1.1.2

PC-B

IP-B

MAC-B

The following steps explain how the attacker's PC can become a man in the middle in Figure 18-6:

1. PC-B requests an IP address using DHCP.

2. The attacker PC replies, and assigns a good IP/mask, but using its own IP address as the default gateway.

3. PC-B sends data frames to the attacker, thinking that the attacker is the default gateway.

4. The attacker forwards copies of the packets, becoming a man in the middle.

NOTE PC-B will use the first DHCP reply, so with the legitimate DHCP server only reachable over the WAN, the attacker's DHCP response should be the first response received by PC-B.

DHCP snooping defeats such attacks for ports it considers to be untrusted. DHCP snooping allows all DHCP messages on trusted ports, but it filters DHCP messages on untrusted ports. It operates based on the premise that only DHCP clients should exist on untrusted ports; as a result, the switch filters incoming DHCP messages that are only sent by servers. So, from a design perspective, unused and unsecured user ports would be configured as untrusted to DHCP snooping.

DHCP snooping also needs to examine the DHCP client messages on untrusted ports, because other attacks can be made using DHCP client messages. DHCP servers identify clients based on their stated client hardware address as listed in the DHCP request. A single device could pose as multiple devices by sending repeated DHCP requests, each with a different DHCP client hardware address. The legitimate DHCP server, thinking the requests are from different hosts, assigns an IP address for each request. The DHCP server will soon assign all IP addresses available for the subnet, preventing legitimate users from being assigned an address.

For untrusted ports, DHCP snooping uses the following general logic for filtering the packets: It filters all messages sent exclusively by DHCP servers.

The switch checks DHCP release and decline messages against the DHCP snooping binding table; if the IP address in those messages is not listed with the port in the DHCP snooping binding table, the messages are filtered.

3. Optionally, it compares a DHCP request's client hardware address value with the source MAC address inside the Ethernet frame.

Of the three entries in this list, the first takes care of the fake DHCP server man-in-the-middle attack shown in Figure 18-6. The second item prevents an attacking host from releasing a legitimate host's DHCP lease, then attempting to request an address and be assigned the same IP address— thereby taking over any existing connections from the original host. Finally, the last item in the list prevents the DoS attack whereby a host attempts to allocate all the IP addresses that the DHCP server can assign in the subnet.

Key Topic

Table 18-6 lists the key configuration commands for configuring DHCP snooping on a Cisco 3550 switch.

Table 18-6 Cisco IOS Switch Dynamic ARP Inspection Commands

Command

Purpose

ip dhcp snooping vlan vlan-range

Global command to enable DHCP snooping for one or more VLANs

[no] ip dhcp snooping trust

Interface command to enable or disable a trust level on an interface; no version (enabled) is the default

ip dhcp snooping binding mac-address vlan vlan-id ip-address interface interface-id expiry seconds

Global command to add static entries to the DHCP snooping binding database

ip dhcp snooping verify mac-address

Interface subcommand to add the optional check of the Ethernet source MAC address to be equal to a DHCP request's client ID

ip dhcp snooping limit rate rate

Sets the maximum number of DHCP messages per second to mitigate DoS attacks

IP Source Guard

The Cisco IOS switch IP Source Guard feature adds one more check to the DHCP snooping logic. When enabled along with DHCP snooping, IP Source Guard checks the source IP address of received packets against the DHCP snooping binding database. Alternatively, it checks both the source IP and source MAC addresses against that same database. If the entries do not match, the frame is filtered.

To better appreciate this feature, consider the example DHCP snooping binding database shown in Example 18-9. Note that each of the entries lists the MAC address and IP address, VLAN, and interface. These entries were gleaned from ports untrusted by DHCP snooping, with the DHCP snooping feature building these entries based on the source MAC address and source IP address of the DHCP requests.

Example 18-9 Sample DHCP Snooping Binding Database

\ Topic

SW1# show ip dhcp

snooping binding

Mac Address

Ip Address

Lease(sec

Type

VLAN

Interface

02:00:01:02:03:04

172.16.1.1

3412

dhcp-snooping

3

FastEthernet0/1

02:00:AA:BB:CC:DD

172.16.1.2

4916

dhcp-snooping

3

FastEthernet0/2

IP Source Guard is enabled using interface subcommands. To check just the source IP address, use the ip verify source interface subcommand; alternately, the ip verify source port-security interface subcommand enables checking of both the source IP and MAC addresses. Optionally, you can use the ip source binding mac-address vlan vlan-id ip-address interface interface-id global command to create static entries that will be used in addition to the DHCP snooping binding database. For example, with IP Source Guard enabled using the ip verify source command under interface fa0/1, the only packets allowed coming into interface fa0/1 would be those with source IP address 172.16.1.1.

802.1X Authentication Using EAP

Switches can use IEEE 802.1X to perform user authentication, rather than the types of device authentication performed by many of the other features described in this section. User authentication requires the user to supply a username and password, verified by a RADIUS server, before the switch will enable the switch port for normal user traffic. Requiring a username and password prevents the attacker from simply using someone else's PC to attack the network without first breaking the 802.1X authentication username and password.

IEEE 802.1X defines some of the details of LAN user authentication, but it also uses the Extensible Authentication Protocol (EAP), an Internet standard (RFC 3748), as the underlying protocol used for authentication. EAP includes the protocol messages by which the user can be challenged to provide a password, as well as flows that create one-time passwords (OTPs) per RFC 2289. Figure 18-7 shows the overall flow of LAN user authentication, without the details behind each message.

Figure 18-7 802.1X for LAN User Authentication

Figure 18-7 802.1X for LAN User Authentication

Ethernet 802 Frame Types

Figure 18-7 introduces a couple of general concepts plus several new terms. First, EAP messages are encapsulated directly inside an Ethernet frame when sent between the 802.1X supplicant (user device) and the 802.1X authenticator (switch). These frames are called EAP over LAN (EAPoL) frames. However, RADIUS expects the EAP message as a data structure called a RADIUS attribute, with these attributes sitting inside a normal RADIUS message. To support the two protocols, the switch translates between EAPoL and RADIUS for messages that need to flow between the supplicant and authentication server.

The rest of Figure 18-7 shows a simplistic view of the overall authentication flow. The switch and supplicant create an OTP using a temporary key, with the switch then forwarding the authentication request to the authentication server. The switch, as authenticator, must be aware of the results (Step 3), because the switch has a duty to enable the port once authenticated.

The 802.1X roles shown in Figure 18-7 are summarized as follows:

■ Supplicant—The 802.1X driver that supplies a username/password prompt to the user and sends/receives the EAPoL messages

■ Authenticator—Translates between EAPoL and RADIUS messages in both directions, and enables/disables ports based on the success/failure of authentication

■ Authentication server—Stores usernames/passwords and verifies that the correct values were submitted before authenticating the user

802.1X switch configuration resembles the AAA configuration covered in the section titled "Using a Default Set of Authentication Methods" earlier in this chapter. The switch configuration treats 802.1X user authentication as another option for AAA authentication, using the following steps:

Step 1 As with other AAA authentication methods, enable AAA with the aaa new-model global command.

Step 2 As with other configurations using RADIUS servers, define the RADIUS server(s) IP address(es) and encryption key(s) using the radius-server host and radius-server key commands.

Step 3 Similar to login authentication configuration, define the 802.1X authentication method (RADIUS only today) using the aaa authentication dot1x default command or, for multiple groups, the aaa authentication dot1x group name global command.

Step 4 Enable 802.1X globally using the dot1x system auth-control global command.

Step 5 Set each interface to use one of three operational settings using the dot1x port-control {auto I force-authorized I force-unauthorized} interface subcommand:

• Not using 802.1X, but the interface is automatically authorized (force-authorized) (default)

• Not using 802.1X, but the interface is automatically unauthorized (force-unauthorized)

Example 18-10 shows a simple 802.1X configuration on a Cisco 3550 switch. The example shows a reasonable configuration based on Figure 18-3 earlier in the chapter, with servers off ports fa0/1 and fa0/2, and two users off ports fa0/3 and fa0/4. Also, consider fa0/5 as an unused port. Note that at the time of this writing, RADIUS is the only available authentication method for 802.1X in the Cisco 3550 and 3560 switches.

Example 18-10 Example Cisco 3550 802.1X Configuration

! The first three commands enable AAA, define that 802.1x should use the RADIUS ! group comprised of all defined RADIUS servers, and enable 802.1X globally, aaa new-model aaa authentication dotlx default group radius

Example 18-10 Example Cisco 3550 802.1X Configuration

! The first three commands enable AAA, define that 802.1x should use the RADIUS ! group comprised of all defined RADIUS servers, and enable 802.1X globally, aaa new-model aaa authentication dotlx default group radius

dot1x system auth-control

! Next, commands shown previously are used to define the default radius group

! These commands are unchanged compared to earlier examples, radius-server host 10.1.1.1 auth-port 1812 acct-port 1646 radius-server host 10.1.1.2 auth-port 1645 acct-port 1646 radius-server key cisco

! The server ports (fa0/1 and fa0/2), inside a secure datacenter, do not require ! 802.1x authentication, int fa0/1

dot1x port-control force-authorized int fa0/2 dot1x port-control force-authorized

! The client ports (fa0/3 and fa0/4) require 802.1x authentication, int fa0/3 dot1x port-control auto int fa0/4 dot1x port-control auto

! These commands are unchanged compared to earlier examples, radius-server host 10.1.1.1 auth-port 1812 acct-port 1646 radius-server host 10.1.1.2 auth-port 1645 acct-port 1646 radius-server key cisco

! The server ports (fa0/1 and fa0/2), inside a secure datacenter, do not require ! 802.1x authentication, int fa0/1

dot1x port-control force-authorized int fa0/2 dot1x port-control force-authorized

! The client ports (fa0/3 and fa0/4) require 802.1x authentication, int fa0/3 dot1x port-control auto int fa0/4 dot1x port-control auto int fa0/5

dot1x port-control force-unauthorized int fa0/5

dot1x port-control force-unauthorized

Storm Control

Cisco IOS for Catalyst switches supports rate-limiting traffic at Layer 2 using the storm-control commands. Storm control can be configured to set rising and falling thresholds for each of the three types of port traffic: unicast, multicast, and broadcast. Each rate limit can be configured on a per-port basis.

You can configure storm control to operate on each traffic type based on either packet rate or a percentage of the interface bandwidth. You can also specify rising and falling thresholds for each traffic type. If you don't specify a falling threshold, or if the falling threshold is the same as the rising threshold, the switch port will forward all traffic up to the configured limit and will not wait for that traffic to pass a specified falling threshold before forwarding it again.

When any of the configured thresholds is passed, the switch can take any of three additional actions, also on a per-port basis. The first, and the default, is that the switch can rate-limit by discarding excess traffic according to the configured command(s) and take no further action. The other two actions include performing the rate-limiting function and either shutting down the port or sending an SNMP trap.

Let's say we have the following goals for a storm-control configuration:

Limit broadcast traffic to 100 packets per second. When broadcast traffic drops back to 50 packets per second, begin forwarding broadcast traffic again.

Limit multicast traffic to 0.5 percent of the 100-Mbps interface rate, or 500 kbps. When multicast traffic drops back to 400 kbps, begin forwarding multicast traffic again.

■ Limit unicast traffic to 80 percent of the 100-Mbps interface rate, or 80 Mbps. Forward all unicast traffic up to this limit.

■ When any of these three conditions occurs and results in rate-limiting, send an SNMP trap. The configuration that results is shown in Example 18-11.

Example 18-11 Storm Control Configuration Example

Cat3560(config)# interface FastEthernet0/10 Cat3560(config-if)# storm-control broadcast level pps 100 50 Cat3560(config-if)# storm-control multicast level 0.50 0.40 Cat3560(config-if)# storm-control unicast level 80.00 Cat3560(config-if)# storm-control action trap Cat3560(config-if)# end Cat3560# show storm-control fa0/10 unicast Interface Filter State Upper Lower Current

Fa0/10 Forwarding 80.00% 80.00% 0.00%

Cat3560# show storm-control fa0/10 broadcast

Interface Filter State Upper Lower Current

Fa0/10 Forwarding 100 pps 50 pps 0 pps

Cat3560# show storm-control fa0/10 multicast

Interface Filter State Upper Lower Current

Jun 10 14:24:47.595: %STORM_CONTROL-3-FILTERED: A Multicast storm detected on

Fa0/19. A packet filter action has been applied on the interface. ! The preceding output indicates that the multicast storm threshold was ! exceeded and the switch took the action of sending ! an SNMP trap to indicate this condition.

'Key One important caveat about storm control is that it supports only physical ports. The configuration Topic commands are available on EtherChannel (port-channel) interfaces, but they have no effect.

Was this article helpful?

0 0

Post a comment