Network Analyst

Cisco MARS Configuration

2010-03-12T03:02:00.001-08:00

For Cisco IPS 5.x, 6.x, and 7.x devices, MARS pulls the logs using SDEE over SSL. Therefore, MARS must have HTTPS access to the sensor. In order to prepare the sensor, you must enable the HTTP server on the sensor, enable TLS to allow HTTPS access, and make sure that the IP address of MARS is defined as an allowed host, one that can access the sensor and pull events. If the sensors have been configured to allow access from limited hosts or subnets on the network, you can use the access-list ip_address/netmask command in order to enable this access.
Components Used
The information in this document is based on these software and hardware versions:

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Related Products
This configuration can also be used with these sensors:

Configure
In this section, you are presented with the information on how to add and configure a Cisco Secure Intrusion Prevention System (IPS) sensor to a Cisco Security Monitoring, Analysis, and Response System (CS-MARS) device.
Add and Configure a Cisco IPS 6.x or 7.x Device in MARS
When you define a Cisco IPS 6.x or 7.x device in MARS, you can discover any virtual sensors configured on the device. When you discover these virtual sensors, this allows MARS to separate the reported events by virtual sensor. It also allows you to tune the list of monitored networks to each virtual sensor, which improves the accuracy of the desired reporting.
Complete these steps in order to add and configure a Cisco IPS 6.x or 7.x device in MARS:

Verify that MARS Pulls Events from a Cisco IPS Device
It is common to create benign events on the network in order to verify the data flow. Complete these steps in order to verify the data flow between a Cisco IPS device and MARS:

Note: If the Test Connectivity operation does not fail during the configuration of a Cisco IPS device in the MARS web interface, then communications are enabled. This task allows you to further verify the alerts are generated and pulled correctly.

Configuring DHCP

2010-03-12T02:53:00.001-08:00

DHCP supports three mechanisms for IP address allocation:

•Automatic allocation—DHCP assigns a permanent IP address to a client.

•Dynamic allocation—DHCP assigns an IP address to a client for a limited period of time (or until the client explicitly relinquishes the address).

•Manual allocation—The network administrator assigns an IP address to a client and DHCP is used simply to convey the assigned address to the client.

The format of DHCP messages is based on the format of Bootstrap Protocol (BOOTP) messages, which ensures support for BOOTP relay agent functionality and interoperability between BOOTP clients and DHCP Servers. BOOTP relay agents eliminate the need for deploying a DHCP Server on each physical network segment. BOOTP is explained in RFC 951, Bootstrap Protocol (BOOTP), and RFC 1542, Clarifications and Extensions for the Bootstrap Protocol.

To identify the hardware platform or software image information associated with a feature, use the Feature Navigator on Cisco.com to search for information about the feature or refer to the software release notes for a specific release. For more information, see the "Identifying Supported Platforms" section in the "Using Cisco IOS Software" chapter in this book.

DHCP Server Overview

The Cisco IOS DHCP Server feature is a full DHCP Server implementation that assigns and manages IP addresses from specified address pools within the router to DHCP clients. If the Cisco IOS DHCP Server cannot satisfy a DHCP request from its own database, it can forward the request to one or more secondary DHCP Servers defined by the network administrator.

the basic steps that occur when a DHCP client requests an IP address from a DHCP Server. The client, Host A, sends a DHCPDISCOVER broadcast message to locate a Cisco IOS DHCP Server. A DHCP Server offers configuration parameters (such as an IP address, a MAC address, a domain name, and a lease for the IP address) to the client in a DHCPOFFER unicast message.

Note A DHCP client may receive offers from multiple DHCP Servers and can accept any one of the offers; however, the client usually accepts the first offer it receives. Additionally, the offer from the DHCP Server is not a guarantee that the IP address will be allocated to the client; however, the server usually reserves the address until the client has had a chance to formally request the address.

The client returns a formal request for the offered IP address to the DHCP Server in a DHCPREQUEST broadcast message. The DHCP Server confirms that the IP address has been allocated to the client by returning a DHCPACK unicast message to the client.

Note The formal request for the offered IP address (the DHCPREQUEST message) that is sent by the client is broadcast so that all other DHCP Servers that received the DHCPDISCOVER broadcast message from the client can reclaim the IP addresses that they offered to the client.

If the configuration parameters sent to the client in the DHCPOFFER unicast message by the DHCP Server are invalid (a misconfiguration error exists), the client returns a DHCPDECLINE broadcast message to the DHCP Server.

The DHCP Server will send to the client a DHCPNAK denial broadcast message, which means the offered configuration parameters have not been assigned, if an error has occurred during the negotiation of the parameters or the client has been slow in responding to the DHCPOFFER message (the DHCP Server assigned the parameters to another client) of the DHCP Server.

DHCP defines a process by which the DHCP Server knows the IP subnet in which the DHCP client resides, and it can assign an IP address from a pool of valid IP addresses in that subnet.

The DHCP Server identifies which DHCP address pool to use to service a client request as follows:

•If the client is not directly connected (the gi-addr field of the DHCPDISCOVER broadcast message is non-zero), the DHCP Server matches the DHCPDISCOVER with a DHCP pool that has the subnet that contains the IP address in the gi-addr field.

•If the client is directly connected (the gi-addr field is zero), the DHCP Server matches the DHCPDISCOVER with DHCP pool(s) that contain the subnet(s) configured on the receiving interface. If the interface has secondary IP addresses, the subnets associated with the secondary IP addresses are examined for possible allocation only after the subnet associated with the primary IP address (on the interface) is exhausted.

The Cisco IOS DHCP Server feature offers the following benefits:

•Reduced Internet access costs

Using automatic IP address assignment at each remote site substantially reduces Internet access costs. Static IP addresses are considerably more expensive to purchase than are automatically allocated IP addresses.

•Reduced client configuration tasks and costs

Because DHCP is easy to configure, it minimizes operational overhead and costs associated with device configuration tasks and eases deployment by nontechnical users.

•Centralized management

Because the DHCP Server maintains configurations for several subnets, an administrator only needs to update a single, central server when configuration parameters change.

Before you configure the Cisco IOS DHCP Server feature, complete the following tasks:

•Identify an external File Transport Protocol (FTP), Trivial File Transfer Protocol (TFTP), or remote copy protocol (rcp) server that you will use to store the DHCP bindings database.

•Identify the IP addresses that you will enable the DHCP Server to assign, and the IP addresses that you will exclude.

•Identify DHCP options for devices where necessary, including the following:

–Default boot image name

–Default routers

–Domain Name System (DNS) servers

–NetBIOS name server

•Decide on a NetBIOS node type (b, p, m, or h).

•Decide on a DNS domain name.

DHCP Client Overview

The Cisco IOS DHCP client now enables you to obtain an IP address from a DHCP Server dynamically using the DHCP protocol as specified in RFC 2131. In Cisco IOS Release 12.2, only Ethernet interfaces are supported; work is in progress to support all interface types. The Cisco IOS DHCP client offers the following benefits:

•Reduces time to configure and deploy

•Reduces the number of configuration errors

•Enables customers to centrally control the IP address assigned to a Cisco IOS router

DHCP Relay Agent Overview

A DHCP relay agent is any host that forwards DHCP packets between clients and servers. Relay agents are used to forward requests and replies between clients and servers when they are not on the same physical subnet. Relay agent forwarding is distinct from the normal forwarding of an IP router, where IP datagrams are switched between networks somewhat transparently. Relay agents receive DHCP messages and then generate a new DHCP message to send out on another interface.

The Cisco IOS DHCP relay agent supports the use of unnumbered interfaces. The DHCP relay agent automatically adds a static host route specifying the unnumbered interface as the outbound interface.

DHCP Configuration Task List

The DHCP Server database is organized as a tree. The root of the tree is the address pool for natural networks, branches are subnetwork address pools, and leaves are manual bindings to clients. Subnetworks inherit network parameters and clients inherit subnetwork parameters. Therefore, common parameters, for example the domain name, should be configured at the highest (network or subnetwork) level of the tree.

Note Inherited parameters can be overridden. For example, if a parameter is defined in both the natural network and a subnetwork, the definition of the subnetwork is used.

Address leases are not inherited. If a lease is not specified for an IP address, by default, the DHCP Server assigns a one-day lease for the address.

To configure the Cisco IOS DHCP Server feature, perform the tasks described in the following sections. First configure a database agent or disable conflict logging, then specify IP addresses that the DHCP Server should not assign (excluded addresses) and should assign (a pool of available IP addresses) to requesting clients. The tasks in the first three sections are required. The tasks in the remaining sections are optional.

•Enabling the Cisco IOS DHCP Server and Relay Agent Features (Optional)

•Configuring a DHCP Database Agent or Disabling DHCP Conflict Logging (Required)

•Excluding IP Addresses (Required)

•Configuring a DHCP Address Pool (Required)

•Configuring Manual Bindings (Optional)

•Configuring a DHCP Server Boot File (Optional)

•Configuring the Number of Ping Packets (Optional)

•Configuring the Timeout Value for Ping Packets (Optional)

•Enabling the Cisco IOS DHCP Client on Ethernet Interfaces (Optional)

•Configuring DHCP Server Options Import and Auto configuration (Optional)

•Configuring the Relay Agent Information Option in BOOTREPLY Messages (Optional)

•Configuring a Relay Agent Information Reforwarding Policy (Optional)

•Enabling the DHCP Smart-Relay Feature (Optional)

Enabling the Cisco IOS DHCP Server and Relay Agent Features

By default, the Cisco IOS DHCP server and relay agent features are enabled on your router. To re-enable these features if they are disabled, use the following command in global configuration mode:

Command	Purpose
Router(config)# service dhcp	Enables the Cisco IOS DHCP server and relay features on your router. Use the no form of this command to disable the Cisco IOS DHCP server and relay features.

Configuring a DHCP Database Agent or Disabling DHCP Conflict Logging

A DHCP database agent is any host—for example, an FTP, TFTP, or rcp server—that stores the DHCP bindings database. You can configure multiple DHCP database agents and you can configure the interval between database updates and transfers for each agent. To configure a database agent and database agent parameters, use the following command in global configuration mode:

Command	Purpose
Router(config)# ip dhcp database url [timeout seconds \| write-delay seconds]	Configures the database agent and the interval between database updates and database transfers.

