This chapter discusses the challenges and unique service requirements of connecting branch sites to central sites. Specifically, the focus is on the routing requirements of branch offices and mobile workers.
Planning the Branch Office Implementation
This section describes the fundamentals of branch office implementation such as design, security concerns, and scalability.
Branch Office Design
There are common requirements that every branch network design needs to address. Connectivity, security, availability, voice, and application optimization requirements impact the branch office design and must be considered. The challenges when addressing these requirements include the following:
-
Bandwidth and network requirements— Increasing bandwidth and network requirements are driven by a unified service network, transporting video, voice, and data, and supporting mission critical functions and applications.
-
Consolidated data centers— Rather than operating local data servers at the branch, information is consolidated at a central local. A primary goal with this consolidation is to gain centralized security and management control, to comply with corporate governance mandates driven in part by government and industry regulations.
-
Mobility— The dispersion of the staff coupled with the consolidation of the IT resources has resulted is a significant WAN load as distant users compete for access across the WAN. Not addressing the issue of the consolidated data center, coupled with users’ mobility, has left legacy branch offices with poor application response time and therefore disgruntled users.
-
Disparate networks— Branch offices that are built in isolation tend to run aging and separate voice and data networks, which do not benefit from the use of collaborative communications applications hosted in IP call servers. Different circuit-switched private branch exchanges (PBXs) from different vendors might exist at various branch office sites, each with its own feature set, proprietary technology, and special operational requirements.
-
Management costs— Generally as branch office sites develop, often without much strategic thought given to future requirements, equipment and services are added to solve specific problems. The result then is a patchwork of network devices in which branch offices often have very different equipment and architectures. For this reason, branch offices are often extremely costly to manage and troubleshoot. In addition, rolling out new services across inconsistent branch office infrastructures is extremely difficult.
Meeting the preceding challenges demands a formal branch office strategy and deployment plan. For this reason, network designers must consider a multidimensional approach to branch design. If we look at these scoping and profiling considerations, they all align to a structured approach that should consider specific areas. Presuming that our objective here is to implement routing facilities for the branch, we will consider how these areas affect the routing design. The considerations are shown in Figure 7-1.
Bandwidth and service availability are largely based on the choices of access and connectivity technologies. Technologies such as digital subscriber line (DSL) and cable usually provide dynamic IP addressing, and therefore a default route is created at the moment of connection. Virtual private networks (VPNs) are created using technologies such as IPsec. However, IPsec does not support dynamic routing protocols, and therefore complementary technologies such as generic routing encapsulation (GRE) should be considered.
Resiliency considerations will typically result in alternative paths to the central location and other branches, and this will impact your choice of routing tools. Your choice of routing protocol is important because it will impact routing convergence, backup routes, load sharing, and so on. In your evaluation of which routing protocol is best suited for your organization, you might consider specific features of Enhanced Interior Gateway Routing Protocol (EIGRP) such as unequal-cost load balancing or stub routing. Otherwise, you might want to control convergence or scalability issues using the multi-area Open Shortest Path First (OSPF) routing protocol.
The traffic and service mix will also have an impact in routing facilities. In deploying branch services, the deployment plan should consider features such as Network Address Translation (NAT), quality of service (QoS), access control lists (ACLs), and WAN optimization.
Other considerations include security and mobility requirements. Now the branch is not only connecting to a central office for service delivery, but also serving as a connectivity hub for mobile users, in their quest for those services. Each user now becomes a new destination that has to be dealt with.
When deploying branch services, one must consider how the following trends and considerations affect the implementation plan:
-
Consolidation
-
Integration
-
High availability
-
VPNs as a WAN option
-
Operational consistency
Data center and branch consolidation is a transforming trend, which results in the branch being seemingly stripped off multiple services that used to be deployed locally at the branch. The remote node is therefore called a thin branch. This approach has no impact on end-user productivity.
However, some of those services are now being deployed in integrated network elements, like Cisco integrated services routers (ISRs). The main result is that implementation plans need to include verification steps to identify services and their impact in the deployment and upgrade of branch routing services. Following is a list of some services that may be deployed on branch routers:
-
Voice
-
Application firewall
-
Intrusion prevention
-
Virtual private network
-
WAN optimization
-
Wireless
-
WAN backup
Therefore, ISRs enable businesses to reduce costs by deploying a single, resilient system for fast, secure delivery of multiple mission-critical business services, including data, voice, security, and wireless.
| Note | Cisco Systems has recently introduced a new branch architecture solution called the Cisco Borderless Network Architecture. This new architecture empowers IT to efficiently manage access from multiple locations, from multiple devices, and to applications that can be located anywhere. It provides the framework to unify wired and wireless access, including security, access control and performance management across many different device types and is based on the new generation of Cisco Integrated Services Router routers (ISR G2). For more information, see http://cisco.com/en/US/netsol/ns1015/. |
Other transforming trends include the increasing use of technologies that facilitate high availability, scalability and resiliency. Solutions such as Multiprotocol Label Switching (MPLS) VPNs and Internet VPNs, using IPsec, bring with them many benefits but also challenges and complexity in branch routing. You may now have to peer with service providers as part of your interior gateway protocol (IGP) configuration, or perhaps not be able to run an IGP across your VPN at all without configuring additional features.
Ultimately, operational consistency is a critical business requirement. The service- and business-ready branch will require a structured approach to configuration and change management, to provide management scalability and reduced costs.
When we are discussing an enterprise network, it is important to consider that most networks are built from a discreet set of interconnected, architectural elements, seen in Figure 7-2, each of which has its own requirements. A branch office, for example, may not have the same scalability requirements as a data center, but has a greater need for reduced form-factor devices with high-value integrated services.
For the branch office in particular, it is essential to follow an established framework to ensure the best possible user experience in all locations. Because each location type has its specific needs and challenges, using a “place-in-the-network” framework is crucial to providing the best solutions for each location. So, you are more likely to see a deployment scenario where VPN is the main link for a branch office in a small branch scenario. You will also see static routes most likely. In a regional office, you would probably see a primary and backup links, with routing protocols selecting the best path. In a campus network, you will see a lot more redundancy and availability scenario with dual-edge routers and redundancy solutions such as Hot Standby Router Protocol (HSRP).
Upgrade Scenario
The objective in this chapter is to demonstrate some of the branch office features following a specific scenario. The scenario is that of a hub-and-spoke branch connectivity deployment. Initially, only one hub and basic services are in place. The branches reach the rest of the network via default routes injected via EIGRP through a private WAN using dedicated links. The hub device, our headquarters router, routes to the branches using EIGRP as routing protocol, and there is currently no redundancy to allow for a more resilient branch architecture. The branch site also provides basic services, including Dynamic Host Configuration Protocol (DHCP) and Network Address Translation (NAT). Figure 7-3 illustrates the original topology.
To illustrate the considerations and trends previously introduced, we will upgrade the branch using IPsec VPN connectivity as shown in Figure 7-4. We will also discover how services such as can impact the network design. Finally, we will test how both the WAN link and the IPsec VPN link can use the EIGRP unequal load-balancing feature.
Implementation Plan
To accomplish the branch office upgrade, we will use a specific implementation plan that will include configurations at both the branch and the headquarters routers, as follows:
We will now take a look at a sample configuration of a branch upgrade. Note that this implementation is not exhaustive and other solutions could also be applied. For example, many other connectivity solutions are available such as Frame Relay, Asynchronous Transfer Mode (ATM), MPLS VPNs, and dedicated leased lines and each with their own unique advantages and disadvantages. The following is to serve as a guide and as just one possible solution to routing to a branch site.
| Note | The specifics of remote-access technologies and of IPsec configuration are beyond the scope of this book. Assume that the Internet team has configured the details of the remote connectivity, including IPsec. Our task, as members of the routing team, is to tune the router for the packets to be translated and routed properly. |
Deploying Broadband Connectivity
Focusing on our upgrade objective, shown in Figure 7-4, let’s now consider the first step of our implementation plan: broadband connectivity.
Branch offices typically use diverse applications (for example, e-mail, web-based applications, mission-critical applications, real-time collaboration, voice, video, and videoconferencing) that require high-bandwidth connections. The choice of access network technology and suitable bandwidth should be the first consideration addressed when connecting branch and small office/home office (SOHO) environments.
Broadband technologies provide always on access which can support enhanced voice and video services. It is often referred to as high-speed access to the Internet because it refers to any connection of 256 Kbps or greater. This can include many different connection options, including the following:
-
Satellite broadband is offered by satellite service providers. The computer connects through Ethernet to a satellite modem that transmits radio signals to the nearest point of presence (POP) within the satellite network.
-
Broadband cable access is offered by cable television service providers. The Internet signal is carried on the same coaxial cable that delivers cable television. A special cable modem separates the Internet signal from the other signals carried on the cable and provides an Ethernet connection to a host computer or LAN.
-
Digital subscriber line (DSL) uses telephone lines, but unlike dialup access, DSL provides a continuous connection to the Internet. DSL uses a special high-speed modem that separates the DSL signal from the telephone signal and provides an Ethernet connection to a host computer or LAN.
| Note | The choice of broadband connectivity is ultimately affected by what is available locally, the cost of the link, and the data and voice requirements of the business. As well, broadband access technologies may not provide the most secure connections which is why they are often combined with IPsec or SSL VPNs. |
The following subsections examine these three broadband technologies.
Satellite Broadband Information
New developments in broadband wireless technology are increasing wireless availability. These new developments include the following:
-
Municipal Wi-Fi
-
WiMAX
-
Satellite Internet
Municipal governments have also joined the Wi-Fi revolution. Often working with service providers, cities are deploying municipal wireless networks. Some of these networks provide high-speed Internet access at no cost or for substantially less than the price of other broadband services. Other cities reserve their Wi-Fi networks for official use, providing police, firefighters, and city workers remote access to the Internet and municipal networks.
Most municipal wireless networks use a mesh topology rather than a hub-and-spoke model. A mesh is a series of access points (radio transmitters), as shown in the Figure 7-5.
Each access point is in range and can communicate with at least two other access points. The mesh blankets its area with radio signals. Signals travel from access point to access point through this cloud.
A meshed network has several advantages over single router hotspots. Installation is easier and can be less expensive because there are fewer wires. Deployment over a large urban area is faster. From an operational point of view, it is more reliable. If a node fails, others in the mesh compensate for it.
WiMAX (Worldwide Interoperability for Microwave Access) is telecommunications technology aimed at providing wireless data over long distances in a variety of ways, from point-to-point links to full mobile cellular type access. WiMAX operates at higher speeds, over greater distances, and for a greater number of users than Wi-Fi. Because of its higher speed (bandwidth) and falling component prices, it is predicted that WiMAX will soon supplant municipal mesh networks for wireless deployments.
As shown in Figure 7-6, a WiMAX network consists of two main components:
-
A tower that is similar in concept to a cellular telephone tower. A single WiMAX tower can provide coverage to an area as large as 3000 square miles, or almost 7500 square kilometers.
-
A WiMAX receiver that is similar in size and shape to a PCMCIA card, or built in to a laptop or other wireless device.
A WiMAX tower station connects directly to the Internet using a high-bandwidth connection (for example, a T3 line). A tower can also connect to other WiMAX towers using line-of-sight microwave links. WiMAX is thus able to provide coverage to rural areas out of reach of “last mile” cable and DSL technologies.
Satellite Internet services are used in locations where land-based Internet access is not available, or for temporary installations that are continually on the move. Internet access using satellites is available worldwide, including for vessels at sea, airplanes in flight, and vehicles moving on land.
There are three ways to connect to the Internet using satellites:
-
One-way multicast satellite Internet systems are used for IP multicast-based data, audio, and video distribution. Even though most IP protocols require two-way communication, for Internet content, including web pages, one-way satellite-based Internet services can be information which is “pushed” to end-user sites by satellite Internet. Full interactivity is not possible.
-
One-way terrestrial return satellite Internet systems use traditional dialup access to send outbound data through a modem and receive downloads from the satellite.
-
Two-way satellite Internet sends data from remote sites via satellite to a hub, which then sends the data to the Internet. The satellite dish at each location needs precise positioning to avoid interference with other satellites.
Figure 7-7 illustrates a two-way satellite Internet system. Upload speeds are about one-tenth of the download speed, which is in the range of 500 kpbs.
The key installation requirement is for the antenna to have a clear view toward the equator, where most orbiting satellites are stationed. Trees and heavy rains can affect signal reception.
Two-way satellite Internet uses IP multicasting technology, which allows one satellite to serve up to 5000 communication channels simultaneously. IP multicast sends data from one point to many points at the same time by sending data in a compressed format. Compression reduces the size of the data and the bandwidth required.
Cable Background Information
Accessing the Internet through a cable network is a popular option used by teleworkers to access enterprise networks. Although this solution still is not popular for connecting branch sites, it should nonetheless be considered as the technology matures.
The cable system uses a coaxial cable that carries radio frequency (RF) signals across the network. Coaxial cable is the primary medium used to build cable TV systems.
Most cable operators use satellite dishes to gather TV signals. Early systems were one way, with cascading amplifiers placed in series along the network to compensate for signal loss. These systems used taps to couple video signals from the main trunks to subscriber homes via drop cables.
Modern cable systems provide two-way communication between subscribers and the cable operator. Cable operators now offer customers advanced telecommunications services, including high-speed Internet access, digital cable television, and residential telephone service. Cable operators typically deploy hybrid fiber-coaxial (HFC) networks to enable high-speed transmission of data to cable modems located in a SOHO.
The cable TV industry uses a portion of the RF electromagnetic spectrum. Within the cable, different frequencies carry TV channels and data. At the subscriber end, equipment such as TVs, VCRs, and high-definition TV set-top boxes tune to certain frequencies that allow the user to view the channel or, using a cable modem, to receive high-speed Internet access.
A cable network is capable of sending signals on the cable in either direction at the same time. The following frequency scope is used:
-
Downstream— The direction of an RF signal transmission (TV channels and data) from the source (headend) to the destination (subscribers). Transmission from source to destination is called the forward path.
-
Upstream— The direction of the RF signal transmission from subscribers to the headend, or the return or reverse path.
For example, as shown in Figure 7-8, downstream frequencies are in the range of 50 MHz to 860 MHz. Upstream frequencies are in the range of 5 MHz to 42 MHz.
As shown in Figure 7-9, two types of equipment are required to send digital modem signals upstream and downstream on a cable system:
A headend CMTS communicates with CMs located in subscriber homes. The headend is actually a router with databases for providing Internet services to cable subscribers. The architecture is relatively simple, using a mixed optical-coaxial network in which optical fiber replaces the lower-bandwidth coaxial.
A web of fiber trunk cables connects the headend to the nodes where optical-to-RF signal conversion takes place. The fiber carries the same broadband content for Internet connections, telephone service, and streaming video as the coaxial cable carries. Coaxial feeder cables originate from the node that carries RF signals to the subscribers.
In a modern HFC network, typically 500 to 2000 active data subscribers are connected to a cable network segment, all sharing the upstream and downstream bandwidth. The actual bandwidth for Internet service over a CATV line can be up to 27 Mbps on the download path to the subscriber and about 2.5 Mbps of bandwidth on the upload path. Based on the cable network architecture, cable operator provisioning practices, and traffic load, an individual subscriber can typically get an access speed of between 256 kpbs and 6 Mbps.
When high usage causes congestion, the cable operator can add additional bandwidth for data services by allocating an additional TV channel for high-speed data. This addition may effectively double the downstream bandwidth that is available to subscribers. Another option is to reduce the number of subscribers served by each network segment. To reduce the number of subscribers, the cable operator further subdivides the network by laying the fiber-optic connections closer and deeper into the neighborhoods.
DSL Background Information
Although satellite broadband and cable broadband solutions are popular options for telecommuters and SOHOs, they are still not an effective option for corporate Internet access. However, DSL is one of many broadband technologies that have become efficient and effective options for corporate Internet access. For this reason, we will use DSL as our solution for the branch office connection.
Several years ago, research by Bell Labs identified that a typical voice conversation over a plain old telephone service (POTS) local loop only required the use of frequencies in the range of 300 Hz to 3400 Hz. For years, the bandwidth greater than 4 KHz went unused. Advances in technology allowed DSL to use the additional bandwidth from 4 KHz up to 1 MHz to deliver high-speed data services over ordinary copper lines.
For example, as shown in Figure 7-10, asymmetric DSL (ADSL) uses a frequency range from approximately 20 KHz to 138 KHz for upstream data transmission and from 142 KHz to 1 MHz for downstream data transmission.
What makes ADSL so attractive is that to deliver this high-bandwidth data rates to subscribers, a relatively small change to the existing telephone company infrastructure is required.
There are many variants of DSL, including ADSL, very high bitrate DSL (VDSL), symmetric digital subscriber line (SDSL), high bitrate digital subscriber line (HDSL), and single-pair high-speed digital subscriber line (SHDSL). When discussing these variants, the following properties are compared:
-
Nature— The nature of DSL is the relation between downstream and upstream speeds. Synchronous DSL has the same speeds in both directions, whereas asynchronous DSL has different downstream and upstream speeds.
-
Maximum data rate— Defines the maximum speed that can be deployed with a certain type of DSL.
-
Data and voice support— Depending on the usage of the available frequency spectrum, certain DSL types support data and voice simultaneously, whereas others do not.
-
Line coding technology— Describes the technique used to represent digital signals to be transported over a copper twisted pair so that the receiver can interpret them accurately.
-
Maximum distance— Describes the maximum distance that a certain type of DSL connection can span from the customer premises equipment (CPE) to the DSL access multiplexer (DSLAM)
ADSL is designed to deliver more bandwidth downstream than upstream, and supports data and voice simultaneously over existing copper lines. ADSL is oriented toward residential subscribers, where more bandwidth is usually required in the downstream for applications such as downloading music, movies, playing online games, surfing the Internet, and receiving e-mail with large attachments. The downstream rate ranges from 256 bpsKbps to 8 Mbps, while upstream speed can reach upwards of 1 Mbps.
HDSL was the first DSL technology to use a higher frequency spectrum of copper, twisted-pair cables. It could deliver T1 (1.544 Mbps) or E1 (2.048 Mbps) of symmetrical bandwidth over two copper twisted pairs. HDSL was replaced by SDSL.
SDSL is proprietary and nonstandardized technology capable of supporting T1/E1 data rates. It can carry only data and cannot coexist with a conventional voice service on the same pair (because it takes over the entire bandwidth). SDSL was mainly targeted at small and medium-size businesses that did not need the service guarantees of Frame Relay or leased line. SDSL is now considered legacy and new installations typically use SHDSL.
SHDSL is standardized and developed by the International Telecommunication Union (ITU). It is also known by the standard’s draft name of G.SHDSL. It offers symmetrical data rates from 192 bpsKbps to 2.3 Mbps and is considered a popular choice to support PBX, VPN, web hosting, and other data services.
VDSL can provide symmetrical or asymmetrical services. The downstream bandwidth ranges from 13 Mbps to 52 Mbps. Like ADSL, VDSL also supports data and voice over a single copper line. VDSL is popular in Japan, South Korea, and Germany.
Table 7-1 summarizes the DSL variants and their characteristics.
Table 7-1: DSL Variants
Open table as spreadsheet | DSL Technology | Nature | Maximum Data Rate (Down / Up) [bps] |
| ADSL | Asymmetric | 8 Mbps / 1 Mbps |
| HDSL | Symmetric | 2 Mbps / 2 Mbps |
| SDSL | Symmetric | 2 Mbps / 2 Mbps |
| SHDSL | Symmetric | 2.3 Mbps / 2.3 Mbps |
| VDSL | Symmetric / asymmetric | 52 Mbps / 16 Mbps |
DSL is not a complete end-to-end solution, but rather a physical layer transmission technology similar to dial, cable, or wireless. To carry data services, DSL works in conjunction with other technologies. This results in several deployment modes. They all use a similar infrastructure shown in Figure 7-11.
DSL connections are deployed in the “last mile” of a local telephone network—the local loop. The connection is set up between a pair of modems on either end of a copper wire extending between the CPE and the DSLAM. A DSLAM is the device located at the central office (CO) of the provider and concentrates connections from multiple DSL subscribers. Users typically use either Point-to-Point Protocol over ATM (PPPoA) or Point-to-Point Protocol over Ethernet (PPPoE) to connect to the providers DSLAM.
In all cases, DSL is a high-speed Layer 1 transmission technology that works over copper wires.
The DSL Layer 1 connection from the CPE is terminated at the DSLAM. The data link layer protocol that is usually used over DSL is ATM. A DSLAM is basically an ATM switch containing DSL interface cards (ATU-Cs). The DSLAM terminates the ADSL connections, and then switches the traffic over an ATM network to the service provider’s core aggregation router. The aggregation router is the Layer 3 device where IP connection from the subscriber terminates.
PPPoA
IP packets over an ATM and DSL connection have to be encapsulated in some way, and these three approaches exist:
-
RFC 1483/2684 bridged
-
PPPoE, Point-to-Point Protocol over Ethernet
-
PPPoA, Point-to-Point Protocol over ATM
RFC 1483 bridging has security and scalability issues, making it unpopular as deployment architecture. PPPoE and PPPoA are more scalable and secure, but also more complex for implementation.
With PPPoA deployment option, the PPP connection is established between the CPE and the service provider core router. The CPE device must be configured with a username and password for authentication with core the router, which is responsible for terminating the PPP session of the CPE. The core router authenticates the users using either a local database or an external RADIUS authentication, authorization, accounting (AAA) server.
After the PPP username and password have been authenticated, the PPP Internet Protocol Control Protocol (IPCP) negotiation takes place to assign an IP address to the CPE. The core router will provide an IP address from its DHCP server. The core router typically assigns only one IP address to the CPE, and the CPE can use NAT and Port Address Translation (PAT) to support multiple inside hosts.
After the IP address has been assigned, a host route is established both on the CPE and the aggregation router.
| Note | The details of PPP negotiations are beyond the scope of this book. |
Configuring PPPoA
In our scenario, the Internet service provider has provided the branch site with a PPPoA connection to the Internet. The steps to configure PPPoA on the branch router, where components of both the DSL architecture and of basic branch IP services are required, are as follows:
-
Configure an ATM interface.
-
Configure a dialer interface.
-
Configure PAT.
-
Configure the branch router as a local DHCP server.
-
Configure a static default route.
ATM and dialer interfaces will establish the ATM virtual circuits and the PPP sessions. A dialer interface is a virtual interface that is configured as an on-demand component. This dialer interface will be up upon successful DSL subscriber authentication. Meanwhile, PAT, DHCP, and default routes provide the IP addressing and routing infrastructure to allow IP traffic to be carried along the DSL connection.
A final branch router configuration is displayed in Example 7-1.
| Note | The PPPoA configuration is provided for reference purpose only; the actual configuration of PPPoA is beyond the scope of this chapter. You can find in-depth information about these commands at Cisco.com. |
Example 7-1: PPPoA Sample Configuration
hostname Branch
!
ip dhcp pool MY-POOL
network 192.168.1.0 255.255.255.0
default-router 192.168.1.1
!
interface ATM0/0
no ip address
dsl operating-mode auto
pvc 8/35
encapsulation aal5mux ppp dialer
dialer pool-member 1
!
interface FastEthernet0/0
ip address 192.168.1.1 255.255.255.0
ip nat inside
!
interface Dialer0
ip address negotiated
encapsulation ppp
dialer pool 1
ip nat outside
ppp authentication chap callin
ppp chap password mysecret
!
ip nat inside source list 101 interface Dialer0 overload
access-list 101 permit ip 192.168.1.0 0.0.0.255 any
!
ip route 0.0.0.0 0.0.0.0 Dialer0
The configuration in Example 7-1 assumes that the branch router has an ATM interface installed on it. Here is a high-level overview of the configuration:
-
The branch router provides DHCP services to users connected to the inside LAN interface. Users connecting to the inside LAN interface would be provided with a private address from the 192.168.1.0 pool.
-
The configuration specifics of the ATM 0/0 interface and the permanent virtual circuit (PVC) are provided by the DSL service provider. Notice the combination of the ATM interface dialer pool-member 1 command and the dialer interface dialer-pool 1 commands. These two commands associate the ATM 0/0 interface to the Dialer 0 interface.
-
The Dialer 0 interface is a virtual interface that initiates PPP connectivity, including PPP services such as user authentication. Notice that it is also identified as the outside NAT interface.
-
NAT is configured to translate traffic initiated at the LAN port into the IP address of the dialer interface, which is obtained via DHCP from the DSL provider. In Example 7-1, you can see the ip nat commands, which defined the inside network with ACL 110, the outside network and how inside hosts will be translated when the traffic leaves for the outside network. Notice the overload keyword, which enables PAT. This means that inside users exiting through the Internet connection would share the IP address of the dialer interface. Although NAT would be more indicative of a large branch site, PAT is configured here as an example.
-
Finally, notice that the static default route points to the dialer interface. The routing of traffic to this default route would trigger the dialer interface to activate.
To summarize the stages of a DSL connection: Inside traffic is routed to the dialer interface (Dialer 0). Dialer 0 being a virtual interface, which has been configured to enlist the help of any physical interfaces member of the dialer pool 1, will turn to interface ATM 0/0. Interface ATM 0/0 has been configured to bring up a DSL connection using PPP encapsulation. When the service provider core router requests a username and a password, the credentials configured under interface Dialer 0 will be presented. The core router then provides an IP address to the ATM 0/0 interface, and the Internet connection will be active. Inside users leaving through the Internet connection are provided with the IP address of the virtual interface.
Verifying PPPoA
To check a DSL configuration, the best approach is to use the divide-and-conquer troubleshooting model. At each layer, we will have components that help understand the status of the connection, including DSL line status, ATM PVC establishment, PPP session negotiations, and IP addresses and other components.
To confirm that the branch router has a route pointing to the dialer interface, use the show ip route command. Next, to check IP connectivity, use the ping and traceroute commands from an inside host to confirm proper translation and routing of the packets and that return traffic is coming back.
You can also use debug ppp authentication to debug the PPP session authentication. To check ATM connectivity, use debug atm events to see the establishment of ATM PVC. Finally, to check Layer 1 connectivity, use show dsl interface atm number. This command would assist in discovering the DSL line status.
| Note | Again, PPP, ATM, and DSL commands are beyond the scope of this chapter. You can find more information about these commands at Cisco.com. |
The list of verification commands presented here is not exhaustive. It represents a small number of useful commands that enable you to verify the configuration.
Now that basic connectivity has been established, we move on to the next step in our implementation plan.
Configuring Static Routing
Focusing on our upgrade objective, we will now take a look at the second step of our implementation plan: static routing.
Currently, the branch office users connect to the headquarters site across a private WAN link. This link is used to provide users on the branch LAN access to servers located on the headquarters LAN. EIGRP was implemented as the dynamic routing protocol between the branch router and the HQ router. The HQ router also provides Internet access to branch LAN users by propagating a default route through EIGRP.
Although adding a new Internet connection on the branch router could also provide Internet access to the branch users, the current requirement is just to have it serve as a backup alternative in case the private WAN link fails.
Figure 7-12 will serve as our main topology to guide us through the next implementation step.
The following is a summary of the topology:
-
The branch router and HQ router are interconnected over a private WAN using subnet 172.16.1.0 /30.
-
The HQ LAN is on network 10.10.10.0 /24. It also has an e-mail server that the branch users access at IP address 10.10.10.238. Mobile users can also access the e-mail server from the Internet by going to the 209.165.200.238 public address. This address is translated to the internal e-mail server address using static NAT.
-
The HQ router also has an Internet connection to the ISP router by exiting out of the Internet-facing interface (Serial 0/0/1). All HQ LAN and Branch LAN traffic is subject to being translated to an address in the NAT pool.
-
The branch router LAN is on network 192.168.1.0 /24. It also has a server, which the HQ LAN users access at IP address 192.168.1.254.
-
The Branch LAN users access the Internet by using the default route propagated by the HQ router.
-
The branch router also has a new Internet connection on subnet 209.165.200.240/29. This connection will serve as a backup route for the private WAN link.
| Note | To keep it simple, the ATM Internet link from the “Deploy Broadband Connectivity” implementation step has been replaced by the Serial 0/0/1 links on the Branch and HQ routers. |
Routing to the Internet
Our scenario dictates that all corporate traffic, from the HQ LAN to branch office LAN must go through the private WAN. Our next step is to enable the Internet link as a back to the private WAN link. To do so, a floating static route will be configured on the Branch. Let’s verify the current status of the network before we configure the floating static route.
| Note | Instead of creating a floating static route, we could have used backup interface command to accomplish a quick turn over instead of relying on EIGRP convergence to figure there is an issue with a particular path. |
Currently, the main connection to the HQ is via the private WAN network because it is configured for routing with EIGRP. You can verify this with the show ip protocols command issued to the branch router, as shown in Example 7-2.
Example 7-2: show ip protocols Output on Branch Router
Branch#show ip protocols
Routing Protocol is "eigrp 1"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Default networks flagged in outgoing updates
Default networks accepted from incoming updates
EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0
EIGRP maximum hopcount 100
EIGRP maximum metric variance 1
Redistributing: eigrp 1
EIGRP NSF-aware route hold timer is 240s
Automatic network summarization is not in effect
Maximum path: 4
Routing for Networks:
172.16.1.0/30
192.168.1.0
Routing Information Sources:
Gateway Distance Last Update
172.16.1.1 90 00:08:19
Distance: internal 90 external 170
Branch#
We see that an EIGRP process is running and that it is advertising the branch office LAN 192.168.1.0/24 toward the HQ router, using the 172.16.1.0/30 segment.
Verify the routing table on the branch router with the show ip route command, as shown in Example 7-3.
Example 7-3: show ip route Output on Branch
Branch#show ip route
*Mar 26 03:45:38.207: %SYS-5-CONFIG_I: Configured from console by consolee
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is 172.16.1.1 to network 0.0.0.0
172.16.0.0/30 is subnetted, 1 subnets
C 172.16.1.0 is directly connected, Serial0/0/0
209.165.200.0/29 is subnetted, 1 subnets
C 209.165.200.240 is directly connected, Serial0/0/1
10.0.0.0/24 is subnetted, 1 subnets
D 10.10.10.0 [90/2172416] via 172.16.1.1, 00:00:17, Serial0/0/0
C 192.168.1.0/24 is directly connected, FastEthernet0/0
D*EX 0.0.0.0/0 [170/2681856] via 172.16.1.1, 00:00:17, Serial0/0/0
Branch#
Notice that we have three directly connected networks. The branch LAN is on network 192.168.1.0/24, the private WAN link is on network 172.16.1.0/30, and the new Internet connection is on network 209.165.200.240/29. There are also two EIGRP routes denoted by the letter D, which stands for Diffusing Update Algorithm (DUAL), the EIGRP routing algorithm. The route to the corporate 10.10.10.0 LAN on the HQ router is provided by EIGRP. The other EIGRP route is denoted with an asterisk (*), which means that it is candidate default route and responsible for providing the gateway of last resort to 172.16.1.1. The EX and the EIGRP administrative distance of 170 signifies that this is a route has been redistributed into EIGRP by another router.
To verify that EIGRP is also running on the HQ router, use the show ip protocols command, as shown in Example 7-4. Notice that it is advertising the 172.16.1.0/30 and 10.10.10.0 subnets.
Example 7-4: show ip protocols Output on the HQ Router
HQ#show ip protocols
Routing Protocol is "eigrp 1"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Default networks flagged in outgoing updates
Default networks accepted from incoming updates
EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0
EIGRP maximum hopcount 100
EIGRP maximum metric variance 1
Redistributing: static, eigrp 1
EIGRP NSF-aware route hold timer is 240s
Automatic network summarization is not in effect
Maximum path: 4
Routing for Networks:
10.10.10.0/24
172.16.1.0/30
Routing Information Sources:
Gateway Distance Last Update
172.16.1.2 90 00:04:40
Distance: internal 90 external 170
HQ#
Notice that the HQ router is advertising a static route. To verify the router, use the show ip route command, as shown in Example 7-5.
Example 7-5: show ip route Output on the HQ Router
HQ#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is 0.0.0.0 to network 0.0.0.0
172.16.0.0/30 is subnetted, 1 subnets
C 172.16.1.0 is directly connected, Serial0/0/0
209.165.200.0/29 is subnetted, 1 subnets
C 209.165.200.224 is directly connected, Serial0/0/1
10.0.0.0/24 is subnetted, 1 subnets
C 10.10.10.0 is directly connected, FastEthernet0/0
D 192.168.1.0/24 [90/2172416] via 172.16.1.2, 00:48:28, Serial0/0/0
S* 0.0.0.0/0 is directly connected, Serial0/0/1
HQ#
From the branch router, verify connectivity to the HQ e-mail server using the ping and trace commands to the 10.10.10.238 IP address on the HQ router, as shown in Example 7-6.
Example 7-6: Verifying Connectivity to the HQ E-Mail Server
Branch#ping 10.10.10.238 source 192.168.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.238, timeout is 2 seconds:
Packet sent with a source address of 192.168.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
Branch#
Branch#trace 10.10.10.238 source 192.168.1.1
Type escape sequence to abort.
Tracing the route to 10.10.10.238
1 172.16.1.1 0 msec 0 msec *
Branch#
Notice that both the ping and trace were successful. Also notice the path that the branch router took was the private WAN link to IP address 172.16.1.1. Finally, test connectivity to the Internet. Ping the ISP’s website at IP address 209.165.202.111 and source the packets from the inside LAN, as shown in Example 7-7.
Example 7-7: Verifying Connectivity to the ISP Website
Branch#ping 209.165.202.211 source 192.168.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 209.165.202.211, timeout is 2 seconds:
Packet sent with a source address of 192.168.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/32/32 ms
Branch#
Branch# trace 209.165.202.211 source 192.168.1.1
Type escape sequence to abort.
Tracing the route to 209.165.202.211
1 172.16.1.1 0 msec 0 msec 0 msec
2 209.165.200.225 16 msec 16 msec *
Branch#
The pings are successful, and the output of the trace command confirms that the branch LAN is reaching the Internet via the private WAN link (172.16.1.1) and then the ISP router (209.165.200.225).
We are now ready to configure the backup connection.
Floating Static Route
What happens if the private WAN link fails? Traffic to the HQ e-mail server or to the Internet would not be possible. However, by adding floating default static route to the branch router, we can accomplish resiliency dynamically. Whenever the link through the private WAN link fails, the floating would populate the routing table. When the private WAN reactivates, EIGRP would reroute traffic through the private WAN.
A floating static is simply a static route with an AD greater than that of the existing dynamic routing protocol. To create a floating static route, use the ip route prefix mask next-hop-ip-address distance command. The default AD for a static route is 1.
We have already seen in Example 7-3 that the current AD of the default route is 170. That route is learned via EIGRP and uses the private WAN back to the HQ router. Therefore, for a floating static route to work, we need to use a distance greater than 170. Create a floating default static route to the ISP as configured in Example 7-8.
Example 7-8: Configuring a Floating Default Static Route on Branch
Branch(config)#ip route 0.0.0.0 0.0.0.0 209.165.200.241 171
Branch(config)#exit
Notice that the default static route has been configured with an AD of 171, making it a floating static route. We can only assume that the floating static route is waiting for the private WAN link to fail.
To test the backup feature, we will first issue the debug ip routing command on the branch router to observe events and then disable the interface to the private WAN, as shown in Example 7-9.
Example 7-9: Observe the Floating Static Route
Branch#debug ip routing
IP routing debugging is on
Branch#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Branch(config)#int s0/0/0
Branch(config-if)#shutdown
Branch(config-if)#
*Mar 26 06:22:23.759: RT: is_up: Serial0/0/0 0 state: 6 sub state: 1 line: 0 has_route: True
*Mar 26 06:22:23.759: RT: interface Serial0/0/0 removed from routing table
*Mar 26 06:22:23.759: RT: del 172.16.1.0/30 via 0.0.0.0, connected metric [0/0]
*Mar 26 06:22:23.759: RT: delete subnet route to 172.16.1.0/30
*Mar 26 06:22:23.759: RT: NET-RED 172.16.1.0/30
*Mar 26 06:22:23.759: RT: delete network route to 172.16.0.0
*Mar 26 06:22:23.759: RT: NET-RED 172.16.0.0/16
*Mar 26 06:22:23.759: RT: Pruning routes for Serial0/0/0 (3)
*Mar 26 06:22:23.763: RT: delete route to 10.10.10.0 via 172.16.1.1, Serial0/0/0
*Mar 26 06:22:23.763: RT: no routes to 10.10.10.0, flushing
*Mar 26 06:22:23.763: RT: NET-RED 10.10.10.0/24
*Mar 26 06:22:23.767: RT: delete network route to 10.0.0.0
*Mar 26 06:22:23.767: RT: NET-RED 10.0.0.0/8
*Mar 26 06:22:23.767: RT: delete route to 0.0.0.0 via 172.16.1.1, Serial0/0/0
*Mar 26 06:22:23.767: RT: no routes to 0.0.0.0, flushing
*Mar 26 06:22:23.767: RT: NET-RED 0.0.0.0/0
*Mar 26 06:22:23.771: RT: add 0.0.0.0/0 via 209.165.200.241, static metric [171/0]
*Mar 26 06:22:23.771: RT: NET-RED 0.0.0.0/0
*Mar 26 06:22:23.771: RT: default path is now 0.0.0.0 via 209.165.200.241
*Mar 26 06:22:23.771: RT: new default network 0.0.0.0
*Mar 26 06:22:23.771: RT: NET-RED 0.0.0.0/0
*Mar 26 06:22:23.771: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.1.1
(Serial0/0/0) is down: interface down
Branch(config-if)#end
Branch#undebug all
All possible debugging has been turned off
Branch#
| Note | debug commands produce verbose outputs, which in a production environment could slow down your router. Use with care. Use the no debug all or undebug all command to turn off debugging on a router. |
Notice that the default route to 172.16.1.1 has been removed but the new floating default static route has been added. If we verify the routing table of the branch router, we will see the static route pointing to the HQ LAN, as shown in Example 7-10.
Example 7-10: Verify the Routing Table
Branch#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is 209.165.200.241 to network 0.0.0.0
209.165.200.0/29 is subnetted, 1 subnets
C 209.165.200.240 is directly connected, Serial0/0/1
192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.1.0/24 is directly connected, FastEthernet0/0
S* 0.0.0.0/0 [171/0] via 209.165.200.241
Branch#
A trace from the branch LAN to the HQ e-mail server global IP address of 209.165.200.238 confirms that the path taken is now through the Internet connection, as shown in Example 7-11.
Example 7-11: Trace from the Branch LAN to the E-Mail Server
Branch#ping 209.165.200.238 source 192.168.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 209.165.200.238, timeout is 2 seconds:
Packet sent with a source address of 192.168.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/56/60 ms
Branch#
Branch#trace 209.165.200.238 source 192.168.1.1
Type escape sequence to abort.
Tracing the route to 209.165.200.238
1 209.165.200.241 12 msec 12 msec 16 msec
2 209.165.200.238 28 msec 28 msec *
Branch#
It would appear that all is working as expected. However, the scenario as presented so far would really not be feasible, because the private addresses of the branch LAN would be filtered by the ISP router. Therefore, on the branch router, the internal private IP addresses must be translated via NAT to global public IP addresses.
Verifying Branch Services
Focusing on our upgrade objective, we will now discuss the third step of our implementation plan, verify branch services, including the following:
-
NAT
-
DHCP
-
Access lists
-
Policy-based routing
-
HSRP
We will specifically focus on NAT. Figure 7-13 will serve as our main topology to guide us through the next implementation step.
The reference topology is the same as in the previous step except that it now displays the NAT pool of global IP addresses available on the branch router. Also notice that the Branch server has a static NAT global address (209.165.200.254).
The branch router must be configured to deploy NAT as described.
Configuring NAT
There are three generic steps to configuring NAT. You need to identify
-
Which traffic will be translated
-
To what address will it be translated
-
Which interfaces are involved in the translation selection
The first step in configuring NAT is to create an access control list (ACL) that will declare which traffic will be translated.
It is important to understand that the access list is not used to filter the traffic. Instead, it is used to designate which traffic will be translated by NAT. A permit statement in a NAT access list means “translate,” and a deny statement in the same access list means “do not translate.”
After we have declared which traffic will be translated, we need to define to which IP address the traffic will be translated. We will use the ip nat pool name start-ip end-ip {netmask netmask | prefix-length prefix-length} command to define a pool of IP addresses for NAT, as shown in Table 7-2.
Table 7-2: ip nat pool Global Command
Open table as spreadsheet | Parameter | Description |
| name | IP route prefix for the destination. |
| start-ip | Starting IP address that defines the range of addresses in the address pool. |
| end-ip | Ending IP address that defines the range of addresses in the address pool. |
| netmask netmask | Network mask that indicates which address bits belong to the network and subnetwork fields and which bits belong to the host field. Specify the netmask of the network to which the pool addresses belong. |
| prefix-length prefix-length | Number that indicates how many bits of the netmask are 1s (how many bits of the address indicate network). Specify the netmask of the network to which the pool addresses belong. |
| type rotary | (Optional) Indicates that the range of address in the address pool identify real, inside hosts among which TCP load distribution will occur. |
We now need to link the source IP address to the pool for translated address. This is accomplished with the ip nat inside source command. Table 7-3 shows the details of options for the ip nat inside source {list {access-list-number | access-list-name} | route-map name} {interface type number | pool name} [overload] command. If static translation is preferred, the command is ip nat inside source {static {local-ip global-ip}.
Table 7-3: ip nat inside source Global Command
Open table as spreadsheet | Parameter | Description |
| list access-list-number | Number of a standard IP access list. Packets with source addresses that pass the access list are dynamically translated using global addresses from the named pool. |
| list access-list-name | Name of a standard IP access list. Packets with source addresses that pass the access list are dynamically translated using global addresses from the named pool. |
| route-map name | Specifies the named route map. |
| interface type number | Specifies the interface type and number for the global address. |
| pool name | Name of the pool from which global IP addresses are allocated dynamically. |
| overload | (Optional) Enables the router to use one global address for many local addresses. When overloading is configured, the TCP or User Datagram Protocol (UDP) port number of each inside host distinguishes between the multiple conversations using the same local IP address. |
| static local-ip | Sets up a single static translation. The local-ip argument establishes the local IP address assigned to a host on the inside network. |
| local-port | Sets the local TCP/UDP port in a range from 1 to 65535. |
| static global-ip | Sets up a single static translation. The local-ip argument establishes the globally unique IP address of an inside host as it appears to the outside world. |
| global-port | Sets the global TCP/UDP port in a range from 1 to 65535. |
| extendable | (Optional) Extends the translation. |
| no-alias | (Optional) Prohibits an alias from being created for the global address. |
| no-payload | (Optional) Prohibits the translation of an embedded address or port in the payload. |
| redundancy group-name | (Optional) Establishes NAT redundancy. |
| esp ip-local | Establishes IPsec-ESP (tunnel mode) support. |
The final step is to designate that traffic originating from or destined for a specific interface is subject to be translated. To do so, use the ip nat interface configuration command. Some details of the ip nat command are shown in Table 7-4.
Table 7-4: ip nat Interface Command
Open table as spreadsheet | Parameter | Description |
| inside | Indicates that the interface is connected to the inside network (the network subject to NAT translation). |
| outside | Indicates that the interface is connected to the outside network. |
| Note | Not all NAT command parameters were included or discussed. For more information, see Cisco.com. |
Example of NAT Configuration
Our first step is to configure NAT on the branch router depicted in Figure 7-13. To do so, we will define an access list identifying which traffic is allowed to use NAT.
We are going to translate addresses coming from the branch LAN, regardless of destination. This is accomplished with the access list depicted in Example 7-12. Traffic with source IP address 192.168.1.0/24 is targeted for translation by the permit statement. The unseen implicit deny statement will not translate any other addresses.
Example 7-12: Access List Used for NAT
Branch(config)#ip access-list extended BRANCH-NAT-ACL
Branch(config-ext-nacl)#permit ip 192.168.1.0 0.0.0.255 any
Branch(config-ext-nacl)#exit
Branch(config)#
Next, the NAT pool of public IP address is defined using the ip nat pool command. In Example 7-13, the NAT pool is named BRANCH-NAT-POOL and identifies a range of valid and available Internet IP address. In this case, the public IP addresses are in the range from 209.165.201.1 to 209.165.201.29 /27.
Example 7-13: NAT Pool Is Created
Branch(config)#ip nat pool BRANCH-NAT-POOL 209.165.200.249 209.165.200.253 netmask
255.255.255.248
Branch(config)#
Branch(config)#! Or use the prefix-length keyword
Branch(config)#
Branch(config)#ip nat pool BRANCH-NAT-POOL 209.165.200.249 209.165.200.253 prefix-
length 29
Branch(config)#
Notice that the subnet mask of the public IP addresses can be specified using either the prefix-length or netmask keywords.
The BRANCH-NAT-ACL and BRANCH-NAT-POOL will now be bound together with the ip nat inside source command shown in Example 7-14.
Example 7-14: ip nat inside source Command for Dynamic NAT on the Branch Router
Branch(config)#ip nat inside source list BRANCH-NAT-ACL pool BRANCH-NAT-POOL
Branch(config)#
The ip nat inside command specifies that the router will translate all inside IP addresses identified by the source list BRANCH-NAT-ACL keywords to the publicly available IP addresses identified by the pool BRANCH-NAT-POOL keywords.
| Note | Optionally, PAT could have been configured by appending the keyword overload to the ip nat inside command. PAT enables a router to use only one global IP address to be shared by many inside addresses. PAT is commonly deployed in smaller branch and SOHO sites and is discussed in the “Mobile Worker” section of this chapter. |
The branch site also has a web server that requires a static global IP address assigned to its internal IP address. Specifically, the internal IP address of the web server is 192.168.1.254, and it should always be translated to the global IP address 209.165.200.254.
| Note | In a normal environment, the web server would not be located on the inside network, as shown in Figure 7-8. That particular server-host would be located on a separate segment, usually called the demilitarized zone (DMZ). |
Example 7-15 creates a static translation entry in the router, where the inside local address 192.168.1.254 is always translated to the global 209.165.200.254 on the outside.
Verifying NAT
To display active NAT translations, use the show ip nat translations command in EXEC mode. The details of command are shown in Table 7-5.
Table 7-5: show ip nat translation Command
Open table as spreadsheet | Parameter | Description |
| esp | (Optional) Displays Encapsulating Security Payload (ESP) entries |
| icmp | (Optional) Displays Internet Control Message Protocol (ICMP) entries |
| pptp | (Optional) Displays Point-to-Point Tunneling Protocol (PPTP) entries |
| tcp | (Optional) Displays TCP protocol entries |
| udp | (Optional) Displays UDP entries |
| verbose | (Optional) Displays additional information for each translation table entry, including how long ago the entry was created and used |
| vrf vrf-name | (Optional) Displays VPN routing and forwarding (VRF) traffic-related information |
You can also use the show ip nat statistics to display NAT statistics. This command has no arguments or keywords.
The clear ip nat translation can be used to clear dynamic NAT translations from the translation table. The details for the clear ip nat translation {* | [inside global-ip global-port local-ip local-port] | [outside local-ip global-ip] [esp | tcp | udp]} are shown in Table 7-6.
Table 7-6: clear ip nat translation Command
Open table as spreadsheet | Parameter | Description |
| * | Clears all dynamic translations |
| inside | (Optional) Clears the inside translations containing the specified global-ip and local-ip addresses |
| global-ip | (Optional) Global IP address |
| global-port | (Optional) Global port |
| local-ip | (Optional) Local IP address |
| local-port | (Optional) Local port |
| outside | (Optional) Clears the outside translations containing the specified global and local addresses. |
| esp | (Optional) Clears ESP entries from the translation table |
| tcp | (Optional) Clears the TCP entries from the translation table |
| udp | (Optional) Clears the UDP entries from the translation table |
| Note | Even though the show command has the word translations in plural, as in show ip nat translations, the clear command uses the singular form in clear ip nat translation. |
You can also use the clear ip nat statistics to reset the statistic counters to zero.
Example of NAT Verification
The show ip nat translations command displays the current NAT translations, as shown in Example 7-17.
Example 7-17: show ip nat translations Command
Branch#show ip nat translations
Pro Inside global Inside local Outside local Outside global
—- 209.165.200.254 192.168.1.254 —- —-
Branch#
Other than the static translation to the inside web server, there are no dynamic translations listed in the NAT cache.
Another good verification command is show ip nat statistics, as shown in Example 7-18.
Example 7-18: show ip nat statistics Command on the Branch Router
Branch#show ip nat statistics
Total active translations: 1 (1 static, 0 dynamic; 0 extended)
Peak translations: 1, occurred 00:31:21 ago
Outside interfaces:
Serial0/0/1
Inside interfaces:
FastEthernet0/0
Hits: 0 Misses: 0
CEF Translated packets: 0, CEF Punted packets: 0
Expired translations: 0
Dynamic mappings:
— Inside Source
[Id: 1] access-list BRANCH-NAT-ACL pool BRANCH-NAT-POOL refcount 0
pool BRANCH-NAT-POOL: netmask 255.255.255.224
Appl doors: 0
Normal doors: 0
Queued Packets: 0
Branch#
This command displays the number of active translations, which in this case is one static and zero dynamic translation. It also lists the interfaces involved in the NAT translations and the specifics of the BRANCH-NAT-POOL in use, including the BRANCH-NAT-ACL access list used for the traffic to be translated.
To test the new configuration, we will attempt to telnet to the public IP address of the HQ router, while sourcing it from the inside network address 192.168.1.1. However, before doing so, we will clear the NAT statistics, and enable the debug ip nat command to observe NAT translations, as shown in Example 7-19.
Example 7-19: Generating NAT Traffic
Branch#debug ip nat
IP NAT debugging is on
Branch#clear ip nat statistics
Branch#clear ip nat translation *
Branch#telnet 209.165.200.226 /source-interface fa0/0
Trying 209.165.200.226 ... Open
Password required, but none set
*Mar 26 14:20:10.563: NAT: s=192.168.1.1->209.165.200.249, d=209.165.200.226 [10933]
*Mar 26 14:20:10.591: NAT*: s=209.165.200.226, d=209.165.200.249->192.168.1.1
[60321]
*Mar 26 14:20:10.595: NAT: s=192.168.1.1->209.165.200.249, d=209.165.200.226 [10934]
*Mar 26 14:20:10.595: NAT: s=192.168.1.1->209.165.200.249, d=209.165.200.226 [10935]
*Mar 26 14:20:10.595: NAT: s=192.168.1.1->209.165.200.249, d=209.165.200.226 [10936]
*Mar 26 14:20:10.627: NAT*: s=209.165.200.226, d=209.165.200.249->192.168.1.1
[60322]
*Mar 26 14:20:10.627: NAT: s=192.168.1.1->209.165.200.249, d=209.165.200.226 [10937]
*Mar 26 14:20:10.627: NAT: s=192.168.1.1->209.165.200.249, d=209.165.200.226 [10938]
*Mar 26 14:20:10.631: NAT: s=192.168.1.1->209.165.200.249, d=209.165.200.226 [10939]
*Mar 26 14:20:10.639: NAT*: s=209.165.200.226, d=209.165.200.249->192.168.1.1
[60323]
*Mar 26 14:20:10.827: NAT*: s=209.165.200.226, d=209.165.200.249->192.168.1.1
[60324]
*Mar 26 14:20:10.839: NAT: s=192.168.1.1->209.165.200.249, d=209.165.200.226 [10940]
[Connection to 209.165.200.226 closed by foreign host]
Branch#
*Mar 26 14:20:12.723: NAT*: s=209.165.200.226, d=209.165.200.249->192.168.1.1
[60325]
*Mar 26 14:20:12.723: NAT: s=192.168.1.1->209.165.200.249, d=209.165.200.226 [10941]
*Mar 26 14:20:12.727: NAT: s=192.168.1.1->209.165.200.249, d=209.165.200.226 [10942]
*Mar 26 14:20:12.759: NAT*: s=209.165.200.226, d=209.165.200.249->192.168.1.1
[60326]
Branch#
Although the Telnet to the HQ router failed, it did manage to generate some debug output. The first translation is showing that the internal IP address 192.168.1.1 was translated to 209.165.200.249 and sent to the IP address of the HQ router. The next line, with NAT*, indicates the return TCP traffic.
Example 7-20 displays the output of the show ip nat translations and show ip nat statistics commands.
Example 7-20: Verifying the NAT Translations
Branch#show ip nat translations
Pro Inside global Inside local Outside local Outside global
tcp 209.165.200.249:55041 192.168.1.1:55041 209.165.200.226:23 209.165.200.226:23
—- 209.165.200.249 192.168.1.1 —- —-
—- 209.165.200.254 192.168.1.254 —- —-
Branch#
Branch#show ip nat statistics
Total active translations: 3 (1 static, 2 dynamic; 1 extended)
Peak translations: 3, occurred 00:13:14 ago
Outside interfaces:
Serial0/0/1
Inside interfaces:
FastEthernet0/0
Hits: 32 Misses: 0
CEF Translated packets: 12, CEF Punted packets: 2
Expired translations: 1
Dynamic mappings:
— Inside Source
[Id: 1] access-list BRANCH-NAT-ACL pool BRANCH-NAT-POOL refcount 2
pool BRANCH-NAT-POOL: netmask 255.255.255.248
Appl doors: 0
Normal doors: 0
Queued Packets: 0
Branch#
The commands are indicating the results of the dynamic translations. The first highlighted entry also includes the source and destination TCP port numbers.
The next step is to test the static translation. To do so, issue a ping command from the HQ router to the static NAT address of 209.165.200.254, as shown in Example 7-21.
Example 7-21: Verifying the Static NAT Translation
HQ#ping 209.165.200.254
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 209.165.200.254, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/57/60 ms
HQ#
Immediately on the branch router, the debug command again generates NAT output, as shown in Example 7-22.
Example 7-22: Verifying the NAT Translations
Branch#
*Mar 26 14:46:49.423: NAT*: s=209.165.200.226, d=209.165.200.254->192.168.1.254 [10]
*Mar 26 14:46:49.427: NAT: s=192.168.1.254->209.165.200.254, d=209.165.200.226 [10]
*Mar 26 14:46:49.483: NAT*: s=209.165.200.226, d=209.165.200.254->192.168.1.254 [11]
*Mar 26 14:46:49.483: NAT: s=192.168.1.254->209.165.200.254, d=209.165.200.226 [11]
*Mar 26 14:46:49.539: NAT*: s=209.165.200.226, d=209.165.200.254->192.168.1.254 [12]
*Mar 26 14:46:49.539: NAT: s=192.168.1.254->209.165.200.254, d=209.165.200.226 [12]
*Mar 26 14:46:49.599: NAT*: s=209.165.200.226, d=209.165.200.254->192.168.1.254 [13]
*Mar 26 14:46:49.599: NAT: s=192.168.1.254->209.165.200.254, d=209.165.200.226 [13]
Branch#
*Mar 26 14:46:49.655: NAT*: s=209.165.200.226, d=209.165.200.254->192.168.1.254 [14]
*Mar 26 14:46:49.655: NAT: s=192.168.1.254->209.165.200.254, d=209.165.200.226 [14]
Branch#
The source address is the HQ router IP address going to the branch server global IP address, which is then being translated to its internal IP address. Verifying the NAT translations is displayed in Example 7-23.
Example 7-23: Verifying the NAT Translations
Branch#show ip nat translations
Pro Inside global Inside local Outside local Outside global
—- 209.165.200.249 192.168.1.1 —- —-
icmp 209.165.200.254:2 192.168.1.254:2 209.165.200.226:2 209.165.200.226:2
—- 209.165.200.254 192.168.1.254 —- —-
Branch#
Notice we also have an extended ICMP entry. Entries in the NAT cache eventually expire, and the entry is removed. Notice that a minute later, another debug message informs us that the last ICMP entry has expired, as shown in Example 7-24.
Verifying Other Services
As mentioned earlier, we also have to verify other services and how they can impact the branch site design.
DHCP is a common service used as an initial source of information to see which IP address should be reachable across our VPN connection. Because of the structure of the VPN, the branch office LAN will be considered part of the private corporate network. The headquarters LAN will also be considered part of the private corporate network. Therefore, we must check whether we have overlapping IP addresses between the two LANs. This could happen when, for example, two organizations merge and they both have IP subnet 10.10.10.0 /24 for their LAN, as shown in Figure 7-14.
If that were the case, we would have connectivity problem. Each router would think that a packet addressed to 10.10.10.254 is addressed to its local LAN, when in fact it might be for a host in the other LAN.
Additional verification will include checking the access lists currently configured on the routers. A branch router will require an inbound access list applied to its Internet-facing interface. However, there might also be additional security controls on the branch router that block important protocols necessary for the VPN establishment.
For example, edge routers must be capable of forwarding protocols required to support IPsec VPNs, such as the following:
-
Encapsulation Security Payload (ESP) protocol, which provides confidentiality through encryption. ESP, located at Layer 4 of the OSI model, uses protocol 50.
-
Authentication Header (AH), which is similar to ESP but provides only integrity. AH uses protocol 51.
-
Internet Security Association and Key Management Protocol (ISAKMP), which is required during the first stage of IPsec tunnels coming up, when peer negotiations and credentials are exchanged using a protocol. ISAKMP uses the UDP port 500.
| Note | Securing the edge router interface using access lists and firewalls is beyond the scope of this chapter. |
Other services that will require your attention are those that might alter the path of the traffic, especially in the presence of dual connections. Policy-based routing (PBR) can be implemented to redirect traffic.
| Note | PBR for IPv4 is covered in Chapter 5, “Implementing Path Control,” and PBR for IPv6 is covered in Chapter 8, “Implementing IPv6 in an Enterprise Network.” |
Finally, another service that would have an impact is the Hot Standby Route Protocol (HSRP). This would not be the case with the current topology at our branch office, but other branch offices might have redundancy at the edge routers, as shown in Figure 7-15. HSRP would decide to switch to another active router upon failure and would define the traffic flow.
| Note | This topic is discussed further in the SWITCH course and related Cisco Press material. |
Verifying and Tuning IPsec VPNs
Now that broadband connectivity has been established, and our floating static route works, and NAT is performing properly, we will move on to securing our LAN-to-LAN Internet links using IPsec VPN tunnels. Specifically, we want to allow the branch to use the Internet as a backup connectivity option.
The intent of this section is not to provide detailed coverage of IPsec VPNs. It is about understanding the impact on routing services and addressing schemes when deploying IPsec VPNs at branch office routers.
| Note | For more information about cryptography and IPsec configuration for IOS routers, see the Cisco Press book Implementing Cisco IOS Network Security (IINS): (CCNA Security Exam 640-553) (Authorized Self-Study Guide) by Catherine Paquet, where Chapter 4 deals exclusively with fundamentals of cryptography and Chapter 5 with a site-to-site VPN between a head office and a branch office. In addition, you can find in-depth information about IPsec in the Cisco Networking Academy CCNA Security course. |
Using public networks to provide connectivity is a clear trend when designing branch office architectures. The main reasons public networks are connected to branch offices include ubiquitous availability and low cost, as compared to private WANs (the costs of which are often prohibitive for small businesses). However, there are many issues with providing connectivity through the Internet for the private traffic that might be generated within an organization, including the following:
-
Security— By default, all the traffic leaving on the public network is in clear text and could be read by anyone with the technical know-how and means.
-
Transparency and complexity— While using a public network to reach the head office, users of branch offices need to have the illusion that they are connected to the corporate network, and as such are using a private IP address compatible with the addressing scheme used by the organization.
IPsec seeks to resolve both issues.
IPsec Technologies
IPsec provides two significant benefits:
-
Encryption— Using a cryptographic algorithm, IPsec encrypts the data exchanged by the corporate offices that are using the public Internet.
-
Encapsulation— Using tunneling technology, it encapsulate the data as it leaves a corporate site, thus protecting its original IP address and providing the illusion to the recipient that the sender is located within the organization.
IPsec encryption provides three major services:
-
Confidentiality— Confidentiality provides encryption during the exchange of the data. Only the recipient in possession of the valid key can decrypt the packets. Confidentiality is provided by cryptographic algorithms, such as Data Encryption Standard (DES), Triple DES (3DES), and Advanced Encryption Standard (AES).
-
Integrity— Integrity provides a check to confirm that the data was not altered during the transmission. Integrity checks are provides by hashing algorithms such as message digest algorithm 5 (MD5) and Secure Hash (SHA).
-
Authentication— Authentication provides assurance that the data is exchanged with the rightful party and not with a hacker who is using the identity of a valid peer. Authentication is provided by signing the results of hashing algorithms.
Encapsulation Process
As mentioned, one of the benefits of IPsec is its capability to tunnel packets using an additional encapsulation. For example, in Figure 7-16 the original packet is encapsulated inside a new IP packet before it leaves the branch office.
The VPN router responsible for forwarding this packet performs this encapsulation task. At the receiving end, the destination VPN router performs the decapsulation functions, removing the newer IP packet and forwarding the original IP packet to the internal host as it was constructed by the source host.
The IPsec encapsulation process does not just add an additional IP header to the original packet. It also performs security functions. The VPN router responsible for releasing this packet can also encrypt most of the payload of the new packet, providing confidentiality to the transmission.
Figure 7-17 shows a sample scenario.
Assume the host on the branch site at IP address 192.168.1.10 wants to contact another host using its internal private IP address (10.10.10.10) and that the link is secured using a site-to-site IPsec VPN.
When the packet from the branch host leaves the branch router, this traffic will be flagged as being interesting and that an IPsec VPN should be established between the branch router and the HQ router. These two routers will then negotiate and secure a tunnel that encapsulates the original IP header into another, secure new IP header. The packet will then be forwarded to the HQ site. Once it arrives at the HQ site, the HQ router will decrypt the packet with the correct preshared key, extracting the IP packet, and forwarding it to the HQ host.
In our scenario, we will assume that our Internet security team has just finished configuring our branch router to support an IPsec VPN with the HQ site. This IPsec VPN is enabled whenever users on the branch LAN connect to another host on the HQ LAN over the Internet connection. Otherwise, the VPN does not activate. All we have to do is verify its proper configuration and operation. However, all the details of cryptographic services such as confidentiality, integrity, and VPN end-point authentication will be transparent to us.
To guide our discussion, let’s take a look at Figure 7-18. Assume that the purpose of the IPsec VPN link is to serve as a backup link in case our private WAN link fails. The long-term goal is to decommission the WAN link completely and use only the VPN connection to communicate between the branch office and the headquarters.
IPsec Site-to-Site VPN Configuration
To better understand how to verify an IPsec VPN, we must ensure that certain concepts are understood.
The steps to configure an IPsec VPN are as follows:
-
Configure the initial key (ISAKMP) details.
-
Configure the IPsec details.
-
Configure the crypto ACL.
-
Configure the VPN tunnel details.
-
Apply the crypto map
The final branch router IPsec VPN configuration is displayed in Example 7-26.
| Note | The details of cryptology and IPsec VPNs are beyond the scope of this chapter. However, you can find more information about these at Cisco.com. |
Example 7-26: Sample IPsec VPN Configuration
Branch#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Branch(config)#crypto isakmp policy 1
Branch(config-isakmp)#encryption aes
Branch(config-isakmp)#authentication pre-share
Branch(config-isakmp)#group 2
Branch(config-isakmp)#exit
Branch(config)#crypto isakmp key cisco123 address 209.165.200.226
Branch(config)#
Branch(config)#crypto ipsec transform-set HQ-VPN esp-sha-hmac esp-3des
Branch(cfg-crypto-trans)#exit
Branch(config)#
Branch(config)#crypto map HQ-MAP 10 ipsec-isakmp
% NOTE: This new crypto map will remain disabled until a peer
Branch(config-crypto-map)#set transform-set HQ-VPN
Branch(config-crypto-map)#set peer 209.165.200.226
Branch(config-crypto-map)#match address 110
Branch(config-crypto-map)#exit
Branch(config)#access-list 110 permit ip 192.168.1.0 0.0.0.255 10.10.10.0 0.0.0.255
Branch(config)#
Branch(config)#int s0/0/1
Branch(config-if)#crypto map HQ-MAP
*Mar 24 06:27:18.091: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ON
Branch(config-if)# ^Z
Branch#
Here is a high-level overview of the configuration:
-
The ISAKMP policy identifies the specifics for the initial key and secure parameters exchange.
-
The IPsec details define how the IP packet will be encapsulated and how it will be identified by the named HQ VPN.
-
The VPN tunnel information is identified in the crypto map named HQ-MAP, which combines the ISAKMP policies, IPsec packet detail, the peer address, and ACL 110.
-
ACL 110 is the crypto access control list that identifies interesting traffic that will trigger the VPN to activate.
-
Finally, the crypto map is applied to the interface.
ISAKMP Policy
Whenever an IPsec VPN is initiated, the first stage is to negotiate and exchange credentials with a peer. This exchange uses the protocol called ISAKMP on UDP port 500. The ISAKMP parameters are configured using the crypto isakmp policy command, which opens the crypto subconfiguration mode. This command enables you to specify the following:
-
Which authenticated method will be used
-
Which encryption method to use
-
Which hashing method to use
-
How long of a random number to use when creating unique key strings between peers
-
How long before these parameters have to be exchanged
| Note | Other optional features that may be configured include Dead Peer Detection (DPD), using the crypto isakmp keepalive command. However, this is beyond the scope of this book. For more information on these topics, see Cisco.com. |
IPsec Details
IPsec is the framework that enables a VPN tunnel to be created. Specifically, the crypto ipsec transform-set command identifies how the packets will be encapsulated by identifying an acceptable combination of security protocols, algorithms, and other settings to apply to IPsec-protected traffic. During the IPsec security association (SA) negotiation, the peers agree to use a particular transform set when protecting a particular data flow.
VPN Tunnel Information
Once the ISAKMP and IPsec parameters are identified, the actual VPN tunnel specifics must be entered. The crypto map command enters a subconfiguration mode where you can create or edit a named entry that specifies the VPN settings to apply them to an interface.
The crypto map is where you specify the following:
-
The predefined ISAKMP settings to use
-
Which IPsec transform set to use
-
Which peer router to establish an IPsec VPN tunnel with
-
Which ACL will be used to identify interesting traffic
-
How long the security association should be kept before it is renegotiated
Conceptually, a crypto map is similar to a funnel. The funnel, shown in Figure 7-19, channels all configuration components to the appropriate interface, serving as initiation and termination point of IPsec tunnels. You configure the IPsec settings, group them together in a crypto map, and then apply the crypto map to the interface. When traffic meets the criteria, it passes through the funnel, and its policies are enforced. Traffic that does not meet criteria configured in the crypto maps leaves the Internet-facing interface unencrypted.
This crypto map-to-interface association will indicate where initiation and termination of the tunnel occur, thus identifying the interface requiring additional configuration for VPN to work, such as allowing dynamic routing and tuning address translations. In Figure 7-19, crypto maps are applied to the VPN router interface facing the public.
VPN ACL
Typically, traffic exiting a branch site is destined for the corporate LAN and thus should be protected. Otherwise, traffic is destined for the Internet and an IPsec VPN is not required to protect it.
The crypto ACL is an extended IP ACL that is used to identify the traffic that should be protected. A permit statement in a crypto ACL will result in the traffic being encrypted, and a deny statement will result in the traffic being sent out by the Internet-facing interface in clear text.
Both VPN peers must have reciprocating ACLs. For instance, the branch router requires an extended ACL to identify traffic going from its LAN to the HQ LAN, whereas the HQ router requires an ACL to identify traffic going from its LAN to the branch LAN.
Apply the Crypto Map
Finally, the named crypto map must be applied to the Internet-facing interface that the peering router will connect to. The map entry is identified using the crypto map interface configuration command. Once configured, all traffic exiting the interface is subject to filtering by the crypto map ACL. If the traffic matches the ACL, the router will begin the process to encrypt and tunnel traffic across to the VPN peer.
Verifying an IPsec VPN
Various commands can be used to verify whether a VPN is functioning properly. Which you choose will depend on the information you want. For example, to display the specifics contained in a crypto map configuration, use the show crypto map command, as explained in Table 7-7.
Table 7-7: show crypto map Command
Open table as spreadsheet | Parameter | Description |
| interface interface | (Optional) Displays only the crypto map set applied to the specified interface |
| tag map-name | (Optional) Displays only the crypto map set with the specified map-name |
To display status information for active crypto sessions, use the show crypto session command. The details are shown in Table 7-8.
Table 7-8: show crypto session Command
Open table as spreadsheet | Parameter | Description |
| detail | (Optional) Provides more detailed information about the session, such as the capability of the Internet Key Exchange (IKE) SA, connection ID, remaining lifetime of the IKE SA, inbound or outbound encrypted or decrypted packet number of the IPsec flow, dropped packet number, and kilobyte per second lifetime of the IPsec SA |
| local ip-address | (Optional) Displays status information about crypto sessions of a local crypto endpoint |
| port local-port | (Optional) Port of the local crypto endpoint |
| remote ip-address | (Optional) Displays status information about crypto sessions of a remote session |
| port remote-port | (Optional) Displays status information about crypto sessions of a remote crypto endpoint |
| active | (Optional) Displays all crypto sessions in the active state |
| standby | (Optional) Displays all crypto sessions that are in the standby state |
Use the show crypto ipsec sa command to display the settings used by current SAs. The details of the command are in Table 7-9.
Table 7-9: show crypto ipsec sa Command
Open table as spreadsheet | Parameter | Description |
| map map-name | (Optional) Any existing SAs that were created for the crypto map set named map-name are displayed. |
| address | (Optional) All existing SAs are displayed, sorted by the destination address (either the local address or the address of the IPsec remote peer) and then by protocol (AH or ESP). |
| identity | (Optional) Only the flow information is displayed. It does not show the SA information. |
| interface interface | (Optional) All existing SAs created for an interface that is named interface are displayed. |
To view real time IPsec events, use the debug crypto ipsec command. This command has no arguments or keywords.
Example of IPsec VPN Verification
Continuing with our scenario, recall that the security team of the organization has configured the Branch and HQ routers to support VPN connectivity. Your role is to confirm that the IPsec tunnel is up and to add the necessary configuration to ensure that routing is successful. Therefore, only the IPsec commands related to confirming that IPsec is working are covered in this book.
In Example 7-26, interesting traffic was identified by ACL 110, and therefore we will initiate interesting traffic and then display the VPN tunnel information using the show crypto session command. However, to observe the IPsec events as they happen, we will initially enable the debug crypto ipsec command, as shown in Example 7-27.
Example 7-27: Initiating an IPsec VPN Tunnel
Branch#debug crypto ipsec
Crypto IPSEC debugging is on
Branch#ping 10.10.10.1 source 192.168.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/56/60 ms
Branch#
Branch#show crypto session
Crypto session current status
Interface: Serial0/0/1
Session status: DOWN
Peer: 209.165.200.226 port 500
IPSEC FLOW: permit ip 192.168.1.0/255.255.255.0 10.10.10.0/255.255.255.0
Active SAs: 0, origin: crypto map
Branch#
Although the ping was successful, it appears that the tunnel is down. Recall that in the last implementation step, we implemented NAT. Perhaps this is causing some problems with the IPsec tunnel being created.
To test this, we will enable the debug ip nat command and reissue the extended ping, as shown in Example 7-28.
Example 7-28: Debugging NAT in an IPsec VPN Tunnel
Branch#debug ip nat
IP NAT debugging is on
Branch#ping 10.10.10.1 source 192.168.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/57/60 ms
Branch#
*Mar 26 16:35:21.251: NAT: s=192.168.1.1->209.165.200.249, d=10.10.10.1 [35]
*Mar 26 16:35:21.307: NAT*: s=209.165.200.238, d=209.165.200.249->192.168.1.1 [35]
*Mar 26 16:35:21.307: NAT: s=192.168.1.1->209.165.200.249, d=10.10.10.1 [36]
*Mar 26 16:35:21.367: NAT*: s=209.165.200.238, d=209.165.200.249->192.168.1.1 [36]
*Mar 26 16:35:21.367: NAT: s=192.168.1.1->209.165.200.249, d=10.10.10.1 [37]
*Mar 26 16:35:21.423: NAT*: s=209.165.200.238, d=209.165.200.249->192.168.1.1 [37]
*Mar 26 16:35:21.423: NAT: s=192.168.1.1->209.165.200.249, d=10.10.10.1 [38]
*Mar 26 16:35:21.479: NAT*: s=209.165.200.238, d=209.165.200.249->192.168.1.1 [38]
Branch#
*Mar 26 16:35:21.483: NAT: s=192.168.1.1->209.165.200.249, d=10.10.10.1 [39]
*Mar 26 16:35:21.539: NAT*: s=209.165.200.238, d=209.165.200.249->192.168.1.1 [39]
Branch#
Again, the pings are successful. Notice, however, that the internal IP address is being translated to a global NAT IP address, making the source traffic uninteresting.
We started this section with the intention to understand the impact on routing services and addressing schemes when deploying IPsec VPNs at branch office routers. Corporate LAN-to-LAN IPsec traffic does not need to be translated. It should remain private in its path, because it is encapsulated inside another IP packet. However, NAT can interfere with this process.
Because the NAT process takes place before the encryption process, by the time the traffic arrives at the crypto map ACL, it looks like it is from 209.165.200.248 /29 going to 10.10.10.0. In Example 7-29, we used the command show ip access-lists to display the content of the configured ACLs.
Example 7-29: show ip access-lists 110 Command
Branch#show access-lists
Extended IP access list 110
10 permit ip 192.168.1.0 0.0.0.255 10.10.10.0 0.0.0.255
Extended IP access list BRANCH-NAT-ACL
10 permit ip 192.168.1.0 0.0.0.255 any (1 match)
Branch#
ACL 110 identifies interesting VPN traffic, and the BRANCH-NAT-ACL identifies traffic to be translated. Notice that the crypto map ACL 110 is configured to encrypt traffic between 192.168.1.0/24 to 10.10.10.0/24, but the traffic arrives at the crypto process with a 209.165.200.248 address. So, the crypto map does not encrypt it. We can therefore deduce that our current NAT configuration is creating the problem and will need to be tuned.
The solution to this NAT problem is to create a NAT exemption. The NAT access list that defines traffic that will be translated can also identify when traffic should not be translated. For the NAT process, a permit line in an access list means “translate,” and a deny line means “do not translate.”
On our branch router, we need to alter the NAT ACL so that it excludes the VPN traffic from being translated, as shown in Example 7-30.
Example 7-30: Alter the NAT ACL
Branch#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Branch(config)#no ip access-list extended BRANCH-NAT-ACL
Branch(config)#ip access-list extended BRANCH-NAT-ACL
Branch(config-ext-nacl)#deny ip 192.168.1.0 0.0.0.255 10.10.10.0 0.0.0.255
Branch(config-ext-nacl)#permit ip 192.168.1.0 0.0.0.255 any
Branch(config-ext-nacl)#^Z
Branch#
Now test our link again using an extended ping, as shown in Example 7-31.
Example 7-31: Test the VPN Link
Branch#ping 10.10.10.1 source 192.168.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/57/60 ms
Branch#
*Mar 26 17:47:15.842: NAT: s=192.168.1.1->209.165.200.249, d=10.10.10.1 [70]
*Mar 26 17:47:15.898: NAT*: s=209.165.200.238, d=209.165.200.249->192.168.1.1 [70]
*Mar 26 17:47:15.902: NAT: s=192.168.1.1->209.165.200.249, d=10.10.10.1 [71]
*Mar 26 17:47:15.958: NAT*: s=209.165.200.238, d=209.165.200.249->192.168.1.1 [71]
*Mar 26 17:47:15.958: NAT: s=192.168.1.1->209.165.200.249, d=10.10.10.1 [72]
*Mar 26 17:47:16.014: NAT*: s=209.165.200.238, d=209.165.200.249->192.168.1.1 [72]
*Mar 26 17:47:16.018: NAT: s=192.168.1.1->209.165.200.249, d=10.10.10.1 [73]
*Mar 26 17:47:16.074: NAT*: s=209.165.200.238, d=209.165.200.249->192.168.1.1 [73]
Branch#
Again, the ping is successful, but it appears that NAT still translated the inside LAN address. Verify the NAT translation as shown in Example 7-32.
Example 7-32: Display the NAT Translations
Branch#show ip nat translations
Pro Inside global Inside local Outside local Outside global
icmp 209.165.200.249:18 192.168.1.1:18 209.165.200.238:18 209.165.200.238:18
—- 209.165.200.249 192.168.1.1 —- —-
—- 209.165.200.254 192.168.1.254 —- —-
Branch#
Notice that the 192.168.1.1 address is still in the NAT cache. This is the cause of our current problem. The NAT translations should be cleared, and only then will the branch router enforce the new BRANCH-NAT-ACL entries.
Clear the NAT translations and reissue the extended ping, as shown in Example 7-33.
Example 7-33: Clear the NAT Translation and Test the VPN Link
Branch#clear ip nat translation *
Branch#clear crypto isakmp
Branch#clear crypto sa
Branch#ping 10.10.10.1 source 192.168.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.1.1
*Mar 26 18:28:45.166: IPSEC(sa_request): ,
(key eng. msg.) OUTBOUND local= 209.165.200.242, remote= 209.165.200.226,
local_proxy= 192.168.1.0/255.255.255.0/0/0 (type=4),
remote_proxy= 10.10.10.0/255.255.255.0/0/0 (type=4),
protocol= ESP, transform= esp-3des esp-sha-hmac (Tunnel),
lifedur= 3600s and 4608000kb,
spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x0
*Mar 26 18:28:45.730: IPSEC(validate_proposal_request): proposal part #1
*Mar 26 18:28:45.730: IPSEC(validate_proposal_request): proposal part #1,
(key eng. msg.) INBOUND local= 209.165.200.242, remote= 209.165.200.226,
local_proxy= 192.168.1.0/255.255.255.0/0/0 (type=4),
remote_proxy= 10.10.10.0/255.255.255.0/0/0 (type=4),
protocol= ESP, transform= NONE (Tunnel),
lifedur= 0s and 0kb,
spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x0
*Mar 26 18:28:45.730: Crypto mapdb : proxy_match
*Mar 26 18:28:45.734: IPSEC(key_engine): got a queue event with 1 KMI message(s)
*Mar 26 18:28:45.734: Crypto mapdb : proxy_match
*Mar 26 18:28:45.734: IPSEC(crypto_ipsec_sa_find_ident_head): reconnecting with
the same proxies
and peer 209.165.200.226
*Mar 26 18:28:45.734: IPSEC(policy_db_add_ident): src 192.168.1.0, dest
10.10.10.0, dest_port 0
*Mar 26 18:28:45.734: IPSEC(create_sa): sa created,
(sa) sa_dest= 209.165.200.242, sa_proto= 50,
sa_spi= 0xADDF016B(2917073259),
sa_trans= esp-3des esp-sha-hmac , sa_conn_id= 2009
*Mar 26 18:28:45.738: IPSEC(create_sa): sa created,
(sa) sa_dest= 209.165.200.226, sa_proto= 50,
sa_spi= 0x1C838B72(478382962),
sa_trans= esp-3des esp-sha-hmac , sa_conn_id= 2010
*Mar 26 18:28:45.738: IPSEC(update_current_outbound_sa): updated peer
209.165.200.226 current
outbound sa to SPI 1C838B72!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 88/89/92 ms
Branch#
It appears our VPN link has been activated, as evidenced by the generated output of the debug crypto ipsec command. Notice, too, that four out of the five pings were successful. Typically, the initial traffic that initiates the VPN tunnel may time out, which in this case made the first ping fail.
Example 7-34 provides a quick look at the show crypto session command.
Example 7-34: Display Crypto Session Information
Branch#show crypto session
Crypto session current status
Interface: Serial0/0/1
Session status: UP-ACTIVE
Peer: 209.165.200.226 port 500
IKE SA: local 209.165.200.242/500 remote 209.165.200.226/500 Active
IPSEC FLOW: permit ip 192.168.1.0/255.255.255.0 10.10.10.0/255.255.255.0
Active SAs: 2, origin: crypto map
Branch#
As you can see, the session is active with the HQ peer. As an alternative, we could have added the detail keyword as shown in Example 7-35.
Example 7-35: Display the Crypto Session with Detail Information
Branch#show crypto session detail
Crypto session current status
Code: C - IKE Configuration mode, D - Dead Peer Detection
K - Keepalives, N - NAT-traversal, T - cTCP encapsulation
X - IKE Extended Authentication, F - IKE Fragmentation
Interface: Serial0/0/1
Uptime: 00:28:17
Session status: UP-ACTIVE
Peer: 209.165.200.226 port 500 fvrf: (none) ivrf: (none)
Phase1_id: 209.165.200.226
Desc: (none)
IKE SA: local 209.165.200.242/500 remote 209.165.200.226/500 Active
Capabilities:(none) connid:1005 lifetime:23:31:42
IPSEC FLOW: permit ip 192.168.1.0/255.255.255.0 10.10.10.0/255.255.255.0
Active SAs: 2, origin: crypto map
Inbound: #pkts dec'ed 4 drop 0 life (BPSKBPSec) 4444197/1902
Outbound: #pkts enc'ed 4 drop 1 life (BPSKBPSec) 4444197/1902
Branch#
Now we will issue the show crypto ipsec sa command to display the specifics about the current SA, as shown in Example 7-36.
Example 7-36: Display the Crypto IPsec SA Information
Branch#show crypto ipsec sa
interface: Serial0/0/1
Crypto map tag: HQ-MAP, local addr 209.165.200.242
protected vrf: (none)
local ident (addr/mask/prot/port): (192.168.1.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (10.10.10.0/255.255.255.0/0/0)
current_peer 209.165.200.226 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 4, #pkts encrypt: 4, #pkts digest: 4
#pkts decaps: 4, #pkts decrypt: 4, #pkts verify: 4
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 1, #recv errors 0
local crypto endpt.: 209.165.200.242, remote crypto endpt.: 209.165.200.226
path mtu 1500, ip mtu 1500, ip mtu idb Serial0/0/1
current outbound spi: 0x1C838B72(478382962)
inbound esp sas:
spi: 0xADDF016B(2917073259)
transform: esp-3des esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 2009, flow_id: NETGX:9, crypto map: HQ-MAP
sa timing: remaining key lifetime (k/sec): (4444197/3572)
IV size: 8 bytes
replay detection support: Y
Status: ACTIVE
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0x1C838B72(478382962)
transform: esp-3des esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 2010, flow_id: NETGX:10, crypto map: HQ-MAP
sa timing: remaining key lifetime (k/sec): (4444197/3572)
IV size: 8 bytes
replay detection support: Y
Status: ACTIVE
outbound ah sas:
outbound pcp sas:
Branch#
The command confirms that the branch router and HQ router have an established VPN. Also notice that the four successful pings were encapsulated and the return pings were decapsulated.
We have just demonstrated the link and dependencies between VPN and common router services such as NAT.
Impact on Routing
One of the significant drawbacks of an IPsec VPN is that it cannot route multicast and broadcast packets. Therefore, interior gateway protocols (IGPs) such as EIGRP and OSPF that use multicast packets cannot send routing advertisements through an IPsec VPN. However, IPsec can be combined with generic routing encapsulation (GRE) to create a tunnel to circumvent the issue with IGP routing within VPN tunnels.
Configuring GRE Tunnels
Even though you might not be responsible for configuring VPN tunnels (after all, it is often the responsibility of the security group staff to do so), you might have to build routing around them. Therefore, if you want the Internet connection to use the IPsec VPN and become the main link back to headquarters, additional configuration will be needed to support dynamic routing protocols.
There are four options to route dynamic routing protocols through an IPsec tunnel:
-
Point-to-point generic routing encapsulation (P2P GRE)
-
Virtual tunnel interface (VTI)
-
Dynamic multipoint VPN (DMVPN)
-
Group encrypted transport VPN (GET VPN)
In this section, we focus on P2P GRE. However, the other options are briefly discussed.
A major benefit of VTI is that the configuration does not require a static mapping of an IPsec session to a physical interface. The IPsec endpoint is associated with an actual virtual interface. This is then a routable interface at the tunnel endpoint, and many common interface capabilities can be applied to the IPsec tunnel. They include the association of routing protocols and therefore routing across the VPN tunnel. In the end, VTI is a good alternative to IPsec over GRE tunnels.
Looking ahead, it is common for dual headend routers to be used for redundancy in bigger scenarios. While looking at Figure 7-20, think of the implications of a full-meshed GRE tunnel where hub-to-spoke routing and spoke-to-spoke routing are required. Nowadays, with VoIP, branch offices expect to call other branch offices directly, without going through headquarters, which would only contribute latency. Configuring GRE tunnels is the way we will do it in the next section; for point-to-point connectivity between every spoke, does not scale well.
Scalable alternatives to GRE when full-mesh connectivity is necessary between the branches are DMVPN and GET VPN. These technologies combine multipoint GRE tunnels, dynamic resolutions of endpoints, and crypto profiles that overwrite the requirement for defining crypto maps.
So, in preparation for more complex scenarios, you may want to read up on backup interfaces, VTI, DMVPN, and GET VPN.
| Note | VTI, DMVPN, and GET VPN are beyond the scope of this book. For more information on these topics, see Cisco.com. |
Generic Routing Encapsulation
GRE is a tunneling protocol developed by Cisco. It is capable of encapsulating a wide variety of network layer protocols packets inside IP tunnels. This creates virtual point-to-point links. It is a common option to use GRE to pass dynamic routing protocol traffic across an IPsec tunnel.
It is worth mentioning, though, that GRE tunnels do not provide encryption services. GRE is just an encapsulation protocol. It does not offer other services such as encryption. By default, the traffic leaves in clear text. In our implementation, however, GRE packets will be encrypted by IPsec.
Point-to-point GRE encapsulates routing protocols in GRE first, and then the GRE packets are encapsulated in IPsec and encrypted. Figure 7-21 shows the encapsulation process. The routing protocols will be associated with tunnel interfaces, which will use the physical interface of the router to send GRE traffic that will then have to match the parameters of the crypto map and therefore be encrypted by IPsec.
With GRE, multicasts and broadcasts will be carried inside unicast packets, which IPsec can forward.
Working with the example we have used in the previous section of this chapter, the payload of GRE packets will be EIGRP routing updates and LAN-to-LAN corporate traffic. The GRE packet will then be encapsulated inside an IPsec packet. This means that the payload of the IPsec packet is a GRE packet, which itself has as payload of an EIGRP packet or user traffic. Therefore, IPsec is the “transport protocol,” and GRE is the “carrier protocol” used to carry other “passenger protocols,” such as IP broadcast or IP multicast, and non-IP protocols, as shown in Figure 7-22.
Figure 7-23 shows the extra overhead created by these additional encapsulations (necessary overhead if we want to pass routing protocols with the current implementation).
Configuring GRE
These following three configuration steps will help us accomplish our goal:
-
Create tunnel interfaces for GRE.
-
Change the crypto ACL to encrypt GRE traffic.
-
Configure routing protocols to route through the GRE tunnel.
We will first configure the tunnel interfaces with GRE encapsulation. We will make sure that the tunnel is up and running. Next, we will make a change to the IPsec configuration to include GRE traffic to the crypto ACL. This will cause GRE traffic, and with it the routing updates, to be channeled across the IPsec VPN tunnel. Finally, we will configure our routing protocol to use the tunnel interface as a routable interface and therefore advertise on it.
| Note | This section covers the basics of configuring GRE over IPv4. For more information, see the Point-to-Point GRE over IPsec Design Guide located at Cisco.com (http://www.cisco.com/en/US/customer/docs/solutions/Enterprise/WAN_and_MAN/P2P_GRE_IPSec/P2P_GRE_IPSec.html). |
A GRE tunnel is created using the interface tunnel 0 command. A tunnel interface is a virtual interface that is assigned an IP address to identify the end of the tunnel. After the tunnel interface has been created and has been configured with an IP address, the actual source of the tunnel is identified using the tunnel source {ip-address | interface-type interface-number} command shown in Table 7-10.
Table 7-10: tunnel source Command
Open table as spreadsheet | Parameter | Description |
| ip-address | IP address to use as the source address for packets in the tunnel. |
| interface-type | Interface type, such as loopback interface. |
| interface-number | Port, connector, or interface card number. The numbers are assigned at the factory at the time of installation or when added to a system and can be displayed with the show interfaces command. |
| Note | A common best practice is to create a loopback interface, which is then used as the tunnel source IP address. |
We also identify the other endpoint of the tunnel with the tunnel destination command shown in Table 7-11.
Table 7-11: tunnel destination Command
Open table as spreadsheet | Parameter | Description |
| type | Type of interface to be configured |
| host-name | Name of the host destination |
| ip-address | IP address of the host destination expressed in dotted-decimal notation |
A GRE tunnel can be configured to operate within an IPv4, IPv6, or multipoint configuration using the tunnel mode gre command. However, by default the encapsulation of GRE is within an IPv4 packet, and therefore the tunnel mode gre ip command is not required.
| Note | The tunnel mode gre ipv6 command is required when configuring GRE over IPv6. This command will be used in the next chapter. |
Example of GRE Configuration
Recall that the long-term goal is to decommission to WAN link completely and use only the VPN connection to communicate between the branch office and the headquarters. We are now ready to so. We’ll use the configuration in Figure 7-24 as our guide as we progress.
Although we now have a working IPsec VPN solution, we need to add routing functionality between sites using a GRE tunnel. To do so, we need to do the following:
-
Create a tunnel interface and configure the specifics such as the tunnel IP address, tunnel source, and tunnel destination.
-
Change the crypto ACL to encrypt GRE traffic.
-
Configure routing protocols to route through the GRE tunnel.
To avoid errant EIGRP neighbor messages from appearing, we will first begin by removing the dynamic routing protocol, as shown in Example 7-37.
Example 7-37: Disable EIGRP
Branch(config)#no router eigrp 1
Branch(config)#
Now we configure the GRE Tunnel 0 interface, as shown in Example 7-38.
Example 7-38: Creating a Tunnel Interface on the Branch Router
Branch(config)#interface tunnel 0
Branch(config-if)#ip address 172.16.100.2 255.255.255.252
Branch(config-if)#tunnel source 209.165.200.242
Branch(config-if)#tunnel destination 209.165.200.226
Branch(config-if)#
*Mar 27 15:45:05.647: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0,
changed state to
up
Branch(config-if)#
The tunnel IP address is 172.16.100.2 /30, which will serve as the tunnel destination in the HQ router tunnel configuration. The tunnel source is the reachable IP address of the Internet-facing interface on the branch router. The tunnel source command is used to specify either the source interface or the source IP address. We have chosen to specify the IP address. The destination of the tunnel interface will be the reachable global IP address of the HQ router.
Notice the console message informing us that the tunnel interface is active.
| Note | GRE over IP is the default encapsulation of GRE tunnel, and therefore the tunnel interface command tunnel mode gre ip is not required. |
Next, we repeat the preceding configurations on the HQ router, as shown in Example 7-39.
Example 7-39: Creating a loopback and Tunnel Interfaces on the HQ Router
HQ(config-if)#no router eigrp 1
HQ(config)#interface Tunnel0
HQ(config-if)#ip address 172.16.100.1 255.255.255.252
HQ(config-if)#tunnel source 209.165.200.226
HQ(config-if)#tunnel destination 209.165.200.242
HQ(config-if)#
*Mar 27 10:50:59.151: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0,
changed state to
up
HQ(config)#
Again, we receive a console message informing us that the tunnel interface is active.
| Note | Optionally, the keepalive command could also be configured to provide a trigger mechanism to cause the line protocol to be changed from an up/up to an up/down state during a failure event. |
To verify the current tunnel interface configuration, we can use the show ip interfaces command, as shown in Example 7-40.
Example 7-40: show interface tunnel 0 on the Branch Router
Branch#show interfaces tunnel 0
Tunnel0 is up, line protocol is up
Hardware is Tunnel
Internet address is 172.16.100.2/30
MTU 17916 bytes, BW 100 Kbit/sec, DLY 50000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation TUNNEL, loopback not set
Keepalive not set
Tunnel source 209.165.200.242, destination 209.165.200.226
Tunnel protocol/transport GRE/IP
Key disabled, sequencing disabled
Checksumming of packets disabled
Tunnel TTL 255
Fast tunneling enabled
Tunnel transport MTU 1476 bytes
Tunnel transmit bandwidth 8000 (kbps)
Tunnel receive bandwidth 8000 (kbps)
Last input never, output never, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/0 (size/max)
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
0 packets output, 0 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 unknown protocol drops
0 output buffer failures, 0 output buffers swapped out
Branch#
Notice that the tunnel is reported to be up/up state and that the encapsulation used is tunnel. We can also confirm the source and destination tunnel IP addresses and that the tunnel protocol is GRE over IP. Remember that GRE over IP is the default for tunnel interfaces, and therefore we did not need to configure that tunnel mode.
No traffic is currently using these tunnel interfaces because our dynamic routing process is not yet aware that it has to use them to communicate.
For this reason, we must now change the crypto ACL to make the GRE traffic interesting and enable the IPsec tunnel. To do so, we will remove the current crypto ACL and replace it, as shown in Example 7-41.
Example 7-41: Replacing the Crypto ACL on the Branch Router
Branch(config)#no access-list 110
Branch(config)#access-list 110 permit gre host 209.165.200.242 host 209.165.200.226
Branch(config)#
The new crypto map ACL specifies that whenever the public IP address of the branch router attempts to send a GRE update to the public IP address of the HQ router an IPsec VPN should be enabled. The reciprocating crypto map is configured on the HQ router, as shown in Example 7-42.
Example 7-42: Replacing the Crypto ACL on the HQ Router
HQ(config)#no access-list 110
HQ(config)#$ access-list 110 permit gre host 209.165.200.226 host 209.165.200.242
HQ(config)#
We should now have basic GRE over IPv4 connectivity. Ping the tunnel IP address as shown in Example 7-43.
Example 7-43: Activating the GRE Tunnel
Branch#ping 172.16.100.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.100.1, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 96/99/100 ms
Branch#
The pings are 80 percent successful, indicating that perhaps the first ping timed out because of the IPsec VPN being activated. Verify the VPN tunnel information using the show crypto session command, as shown in Example 7-44.
Example 7-44: Verifying the IPsec VPN Tunnel
Branch#show crypto session detail
Crypto session current status
Code: C - IKE Configuration mode, D - Dead Peer Detection
K - Keepalives, N - NAT-traversal, T - cTCP encapsulation
X - IKE Extended Authentication, F - IKE Fragmentation
Interface: Serial0/0/1
Uptime: 00:01:38
Session status: UP-ACTIVE
Peer: 209.165.200.226 port 500 fvrf: (none) ivrf: (none)
Phase1_id: 209.165.200.226
Desc: (none)
IKE SA: local 209.165.200.242/500 remote 209.165.200.226/500 Active
Capabilities:(none) connid:1002 lifetime:23:58:21
IPSEC FLOW: permit 47 host 209.165.200.242 host 209.165.200.226
Active SAs: 2, origin: crypto map
Inbound: #pkts dec'ed 4 drop 0 life (BPSKBPSec) 4495373/3501
Outbound: #pkts enc'ed 4 drop 1 life (BPSKBPSec) 4495373/3501
Branch#
| Note | The IPSEC FLOW is permitting IP protocol 47, which is the protocol number for GRE. |
Now we must verify connectivity from the branch LAN to the HQ LAN, as shown in Example 7-45.
Example 7-45: Verifying LAN to LAN Connectivity
Branch#ping 10.10.10.1 source 192.168.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.1.1
.....
Success rate is 0 percent (0/5)
Branch#
Now the LANs can no longer reach each other. Verify the routing table of the branch router, as shown in Example 7-46.
Example 7-46: Routing Table of the Branch Router
Branch#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is 209.165.200.241 to network 0.0.0.0
172.16.0.0/30 is subnetted, 1 subnets
C 172.16.100.0 is directly connected, Tunnel0
209.165.200.0/29 is subnetted, 1 subnets
C 209.165.200.240 is directly connected, Serial0/0/1
C 192.168.1.0/24 is directly connected, FastEthernet0/0
S* 0.0.0.0/0 [171/0] via 209.165.200.241
Branch#
Notice that we have the 172.16.100.0 network connected to the Tunnel 0 interface. In addition, we still have the default static route we configured earlier. However, the branch LAN does not know about the HQ LAN located on 10.10.10.0 /24.
We will now configure EIGRP to propagate the LAN and the tunnel routing information between the sites, as shown in Example 7-47.
Example 7-47: Enabling EIGRP on the Branch Router
Branch(config)#router eigrp 1
Branch(config-router)#network 192.168.1.0 0.0.0.255
Branch(config-router)#network 172.16.100.0 0.0.0.3
Branch(config-router)#no auto-summary
Branch(config-router)#
Next, we configure the HQ router to propagate its LAN and the tunnel routing information, as shown in Example 7-48.
Example 7-48: Enabling EIGRP on the HQ Router
HQ(config)#router eigrp 1
HQ(config-router)#network 10.10.10.0 0.0.0.255
HQ(config-router)#network 172.16.100.0 0.0.0.3
HQ(config-router)#no auto-summary
HQ(config-router)#
*Mar 27 12:02:52.483: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.100.2
(Tunnel0) is up:
new adjacency
HQ(config-router)#
Notice that right away EIGRP formed an adjacency with the branch router using the tunnel interface IP address 172.16.100.2.
From the branch router, verify the EIGRP neighbor, as shown in Example 7-49.
Example 7-49: Verifying the EIGRP Neighbor
Branch#show ip eigrp neighbors
IP-EIGRP neighbors for process 1
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 172.16.100.1 Tu0 14 00:00:27 92 2151 0 3
Branch#
As you can see, we have the HQ router as an EIGRP neighbor through the Tunnel 0 interface. Now verify the routing table for only specific EIGRP information, as shown in Example 7-50.
Example 7-50: Verifying the EIGRP Routing Table
Branch#show ip route eigrp 1
10.0.0.0/24 is subnetted, 1 subnets
D 10.10.10.0 [90/26882560] via 172.16.100.1, 00:04:40, Tunnel0
Branch#
Notice that we see the HQ LAN listed in the routing table.
Now that we have configured EIGRP to work over the IPsec tunnel, using GRE, we will do some tests. Verify connectivity to it using an extended ping and trace commands, as shown in Example 7-51.
Example 7-51: Verifying the EIGRP Routing Table
Branch#ping 10.10.10.1 source 192.168.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 100/100/100 ms
Branch#
Branch#trace 10.10.10.1 source 192.168.1.1
Type escape sequence to abort.
Tracing the route to 10.10.10.1
1 172.16.100.1 68 msec 68 msec *
Branch#
Both are successful. Notice how it appears that the trace has traveled to only one other router. This confirms that packets are indeed traversing the IPsec VPN. Otherwise, the trace would have displayed the actual router IP addresses between the braches and HQ routers.
Verify the IPsec counters using the show crypto session detail command, as shown Example 7-52.
Example 7-52: Verifying the IPsec VPN Information
Branch#show crypto session detail
Crypto session current status
Code: C - IKE Configuration mode, D - Dead Peer Detection
K - Keepalives, N - NAT-traversal, T - cTCP encapsulation
X - IKE Extended Authentication, F - IKE Fragmentation
Interface: Serial0/0/1
Uptime: 00:35:47
Session status: UP-ACTIVE
Peer: 209.165.200.226 port 500 fvrf: (none) ivrf: (none)
Phase1_id: 209.165.200.226
Desc: (none)
IKE SA: local 209.165.200.242/500 remote 209.165.200.226/500 Active
Capabilities:(none) connid:1002 lifetime:23:24:11
IPSEC FLOW: permit 47 host 209.165.200.242 host 209.165.200.226
Active SAs: 2, origin: crypto map
Inbound: #pkts dec'ed 142 drop 0 life (BPSKBPSec) 4495354/1452
Outbound: #pkts enc'ed 211 drop 1 life (BPSKBPSec) 4495345/1452
Branch#
As confirmed in the output, many packets are being decrypted and encrypted on this link. However, not all packets have been generated by the ping and trace commands. Remember that EIGRP is also being transmitted across the IPsec VPN.
Now we test to see which path is taken when we do an extended trace from the branch LAN to the HQ Internet address, as shown in Example 7-53.
Example 7-53: Verifying Internet Connectivity
Branch#trace 209.165.200.226 source 192.168.1.1
Type escape sequence to abort.
Tracing the route to 209.165.200.226
1 209.165.200.241 12 msec 12 msec 16 msec
2 209.165.200.226 28 msec 28 msec *
Branch#
As you can see, regular traffic does not take the GRE over IPsec VPN tunnel.
Example 7-54 shows the final GRE over IPsec configuration in this section.
Example 7-54: Final GRE over IPsec Configuration on the Branch Router
Branch#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Branch(config)#interface tunnel 0
Branch(config-if)#ip address 172.16.100.2 255.255.255.252
Branch(config-if)#tunnel source 209.165.200.242
Branch(config-if)#tunnel destination 209.165.200.226
Branch(config-if)#
*Mar 27 21:58:46.631: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up
Branch(config-if)#exit
Branch(config)#
Branch(config)#
Branch(config)#no access-list 110
Branch(config)#access-list 110 permit gre host 209.165.200.242 host 209.165.200.226
Branch(config)#
Branch(config)#router eigrp 1
Branch(config-router)#network 192.168.1.0 0.0.0.255
Branch(config-router)#network 172.16.100.0 0.0.0.3
Branch(config-router)#no auto-summary
Branch(config-router)#end
Branch#
This concludes our implementation plan to upgrade a branch office.
Specifically, we followed these steps:
We have now completed the branch office update. It is time for us to explore routing solutions for the mobile worker.
1 comments
What is the difference between a router and a modem?
branch office router
Post a Comment