Network Bulls
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
Many options exist today for private connectivity between an Enterprise branch office
and the core of an Enterprise network. These options include leased lines, Frame Relay,
MPLS VPNs, and Metro Ethernet. Although each differs in some way, they all share an
important characteristic: They provide an inherently private path over which two Enterprise
routers can send packets to each other.
Several other public options exist for branch office connectivity. All these options use the
Internet for connectivity between the branch office and the core of the Enterprise network.
Regardless of the particular physical Internet access technology–typically digital
subscriber line (DSL), cable, or wireless broadband–all these options use a public Internet
to forward the packets.
The differences between the public Internet and private connectivity mean that the
branches need to use several additional functions just to make the connectivity work, plus
the branches need to add other functions to make the connection secure. This chapter focuses
on the functions required, and how they impact routing between the branch and the
rest of the Enterprise.
The branch routing for the Internet-connected branch differs in part depending on the design.
Figure 19-1 shows three examples of branch offices of different sizes. The figure labels
these branches as small, medium, and large, but frankly, those descriptions are a bit
subjective. For the purposes of this chapter, as the size increases, the number of connections
or routers increases, and with that, the number of issues to consider also increases.
For the small branch design, most of the implementation challenges fall into two main categories:
features needed for communication with hosts in the public Internet, and features
needed to support secure communications with hosts in the Enterprise. The first category
includes the Internet access details–how to make DSL, cable, and so on work–plus services
likely to be required to learn, allocate, and translate the public IP addresses learned
from the ISP, such as NAT and DHCP. The second category focuses on virtual private network
(VPN) options that allow the Enterprise to trust that a packet comes from a legitimate
branch office, and to prevent attackers from reading the contents of the packet as it
crosses the Internet.
The rest of this first section of the chapter gives an overview of the various pieces of the
puzzle of supporting private Enterprise traffic, over the public Internet, between the
branch and the rest of the Enterprise.
Broadband Internet Access Basics
The term broadband has been around in the world of networking for a long time. The
original meaning related to the frequency bands used by some Layer 1 standards that used
a wider (broader) range of frequencies to achieve a higher bit rate. Today, the term broadband
has grown to become synonymous with high speed.
Based Access Control (CBAC) and newer IOS Zone-Based Firewall. Cisco also supplies
the IOS IPS feature as well.
Although it may seem that running such features on a branch router might overload the
router, Cisco designed its Integrated Services Routers (ISR) to have the power to concurrently
run many services for exactly this type of application. ISRs include the older model
series 800, 1800, 2800, and 3800 ISR families, plus model series 1900, 2900, and 3900, introduced
in 2009.
Using IPsec Tunnels
The technologies reviewed up to this point, when implemented at the branch, give hosts
at the branch the capability to access hosts in the Internet, and to do so securely. However,
the hosts at the branch typically cannot access applications inside the Enterprise at
this point.
Several problems prevent the branch hosts from accessing hosts with private IP addresses
inside the Enterprise core. One problem is that packets from branch hosts at this point
look like packets from any other Internet-based hosts, and the Enterprise firewall could
(and should) discard such packets. For example, if a branch host tries to send a packet to a
host inside the Enterprise core, the branch would NAT the packet to use the branch’s public
IP address. When that packet arrives at the Enterprise’s firewall at the company’s main
Internet connection, the firewall would have no way to know whether the packet came
from a legitimate host at the branch. One solution would be to allow packets past the firewall,
making the server available to the Internet, and rely on host security to prevent access,
but that may be too risky.
To solve this problem, typically the engineer configures a tunnel between the branch and
the Enterprise core. Then the branch router directs traffic destined for the Enterprise
through the tunnel. For such packets, the branch router will not translate the IP address of
the original packet using NAT. Instead, the branch router will encrypt the IP packet and
encapsulate the encrypted packet inside another IPv4 header, using public source and destination
addresses in this new packet. Then, the branch router can forward this packet
through the public Internet, with a device in the Enterprise core receiving and decrypting
the packet. That device can tell from additional security headers in the encrypted packet
whether it comes from a trusted branch router. Figure 19-4 shows an example of the
process.
Following the steps in Figure 19-4:
Step 1. PC1 creates a packet, with its own 10.99.1.1 address as source, and server
S1’s 10.1.1.1 IP address as destination. PC1 sends the packet to its default
gateway (BO1).
Step 2. When Router BO1 tries to route the packet toward the Internet, the router’s
logic tells it to check an ACL. All packets permitted by the ACL go through
the tunnel–in this case, all packets destined for 10.0.0.0/8, the private network
used by this Enterprise.
Step 3. Router BO1 encrypts the original packet so that no one in the Internet can
read the data.
Step 3. PC1 sends another packet; this one is destined for the public web server’s public
IP address.
Step 4. Router BO1 does not match the packet with its IPsec ACL, so BO1 just routes
the packet out its Internet connection, after using NAT.
Routing in Medium and Large Branches
The final concept in this broad overview section has to do with routing in medium and
large branches, after the branch has a working Internet connection plus an IPsec tunnel. In
the medium- and large-branch examples, another private WAN connection exists between
the branch and the Enterprise core. So, the branch needs to make choices about when to
use routes that use the private connection and when to use routes that use the public connection.
Likewise, the routers in the Enterprise need to make good routing choices about
how to route packets back to the branch.
Focusing on the branch router’s logic, two main options exist: using static routes and using
an IGP. Static routes can be used to forward traffic over the private connection and
over the IPsec tunnel. However, IPsec does not directly support IGP protocols, because
the IPsec tunnel cannot natively forward IPv4 multicasts. To overcome this restriction,
you can use a GRE tunnel that actually runs over the IPsec tunnel. GRE supports multicasts
by encapsulating them in unicast packets, so GRE supports IGPs. Summarizing, by
using GRE, you get the following features:
■ A GRE tunnel acts like a point-to-point link from a Layer 3 perspective.
■ A GRE tunnel supports many passenger protocols, including IPv4.
■ A GRE tunnel encapsulates/forwards broadcasts and multicasts, therefore supporting
IPv4 IGPs.
■ Although not mentioned in Chapter 18, GRE tunnels can run through IPsec tunnels.
After configuring a GRE tunnel to run over the IPsec tunnel on a medium or large branch,
from a routing perspective, the branch now has two Layer 3 paths to the rest of the Enterprise
network: out the GRE tunnel interface and out the private WAN interface. Then you
can run an IGP on each, and the branch can choose which path is best using the usual IGP
criteria. Figure 19-6 shows an example with a single branch router, a leased line, and a
GRE tunnel running through the Internet.
For the network in the figure, branch Router BO1 has two possible outgoing interface
choices for any static or IGP-learned route: interface S0/0 (the leased line) or tunnel0 (the
GRE tunnel). When a packet arrives at BO1, if the route forwards the packet over tunnel0,
the next step in the logic triggers the GRE tunnel logic, encapsulating the packet. Then,
that packet matches the IPsec ACL for all packets destined for network 10.0.0.0/8 (in this
case) and causes the IPsec process to occur. The IPsec-generated packet can then be
routed through the public Internet.
Note: Figure 19-12, in the section “Summary–Branch Routing from PC1 to Enterprise
Server S1,” shows the encapsulation used to support the design shown in Figure 19-6.
www.CareerCert.info
658 CCNP ROUTE 642-902 Official Certification Guide
BO1
Enterprise
R1 Core
IPsec Tunnel
Tu0
GRE
Tu1
GRE
S0/0
Ent1
Figure 19-6 Competing Routes–Private Link and GRE Tunnel
Next, the text examines the static routing option at the branch, followed by the option to
use IGPs and GRE tunnels.
Routing Using Floating Static Routes
A floating static route occurs when the ip route command configures a static route in
which the command overrides the default AD value of 1. With a higher AD for the static
route, the router may consider some other routes for that same prefix as being better. For
example, if the IGP learns a route for the same prefix as defined in the static route, the
router does not use the static route with the higher AD, instead uses the dynamically
learned route with the lower AD. Should the dynamically learned route fail, the router
adds the static route back to the IP routing table. The term floating static refers to that the
route may float in and out of the routing table.
A branch router can use a floating static route directing Enterprise traffic over the Internet,
but only using that route when the IGP-learned route over the private link fails. Often,
the branch design uses the Internet connection just as a backup for the private link into
the Enterprise. To implement such a design, a branch router can use a floating static route
for the route over the Internet, only using that route when the IGP-learned route over the
private link fails. For example, in Figure 19-6, Router BO1 could use EIGRP over the
leased line and configure a floating static route for 10.0.0.0/8 that routes traffic over the Internet
connection. Router BO1 would prefer an EIGRP learned, AD 90 route for 10.0.0.0/8
instead, until that route through S0/0 failed.
Note that to use the floating static route option, a GRE tunnel would not be required, because
the routers do not need to use an IGP through the Internet.
Dynamic Routing over the GRE Tunnel
If the design engineer decides that the branch router should use both paths into the Enterprise,
a somewhat simple solution exists. Simply configure an IGP to run as normal, over
both the private WAN connection and over a GRE tunnel. For example, with Figure 19-6,
enable EIGRP on the branch Router BO1 on both interface S0/0 and Tu0. The design can
then use all the usual tools to manipulate the choice of routes, including tuning the metrics
and configuring variance to influence load sharing.
Key
Topic
www.CareerCert.info
Chapter 19: Routing over Branch Internet Connections 659
This concludes the overview of branch office routing. The next two major sections of this
chapter examine broadband access and IPsec VPNs. These sections go a little deeper on
the concepts and show sample configurations for perspective.
No comments:
Post a Comment