CCNP Route Notes Branch Office Connectivity

The needs of branch offices are changing. This is due to the adoption of unified networks that support voice, video, and
data; the consolidation of IT resources; and the physical mobility of many users.

Branch Office Design Considerations

Some design considerations for branch offices include

Connectivity technologies: What WAN options are available?
Resiliency: How much downtime can the site tolerate? Are there alternate WAN paths available?
Routing: Will the WAN support routing protocols?
Services: Are services such as NAT, WAN optimization, and QoS needed at the branch?
Security and compliance: What security is needed, where will it be placed, and how will that affect routing?
Mobility: Do teleworkers use this branch for VPN access?

Strive for a consistent design across your branch offices, with a structured method of handling change management and configuration. Branch offices have different needs from campus locations, but you can still have a common design foundation by creating standard designs for different size offices. Each category of branch office is its own “place in the network.” Categorize offices not only by the number of users they have, but also by how critical the branch is. The following office profiles are meant as a baseline, not a recommendation for every network.

Small Branch Office Design

A small branch office typically leverages an ISR router to provide multiple services such as WAN and PSTN connectivity,
NAT, WAN optimization, firewall, and DHCP. Its WAN connectivity might be a T1 primary link with a cable or DSL
backup link using an IPsec VPN. You might run a routing protocol or simply use floating static routes. The infrastructure
typically consists of Layer 2 switching—either internal to the router or using an external switch, computers, phones, and
printers.

This design is cost-effective and provides minimum devices to manage. However, network resiliency suffers because the
router is a single point of failure.

Medium Branch Office Design

A medium-sized branch office requires some additional resiliency and network equipment. There typically are redundant
WAN routers with dual connections to a private WAN using either MPLS or Frame Relay. The routers will be higher
capacity devices but might still provide services such as firewall, NAT, DHCP, and WAN optimization. The network
might use a FHP such as HSRP. The infrastructure typically consists of either Layer 2 or Layer 3 external switches,
computers, phones, and printers.

This design is more resilient than the small office design. However, the dual paths add path control complexity and dynamic
routing is needed to accomplish load sharing across the links. Documenting traffic flows becomes more important.

Large Branch Office Design

A large branch office is similar to a campus design in that it typically uses a layered design with redundancy at all but the
access layer. Stand-alone devices for firewalls and WAN optimization might be used, along with multilayer switches. This
branch can provide services to other branches and can thus benefit from an MPLS WAN with its any-to-any connectivity.
The infrastructure is engineered for high availability. It typically consists of dual WAN access routers, dual distribution
switches, and dual firewalls.

This design adds more complexity to the routing structure and might require route redistribution and filtering. Regulatory
requirements can lead to deploying overlay VPNs such as Dynamic Multipoint VPN (DMVPN) or Group Encrypted
Transport VPN (GET VPN).

Implementing Branch Offices

A full branch office implementation plan aims to integrate the new design without disrupting the existing users. It would include the following items:

Deployment strategy
Network diagrams
Installation and site tests
Site survey results
Installation guidelines
Device-specific configuration templates
Test and acceptance plan
Documentation of the new network

Verifying Existing Services

Because a CCNP-level engineer should handle the device configuration, we start at that step of the plan. The implementation is likely an upgrade to an existing branch office network, so the first step is to identify and document the current configuration of every device and the services it provides. These services might include NAT, HSRP, ACLs, firewall, or redirection services such as PBR or WCCP. The IP address schema must also be documented.

To see the NAT settings, you might use the commands show ip nat translations and show ip nat statistics. To document
DHCP, use the commands show ip dhcp pool and show ip dhcp server statistics. The show access-lists and show ip interface commands give you information about ACLs and where they are applied. To see what IOS firewall rules are in
place, use the commands show ip inspect interfaces and show zone-pair security. Verify HSRP operation with show
standby brief. The command show ip policy displays any PBR policies.

Configuring a Backup DSL Connection

Assume that this branch already has a WAN connection, and you are adding redundancy by provisioning a backup DSL connection. Voice does not use all the available bandwidth on a phone line; it uses frequencies up to only approximately 3
kHz. DSL was created to use the space between 3 kHz and 1 MHz to send data traffic over a telephone local loop. Thus, both voice and data can be sent simultaneously over the same connection. (Some variants of DSL use the entire spectrum, however, so no voice can be sent.) DSL is a physical layer medium that extends between the subscriber’s DSL modem and the provider’s DSL Access Multiplexer (DSLAM).

Asymmetrical DSL has higher downstream (from the provider’s Central Office to the subscriber) bandwidth than upstream (from the subscriber to the CO.) Symmetrical DSL has the same bandwidth both downstream and upstream. You sometimes see these referred to as “asynchronous” and “synchronous” DSL.

The various types of DSL include

