|
|
This chapter explains the basic tasks for configuring IP-based, intranet and extranet Virtual Private Networks (VPNs) on a Cisco 7100 series router using generic routing encapsulation (GRE) and IPSec tunneling protocols. Basic security, Network Address Translation (NAT), Encryption, Cisco IOS weighted fair queuing (WFQ), and extended access lists for basic traffic filtering are configured.
 |
Note This chapter describes basic features and configurations used in a site-to-site VPN scenario. Some Cisco IOS security software features not described in this document can be used to increase performance and scalability of your VPN. For up-to-date Cisco IOS security software features documentation, refer to the Cisco IOS Security Configuration Guide and the Cisco IOS Security Command Reference publication. To access these documents, go to Cisco Connection Online, at http://www.cisco.com, and select the following links under "Service & Support": Technical Documents: Cisco Product Documentation: Cisco IOS Software Configuration: Cisco IOS Release 12.1: Configuration Guides and Command References |
This chapter includes the following sections:
|
Note Throughout this chapter, there are numerous configuration examples and sample configuration outputs that include unusable IP addresses. Be sure to use your own IP addresses when configuring your Cisco 7100 series router. |
Figure 3-1 shows a headquarters network providing a remote office access to the corporate intranet. In this scenario, the headquarters and remote office are connected through a secure GRE tunnel that is established over an IP infrastructure (the Internet). Employees in the remote office are able to access internal, private web pages and perform various IP-based network tasks.
|
Note Although the intranet VPN scenario in this chapter is configured with GRE tunneling, an intranet VPN can also be configured with IPSec only tunneling. |
Figure 3-2 shows the physical elements of the scenario. The Internet provides the core interconnecting fabric between the headquarters and remote office routers. Both the headquarters and remote office are using a Cisco 7140-2T3 as a gateway router. Both routers have two high-speed synchronous serial T3 interfaces, two Fast Ethernet 10/100BaseT autosensing interfaces, and one Integrated Service Module (ISM) installed. The ISM provides hardware-based encryption services for any interface installed in the router.
The configuration steps in the following sections are for the headquarters router, unless noted otherwise. Comprehensive configuration examples for both the headquarters and remote office routers are provided in the "Comprehensive Configuration Examples" section.
Table 3-1 lists the intranet scenario's physical elements.
| Headquarters Network | Remote Office Network | ||||
|---|---|---|---|---|---|
| Site Hardware | WAN IP Address | Ethernet IP Address | Site Hardware | WAN IP Address | Ethernet IP Address |
hq-sanjose | Serial interface 1/0: Tunnel interface 0: | Fast Ethernet Fast Ethernet | ro-rtp | Serial interface 1/0: Tunnel interface 1: | Fast Ethernet |
Corporate server | --- | 10.1.3.6 | PC A | --- | 10.1.4.3 |
Web server | --- | 10.1.6.5 | |||
The extranet scenario introduced in Figure 3-3 builds on the intranet scenario by providing a business partner access to the same headquarters network. In the extranet scenario, the headquarters and business partner are connected through a secure IPSec tunnel and the business partner is given access only to the headquarters public Web server to perform various IP-based network tasks, such as placing and managing product orders.
Figure 3-4 shows the physical elements of the scenario. As in the intranet business scenario, the Internet provides the core interconnecting fabric between the headquarters and business partner routers. Like the headquarters office, the business partner is also using a Cisco 7140-2T3 as a gateway router, which has two high-speed synchronous serial T3 interfaces, two Fast Ethernet 10/100BaseT autosensing interfaces, and one Integrated Service Module (ISM) installed. The ISM provides hardware-based encryption for all interfaces installed in the router, including the IP Security Protocol (IPSec) tunneling services for the serial connection between the headquarters and business partner routers.
The IPSec tunnel between the two sites is configured on the second serial interface in chassis slot 2 (serial 2/0) of the headquarters router and the first serial interface in chassis slot 1 (serial 1/0) of the business partner router. Fast Ethernet interface 0/0 of the headquarters router is still connected to a private corporate server and Fast Ethernet interface 0/1 is connected to a public Web server. Fast Ethernet interface 0/0 of the business partner router is connected to a PC client.
The configuration steps in the following sections are for the headquarters router, unless noted otherwise. Comprehensive configuration examples for both the headquarters and business partner routers are provided in the "Comprehensive Configuration Examples" section.
Table 3-2 lists the extranet scenario's physical elements.
| Headquarters Network | Business Partner Network | ||||
|---|---|---|---|---|---|
| Site Hardware | WAN IP Address | Ethernet IP Address | Site Hardware | WAN IP Address | Ethernet IP Address |
hq-sanjose | Serial interface 2/0: | Fast Ethernet Fast Ethernet | bus-ptnr | Serial interface 1/0: | Fast Ethernet |
Corporate server | --- | 10.1.3.6 | PC B | --- | 10.1.5.3 |
Web server | --- | 10.1.6.51 | |||
| 1The inside local IP address of the headquarters network public Web server (10.1.6.5) is translated to inside global IP address 10.2.2.2 in the "Step 2Configuring Network Address Translation" section. |
Tunneling has the following three primary components:
Figure 3-5 illustrates IP tunneling terminology and concepts.
GRE is capable of handling the transportation of multiprotocol and IP multicast traffic between two sites, which only have IP unicast connectivity. The importance of using tunnels in a VPN environment is based on the fact that IPSec encryption only works on IP unicast frames. Tunneling allows for the encryption and the transportation of multiprotocol traffic across the VPN since the tunneled packets appear to the IP network as an IP unicast frame between the tunnel endpoints. If all connectivity must go through the home gateway router, tunnels also enable the use of private network addressing across a service provider's backbone without the need for running the Network Address Translation (NAT) feature.
This section contains basic steps to configure a GRE tunnel and includes the following tasks:
To configure a GRE tunnel between the headquarters and remote office routers, you must configure a tunnel interface, source, and destination on the headquarters and remote office routers. To do this, complete the following steps starting in global configuration mode.
|
Note The following procedure assumes the tunnel interface, source, and destination on the remote office router are configured with the values listed in Table 3-1. |
| Command | Purpose | |
|---|---|---|
Step 1 |
| Specify a tunnel interface number, enter interface configuration mode, and configure an IP address and subnet mask on the tunnel interface. This example configures IP address and subnet mask 172.17.3.3 255.255.255.0 for tunnel interface 0 on the headquarters router. |
Step 2 | | Specify the tunnel interface source address and subnet mask. This example uses the IP address and subnet mask of T3 serial interface 1/0 of the headquarters router. |
Step 3 | | Specify the tunnel interface destination address. This example uses the IP address and subnet mask of T3 serial interface 1/0 of the remote office router. |
Step 4 | | Configure GRE as the tunnel mode. GRE is the default tunnel encapsulation mode, so this command is considered optional. |
Step 5 |
| Bring up the tunnel interface.1 |
Step 6 |
| Exit back to global configuration mode and configure traffic from the remote office network through the tunnel. This example configures traffic from the remote office Fast Ethernet network (10.1.4.0 255.255.255.0) through GRE tunnel 0. |
| 1This command changes the state of the tunnel interface from administratively down to up. |
|
Note When configuring GRE, you must have only Cisco routers or access servers at both ends of the tunnel connection. |
To verify the configuration:
hq-sanjose# show interfaces tunnel 0
Tunnel0 is up, line protocol is up
Hardware is Tunnel
Internet address is 172.17.3.3/24
MTU 1514 bytes, BW 180 Kbit, DLY 500000 usec,
reliablility 255/255, txload 1/255, rxload 1/255
Encapsulation TUNNEL, loopback not set
Keepalive set (10 sec)
Tunnel source 172.17.2.4, destination 172.24.2.5
Tunnel protocol/transport GRE/IP, key disabled, sequencing disabled
Checksumming of packets disabled, fast tunneling enabled
Last input never, output 00:10:44, output hang never
Last clearing of "show interface" counters never
Queueing strategy:fifo
Output queue 0/0, 0 drops; input queue 0/75, 0 drops
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
0 packets input, 0 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
29 packets output, 2348 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 output buffer failures, 0 output buffers swapped out
hq-sanjose(config)# ping 172.24.3.6 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.24.3.6, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 4/5/8 ms
 |