If you choose not to configure a DHCP database agent, disable the recording of DHCP address conflicts on the DHCP Server. To disable DHCP address conflict logging, use the following command in global configuration mode:

Command	Purpose
Router(config)# no ip dhcp conflict logging	Disables DHCP address conflict logging.

Excluding IP Addresses

The DHCP Server assumes that all IP addresses in a DHCP address pool subnet are available for assigning to DHCP clients. You must specify the IP address that the DHCP Server should not assign to clients. To do so, use the following command in global configuration mode:

Command	Purpose
Router(config)# ip dhcp excluded-address low-address [high-address]	Specifies the IP addresses that the DHCP Server should not assign to DHCP clients.

Configuring a DHCP Address Pool

You can configure a DHCP address pool with a name that is a symbolic string (such as "engineering") or an integer (such as 0). Configuring a DHCP address pool also places you in DHCP pool configuration mode—identified by the (dhcp-config)# prompt—from which you can configure pool parameters (for example, the IP subnet number and default router list). To configure a DHCP address pool, complete the required tasks in the following sections.

Configuring the DHCP Address Pool Name and Entering DHCP Pool Configuration Mode

To configure the DHCP address pool name and enter DHCP pool configuration mode, use the following command in global configuration mode:

Command	Purpose
Router(config)# ip dhcp pool name	Creates a name for the DHCP Server address pool and places you in DHCP pool configuration mode (identified by the dhcp-config# prompt).

Configuring the DHCP Address Pool Subnet and Mask

To configure a subnet and mask for the newly created DHCP address pool, which contains the range of available IP addresses that the DHCP Server may assign to clients, use the following command in DHCP pool configuration mode:

Command	Purpose
Router(dhcp-config)# network network-number [mask \| /prefix-length]	Specifies the subnet network number and mask of the DHCP address pool. The prefix length specifies the number of bits that comprise the address prefix. The prefix is an alternative way of specifying the network mask of the client. The prefix length must be preceded by a forward slash (/).

Note You can not configure manual bindings within the same pool that is configured with the network command. To configure manual bindings, see the "Configuring Manual Bindings" section.

Configuring the Domain Name for the Client

The domain name for a DHCP client places the client in the general grouping of networks that make up the domain. To configure a domain name string for the client, use the following command in DHCP pool configuration mode:

Command	Purpose
Router(dhcp-config)# domain-name domain	Specifies the domain name for the client.

Configuring the IP Domain Name System Servers for the Client

DHCP clients query DNS IP servers when they need to correlate host names to IP addresses. To configure the DNS IP servers that are available to a DHCP client, use the following command in DHCP pool configuration mode:

Command	Purpose
Router(dhcp-config)# dns-server address [address2 ... address8]	Specifies the IP address of a DNS server that is available to a DHCP client. One IP address is required; however, you can specify up to eight IP addresses in one command line.

Configuring the NetBIOS Windows Internet Naming Service Servers for the Client

Windows Internet Naming Service (WINS) is a name resolution service that Microsoft DHCP clients use to correlate host names to IP addresses within a general grouping of networks. To configure the NetBIOS WINS servers that are available to a Microsoft DHCP client, use the following command in DHCP pool configuration mode:

Command	Purpose
Router(dhcp-config)# netbios-name-server address [address2 ... address8]	Specifies the NetBIOS WINS server that is available to a Microsoft DHCP client. One address is required; however, you can specify up to eight addresses in one command line.

Configuring the NetBIOS Node Type for the Client

The NetBIOS node type for Microsoft DHCP clients can be one of four settings: broadcast, peer-to-peer, mixed, or hybrid. To configure the NetBIOS node type for a Microsoft DHCP, use the following command in DHCP pool configuration mode:

Command	Purpose
Router(dhcp-config)# netbios-node-type type	Specifies the NetBIOS node type for a Microsoft DHCP client.

Configuring the Default Router for the Client

After a DHCP client has booted, the client begins sending packets to its default router. The IP address of the default router should be on the same subnet as the client. To specify a default router for a DHCP client, use the following command in DHCP pool configuration mode:

Command	Purpose
Router(dhcp-config)# default-router address [address2 ... address8]	Specifies the IP address of the default router for a DHCP client. One IP address is required; however, you can specify up to eight addresses in one command line.

Configuring the Address Lease Time

By default, each IP address assigned by a DHCP Server comes with a one-day lease, which is the amount of time that the address is valid. To change the lease value for an IP address, use the following command in DHCP pool configuration mode:

Command	Purpose
Router(dhcp-config)# lease {days [hours][minutes] \| infinite}	Specifies the duration of the lease. The default is a one-day lease. •Use the show ip dhcp binding to display the lease expiration time and date of the IP address of the host.

Configuring Manual Bindings

An address binding is a mapping between the IP address and MAC address of a client. The IP address of a client can be assigned manually by an administrator or assigned automatically from a pool by a DHCP server.

Manual bindings are IP addresses that have been manually mapped to the MAC addresses of hosts that are found in the DHCP database. Manual bindings are stored in NVRAM on the DHCP server. Manual bindings are just special address pools. There is no limit on the number of manual bindings, but you can only configure one manual binding per host pool.

Automatic bindings are IP addresses that have been automatically mapped to the MAC addresses of hosts that are found in the DHCP database. Automatic bindings are stored on a remote host called a database agent. The bindings are saved as text records for easy maintenance.

All DHCP clients send a client identifier (DHCP option 61) in the DHCP packet. To configure manual bindings, you must enter the client-identifier DHCP pool configuration command with the appropriate hexadecimal values identifying the DHCP client.

To configure a manual binding, first create a host pool, then specify the IP address of the client and client identifier or hardware address.

To configure manual bindings, use the following commands beginning in global configuration mode:

	Command	Purpose
Step 1	Router(config)# ip dhcp pool name	Creates a name for the a DHCP Server address pool and places you in DHCP pool configuration mode—identified by the (dhcp-config)# prompt.
Step 2	Router(dhcp-config)# host address [mask \| /prefix-length]	Specifies the IP address and subnet mask of the client. The prefix length specifies the number of bits that comprise the address prefix. The prefix is an alternative way of specifying the network mask of the client. The prefix length must be preceded by a forward slash (/).
Step 3	Router(dhcp-config)# client-identifier unique-identifier	Specifies the unique identifier for DHCP clients. This command is used for DHCP requests. •DHCP clients require client identifiers. The unique identification of the client is specified in dotted hexadecimal notation, for example, 01b7.0813.8811.66, where 01 represents the Ethernet media type.
Step 4	Router(dhcp-config)# hardware-address hardware-address type	(Optional) Specifies a hardware address for the client. This command is used for BOOTP requests. The type value: •Indicates the protocol of the hardware platform. Strings and values are acceptable. The string options are: –Ethernet –ieee802 •The value options are: –1 10Mb Ethernet –6 IEEE 802 If no type is specified, the default protocol is Ethernet.
Step 5	Router(dhcp-config)# client-name name	(Optional) Specifies the name of the client using any standard ASCII character. The client name should not include the domain name. For example, the name mars should not be specified as mars.cisco.com.

Troubleshooting Tips

You can determine the client identifier by using the debug ip dhcp server packet command. In the following example, the client is identified by the value 0b07.1134.a029.

Router# debug ip dhcp server packet

DHCPD:DHCPDISCOVER received from client 0b07.1134.a029 through relay 10.1.0.253.

DHCPD: assigned IP address 10.1.0.3 to client 0b07.1134.a029.

Configuring a DHCP Server Boot File

The boot file is used to store the boot image for the client. The boot image is generally the operating system the client uses to load. To specify a boot file for the DHCP client, use the following command in DHCP pool configuration mode:

Command	Purpose
Router(dhcp-config)# bootfile filename	Specifies the name of the file that is used as a boot image.

Configuring the Number of Ping Packets

By default, the DHCP Server pings a pool address twice before assigning a particular address to a requesting client. If the ping is unanswered, the DHCP Server assumes (with a high probability) that the address is not in use and assigns the address to the requesting client. To change the number of ping packets the DHCP Server should send to the pool address before assigning the address, use the following command in global configuration mode:

Command	Purpose
Router(config)# ip dhcp ping packets number	Specifies the number of ping packets the DHCP Server sends to a pool address before assigning the address to a requesting client. The default is two packets. Setting the count argument to a value of 0 turns off DHCP Server ping operation completely.

Configuring the Timeout Value for Ping Packets

By default, the DHCP Server waits 500 milliseconds before timing out a ping packet. To change the amount of time the server waits, use the following command in global configuration mode:

Command	Purpose
Router(config)# ip dhcp ping timeout milliseconds	Specifies the amount of time the DHCP Server must wait before timing out a ping packet. The default is 500 milliseconds.

Enabling the Cisco IOS DHCP Client on Ethernet Interfaces

To acquire an IP address via DHCP on an Ethernet interface, use the following command in interface configuration mode:

Command	Purpose
Router(config-if)# ip address dhcp [client-id interface name] [hostname host-name]	Specifies that the Ethernet interface acquires an IP address through DHCP.

Configuring DHCP Server Options Import and Autoconfiguration

The Cisco IOS DHCP server can dynamically configure options such as the DNS and WINS addresses to respond to DHCP requests from local clients behind the customer premises equipment (CPE).

Previously, network administrators needed to manually configure the Cisco IOS DHCP server on each device enabled with this feature. The Cisco IOS DHCP server was enhanced to allow configuration information to be updated automatically. Network administrators can configure one or more centralized DHCP servers to update specific DHCP options within the DHCP pools. The remote servers can request or "import" these option parameters from the centralized servers. See the section "DHCP Server Options Import and Auto configuration Example" later in this chapter for a configuration example.

To configure the central router to update specific DHCP options within the DHCP pools, use the following commands beginning in global configuration mode:

	Command	Purpose
Step 1	Router(config)# ip dhcp pool name	Creates a name for the a DHCP Server address pool and places you in DHCP pool configuration mode—identified by the (dhcp-config)# prompt.
Step 2	Router(dhcp-config)# network network-number [mask \| /prefix-length]	Specifies the subnet network number and mask of the DHCP address pool. The prefix length specifies the number of bits that comprise the address prefix. The prefix is an alternative way of specifying the network mask of the client. The prefix length must be preceded by a forward slash (/).
Step 3	Router(dhcp-config)# dns-server address [address2 ... address8]	Specifies the IP address of a DNS server that is available to a DHCP client. One IP address is required; however, you can specify up to eight IP addresses in one command line.

