Catalyst 4500 Series Switch Software Configuration Guide, IOS XE 3.8.xE and IOS 15.2(4)Ex

Trusted and Untrusted Sources

The DHCP snooping feature determines whether traffic sources are trusted or untrusted. An untrusted source may initiate traffic attacks or other hostile actions. To prevent such attacks, the DHCP snooping feature filters messages and rate-limits traffic from untrusted sources.

In an enterprise network, devices under your administrative control are trusted sources. These devices include the switches, routers and servers in your network. Any device beyond the firewall or outside your network is an untrusted source. Host ports are generally treated as untrusted sources.

In a service provider environment, any device that is not in the service provider network is an untrusted source (such as a customer switch). Host ports are untrusted sources.

In the Catalyst 4500 series switch, you indicate that a source is trusted by configuring the trust state of its connecting interface.

The default trust state of all interfaces is untrusted. You must configure DHCP server interfaces as trusted. You can also configure other interfaces as trusted if they connect to devices (such as switches or routers) inside your network. You usually do not configure host port interfaces as trusted.

Note For DHCP snooping to function properly, all DHCP servers must be connected to the switch through trusted interfaces, as untrusted DHCP messages will be forwarded only to trusted interfaces.

About the DHCP Snooping Database Agent

To retain the bindings across switch reloads, you must use the DHCP snooping database agent. Without this agent, the bindings established by DHCP snooping are lost upon switch reload. Connectivity is lost as well.

The mechanism for the database agent stores the bindings in a file at a configured location. Upon reload, the switch reads the file to build the database for the bindings. The switch keeps the file current by writing to the file as the database changes.

The format of the file that contains the bindings is as follows:

Each entry in the file is tagged with a checksum that is used to validate the entries whenever the file is read. The <initial-checksum> entry on the first line helps distinguish entries associated with the latest write from entries that are associated with a previous write.

it is a sample bindings file:

Each entry holds an IP address, VLAN, MAC address, lease time (in hex), and the interface associated with a binding. At the end of each entry is a checksum that accounts for all the bytes from the start of the file through all the bytes associated with the entry. Each entry consists of 72 bytes of data, followed by a space, followed by a checksum.

Upon bootup, when the calculated checksum equals the stored checksum, a switch reads entries from the file and adds the bindings to the DHCP snooping database. When the calculated checksum does not equal the stored checksum, the entry read from the file is ignored and so are all the entries following the failed entry. The switch also ignores all those entries from the file whose lease time has expired. (This situation is possible because the lease time might indicate an expired time.) An entry from the file is also ignored if the interface referred to in the entry no longer exists on the system or if it is a router port or a DHCP snooping-trusted interface.

When a switch learns of new bindings or when it loses some bindings, the switch writes the modified set of entries from the snooping database to the file. The writes are performed with a configurable delay to batch as many changes as possible before the actual write happens. Associated with each transfer is a timeout after which a transfer is aborted if it is not completed. These timers are referred to as the write delay and abort timeout.

Option 82 Data Insertion

In residential, metropolitan Ethernet-access environments, DHCP can centrally manage the IP address assignments for a large number of subscribers. When the DHCP Option 82 feature is enabled on the switch, a subscriber device is identified by the switch port through which it connects to the network (in addition to its MAC address). Multiple hosts on the subscriber LAN can be connected to the same port on the access switch and are uniquely identified.

Note The DHCP Option 82 feature is supported only when DHCP snooping is globally enabled and on the VLANs to which subscriber devices using this feature are assigned.

Figure 56-1 is an example of a metropolitan Ethernet network in which a centralized DHCP server assigns IP addresses to subscribers connected to the switch at the access layer. Because the DHCP clients and their associated DHCP server do not reside on the same IP network or subnet, a DHCP relay agent (the Catalyst switch) is configured with a helper address to enable broadcast forwarding and to transfer DHCP messages between the clients and the server.

Figure 56-1 DHCP Relay Agent in a Metropolitan Ethernet Network

When you enable the DHCP snooping information Option 82 on the switch, this sequence of events occurs:

• The host (DHCP client) generates a DHCP request and broadcasts it on the network.
• When the switch receives the DHCP request, it adds the Option 82 information in the packet. By default, the remote ID suboption is the switch MAC address, and the circuit ID suboption is the port identifier, vlan-mod-port, from which the packet is received. Beginning with Cisco IOS Release 12.2(40)SG, you can configure the remote ID and circuit ID. For information on configuring these suboptions, see the “Enabling DHCP Snooping and Option 82” section.
• If the IP address of the relay agent is configured, the switch adds this IP address in the DHCP packet.
• The switch forwards the DHCP request that includes the Option 82 field to the DHCP server.
• The DHCP server receives the packet. If the server is Option 82-capable, it can use the remote ID, the circuit ID, or both to assign IP addresses and implement policies, such as restricting the number of IP addresses that can be assigned to a single remote ID or circuit ID. The DHCP server then echoes the Option 82 field in the DHCP reply.
• The DHCP server unicasts the reply to the switch if the request was relayed to the server by the switch. The switch verifies that it originally inserted the Option 82 data by inspecting the remote ID and possibly the circuit ID fields. The switch removes the Option 82 field and forwards the packet to the switch port that connects to the DHCP client that sent the DHCP request.

In the default suboption configuration, when the described sequence of events occurs, the values in these fields in Figure 56-2 do not change:

• Circuit ID suboption fields

– Suboption type

– Length of the suboption type

– Circuit ID type

– Length of the circuit ID type

• Remote ID suboption fields

– Suboption type

– Length of the suboption type

– Remote ID type

– Length of the remote ID type

Figure 56-2 shows the packet formats for the remote ID suboption and the circuit ID suboption when the default suboption configuration is used. For the circuit ID suboption, the module number corresponds to the switch module number. The switch uses the packet formats when you globally enable DHCP snooping and enter the ip dhcp snooping information option global configuration command.

Figure 56-2 Suboption Packet Formats

Figure 56-3 shows the packet formats for user-configured remote ID and circuit ID suboptions. The switch uses these packet formats when DHCP snooping is globally enabled and when the ip dhcp snooping information option format remote-id global configuration command and the ip dhcp snooping vlan information option format-type circuit-id string interface configuration command are entered.

The values for these fields in the packets change from the default values when you configure the remote ID and circuit ID suboptions:

• Circuit ID suboption fields

– The circuit ID type is 1.

– The length values are variable, depending on the length of the string that you configure.

• Remote ID suboption fields

– The remote ID type is 1.

– The length values are variable, depending on the length of the string that you configure.

Figure 56-3 User-Configured Suboption Packet Formats

Default Configuration for DHCP Snooping

DHCP snooping is disabled by default. Table 56-1 shows all the default configuration values for each DHCP snooping option.

If you want to change the default configuration values, see the “Enabling DHCP Snooping” section.

Enabling DHCP Snooping

Note When DHCP snooping is enabled globally, DHCP requests are dropped until the ports are configured. Consequently, you should probably configure this feature during a maintenance window and not during production.

To enable DHCP snooping, perform this task:

You can configure DHCP snooping for a single VLAN or a range of VLANs. To configure a single VLAN, enter a single VLAN number. To configure a range of VLANs, enter a beginning and an ending VLAN number or a dash and range of VLANs.

The number of incoming DHCP packets is rate-limited to prevent a denial-of-service attack. When the rate of incoming DHCP packets exceeds the configured limit, the switch places the port in the errdisabled state. To prevent the port from shutting down, you can use the errdisable detect cause dhcp-rate-limit action shutdown vlan global configuration command to shut down just the offending VLAN on the port where the violation occurred.

When a secure port is in the errdisabled state, you can bring it out of this state automatically by configuring the errdisable recovery cause dhcp-rate-limit global configuration command or you can manually reenable it by entering the shutdown and no shut down interface configuration commands. If a port is in per-VLAN errdisable mode, you can also use clear errdisable interface name vlan range command to reenable the VLAN on the port.

This example shows how to enable DHCP snooping on VLAN 500 through 555:

The following configuration describes the DHCP snooping configuration steps if routing is defined on another Catalyst switch (for example, a Catalyst 6500 series switch):

