Intelligent Wan Multiple Data Center Deployment Guide: Cisco Validated Design
Intelligent Wan Multiple Data Center Deployment Guide: Cisco Validated Design
Intelligent Wan Multiple Data Center Deployment Guide: Cisco Validated Design
Intelligent WAN
Multiple Data Center
Deployment Guide
April 2017
Table of Contents
Table of Contents
Deploying the Cisco Intelligent WAN................................................................................................. 1
Deployment Details...........................................................................................................................................................1
Appendix B: Changes..................................................................................................................... 37
Deployment Details
How to Read Commands
This guide uses the following conventions for Commands at a CLI or script prompt:
commands that you enter at the command-line Router# enable
interface (CLI).
Long commands that line wrap are underlined.
Commands to enter at a CLI prompt: Enter them as one command:
configure terminal police rate 10000 pps burst 10000
packets conform-action
Commands that specify a value for a variable:
ntp server 10.10.48.17 Noteworthy parts of system output (or of device
configuration files) are highlighted:
Commands with variables that you must define: interface Vlan64
class-map [highest class name] ip address 10.5.204.5 255.255.255.0
•• Remote sites can access any data center across either hub.
•• Data centers can reach any remote site across any of the transit sites.
•• Multiple hub BRs per DMVPN per site may be required for horizontal scaling, as noted in the previous pro-
cess.
This design introduces the concept of a transit master controller and transit BRs.
•• Transit Master Controller—The Transit MC is the MC at the transit-site. There is no policy configuration on
this device. It receives policy from the Hub MC. This device acts as MC for that site for making path optimiza-
tion decision. The configuration includes the IP address of the hub MC.
•• Transit Border Router—This is a BR at the transit MC site. This is the device where WAN interfaces terminate.
There can only be one WAN interface on the device. There can be one or more transit BRs. On the transit
BRs, PfRv3 must be configured with:
The following diagram shows the transit MC with two additional transit BRs and where they fit into the IWAN hy-
brid design model.
DC1 DC2
10.4.0.0/16 10.4.0.0/16
10.6.0.0/16 DCI 10.8.0.0/16
WAN Core
Hub MC Transit MC
POP-ID 0 POP-ID 1
10.4.0.0/16 10.4.0.0/16
10.6.0.0/16 10.8.0.0/16
2309F
DMVPN 1 DMVPN 2 DMVPN 1 DMVPN 2
With the IOS release used for this guide, data center affinity is enabled by default. It is applicable for both path
preference and load balancing. There is no CLI change required and PfR will use the primary data center as its
preference for all traffic.
If the MPLS1 path is primary and INET1 path is secondary in your design, the path preference will be as follows:
•• Path #1 to 10.4.0.0/16 is MPLS1 path to DC#1
If you want the path preference to be the MPLS path as primary and INET path as fallback across data centers,
there is a domain transit-site-affinity command to disable data center affinity.
domain iwan
vrf default
master hub
advanced
no transit-site-affinity
If no transit-site-affinity is enabled, the failover order for the example given above would be as follows:
•• Path #1 to 10.4.0.0/16 is MPLS1 path to DC#1
For this process, you configure two transit site BRs with similar base configurations as the existing hub BRs. You
have to make changes to the base configurations and the remote site routers to take advantage of the new transit
site location.
The transit site BR routers have unique IP addresses and port-channel assignments, but the rest of the configura-
tion items are the same.
Follow the process “Configuring DMVPN Hub Router,” using the base PfR information from the first two hub BRs.
Make the required changes from the procedures below to add a transit site to your IWAN domain.
Procedure 1 Copy the configuration from existing router to the new router
Optional
If the hardware for the corresponding transit BR is identical to the hub BR, you can use this optional procedure to
copy the configuration file from one router to the other as a starting point, and then follow the procedures below.
Skip this procedure if you do not want to copy the configuration from an existing router.
Step 1: Copy the running configuration from an existing router to your FTP server.
Step 2: From the console of the new transit BR, copy and paste the configuration into the router before making
the changes below.
You can also make the changes below in a text editor before pasting the configuration into the router.
In this procedure, you configure system settings that are unique to the transit BR.
Step 1: Configure the device host name to make it easy to identify the device.
hostname HY-MPLS1-ASR1002X-T1
The loopback interface is a logical interface that is always reachable as long as the device is powered on and any
IP interface is reachable to the network.
The loopback address is commonly a host address with a 32-bit address mask.
interface Loopback 0
ip address 10.8.32.241 255.255.255.255
Any links to adjacent distribution layers should be Layer 3 links or Layer 3 EtherChannels. Choose a unique port-
channel interface from the LAN switch perspective.
interface Port-channel1
description IWAN-D3750X-T
ip address 10.8.32.2 255.255.255.252
ip pim sparse-mode
no shutdown
Step 2: Configure EtherChannel member interfaces. Configure the physical interfaces to tie to the logical port-
channel by using the channel-group command. The number for the port-channel and channel-group must
match. Not all router platforms can support LACP to negotiate with the switch, so EtherChannel is configured
statically.
interface GigabitEthernet0/0/0
description IWAN-D3750X-T Gig1/0/1
interface GigabitEthernet0/0/1
description IWAN-D3750X-T Gig2/0/1
If you are planning to use EIGRP, choose option 1. If you are planning to use BGP on the WAN and OSPF on the
LAN, choose option 2.
In this design, the tunnel, port-channel and loopback must be EIGRP interfaces. The loopback may remain a pas-
sive interface. The network range must include all interface IP addresses, either in a single network statement or
in multiple network statements.
This design uses a best practice of assigning the router ID to a loopback address.
Allow EIGRP to form neighbor relationships across the interface in order to establish peering adjacencies and
exchange route tables. In this step, you configure EIGRP authentication by using the authentication key specified
in the previous procedure.
At the hub location where there are multiple border routers, the interface throughput delay setting should be set
to influence the EIGRP routing protocol path preference.
Tech Tip
If you are using Port-channel interfaces with two Gigabit Ethernet members as recommended in this
guide, you will have to double the LAN path delay to 500000 microseconds (usec), instead of the
standard IWAN setting of 250000.
Set the internal LAN path to 500000 microseconds (usec). The delay command is entered in 10 usec units.
interface Port-channel1
delay 50000
Step 1: Configure OSPF Area 0 by using the loopback interface IP address as the router-id.
Each IWAN DMVPN hub requires a connection to the WAN transport, which for the hybrid model is either MPLS
or Internet.
If you are using MPLS in this design, the DMVPN hub is connected to the service provider’s MPLS PE router. The
IP addressing used between IWAN CE and MPLS PE routers must be negotiated with your MPLS carrier.
If you are using the Internet in this design, the DMVPN hub is connected through a Cisco ASA 5500 using a DMZ
interface specifically created and configured for a VPN termination router.
The IP address that you use for the Internet-facing interface of the DMVPN hub router must be an Internet-
routable address. There are two possible methods for accomplishing this task:
•• Assign a routable IP address directly to the router.
•• Assign a non-routable RFC-1918 address directly to the router and use a static NAT on the Cisco ASA 5500
to translate the router IP address to a routable IP address.
This design assumes that the Cisco ASA 5500 is configured for static NAT for the DMVPN hub router.
Step 1: Enable the interface, select the VRF, and assign the IP address.
interface GigabitEthernet0/0/3
vrf forwarding IWAN-TRANSPORT-1
ip address 192.168.6.41 255.255.255.252
no shutdown
The VRF created for FVRF must have its own default route to the MPLS. This default route points to the MPLS PE
router’s IP address and is used by DMVPN for tunnel establishment.
Step 1: The DMVPN design is using FVRF, so you must place the WAN interface into the VRF configured in Pro-
cedure 3, “Configure the WAN-facing VRF.”
Step 2: Enable the interface, select the VRF, and assign the IP address.
interface GigabitEthernet0/0/3
vrf forwarding IWAN-TRANSPORT-2
ip address 192.168.146.11 255.255.255.0
no shutdown
The VRF created for FVRF must have its own default route to the Internet. This default route points to the Cisco
ASA 5500’s DMZ interface IP address.
The parameters in the table below are used in this procedure. Choose the row that represents the transit site BR
that you are configuring. This procedure applies to the transit site BR in the IWAN hybrid design model.
The tunnel number is arbitrary, but it is best to begin tunnel numbering at 10 or above, because other features
deployed in this design may also require tunnels and they may select lower numbers by default.
interface Tunnel10
ip address 10.6.34.2 255.255.254.0
If you are planning to use EIGRP, choose option 1. If you are planning to use BGP on the WAN and OSPF on the
LAN, choose option 2.
The IP assignments for the entire network were designed so they can be summarized within a few aggregate
routes. As configured below, the summary-address command suppresses the more specific routes. If any net-
work within the summary is present in the route table, the summary is advertised to the remote sites, which offers
a measure of resiliency. If the various networks cannot be summarized, then EIGRP continues to advertise the
specific routes.
Step 3: If there are many component routes to be summarized and the component routes are frequently up-
dated, the metrics are also updated frequently, which may cause a spike in the CPU usage. The summary-metric
command explicitly sets the metric for the summary regardless of the component route metric, which reduces the
computational load on a router.
The first value is the bandwidth metric in Kbits per second. The second value is the delay metric in 10 usecs. The
third value is the reliability metric where 255 is 100% reliable. The fourth value is the effective bandwidth metric
(loading) where 255 is 100% loaded. The fifth value is the MTU of the path.
Tech Tip
EIGRP uses the path’s minimum bandwidth as part of the metric calculation. The path’s minimum
bandwidth is defined in a route advertisement in the minimum bandwidth path attribute. Setting the
summary metric bandwidth (first value) to 10 Mbps essentially removes the ability to differentiate
between a 10 Mbps tunnel (MPLS1) and a 100 Mbps circuit (INET1) because both paths have a mini-
mum bandwidth of 10 Mbps. Setting the summary metric bandwidth to 10 Gbps as recommended in
this guide allows the calculations on the branch router to differentiate tunnel bandwidth regardless of
the size of each path.
Use the identical values for each summary address defined in the previous step.
The tunnel interface throughput delay setting should be set to influence the EIGRP routing protocol path prefer-
ence. Set the primary WAN path to 10000 usec and the secondary WAN path to 20000 usec to prefer one over
the other. The delay command is entered in 10 usec units.
interface Tunnel10
delay 1000
Step 5: Tag the routes for data center (POP) affinity.
In this design, there are different IP subnets for each DMVPN network, and the EIGRP tags are clearly defined to
help with readability and troubleshooting. When a design uses more than one POP site, tags are required in order
to identify the different DMVPN hub router locations, which allows a remote site to prefer one POP over the other.
Outbound distribute-lists are used to set tags on the DMVPN hub routers towards the WAN. The remote-site
routers use eigrp stub-site in order to protect against becoming transit sites.
The following tables show specific route tags in use.
The following examples show the hub and transit border routers in the IWAN hybrid design model.
Table 7 Tunnel IPs, local preferences, community strings, and metrics for hub BRs
BGP
DMVPN BGP local community OSPF metric OSPF metric
DMVPN hub router Tunnels preference string preferred POP secondary POP
HY-MPLS1-ASR1002X-1 10.6.34.0/23 800 (MPLS1) 65100:100 1000 2000
HY-INET1-ASR1002X-2 10.6.36.0/23 780 (INET1) 65100:200 1200 2200
Table 8 Tunnel IPs, local preferences, community strings, and metrics for transit BRs
BGP
DMVPN BGP local community OSPF metric OSPF metric
DMVPN hub router Tunnels preference string preferred POP secondary POP
HY-MPLS1-ASR1002X-T1 10.6.34.0/23 600 (MPLS1) 65100:101 1000 2000
HY-INET1-ASR1002X-T2 10.6.36.0/23 580 (INET1) 65100:202 1200 2200
Step 1: Configure BGP values for the tunnel interface. Use a private AS number for the BGP process. Assign this
router’s loopback address as the BGP router-id. Log the neighbor changes. Create a listen range that includes
the subnet range of the tunnel interface. For internal BPG, use the same AS number for the remote sites. Create
the route reflector and use the tunnel as the update source interface. Adjust the BGP hello and hold timers to 20
seconds and 60 seconds, respectively.
Step 2: Create the static null routes for the enterprise summary prefix and the site-specific prefixes.
Step 3: Configure the BGP address family. Define the network statements for the default network, the enterprise
summary prefix, the site-specific prefixes, and the local MC loopback IP address the router will advertise to the
remote sites. Configure BGP dynamic neighbors for the remote sites. Set the BGP distance and redistribute the
internal networks.
Define the prefix-lists for the default network, the enterprise summary prefix, the site-specific prefixes, the local
MC loopback IP address, and the subnet ranges for the DMVPN tunnels.
Step 5: Create and apply the prefix route maps for BGP.
Define the route map to block prefixes inbound on the tunnel interface. Define the route map to allow prefixes to
go out on the tunnel interface. Set the local preference and the community string for this DMVPN hub router. Ap-
ply the route maps to the BGP address family. Configure BGP to display communities in the format AA:NN.
Step 6: Create and apply the BGP to OSPF redistribution route map for hub BRs.
When there are two or more POP sites, there might be certain remote sites that want to prefer one POP over the
other. This preference choice is done using a community string value, which is sent by the remote site router to
indicate which POP they prefer.
This example uses a community string in the form of AS:NN with AS being the BGP autonomous system number
and NN being the value that selects the preferred POP.
Example:
The hub location matches the POP2 community string to set the higher metric values.
Step 7: Create and apply the updated BGP to OSPF redistribution route map for transit BRs.
The POP preference route map changes from the previous step have to be applied to the corresponding transit
BRs at your POP2 location.
The transit location matches the POP1 community string to set the higher metric values.
You have to add the transit site Internet BR to your firewall configuration for network address translation.
The DMZ network uses private network (RFC 1918) addressing that is not Internet-routable, so the firewall must
translate the DMZ address of the DMVPN hub router to an outside public address.
The example DMZ address to public IP address mapping is shown in the following table.
First, to simplify the configuration of the security policy, you create the External DMZ network objects that are
used in the firewall policies.
Object
Network object name type IP address Description
outside-dmvpn-T2-ISPa Host 172.16.140.2 DMVPN hub router T2 on ISP A (outside)
Step 3: In the Name box, enter the name. (Example: outside-dmvpn-T2-ISPa)
Step 4: In the Type list, choose Host or Network. (Example: Host)
Step 5: In the IP Address box, enter the address. (Example: 172.16.140.2)
Step 6: In the Description box, enter a useful description, and then click OK. (Example: DMVPN hub router T2 on
ISP A)
Step 7: Repeat Step 2 through Step 6 for each object listed in the above table. If an object already exists, then
skip to the next object listed in the table.
Step 8: After adding all of the objects listed, on the Network Objects/Groups pane, click Apply.
Next, you add a network object for the private DMZ address of the DMVPN hub router.
Object
Network object name type IP address Description
dmz-dmvpn-T2 Host 192.168.146.13 DMVPN hub router T2 on vpn-dmz
Step 11: In the Name box, enter the name. (Example: dmz-dmvpn-T2)
Step 12: In the Type list, choose Host or Network. (Example: Host)
Step 13: In the IP Address box, enter the address. (Example: 192.168.146.13)
Step 14: In the Description box, enter a useful description, and then click OK. (Example: DMVPN hub router T2
on vpn-dmz)
Step 15: Click the two down arrows. The NAT pane expands.
Step 17: In the Translated Address list, choose the network object created previously. (Example: outside-dm-
vpn-T2-ISPa)
Step 18: Select Use one-to-one address translation, and then click OK.
Step 19: Repeat Step 10 through Step 18 for each object listed in the table above. If an object already exists,
then skip to the next object listed in the table.
Step 20: After adding all of the objects listed, on the Network Objects/Groups pane, click Apply.
For this process, you configure a transit MC with a similar base configuration as the existing hub MC. You have to
make changes to the base configuration and the remote site routers in order to take advantage of the new transit
site location.
The additional MC router has a unique pop-id, IP addresses and port-channel assignments, and a much simpler
PfR MC configuration, but the rest of the configuration is the same. The hub MC has a default pop-id of 0 and
transit MCs pop-id start at 1.
Loopback
Host name Pop ID IP address Port-channel IP address
HY-MC-CSR1000v-1 0 10.6.32.251/32 10.6.32.151/25
HY-MC-ASR1002X-T1 1 10.8.32.251/32 10.8.32.151/25
Follow the process “Configuring Hub Master Controller” using the base PfR information from the hub MC. Make
the required changes from the procedures below in order to add a transit site to your IWAN domain.
Procedure 1 Copy the configuration from existing router to the new router
Optional
If the hardware for the transit MC is identical to the hub MC, you can use this optional procedure to copy the
configuration file from one router to the other as a starting point, and then follow the procedures below. Skip this
procedure if you do not want to copy the configuration from an existing router.
Step 1: Copy the running configuration from an existing router to your FTP server.
Step 2: From the console of the new transit MC, copy and paste the configuration into the router before making
the changes below.
You can also make the changes below in a text editor before pasting the configuration into the router.
In this procedure, you configure system settings that are unique to the transit MC.
Step 1: Configure the device host name to make it easy to identify the device.
hostname HY-MC-ASR1002X-T1
The loopback interface is a logical interface that is always reachable as long as the device is powered on and any
IP interface is reachable to the network.
The loopback address is commonly a host address with a 32-bit address mask.
interface Loopback 0
ip address 10.8.32.151 255.255.255.255
EIGRP is configured facing the LAN distribution or core layer. In this design, the port-channel interface and the
loopback must be EIGRP interfaces. The loopback may remain a passive interface. The network range must in-
clude both interface IP addresses, either in a single network statement or in multiple network statements.
This design uses a best practice of assigning the router ID to a loopback address.
Any links to adjacent distribution layers should be Layer 3 links or Layer 3 EtherChannels.
interface Port-channel21
description IW-WAN-D3750X-T
ip address 10.8.32.151 255.255.255.192
no shutdown
Configure the physical interfaces to tie to the logical port-channel by using the channel-group command. The
number for the port-channel and channel-group must match. Not all router platforms can support LACP to nego-
tiate with the switch, so EtherChannel is configured statically.
interface GigabitEthernet0/0/0
description IW-WAN-D3750X-T Gig1/0/3
interface GigabitEthernet0/0/1
description IW-WAN-D3750X-T Gig2/0/3
If you are planning to use EIGRP, choose option 1. If you are planning to use BGP on the WAN and OSPF on the
LAN, choose option 2.
The network range must include both interface IP addresses, either in a single network statement or in multiple
network statements.
This design uses a best practice of assigning the router ID to a loopback address.
Allow EIGRP to form neighbor relationships across the interface to establish peering adjacencies and exchange
route tables. In this step, you configure EIGRP authentication by using the authentication key specified in the
previous procedure.
Step 1: Configure OSPF Area 0 by using the network summary addresses and the loopback interface IP address
as the router-id.
Step 2: Turn on passive-interface as the default and remove it for the LAN interface.
After the transit BRs and MC are configured, you will configure PfR for the transit site location.
It is mandatory to use loopback interfaces for the peering traffic between the BR and MC routers. For this design,
you put the loopback addresses into a specific subnet range, so they are easily identified in the routing table. The
loopback address ranges for the remote sites are as follows:
Tunnel Loopback 0
IWAN design model type address range
Hybrid—Primary Router MPLS1 10.255.241.0/24
Hybrid—Secondary Router INET1 10.255.242.0/24
Step 1: Verify that the loopback 0 interfaces on each of your remote sites are reachable from the transit MC by
using the show ip route command.
This example shows a loopback address range of 10.255.241.0/24 for nine remote site primary routers and an
address range of 10.255.242.0/24 for four remote site secondary routers.
Before the configuration of PfRv3 on the transit MC, you must create prefix lists for the data center. The enter-
prise-prefix list is only configured on the hub MC and you will not configure one on the transit MC.
The site-prefix range for the transit site includes the prefixes at this specific site, which is normally a WAN ag-
gregation or data center site. Site-prefixes are typically statically defined at WAN aggregation and DC sites and
discovered automatically at remote sites.
Tech Tip
Example
This example shows a data center network with two class B private address blocks of 10.4.0.0 and 10.8.0.0.
Domain policies are configured on the hub MC. These policies are distributed to branch MCs and the transit MC
by using the peering infrastructure. All sites that are in the same domain will share the same set of PfR policies.
The transit MC must peer to the hub MC to get the policy information.
domain [name]
vrf [name]
master transit [number]
source-interface [interface]
site-prefixes prefix-list [prefixes from previous procedure]
password [password of hub MC]
hub [IP address of hub MC]
Example
domain iwan
vrf default
master transit 1
source-interface Loopback0
site-prefixes prefix-list DC2-PREFIXES
password c1sco123
hub 10.6.32.251
Step 2: Verify the hub MC policy configuration is available by using the show domain [name] master policy
command.
The output from this command should look the same as the output on the hub MC.
The transit BRs are also the DMVPN hub WAN aggregation routers for the transit site network. The PfRv3 con-
figurations for standalone BRs are much simpler because they dynamically learn their policy information from the
transit MC. The transit BR routers are also used to advertise the path names and path-ids specified in the hub
MC configuration.
There is an optional feature called zero-SLA that reduces the probing to only the default class by muting the other
DSCP probes. This feature is useful on Internet connections where nothing is guaranteed. Zero-SLA reduces
bandwidth usage on metered interfaces such as 4G LTE or other Internet connections with a monthly data cap
limit.
Tech Tip
If you want to add the zero-SLA feature to an existing hub BR, you must shut down the DMVPN tun-
nel interface before configuring. After the feature is added to the hub BR, bring the tunnel interface
back up.
Path Loopback
Host name Path ID IP address Zero SLA
HY-MPLS1-ASR1002X-T1 MPLS1 1 10.8.32.241/32 No
HY-INET1-ASR1002X-T2 INET1 2 10.8.32.242/32 Yes (optional)
domain [name]
vrf [name]
border (create the BR)
source-interface [interface]
master [IP address of transit MC]
password [password of hub MC]
Example
domain iwan
vrf default
border
source-interface Loopback0
master 10.8.32.251
password c1sco123
Step 2: Add the path names and path-ids to the tunnel interfaces of the transit BR.
Example
This example is the primary transit BR using Tunnel 10 with MPLS as the provider.
interface Tunnel10
domain iwan path MPLS1 path-id 1
Step 3: (Optional) This example is the secondary hub BR using Tunnel 11 with INET as the provider and the zero-
sla feature. If this is an existing configuration, you shut down the interface, add the zero SLA feature. and then
bring the interface back up.
interface Tunnel11
shutdown
domain iwan path INET1 path-id 2 zero-sla
no shutdown
Step 4: Verify the border is operational by using the show domain [name] border status command.
Step 5: Repeat this procedure for each transit BR by using the appropriate path name and path-id.
The PfR path names and path-ids are automatically discovered at the remote site routers from the configuration
entered into the tunnel interfaces at the hub and transit sites. The hub MC uses the path names and path-ids to
determine where traffic should be sent according to its policies.
Step 1: Verify the domain is operational from the transit MC using the show domain [name] master status com-
mand.
PROCESS
There are additional commands you need to configure at a remote site to begin using the transit site BRs.
An additional NHRP command has to be added to the tunnel interfaces of remote site BRs for them to begin using
the transit BRs.
The DMVPN hub router is the NHRP server for all of the spokes. Remote routers use NHRP in order to determine
the tunnel destinations for peers attached to the mGRE tunnel.
The spoke router requires an additional configuration statement in order to define the NHRP server. This state-
ment includes the NBMA definition for the DMVPN hub router tunnel endpoint. Spoke routers require the NHRP
multicast keyword in this statement.
The value used for the NHS is the mGRE tunnel address for the DMVPN hub router. The NBMA entry must be set
to either the MPLS DMVPN hub router’s actual public address or the outside NAT value of the DMVPN hub, as
configured on the Cisco ASA 5500. This design uses the values shown in the table above.
interface Tunnel11
ip nhrp nhs 10.6.36.2 nbma 172.16.140.2 multicast
Step 2: Confirm the hub and transit BRs are reachable with show ip eigrp neighbors.
Step 3: Repeat this procedure for each remote site that will use the transit BRs.
If you are planning to use EIGRP, choose option 1. If you are planning to use BGP on the WAN and OSPF on the
LAN, choose option 2.
DMVPN
Tunnel interface tunnel key Tag tunnel Metric
Tunnel 10 (DMVPN 1) 101 101 +10000
(MPLS1) (All routes)
Tunnel 11 (DMVPN 2) 102 102 +20000
(INET1) (All routes)
DMVPN
Tunnel interface tunnel key Tag tunnel Metric
Tunnel 10 (DMVPN 1) 106 106 +10000
(MPLS1) (All routes)
Tunnel 11 (DMVPN 2) 107 107 +20000
(INET1) (All routes)
Set the EIGRP metric value higher for the routes tagged from the non-preferred site.
Step 1: Define the route maps to identify the tags from border routers in POP1 and POP 2.
Step 2: Apply the POP select route map on the inbound tunnel interfaces.
topology base
distribute-list route-map POP-SELECT in Tunnel10
distribute-list route-map POP-SELECT in Tunnel11
exit-af-topology
Step 3: Repeat this process for each remote site that will use the transit BRs.
Table 18 Local preferences, community strings, and metrics for hub BRs at POP1
BGP
BGP local community OSPF metric OSPF metric
Transport preference string preferred POP secondary POP
MPLS1 800 65100:100 1000 2000
INET1 780 65100:200 1200 2200
Table 19 Local preferences, community strings, and metrics for transit BRs at POP2
BGP
BGP local community OSPF metric OSPF metric
Transport preference string preferred POP secondary POP
MPLS1 600 (MPLS1) 65100:101 1000 2000
INET1 580 (INET1) 65100:202 1200 2200
ip bgp-community new-format
Step 2: Define the community lists to identify the border routers from POP1 and POP 2.
Step 3: Create the inbound route maps and update the outbound route map.
Update the outbound route map with a community string to signal the POP preference to the border routers.
Example:
Step 4: Apply the POP select route map on the inbound WAN transports.
Step 5: Repeat this process for each remote site that will use the transit BRs.
Appendix B: Changes
This appendix summarizes the changes Cisco made to this guide since its last edition.
•• Routing updates:
◦◦ Simplified the EIGRP tagging and removed the filtering that was no longer needed
◦◦ Added the EIGRP data center affinity use case to hub and remote sites
•• Guide updates:
Cisco has more than 200 offices worldwide. Addresses, phone numbers, and fax numbers are listed on the Cisco Website at www.cisco.com/go/offices.
ALL DESIGNS, SPECIFICATIONS, STATEMENTS, INFORMATION, AND RECOMMENDATIONS (COLLECTIVELY, “DESIGNS”) IN THIS MANUAL ARE PRESENTED “AS
IS,” WITH ALL FAULTS. CISCO AND ITS SUPPLIERS DISCLAIM ALL WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE WARRANTY 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 THE DESIGNS, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN
ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. THE DESIGNS ARE SUBJECT TO CHANGE WITHOUT NOTICE. USERS ARE SOLELY RESPONSIBLE FOR
THEIR APPLICATION OF THE DESIGNS. THE DESIGNS DO NOT CONSTITUTE THE TECHNICAL OR OTHER PROFESSIONAL ADVICE OF CISCO, ITS SUPPLIERS
OR PARTNERS. USERS SHOULD CONSULT THEIR OWN TECHNICAL ADVISORS BEFORE IMPLEMENTING THE DESIGNS. RESULTS MAY VARY DEPENDING ON
FACTORS NOT TESTED BY CISCO.
Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and figures included
in the document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and coincidental.
Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go
to this URL: www.cisco.com/go/trademarks. Third-party trademarks mentioned 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. (1110R)