To configure the remote router to import DHCP options into the DHCP server database, use the following commands beginning in global configuration mode:

	Command	Purpose
Step 1	Router(config)# ip dhcp pool name	Creates a name for the a DHCP Server address pool and places you in DHCP pool configuration mode—identified by the (dhcp-config)# prompt.
Step 2	Router(dhcp-config)# network network-number [mask \| /prefix-length]	Specifies the subnet network number and mask of the DHCP address pool. The prefix length specifies the number of bits that comprise the address prefix. The prefix is an alternative way of specifying the network mask of the client. The prefix length must be preceded by a forward slash (/).
Step 3	Router(dhcp-config)# import all	Import DHCP option parameters into the DHCP server database.
Step 4	Router(dhcp-config)# exit	Exits DHCP pool configuration mode.
Step 5	Router(config)# interface type number	Configures an interface and enters interface configuration mode.
Step 6	Router(config-if)# ip address dhcp [client-id interface name] [hostname host-name]	Specifies that the interface acquires an IP address through DHCP.

Configuring the Relay Agent Information Option in BOOTREPLY Messages

To configure the DHCP Server to validate the relay agent information option in forwarded BOOTREPLY messages, use the following command in global configuration mode:

Command	Purpose
Router(config)# ip dhcp relay information check	Configures the DHCP Server to check that the relay agent information option in forwarded BOOTREPLY messages is valid.

Configuring a Relay Agent Information Reforwarding Policy

To configure a relay agent information reforwarding policy on the DHCP Server (what the DHCP Server should do if a forwarded message already contains relay information), use the following command in global configuration mode:

Command	Purpose
Router(config)# ip dhcp relay information policy {drop \| keep \|replace}	Determines the relay information reforwarding policy in a cable modem termination system.

Enabling the DHCP Smart-Relay Feature

By default, the DHCP smart-relay feature is disabled. To enable the smart-relay functionality, use the following command in global configuration mode:

Command	Purpose
Router(config)# ip dhcp smart-relay	Allows the DHCP relay agent to switch the gateway address (giaddr field of a DHCP packet) to secondary addresses when there is no DHCPOFFER message from a DHCP Server.

Monitoring and Maintaining the DHCP Server

To clear DHCP Server variables, use the following commands in privileged EXEC mode, as needed:

Command	Purpose
Router# clear ip dhcp binding {address \| *}	Deletes an automatic address binding from the DHCP database. Specifying the address argument clears the automatic binding for a specific (client) IP address, whereas specifying an asterisk (*) clears all automatic bindings.
Router# clear ip dhcp conflict {address \| *}	Clears an address conflict from the DHCP database. Specifying the address argument clears the conflict for a specific IP address, whereas specifying an asterisk (*) clears conflicts for all addresses.
Router# clear ip dhcp server statistics	Resets all DHCP Server counters to 0.
Router# clear ip route [vrf vrf-name] dhcp [ip-address]	Removes routes from the routing table added by the Cisco IOS DHCP Server and Relay Agent for the DHCP clients on unnumbered interfaces.

To enable DHCP Server debugging, use the following command in privileged EXEC mode:

Command	Purpose
Router# debug ip dhcp server {events \| packets \| linkage}	Enables debugging on the DHCP Server.

To display DHCP Server information, use the following commands in EXEC mode, as needed:

Command	Purpose
Router# show ip dhcp binding [address]	Displays a list of all bindings created on a specific DHCP Server. •Use the show ip dhcp binding to display the lease expiration time and date of the IP address of the host and the number. You can also use this command to display the IP addresses that have already been assigned.
Router# show ip dhcp conflict [address]	Displays a list of all address conflicts recorded by a specific DHCP Server.
Router# show ip dhcp database [url]	Displays recent activity on the DHCP database. Note Use this command in privileged EXEC mode.
Router# show ip dhcp server statistics	Displays count information about server statistics and messages sent and received.
Router# show ip dhcp import	Displays the option parameters that were imported into the DHCP Server database. Imported option parameters are not part of the router configuration and are not saved in NVRAM.
Router# show ip route [vrf vrf-name] dhcp [ip-address]	Displays the routes added to the routing table by the Cisco IOS DHCP Server and Relay Agent.

Configuration Examples

This section provides the following configuration examples:

•DHCP Database Agent Configuration Example

•DHCP Address Pool Configuration Example

•Manual Bindings Configuration Example

•Cisco IOS DHCP Client Example

•DHCP Server Options Import and Auto configuration Example

DHCP Database Agent Configuration Example

The following example stores bindings on host 172.16.4.253. The file transfer protocol is FTP. The server should wait 2 minutes (120 seconds) before writing database changes.

ip dhcp database ftp://user:password@172.16.4.253/router-dhcp write-delay 120

DHCP Address Pool Configuration Example

In the following example, three DHCP address pools are created: one in network 172.16.0.0, one in subnetwork 172.16.1.0, and one in subnetwork 172.16.2.0. Attributes from network 172.16.0.0—such as the domain name, DNS server, NetBIOS name server, and NetBIOS node type—are inherited in subnetworks 172.16.1.0 and 172.16.2.0. In each pool, clients are granted 30-day leases and all addresses in each subnetwork, except the excluded addresses, are available to the DHCP Server for assigning to clients. Table 5 lists the IP addresses for the devices in three DHCP address pools.

Table 5 DHCP Address Pool Configuration Example
Pool 0 (Network 172.16.0.0)		Pool 1 (Subnetwork 172.16.1.0)		Pool 2 (Subnetwork 172.16.2.0)
Device	IP Address	Device	IP Address	Device	IP Address
Default routers	-	Default routers	172.16.1.100 172.16.1.101	Default routers	172.16.2.100 172.16.2.101
DNS Server	172.16.1.102 172.16.2.102	—	—	—	—
NetBIOS name server	172.16.1.103 172.16.2.103	—	—	—	—
NetBIOS node type	h-node	—	—	—	—

ip dhcp database ftp://user:password@172.16.4.253/router-dhcp write-delay 120

ip dhcp excluded-address 172.16.1.100 172.16.1.103

ip dhcp excluded-address 172.16.2.100 172.16.2.103

ip dhcp pool 0

network 172.16.0.0 /16

domain-name cisco.com

dns-server 172.16.1.102 172.16.2.102

netbios-name-server 172.16.1.103 172.16.2.103

netbios-node-type h-node

ip dhcp pool 1

network 172.16.1.0 /24

Default-router 172.16.1.100 172.16.1.101

lease 30

ip dhcp pool 2

network 172.16.2.0 /24

default-router 172.16.2.100 172.16.2.101

lease 30

Manual Bindings Configuration Example

The following example creates a manual binding for a client named Mars.cisco.com. The MAC address of the client is 02c7.f800.0422 and the IP address of the client is 172.16.2.254.

ip dhcp pool Mars

host 172.16.2.254

hardware-address 02c7.f800.0422 ieee802

client-name Mars

Because attributes are inherited, the previous configuration is equivalent to the following:

ip dhcp pool Mars

host 172.16.2.254 mask 255.255.255.0

hardware-address 02c7.f800.0422 ieee802

client-name Mars

default-router 172.16.2.100 172.16.2.101

domain-name cisco.com

dns-server 172.16.1.102 172.16.2.102

netbios-name-server 172.16.1.103 172.16.2.103

Netbios-node-type h-node

Cisco IOS DHCP Client Example

Figure 15 shows a simple network diagram of a DHCP client on an Ethernet LAN.

Figure 15 Topology Showing DHCP Client with Ethernet Interface

On the DHCP Server, the configuration is as follows:

ip dhcp pool 1

network 10.1.1.0 255.255.255.0

lease 1 6

On the DHCP client, the configuration is as follows on interface E2:

interface Ethernet2

ip address dhcp

This configuration allows the DHCP client to acquire an IP address from the DHCP Server through an Ethernet interface.

DHCP Server Options Import and Auto configuration Example

The following example shows a remote and central server configured to support DHCP options import and auto configuration. The central server is configured to automatically update DHCP options, such as DNS and WINs addresses, within the DHCP pools. In response to a DHCP request from a local client behind CPE equipment, the remote server can request or "import" these option parameters from the centralized server. See Figure 16 for a diagram of the network topology.

Figure 16 DHCP Example Network Topology

Central Router

!do not assign this range to DHCP clients

ip dhcp-excluded address 10.0.0.1 10.0.0.5

ip dhcp pool central

! Specifies network number and mask for DHCP clients

network 10.0.0.0 255.255.255.0

! Specifes the domain name for the client

domain-name central

! Specifies DNS server that will respond to DHCP clients when they need to correlate host

! name to ip address

dns-server 10.0.0.2

! Specifies the NETBIOS WINS server

netbios-name-server 10.0.0.2

interface FastEthernet0/0

ip address 10.0.0.1 255.255.255.0

! Imports DHCP options parameters into DHCP server database

Import all

Network 20.0.0.0 255.255.255.0

Interface FastEthernet0/0

ip address dhcp

Duplex auto

Speed auto

Cisco EtherChannel

2010-03-10T22:03:00.001-08:00

Introduction

Etherchannel (also referred to as "Fast Etherchannel" or simply "trunking") is a scheme to trunk together multiple 10/100 Mb/s Ethernet links to form a single, fat pipe in order to:

load-balance traffic over the physical links; and
recover from link failures.

Etherchannel was originally proposed by Sun and picked up by Cisco. Cisco and Sun (and host of switch vendors) currently support Etherchannel in their products. Etherchannel is typically used in LAN backbones for switch-switch, router-switch or server-switch/router connectivity.
In what follows, the terms "Etherchannel" and "trunking" are used interchangeably.
Why Etherchannel?

Etherchannel provides a fat pipe by linking together multiple 10/100 BaseT links.
Etherchannel provides load-balancing of traffic over the physical links.
Etherchannel provides recovery from link failures.
Etherchannel uses 10/100BaseT technology as its core. This leverages investments in existing network infrastructure (UTP wiring, 10/100 switches, etc.). The only thing required is a software upgrade on switches, routers and servers.
Even though Gigabit Ethernet products are shipping, products that enable Gigabit Ethernet over copper (4 pairs of UTP cabling) are not going to be shipped for a several years. Etherchannel gives customers reluctant to switch to fiber in the LAN backbones an alternative to Gigabit Ethernet.