ADSL: Asymmetric DSL supports both voice and data. Downstream bandwidth goes up to 8 Mbps; upstream goes up to 1 Mbps. Two other versions, ADSL2 and ADSL2+, provide 24 Mbps downstream and 1.5 Mbps upstream. The maximum distance from the CO is 18,000 feet, or 5.46 km.
VDSL: Very-high-rate DSL can be either symmetric or asymmetric and can carry voice along with data. Maximum symmetric bandwidth is 26 Mbps; maximum asymmetric is 52 Mbps downstream and 13 Mbps upstream. The maximum distance from the CO is 4,500 feet, or 1.37 km.
SDSL: Symmetric DSL carries only data, with a maximum for both downstream and upstream of 768 kbps. The distance limitation is 22,000 feet, or 6.7 km. It is a proprietary technology that uses only one twisted pair of wires. n HDSL: High-data-rate DSL uses two twisted pairs of wires to achieve a maximum symmetrical bandwidth of 2.048 Mbps. Its maximum distance from the CO is 12,000 feet, or 3.7 km. HDSL carries only data, no voice.
G.SHDSL: Symmetric High-speed DSL has a symmetrical data rate of 2.3 Mbps and the longest maximum distance: 28,000 feet, or 8.52 km. It also carries only data, no voice.

Figure 7-1 shows how ADSL components work together in a typical residential implementation. The telephone company’s Central Office forwards both POTS and DSL data traffic over the same line to the subscriber. The line enters at the Network Interface Device (NIDS) and branches toward the telephone and the PC. A low-pass filter blocks everything but voice frequencies from reaching the phone. A DSL modem (or router with a DSL interface) forwards data to the PC. When the Central Office receives traffic from the subscriber, a splitter sends voice frequencies to the PSTN switch and DSL frequencies to the DSLAM. The DSLAM sends data traffic to a router for forwarding to the Internet.

FIGURE 7-1 Components of an ADSL System

Recall that DSL is a Layer 1—Physical Layer—technology. Following are the three methods of carrying data at Layer 2 over DSL:

Bridging: Based on RFCs 1483 and 2684. Ethernet traffic is just bridged from the subscriber PCs, through the DSL modem and the DSLAM, to a provider router. Is not as secure or scalable as other methods.
Point-to-Point Protocol over Ethernet (PPPoE): The most common Layer 2 method of carrying data over DSL. PPP traffic is encapsulated in Ethernet frames.
Point-to-Point Protocol over ATM (PPPoA): PPP packets are routed over ATM between the subscriber equipment and the provider.

In the following example we use PPoA, which requires a CPE router because traffic is routed from the subscriber PCs to the aggregation router. The PPP session is established between the CPE router and the aggregation router. Either Password Authentication Protocol (PAP) or Challenge Handshake Authentication Protocol (CHAP) authentication can be used. Multiple users are supported if the CPE router is configured to do DHCP and NAT. Traffic between the CPE router and the aggregation router is encapsulated as ATM at Layer 2.

When configuring PPPoA you must set up the internal Ethernet interface, a dialer interface, NAT or PAT, DHCP, and a static default route. Because this is ATM, you must configure Virtual Path Identifier (VPI) and Virtual Circuit Identifier (VCI) information on the external interface to match that of the provider. The type of ATM encapsulation must be specified PPPoA must be enabled, and the ATM interface must be linked to the virtual dialer interface. A dialer pool is associated with PVC. The final configuration is shown in the following examples.

Internal Ethernet interface:

interface FastEthernet0/1
description Internal interface
ip address 172.16.1.1 255.255.255.0
ip nat inside

Dialer interface:

interface Dialer1
ip address negotiated
ip mtu 1492
ip nat outside
encapsulation ppp
dialer pool 1
ppp authentication chap
ppp chap password 0 dslpass

Port address translation (PAT)

access-list 100 permit ip 172.16.1.0 0.0.0.255 any
ip nat inside source list 100 interface Dialer1 overload

DHCP:

ip dhcp pool Users
import all
network 172.16.1.0 255.255.255.0
default-router 172.16.1.1
Static default route:
ip route 0.0.0.0 0.0.0.0 Dialer1

External ATM interface:

interface ATM1/0
descrip tion DSL interface
  no ip address
dsl operating-mode auto
pvc 1/100
encapsulation aal5mux ppp dialer
dialer pool-member 1

To verify and troubleshoot the DSL configuration, use the commands show dsl interface atm number, debug atm events,
debug ppp authentication, show ip route, ping, and traceroute.

Configuring an IPsec VPN

IPsec is not covered in depth on the ROUTE exam, but you need to understand it well enough to verify the configuration and add routing across it. This sample branch uses an IPsec VPN to connect to the headquarters when the backup DSL link is active.

When IPsec establishes a VPN between two peer hosts, it sets up a security association (SA) between them. SAs are unidirectional, so each bidirectional data session requires two. The Internet Security Association and Key Management Protocol (ISAKMP) defines how SAs are created and deleted.