Tips If you have trouble, make sure you are using the correct IP address and that you enabled the tunnel interface with the no shutdown command. |
IPSec can be configured it tunnel mode or transport mode. IPSec tunnel mode is an alternative to using a GRE tunnel. In IPSec tunnel mode, the entire original IP datagram is encrypted, and it becomes the payload in a new IP packet. This mode allows a network device, such as a router, to act as an IPSec proxy. That is, the router performs encryption on behalf of the hosts. The source router encrypts packets and forwards them along the IPSec tunnel. The destination router decrypts the original IP datagram and forwards it on to the destination system. The major advantage of tunnel mode is that the end systems do not need to be modified to receive the benefits of IPSec. Tunnel mode also protects against traffic analysis; with tunnel mode an attacker can only determine the tunnel endpoints and not the true source and destination of the tunneled packets, even if they are the same as the tunnel endpoints.
|
Note IPSec tunnel mode configuration instructions are described in detail in the "Configuring IPSec and IPSec Tunnel Mode" section. |
In IPSec transport mode, only the IP payload is encrypted, and the original IP headers are left intact. (See Figure 3-6.) This mode has the advantage of adding only a few bytes to each packet. It also allows devices on the public network to see the final source and destination of the packet. With this capability, you can enable special processing (for example, QoS) in the intermediate network based on the information in the IP header. However, the Layer 4 header will be encrypted, limiting the examination of the packet. Unfortunately, by passing the IP header in the clear, transport mode allows an attacker to perform some traffic analysis. (See the "Defining Transform Sets and Configuring IPSec Tunnel Mode" section for an IPSec transport mode configuration example.)
|
Note NAT is used if you have conflicting private address spaces in the extranet scenario. If you have no conflicting private address spaces, proceed to the "Step 3Configuring Encryption and IPSec" section |
Static translation establishes a one-to-one mapping between your internal local address and an inside global address. Static translation is useful when a host on the inside must be accessible by a fixed address from the outside.
|
Note For detailed, additional configuration information on NAT---for example, instructions on how to configure dynamic translation---refer to the "Configuring IP Addressing" chapter in the Network Protocols Configuration Guide, Part 1. NAT is also described in RFC 1631. |
NAT uses the following definitions:
Figure 3-7 illustrates a router that is translating a source address inside a network to a source address outside the network.
The following process describes inside source address translation, as shown in Figure 3-7:
1. The user at Host 10.1.1.1 opens a connection to Host B.
2. The first packet that the router receives from Host 10.1.1.1 causes the router to check its NAT table.
3. The router replaces the inside local source address of Host 10.1.1.1 with the translation entry's global address, and forwards the packet.
4. Host B receives the packet and responds to Host 10.1.1.1 by using the inside global IP destination address (DA) 10.2.2.2.
5. When the router receives the packet with the inside global IP address, it performs a NAT table lookup by using the inside global address as a key. It then translates the address to the inside local address of Host 10.1.1.1 and forwards the packet to Host 10.1.1.1.
6. Host 10.1.1.1 receives the packet and continues the conversation. The router performs Steps 2 through 5 for each packet.
To configure static inside source address translation, complete the following steps starting in global configuration mode:
| Command | Purpose | |
|---|---|---|
Step 1 | | Establish static translation between an inside local address and an inside global address. This example translates inside local address 10.1.6.5 (the Web server) to inside global address 10.2.2.2. |
Step 2 | | Specify the inside interface. This example specifies Fast Ethernet interface 0/1 on the headquarters router. |
Step 3 | | Mark the interface as connected to the inside. |
Step 4 | | Specify the outside interface. This example specifies serial interface 2/0 on the headquarters router. |
Step 5 | | Mark the interface as connected to the outside. |
Step 6 |
| Exit back to global configuration mode. |
The previous steps are the minimum you must configure for static inside source address translation. You could configure multiple inside and outside interfaces.
To verify the configuration:
hq-sanjose# show ip nat translations verbose
Pro Inside global Inside local Outside local Outside
global
--- 10.2.2.2 10.1.6.5 --- ---
create 00:10:28, use 00:10:28, flags:
static
hq-sanjose# show running-config interface FastEthernet0/1 ip address 10.1.6.5 255.255.255.0 no ip directed-broadcast ip nat inside interface serial2/0 ip address 172.16.2.2 255.255.255.0 ip nat outside ip nat inside source static 10.1.6.5 10.2.2.2
The most important part of building a VPN is maintaining security, while allowing authorized users access. The Integrated Service Module (ISM) in slot 5 of Cisco 7100 series routers provides hardware-based data encryption services for Cisco 7100 series routers. The hardware-based service provided by the ISM improves the overall performance of Cisco 7100 series routers by off-loading data encryption processing from the main system processor. The ISM supports IP Security Protocol (IPSec), Internet Key Exchange (IKE), and Certification Authority (CA) interoperability features.
For the ISM in slot 5 of Cisco 7100 series routers to provide encryption and IPSec tunneling services, you must complete the following tasks:
|
Note When using GRE tunnels, you should not configure IPSec tunnel mode. |
Optionally, you can configure Certification Authority (CA) interoperability. This guide does not explain how to configure CA interoperability on your Cisco 7100 series router. Refer to the "IP Security and Encryption" part of the Security Configuration Guide and the Security Command Reference publications for detailed information on configuring CA interoperabilty.
|
Note This section only contains basic configuration information for enabling encryption and IPSec tunneling services. Refer to the "IP Security and Encryption" part of the Security Configuration Guide and the Security Command Reference publications for detailed configuration information on IPSec, IKE, and CA. Refer to the Integrated Service Adapter and Integrated Service Module Installation and Configuration publication for detailed configuration information on the ISM. |
You can create multiple IKE policies, each with a different combination of parameter values. If you do not configure any IKE policies, the router uses the default policy, which is always set to the lowest priority, and which contains each parameter default value.
For each policy that you create, you assign a unique priority (1 through 10,000, with 1 being the highest priority). You can configure multiple policies on each peer---but at least one of these policies must contain exactly the same encryption, hash, authentication, and Diffie-Hellman parameter values as one of the policies on the remote peer. If you do not specify a value for a parameter, the default value is assigned.
This section contains basic steps to configure IKE policies and includes the following tasks:
To create an IKE policy, complete the following steps starting in global configuration mode:
| Command | Purpose | |
|---|---|---|
Step 1 | | Enter config-isakmp command mode and identify the policy to create. (Each policy is uniquely identified by the priority number you assign.) This example configures policy 1. |
Step 2 | | Specify the encryption algorithm---56-bit Data Encryption Standard (DES [des]) or 168-bit Triple DES (3des). This example configures the DES algorithm, which is the default. |
Step 3 | | Specify the hash algorithm---Message Digest 5 (MD5 [md5]) or Secure Hash Algorithm (SHA [sha]). This example configures SHA, which is the default. |
Step 4 | | Specify the authentication method---preshared keys (pre-share), RSA1 encrypted nonces (rsa-encr), or RSA signatures (rsa-slg). This example configures preshared keys. The default is RSA signatures. |
Step 5 | | |
Step 6 | | Specify the security association's lifetime---in seconds. This example configures 86400 seconds (one day). |
Step 7 |
| Exit back to global configuration mode. |
| 1RSA = Rivest, Shamir, and Adelman. |
Each authentication method requires an additional companion configuration as follows:
If RSA encryption is configured and signature mode is negotiated, the peer will request both signature and encryption keys. Basically, the router will request as many keys as the configuration will support. If RSA encryption is not configured, it will just request a signature key.
Step 2 Specify the shared keys at each peer. Note that a given preshared key is shared between two peers. At a given peer, you could specify the same key to share with multiple remote peers; however, a more secure approach is to specify different keys to share between different pairs of peers.
|
Note The following procedure is based on the "Intranet Scenario" section. However, the same configuration commands can be used in an extranet scenario. |
To specify preshared keys at a peer, complete the following steps in global configuration mode:
| Command | Purpose | |
|---|---|---|
Step 1 | | At the local peer: Specify the ISAKMP identity (address or hostname) the headquarters router will use when communicating with the remote office router during IKE negotiations. This example specifies the address keyword, which uses IP address 172.17.2.4 (serial interface 1/0 of the headquarters router) as the identity for the headquarters router. |
Step 2 | | At the local peer: Specify the shared key the headquarters router will use with the remote office router. This example configures the shared key test12345 to be used with the remote peer 172.24.2.5 (serial interface 1/0 on the remote office router). |
Step 3 | | At the remote peer: Specify the ISAKMP identity (address or hostname) the remote office router will use when communicating with the headquarters router during IKE negotiations. Again, this example specifies the address keyword, which uses IP address 172.24.2.5 (serial interface 1/0 of the remote office router) as the identity for the remote office router. |
Step 4 | | At the remote peer: Specify the shared key to be used with the local peer. This is the same key you just specified at the local peer. This example configures the shared key test12345 to be used with the local peer 172.17.2.4 (serial interface 1/0 on the headquarters router). |
To verify the configuration:
hq-sanjose# show crypto isakmp policy Protection suite priority 1 encryption algorithm: DES - Data Encryption Standard (56 bit keys) hash algorithm: Secure Hash Standard authentication method: Pre-Shared Key Diffie-Hellman group: #1 (768 bit) lifetime: 86400 seconds, no volume limit
|
Note Although the above output shows "no volume limit" for the lifetimes, you can currently only configure a time lifetime (such as 86400 seconds); volume limit lifetimes are not configurable. |
|
Tips If you have trouble, use the show version command to ensure your Cisco 7100 series router is running a Cisco IOS software image that supports crypto. |
hq-sanjose# show version Cisco Internetwork Operating System Software IOS (tm) EGR Software (c7100-JOS56I-M), Release Version 12.0(4)XE Copyright (c) 1986-1999 by cisco Systems, Inc. Compiled Mon 22-Mar-99 21:41 by biff Image text-base:0x600088F8, data-base:0x611CE000 ROM:System Bootstrap, Version 12.0(4)XE RELEASE SOFTWARE router uptime is 20 hours, 34 minutes System restarted by reload at 22:36:57 PST Fri Dec 31 1999 System image file is "c7100-jos56i-mz" cisco 7140 (EGR) processor with 188416K/139264K bytes of memory. R7000 CPU at 262Mhz, Implementation 39, Rev 1.0, 256KB L2, 2048KB L3 Cache Last reset from power-on Bridging software. X.25 software, Version 3.0.0. SuperLAT software copyright 1990 by Meridian Technology Corp). TN3270 Emulation software. 3 FastEthernet/IEEE 802.3 interface(s) 2 Serial network interface(s) 125K bytes of non-volatile configuration memory. 40960K bytes of ATA PCMCIA card at slot 0 (Sector size 512 bytes). 8192K bytes of Flash internal SIMM (Sector size 256K). Configuration register is 0x0
Because preshared keys were specified as the authentication method for policy 1 in the "Configuring IKE Policies" section, (the policy that will also be used on the business partner router) complete the following steps at the headquarters router as well as the business partner router:
Step 2 Specify the shared keys at each peer. Note that a given preshared key is shared between two peers. At a given peer, you could specify the same key to share with multiple remote peers; however, a more secure approach is to specify different keys to share between different pairs of peers.
|
Note The following procedure is based on the "Extranet Scenario" section. |
| Command | Purpose | |
|---|---|---|
Step 1 | | At the local peer: Specify the shared key the headquarters router will use with the business partner router. This example configures the shared key test67890 to be used with the remote peer 172.23.2.7 (serial interface 1/0 on the business partner router). |
Step 2 | | At the remote peer: Specify the ISAKMP identity (address or hostname) the business partner router will use when communicating with the headquarters router during IKE negotiations. (This task was already completed on the headquarters router when policy 1 was configured in the "Configuring IKE Policies" section.) This example specifies the address keyword, which uses IP address 172.23.2.7 (serial interface 1/0 of the business partner router) as the identity for the business partner router. |
Step 3 | | At the remote peer: Specify the shared key to be used with the local peer. This is the same key you just specified at the local peer. This example configures the shared key test67890 to be used with the local peer 172.16.2.2 (serial interface 2/0 on the headquarters router). |
Crypto access lists are used to define which IP traffic will be protected by crypto and which traffic will not be protected by crypto. (These access lists are not the same as regular access lists, which determine what traffic to forward or block at an interface.) For example, you can create access lists to protect all IP traffic between the headquarters router and business partner router.
The access lists themselves are not specific to IPSec. It is the crypto map entry referencing the specific access list that defines whether IPSec processing is applied to the traffic matching a permit in the access list.
To create crypto a access list, enter the following command in global configuration mode:
| Command | Purpose |
|---|---|
| Specify conditions to determine which IP packets are protected.1 (Enable or disable crypto for traffic that matches these conditions.) This example configures access list 111 to encrypt all IP traffic between the headquarters Web server (translated inside global IP address 10.2.2.2) and PC B (IP address 10.1.5.3) in the business partner office. We recommend that you configure "mirror image" crypto access lists for use by IPSec and that you avoid using the any keyword. |
| 1You specify conditions using an IP access list designated by either a number or a name. The access-list command designates a numbered extended access list; the ip access-list extended command designates a named access list. |
To verify the configuration:
hq-sanjose# show access-lists 111
Extended IP access list 111
permit ip host 10.2.2.2 host 10.1.5.3
|
Tips If you have trouble, make sure you are specifying the correct access list number. |
If you have configured a GRE tunnel (described in the "Intranet Scenario" section), there is no need to configure IPSec tunnel mode. You must, however, define transform sets regardless of the tunneling protocol you use.
To define a transform set and configure IPSec tunnel mode, complete the following steps starting in global configuration mode:
| Command | Purpose | |
|---|---|---|
Step 1 | | Define a transform set and enter crypto-transform configuration mode. This example combines AH1 transform ah-sha-hmac, ESP2 encryption transform esp-des, and ESP authentication transform esp-sha-hmac in the transform set proposal4. There are complex rules defining which entries you can use for the transform arguments. These rules are explained in the command description for the crypto ipsec transform-set command. You can also use the crypto ipsec transform-set? command, in global configuration mode, to view the available transform arguments. |
Step 2 | | Change the mode associated with the transform set. The mode setting is only applicable to traffic whose source and destination addresses are the IPSec peer addresses; it is ignored for all other traffic. (All other traffic is in tunnel mode only.) This example configures tunnel mode for the transport set proposal4, which creates an IPSec tunnel between the IPSec peer addresses. |
Step 3 |
| Exit back to global configuration mode. |
| 1AH = authentication header. This header, when added to an IP datagram, ensures the integrity and authenticity of the data, including the invariant fields in the outer IP header. It does not provide confidentiality protection. AH uses a keyed-hash function rather than digital signatures. 2ESP = encapsulating security payload. This header, when added to an IP datagram, protects the confidentiality, integrity, and authenticity of the data. If ESP is used to validate data integrity, it does not include the invariant fields in the IP header. |
To verify the configuration:
hq-sanjose# show crypto ipsec transform-set
Transform set proposal4: { ah-sha-hmac }
will negotiate = { Tunnel, },
{ esp-des esp-sha-hmac }
will negotiate = { Tunnel, },
-Display text omitted-
For IPSec to succeed between two IPSec peers, both peers' crypto map entries must contain compatible configuration statements.
When two peers try to establish a security association (SA), they must each have at least one crypto map entry that is compatible with one of the other peer's crypto map entries. For two crypto map entries to be compatible, they must meet the following minimum criteria:
After you have completed configuring IPSec at each participating IPSec peer, configure crypto map entries and apply the crypto maps to interfaces. This section contains basic steps to configure crypto maps and includes the following tasks:
To create crypto map entries that will use IKE to establish the SAs, complete the following steps starting in global configuration mode:
| Command | Purpose | |
|---|---|---|
Step 1 | | Create the crypto map and specify a local address (physical interface) to be used for the IPSec traffic. This example creates crypto map s4second and specifies serial interface 2/0 of the headquarters router as the local address. This step is only required if you have previously used the loopback command or if you are using GRE tunnels. |
Step 2 | | Enter crypto map configuration mode, specify a sequence number for the crypto map you created in Step 1, and configure the crypto map to use IKE to establish SAs. This example configures sequence number 2 and IKE for crypto map s4second. |
Step 3 | | Specify an extended access list. This access list determines which traffic is protected by IPSec and which traffic is not be protected by IPSec. This example configures access list 111, which was created in the "Creating Crypto Access Lists" section. |
Step 4 | | Specify a remote IPSec peer (by host name or IP address). This is the peer to which IPSec protected traffic can be forwarded. This example specifies serial interface 1/0 (172.23.2.7) on the business partner router. |
Step 5 | | Specify which transform sets are allowed for this crypto map entry. List multiple transform sets in order of priority (highest priority first). This example specifies transform set proposal4, which was configured in the "Defining Transform Sets and Configuring IPSec Tunnel Mode" section. |
Step 6 |
| Exit back to global configuration mode. |
To verify the configuration:
hq-sanjose# show crypto map
Crypto Map: "s4second" idb: Serial2/0 local address: 172.16.2.2
Crypto Map "s4second" 2 ipsec-isakmp
Peer = 172.23.2.7
Extended IP access list 111
access-list 111 permit ip
source: addr = 10.2.2.2/255.255.255.0
dest: addr = 10.1.5.3/255.255.255.0S
Current peer: 172.23.2.7
Security-association lifetime: 4608000 kilobytes/3600 seconds
PFS (Y/N): N
Transform sets={proposal4,}
-Display text omitted-
|
Tips If you have trouble, make sure you are using the correct IP addresses. |
To apply a crypto map set to an interface, complete the following steps starting in global configuration mode:
| Command | Purpose | |||
|---|---|---|---|---|
Step 1 | | Specify a physical interface on which to apply the crypto map and enter interface configuration mode. This example specifies serial interface 2/0 on the headquarters router. | ||
Step 2 | | Apply the crypto map set to the physical interface. This example configures crypto map s4second, which was created in the "Creating Crypto Map Entries" section. | ||
Step 3 |
| Exit back to global configuration mode. | ||
Step 4 | | In privileged EXEC mode, clear the existing IPSec SAs so that any changes are used immediately. (Manually established SAs are reestablished immediately.)
|
To verify the configuration:
hq-sanjose# show crypto map interface serial 2/0Crypto Map "s4second" 2 ipsec-isakmpPeer = 172.23.2.7Extended IP access list 111access-list 111 permit ip host 10.2.2.2 host 10.1.5.3Current peer:172.23.2.7Security association lifetime:4608000 kilobytes/1000 secondsPFS (Y/N):NTransform sets={ proposal4, }
Cisco IOS quality of service (QoS) refers to the ability of a network to provide better service to selected network traffic over various underlying technologies including Frame Relay, Asynchronous Transfer Mode (ATM), Ethernet and 802.1 networks, SONET, and IP-routed networks. In particular, QoS features provide better and more predictable network service by:
You configure QoS features throughout a network to provide for end-to-end QoS delivery. The following three components are necessary to deliver QoS across a heterogeneous network:
Not all QoS techniques are appropriate for all network routers. Because edge routers and backbone routers in a network do not necessarily perform the same operations, the QoS tasks they perform might differ as well.
In general, edge routers perform the following QoS functions:
In general, backbone routers perform the following QoS functions:
Cisco IOS QoS service models, features, and sample configurations are explained in detail in the Quality of Service Solutions Configuration Guide and the Quality of Service Solutions Command Reference. Refer to these two publications as you plan and implement a QoS strategy for your VPN, because there are various QoS service models and features that you can implement on your VPN.
This section contains basic steps to configure QoS weighted fair queuing (WFQ), which applies priority (or weights) to identified traffic on the GRE tunnel you configured in the "Step 1Configuring the Tunnel" section. This section also contains basic steps to configure Network-Based Application Recognition (NBAR), which is a classification engine that recognizes a wide variety of applications, including web-based and other protocols that utilize dynamic TCP/UDP port assignments. This section includes the following tasks:
Network-Based Application Recognition (NBAR) adds intelligent network classification to network infrastructures. NBAR is a classification engine that recognizes a wide variety of applications, including web-based and other protocols that utilize dynamic TCP/UDP port assignments. When an application is recognized and classified by NBAR, a network can invoke services for that specific application. NBAR ensures that network bandwidth is used efficiently by working with QoS features
Your interface to NBAR is through the Modular QoS Command Line Interface (MQC). MQC provides a model for QoS configuration under IOS. MQC provides a clean separation between the specification of a classification policy and the specification of other policies that act based on the results of the applied classification.
Configuring a QoS policy typically requires the configuration of traffic classes, the configuration of policies that will be applied to those traffic classes, and the attaching of policies to interfaces using the following commands:
The following tasks are required to configure NBAR:
|
Note You must enable Cisco Express Forwarding (CEF) before you configure NBAR. For more information on CEF, refer to the Cisco IOS Release 12.0 configuration guide titled Cisco IOS Switching Services Configuration Guide. |
Use the class-map configuration command to define a traffic class and the match criteria that will be used to identify traffic as belonging to that class. Match statements can include criteria such as protocol, ACL, IP precedence value, or interface identifier. The match criteria is defined with one or more of the match statements entered within the class-map configuration mode listed in the table below:
| Command | Purpose | |
|---|---|---|
Step 1 | Router(config)# class-map match-all | match-any class-name | Specifies the user-defined name of the class map. The match-all option specifies that all match criteria in the class map must be matched. The match-any option specifies that one or more match criteria must match.1 |
Step 2 | Router(config-cmap)# match protocol protocol-name | Specifies a protocol supported by NBAR as a matching criteria. |
Step 3 | Router(config-cmap)# match class-map class-name | Specifies a class map as a matching criteria (nested class maps). |
| 1When neither match-all nor match-any is specified, the default is match-all. Use the no class-map command to disable the class map. Use the no match-all and no match-any commands to disable these commands within the class map. Use the match not command to configure a match that evaluates to true if the packet does not match the specified protocol. |
Enter the show class-map command to display all class map information. You can also enter the show class-map class-name command to displays the class map information of a user specified class map.
Use the policy-map configuration command to specify the QoS policies to apply to traffic classes defined by a class map. QoS policies that can be applied to traffic classification are listed in the table below.
| Command | Purpose | |
|---|---|---|
Step 1 | Router(config)# policy-map policy-name | User specified policy map name. |
Step 2 | Router(config-pmap)# class class-name | Specifies the name of a previously defined class map. |
Step 3 | Router(config-pmap-c)# bandwidth kbps | Specifies a minimum bandwidth guarantee to a traffic class. |
Step 4 | Router(config-pmap-c)# police bps conform transmit exceed drop | Specifies a maximum bandwidth usage by a traffic class. |
Step 5 | Router(config-pmap-c)# set ip precedence {0-7} | Specifies the IP precedence of packets within a traffic class. |
Step 6 | outer(config-pmap-c)# set qos-group {0-99} | Specifies a QoS-group value to associate with the packet. |
Step 7 | Router(config-pmap-c)# random-detect | Enables weighted random early detection (WRED) drop policy for a traffic class which has a bandwidth guarantee. |
Step 8 | Router(config-pmap-c)# queue-limit packets | Specifies maximum number of packets queued for a traffic class (in the absence of random-detect). |
Use the no policy-map command to deconfigure the policy map. Use the no bandwidth, no police, no set, and no random-detect commands to disable these commands within the policy map.
Use the service-policy interface configuration command to attach a policy map to an interface and to specify the direction in which the policy should be applied (on either packets coming into the interface or packets leaving the interface).
| Command | Purpose | |
|---|---|---|
Step 1 | Router(config-if)# service-policy output policy-map-name | Specifies the name of the policy map to be attached to the output direction of the interface. |
Step 2 | Router(config-if)# service-policy input policy-map-name | Specifies the name of the policy map to be attached to the input direction of the interface. |
Use the no service-policy [input | output] policy-map-name command to detach a policy map from an interface.
| Command | Purpose |
|---|---|
Router# show policy-map | Displays all configured policy maps. |
Router# show policy-map policy-map-name | Displays the user-specified policy map. |
Router# show policy-map interface | Displays statistics and configurations of all input and output policies, which are attached to an interface. |
Router# show policy-map interface-spec | Displays configuration and statistics of the input and output policies attached to a particular interface. |
Router# show policy-map interface-spec[input] | Displays configuration and statistics of the input policy attached to an interface. |
Router# show policy-map interface-spec[output] | Displays configuration statistics of the output policy attached to an interface. |
Router# show policy-map interface-spec[input|output] class class-name | Displays the configuration and statistics for the class name configured in the policy. |
When WFQ is enabled for an interface, new messages for high-bandwidth traffic streams are discarded after the configured or default congestive messages threshold has been met. However, low-bandwidth conversations, which include control message conversations, continue to enqueue data. As a result, the fair queue may occasionally contain more messages than its configured threshold number specifies.
| Command | Purpose | |
|---|---|---|
Step 1 | | Specify an interface and enter interface configuration mode. This example specifies serial interface 1/0 on the headquarters router. |
Step 2 | | Configure fair queuing on the interface. |
Step 3 |
| Exit back to global configuration mode. |
To verify the configuration:
hq-sanjose# show interfaces serial 1/0 fair-queue Serial1/0 queue size 0 packets output 35, drops 0 WFQ: global queue limit 401, local queue limit 200
hq-sanjose# show interfaces serial 1/0
Serial1/0 is up, line protocol is up
Hardware is M2T-T3 pa
-Display text omitted-
Queueing strategy:weighted fair
Output queue:0/1000/64/0 (size/max total/threshold/drops)
Conversations 0/0/256 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated)
-Display text omitted-
Class-based weighted fair queueing (CBWFQ) extends the standard WFQ functionality to provide support for user-defined traffic classes. For CBWFQ, you define traffic classes based on match criteria including protocols, access control lists (ACLs), and input interfaces. Packets satisfying the match criteria for a class constitute the traffic for that class. A queue is reserved for each class, and traffic belonging to a class is directed to that class's queue.
Once a class has been defined according to its match criteria, you can assign it characteristics. To characterize a class, you assign it bandwidth, weight, and maximum packet limit. The bandwidth assigned to a class is the minimum bandwidth delivered to the class during congestion.
To characterize a class, you also specify the queue limit for that class, which is the maximum number of packets allowed to accumulate in the class's queue. Packets belonging to a class are subject to the bandwidth and queue limits that characterize the class.
After a queue has reached its configured queue limit, enqueuing of additional packets to the class causes tail drop or packet drop to take effect, depending on how class policy is configured.
Tail drop is used for CBWFQ classes unless you explicitly configure policy for a class to use weighted random early detection (WRED) to drop packets as a means of avoiding congestion. Note that if you use WRED packet drop instead of tail drop for one or more classes comprising a policy map, you must ensure that WRED is not configured for the interface to which you attach that service policy.
|
Note Although CBWFQ supports the use of WRED, this guide does not include WRED configuration procedures. For more information on using WRED with CBWFQ, refer to the Cisco IOS Release 12.0 Configuration Guide Master Index. To access this document, go to http://www.cisco.com/ and select the following links: Technical Documents: Cisco Product Documentation: Cisco IOS Software Configuration: Cisco IOS Release 12.0 Master Indexes: Configuration Guide Master Index. |
If a default class is configured, all unclassified traffic is treated as belonging to the default class. If no default class is configured, then by default the traffic that does not match any of the configured classes is flow classified and given best-effort treatment. Once a packet is classified, all of the standard mechanisms that can be used to differentiate service among the classes apply.
Flow classification is standard WFQ treatment. That is, packets with the same source IP address, destination IP address, source Transmission Control Protocol (TCP) or User Datagram Protocol (UDP) port, or destination TCP or UDP port are classified as belonging to the same flow. WFQ allocates an equal share of bandwidth to each flow. Flow-based WFQ is also called fair queueing because all flows are equally weighted.
For CBWFQ, which extends the standard WFQ, the weight specified for the class becomes the weight of each packet that meets the match criteria of the class. Packets that arrive at the output interface are classified according to the match criteria filters you define, then each one is assigned the appropriate weight.
The weight for a packet belonging to a specific class is derived from the bandwidth you assigned to the class when you configured it; in this sense the weight for a class is user-configurable.
After a packet's weight is assigned, the packet is enqueued in the appropriate class queue. CBWFQ uses the weights assigned to the queued packets to ensure that the class queue is serviced fairly.
The following tasks are required to configure CBWFQ:
|
Note Attaching a service policy to an interface disables WFQ on that interface if WFQ is configured for the interface. For this reason, you should ensure that WFQ is not enabled on such an interface. For additional information on WFQ, see the "Configuring Weighted Fair Queueing" chapter of the Cisco IOS Release 12.0 Quality of Service Solutions Configuration Guide. |
To create a class map containing match criteria against which a packet is checked to determine if it belongs to a class, and to effectively create the class whose policy can be specified in one or more policy maps, use the first command in global configuration mode to specify the class-map name. Then use one of the following commands in class-map configuration mode:
| Command | Purpose | |
|---|---|---|
Step 1 |
| Specifies the name of the class map to be created. |
Step 2 | | Specifies the name of the numbered ACL against whose contents packets are checked to determine if they belong to the class. |
Step 3 |
| Specifies the name of the output interface used as a match criterion against which packets are checked to determine if they belong to the class. |
Step 4 | | Specifies the name of the protocol used as a match criterion against which packets are checked to determine if they belong to the class. |
To configure a policy map and create class policies (including a default class) comprising the service policy, use the first global configuration command to specify the policy-map name. Then use the following policy-map configuration commands to configure policy for a standard class and the default class. For each class that you define, you can use one or more of the following policy-map configuration commands to configure class policy. For example, you might specify bandwidth for one class and both bandwidth and queue limit for another class.
The policy-map default class is the class to which traffic is directed if that traffic does not satisfy the match criteria of other classes whose policy is defined in the policy map. To configure policy for more than one class in the same policy map, repeat Steps 2 through 4. Note that because this set of commands uses queue-limit, the policy map uses tail drop for both class policies, not WRED packet drop.
To attach a service policy to an interface and enable CBWFQ on the interface, you must create a policy map. You can configure class policies for as many classes as are defined on the router up to the maximum of 64.
| Command | Purpose | |
|---|---|---|
Step 1 | | Specifies the name of the policy map to be created or modified. |
Step 2 | hq-sanjose(config-pmap)# class class-name | Specifies the name of a class to be created and included in the service policy. |
Step 3 | | Specifies the amount of bandwidth in kilobits per second (kbps) to be assigned to the class. |
Step 4 | | Specifies the maximum number of packets that can be enqueued for the class. |
Step 5 |
| Specifies the default class in order to configure its policy. |
Step 6 |
| Specifies the amount of bandwidth in kilobits per second to be assigned to the default class. |
Step 7 |
| Specifies the maximum number of packets that can be enqueued for the specified default class. |
To attach a service policy to the output interface and enable CBWFQ on the interface, use the interface configuration command in the following table:.
| Command | Purpose |
|---|---|
| Enables CBWFQ and attaches the specified service policy map to the output interface. |
|
Note When CBWFQ is enabled, all classes configured as part of the service policy map are installed in the fair queueing system. |
To display the contents of a specific policy map, a specific class from a specific policy map, or all policy maps configured on an interface, use one of the following global configuration commands:
| Command | Purpose |
|---|---|
| Displays the configuration of all classes comprising the specified policy map. |
| Displays the configuration of the specified class of the specified policy map. |
| Displays the configuration of all classes configured for all policy maps on the specified interface. |
Cisco IOS software provides an extensive set of security features with which you can configure a simple or elaborate firewall, according to your particular requirements. When you configure Cisco IOS firewall features on your Cisco router, you turn your router into an effective, robust firewall.
Cisco IOS firewall features are designed to prevent unauthorized, external individuals from gaining access to your internal network, and to block attacks on your network, while at the same time allowing authorized users to access network resources.
|
Note The Cisco Secure PIX Firewall can be used an an alternative to Cisco IOS firewall features. For detailed information on the Cisco Secure PIX Firewall, refer to the Cisco Secure PIX Firewall documentation located on Cisco Connection Online (CCO). To access these documents, go to http://www.cisco.com/ and select the following links: Technical Documents: Cisco Product Documentation: Internet Service Unit (ISU) Documentation: PIX Firewall. |
|
Note Although Cisco 7100 series routers support intrusion detection features, intrusion detection configuration procedures are not explained in this guide. For detailed information on intrusion detection, refer to the Intrusion Detection Planning Guide. To access this document, go to http://www.cisco.com/ and select the following links: Technical Documents: Cisco Product Documentation: Internet Service Unit (ISU) Documentation: Intrusion Detection Planning Guide. |
You can use Cisco IOS firewall features to configure your Cisco IOS router as:
Cisco IOS firewall features provide the following benefits:
|
Note Refer to the "Traffic Filtering and Firewalls" part of the Security Configuration Guide and the Security Command Reference for advanced firewall configuration information. To access these documents, go to http://www.cisco.com/ and select the following links: Technical Documents: Cisco Product Documentation: Cisco IOS Software Configuration: Cisco IOS Release 12.0: Configuration Guides and Command References: |
This section explains how to configure an extended access list, which is a sequential collection of permit and deny conditions that apply to an IP address, and includes the following tasks:
|
Note The extended access list configuration explained in this section is different from the crypto access list configuration explained in the "Creating Crypto Access Lists" section. Crypto access lists are used to define which IP traffic is or is not protected by crypto, while an extended access list is used to determine which IP traffic to forward or block at an interface. |
The simplest connectivity to the Internet is to use a single device to provide the connectivity and firewall function to the Internet. With everything being in a single device, it is easy to address translation and termination of the VPN tunnels. Complexity arises when you need to add extra VPN gateways to the network. This normally leads people into building a network where the corporate network touches the Internet through a network called the DMZ, or demilitarized zone.
To create an extended access list that denies and permits certain types of traffic, complete the following steps starting in global configuration mode:
| Command | Purpose | |
|---|---|---|
Step 1 | | Define access list 102 and configure the access list to deny all TCP traffic. |
Step 2 | | Configure access list 102 to deny all UDP traffic. |
Step 3 | | Configure access list 102 to permit all IP traffic. |
To verify the configuration:
hq-sanjose# show access-list 102
Extended IP access list 102
deny tcp any any
deny udp any any
permit ip any any
To apply an access list inbound and outbound on an interface, complete the following steps starting in global configuration mode:
| Command | Purpose | |
|---|---|---|
Step 1 | | Specify serial interface 1/0 on the headquarters router and enter interface configuration mode. |
Step 2 | | Configure access list 102 inbound on serial interface 1/0 on the headquarters router. |
Step 3 | | Configure access list 102 outbound on serial interface 1/0 on the headquarters router. |
Step 4 |
| Exit back to global configuration mode. |
For outbound access lists, after receiving and routing a packet to a controlled interface, the software checks the destination address of the packet against the access list. If the access list permits the address, the software transmits the packet. If the access list rejects the address, the software discards the packet and returns an "ICMP Host Unreachable" message.
When you apply an access list that has not yet been defined to an interface, the software acts as if the access list has not been applied to the interface and will accept all packets. Be aware of this behavior if you use undefined access lists as a means of security in your network.
To verify the configuration:
hq-sanjose# show ip interface serial 1/0 Serial1/0 is up, line protocol is up Internet address is 172.17.2.4 Broadcast address is 255.255.255.255 Address determined by setup command Peer address is 172.24.2.5 MTU is 1500 bytes Helper address is not set Directed broadcast forwarding is disabled Outgoing access list is 102 Inbound access list is 102 -Display text omitted-
|
Tips If you have trouble, ensure that you specified the correct interface when you applied the access list. |
Following are comprehensive sample configurations for the intranet and extranet scenarios.
The following sample configuration is based on the physical elements shown in Figure 3-8:
hq-sanjose# show running-config Building configuration... Current configuration: ! version 12.0 service timestamps debug uptime service timestamps log uptime no service password-encryption ! hostname hq-sanjose ! boot system flash bootflash: boot bootldr bootflash:c7100-boot-mz.120-1.1.T boot config slot0:hq-sanjose-cfg-small no logging buffered ! crypto isakmp policy 1 authentication pre-share lifetime 84600 crypto isakmp key test12345 address 172.24.2.5 ! crypto ipsec transform-set proposal1 ah-sha-hmac esp-des esp-sha-hmac mode transport ! ! crypto map s1first local-address Serial1/0 crypto map s1first 1 ipsec-isakmp set peer 172.24.2.5 set transform-set proposal1 match address 101 ! interface Tunnel0 bandwidth 180 ip address 172.17.3.3 255.255.255.0 no ip directed-broadcast tunnel source 172.17.2.4 tunnel destination 172.24.2.5 crypto map s1first ! interface FastEthernet0/0 ip address 10.1.3.3 255.255.255.0 no ip directed-broadcast no keepalive full-duplex no cdp enable ! interface FastEthernet0/1 ip address 10.1.6.4 255.255.255.0 no ip directed-broadcast no keepalive full-duplex no cdp enable ! interface Serial1/0 ip address 172.17.2.4 255.255.255.0 no ip directed-broadcast no ip mroute-cache no keepalive fair-queue 64 256 0 framing c-bit cablelength 10 dsu bandwidth 44210 clock source internal no cdp enable crypto map s1first ! ip route 10.1.4.0 255.255.255.0 Tunnel0 ! access-list 101 permit gre host 172.17.2.4 host 172.24.2.5 ! line con 0 transport input none line aux 0 line vty 0 4 login ! end
ro-rtp# show running-config Building configuration... Current configuration: ! version 12.0 service timestamps debug uptime service timestamps log uptime no service password-encryption ! hostname ro-rtp ! boot system flash bootflash: boot bootldr bootflash:c7100-boot-mz.120-1.1.T boot config slot0:ro-rtp-cfg-small no logging buffered ! crypto isakmp policy 1 authentication pre-share lifetime 84600 crypto isakmp key test12345 address 172.17.2.4 ! crypto ipsec transform-set proposal1 ah-sha-hmac esp-des esp-sha-hmac mode transport ! ! crypto map s1first local-address Serial1/0 crypto map s1first 1 ipsec-isakmp set peer 172.17.2.4 set transform-set proposal1 match address 101 ! interface Tunnel1 bandwidth 180 ip address 172.24.3.6 255.255.255.0 no ip directed-broadcast tunnel source 172.24.2.5 tunnel destination 172.17.2.4 crypto map s1first ! interface FastEthernet0/0 ip address 10.1.4.2 255.255.255.0 no ip directed-broadcast no keepalive full-duplex no cdp enable ! interface Serial1/0 ip address 172.24.2.5 255.255.255.0 no ip directed-broadcast no ip mroute-cache no keepalive fair-queue 64 256 0 framing c-bit cablelength 10 dsu bandwidth 44210 clock source internal no cdp enable crypto map s1first ! ip route 10.1.3.0 255.255.255.0 Tunnel1 ip route 10.1.6.0 255.255.255.0 Tunnel1 ! access-list 101 permit gre host 172.24.2.5 host 172.17.2.4 ! line con 0 transport input none line aux 0 line vty 0 4 login ! end
The following sample configuration is based on the physical elements shown in Figure 3-9:
hq-sanjose# show running-config Building configuration... Current configuration: ! version 12.0 service timestamps debug uptime service timestamps log uptime no service password-encryption ! hostname hq-sanjose ! boot system flash bootflash: boot bootldr bootflash:c7100-boot-mz.120-1.1.T boot config slot0:hq-sanjose-cfg-small no logging buffered ! crypto isakmp policy 1 authentication pre-share lifetime 84600 crypto isakmp key test12345 address 172.24.2.5 crypto isakmp key test67890 address 172.23.2.7 ! crypto ipsec transform-set proposal1 ah-sha-hmac esp-des esp-sha-hmac mode transport ! crypto ipsec transform-set proposal4 ah-sha-hmac esp-des esp-sha-hmac ! ! crypto map s1first local-address Serial1/0 crypto map s1first 1 ipsec-isakmp set peer 172.24.2.5 set transform-set proposal1 match address 101 ! crypto map s4second local-address Serial2/0 crypto map s4second 2 ipsec-isakmp set peer 172.23.2.7 set transform-set proposal4 match address 111 ! interface Tunnel0 bandwidth 180 ip address 172.17.3.3 255.255.255.0 no ip directed-broadcast tunnel source 172.17.2.4 tunnel destination 172.24.2.5 crypto map s1first ! interface FastEthernet0/0 ip address 10.1.3.3 255.255.255.0 no ip directed-broadcast no keepalive full-duplex no cdp enable ! interface FastEthernet0/1 ip address 10.1.6.4 255.255.255.0 no ip directed-broadcast ip nat inside no keepalive full-duplex no cdp enable ! interface Serial1/0 ip address 172.17.2.4 255.255.255.0 no ip directed-broadcast no ip mroute-cache no keepalive fair-queue 64 256 0 framing c-bit cablelength 10 dsu bandwidth 44210 clock source internal no cdp enable crypto map s1first ! interface Serial2/0 ip address 172.16.2.2 255.255.255.0 no ip directed-broadcast ip nat outside no ip mroute-cache no keepalive fair-queue 64 256 0 framing c-bit cablelength 10 dsu bandwidth 44210 clock source internal no cdp enable crypto map s4second ! router bgp 10 network 10.2.2.2 mask 255.255.255.0 network 172.16.2.0 mask 255.255.255.0 ! ip route 10.1.4.0 255.255.255.0 Tunnel0 ! ip nat inside source static 10.1.6.5 10.2.2.2 ! access-list 101 permit gre host 172.17.2.4 host 172.24.2.5 access-list 111 permit ip host 10.2.2.2 host 10.1.5.3 ! line con 0 transport input none line aux 0 line vty 0 4 login ! end
bus-ptnr# show running-config Building configuration... Current configuration: ! version 12.0 service timestamps debug uptime service timestamps log uptime no service password-encryption ! hostname bus-ptnr ! boot system flash bootflash: boot bootldr bootflash:c7100-boot-mz.120-1.1.T boot config slot0:bus-ptnr-cfg-small no logging buffered ! crypto isakmp policy 1 authentication pre-share lifetime 84600 crypto isakmp key test67890 address 172.16.2.2 ! crypto ipsec transform-set proposal4 ah-sha-hmac esp-des esp-sha-hmac ! ! crypto map s4second local-address Serial1/0 crypto map s4second 2 ipsec-isakmp set peer 172.16.2.2 set transform-set proposal4 match address 111 ! interface FastEthernet0/0 ip address 10.1.5.2 255.255.255.0 no ip directed-broadcast no keepalive full-duplex no cdp enable ! interface Serial1/0 ip address 172.23.2.7 255.255.255.0 no ip directed-broadcast no ip mroute-cache no keepalive fair-queue 64 256 0 framing c-bit cablelength 10 dsu bandwidth 44210 clock source internal no cdp enable crypto map s4second ! router bgp 10 network 10.1.5.0 mask 255.255.255.0 network 172.16.2.0 mask 255.255.255.0 ! access-list 111 permit ip host 10.1.5.3 host 10.2.2.2 ! line con 0 transport input none line aux 0 line vty 0 4 login ! end
Posted: Thu Jun 29 13:41:49 PDT 2000
Copyright 1989 - 2000©Cisco Systems Inc.