What is Etherchannel?

As mentioned above, the basic idea in Etherchannel is really simple. The idea is to take some (small number) of Ethernet links and trunk them together. Most switches/routers provide trunking of 2 to 4 links. This trunk looks like a single network pipe to the upper layers (and is administered as a single network pipe). Load balancing is achieved by distributing traffic out onto the physical links. The distribution of outgoing traffic over the links forming the trunk is described below. Furthermore, a trunk with N links can recover from failure of any (N - 1) links by distributing traffic over the remaining links.
Basically, there are two parts to Etherchannel. The first deals with how the links are configured to form a trunk. The second deals with how traffic flowing out on the trunk is load-balanced over the physical links.

Let's proceed further and we will see how to configure a Layer 3 Ether channel using the PAgp Protocol (Port Aggregation Protocol) in Cisco Catalyst Switches.

Here is the scenario which we will follow

From the above diagram we have two Cisco 3560 Catalyst Switches named ITKESW01 and ITKESW02.

We will configure a Layer 3 Etherchannel between the Cisco 3560 Catalyst Switches ITKESW01 and ITKESW02. The Giga Ethernet ports 0/45, 0/46/,0/47 & 0/48 on a Cisco 3560 Catalyst Switches ITKESW01 are connected to Giga Ethernet ports 0/1,0/2,0/3 and 0/in Cisco 3560 Catalyst Switch ITKESW02.

The configuration is as follows

Configuration in the Cisco 3560 Catalyst Switch ITKESW01

ITKESW01#config t

ITKESW01(config)# interface port-channel 1

ITKESW01(config-if)# no switchport

ITKESW01(config-if)# no shutdown

ITKESW01(config-if)# ip address 192.168.1.1 255.255.255.0

ITKESW01(config-if)# end

ITKESW01#config t

ITKESW01(config)# interface range gigabitEthernet 0/45 – 48

ITKESW01(config-if-range)# no switchport

ITKESW01(config-if-range)# no ip address

ITKESW01(config-if-range)# channel-group 1 mode desirable

ITKESW01(config-if-range)#end

Note: This example shows how to configure Gigabit Ethernet ports 0/45 – 0/48   into port channel 1 with PAgP mode desirable

Note: The "no switchport" command is required to change interface from layer2 to layer3 mode.

Configuration in the Cisco 3560 Catalyst Switch ITKESW02

ITKESW02#config t

ITKESW02(config)# interface port-channel 1

ITKESW02(config-if)# no switchport

ITKESW02(config-if)# no shutdown

ITKESW02(config-if)# ip address 192.168.1.2 255.255.255.0

ITKESW02(config-if)# end

ITKESW02#config t

ITKESW02(config)# interface range gigabitEthernet 0/1 – 4

ITKESW02(config-if-range)# no switchport

ITKESW02(config-if-range)# no ip address

ITKESW02(config-if-range)# channel-group 1 mode auto

ITKESW02(config-if-range)#end

Note: This example shows how to configure Gigabit Ethernet ports 0/1 – 0/4   into port channel 1 with PAgP mode auto

Note: The "no switchport" command is required to change interface from layer2 to layer3 mode.

Do use "show etherchannel" command to display port-channel information after configuration and remember to save the configuration.

Cisco Etherchannel Overview and how it can be configured in Cisco Catalyst Switches – Series 7

Now it's the time to proceed further and we will see how to configure a Layer 2 Etherchannel using the LACP Protocol (Link Aggregation Protocol) in Cisco Catalyst Switches.

Here is the scenario which we will follow

From the above diagram we have two Cisco 3560 Catalyst Switches named ITKESW01 and ITKESW02.

We will configure a Layer 2 Etherchannel between the Cisco 3560 Catalyst Switches ITKESW01 and ITKESW02. The Giga Ethernet ports 0/45, 0/46/,0/47 & 0/48 on a Cisco 3560 Catalyst Switches ITKESW01 are trunk ports and they are connected to Giga Ethernet ports 0/1,0/2,0/3 and 0/4 (also trunk ports in desirable mode) in Cisco 3560 Catalyst Switch ITKESW02.

The configuration is as follows

Configuration in the Cisco 3560 Catalyst Switch ITKESW01

First run the command "Show interfaces trunk

ITKESW01#sho interfaces trunk

Port        Mode             Encapsulation Status       Native vlan

Gi0/45      desirable                n-isl         trunking            1

Gi0/46      desirable               n-isl         trunking            1

Gi0/47      desirable                n-isl         trunking            1

Gi0/48      desirable                n-isl         trunking            1

Port        Vlans allowed on trunk

Gi0/45        1-4094

Gi0/46        1-4094

Gi0/47        1-4094

Gi0/48       1-4094

Port        Vlans allowed and active in management domain

Gi0/45        1

Gi0/46       1

Gi0/47       1

Gi0/48        1

Port        Vlans in spanning tree forwarding state and not pruned

Gi0/45      1

Gi0/46       1

Gi0/47       1

Gi0/48       1

ITKESW01#

Second Step configure the Giga Ethernet ports 0/45 to 0/48 in the Etherchannel

ITKESW01#config t

ITKESW01(config)# interface range gigabitEthernet 0/45 – 48

ITKESW01(config-if-range)# channel-protocol lacp

Note: LACP protocol is configured to be used in this channel

ITKESW01 (config-if-range)# channel-group 1 mode active

Note: A logical port-channel interface is automatically created when ports are grouped into a channel group.

Configure the mode active to be used in LACP

Configuration in the Cisco 3560 Catalyst Switch ITKESW02

ITKESW02#sho interfaces trunk

Port        Mode             Encapsulation Status        Native vlan

Gi0/1      desirable            n-isl         trunking            1

Gi0/2      desirable            n-isl         trunking            1

Gi0/3      desirable            n-isl         trunking            1

Gi0/4      desirable            n-isl         trunking            1

Port        Vlans allowed on trunk

Gi0/1        1-4094

Gi0/2        1-4094

Gi0/3        1-4094

Gi0/4        1-4094

Port        Vlans allowed and active in management domain

Gi0/1        1

Gi0/2        1

Gi0/3        1

Gi0/4        1

Port        Vlans in spanning tree forwarding state and not pruned

Gi0/1       1

Gi0/2       1

Gi0/3       1

Gi0/4       1

ITKESW02#

Second Step configure the Giga Ethernet ports 0/1 to 0/4 in the Etherchannel

ITKESW02#config t

ITKESW02(config)# interface range gigabitEthernet 0/1 – 4

ITKESW02(config-if-range)#channel-protocol lacp

Note: LACP protocol is configured to be used in this channel

ITKESW02 (config-if-range)# channel-group 1 mode active

Note: A logical port-channel interface is automatically created when ports are grouped into a channel group.

Configure the mode active to be used in LACP

Now run show command to display the Etherchannel configurations on the Cisco 3560 Catalyst Switches ITKESW01 and ITKESW02

ITKESW01#sho etherchannel 1 summary

Flags: D - down        P - in port-channel

        I - stand-alone s - suspended

        H - Hot-standby (LACP only)

        R - Layer3      S - Layer2

        u - unsuitable for bundling

        U - in use      f - failed to allocate aggregator

        d - default port

Number of channel-groups in use: 1

Number of aggregators:           1

Group Port-channel Protocol    Ports

——+————-+———–+———————————————–

1      Po1(SD)          LACP      Gi0/45 (P)   Gi0/46 (P)  Gi0/47 (P)  Gi0/48 (P)

ITKESW01#

ITKESW02#sho etherchannel 1 summary

Flags: D - down        P - in port-channel

        I - stand-alone s - suspended

        H - Hot-standby (LACP only)

        R - Layer3      S - Layer2

        u - unsuitable for bundling

        U - in use      f - failed to allocate aggregator

        d - default port

Number of channel-groups in use: 1

Number of aggregators:           1

Group Port-channel Protocol    Ports

——+————-+———–+———————————————–

1      Po1(SD)          LACP     Gi0/1 (P)   Gi0/2 (P)  Gi0/3 (P)  Gi0/4 (P)

ITKESW02#

Cisco Etherchannel Overview and how it can be configured in Cisco Catalyst Switches – Series 6

An Etherchannel in a Cisco IOS can be defined as Layer 2 Etherchannel or a Layer 3 Etherchannel.

For a Layer 2 Etherchannel, physical ports are placed into an Etherchannel group.

For a Layer 3 Etherchannel, layer 3 SVI (Switch Virtual Interface) is created, and then the physical ports are placed into an Etherchannel group which is bound to the L3 SVI.

Now let's see how to configure a Configure a Layer 2 Etherchannel in a Cisco Catalyst Switch using a PAGP (port aggregation protocol) Protocol. In my previous posts I did discussed about the PAGP protocol, it's a Cisco proprietary protocol, can be applied only in Cisco Catalyst Switches.

Here is the scenario which we will follow

From the above diagram we have two Cisco 3560 Catalyst Switches named ITKESW01 and ITKESW02.

We will configure a Layer 2 Etherchannel between the Cisco 3560 Catalyst Switches ITKESW01 and ITKESW02. The Giga Ethernet ports 0/45, 0/46/,0/47 & 0/48 on a Cisco 3560 Catalyst Switches ITKESW01 are trunk ports and they are connected to Giga Ethernet ports 0/1,0/2,0/3 and 0/4 (also trunk ports) in Cisco 3560 Catalyst Switch ITKESW02.

The configuration is as follows

Configuration in the Cisco 3560 Catalyst Switch ITKESW01

First run the command "Show interfaces trunk

ITKESW01#sho interfaces trunk

Port        Mode             Encapsulation Status        Native vlan

Gi0/45      on                        802.1q         trunking            1

Gi0/46      on                        802.1q         trunking            1

Gi0/47      on                        802.1q         trunking            1

Gi0/48      on                        802.1q         trunking            1

Port        Vlans allowed on trunk

Gi0/45       1-4094

Gi0/46        1-4094

Gi0/47        1-4094

Gi0/48        1-4094

Port        Vlans allowed and active in management domain

Gi0/45       1

Gi0/46       1

Gi0/47       1

Gi0/48       1

Port        Vlans in spanning tree forwarding state and not pruned