An IPsec transform set defines how VPN data will be protected by specifying the IPsec protocols that will be used. You can specify up to four transforms, and the algorithm to use with each. You can also configure either tunnel or transport mode. (Tunnel is default.)

You use a crypto ACL to identify traffic that should be protected by the IPsec VPN. Any traffic permitted in the ACL will be sent over the VPN. Traffic denied by the ACL will not be dropped; it will simply be sent normally.

A crypto map pulls together the transform sets and crypto ACLs and associates them with a remote peer. After the crypto map is configured, it must be applied to an interface for it to take effect. It is applied at the outgoing interface—the one that VPN traffic uses to reach the other end of the VPN. You might need to use a static route or otherwise adjust your routing to force traffic bound for the VPN destination networks to use the correct outgoing interface.

To verify the IPSEC VPN, use the following commands:

show crypto map: Shows the crypto ACLs, any peers, and the interface where the crypto map is applied
show crypto isakmp sa: Shows information about the ISAKMP security associate negotiation process
show crypto IPsec sa: Shows the settings used by current SAs, including tunnel status and peers

Configuring a Floating Static Route

The IPsec tunnel can be used solely as a backup link, or you can load balance between it and the primary link. To use it as a backup link, you can configure a floating static route. A floating static route is one with an administrative distance greater than the primary route. If the primary route is active, the static route will not be placed into the routing table due to its higher AD. But when the primary route is down, the static route will be used.

The command syntax for a floating static route is: ip route destination-network next-hop-address administrative-distance.

You can find the AD of the primary route by using the command show ip protocols. EIGRP has an AD of 90, so you might use 100 as the AD of a floating static route when the primary route is learned via EIGRP.

Configuring Dynamic Routing over a GRE Tunnel

To use the IPsec tunnel as an “always on” connection, you need to send routing updates over it. However, IPsec VPNs do not carry broadcast or multicast traffic. You need to create a tunnel within the IPsec tunnel to carry the routing traffic.

Four ways to do this include

DMVPN: Creates multipoint tunnels on-demand. Good for scenarios when spoke-to-spoke connections are needed.
GET VPN: Creates encrypted multipoint tunnels on-demand. Good for scenarios when secure spoke-to-spoke connections are needed.
Virtual Tunnel Interface (VTI): Creates an always-on tunnel that carries unicast and multicast traffic. Enables you
to configure the routing protocol on the tunnel interface, saving the 4 extra bytes required for a GRE header.
Generic Routing Encapsulation (GRE): GRE is a tunneling protocol that can support multiple Layer 3 protocols.

It enables the use of multicast routing protocols across the tunnel. It adds a 20-byte IP header and a 4-byte GRE header. GRE does not encrypt traffic or use any strong security measures to protect the traffic. GRE can be used along with IPsec to provide data source authentication, data confidentiality, and assurance of data integrity. GRE over IPsec tunnels are typically configured in a hub-and-spoke topology over an untrusted WAN to minimize the number of tunnels that each router must maintain.

In this section, we configure a GRE tunnel to carry EIGRP traffic over the IPSEC tunnel. This basically creates a tunnel within a tunnel, as shown in Figure 7-2.

FIGURE 7-2 GRE over IPSEC Tunnel

Configuring a GRE tunnel is fairly easy. Follow these steps on the routers at each end of the tunnel:

1. Create a loopback interface to use as the tunnel endpoint. Using a loopback rather than a physical interface adds stability to the configuration.
2. Create the GRE tunnel interfaces.
3. Add the tunnel subnet to the routing process so that it exchanges routing updates across that interface.
4. Add GRE traffic to the crypto access list, so that IPsec encrypts the GRE tunnel traffic.

The following example shows a tunnel interface configured for GRE. The mode command is shown only as a reference; because it is the default, it would not normally appear in the configuration:

interface Tunnel1
ip address 172.16.5.2 255.255.255.0
tunnel source Serial0/0
tunnel destination 10.1.1.1
tunnel mode gre ip

To verify the configuration, use the show ip route command and look for the remote routes in the routing table. They should have a next hop of the tunnel interface. A traceroute shows traffic going across the tunnel. The show crypto ipsec sa command output shows increased traffic as the traceroute goes through the tunnel.

Load Sharing with EIGRP

In the EIGRP chapter you saw how EIGRP can load balance across unequal-cost links. Because you have an always-on IPsec tunnel, you might want to use that in addition to your primary route. Use the variance multiplier command under EIGRP configuration mode. Look in the EIGRP topology table to find the metric for the best route and the secondary route. Determine what you need to multiply the best route’s metric by for it to be more than the secondary route’s metric. That is the variance multiplier number that you should use to configure EIGRP to load balance over both paths.

More Resources