BGP Multi Site Multi Homing
BGP Multi Site Multi Homing
BGP Multi Site Multi Homing
March, 2004
Corporate Headquarters
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
USA
http://www.cisco.com
Tel: 408 526-4000
800 553-NETS (6387)
Fax: 408 526-4100
THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL
STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT
WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS.
THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT
SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE
OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY.
The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB’s public
domain version of the UNIX operating system. All rights reserved. Copyright © 1981, Regents of the University of California.
NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED “AS IS” WITH
ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT
LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF
DEALING, USAGE, OR TRADE PRACTICE.
IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING,
WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO
OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
CCIP, CCSP, the Cisco Arrow logo, the Cisco Powered Network mark, Cisco Unity, Follow Me Browsing, FormShare, and StackWise are trademarks of Cisco Systems, Inc.;
Changing the Way We Work, Live, Play, and Learn, and iQuick Study are service marks of Cisco Systems, Inc.; and Aironet, ASIST, BPX, Catalyst, CCDA, CCDP, CCIE, CCNA,
CCNP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, the Cisco IOS logo, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo,
Empowering the Internet Generation, Enterprise/Solver, EtherChannel, EtherSwitch, Fast Step, GigaStack, Internet Quotient, IOS, IP/TV, iQ Expertise, the iQ logo, iQ Net
Readiness Scorecard, LightStream, MGX, MICA, the Networkers logo, Networking Academy, Network Registrar, Packet, PIX, Post-Routing, Pre-Routing, RateMUX, Registrar,
ScriptShare, SlideCast, SMARTnet, StrataView Plus, Stratm, SwitchProbe, TeleRouter, The Fastest Way to Increase Your Internet Quotient, TransPath, and VCO are registered
trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and certain other countries.
All other trademarks mentioned in this document or Web site are the property of their respective owners. The use of the word partner does not imply a partnership relationship
between Cisco and any other company. (0304R)
Overview 1
INDEX
In almost all Enterprise infrastructures today Internet connectivity is universal, although the topology
designs may be unique. This document introduces a reference topology for Internet edge network
deployments. This covers the basis of design principles as well as an introduction of common
deployment barriers related to Internet edge topologies.
Overview
This document identifies and clarifies multi-site Internet edge designs. Multi-site Internet edge design
refers to the instance of having more than one data center connected to the Internet backbone. This can
either imply that each respective data center is multi-homed or has a single connection each. This
architecture includes the core design principles associated with all network infrastructure designs while
paying special attention to the unique requirements relevant to Internet edge multi-site topologies. Like
any infrastructure design, these aformentioned designs must be highly scalable while maintaining the
key aspects of security and redundancy. The key security functions include:
• Element security
• Identity services
• IP anti-spoofing
• Demilitarized zones (DMZ)
• Basic filtering and application definition
• Intrusion detection
The key redundancy functions associated with multi-site topologies are:
• Multiple data centers that act as Internet gateways for internal users.
• Distributed data centers that provide Internet/intranet server farm resiliency.
This document also discusses multi-homing. Multi-homing provides ISP resiliency by connecting each
data center to two or more ISPs depending on the bandwidth requirements, the server farm architecture,
or other internet services. These Internet connections can be a transit point for traffic both inbound to
the architecture and outbound to the Internet backbone for both the Internet/intranet server farms as
depicted in Figure 1. This document also describes and documents some common deployment problems
when introducing distributed data centers into any network topology.
Deploying distributed data centers introduces additional complexities to network administrators who
want to fully utilize both internet gateway locations. These challenges include:
• Application distribution
• DNS propagation
• Replication timeouts
These design issues are covered in the Data Center Networking: Distributed Data Center SRND located
at
http://www.cisco.com/en/US/netsol/ns110/ns53/ns224/ns304/networking_solutions_design_guidances
_list.html.
Internet
Partners
SP1 SP2
PSTN WAN
VPN
Remote
Internet Edge
Office
Internet Gateway
DMZ
Or Or
Extranet
Private Data Center
Internet
WAN
Server
Farm
Corporate
Infrastructure Campus Core
87352
High Availability
With topologies that connect to a single ISP, which is an enterprise connected to a single ISP, the
differences in redundancy reside at the ISP peering point. If you have a single ISP connection at the edge
of your network topology, the need for redundancy is a null issue because you have only a single exit
point. If the primary edge router fails, the Internet connection itself is down. Therefore, defining
redundancy at the edge of the network has no beneficial affect unless the provider supplies two terrestrial
circuits as depicted below. Multi-homing implementations offer redundancy in these instances, as well
as in the instances where there are multiple data centers for a single enterprise. You can leverage each
respective data center for redundancy and scalability, if you partition applications across multiple data
centers for high availability and scalability. For more information on distributed data center topologies,
refer to the Data Center Networking: Distributed Data Center SRND located at
http://www.cisco.com/en/US/netsol/ns110/ns53/ns224/ns304/networking_solutions_design_guidances
_list.html.
Internet
SP 1 SP 2
SP 3
Corporate WAN
87353
West Coast Data Center East Coast Data Center
Multi-site internet edge topologies are also composed of multiple layers. There must be no single point
of failure within the network architecture. Therefore, complete Internet edge device redundancy in this
architecture is a necessity. The infrastructure devices, such as routers and switches, coupled with specific
Layer 2 and Layer 3 technologies, help achieve this device redundancy. To meet this redundancy
requirement, Internet edge topologies use some of the key functions of the IOS software.
The Layer 3 features, used for high availability, offer redundant default gateways for networked hosts
and provide a predictable traffic flow in both normal operating conditions and under the adverse
conditions surrounding a network link or device failure. These Layer 3 features include:
• Hot Standby Router Protocol (HSRP)
• Multigroup Hot Standby Router Protocol (MHSRP)
• Routing protocol metric tuning (EIGRP and OSPF)
These Layer 3 functions also apply to redundancy by offering multiple default gateways in the network
topologies. HSRP and Multigroup HSRP offer Layer 3 gateway redundancy, whereas the dynamic
routing protocols offer a look into network availability from a higher level.
For instance, you could deploy HSRP between the edge routers to propagate a single default gateway
instance to the internal networks. In this case, if the primary router fails, the HSRP address is still active
on the secondary router instance, therefore the defined static route is still valid.
Scalability
The network architecture must be scalable to accommodate increasing user support, as well as
unforeseen bursts in network traffic. While feature availability and the processing power of network
devices are important design considerations; physical capacity attributes, like port density, can limit
architecture scalability. The termination of circuits can become a burden on device scalability within the
border layer of this topology. This burden is the same for the firewall device provisioning layer and the
Layer 3 switching layer. Port density scalability is also important at the Layer 3 switching layer because
it provides additional connections for host devices, in this case, servers.
HSRP
HSRP enables a set of routers to work together, giving the appearance of a single virtual router or default
gateway to the hosts on a LAN. HSRP is particularly useful in environments where critical applications
are running and fault-tolerant networks have been designed. By sharing an IP address and a MAC
address, two or more routers acting as a single virtual router are able to seamlessly assume the routing
responsibility in a defined event or an unexpected failure. This enables hosts on a LAN to continue to
forward IP packets to a consistent IP and MAC address enabling a transparent changeover of routing
devices.
HSRP allows you to configure hot standby groups to share responsibility for an IP address. You can give
each router a priority, which enables you to weight the prioritization of routers for active router selection.
One of the routers in each group is elected to be the active forwarder and one is elected as the stand-by
router. This is done according to the router's configured priorities. The router with the highest priority
wins and, in the event of a tie in priority, the greater value of their configured IP addresses breaks the
tie. Other routers in this group monitor the active and stand-by routers' status to enable further fault
tolerance.
All HSRP routers participating in a standby group watch for hello packets from the active and the
standby routers. They learn the hello and dead timers, as wells as the shared standby IP address from the
active router in the group, if these parameters are not explicitly configured on each individual router.
Although this is a dynamic process, Cisco recommends that you define the HSRP dead timers in the
topology. If the active router becomes unavailable due to scheduled maintenance, power failure, or other
reasons; the stand-by assumes this functionality transparently within a few seconds. Failover occurs
when three successive hello packets are missed and the dead timer is reached. The standby router
promptly takes over the virtual addresses, identity, and responsibility. When the secondary interface
assumes mastership, the new master sends a gratuitous ARP, which updates the L2 switch's content
addressable memory (CAM). This then becomes the primary route for the devices accessing this
gateway. These HSRP timers can be configured on a per instance of HSRP.
physical network. The Internet serves as an example of an entity that uses this type of routing
because it is comprised of autonomous systems or administrative domains. Many of these domains
represent the various institutions, corporations, and entities that make up the Internet. BGP is
frequently used to provide path determination to provide optimal routing within the Internet.
• Intra-autonomous system routing occurs between two or more BGP routers located within the same
autonomous system. Peer routers within the same autonomous system use BGP to maintain a
consistent view of the system topology. BGP is also used to determine which router serves as the
connection point for specific external autonomous systems. Once again, the Internet provides an
example of interautonomous system routing. An organization, such as a university, could make use
of BGP to provide optimal routing within its own administrative domain or autonomous system. The
BGP protocol can provide both inter- and intra-autonomous system routing services.
• Pass-through autonomous system routing occurs between two or more BGP peer routers that
exchange traffic across an autonomous system that does not run BGP. In a pass-through autonomous
system environment, the BGP traffic did not originate within the autonomous system in question and
is not destined for a node in the autonomous system. BGP must interact with whatever
intra-autonomous system routing protocol is being used to successfully transport BGP traffic
through that autonomous system.
BGP Attributes
BGP attributes support the control of both inbound and outbound network routes. These attributes can
be adjusted to control the decision making process of BGP itself. The BGP attributes are a set of
parameters that describe the characteristics of a prefix (route). The BGP decision process uses these
attributes to select its best routes. Specific attributes associated with larger topologies like this one are
addressed later in this document. More specifically, the MED attribute and the use of route reflectors are
addressed.
Figure 3 displays a multi site multi homed topology.
Internet
SP 1 SP 2
SP 3
Corporate WAN
87353
West Coast Data Center East Coast Data Center
Design Caveats
In certain multi-site deployments, device placement becomes a caveat to the overall design. In a specific
instance, the placement of the firewall and how it is introduced into the architecture from a routing
standpoint are of major concern. There are two main caveats to be concerned with when designing your
network:
• Inability to terminate IGP on firewall device
• Lack of upstream route health or interface uptime
In a design where the PIX firewall is placed at the edge of the network between the Internet border
routers and the internet data center core switches, the PIX can become a black hole route to the end-users
that are geographically adjacent to that data center. In detail, when deploying a PIX firewall, the most
common deployment is to have the device configured with static routes upstream to the internet border
routers and with a static route downstream to the internal Layer 3 switching platform. Since static
routing is the configuration of choice, you can assume that the firewall cannot participate in the IGP
routing protocol. If the external routes from the internet border routers disappear from the routing table,
the internal routing process has no idea that this is no longer a valid route to the Internet.
Since the PIX is not participating in an IGP routing protocol, the firewall has no intelligence of the
routing updates that take place above the firewall layer. Therefore, the device still accepts packets
destined for the Internet. This is usually the case because the Layer 3 switching layer below the PIX
device propagates or redistributes a static route of 0.0.0.0 into the IGP downstream.
Work Arounds
The aformentioned problem is common when deploying distributed data centers and has the following
three work arounds:
• The first work around is using the BGP routing protocol to inform the Layer 3 switching platform
of the route change by tunneling the I-BGP traffic through the firewall to the peer on the inside
interface or the Layer 3 switching platform that houses the IGP routing process. This design is
documented in “High Availability via BGP Tunneling.”
• With a future release of HSRP, the you could use HSRP tracking to track the HSRP interface of the
Internet border routers. This assumes that the border routers also implement a tracking instance of
the upstream ISP interfaces. This has not been tested or documented.
• Finally, you could use the Firewall Service Module (FWSM) in the edge Layer 3 switching platform.
This deployment allows you to process OPSF routes internal to the IGP by having the firewall device
participate in the OSPF process. This deployment that has been tested and is documented in this
document.
BGP AS 100
OSPF OSPF
NSSA NSSA
251 252
OSPF Area
0
Corporate LAN
Connectivity
87354
Border Router Layer
Border routers, typically deployed in pairs, are the edge-facing devices of the network. The number of
border routers deployed is a decision of provisioning, based on memory requirements, and physical
circuit termination. The border router layer is where you provision ISP termination and initial security
parameters. The border router layer serves as the gateway of the network and uses an externally facing
Layer 3 routing protocol, like BGP, integrated with an internally facing OSPF to intelligently route
traffic throughout the external and internal networks, respectively. This layer starts the OSPF process
internally into the network. The Internet edge in an enterprise environment may provide Internet
connectivity to an ISP through the use of multi-homed internet border routers. This layer also injects the
gateway of last resort route into the IGP through specific BGP parameters defined below.
Firewall Layer
The firewall layer is a security layer that allows stateful packet inspection into the network infrastructure
and to the services and applications offered in the server farms and database layers. In this topology, the
firewall layer is represented by the FWSM in the Catalyst 6500 series switching platform. This layer also
acts as the network address translation (NAT) device in most design topologies. NAT, at the Internet
edge, is common based on the ever depleting Ipv4 address pool associated with ISP's. This allows many
ISP's to give a limited address range, which, in turn, requires NAT pools at the egress point of the
topology.
Internet ISP
Networks Cloud Networks
1.x.x.x,...5.x.x.x ISP AS 1/2 6.x.x.x,...12.x.x.x
.1 .1
Network Network
East Coast 172.16.11.x 172.16.10.x West Coast
internet edge internet edge
.254 .254
.1 Network Network .1
172.16.253.x FWSM Outside 172.16.254.x
East Coast West Coast
FWSM Intside
edge .100 .100 edge
.2 Network Network .2
.1 172.16.251.x 172.16.252.x .1
Corporate LAN
87355
Connectivity
Implementation Details
Below are the implementation details associated with defining and configuring the multi-site Internet
edge topology. Also, there are specific configurations associated with each layer that allow for the route
control and failover of the topology stated above.
interface Loopback0
ip address 2.0.0.1 255.255.255.0 secondary
ip address 3.0.0.1 255.255.255.0 secondary
ip address 4.0.0.1 255.255.255.0 secondary
ip address 5.0.0.1 255.255.255.0 secondary
ip address 1.0.0.1 255.255.255.0
When looking into the BGP process below, you can see that only specific subnets were defined for
redistribution. Since this solution is not performance focused, the decision was made to only propagate
those routes. This allows for BGP redistribution to the lower layers to ensure that the internal OSPF
redistribution is working correctly.
router bgp 1
network 1.0.0.0
network 2.0.0.0
network 3.0.0.0
network 4.0.0.0
network 5.0.0.0
network 20.10.5.0
network 172.16.11.0
redistribute connected
neighbor 20.10.5.254 remote-as 2
neighbor 172.16.11.254 remote-as 100
The configuration of the second Internet cloud router is the same as the first except that different IP
addresses were used.
hostname InternetCloud2
interface Loopback0
router bgp 2
network 6.0.0.0
network 7.0.0.0
network 8.0.0.0
network 9.0.0.0
network 11.0.0.0
network 12.0.0.0
network 20.10.5.0
network 172.16.10.0
redistribute connected
neighbor 20.10.5.1 remote-as 1
neighbor 172.16.10.254 remote-as 100
!
hostname EdgeRouter1
!
The interface configurations below represent the donwstream link to the outside interface or segment of
the FWSM link:
Note The OSPF hello and dead-interval timers must be the same across all links and interface:
!
interface FastEthernet0/0
ip address 172.16.253.254 255.255.255.0
no ip route-cache
ip ospf hello-interval 1
ip ospf dead-interval 3
no ip mroute-cache
duplex full
!
The following configuration examples are associated with the upstream links to the ISP clouds:
interface FastEthernet3/0
The following OSPF and BGP edge configurations allow the edge to redistribute BGP processes to the
internal network. The redistribute bgp command within the OSPF process causes this redistribution. This
assumes that the router can propagate those routes internal to the other network segments.
Injecting full BGP routes into an IGP is not recommended. Doing so adds excessive routing overhead to
any IGP. Interior routing protocols were never designed to handle more than the networks inside your
autonomous systems, plus some exterior routes from other IGPs.
This does not mean that BGP routes should never be injected into IGPs. Depending on the number of
BGP routes and how critical the need for them to be in the IGP, injecting partial BGP routes into IGP
may well be appropriate.
Below are the OSPF and BGP configurations respectively:
Note Router OSPF is defined as a not so stubby area (NSSA). This is needed to redistribute the external routes
form the upstream routing instance:
For the sake of the testbed topology and to define that routes have been updated properly, specific BGP
routes were redistributed into the architecture:
router ospf 500
log-adjacency-changes
area 251 nssa
redistribute bgp 100
network 172.16.251.0 0.0.0.255 area 251
network 172.16.253.0 0.0.0.255 area 251
Note In typical Internet edge deployments, the edge routing instance does not redistribute the BGP process
into the OSPF process, but rather uses the default-information originate command to define a default
route to edge routing instance. That default route is then redistributed via the OSPF process to the
internal network only if the edge routing instance has a default route itself:
The ACL's below state that if the router has any entry in its routing table from the next hop ISP router,
then it sends the default route internal to the network. This configuration must be deployed on both edge
routing devices.
access-list 1 permit 0.0.0.0
access-list 2 permit 172.16.11.1
Note The route map SEND_DEFAULT_IF is associated with the default-information originate command. This
route map matches on the condition that the 0/0 default (access-list 1) has a next hop of 172.16.11.1
(access-list 2). This satisfies the condition that the 0/0 is learned via EBGP rather than I-BGP.
Below is the BGP routing instance that defines the upstream BGP neighbor that is necessary for the
above route-map to work.
router bgp 100
no synchronization
bgp log-neighbor-changes
network 172.16.11.0
redistribute connected
neighbor 172.16.11.1 remote-as 1
no auto-summary
Below, are the routes available to the East Coast edge routers:
Note Setting the route propagation via OSPF on the FWSM requires defining route-maps that only allow
specific traffic to the edge layer. Therefore, the only internal route propagated is the 172.16.251.x. This
can be controlled by supernetting the segment to allow only specific addresses.
EdgeRouter1#sho ip route
Codes: C - connected, S - static, I - IGRP, 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, E - EGP
i - IS-IS, 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
propagated to the upstream network. This configuration recommendation is to ensure that restricted
routes are not externally advertised. With areas defined this way, you can tune the routes appropriately
by defining route maps to allow a specific network segment outbound. For instance; if you only wanted
to advertise the VIP addresses of the server farm outbound, you could create a route-map that only allows
those specific addresses outbound.
hostname EASTEDGE1
!
Below, is the configuration that associates specific VLAN's with the FWSM. VLAN 200 is the internal
vlan and VLAN 300 is the external vlan:
firewall module 2 vlan-group 1
firewall vlan-group 1 200,300
!
vlan dot1q tag native
Gigabit 1/1 is the downstream link to the OSPF core Layer 3 switching layer. Note it has be configured
to be in VLAN 200:
!
!
interface GigabitEthernet1/1
no ip address
switchport
switchport access vlan 200
FastEthernet 1/1 is the upstream link to the edge routing layer. Note it has be configured to be in VLAN
300:
!
interface FastEthernet3/1
no ip address
duplex full
speed 100
switchport
switchport access vlan 300
!
Note Interface VLAN 200 OSPF configurations are the same across all OSPF interfaces from the timers
perspective:
!
interface Vlan200
ip address 172.16.251.2 255.255.255.0
ip ospf hello-interval 1
ip ospf dead-interval 3
Note The OSPF routing process below is the internal OSPF neighbor to the core switching layer:
Below are the configurations associated with the FWSM. Notice the OSPF configuration in the FWSM
itself and how it binds itself to the OSPF process.
EDGE1# sess slot 2 proc 1
The default escape character is Ctrl-^, then x.
You can also type 'exit' at the remote prompt to end the session
Trying 127.0.0.21 ... Open
FWSM passwd:
ACL 500 defines which addresses need to be matched to support the advertisement of the OSPF:
access-list 500 permit 172.16.251.0255.255.255.0
pager lines 24
icmp permit any inside
icmp permit any outside
mtu inside 1500
mtu outside 1500
ip address inside 172.16.251.100 255.255.255.0
ip address outside 172.16.253.1 255.255.255.0
no failover
failover lan unit secondary
failover timeout 0:00:00
failover poll 15
failover ip address inside 0.0.0.0
failover ip address outside 0.0.0.0
pdm history enable
arp timeout 14400
static (inside,outside) 172.16.250.10 172.16.250.10 netmask 255.255.255.255 0 0
access-group inside in interface inside
access-group outside in interface outside
The OSPF interface timer configurations below are common across the architecture:
interface inside
ospf hello-interval 1
ospf dead-interval 3
!
!
interface outside
ospf hello-interval 1
ospf dead-interval 3
!
The route-map below states that the permitted advertised traffic must match the access-list 500
addresses. This route-map is then bound to the OSPF process that is redistributing the routes, as seen
below in router OSPF 100:
route-map 500 permit 10
match ip address 500
!
The OSPF configurations below are representative of the recommended security configuration. Within
the configuration, two different OSPF routing processes were defined to control inbound and outbound
route propagation:
router ospf 500
network 172.16.251.0 255.255.255.0 area 251
log-adj-changes
log-adj-changes
!
timeout xlate 3:00:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h323 0:05:00 sip 0:30:00
sip_media 0:02:00
timeout uauth 0:05:00 absolute
aaa-server TACACS+ protocol tacacs+
aaa-server RADIUS protocol radius
aaa-server LOCAL protocol local
no snmp-server location
no snmp-server contact
snmp-server community public
no snmp-server enable traps
floodguard enable
no sysopt route dnat
telnet timeout 5
ssh timeout 5
terminal width 80
Cryptochecksum:03e78100e37fef97b96c15d54be90956
: end
[OK]
Showing the routes available to the FWSM ensures that the proper outside/inside routes were
propagated:
EASTFWSM# exit
Logoff
Below are the routes associated with the edge switching layers. Notice that the edge layer has two routes
to the Internet backbone: one primary route via the OSPF process running locally on the switch and the
redundant route running through Area 0 to the secondary switch. This is the same respectively on each
switch.
EASTEDGE1#sho ip route
Codes: C - connected, S - static, I - IGRP, 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, E - EGP
i - IS-IS, 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
!
hostname EASTCOASTCORE
!
!
interface Port-channel1
no ip address
switchport
switchport trunk encapsulation dot1q
The interface configurations below state that Gigabit 1/1 is the OSPF interface that neighbors to the East
Coast edge layer. This is where the you can tune the OSPF cost to define that any users locally adjacent
to the East Coast core would chose this upstream link for the internet traffic. This same configuration is
also tuned to ensure any west coast traffic traverse the west coast routes:
!
interface GigabitEthernet1/1
ip address 172.16.251.1 255.255.255.0
ip ospf hello-interval 1
ip ospf dead-interval 3
ip ospf cost 5
!
interface GigabitEthernet1/2
no ip address
switchport
switchport trunk encapsulation dot1q
channel-group 1 mode on
!
interface GigabitEthernet2/1
no ip address
switchport
switchport trunk encapsulation dot1q
channel-group 1 mode on
!
interface Vlan1
no ip address
shutdown
!
interface Vlan200
ip address 172.16.250.1 255.255.255.0
ip ospf hello-interval 1
ip ospf dead-interval 3
!
router ospf 500
log-adjacency-changes
area 251 nssa
network 172.16.250.0 0.0.0.255 area 0
network 172.16.251.0 0.0.0.255 area 251
!
ip classless
no ip http server
!
!
!
line con 0
line vty 0 4
login
transport input lat pad mop telnet rlogin udptn nasi
!
end
The following displays the routes associated with East Coast core. Note the path preference is the
respective edge switching layer.
EASTCOASTCORE#sho ip route
Codes: C - connected, S - static, I - IGRP, 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, E - EGP
WESTCOASTCORE#wr t
Building configuration...
!
hostname WESTCOASTCORE
!
!
!
!
interface Port-channel1
no ip address
switchport
switchport trunk encapsulation dot1q
!
interface GigabitEthernet1/1
ip address 172.16.252.1 255.255.255.0
ip ospf hello-interval 1
ip ospf dead-interval 3
ip ospf cost 5
!
interface GigabitEthernet1/2
no ip address
switchport
switchport trunk encapsulation dot1q
channel-group 1 mode on
!
interface GigabitEthernet2/1
no ip address
switchport
switchport trunk encapsulation dot1q
channel-group 1 mode on
!
!
interface Vlan1
no ip address
shutdown
!
interface Vlan200
ip address 172.16.250.254 255.255.255.0
ip ospf hello-interval 1
ip ospf dead-interval 3
!
router ospf 500
log-adjacency-changes
area 252 nssa
network 172.16.250.0 0.0.0.255 area 0
network 172.16.252.0 0.0.0.255 area 252
!
The following displays the routes associated with West Coast core. Note the path
preference is that of the West Coast edge switching layer.
WESTCOASTCORE#sho ip route
Codes: C - connected, S - static, I - IGRP, 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, E - EGP
i - IS-IS, 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
topology from the one ISP link, yet all traffic destined to the topology comes inbound on another ISP
link; you must implement autonomous system prepending. This is most commonly deployed in instances
where you do not want to leave an link idle. For more information regarding route control via BGP, refer
to “Single Site Multi Homing.”
Security Considerations
Security is a necessity in all network architectures today, regardless of your Internet connectivity. Proper
requirements must be taken to ensure that the network architecture and the network devices are securely
provisioned and managed.
Internet edge security is discussed in “Internet Edge Security Design Principles” and “Internet Edge
Security Implementation.” This section provides a brief summary from those guides of the security
functions supported within Internet edge designs. These functions include:
• Element Security - The secure configuration and management of the devices that collectively define
the Internet edge.
• Identity Services - The inspection of IP traffic across the Internet edge requires the ability to identify
the communicating endpoints. Although this can be accomplished with explicit user/host session
authentication mechanisms, usually IP identity across the Internet edge is based on header
information carried within the IP packet itself. Therefore, IP addressing schemas, address
translation mechanisms, and application definition (IP protocol/port identity) play key roles in
identity services.
• IP Anti-Spoofing - This includes support for the requirements of RFC-2827, which requires
enterprises to protect their assigned public IP address space; and RFC-1918, which allows the use
of private IP address spaces within enterprise networks.
• Demilitarized Zones (DMZ) - A basic security policy for enterprise networks is that internal network
hosts should not be directly accessible from hosts on the Internet (as opposed to replies from Internet
hosts for internally initiated session, which are statefully permitted). For those hosts, such as web
servers, mail servers, VPN devices, etc., which are required to be directly accessible from the
Internet, it is necessary to establish quasi-trusted network areas between, or adjacent to both, the
Internet and the internal enterprise network. Such DMZs allow internal hosts and Internet hosts to
communicate with DMZ hosts, but the separate security policies between each area prevent direct
communication originating from Internet hosts from reaching internal hosts.
• Basic Filtering and Application Definition - Derived from enterprise security policies, ACLs are
implemented to provide explicitly permitted and/or denied IP traffic which may traverse between
areas (Inside, Outside, DMZ, etc.) defined to exist within the Internet edge.
• Stateful Inspection - Provides the ability to establish and monitor session states of traffic permitted
to flow across the Internet edge, and deny that traffic which fails to match the expected state of an
existing or allowed session.
• Intrusion Detection - The ability to promiscuously monitor network traffic across discrete points
within the Internet edge, and alarm and/or take action upon detecting suspect behavior that may
threaten the enterprise network.
EIGRP 4
A
Element security 1
ACL 14 element security 24
Application distribution 1 exterior gateway protocol 6
B F
basic filtering 1 Firewall Service Module 9
basic filtering and application definition 24 FWSM 9, 11, 15, 16, 17, 19
BGP 6, 9, 10, 12, 13, 14
BGP attributes 7
BGP attribute tuning 23
H
BGP routing table 6 hot standby router protocol 4
border gateway protocols 6 HSRP 4, 5, 9
border routers 10 HSRP dead timers 5
C I
CAM 5 Identity services 1
content addressable memory 5 identity services 24
IGP 9, 10
IGPs 6
D
injecting partial BGP routes 14
default routing 6 interautonomous system routing 6
Demilitarized zones 1 interior gateway protocols 6
demilitarized zones 24 intra-autonomous system routing 7
device redundancy 4 intrusion detection 1, 24
DMZ 1, 24 IP anti-spoofing 1
DNS propagation 2 ISP peering point 3
dynamic routing 6 ISP resiliency 1
E L
EBGP 15 Layer 3 features 4
EGP 6
Multi Site Multi Homing
Version 1.0 25
Index
M S
NAT 11
network address translation 11
not so stubby area 14
not-so stubby area 9
NSSA 14
OPSF 9
OSPF 10, 12, 14, 16
OSPF cost 21
OSPF dead-interval timers 13
OSPF hello timers 13
OSPF interface timer configurations 18
P anti-spoofing 24
pass-through autonomous system routing 7
PIX firewall 8
Replication timeouts 2
route-map 18
routing protocol metric tuning 4