Gi0/45      1

Gi0/46      1

Gi0/47      1

Gi0/48      1

ITKESW01#

Second Step configure the Giga Ethernet ports 0/45 to 0/48 in the Etherchannel

ITKESW01#config t

ITKESW01(config)# interface range gigabitEthernet 0/45 – 48

ITKESW01(config-if-range)#channel-protocol pagp

Note: PAgP protocol is configured to be used in this channel

ITKESW01 (config-if-range)# channel-group 1 mode desirable

Note: A logical port-channel interface is automatically created when ports are grouped into a channel group.

Configure the mode desirable to be used in PAgP

Configuration in the Cisco 3560 Catalyst Switch ITKESW02

ITKESW02#sho interfaces trunk

Port        Mode             Encapsulation Status        Native vlan

Gi0/1      on                        802.1q         trunking            1

Gi0/2      on                        802.1q         trunking            1

Gi0/3      on                        802.1q         trunking            1

Gi0/4      on                        802.1q         trunking            1

Port        Vlans allowed on trunk

Gi0/1       1-4094

Gi0/2        1-4094

Gi0/3        1-4094

Gi0/4        1-4094

Port        Vlans allowed and active in management domain

Gi0/1       1

Gi0/2       1

Gi0/3       1

Gi0/4       1

Port        Vlans in spanning tree forwarding state and not pruned

Gi0/1      1

Gi0/2      1

Gi0/3      1

Gi0/4      1

ITKESW02#

Second Step configure the Giga Ethernet ports 0/1 to 0/4 in the Etherchannel

ITKESW02#config t

ITKESW02(config)# interface range gigabitEthernet 0/1 – 4

ITKESW02(config-if-range)#channel-protocol pagp

Note: PAgP protocol is configured to be used in this channel

ITKESW02 (config-if-range)# channel-group 1 mode auto

Note: A logical port-channel interface is automatically created when ports are grouped into a channel group.

Configure the mode auto to be used in PAgP

Now run show command to display the Etherchannel configurations on the Cisco 3560 Catalyst Switches ITKESW01 and ITKESW02

ITKESW01#sho etherchannel 1 summary

Flags: D - down        P - in port-channel

        I - stand-alone s - suspended

        H - Hot-standby (LACP only)

        R - Layer3      S - Layer2

        u - unsuitable for bundling

        U - in use      f - failed to allocate aggregator

        d - default port

Number of channel-groups in use: 1

Number of aggregators:           1

Group Port-channel Protocol    Ports

——+————-+———–+———————————————–

1      Po1(SD)          PAgP      Gi0/45 (P)   Gi0/46 (P)  Gi0/47 (P)  Gi0/48 (P)

ITKESW01#

ITKESW02#sho etherchannel 1 summary

Flags: D - down        P - in port-channel

        I - stand-alone s - suspended

        H - Hot-standby (LACP only)

        R - Layer3      S - Layer2

        u - unsuitable for bundling

        U - in use      f - failed to allocate aggregator

        d - default port

Number of channel-groups in use: 1

Number of aggregators:           1

Group Port-channel Protocol    Ports

——+————-+———–+———————————————–

1      Po1(SD)          PAgP      Gi0/1 (P)   Gi0/2 (P)  Gi0/3 (P)  Gi0/4 (P)

ITKESW02#

Cisco Etherchannel Overview and how it can be configured in Cisco Catalyst Switches – Series 5

Now let's see what options are available for load balancing in an Etherchannel bundle. How does the Cisco Catalyst Switch determines which physical link in the Etherchannel bundle to use to forward the data?

The answer is the Cisco Catalyst Switch uses a polymorphic algorithm taking key fields from the header of the packet to generate a hash to a physical link in the Etherchannel group.

Data sent across an Etherchannel is not load-balanced equally between all interfaces. Etherchannel utilizes a load-balancing algorithm, which can be based on several forms of criteria, including:

Cisco Etherchannel Overview and how it can be configured in Cisco Catalyst Switches – Series 4

The automate creation of an Etherchannels group can occur only when the Cisco Switches are running same Etherchannel protocols. Using different Etherchannel protocols at each end will not work. One more important criterion for the automated creation of the Etherchannel is the links must share the similar physical characteristics.

Configuration of ports into an Etherchannel are based on pre defined Etherchannel modes that are assigned as a default or modified via user configuration to an Ethernet port. There are five Etherchannel modes, which can be used for automated creation of an Etherchannel .

Cisco Etherchannel Overview and how it can be configured in Cisco Catalyst Switches – Series 3

Basically there are two types of protocols are available, which can be used to bundled the automated creation of an Etherchannel in the Cisco Catalyst Switches.

Cisco Etherchannel Overview and how it can be configured in Cisco Catalyst Switches – Series 2

·         An Etherchannel Group Number must be in the range of 1 to 256.
·         All ports in the target Etherchannel group MUST be in the same VLAN.
·         If one physical link in the Etherchannel group is a TRUNK, then all other ports must be configured as trunks carrying the same VLAN information.
·         Any defined broadcast limits must be the same across all ports in an Etherchannel.
·         An LACP Etherchannel group cannot support any physical links in half duplex mode.
·         No port in the Etherchannel group can be defined as a SPAN port.

Cisco Etherchannel Overview and how it can be configured in Cisco Catalyst Switches – Series 1

An Etherchannel combines multiple physical links into a single logical link that provides aggregate bandwidth of 800 MBPS (fast Etherchannel, full duplex) , 8 GBPS (Giga Etherchannel) or 80 Gbps (10 Giga Ethernet) . Ideal for load sharing or link redundancy – can be used by both layer 2 and Layer 3 subsystems and Etherchannel can provide network managers with a reliable, high-speed solution for the campus network backbone. EtherChannel technology was invented by Kalpana in the early 1990s. They were later acquired by Cisco Systems in 1994. In 2000 the IEEE passed 802.3ad which is an open standard version of EtherChannel.

I would like to explain some key points about Etherchannel using graphical diagrams so that it's easy understand and to remember.

Etherchannel can be configured defined on Ethernet, Fast Ethernet, Giga Ethernet or 10 Giga Ethernet ports

Scenario : Verifying BGP Operation

2010-03-10T21:37:00.001-08:00

Scenario : Verifying BGP Operation

This final scenario looks at Cisco IOS mechanisms for monitoring and verifying BGP routing within a Cisco router network.

The BGP topology to see how to use some common show commands to verify that BGP is operating correctly.

Show and debug commands can be valuable, not only in the real-life networks you come across, but also during your certification exams.

This scenario covers the following commands:

show ip bgp
summary— Displays BGP neighbors in summary mode
show ip bgp— Displays the BGP topology table
clear ip bgp *— Clears all BGP TCP sessions
show tcp brief— Displays all TCP sessions (BGP uses TCP)
debug ip bgp events— Displays any BGP events, such as neighbor state changes

Example 6-73 displays a sample output taken from R1 using the IOS show ip bgp summary command.

Example 6-73. show ip bgp summary on R1

R1#show ip bgp summary

BGP router identifier 131.108.255.13, local AS number 1

BGP table version is 11, main routing table version 11

6 network entries and 10 paths using 854 bytes of memory

3 BGP path attribute entries using 280 bytes of memory

BGP activity 50/44 prefixes, 73/63 paths

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd

131.108.1.2 4 1 194 195 11 0 0 00:03:22 2

131.108.255.6 4 1 84 83 11 0 0 00:03:23 3

131.108.255.14 4 1 152 152 11 0 0 00:03:23 3

141.199.1.1 4 1001 0 0 0 0 0 never Idle

Example 6-73 displays a lot of useful information, including the local router identifier 131.108.255.13, the local AS of 1, and the BGP table version of 11. (An increasing version number indicates a network change is occurring; if no changes occur, this number remains the same.) It also shows six network paths on R1, using 854 bytes of memory.

Memory is important in BGP because in a large network, such as the Internet, memory can be a limiting factor. As more BGP entries populate the IP routing table, more memory is required. Example 6-73 displays four configured remote peers: the first three are IBGP (because the AS is 1 and the same as the local AS) and one remote peer that has never been active. (The output indicates an idle session, and the up/down time displays this connection was never established.)

The BGP table is one that confuses most people. Most engineers are familiar with a standard Cisco IOS IP routing table and mistakenly apply the same principles to the BGP table. The BGP table is not an IP routing table. The BGP table displays information, such as remote and local network entries, BGP attributes, and selected paths. Entries are then inserted into the IP routing table.

Example 6-74 displays the BGP table on R1. Notice the show ip bgp command can be performed in executive mode.

Example 6-74. show ip bgp

R1>show ip bgp

BGP table version is 11, local router ID is 131.108.255.13

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal

Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

*>i131.108.255.0/30 131.108.1.2 0 100 1000 i

* i 131.108.255.14 0 100 1000 i

*> 131.108.255.4/30 0.0.0.0 0 32768 i

* i 131.108.255.6 0 100 1000 i

*>i131.108.255.8/30 131.108.1.2 0 100 1000 i

* i 131.108.255.6 0 100 1000 i

*> 131.108.255.12/30 0.0.0.0 0 32768 i

* i 131.108.255.14 0 100 1000 i

*>i141.108.1.0/24 131.108.255.6 0 100 1000 i

*>i151.108.1.0/24 131.108.255.14 0 100 1000 i

Again, the BGP table version is displayed as 11 and the local router ID is 131.108.255.13. The various networks are listed along with the next hop address, metric (MED), local preference (Locpref), weight, and the path. The i on the left side (part of the status codes) indicates an internal BGP route and the i on the right side of Example 6-74 indicates the origin. (i is for IGP, part of the origin codes.)

If a BGP configuration change is completed on Cisco IOS routers, the BGP peer session must be cleared. The command to clear all sessions is clear ip bgp *. To clear a single peer router, use the clear ip bgp
peer-ip-address command.

Example 6-75 clears all BGP sessions on R1 after a configuration change to set all IBGP peer localpref attributes to 1000, instead of the default value of 100.

Example 6-75 displays the BGP table after the change is configured and you clear all BGP peers sessions on R1.

Example 6-75. clear ip bgp * and show ip bgp on R1

R1#clear ip bgp ?

* Clear all connections

<1-65535> AS number of the peers

A.B.C.D BGP neighbor address to clear

dampening Clear route flap dampening information