Note If you are enabling trunking on uplink gigabit interfaces, and the above routing configuration is defined on a Catalyst 6500 series switch, you must configure the “trust” relationship with downstream DHCP snooping (on a Catalyst 4500 series switch) which adds Option 82. On a Catalyst 6500 series switch, this task is accomplished with the ip dhcp relay information trusted VLAN configuration command.

Enabling DHCP Snooping on the Aggregation Switch

To enable DHCP snooping on an aggregation switch, configure the interface connecting to a downstream switch as a snooping untrusted port. If the downstream switch (or a device such as a DSLAM in the path between the aggregation switch and the DHCP clients) adds DHCP information Option 82 to the DHCP packets, the DHCP packets would be dropped on arriving on a snooping untrusted port. If you configure the ip dhcp snooping information option allow-untrusted global configuration command on the aggregation switch, the aggregation switch can accept DHCP requests with Option 82 information from any snooping untrusted port.

Enabling DHCP Snooping and Option 82

To enable DHCP snooping and Option 82 on the switch, perform the following steps:

To disable DHCP snooping, use the no ip dhcp snooping global configuration command. To disable DHCP snooping on a VLAN or range of VLANs, use the no ip dhcp snooping vlan vlan-range global configuration command. To disable the insertion and removal of the Option 82 field, use the no ip dhcp snooping information option global configuration command. To configure an aggregation switch to drop incoming DHCP snooping packets with Option 82 information from an edge switch, use the no ip dhcp snooping information option allow-untrusted global configuration command.

This example shows how to enable DHCP snooping globally and on VLAN 10 and to configure a rate limit of 100 packets per second on a port:

The following example shows how to enable DHCP snooping on VLAN 500 through 555 and option 82 circuit-id:

This example shows how to configure the Option 82 circuit-ID override suboption:

Enabling DHCP Snooping on Private VLAN

DHCP snooping can be enabled on private VLANs, which provide isolation between Layer 2 ports within the same VLAN. If DHCP snooping is enabled (or disabled), the configuration is propagated to both the primary VLAN and its associated secondary VLANs. You cannot enable (or disable) DHCP snooping on a primary VLAN without reflecting this configuration change on the secondary VLANs.

Configuring DHCP snooping on a secondary VLAN is still allowed, but it does not take effect if the associated primary VLAN is already configured. If the associated primary VLAN is configured, the effective DHCP snooping mode on the secondary VLAN is derived from the corresponding primary VLAN. Manually configuring DHCP snooping on a secondary VLAN causes the switch to issue this warning message:

The show ip dhcp snooping command displays all VLANs (both primary and secondary) that have DHCP snooping enabled.

Configuring DHCP Snooping on Private VLAN

DHCP snooping, IPSG, and DAI are Layer 2-based security features that can be enabled and disabled on an individual VLAN, including auxiliary or voice VLAN. You need to enable DHCP snooping on a voice VLAN for a Cisco IP phone to function properly.

Configuring DHCP Snooping with an Ethernet Channel Group

When you configure DHCP snooping, you need to configure trunk interfaces that transmit DHCP packets as trusted interfaces by adding ip dhcp snooping trust to the physical interface configuration. However, if DHCP packets will be transmitted over an Ethernet channel group, you must configure
ip dhcp snooping trust on the logical port channel interface, for example:

Enabling the DHCP Snooping Database Agent

To configure the database agent, perform one or more of the following tasks:

Note Because both NVRAM and bootflash have limited storage capacity, you should use TFTP or network-based files. If you use flash to store the database file, new updates (by the agent) result in the creation of new files (flash fills quickly). Moreover, because of the nature of the file system used on flash, a large number of files can cause slow access. When a file is stored in a remote location accessible through TFTP, an RPR or SSO standby supervisor engine can take over the binding list when a switchover occurs.

Note Network-based URLs (such as TFTP and FTP) require that you create an empty file at the configured URL before the switch can write the set of bindings for the first time.

Limiting the Rate of Incoming DHCP Packets

The switch CPU performs DHCP validation checks; therefore, the number of incoming DHCP packets is rate-limited to prevent a denial-of-service attack.