flap-statistics Clear route flap statistics

peer-group Clear BGP connections of peer-group

R1#clear ip bgp *

R1#show ip bgp

BGP table version is 11, local router ID is 131.108.255.13

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal

Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

*>i131.108.255.0/30 131.108.1.2 0 1000 1000 i

* i 131.108.255.14 0 1000 1000 i

*> 131.108.255.4/30 0.0.0.0 0 32768 i

* i 131.108.255.6 0 1000 1000 i

*>i131.108.255.8/30 131.108.1.2 0 1000 1000 i

* i 131.108.255.6 0 1000 1000 i

*> 131.108.255.12/30 0.0.0.0 0 32768 i

* i 131.108.255.14 0 1000 1000 i

*>i141.108.1.0/24 131.108.255.6 0 1000 1000 i

*>i151.108.1.0/24 131.108.255.14 0 100 1000 i

The ? tool displays a number of options, including clearing BGP sessions based on AS numbers or remote peer address. On Cisco IOS routers, you must clear the BGP sessions if you want a change to take place because BGP does not update changes after a BGP session is established. You can, however, configure soft configurations with the neighbor
peer address
soft-reconfiguration inbound command, which enables you to make changes and not have to clear the TCP peer, resulting in no downtime.

Example 6-76 displays the output from the show tcp brief command on R1.

Example 6-76. show tcp brief

R1#show tcp brief

TCB Local Address Foreign Address (state)

812CC228 131.108.255.5.11040 131.108.255.6.179 ESTAB

812CF508 131.108.1.1.11039 131.108.1.2.179 ESTAB

812D0054 131.108.255.13.11041 131.108.255.14.179 ESTAB

Router R1, as displayed in Example 6-76, has three TCP sessions in an established state. The TCP port numbers are also listed. This command is useful because you need to be certain that TCP is active at Layer 4 of the OSI model when troubleshooting to discover why two BGP peers are not sending updates, for example. The foreign addresses list the TCP port as 179, and the local address is a number TCP generates. This tells you that R1 has three TCP sessions active, and you can expect BGP to send updates and keepalives across each TCP session.

Debugging BGP is useful. The most widely used tool when establishing why BGP is or is not peering is the debug ip bgp events command. Next, clear all BGP sessions on R1 with this debug command turned on to discover the session you activated.

Example 6-77 displays the sample output taken from R1 when the BGP sessions are cleared for demonstration purposes. You would never use this command during normal working hours, because BGP loses peering to any remote peers. Also, notice that the clear and debug commands are performed in privileged mode.

Example 6-77. debug ip bgp events and clear ip bgp *on R1

R1#debug ip bgp events

BGP events debugging is on

R1#clear ip bgp *

4d01h: BGP: reset all neighbors due to User reset

4d01h: BGP: 131.108.1.2 went from Established to Idle

4d01h: BGP: 131.108.255.6 went from Established to Idle

4d01h: BGP: 131.108.255.14 went from Established to Idle

4d01h: BGP: 131.108.1.2 went from Idle to Active

4d01h: BGP: 131.108.255.6 went from Idle to Active

4d01h: BGP: 131.108.255.14 went from Idle to Active

4d01h: BGP: 131.108.255.6 went from Active to OpenSent

4d01h: BGP: 131.108.255.6 went from OpenSent to OpenConfirm

4d01h: BGP: 131.108.255.6 went from OpenConfirm to Established

4d01h: BGP: 131.108.255.6 computing updates, neighbor version 0, table version 1,

starting at 0.0.0.0

4d01h: BGP: 131.108.255.6 update run completed, ran for 0ms, neighbor version 0,

start version 1, throttled to 1, check point net 0.0.0.0

4d01h: BGP: 131.108.255.14 went from Active to OpenSent

4d01h: BGP: 131.108.255.14 went from OpenSent to OpenConfirm

4d01h: BGP: 131.108.255.14 went from OpenConfirm to Established

4d01h: BGP: 131.108.255.14 computing updates, neighbor version 0, table version 1,

starting at 0.0.0.0

4d01h: BGP: 131.108.255.14 update run completed, ran for 0ms, neighbor version 0,

start version 1, throttled to 1, check point net 0.0.0.0

4d01h: BGP: 131.108.1.2 went from Active to OpenSent

4d01h: BGP: 131.108.1.2 went from OpenSent to OpenConfirm

4d01h: BGP: 131.108.1.2 went from OpenConfirm to Established

4d01h: BGP: 131.108.1.2 computing updates, neighbor version 0, table version 1,

starting at 0.0.0.0

4d01h: BGP: 131.108.1.2 update run completed, ran for 0ms, neighbor version 0,

start version 1, throttled to 1, check point net 0.0.0.0

4d01h: BGP: 131.108.255.6 computing updates, neighbor version 1, table version 9,

starting at 0.0.0.0

4d01h: BGP: 131.108.255.6 update run completed, ran for 0ms, neighbor version 1,

start version 9, throttled to 9, check point net 0.0.0.0

4d01h: BGP: scanning routing tables

The sample output from Example 6-77 displays the BGP session's teardown state (reset by user) and the re-establishing of TCP sessions to the three peers: 131.108.255.14, 131.108.255.14, and 131.108.1.2. After the sessions are active, only changes are sent across the TCP peers. You can view keepalives with the debug ip bgp keepalives command. Example 6-78 displays a sample output taken from R1 after the TCP peers are established.

Example 6-78. debug ip bgp keepalives on R1

R1#debug ip bgp keepalives

BGP keepalives debugging is on

4d01h: BGP: 131.108.255.6 sending KEEPALIVE

4d01h: BGP: 131.108.255.6 KEEPALIVE rcvd

4d01h: BGP: 131.108.255.14 sending KEEPALIVE

4d01h: BGP: 131.108.255.14 KEEPALIVE rcvd

4d01h: BGP: 131.108.1.2 sending KEEPALIVE

4d01h: BGP: 131.108.1.2 KEEPALIVE rcvd

R1 is sending and receiving keepalives to the three remote peers to ensure that the remote routers are still active. Assume that R1 is reloaded.

If you display the TCP sessions now, you will discover three TCP sessions using a new local TCP port number because the sessions have been re-established and a new random local TCP port number has been chosen by TCP.

Example 6-79 displays the TCP sessions on R1.

Example 6-79. show tcp brief on R1

R1#sh tcp brief

TCB Local Address Foreign Address (state)

812CF984 131.108.255.5.11042 131.108.255.6.179 ESTAB

812CCB20 131.108.1.1.11044 131.108.1.2.179 ESTAB

812CC6A4 131.108.255.13.11043 131.108.255.14.179 ESTAB

BGP Configuration Scenario : BGP with Communities and Peer Groups

2010-03-10T21:34:00.001-08:00

BGP Configuration Scenario : BGP with Communities and Peer Groups

BGP deals with large BGP peers by using many different scalable solutions, such as the community attribute and peer groups. In this scenario, you discover how BGP uses the community attribute along with a peer group to ensure that IBGP is scalable in a large network environment. A community is a group of routers sharing the same property. A peer group is a group of BGP neighbors sharing the same update policies.

In this scenario, you configure a well-known BGP community and discover the advantages of peer groups.

Note

The community attribute is a number defined in the range 1 to 4,294,967,200. The IOS set community
community-number [additive] command is used to define a value. Some well-known community attributes, such as no-export (do not advertise to EBGP peers) and no-advertise (do not advertise this route to any peer), can substitute for community-number.

The no export community attribute advises a BGP router carrying this attribute that the route advertised should not be advertised to any peers outside the AS.

The no advertise community attribute advises a BGP router carrying this attribute that the route advertised should not be advertised to any peers.

To apply the community attribute to a remote BGP neighbor, use the neighbor command:

neighbor {ip address | peer group} send-community

Figure 6-5 displays a simple four-router topology, including an Internet connection on R1 and R2. R1 peers to an EBGP peer with the IP address 141.199.1.1 (Remote AS 1001), and R2 peers to an EBGP peer with the IP address 151.100.1.1 (Remote AS 1002). Typically, large companies have more than one Internet connection, so to ensure that R1 and R2 are not the transit paths for any ISP-based traffic, you set the community attribute (well-known) no-export on R1 and R2.

Figure 6-5

Example 6-61 displays the community attribute setting on R1.

Example 6-61. BGP Configuration on R1

R1(config)#router bgp 1

R1(config-router)#neighbor 141.199.1.1 remote-as 1001

R1(config-router)#neighbor 141.199.1.1 send-community

R1(config-router)#neighbor 141.199.1.1 route-map setcommunity ?

in Apply map to incoming routes

out Apply map to outbound routes

R1(config-router)#neighbor 141.199.1.1 route-map setcommunity out

R1 is configured for EBGP and IBGP. The EBGP connection to the remote peer address, 141.199.1.1, is the Internet gateway. Therefore, you must send the 6community to the remote peer and apply an outbound route map, so the Internet routers do not use R1 as a transit path. You have yet to apply the route map named setcommunity (arbitrary name). Example 6-62 displays the route map configuration on R1. Apply the well-known community no-export, which informs the neighboring router not to use R1 for any traffic not destined for the network 131.108.0.0/16.

Example 6-62. Route Map Configuration on R1

R1(config)#route-map setcommunity

R1(config-route-map)#set community ?

<1-4294967295> community number

aa:nn community number in aa:nn format

additive Add to the existing community

local-AS Do not send outside local AS (well-known community)

no-advertise Do not advertise to any peer (well-known community)

no-export Do not export to next AS (well-known community)

none No community attribute

<cr>

R1(config-route-map)#set community no-export

Notice that the ? tool displays all the community variations, including a community number and the two other well-known community values: local-AS and no-advertise.

You must ensure that the ISP connected to R2 does not use R2 as a transit path. Example 6-63 configures R2 to ensure that the ISP is not using the network of Routers R1–R4 as a transit path.

Example 6-63. Community Configuration on R2

R2(config)#router bgp 1

R2(config-router)#neighbor 151.100.1.1 remote-as 1002

R2(config-router)#neighbor 151.100.1.1 se

R2(config-router)#neighbor 151.100.1.1 send-community

R2(config-router)#neighbor 151.100.1.1 route-map setcommunity out

R2(config-router)#exit

R2(config)#route-mapsetcommunity

R2(config-route-map)#set community no-export

The route map name is the same as the name used on R1 because route map names are locally significant on Cisco routers.

Next, configure the four routers, R1–R4, for IBGP, and set the same policies on all four routers. Assume the network designer has asked you to ensure that R1 does not receive any default routes from R2, R3, or R4. Also set the next-hop-self attribute on all IBGP peer sessions. Ensure that R1 sets the community to the value 2000.

For a small network such as this, the configuration on R1 can grow quite large. Take advantage of peer groups and configure one policy, and apply that policy on R1 to all three remote routers (R2, R3, and R4).

First, to demonstrate the power of peer groups, configure IBGP on R1.

Example 6-64 configures R1 for IBGP to R2 only, sets the next-hop-self attribute (no defaults routes permitted), sends the community value of 2000, and sets the weight to 1000.

Example 6-64. R1's IBGP Configuration to R2

R1(config-router)#neighbor 131.108.1.2 route-map setattributes in

R1(config-router)#neighbor 131.108.1.2 next-hop-self

R1(config-router)#neighbor 131.108.1.2 distribute-list 1 in

R1(config-router)#neighbor 131.108.1.2 send-community

R1(config-router)#neighbor 131.108.1.2 weight 1000

R1(config)#route-map setattributes

R1(config-route-map)#set community 2000

R1(config)#access-list 1 deny 0.0.0.0

To configure R1 to set the same attributes and conditions to R3 and R4, you need to complete the same set of IOS commands (seven IOS commands in total) and have different route maps and access lists. Clearly with a large network, this is not scalable.

To create a BGP peer group, use the neighbor peer-group command, beginning in router configuration mode. Example 6-65 creates a peer group on R1 named internal; again, the name is an arbitrary name.

Example 6-65. Peer Group Command on R1

R1(config)#router bgp 1

R1(config-router)#neighbor internal peer-group

You must then assign the options, such as the weight and community value, to the peer groups. Example 6-66 displays all the available options you can assign to a peer group.

Example 6-66. Peer Groups Options

R1(config-router)#neighbor internal ?

advertise-map specify route-map for conditional advertisement

advertisement-interval Minimum interval between sending EBGP routing updates

default-originate Originate default route to this neighbor

description Neighbor specific description

distribute-list Filter updates to/from this neighbor

ebgp-multihop Allow EBGP neighbors not on directly connected

networks

filter-list Establish BGP filters

maximum-prefix Maximum number of prefix accept from this peer

next-hop-self Disable the next hop calculation for this neighbor

password Set a password

peer-group Configure peer-group

prefix-list Filter updates to/from this neighbor

remote-as Specify a BGP neighbor

remove-private-AS Remove private AS number from outbound updates

route-map Apply route map to neighbor

route-reflector-client Configure a neighbor as Route Reflector client

send-community Send Community attribute to this neighbor

shutdown Administratively shut down this neighbor

soft-reconfiguration Per neighbor soft reconfiguration

timers BGP per neighbor timers

unsuppress-map Route-map to selectively unsuppress suppressed routes

The shaded sections in Example 6-66 contain the options you set. Example 6-67 displays the setting of a distribution list to stop a default route from being accepted on R1, advertising the next-hop-self attribute, setting the remote AS number to 1 (same on all IBGP peers), and ensuring that community 2000 is sent to R2, R3, and R4.

Example 6-67. Peer Group Definitions

R1(config-router)#neighbor internal distribute-list 1 in

R1(config-router)#neighbor internal next-hop-self

R1(config-router)#neighbor internal remote-as 1

R1(config-router)#neighbor internal route-map setattributes in

Finally, apply these settings to all the remote peers. Example 6-68 shows how to make R2, R3, and R4 members of the peer group called internal.

Example 6-68. Making R2, R3, and R4 Members of the Peer Group Internal

router bgp 1

neighbor 131.108.1.2 peer-group internal

neighbor 131.108.255.6 peer-group internal

neighbor 131.108.255.14 peer-group internal

R1 has defined three remote IBGP peers with one statement that sets all the parameters defined by the peer group internal. You can configure BGP peers to override configuration options if required. The beauty of using peer groups is that you can add more BGP peers by using only one command. This scales much better than configuring a multitude of IOS commands on several routers. Chapter 7 describes two other main methods used in BGP networks to scale in large networks, namely route reflectors (you might notice this network is fully meshed, that is, every BGP routers has a peer to each other) and confederations.

Example 6-69 displays the full working configuration on R1. Take note of the shaded sections that configure R1 to set local-based policies to all three IBGP peers. Peer groups can also be applied to EBGP peers and are commonly used in large ISP networks in which many thousands of customers might have Internet connections.

Example 6-69. R1's Full Working Configuration

hostname R1

enable password cisco

interface Ethernet0/0

ip address 131.108.1.1 255.255.255.0

interface Serial1/0

ip address 131.108.255.5 255.255.255.252

clockrate 128000

interface Serial1/1

Description Link to Internet

ip address 141.199.2.1 255.255.255.252

interface Serial1/2

ip address 131.108.255.13 255.255.255.252

no ip directed-broadcast

router bgp 1

no synchronization

network 131.108.255.4 mask 255.255.255.252

network 131.108.255.12 mask 255.255.255.252

neighbor internal peer-group

neighbor internal remote-as 1

neighbor internal distribute-list 1 in

neighbor internal route-map setattributes in

neighbor 131.108.1.2 peer-group internal

neighbor 131.108.255.6 peer-group internal

neighbor 131.108.255.14 peer-group internal

neighbor 141.199.1.1 remote-as 1001

neighbor 141.199.1.1 send-community

neighbor 141.199.1.1 route-map setcommunity out

access-list 1 deny 0.0.0.0

access-list 1 permit any

route-map setcommuntiy permit 10

set community no-export

route-map setattributes permit 10

match ip address 2

set weight 1000

set community 1000

line con 0

line aux 0

line vty 0 4

end

Example 6-70 displays the full working configuration on R2. Notice R2 is not configured for peer groups.

Example 6-70. R2's Full Working Configuration

hostname R2

enable password cisco

interface Ethernet0/0

ip address 131.108.1.2 255.255.255.0

interface Serial1/0

bandwidth 128

ip address 131.108.255.1 255.255.255.252

no ip directed-broadcast

no ip mroute-cache

interface Serial1/1

Description Link to Internet

ip address 151.100.2.1 255.255.255.252

interface Serial1/2

ip address 131.108.255.9 255.255.255.252

clockrate 128000

router bgp 1

no synchronization

network 131.108.255.0 mask 255.255.255.252

network 131.108.255.8 mask 255.255.255.252

neighbor 131.108.1.1 remote-as 1

neighbor 131.108.255.2 remote-as 1

neighbor 131.108.255.10 remote-as 1

neighbor 151.100.1.1 remote-as 1002

neighbor 151.100.1.1 send-community

neighbor 151.100.1.1 route-map setcommunity out

route-map setcommunity permit 10

set community no-export

line con 0

line aux 0

line vty 0 4

end

Example 6-71 displays the full working configuration on R3. Notice R3 is not configured for peer groups.

Example 6-71. R3's Full Working Configuration

hostname R3

enable password cisco

interface Ethernet0

ip address 141.108.1.1 255.255.255.0

interface Serial0

ip address 131.108.255.6 255.255.255.252

interface Serial1

ip address 131.108.255.10 255.255.255.252

router bgp 1

no synchronization

network 141.108.1.0 mask 255.255.255.0

network 131.108.255.4 mask 255.255.255.252

network 131.108.255.8 mask 255.255.255.252

neighbor 131.108.255.5 remote-as 1

neighbor 131.108.255.9 remote-as 1

no ip classless

route-map setweight permit 10

match ip address 1

set weight 1

route-map setweight permit 20

match ip address 2

line con 0

line aux 0

line vty 0 4

end

Example 6-72 displays the full working configuration on R4. Notice R4 is not configured for peer groups.

Example 6-72. R4's Full Working Configuration

hostname R4

enable password cisco

interface Ethernet0

ip address 151.108.1.1 255.255.255.0

interface Serial0

ip address 131.108.255.2 255.255.255.252

clockrate 125000

interface Serial1

ip address 131.108.255.14 255.255.255.252

clockrate 125000

interface Serial3

ip address 131.108.255.10 255.255.255.252

clockrate 125000

router bgp 1

no synchronization

network 131.108.255.0 mask 255.255.255.252

network 131.108.255.12 mask 255.255.255.252

network 151.108.1.0 mask 255.255.255.0

neighbor 131.108.255.1 remote-as 1

neighbor 131.108.255.13 remote-as 1

line con 0

line aux 0

line vty 0 4

end

BGP Configuration Scenario: BGP with Policy-Based Routing

2010-03-10T21:32:00.001-08:00

BGP Configuration Scenario: BGP with Policy-Based Routing

In this scenario, you configure EBGP using the next hop addresses and use policy-based routing to allow certain network design policies to affect IP routing decisions.

Policy-based routing is used for the following main reasons:

To control traffic flow direction either by source or destination address
To change the next hop address
To change the way traffic is sent to a neighboring router

The advantages of using policy routing is the ability to load share to provide high-quality service and cost saving, based on data traffic, for expensive links.

Figure 6-4 displays the same two-router network used in Scenario 6-3, except this time you configure two EBGP sessions between R1 and R2 and use BGP to route dynamically without static routing.

Figure 6-4 Two- Session Topology