When the rate of incoming DHCP packets exceeds the configured limit, the switch places the port in the errdisabled state. The port remains in that state until you intervene or you enable errdisable recovery so that ports automatically emerge from this state after a specified timeout period.

Note Unless you explicitly configure a rate limit on an interface, changing the trust state of the interface also changes its rate limit to the default value for that trust state. After you configure the rate limit, the interface retains the rate limit even when its trust state is changed. If you enter the
no ip dhcp snooping limit rate interface configuration command, the interface reverts to its default rate limit.

To prevent the port from shutting down, you can use the errdisable detect cause dhcp-rate-limit action shutdown vlan global configuration command to shut down just the offending VLAN on the port where the violation occurred.

To limit the rate of incoming DHCP packets, perform this task:

To return to the default rate-limit configuration, use the no ip dhcp-rate-limit interface configuration command. To disable error recovery for DHCP inspection, use the no errdisable recovery cause dhcp-rate-limit global configuration command.

This example shows how to set an upper limit for the number of incoming packets (100 pps) and to specify a burst interval (1 second):

Configuration Examples for the Database Agent

The following examples show how to configuration commands in the previous procedure:

Example 1: Enabling the Database Agent

The following example shows how to configure the DHCP snooping database agent to store the bindings at a given location and to view the configuration and operating state:

The first three lines of output show the configured URL and related timer configuration values. The next three lines show the operating state and the amount of time left for expiry of write delay and abort timers.

Among the statistics shown in the output, startup failures indicate the number of attempts the read or create of the file has failed upon bootup.

Note Because the location is based off in the network, you must create a temporary file on the TFTP server. You can create a temporary file on a typical UNIX workstation by creating a 0 byte file “file” in the directory “directory” that can be referenced by the TFTP server daemon. With some server implementations on UNIX workstations, the file should be provided with full (777) permissions for write access to the file.

DHCP snooping bindings are keyed on the MAC address and VLAN combination. If an entry in the remote file has an entry for a given MAC address and VLAN set, for which the switch already has a binding, the entry from the remote file is ignored when the file is read. This condition is referred to as the binding collision.

An entry in a file may no longer be valid because the lease indicated by the entry may have expired by the time it is read. The expired leases counter indicates the number of bindings ignored because of this condition. The Invalid interfaces counter refers to the number of bindings that have been ignored when the interface referred by the entry either does not exist on the system or is a router or DHCP snooping trusted interface if it exists, when the read happened. Unsupported VLANs refers to the number of entries that have been ignored because the indicated VLAN is not supported on the system. The Parse failures counter provides the number of entries that have been ignored when the switch is unable to interpret the meaning of the entries from the file.

The switch maintains two sets of counters for these ignored bindings. One provides the counters for a read that has at least one binding ignored by at least one of these conditions. These counters are shown as the “Last ignored bindings counters.” The total ignored bindings counters provides a sum of the number of bindings that have been ignored because of all the reads since the switch bootup. These two set of counters are cleared by the clear command. The total counter set may indicate the number of bindings that have been ignored since the last clear.

Example 2: Reading Binding Entries from a TFTP File

To manually read the entries from a TFTP file, perform this task:

it is an example of how to manually read entries from the tftp://10.1.1.1/directory/file:

Example 3: Adding Information to the DHCP Snooping Database

To manually add a binding to the DHCP snooping database, perform this task:

This example shows how to manually add a binding to the DHCP snooping database:

Displaying a Binding Table

The DHCP snooping binding table for each switch contains binding entries that correspond to untrusted ports. The table does not contain information about hosts interconnected with a trusted port because each interconnected switch has its own DHCP snooping binding table.

This example shows how to display the DHCP snooping binding information for a switch:

Table 56-2 describes the fields in the show ip dhcp snooping binding command output.

Displaying the DHCP Snooping Configuration

This example shows how to display the DHCP snooping configuration for a switch:

Configuring IP Source Guard on Private VLANs

For IP source guard to be effective on PVLAN ports, you must enable DHCP snooping on primary VLANs. IP source guard on a primary VLAN is automatically propagated to a secondary VLAN. You can configure static IP source binding on a secondary VLAN, but it does not work. When manually configuring a static IP source binding on a secondary VLAN, you receive the following message:

Note IP Source Guard is supported on private VLAN host ports only.

About IP Source Guard for Static Hosts

The prior feature, IPSG, uses the entries created by the DHCP snooping feature to validate the hosts connected to a switch. Any traffic received from a host without a valid DHCP binding entry is dropped. A DHCP environment is a prerequisite for IPSG to work. The IPSG for static hosts feature removes IPSG’ dependency on DHCP. The switch creates static entries based on ARP requests or other IP packets and uses them to maintain the list of valid hosts for a given port. In addition, you can specify the number of hosts that would be allowed to send traffic to a given port. it is equivalent to port security at Layer 3.

Note Some IP hosts with multiple network interfaces may inject some invalid packets into a network interface. Those invalid packets contain the IP-to-MAC address for another network interface of that host as the source address. It may cause IPSG for static hosts in the switch, which connects to the host, to learn the invalid IP-to-MAC address bindings and reject the valid bindings. You should consult the vendor of the corresponding operating system and the network device of that host to prevent it from injecting invalid packets.

IPSG for static hosts initially learns IP-to-MAC bindings dynamically through an ACL-based snooping method. IP-to-MAC bindings are learned from static hosts by using ARP and IP packets and are stored using the device tracking database. Once the number of IP addresses that have been dynamically learned or statically configured on a given port reaches a maximum limit, any packet with a new IP address is dropped in hardware. To handle hosts that have moved or gone away for any reason, the IPSG for static hosts feature uses the IP device tracking functionality to age out dynamically learned IP address bindings. This feature can be used in conjunction with DHCP snooping. Multiple bindings will be established on a port that is connected to both DHCP and static hosts (that is, bindings will be stored in both the device tracking database as well as the DHCP snooping binding database).

Configuring IPSG for Static Hosts on a Layer 2 Access Port

You can configure IPSG for static hosts on a Layer 2 access port.

To enable IPSG for static hosts with IP filters on a Layer 2 access port, perform this task:

To stop IPSG with static hosts on an interface, use the following commands in interface configuration submode:

To enable IPSG with static hosts on a port, enter the following commands:

Caution If you only configure the ip verify source tracking [port-security] interface configuration command on a port without enabling IP device tracking globally or setting an IP device tracking maximum on that interface, IPSG with static hosts will reject all the IP traffic from that interface.

This issue also applies to IPSG with static hosts on a PVLAN host port.

---

This example shows how to enable IPSG for static hosts with IP filters on a Layer 2 access port and to verify the three valid IP bindings on the interface Fa4/3:

The following example shows how to enable IPSG for static hosts with IP MAC filters on a Layer 2 access port, to verify the five valid IP-MAC bindings on the interface Fa4/3, and to verify that the number of bindings on this interface has reached the maximum limit:

The following example displays all IP-to-MAC binding entries for all interfaces. The CLI displays all active as well as inactive entries. When a host is learned on a interface, the new entry is marked as active. When the same host is disconnected from the current interface and connected to a different interface, a new IP-to-MAC binding entry is displayed as active as soon as the host is detected. The old entry for this host on the previous interface is now marked as inactive.

The following example displays all active IP-to-MAC binding entries for all interfaces:

The following example displays all inactive IP-to-MAC binding entries for all interfaces. The host was first learned on GigabitEthernet 3/1 then moved to GigabitEthernet 4/1. The IP-to-MAC binding entries learned on GigabitEthernet 3/1 are marked as inactive.

The following example display the count of all IP device tracking host entries for all interfaces:

Configuring IPSG for Static Hosts on a PVLAN Host Port

You can configure IPSG for static hosts on a PVLAN host port.

To enable IPSG for static hosts with IP filters on a PVLAN host port, perform this task:

This example shows how to enable IPSG for static hosts with IP filters on a PVLAN host port:

The output shows the five valid IP-to-MAC bindings that have been learned on the interface Fa4/3. For the PVLAN, the bindings are associated with primary VLAN ID. In this example, the primary VLAN ID, 200, is shown in the table.

The output shows that the five valid IP-to-MAC bindings are on both the primary and secondary VLAN.