Configure two EBGP TCP sessions between R1 and R2. Example 6-46 displays the EBGP configuration on R1. (Notice, you don't need EBGP multihop because you are using a directly connected peer.)

Example 6-46. EBGP on R1

R1(config)#router bgp 1

R1(config-router)#network 131.108.1.0 mask 255.255.255.0

R1(config-router)#neighbor 131.108.255.2 remote-as 2

R1(config-router)#neighbor 131.108.255.6 remote-as 2

Example 6-47 displays the two EBGP sessions configured on R2.

Example 6-47. EBGP on R2

R2(config)#router bgp 2

R2(config-router)#network 161.108.1.0 mask 255.255.255.0

R2(config-router)#neighbor 131.108.255.1 remote-as 1

R2(config-router)#neighbor 131.108.255.5 remote-as 1

Example 6-48 displays the IP BGP table on R1 after the two BGP sessions are established.

Example 6-48. BGP Table on R1

R1#show ip bgp

BGP table version is 3, local router ID is 131.108.255.5

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal

Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

*> 131.108.1.0/24 0.0.0.0 0 32768 i

* 161.108.1.0/24 131.108.255.6 0 0 2 i

*> 131.108.255.2 0 0 2 i

Example 6-48 displays R1 choosing the path through the next hop address. 131.108.255.2. to reach the remote network 161.108.1.0/24 because BGP does not load balance as you discovered in Scenario 6-2. The path is chosen through 131.108.255.2 because of its lower IP addresses; all other parameters that BGP bases decisions on are equal in this case. Assume that all traffic from the Ethernet segment on R1 bound for 161.108.1.0 must be sent through the next hop address 131.108.255.6, or Serial 1/1, and all traffic destined for the Internet is sent through Serial 1/0.

You can force BGP to complete this task by using policy-based routing or changing BGP attributes. But, suppose you want to send internal traffic through one path and all Internet traffic through the second link. Next, you learn to configure policy-based routing to illustrate how you can use route maps to achieve this.

To illustrate policy-based routing, configure R1 to choose a different next hop address for IP ICMP packets destined for the remote network 161.108.1.0 (Serial 1/1) than for all other destinations (for example, Internet-based traffic), which will be through the second link (Serial 1/0).

Policy routing is based on incoming packets only, so you need to apply the policy command on the Ethernet interface on R1.

First, configure R2 to advertise a default route to R1.

Example 6-49 displays the configuration on R2 so that it sends a default BGP route to R1. Two default statements are configured for redundancy purposes.

Example 6-49. Default Route Configuration on R2

R2(config)#router bgp 2

R2(config-router)#neighbor 131.108.255.1 default-originate

R2(config-router)#neighbor 131.108.255.5 default-originate

Example 6-50 displays the BGP default route in R1's BGP table.

Example 6-50. show ip bgp Command on R1

R1>show ip bgp

BGP table version is 4, local router ID is 131.108.255.5

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal

Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

* 0.0.0.0 131.108.255.6 0 2 i

*> 131.108.255.2 0 2 i

*> 131.108.1.0/24 0.0.0.0 0 32768 i

* 161.108.1.0/24 131.108.255.6 0 0 2 i

*> 131.108.255.2 0 0 2 i

Example 6-50 tells you that R1 is choosing all traffic through the next hop address 131.108.255.2. Example 6-51 confirms this when you view the IP routing table on R1.

Example 6-51. show ip route Command on R1

R1>show ip route

Gateway of last resort is 131.108.255.2 to network 0.0.0.0

131.108.0.0/16 is variably subnetted, 3 subnets, 2 masks

C 131.108.255.0/30 is directly connected, Serial1/0

C 131.108.255.4/30 is directly connected, Serial1/1

C 131.108.1.0/24 is directly connected, Ethernet0/0

161.108.0.0/24 is subnetted, 1 subnets

B 161.108.1.0 [20/0] via 131.108.255.2, 00:23:11

B* 0.0.0.0/0 [20/0] via 131.108.255.2, 00:13:58

Policy routing needs to be configured on R1 to ensure that IP ICMP packets destined for the remote network 161.108.1.0/24 are sent through the next hop address 131.108.255.6 and all other traffic is sent through 131.108.1.1 (Serial 1/0 to R2).

To configure policy routing, you apply the policy statement on the outbound interface and reference a route map. The IOS command is ip policy route-map
route-map-name.

Example 6-52 displays the policy routing interface configuration on R1. The route map name is an arbitrary name you can assign. This example assigns a route map called nondefault.

Example 6-52. Policy Configuration on R1

R1(config)#interface E0/0

R1(config-if)#ip policy route

R1(config-if)#ip policy route-map ?

WORD Route map name

R1(config-if)#ip policy route-map nondefault

Next, you must set the conditions on R1 so that policy routing can occur. Example 6-53 sets all IP ICMP traffic from the Ethernet segment on R1 destined for 161.108.1.0/24 through Serial 1/1 (next hop address 131.108.255.6) and all default traffic through Serial 1/0 (next hop address 131.108.255.1). Remember that BGP, as displayed in Example 6-50, is sending all traffic through Serial 1/0 on R1. Example 6-52 uses the ? tool to illustrate the options available to you.

Example 6-53. Route Map Configuration on R1

route-map default permit 10

match ip address 100

set ip next-hop 131.108.255.6

access-list 100 permit icmp 131.108.1.0 0.0.0.255 161.108.1.0 0.0.0.255

The route map on R1 policy routes any IP ICMP packets with a source address in the range 131.108.1.1–131.108.1.255 through the next hop address 131.108.255.6.

Unfortunately, you cannot verify policy routing with the IP routing table. Example 6-54 displays R1's IP routing table.

Example 6-54. show ip route on R1

R1#show ip route

131.108.0.0/16 is variably subnetted, 3 subnets, 2 masks

C 131.108.255.0/30 is directly connected, Serial1/0

C 131.108.255.4/30 is directly connected, Serial1/1

C 131.108.1.0/24 is directly connected, Ethernet0/0

161.108.0.0/24 is subnetted, 1 subnets

B 161.108.1.0 [20/0] via 131.108.255.2, 00:22:52

B* 0.0.0.0/0 [20/0] via 131.108.255.2, 00:22:52

Example 6-54 stills displays that all remote networks are routed through 131.108.255.2, or Serial 1/0.

An extended ping request along with a debug ip policy on R1 displays any policy routing.

Example 6-55 displays an extended ping using the source address 131.108.1.1 (R1's Ethernet interface) to the remote network 161.108.1.0/4.

Example 6-55. Extended Ping on R1

R1#debug ip policy

Policy routing debugging is on

R1#ping

Protocol [ip]:

Target IP address: 161.108.1.1

Repeat count [5]:

Datagram size [100]:

Timeout in seconds [2]:

Extended commands [n]: y

Source address or interface: 131.108.1.1

Type of service [0]:

Set DF bit in IP header? [no]:

Validate reply data? [no]:

Data pattern [0xABCD]:

Loose, Strict, Record, Timestamp, Verbose[none]:

Sweep range of sizes [n]:

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 161.108.1.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 16/18/20 ms

00:26:57: IP: s=131.108.1.1 (local), d=161.108.1.1, len 100, policy match

00:26:57: IP: route map default, item 10, permit

00:26:57: IP: s=131.108.1.1 (local), d=161.108.1.1 (Serial1/1), len 100, policy

routed

00:26:57: IP: local to Serial1/1 131.108.255.6

00:26:57: IP: s=131.108.1.1 (local), d=161.108.1.1, len 100, policy match

00:26:57: IP: route map default, item 10, permit

00:26:57: IP: s=131.108.1.1 (local), d=161.108.1.1 (Serial1/1), len 100, policy

routed

00:26:57: IP: local to Serial1/1 131.108.255.6

00:26:57: IP: s=131.108.1.1 (local), d=161.108.1.1, len 100, policy match

00:26:57: IP: route map default, item 10, permit

00:26:57: IP: s=131.108.1.1 (local), d=161.108.1.1 (Serial1/1), len 100, policy

routed

00:26:57: IP: local to Serial1/1 131.108.255.6

00:26:57: IP: s=131.108.1.1 (local), d=161.108.1.1, len 100, policy match

00:26:57: IP: route map default, item 10, permit

00:26:57: IP: s=131.108.1.1 (local), d=161.108.1.1 (Serial1/1), len 100, policy

routed

00:26:57: IP: local to Serial1/1 131.108.255.6

00:26:57: IP: s=131.108.1.1 (local), d=161.108.1.1, len 100, policy match

00:26:57: IP: route map default, item 10, permit

00:26:57: IP: s=131.108.1.1 (local), d=161.108.1.1 (Serial1/1), len 100, policy

routed

00:26:57: IP: local to Serial1/1 131.108.255.6

Example 6-55 displays the five ping requests successfully policy routed through Serial 1/1, or the next hop address 131.108.255.6.

Example 6-56 displays a ping request to the unknown network 141.108.1.1 on R1 and the subsequent policy debug output.

Example 6-56. ping 141.108.1.1 on R1

R1#ping 141.108.1.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 141.108.1.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 16/16/20 ms

00:30:35: IP: s=131.108.255.1 (local), d=141.108.1.1, len 100, policy rejected -

- normal forwarding

00:30:35: IP: s=131.108.255.1 (local), d=141.108.1.1, len 100, policy rejected -

- normal forwarding

00:30:35: IP: s=131.108.255.1 (local), d=141.108.1.1, len 100, policy rejected -

- normal forwarding

00:30:35: IP: s=131.108.255.1 (local), d=141.108.1.1, len 100, policy rejected -

- normal forwarding

00:30:35: IP: s=131.108.255.1 (local), d=141.108.1.1, len 100, policy rejected -

- normal forwarding

00:30:37: IP: s=131.108.255.1 (local), d=131.108.255.2, len 59, policy rejected

-- normal forwarding

00:30:39: IP: s=131.108.255.5 (local), d=131.108.255.6, len 59, policy rejected

-- normal forwarding

R1 sends all packets to an unknown destination through normal forwarding through Serial 1/0. The debug output in Example 6-56 displays a nonmatching policy; hence, the IP datagram is forwarded through the normal outbound interface.

This simple scenario demonstrates the powerful use of policy-based routing on source and destination addresses. With the use of extended access lists, you can also base routing on port numbers. For example, you can do this if you want Telnet sessions to go through one interface or another.

Configure R1 to send all Telnet traffic originated from the network 131.108.1.0/24 through the next hop interface 131.108.255.6.

Example 6-57 displays the access-list configuration to allow Telnet sessions through Serial 1/1.

Example 6-57. Allowing Telnet to Be Policy Routed on R1

access-list 100 permit tcp 131.108.1.0 0.0.0.255 161.108.1.0 0.0.0.255 eq telnet

Example 6-58. Sample debug ip policy Output on R1

R1#debug ip policy

Policy routing debugging is on

R1#telnet 161.108.1.1 /source-interface ethernet 0/0

Trying 161.108.1.1 ... Open

R2>

01:04:00: IP: s=131.108.1.1 (local), d=161.108.1.1, len 44, policy match

01:04:00: IP: route map default, item 10, permit

01:04:00: IP: s=131.108.1.1 (local), d=161.108.1.1 (Serial1/1), len 44, policy

routed