Cisco dCloud

Cisco IWAN 4D Lab v1

Last Updated: 31-AUGUST-2016

About This Solution

NOTE: Do you have a suggestion or feedback on the Cisco IWAN 4D Lab guide? Please click here to send us your ideas.

This lab highlights the overall topology of the IWAN solution. This lab guide focuses on both physical and logical configurations.
Upon completion of this topology lab, you will have a thorough understanding of IWAN.

NOTE: The IWAN 4D Series of lab offerings are very extensive. As such, they require considerable computer resource allocation
on the backend. This limits the number of simultaneously running demos.

In order to ensure that the labs are available when needed for design workshop and proof of value engagements, please ensure
that you are not reserving the labs for longer than required. The ability exists to schedule and start any of these labs on demand as
needed. We appreciate your support in maximizing availability and optimizing usage of these demos.

About the Topology

The lab topology includes four distinct locations. Each location connects to two separate types of transport and subscribes to both
MPLS and Internet services. HQ/DC and Branch 1 split the transport links between two routers for added hardware resiliency,
while Branch 2 and Branch 3 terminate both links into a single router. A dual router configuration results in the difference of
99.999% resiliency/uptime vs. 99.995% resiliency/uptime in protection against device failure.

The HQ/DC site has local 198.18.128.X/18 prefixes for DC servers and appliances. Most servers include 133 in the third octet,
represented by 198.18.133.X/18. Routed links between the core switch and the routers at the edge, as well as between the core
switch and the CA, leverage 198.19.0.X/30. The third octet is the site ID—the HQ/DC represents site 0.

Leveraging the third octet in this way is a common setup for each location. Device loopback addresses leverage the 172.31.X.Y/32
space, where X is the site identifier and Y is a unique number for the site. HQ/DCs have loopbacks falling in the 172.31.0.X/32
range. The switch at this location is the only routable switch in our lab and it uses 172.31.0.0/32 for its loopback address. Router 1
at HQ/DC and other locations has a loopback ending in X.1. Router 2, where present, such as HQ/DC and BR1, has a loopback
ending in X.2. The Master Controller for PfRv3 has the loopback address of 172.31.0.5. Loopback addresses are important to note
as we look at verification output.

Branch 1

As illustrated in the bottom left hand side of the topology, the third octet is our site ID and therefore Branch 1 represents site 1. The
Branch 1 location hosts the 198.19.1.X/24 and 198.20.1.X/24 prefixes. Router 1 has a loopback interface with an address of
172.31.1.1/32, while Router 2 has a loopback interface with the address 172.31.1.2/32. This site has a host machine, PC11, with
the address of 198.19.1.11. PC11 uses an HSRP gateway address of 198.19.1.254, configured on the edge routers for first hop
redundancy. You can RDP to this PC, and others, from the jumpbox, PC01, in the HQ/DC. This generates additional traffic.

Branch 2

Branch 2 represents site 2. Our Branch 2 location hosts the 198.19.2.X/24 and 198.20.2.X/24 prefixes. Router 1 is the only router
at this site and has a loopback with and address of 172.31.2.1/32. This site has two host machines that we can log into if
necessary—PC21 on the internal private network and PC22 connecting on the Guest network. PC22 is segmented from our

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 1 of 152
 Cisco dCloud

network and only has access to the outside Internet. The 198.20.2.X/24 segment leverages an external WAAS virtual instance. In
most remote site deployments, this runs as an integrated service on the router. This leveraging is not available in this lab, since
this lab uses all virtual routers.

Branch 3

Branch 3 includes basic router connectivity for both the Internet and MPLS circuits, as well as for simplified IWAN provisioning.
This lab illustrates the deployment of a site using centralized management capabilities and an IWAN wizard.

HQ/DC

HQ/DC centralizes the DHCP and DNS for all non-guest branch networks. The Guest network at Branch 2 retrieves DHCP and
external DNS settings from a DHCP pool configured on BR2-WAN1. The Domain Controller, 198.18.133.1 in the HQ/DC, is also
the internal DNS Server and retrieves its DNS from an external DNS server. The vPod GW router, in HQ/DC, connects the demo to
the Internet in the role of the NTP Master.

Although distributed Internet connectivity is present at each of the locations, Internet Traffic for Branch1 is forced out through the
HQ/DC, leveraging the traditional model of centralized Internet services and security. The Direct Internet Attach (DIA) door is open
at Branch 2 for both the internal secure VLANs and the Guest Network. The option exists to use the distributed connectivity at the
remote site edge (by network, by location) in order to accommodate demand for distributed connectivity. This demand is often
associated with the rollout of public cloud based SaaS applications.

To accentuate this, part of the lab focuses on remote site guest services that allow for DIA at Branch 2 (which helps limit traffic
over WAN links), as well as looking at accommodating internal secure networks accessing DIA.

Challenges

Duplicate route entries present the potential for conflict. Using virtual routing tables helps to avoid a default route pointing out of
both the local Internet and MPLS circuits for simplified connectivity. Conflicts with the default route will also lead to challenges with
VPN connectivity over each of the underlying transports. Another conflict could occur with the default route being recorded
dynamically by the routing protocol, which is leveraged over the DMVPN tunnels and pointing out of the overlay.

This could possibly occur in situations where a customer prefers centralized Internet connectivity, or attempts to leverage
centralized connectivity as a backup to DIA. You could solve this problem by creating a static route to the public address of the
hub, or configuring a default route, but that solution limits you to routing traffic through the hub, which is problematic for voice,
video or other peer-to-peer applications.

Dynamic Multipoint Virtual Private Networks (DMPVN) include simple Hub and Spoke design, but with the added benefits of
dynamic tunnel establishment between spokes for direct transport capabilities. Manually adding routes to spokes to accommodate
spoke-to-spoke dynamic VPN tunnel establishment would not scale, since remote site addresses are dynamically assigned via
DHCP from the provider, which makes route prediction nearly impossible.

Solutions

Front Door VRF (Virtual Routing and Forwarding), or fVRF, provides a solution. fVRF virtualizes routing within devices by creating
separate virtual routing forwarding tables on the devices. By hiding the Internet Route connectivity at each Internet termination
point within a dedicated VRF (VRF ISP1 and VRF ISP2) leveraging VRF/VRF-Lite, the default routes contained within these VRFs
are also hidden from each other and from the global routing table. This eliminates competing routing information within the global
default routing table, leaving only the default route pointing out of the tunnel, forcing centralization of Internet services.

Using a DMPVN overlay design, there is no need to exchange routing with providers. All that is necessary is a default route out to
the next hop Provider Edge (PE) for each hidden circuit, as well as a mechanism to permit overlay tunnels to see and use default

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 2 of 152
 Cisco dCloud

routes to establish DMVPN connectivity to other sites. VRF is a requirement for all underlying transport, as it enables the desired
flexibility and convenience of simplified provider migrations.

With the exception of external facing interfaces, every other interface is part of the default VRF/routing table. The VPN Tunnel
configuration allow the VRF tunnels to leverage the dedicated VRFs configured on the external facing interfaces to establish VPN
connectivity over the provided transport. This is the Front Door VRF.

IP Addresses

IWAN design uses DMVPN running separate DMVPN tunnel instances for Public and Private transport. Public Tunnel interfaces
use interface Tunnel 100 (IP addressing space 172.29.X.1/16) at each site. MPLS tunnel interfaces leverage interface Tunnel 200
(IP addressing space 172.30.X.1/16).

The unique address for each device correlates to the branch number, with third octet changing to match:

• HQ/DC = 172.29.0.1 and 172.30.0.1

• BR1 = 172.29.1.1 and 172.30.1.1

• BR2 = 172.29.2.1 and 172.30.2.1

• BR3 = 172.29.3.1 and 172.30.3.1

Video Resources
Several videos are available to walk you through the LAB, and are accessible using the link below:

• https://salesconnect.cisco.com/#/search/IWAN%25204D/undefined

About this Lab

The Cisco IWAN Cisco Intelligent WAN (IWAN) Design Workshop - 4D Series Lab v1 includes

• Lab 1: Initial Setup

• Lab 2: Starting with IWAN

• Lab 3: DMVPN

• Lab 4: Intelligent Path Control – PFR

• Lab 5: Optimizing Application Performance

• Lab 6: Security and Distributed Network

• Lab 7: Simplified Management

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 3 of 152
 Cisco dCloud

Lab Topology
This demonstration includes several server virtual machines. Most of the servers are fully configurable using the administrative
level account. Administrative account details are included in the script steps where relevant and in the server details table.

Figure 1. Lab Topology

Figure 2. Generic IWAN Topology

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 4 of 152
 Cisco dCloud

Figure 3. Lab Overview

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 5 of 152
 Cisco dCloud

Lab Preparation
Follow the steps below to schedule your demonstration and configure your demonstration environment.

1. Browse to dcloud.cisco.com, select the location closest to you, and then login with your Cisco.com credentials.

2. Schedule a demonstration [Show Me How].

3. Verify your connection from the demonstration location before performing any demonstration scenario. [Show Me How]

4. Verify your demonstration has a status of Active under My Demonstrations on the My Dashboard page in the dCloud UI.

• It may take up to 15 minutes for your demonstration to become active.

5. Connect to the lab environment using Cisco AnyConnect (Recommended) [Show Me How] and a local RDP client. [Show Me
How]

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 6 of 152
 Cisco dCloud

Lab 1: Initial Setup

Complete the following steps prior to session kickoff.

Lab Steps
1. Once VPN connectivity has been established, RDP to PC01 and leverage MTPuTTY on the workstation.

NOTE: The password for all workstations is C1sco12345.

Figure 4. Using native RDP client after VPN into the demo

2. Double click the MTPuTTY icon on the desktop.

NOTE: Before launching MTPuTTY, make sure it is not already open as part of any previous sessions. Do not use or modify any of
the settings in putty.exe, as this could cause problems.

Figure 5. Launch MTPuTTY

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 7 of 152
 Cisco dCloud

3. View devices in the pane on the left by selecting Servers from the View menu.

Figure 6. List of servers in MTPuTTY

NOTE: The default username/password information for each of the devices is admin/C1sco12345.

Some devices connect via VTY while most connect via CON. Routers that connect via VTY need to log in before proceeding.

4. When opening devices, pay attention to the preferred order by referencing the tabs from left to right.

Figure 7. Recommended order of open MTPuTTY tabs

5. Launch all terminal windows with MTPuTTY in full screen mode.

6. Close out the Server View preview panel. This lab uses load/send script capability within MTPuTTY to make it easy to issue
commands across multiple devices for verification.

NOTE: Some commands referencing interface specifics might not be valid for all devices and therefore we will ignore the
generated output errors.

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 8 of 152
 Cisco dCloud

7. Before starting with command line review:

• Load the MTPuTTY 000_Adjust_Terminal_Length script.

• Select all devices to avoid verification output interruption.

Figure 8. Launching scripts within MTPuTTY

Figure 9. Launching scripts within MTPuTTY

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 9 of 152
 Cisco dCloud

Lab 2: Starting with IWAN

Lab Steps
1. Load the 001_Front_Door_VRF_Configuration.

2. Clear selected devices and select all border routers (BR1-WAN1, BR1-WAN2, BR2-WAN1, HQ-DC-WAN1, HQ-DC-WAN2).

NOTE: BR3-WAN1 is not used until later in the lab when we showcase an IWAN Wizard deployment leveraging Cisco Prime
Infrastructure.

3. Discuss the purpose of each verification command prior to sending the script and reviewing.

• sh ip int br | ex una

• sh run | sec vrf definition

• sh run int g1 | in Eth|address|vrf

• sh run int e0/0 | in Eth|address|vrf

• sh run int e0/1 | in Eth|address|vrf

• sh ip vrf interface

• sh ip route vrf ISP1

• sh ip route vrf ISP2

• sh run | sec ip route vrf

• sh ip route

Figure 10. Load 001 script

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 10 of 152
 Cisco dCloud

The upcoming steps will:

• Walk through performing a basic show ip interface brief | exclude unassigned to compare CLI output to the diagram.

• Run sh run | section vrf definition to view VRFs configuration.

• Run sh run int X/X | in Eth|address|vrf to illustrate how VRF configuration is applied to interfaces on the border routers.

• Illustrate interface to VRF mappings by looking at the output of show ip vrf interface.

• Viewing the routing tables for both VRF instances along with the static VRF based static route and the global default
routing table.

4. Send script 001. Once complete review the verification output.

NOTE: Errors may exist in the output for script 001, as not all routers have the same interface naming.

HQ-DC-WAN1

1. Start by reviewing the configuration for the routers in the data center. Two physical interfaces exist, as well as the configured
tunnel interface and loopback.

NOTE: Interface Tunnel 0 and Interface Tunnel 1 were created dynamically. They are associated with PfRv3 and Multicast
configuration, respectively.

2. Turning on WAAS integration capability on our head-end border routers creates the AppNav-Compress1 and AppNav-
UnCompress1 interfaces. AppNav allows load sharing across all available physical and virtual optimization resources. The
AppNav integration also optimizes asymmetric traffic flows—a critical consideration when adding optimization capabilities into
an Active/Active WAN environment.

Figure 11. show ip interface brief | exclude unassigned output

3. VRF configuration is very simple and straightforward. Type the vrf definition name and assign a route distinguisher (rd
x:x).

Figure 12. sh run | section vrf definition output

4. The VRF forwarding command displays under the interface configuration.

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 11 of 152
 Cisco dCloud

Figure 13. show run interface g1 output

5. After configuration, the interface to VRF mapping is evident in the show ip vrf interfaces output.

Figure 14. show ip vrf interfaces output

NOTE: Even though VRF naming conventions are locally significant, ensure they match across all devices to simplify template
configuration. In VRF, verification and troubleshooting uses VRF as the keyword, followed by the specific VRF name configured.
Outside of leveraging the VRF to provide hidden routing information for our tunnels to leverage as part of the front door VRF
configuration, VRF is not necessary throughout the rest of the environment.

Figure 15. show ip route vrf output

6. Enter show ip route vrf. The routing table is now virtualized and ready for the DMVPN overlay.

Figure 16. show run | sec ip route vrf output

7. Outside of the connected interface, the only other route is a static default route that was setup using ip route vrf ISP1 0.0.0.0
0.0.0.0 198.51.100.1.

NOTE: You have the option of using a static route or leveraging routing with the provider to obtain a default route. Routing with the
provider limits you in achieving complete transport independence.

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 12 of 152
 Cisco dCloud

Figure 17. show ip route output (truncated)

8. Next, show a familiar ip route statement to provide visibility into the global table. This part of the lab runs EIGRP and learning
routes from HQ-DC-Core-SW, as well as each of the locations over the DMVPN tunnel.

NOTE: Quickly review the same configuration output on the other routers. It is recommended that you view HQ-DC-WAN1, HQ-
DC-WAN2 and BR2-WAN1 outputs.

HQ-DC-WAN2

This router has two physical interfaces, as well as our configured tunnel interface and loopback.

NOTE: Interface Tunnel 0 and Interface Tunnel 1 were created dynamically. They are associated with PfRv3 and Multicast
configuration, respectively.

1. Turning on WAAS integration capability on our head-end border routers creates the AppNav-Compress1 and AppNav-
UnCompress1 interfaces, which form the optimization cluster between the two borders.

Figure 18. show ip interface brief | exclude unassigned output

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 13 of 152
 Cisco dCloud

2. A VRF is also configured for the MPLS terminating interfaces.

Figure 19. sh run | section vrf definition output

NOTE: Although this may not be necessary in your environment, it is a recommended best practice and ignoring can cause
undesired complications.

3. Focusing on transport independent design, treat all underlying networks equally to provide future flexibility for migration.

NOTE: The VRF names are locally significant and the route distinguisher (rd) is in the form of X:X.

4. The VRF is applied to the interface using the vrf forwarding command.

Figure 20. show run interface g1 output

5. The show ip vrf interfaces output shows the VRF to interface mapping.

Figure 21. show ip vrf interfaces output

6. The VRF specific routing table is virtualized now virtualized and ready for the overlay to realize transport independence.

Figure 22. show ip route vrf output

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 14 of 152
 Cisco dCloud

7. Outside of the connected interface, the only other route is a static default route that was setup using ip route vrf ISP2 0.0.0.0
0.0.0.0 203.0.113.1.

Figure 23. show run | sec ip route vrf output

8. Notice in the global default routing table, EIGRP is running and learning routes from Core SW1, as well as each of the
locations over the DMVPN tunnel.

Figure 24. show ip route output (truncated)

BR1-WAN1

This router has three physical interfaces. One interface connects to the underlay network and two connect Router 1 to Router 2
and to the host PC11. It is necessary to have a shared segment for PfRv3 Master Branch to Branch border router communications.

NOTE: Interface Tunnel 0 and Interface Tunnel 1 were created dynamically. They are associated with PfRv3 and Multicast
configuration, respectively.

Figure 25. show ip interface brief | exclude unassigned output

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 15 of 152
 Cisco dCloud

1. Configure the VRF and RD.

Figure 26. sh run | section vrf definition output

2. The VRF is applied to the interface using the vrf forwarding command.

Figure 27. sh run int e0/0 | in Eth|address|vrf output

3. The show ip vrf interfaces output shows the VRF to interface mapping.

Figure 28. show ip vrf interfaces output

4. The VRF specific routing table is virtualized and ready for overlay.

Figure 29. show ip route vrf output

5. Outside of the connected interface, the only other route is a static default route that was setup using ip route vrf ISP1 0.0.0.0
0.0.0.0 198.51.100.5.

Figure 30. show run | sec ip route vrf output

6. Looking at the global default routing table we can see that we are running EIGRP and are learning routes for each of the
locations over the DMVPN tunnel. You can also see that this site is taking advantage of centralized Internet connectivity.

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 16 of 152
 Cisco dCloud

Figure 31. show ip route output (truncated)

BR1-WAN2

This router has three physical interfaces. One interface connects to the underlay network and two connect Router 1 to Router 2
and to the host PC11.

NOTE: Interface Tunnel 0 and Interface Tunnel 1 were created dynamically. They are associated with PfRv3 and Multicast
configuration, respectively.

Figure 32. show ip interface brief | exclude unassigned output

1. Configure the VRF and RD.

Figure 33. sh run | section vrf definition output

2. The VRF is applied to the interface using the vrf forwarding command.

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 17 of 152
 Cisco dCloud

Figure 34. sh run int e0/0 | in Eth|address|vrf output

3. The show ip vrf interfaces output shows the VRF to interface mapping.

Figure 35. show ip vrf interfaces output

4. The routing table is now virtualized and ready for the DMVPN overlay.

Figure 36. show ip route vrf output

5. Outside of the connected interface the only other route is a static default route that was setup using ip route vrf ISP2 0.0.0.0
0.0.0.0 203.0.113.5.

Figure 37. show run | sec ip route vrf output

6. Looking at the global default routing table, we can see that This part of the lab runs EIGRP and learning routes from HQ-DC-
Core-SW, as well as each of the locations over the DMVPN tunnel. This site also takes advantage of centralized Internet
connectivity.

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 18 of 152
 Cisco dCloud

Figure 38. show ip route output (truncated)

BR2-WAN1

This router has five physical interfaces. You could leverage three logical sub-interfaces for our inside network configuration in the
real world. This would be typical of a router on a stick deployment model. The sub-interfaces act as gateways for each of the VLAN
segments specific to this site. Logical or physical configuration does not affect the design, keeping it as simple as by using
separate physical interfaces with virtual routers.

NOTE: Interface Tunnel 0 and Interface Tunnel 1 were created dynamically. They are associated with PfRv3 and Multicast
configuration, respectively.

Figure 39. show ip interface brief | exclude unassigned output

1. Configure the VRF and RD.

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 19 of 152
 Cisco dCloud

Figure 40. sh run | section vrf definition output

2. The VRF is applied to the interface using the vrf forwarding command. You could also issue a show run int e0/3 to look at the
vrf forwarding for the Guest Network interface.

Figure 41. sh run int e0/0 and e0/1| in Eth|address|vrf output

3. The show ip vrf interfaces output shows the VRF to interface mappings. The guest network interface uses to the same ISP1
VRF as the outside Internet ISP interface. This prevents that segment from mixing with private segments, and allows traffic to
route out locally. This is a relevant use case for initial Direct Internet Attach (DIA) provisioning.

Figure 42. show ip vrf interfaces output

4. Now we have three separate routing tables on the router. The VRF specific routing tables are virtualized and ready for the
DMVPN overlay.

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 20 of 152
 Cisco dCloud

Figure 43. show ip route vrf output

Figure 44. show ip route vrf output

5. Outside of the connected interfaces the only other routes are static default routes that were setup for each VRF using ip route
vrf ISP1 0.0.0.0 0.0.0.0 198.51.100.9 and ip route vrf ISP2 0.0.0.0 0.0.0.0 203.0.113.9.

Figure 45. show run | sec ip route vrf output

6. The global default routing table runs EIGRP and learning routes from each of the locations over the tunnels. Equal cost
multipath routing (ECMP) over the DMVPN tunnels is not necessary for Active/Active configuration, as PfRv3 provides load-
balancing capability for unclassified traffic.

NOTE: The delay on the interface tunnel 100 is set to a higher value then the MPLS overlay path. This also occurs with DMVPN
configuration. You will take a closer look at EIGRP routing configuration on all devices after discussing the DMVPN configuration.

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 21 of 152
 Cisco dCloud

Figure 46. show ip route output (truncated)

Figure 47. show ip route output (truncated)

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 22 of 152
 Cisco dCloud

7. For each terminal window

• Right click the terminal window and select Reset Terminal.

• Right click the terminal window and select Clear Scrollback. Clear the terminal and scrollback in each MTPuTTY tab

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 23 of 152
 Cisco dCloud

Lab 3: DMVPN
During this lab, you perform a basic show run interface tunnel and look at the DMVPN Tunnel configuration on the aggregation
and remote site routers. The lab also looks at show ip nhrp brief and show ip nhrp detail to illustrate how NHRP dynamically
maps tunnel addresses to physical addresses on the Next Hop Servers (NHS).

This lab focuses on the configuration independent of encryption capabilities, as encryption is simply an added layer of
configuration for security purposes. Although DMVPN is DMVPN without encryption services, you should not overlook or downplay
security.

Lab Steps
1. Load 002_DMVPN_Tunnel_Configuration.

2. Select all five border routers.

3. Discuss the purpose of each verification command prior to sending the script and reviewing.

NOTE: At a minimum, it is recommended that you review HQ-DC-WAN1, HQ-DC-WAN2, and BR2-WAN1.

• show run interface Tunnel 100

• show run interface Tunnel 200

• show ip nhrp brief

• show ip nhrp detail

4. Send script 002. Review the verification output.

Figure 48. Run 002 MTPuTTY script.

HQ-DC-WAN1

1. Set the interface bandwidth in Kilobits to equal 100Mbps (bandwidth 100000).

2. Assign the unique IP Address within the 172.29.X.X/16 subnet (ip address 172.29.0.1).

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 24 of 152
 Cisco dCloud

NOTE: It is recommended to set the Tunnel MTU to 1400 (ip mtu 1400) and to configure ip tcp adjust-mss to 1360. The IP and
TCP headers combine for 40 bytes of overhead, so the typical MSS value reported by network clients will be 1460 with 1500 byte
MTU. This design includes encrypted tunnels with a 1400 byte MTU, so the MSS used by endpoints should be configured to be
1360 to minimize any impact of fragmentation.

The bottom half of the tunnel configuration illustrates that DMVPN uses multipoint GRE (mGRE) tunnels (tunnel mode gre
multipoint). This type of tunnel requires a source interface only (tunnel source g1). The source interface that connects to the
Internet is the same as the one assigned to VRF ISP1, leveraging the vrf forwarding command.

3. Set the tunnel vrf command to the VRF defined previously for Front Door VRF.

NOTE: This command is not making the tunnel part of the VRF, as we have not issued vrf forwarding under this interface. This
command allows the tunnel to get priority treatment from the VRF since the tunnel source is an interface belonging to that VRF.
The tunnel remains part of the global routing table, but will have permission to use the VRF to establish overlay DMVPN tunnel
connectivity.

4. Look at the Next Hop Resolution Protocol (NHRP) portion of the configuration.

NOTE: The DMVPN hub router takes on the role of NHRP server or NHS for all of the spokes. NHRP is leveraged by spoke
routers to determine the tunnel destinations for remote peers attached to the mGRE tunnel. This allows for dynamic tunnel
configuration between the spokes when needed to provide for full mesh connectivity without the administrative overhead
associated with configuring and managing tunnels between all devices. On the hub, use the command ip nhrp map multicast
dynamic to discover the spoke tunnel address to real address mappings and to create the database.

NHRP requires all devices within a DMVPN cloud to use the same network ID (ip nhrp network-id 100) and authentication key (ip
nhrp authentication CISCO). The NHRP cache hold time should be configured to 600 seconds (ip nhrp holdtime 600). The ip
nhrp redirect command allows the DMVPN hub to notify spoke routers that a more optimal path may exist to a destination network.
This may be required for DMVPNnm spoke-spoke direct communications. When leveraging this command, DMVPN leverages a
Phase III deployment model. Before DMVPN Phase III commands became available, a workaround is necessary to redirect routing
to accomplish spoke-to-spoke connectivity.

5. EIGRP relies on a multicast transport and requires NHRP to add routers automatically to the multicast NHRP mappings.

NOTE: You encourage follow up one-on-one design workshops if this overview is used as part of a one-to-many design
clinic/demand generation event.

The additional configuration under the tunnel interface accommodates other optional services, such as, site-to-site multicast
transport, Per Tunnel QoS, and AVC.

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 25 of 152
 Cisco dCloud

Figure 49. show run interface tunnel output

6. The output of show ip nhrp brief shows two dynamically established tunnels, one for each of our remote sites, as well as
actual addresses registered and mapped.

NOTE: Since we allow direct site-to-site VPN Tunnel establishment between spoke sites in the configuration, this information will
later be shared by the NHRP server (NHS) when the remote site spokes attempt to establish direct site communications.

Figure 50. show ip nhrp brief output

7. The show ip nhrp detail output contains more information.

NOTE: The spoke is able to tell the hub the speed of its connection so the hub shapes traffic to the spoke at the subscribed rate to
avoid traffic saturation.

Figure 51. Show ip nhrp detail output

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 26 of 152
 Cisco dCloud

8. The show dmvpn output provides yet another view of the mapping.

NOTE: Quickly review the same configuration output on the other routers. Briefly look at the other hub and BR2-WAN1.

Figure 52. show dmvpn output

HQ-DC-WAN2

1. Set the interface bandwidth in Kilobits to equal 100Mbps (bandwidth 100000).

2. Assign the unique IP Address within the 172.30.X.X/16 subnet (ip address 172.30.0.1).

3. Set the Tunnel MTU to 1400 (ip mtu 1400) and to configure ip tcp adjust-mss to 1360.

The bottom half of the tunnel configuration illustrates how DMVPN uses multipoint GRE (mGRE) tunnels (tunnel mode gre
multipoint). This type of tunnel requires a source interface only (tunnel source g1). The source interface is the same as the one that
connects to the Internet.

4. Set the tunnel vrf command to the VRF defined previously for Front Door VRF.

NOTE: This command allows the tunnel to get priority treatment from the VRF since the tunnel source is an interface belonging to
that VRF. The tunnel remains part of the global routing table, but will have permission to use the VRF to establish overlay DMVPN
tunnel connectivity.

5. On the hub, configure the ip nhrp map multicast dynamic command.

NHRP requires all devices within a DMVPN cloud to use the same network ID (ip nhrp network-id 200) and authentication key (ip
nhrp authentication CISCO). The NHRP cache holdtime should be configured to 600 seconds (ip nhrp holdtime 600). The ip nhrp
redirect command allows the DMVPN hub to notify spoke routers that a more optimal path may exist to a destination network,
which may be required for DMVPN spoke-spoke direct communications.

NOTE: You encourage follow up one-on-one design workshops if this overview is used as part of a one-to-many design
clinic/demand generation event.

A follow-up design session may be necessary to discuss DMVPN phases, scaling, and design options based on your specific
requirements. Not every organization allows spoke-to-spoke connections. While this lab leverages DMVPN Phase 3, other options
are supported.

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 27 of 152
 Cisco dCloud

Figure 53. show run interface tunnel output

6. The output of show ip nhrp brief illustrates two dynamically established tunnels, one for each of our remote sites, as well as
actual addresses registered and mapped.

NOTE: Given that we have allowed direct site-to-site VPN Tunnel establishment between spoke sites as a result of our
configuration, this information will later be shared by the NHRP server when the remote site spokes attempt to establish direct site
communications.

Figure 54. show ip nhrp brief output

7. The show ip nhrp detail output contains more information.

NOTE: The spokes notify the hub of their subscribed rate, allowing the hub to leverage per tunnel QoS, shaping to the spoke to
avoid spoke saturation.

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 28 of 152
 Cisco dCloud

Figure 55. show ip nhrp detail output

8. Look at the show dmvpn output for another view of the mapping.

Figure 56. show dmpvn output

BR2-WAN1

BR2-WAN1 has connections to both hubs. Differences exist on the spoke side, taking advantage of static mappings to each hub
over the dedicated DMVPN transport networks. A partial or entire configuration is applied to each spoke, contingent on whether
they are single attached or dual attached.

1. For Interface Tunnel 100, set the interface bandwidth in Kilobits to equal 20Mbps (bandwidth 20000).

2. Assign our unique IP Address within the 172.29.X.X/16 subnet (ip address 172.29.2.1).

3. Set the Tunnel MTU to 1400 (ip mtu 1400) and configure ip tcp adjust-mss to 1360.

The bottom half of the tunnel configuration illustrates how DMVPN uses multipoint GRE (mGRE) tunnels (tunnel mode gre
multipoint). This type of tunnel requires a source interface only (tunnel source g1). The source interface is the same as the one that
connects to the Internet.

4. Set the tunnel vrf command to the VRF defined previously for Front Door VRF.

NOTE: This command allows the tunnel to get priority treatment from the VRF since the tunnel source is an interface belonging to
that VRF. The tunnel remains part of the global routing table, but will have permission to use the VRF to establish overlay DMVPN
tunnel connectivity.

NHRP requires several additional configuration statements to define the NHRP server (NHS) and NHRP map statements for the
DMVPN hub router mGRE tunnel IP address.

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 29 of 152
 Cisco dCloud

EIGRP relies on a multicast transport and therefore spoke routers require the NHRP static multicast mapping (ip nhrp map
multicast 198.51.100.2).

5. For the Next Hop Resolution Protocol Server (NHS) value, use the mGRE tunnel address for the DMVPN hub router (ip nhrp
nhs 172.29.0.1).

6. On the spoke, configure static mappings to the hub (ip nhrp map 172.29.0.1 198.51.100.2).

NHRP requires all devices within a DMVPN cloud to use the same network ID (ip nhrp network-id 100) and authentication key (ip
nhrp authentication CISCO). The NHRP cache holdtime should be configured to 600 seconds (ip nhrp holdtime 600). For a phase
III style deployment, we want to configure the ip nhrp shortcut command to enable shortcut switching when building spoke-to-
spoke tunnels. The ip nhrp registration no-unique command is not needed in our topology, but has been included to show you the
command that would be required if you are using DHCP allocated addressing from the provider.

7. Since this single router terminates both circuits, look at Interface Tunnel 200, as well.

Figure 57. show run interface tunnel output

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 30 of 152
 Cisco dCloud

Figure 58. Show run int tunnel 200

8. The output of show ip nhrp brief illustrates two static tunnels pointing to our hubs, as well as, actual addresses registered
and mapped.

Figure 59. show ip nhrp brief output

9. The show ip nhrp detail output provides more information.

Figure 60. show ip nhrp detail output

10. The show dmvpn output provides another view of the mapping.

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 31 of 152
 Cisco dCloud

Figure 61. show dmpvn output

NOTE: Minimize the potential perceived complexity of the configuration by highlighting the repetitiveness of spoke router
configuration. The only things that are unique are the ip address and the bandwidth statements. Introduce the value of templates
and automation tools for simplified deployment. You will show an IWAN Wizard deployment for Branch 3 leveraging Cisco Prime
Infrastructure.

DMVPN is the most complex portion of the IWAN design, especially when adding the encryption related configuration. The
configuration is slightly simplified by repetition and can be made into a template for simplified deployment through Prime
Infrastructure or rolled out leveraging an automated deployment model through a number of tools and services.

11. Look at the encryption configuration. Although verification commands are sent to all routers, the configuration is repetitive,
enabling you to look at another border router to get a complete picture of the encryption policy.

12. Reset Terminal and Clear Scrollback.

13. Load script 003_Crypto_Configuration and select BR2-WAN1 routers.

14. Discuss the purpose of each verification command prior to sending the script and reviewing.

• sh run | sec crypto IKEv2 keyring

• sh run | sec crypto IKEv2 profile

• sh run | sec crypto IKEv2 dpd

• sh run | sec crypto ipsec

• sh crypto IKEv2 profile

• sh crypto ipsec profile

• sh run int tun100 | in Tunnel|ipsec

• sh run int tun200 | in Tunnel|ipsec

• clear crypto sa counters

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 32 of 152
 Cisco dCloud

• sh crypto ipsec sa

Load 003 MTPuTTY script

Next, look at the crypto IKEv2 keyring and profile configuration and the phase 2 IPsec configuration parameters. A specific line
under the tunnel configuration enables encryption and that completes the security capability addition to our DMVPN tunnels,
allowing you to protect data and to ensure confidentiality over public transport. When complete, empty the crypto counters and look
at the IPSec SA specifics.

15. Send script 003. Once complete review the verification output on BR2-WAN1.

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 33 of 152
 Cisco dCloud

BR2-WAN1

1. Look at BR2-WAN1, which terminates both tunnels on a single router.

Figure 62. show run | sec crypto IKEv2 keyring output

The crypto keyring defines a pre-shared key (or password) valid for IP sources that are reachable within a particular VRF. The key
is configured as ‘cisco123’ leveraging wildcard address 0.0.0.0 0.0.0.0 for this pre-shared key. This allows the same password to
apply to any IP source authenticating. In order to provide additional security one could leverage certificates in the place of pre-
shared keys. You can definitely cover this configuration in more detail during a one-on-one design session.

2. The default IKEv2 proposal is used, which includes the following:

• Encryption with AES cipher with a 256-bit key

• Integrity with SHA with 512-bit digest

• Pseudo-random function with SHA with 512-bit digest

• Diffie-Hellman group: 5

Figure 63. show run | sec crypto IKEv2 profile output

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 34 of 152
 Cisco dCloud

3. To illustrate leveraging IKEv2 proposal defaults, move onto the IKEv2 profile configuration.

The IKEv2 profile creates an association between an identity address, a VRF, and a crypto keyring. A wildcard address within a
VRF is referenced with 0.0.0.0. The profile also defines what method of key sharing will be used on this router with authentication
local and what methods will be accepted from remote locations with authentication remote. The pre-share keyword is used with the
keyring defined in the previous output.

Figure 64. show run | sec crypto IKEv2 dpd output

4. DPD is essential in order to facilitate fast convergence and for spoke registration to function properly in case a DMVPN hub is
restarted. The IWAN design recommends you set the remote site DPD timer to 40 seconds with five for a second retry. This
command must be configured for spoke routers only.

Figure 65. show run | sec crypto ipsec output

5. Next, configure phase 2 parameters and specify an IPSec transform set. A transform set is an acceptable combination of
security protocols, algorithms and other settings to apply to IPsec-protected traffic. Peers agree to use a particular transform
set when protecting a particular data flow.

6. IPsec transform sets for both DMVPN tunnels use:

• ESP with the 256-bit AES encryption algorithm

• ESP with the SHA (HMAC variant) authentication algorithm

Although DMVPN supports both tunnel mode (mode tunnel) and transport mode (mode transport), transport mode is highly
recommended for most situations, except when the GRE tunnel endpoints are different from the crypto tunnel endpoints such as
with a Dual Tier design. In that case, tunnel mode is required.

The IPsec profiles bring the entire configuration together by creating an association between an IKEv2 profile and an IPsec
transform-set. This is what will be applied under the tunnel interfaces. The security-association replay window-size is set to 512 or
1024 if supported to accommodate out of order packets that might result from the implementation of Low Latency Queuing (LLQ)
which is part of our QoS policy.

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 35 of 152
 Cisco dCloud

Figure 66. show crypto IKEv2 profile output

Figure 67. show crypto IKEv2 profile output

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 36 of 152
 Cisco dCloud

7. This output provides a different look at the ISAKMP profile.

Figure 68. show crypto ipsec profile output

8. The output associated with this command provides a different look at the IPsec profile configuration.

Figure 69. show run interface tunnel X | include Tunnel|ipsec output

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 37 of 152
 Cisco dCloud

9. A single command under the interface enables encryption.

Figure 70. show crypto ipsec sa output (Truncated)

10. The show crypto ipsec sa output shows IPsec security associations and encrypted packets.

11. Next, review our EIGRP named mode routing configuration next.

12. Reset Terminal and Clear Scrollback.

13. Load script 004_Routing_Review. Select all edge devices.

14. Discuss the purpose of each verification command prior to sending the script and reviewing.

• sh ip eigrp interface

• sh ip eigrp neighbor

• sh run | sec router eigrp

• sh run | sec ip prefix-list TUNNEL

• sh run | sec route-tag

• sh ip access-list DMVPN-100-SPOKES

• sh ip access-list DMVPN-200-SPOKES

• sh run | sec route-map SET

• sh run | sec route-map BLOCK

• sh run | sec route-map LEAK

• sh run | sec route-map BRANCH

• sh ip route eigrp

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 38 of 152
 Cisco dCloud

Figure 71. Load 004 MTPuTTY script

15. Start by looking at the enabled EIGRP interfaces followed by the neighbor relationships that have been established over the
enabled links. You will then turn our attention to the EIGRP related configuration. Check to see whether there is any prefix-list
or route-maps configured as part of the EIGRP filtering process. Look at the routing table for routes learned via EIGRP.

16. Send script 004. Once complete review the verification output on all edge devices or at a minimum on both Hubs and BR2-
WAN1.

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 39 of 152
 Cisco dCloud

HQ-DC-WAN1

1. Look at HQ-DC-WAN1 first.

Figure 72. show ip eigrp interfaces output

2. There are two interfaces enabled on HQ-DC-WAN1. One is connected to the Core Switch and other is the tunnel.

Figure 73. show ip eigrp neighbors output

3. The router is peering with both remote sites 1 and 2 over the tunnel. It is also peering with HQ-DC-CORE-SW.

Figure 74. show run | sec router eigrp output

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 40 of 152
 Cisco dCloud

The routing configuration on the Border Hub Routers are a little more involved as we are applying inbound and outbound
distribute-lists to the interfaces to protect against suboptimal routing. To send routing updates out of these interfaces, advertise all
directly connected networks as internal routes and leverage passive-interface default with no passive-interface for tunnel100 and
g2. Again, our EIGRP router-id is set to loopback 0 which is in accordance with best practices. Let us look at the route-maps and
associated configuration referenced as part of the distribute-list commands to get a better feel for what is happening with this
configuration.

Figure 75. show ip access-list

4. Start by classifying routes tied to this tunnel by leveraging an ACL. This ACL will be used as part of our route-map
configuration.

Figure 76. show run | sec route-tag

5. For scalability and simplified identification, we are using dotted decimal notations for route tagging where the routes we tag will
match the DMVPN subnet of 172.29.0.0.

Figure 77. show run | sec route-map

Route-maps work very similar to ACLs and Prefix-lists given that they are sequential in nature and leverage deny and permit
statements. They also have an implicit deny all at the end.

6. Map the route-map output back to the distribute-lists and the access-list from earlier. All routes sourced from our DMPVN
spokes are tagged with 172.29.0.0.

7. Override the implicit deny and leverage a permit statement to allow everything else in. The routes sent into the LAN are
tagged with a tag of 172.29.0.0. Any routes that have been tagged by the other DMVPN network are blocked with a tag of
172.30.0.0, preventing them from coming into this router from the LAN. Everything else is permitted and tagged going out of
the tunnel interface with a tag of 172.29.0.0. This configuration is an extremely scalable way to protect against suboptimal
routing to ensure that we only learn routes from intended sources.

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 41 of 152
 Cisco dCloud

Figure 78. show ip route eigrp output

8. You can see that we are learning routes from the other routers in HQ/DC and HQ-DC-CORE-SW. You also see that routes are
being learned over our DMVPN Tunnel interface from both remote sites.

HQ-DC-WAN2

1. HQ-DC-WAN2 has a very similar setup.

Figure 79. show ip eigrp interfaces output

2. You have two interfaces enabled on HQ-DC-WAN2. One is connected to the Core Switch and other is our tunnel.

Figure 80. show ip eigrp neighbors output

3. The router is peering with both remote sites 1 and 2 over the tunnel. It is also peering with HQ-DC-CORE-SW.

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 42 of 152
 Cisco dCloud

Figure 81. show run | sec router eigrp output

The routing configuration on the Border Hub Routers is a little more complicated, as we are applying inbound and outbound
distribution-lists to the interfaces to protect against suboptimal routing. Advertise all directly connected networks as internal routes
and leverage passive-interface default with no passive-interface for tunnel200 and g2 to send routing updates out of these
interfaces. The EIGRP router-id is set to loopback 0, in accordance with best practices. Look at the route-maps and associated
configuration referenced as part of the distribute-list commands to get a better feel for what is happening with this configuration.

Figure 82. show ip access-list

4. Start by classifying routes tied to this tunnel by leveraging an ACL. This ACL is part of our route-map configuration.

Figure 83. show run | sec route-tag

5. For scalability and simplified identification, use dotted decimal notations for route tagging where the tagged routes match the
DMVPN subnet of 172.30.0.0.

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 43 of 152
 Cisco dCloud

Figure 84. show run | sec route-map

Route-maps work very similar to ACLs and Prefix-lists given that they are sequential in nature and leverage deny and permit
statements. They also have an implicit deny all at the end. Next, map the route-map output back to the distribute-lists and the
access-list that we recently viewed. Notice the tagging of all routes sourced from our DMPVN spokes with a tag of 172.30.0.0. You
override the implicit deny and leverage a permit statement to allow everything else in. When we send the routes to into the LAN we
tag all routes with a tag of 172.30.0.0. You then block any routes that have been tagged by the other DMVPN network with a tag of
172.29.0.0 from coming into this router from the LAN. Everything else is permitted and tagged going out of the tunnel interface with
a tag of 172.30.0.0. This configuration is an extremely scalable way to protect against suboptimal routing to ensure that we only
learn routes from intended sources.

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 44 of 152
 Cisco dCloud

Figure 85. show ip route eigrp output

6. Routes from the other routers are being learned in HQ/DC and HQ-DC-CORE-SW. Routes are being learned over our
DMVPN Tunnel interface from both remote sites.

BR1-WAN1

1. Next, look at BR1 remote site routers.

Figure 86. show ip eigrp interfaces output

2. Three interfaces are enabled on BR1-WAN1. Two are connected to the shared LAN between the two edge routers and the
other is our tunnel.

Figure 87. show ip eigrp neighbors output

3. The router is peering with HQ-DC-WAN1 over the tunnel. It is also peering with BR1-WAN2 over both internal interfaces.

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 45 of 152
 Cisco dCloud

Figure 88. show run | sec router eigrp output

The routing configurations on the Spoke Routers also have an outbound distribute-list applied to the tunnel interface. You will look
at this in more detail in just a minute to see what it is doing. Advertise all directly connected networks as internal routes and
leverage passive-interface default with no passive-interface for tunnel100, e0/1 and e0/2 to send routing updates out of these
interfaces. The EIGRP router-id is set to the loopback 0 address, which is in accordance with best practices. The last line of
configuration tells us that we have configured the spoke routers as EIGRP Stubs advertising connected, summarized and
redistributed routes. The Leak-Map at the end of the command matches on a Route-Map that has no match entries meaning that it
matches everything. This allows us to override the default Stub Router behavior of not being able to advertise routes learned. Let
us look at the route-maps and associated configuration referenced as part of the distribute-list commands and the Leak-Map to get
a better feel for what is happening with this configuration.

Figure 89. show run | sec ip prefix-list output

4. Start by classifying tunnel subnets for each of the tunnels. This prefix-list will be used as part of our route-map configuration to
avoid sending the tunnel addressing out of our tunnel that we learned from our neighbor.

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 46 of 152
 Cisco dCloud

Figure 90. show run | sec route-tag

5. For scalability and simplified identification, use dotted decimal notations for route tagging and matching, where the routes we
match will match the tags of 172.29.0.0 and 172.30.0.0.

Figure 91. show run | sec route-map

Mapping this output back to the end of the EIGRP Stub command statement we see a line for route-map LEAK-EIGRP permit
1000 with nothing matching under it. This means match everything and allow it. The distribute-list that we looked at a moment ago
maps to route-map BRANCH-OUT. You can see that we are blocking the router from advertising routes that have a tag of
172.29.0.0 and 172.30.0.0, which are routes learned from the Hub Border Routers and other Remote Sites through the Hubs. You
just finished reviewing this configuration on the Hub Border Routers. You are also blocking tunnel routes 172.30.0.0/16 learned
from BR1-WAN2 from being advertised. This is what that prefix-list TUNNEL-ROUTES is matching. You then permit everything
else again with an empty permit route-map statement. This configuration is an extremely scalable way to protect against
suboptimal routing. With this configuration in place one spoke at a site can share routes with another spoke, but spokes with this
configuration will not share specific routes with tags and tunnel addressing learned by the other router out of the tunnel interface.

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 47 of 152
 Cisco dCloud

Figure 92. show ip route eigrp output

6. You are learning routes over the tunnel as well as from BR1-WAN2.

BR1-WAN2

1. Next look at BR1-WAN2, as the configuration is nearly identical.

Figure 93. show ip eigrp interfaces output

2. Three interfaces are enabled on BR1-WAN2. Two are connected to the shared LAN between the two edge routers and the
other is our tunnel.

Figure 94. show ip eigrp neighbors output

3. The router is peering with HQ-DC-WAN2 over the tunnel. It is also peering with BR1-WAN1 over both internal interfaces.

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 48 of 152
 Cisco dCloud

Figure 95. show run | sec router eigrp output

The routing configurations on the Spoke Routers also have an outbound distribute-list applied to the tunnel interface. You will look
at this in more detail in just a minute to see that it is doing the same thing that BR-WAN1 is doing. Advertise all directly connected
networks as internal routes and leverage passive-interface default with no passive-interface for tunnel100, e0/1 and e0/2 to send
routing updates out of these interfaces. The EIGRP router-id is set to the loopback 0 address, which is in accordance with best
practices. The last line of configuration tells us that we have configured the spoke routers as EIGRP Stubs advertising connected,
summarized and redistributed routes. The Leak-Map at the end of the command matches on a Route-Map that has no match
entries meaning that it matches everything. This allows us to override the default Stub Router behavior of not being able to
advertise routes learned. Let us look at the route-maps and associated configuration referenced as part of the distribute-list
commands and the Leak-Map to get a better feel for what is happening with this configuration.

Figure 96. show run | sec ip prefix-list output

4. Similarly to BR1-WAN1, start by classifying tunnel subnets for each of the tunnels. This prefix-list will be used as part of our
route-map configuration to avoid sending the tunnel addressing out of our tunnel that we learned from our neighbor.

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 49 of 152
 Cisco dCloud

Figure 97. show run | sec route-tag

5. For scalability and simplified identification, use dotted decimal notations for route tagging and matching, where the routes we
match will match the tags of 172.29.0.0 and 172.30.0.0.

Figure 98. show run | sec route-map

Mapping this output back to the end of the EIGRP Stub command statement we see a line for route-map LEAK-EIGRP permit
1000 with nothing matching under it. This means match everything and allow it. The distribute-list that we looked at a moment ago
maps to route-map BRANCH-OUT. You can see that we are blocking the router from advertising routes that have a tag of
172.29.0.0 and 172.30.0.0, which are routes learned from the Hub Border Routers and other Remote Sites through the Hubs. You
just finished reviewing this configuration. You are also blocking tunnel routes 172.29.0.0/16 learned from BR1-WAN1 from being
advertised. This is what that prefix-list TUNNEL-ROUTES is matching. You then permit everything else again with an empty permit
route-map statement. This configuration is an extremely scalable way to protect against suboptimal routing. With this configuration
in place one spoke at a site can share routes with another spoke, but spokes with this configuration will not share specific routes
with tags and tunnel addressing learned by the other router out of the tunnel interface.

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 50 of 152
 Cisco dCloud

Figure 99. show ip route eigrp output

6. You are learning routes over the tunnel and from BR1-WAN1.

7. Move over to BR2-WAN1. You will notice that the configuration is again very repetitive making it perfect for creating templates
for simplified deployment models.

Figure 100. show ip eigrp interfaces output

8. You have two interfaces enabled on BR2-WAN1 and both are the tunnels.

Figure 101. show ip eigrp neighbors output

9. As expected the router is peering with HQ-DC-WAN1 and HQ-DC-WAN2 over the tunnels.

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 51 of 152
 Cisco dCloud

Figure 102. show run | sec router eigrp output

The routing configurations on the Spoke Routers also have an outbound distribute-list applied to the tunnel interface. You will look
at this in more detail in just a minute to see that it is doing the same thing that BR-WAN1 and BR-WAN2 were doing. Advertise all
directly connected networks as internal routes and leverage passive-interface default with no passive-interface for tunnel100, e0/1
and e0/2 to send routing updates out of these interfaces. The EIGRP router-id is set to the loopback 0 address, which is in
accordance with best practices. The last line of configuration tells us that we have configured the spoke routers as EIGRP Stubs
advertising connected, summarized and redistributed routes. Notice that we are not leveraging a Leak-Map at the end of the
command to match on a Route-Map that has no match entries. Since there is no other routing device connected over the LAN,
there is no need to override the default Stub Router behavior of not being able to advertise routes learned. Let us look at the route-
maps and associated configuration referenced as part of the distribute-list command to get a better feel for what is happening with
this configuration.

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 52 of 152
 Cisco dCloud

Figure 103. show run | sec ip prefix-list output

10. Just as we did on BR1-WAN1 and WAN2, we will start by classifying tunnel subnets for each of the tunnels. This prefix-list will
be used as part of our route-map configuration to avoid sending the tunnel addressing out of our tunnel that we learned from
our neighbor. This configuration is actually not necessary given there is no Leak-Map and other router sharing the tunnel
routes of the other tunnel.

Figure 104. show run | sec route-tag

11. Once again for scalability and simplified identification we are using dotted decimal notations for route tagging and matching,
where the routes we match will match the tags of 172.29.0.0 and 172.30.0.0. Again given the absence of the Leak-Map and
other router sharing routes learned this configuration is not necessary but creates no harm.

Figure 105. show run | sec route-map

The distribute-list that we looked at a moment ago maps to route-map BRANCH-OUT. You are blocking the router from
advertising routes that have a tag of 172.29.0.0 and 172.30.0.0, which are routes learned from the Hub Border Routers and other
Remote Sites through the Hubs. You just finished reviewing this configuration. You are blocking tunnel routes 172.29.0.0/16 and
172.30.0.0/16 learned from future adjacently configured routers from being advertised. This is what that prefix-list TUNNEL-
ROUTES is matching. You then permit everything else again with an empty permit route-map statement. This configuration is an
extremely scalable way to protect against suboptimal routing. With this configuration in place and the addition of the Leak-Map, a
device participating in EIGRP at the site can share routes with this device, but spokes with this configuration will not share specific
routes with tags and tunnel addressing learned by the other device out of the tunnel interface.

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 53 of 152
 Cisco dCloud

Figure 106. show ip route eigrp output

12. You are learning routes over tunnel 200, which has a lower delay setting. Any other spoke router leverages the same
configuration seen previously.

13. Let us see NHRP go to work next by leveraging traceroute from one remote site to another.

• Reset Terminal and Clear Scrollback. Once complete

• Load script 005_NHRP_Traceroute.

• ‘Select None’ to clear all router checkboxes and select BR1-WAN1 ONLY.

14. Discuss the purpose of each verification command prior to sending the script and reviewing.

• clear ip nhrp

• show ip nhrp brief

• show crypto ikev2 sa

• traceroute 198.19.2.1

• traceroute 198.19.2.1 (up arrow key)

• show ip nhrp brief (up arrow key)

• show crypto ikev2 sa (up arrow key)

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 54 of 152
 Cisco dCloud

Figure 107. Load 005 MTPutty script

15. Start by clearing dynamic NHRP associations and look at NHRP status on the router.

16. Look at ikev2 sa output and perform back-to-back traceroutes to BR2-WAN1 internal host PC21 IP Address 198.19.2.21. You
should see that the first time we issue traceroute we go to the hub and the second time we go direct.

17. Look at changes to NHRP and IKEv2 SA status.

18. Send script 005. Once complete review the verification output on BR1-WAN1.

BR1-WAN1

Figure 108. Verification Output

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 55 of 152
 Cisco dCloud

A static association to the Hub exists through Tunnel 100. Using traceroute, the first hop hits the hub and travels to the spoke.

1. Use the up arrow key to issue the command again. The second time goes directly from spoke to spoke. This is the NHRP
Phase 3 deployment model at work.

2. Use the up arrow key to look at show ip nhrp brief again. Notice the dynamic entries for both the tunnel endpoint associated
with BR2-WAN1 and Branch 2 internal network 198.19.2.0/25.

3. Use the up arrow key several times to find the show crypto ikev2 sa command. Looking at our ikev2 SAs we see the
bidirectional security associations. These real addresses where learned from the NHRP Server.

4. Close out with a two-minute review of the following slide covering best practices associated with:

• Private peering with Internet providers

• Use of a separate DMVPN network per provider

• Transport settings

• Routing protocols

• Internet security

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 56 of 152
 Cisco dCloud

Figure 109. Power Point Slide

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 57 of 152
 Cisco dCloud

Lab 4: Intelligent Path Control – PFR

1. Reset Terminal and Clear Scrollback.

2. Load script 006_PfRv3_Configuration. Select all 6 routers including the Master Controller HQ-DC-MC.

3. Discuss the purpose of each verification command prior to sending the script and reviewing.

• sh run | sec domain 10

• sh run | sec HQ_Prefix

• sh run | sec Enterprise_Prefix

• sh run int tunn100 | in interface|domain

• sh run int tunn200 | in interface|domain

Figure 110. Load 006 MTPuTTY script

Performance Routing (PfR) delivers intelligent path selection. Devices play four roles in PfRv3 configuration:

• Hub Master Controller (MC) - The master controller at the hub-site, which can be either a data center or headquarters.
All policies are configured on the hub MC. It acts as master controller for domain and makes optimization decisions.

• Hub Border Routers - The border controllers at the hub-site. WAN interfaces terminate in the hub border routers which
are also acting as DMVPN Next Hop Resolution servers. A PfRv3 path name is enabled on the tunnel interfaces of these
routers. You can configure more than one WAN interface on the same device. You can also have multiple hub border
devices like we do in our topology.

• Branch Master Controller - The branch master controller is the master controller at the branch-site. There is no policy
configuration on this device. It receives policy from the Hub MC. This device acts as master controller for that site and is
responsible for making optimization decisions.

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 58 of 152
 Cisco dCloud

• Branch Border Router - The border device at the branch-site. There is no configuration other than enabling of PfRv3
border MC on the device. The WAN overlay interface that terminates on the device is detected automatically.

NOTE: When you have a single router at a remote site it will need to be configured as both a Branch Master Controller and a
Branch Border Router. Let look at our Hub Master Controller first where the bulk of the configuration lives. You will see the
simplified, centralized policy definition and control that gets pushed out to rest of the domain.

4. Send script 006. Once complete review the verification output on the HQ-DC-MC first followed by the Aggregation routers and
then the branches.

HQ-DC-MC

The bulk of the PfRv3 configuration happens on the Hub Master Controller. Domain policies are defined on the Hub Master
Controller and sent over the peering infrastructure to all MC peers at each site. Policies can be defined per application, or per
DSCP. You cannot mix and match DSCP and application based policies in the same class group, but multiple class groups can be
configured in a sequential order. Traffic that does not match any of the classification and match statements falls into a default
group, which we can either be load balanced or controlled to influence primary path selection tied to SLAs.

1. Start by specifying the domain name or number (domain 10) that will match on all of our devices.

Figure 111. show run | sec domain 10

2. Under vrf default, define the role of the device. On the Hub MC, the role was configured as master hub.

3. Set the source-interface to our loopback0 interface and specify a site-prefixes prefix-list that contains a list of site prefixes
that our internal to our DC environment and that we can disregard.

4. Configure an enterprise-prefix prefix-list for those prefixes that we want to learn and control.

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 59 of 152
 Cisco dCloud

Figure 112. show run | sec HQ_Prefix

The default monitor interval is 30 seconds. You can lower the monitor interval for some of critical applications in order to achieve a
fast failover to the secondary path (quick monitor). In a real world example, you might not choose to enable quick monitor for all of
the configured DSCP values, since there are multiple class groups configured and the syntax is pretty straight-forward.

Specify the class group using class followed by a unique name and sequence number. Under the class group, match on either
applications or dscp values and assign a built in policy or a custom policy template followed by path preference. The PUBLIC and
MPLS key words for path options are configured under the tunnel interfaces on the Hub Border Routers.

The available templates for domain policy types are:

• best-effort

• bulk-data

• low-latency-data

• real-time-video

• scavenger

• voice

• custom - Defines customized user-defined policy values.

HQ-DC-WAN1

1. Use the same domain number and under vrf default to assign the role as border.

Figure 113. show run | sec domain 10

2. Specify the source interface to be loopback0 and point to the location specific master loopback/source address.

3. Issue a show run interface tunnel100 | in interface|domain to see what is configured under the tunnel interface.

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 60 of 152
 Cisco dCloud

Figure 114. show run int tunn100 | in interface|domain

You will see a similar setup on HQ-DC-WAN2.

HQ-DC-WAN2

1. Use the same domain number and under vrf default we assign the role as border.

2. Specify the source interface to be loopback0 and we point to the location specific master loopback/source address.

Figure 115. show run | sec domain 10

3. Issue a show run interface tunnel200 | in interface|domain to see what is configured under the tunnel interface.

Figure 116. show run int tunn200 | in interface|domain

BR1-WAN1

1. Use the same domain number and under vrf default we assign the role as border.

Figure 117. show run | sec domain 10

2. Specify the source interface to be loopback0 and we point to the loopback of BR1-WAN2 as master for this site.

BR1-WAN2

BR1-WAN2 is both a branch master and a border. The border configuration is similar to what we have already looked at with the
exception that we specify the master as being local. You then go on to specify our second role as master branch. Again we specify
our source-interface as loopback0 and point to the Hub Master Controller.

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 61 of 152
 Cisco dCloud

Figure 118. show run | sec domain 10

BR2-WAN1

BR2-WAN1, being a single router in remote site 20, acts as both a border and a master branch router.

Figure 119. show run | sec domain 10

This is all that it takes to get PfRv3 up and running. The PfRv3 solution is more focused on applications. It provides a simple way to
provision policies based on the application (classification based on Cisco's deep packet inspection engine NBAR2). It provides
visibility into applications by integrating with Unified Monitoring (Performance Monitor) which is a built in function. Application
visibility includes bandwidth, performance, correlation to QoS queues, etc. It monitors performance metrics per DSCP rather than
monitoring on a per-flow or per-prefix basis.

When Application based policies are used, the MC will use a mapping table between the Application Name and the DSCP
discovered. This reduces the number of records significantly. PfRv3 also relies on performance data measured on the existing data
traffic on all paths whenever it can, thereby reducing the need of synthetic traffic which was the case in the past. Furthermore, the
measurement data is not exported unless there is a violation, which further reduces control traffic and processing of those records.
Unified Monitors (Performance Monitors) are automatically configured and activated in the background by PfRv3.

There is no need for manual configuration. Performance Monitor definitions are pre-defined on the Hub MC and distributed to
branch BRs using the domain infrastructure. Three different Performance Monitors are automatically enabled on all Border Routers
in the domain:

• Performance Monitor 1: to learn site prefixes (applied on external interfaces on egress)

• Performance Monitor 2: to monitor bandwidth on egress (applied on external interfaces on egress)

• Performance Monitor 3: to monitor performance on ingress (applied on external interfaces on ingress)

1. Issue MC and Border specific verification commands:

• Reset Terminal and Clear Scrollback.

• Load script 007_PfRv3_Master_Configuration.

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 62 of 152
 Cisco dCloud

• Choose Select None and then Select only the Master Controller HQ-DC-MC ONLY.

2. Discuss the purpose of each verification command prior to sending the script and reviewing.

• sh domain 10 master status

• sh domain 10 master policy

• sh domain 10 master traffic-classes policy VOICE

• sh domain 10 master traffic-classes policy VIDEO

• sh domain 10 master traffic-classes policy WEBEX

• sh domain 10 master traffic-classes policy CRITICAL-APPLICATIONS

• sh domain 10 master traffic-classes policy BULK-DATA

• sh domain 10 master traffic-classes summary

Figure 120. Load 007 MTPuTTY script

3. Look at the overall status and policy of the master, followed by a look into the details of the traffic classes.

4. Send script 007. Once complete review the verification output on the HQ-DC-MC.

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 63 of 152
 Cisco dCloud

Figure 121. show domain 10 master status output (truncated)

5. From the output, notice that you are up and operational. You can also see that borders at the bottom are both up. Notice that
the PUBLIC and MPLS keywords were learned from the hub border routers.

Figure 122. show domain 10 master policy output (truncated)

6. Look at the specific details associated with the policy template selected for each class group.

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 64 of 152
 Cisco dCloud

Figure 123. show domain 10 master traffic-classes policy

7. See whether the traffic class is controlled and in policy based on performance status. You can see both previous and current
service providers, the bandwidth utilization and the reason for the last route change. Let us scroll to the bottom and look at the
summary.

Figure 124. show domain 10 master traffic-classes summary output

Here we can quickly see destination site prefixes along with DSCP values. You also see whether the traffic is currently controlled
and which provider/interface is being leveraged.

8. Looks like our PfRv3 configuration is working nicely. Move onto border router verification next.

• Reset Terminal and Clear Scrollback.

• Load script 008_PfRv3_Border_Configuration.

• Choose Select None and then Select all five Border Routers.

9. Discuss the purpose of each verification command prior to sending the script and reviewing.

• show domain 10 border status

• show domain 10 border site-prefix

• show domain 10 border traffic-classes

• show domain 10 border channels

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 65 of 152
 Cisco dCloud

Figure 125. Load 008 MTPuTTY script

10. You will look at the overall border status and site prefixes learned. You will follow that by taking a look into the details of the
traffic classes and finish up with a glance at the channels.

11. Send script 008. Once complete review the verification output on the border routers. Cover thoroughly on one router and then
only look at border status and site-prefixes output on the others.

HQ-DC-WAN1

1. Notice that the router Border status is up and that it has a connection with the MC. You also see the local tunnel interface as
well as the other Border reachable via dynamic tunnel 0.

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 66 of 152
 Cisco dCloud

Figure 126. show domain 10 border status output

Figure 127. show domain 10 border site-prefix output

2. This command show the site prefixes associated with the various site IDs.

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 67 of 152
 Cisco dCloud

Figure 128. show domain 10 border traffic-classes output (truncated)

3. This is similar to the command that was viewed on the master. You can see the present state, primary interface and backup
interface for various traffic classes. You also see the associated channel-ids for primary and backup connections. Let us look
at those channels next.

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 68 of 152
 Cisco dCloud

Figure 129. show domain 10 border channels output

4. Notice the channel send/receive probes and packet details from this configuration output.

Figure 130. show domain 10 master traffic-classes summary output

5. Launch a WebEx on PC11, come back to HQ-DC-MC, and hit our up arrow key to see the traffic-classes summary again.

NOTE: There RDP connection shortcuts on the desktop of our jumpbox PC01.

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 69 of 152
 Cisco dCloud

Figure 131. RDP to PC11

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 70 of 152
 Cisco dCloud

Launch a WebEx meeting.

Figure 132. WebEx

Figure 133. show domain 10 master traffic-classes summary output

1. The Master Controller might take some time to learn the application and the health of the network prior to leveraging the
preferred path. As you can see PfR learns the application and things are working as expected as long as the SLAs have been
met.

Figure 134. show domain 10 master traffic-classes | sec webex output

2. Close out the WebEx session that is running on PC11.

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 71 of 152
 Cisco dCloud

Lab 5: Optimizing Application Performance

• Reset Terminal and Clear Scrollback.

• Load script 010_FNF_Configuration.

• Select router BR2-WAN1. You are reviewing this configuration to highlight that both Prime Infrastructure and LiveAction
can push out the configuration if required.

• Send 010_FNF_Configuration script.

Figure 135. Load 010 MTPuTTY script

Figure 136. Show run | sec flow

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 72 of 152
 Cisco dCloud

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 73 of 152
 Cisco dCloud

As can be seen from this output we can configure multiple flow exporters on the router with each pointing to a different destination
and utilizing a different relevant port number. The flow record is standard and leverages collect application name for integration
with NBAR2. The flow monitor ties the record and exporter together and gets applied in both ingress and egress directions on
relevant interfaces. Both Cisco Prime Infrastructure and LiveAction can be used to push out this template configuration which is the
same on all devices.

As part of this review point we are going to look at how we can leverage Easy Performance Monitoring (EZPM) to provide
additional application visibility. The Performance Monitoring style configuration greatly simplifies the entire previous separate
configuration that was at one time required to gain visibility into applications and application health. You will look at this method of
configuration from our Prime Infrastructure management console as part of the next review point. As part of this review we will
login to Prime Infrastructure to see the results of configuring for enhanced visibility into our application environment. Enabling FNF
with NBAR2 is not required for PfRv3 to do its job. Again, Unified Monitors (Performance Monitors) are automatically configured
and activated in the background by PfRv3 for the Intelligent Path Selection functionality. There is no need for manual configuration
to make this work. Performance Monitor definitions are pre-defined on the Hub MC and distributed to branch BRs using the domain
infrastructure. You are configuring an explicit instance of Unified Monitoring for enhanced visibility within tools such as Prime
Infrastructure.

NOTE: Certain monitoring and reporting applications might not be able to leverage EZPM and we may still need to configure FNF
with NBAR2 integration. Traditional NetFlow (also called Classic NetFlow) and NetFlow version 5 are not suitable for AVC
solutions because they can report only L3 and L4 information. When possible, it is highly recommended to migrate to Flexible

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 74 of 152
 Cisco dCloud

NetFlow with NBAR as outlined in the CVD guide ‘ Application Monitoring Using NetFlow’:
http://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Dec2013/CVD-ApplicationMonitoringUsingNetFlowDesignGuide-
DEC13.pdf

In the past, typical network traffic could easily be identified using well known port numbers. Today, many applications are carried
on the network as HTTP and HTTPS, so identifying applications by their well-known port number is no longer sufficient. Cloud
applications and services such as WebEx, SalesForce.com, and Microsoft Office 365 are delivered over HTTP and HTTPS using
the same ports as other web-based traffic such as Netflix, Hulu, Pandora, and iTunes. In addition, many applications such as
voice, video, and Microsoft Exchange use dynamic ports and therefore are not uniquely identifiable by their port numbers alone.
Network administrators need enhanced visibility into different types of traffic that use well-known and dynamic port numbers.
Network Based Application Recognition (NBAR) is an intelligent classification engine in Cisco IOS Software that can recognize a
wide variety of applications, including web-based and client/server applications. NBAR uses deep packet inspection to look within
the transport layer payload in order to determine the associated application.

NBAR2 is the next-generation architectural evolution of NBAR. NBAR2 or Next Generation NBAR is part of the Cisco AVC
solution, which enables greater classification and visibility of network traffic flows. NBAR2 is a stateful, deep packet inspection
technology based on the Cisco Service Control Engine (SCE) with advanced classification techniques, greater accuracy, and many
more application signatures supporting over 1000 applications and sub-classifications. NBAR2 includes Cisco’s cross platform
deep packet inspection (DPI) and field extraction technology and is currently supported on Cisco ASR 1000 and ISR G2 as well as
ISR4K platforms. The heuristic analysis engine allows NBAR2 to identify applications regardless of their ports and can identify
applications such as Skype, Youtube, and BitTorrent. Support for NBAR2 protocol packs (PP) provides the ability to update and
add application signatures while the routers are service independent of full Cisco IOS Software updates. New protocol packs with
new application signatures are typically released every month. Application categorization uses NBAR2 attributes to group similar
applications in order to simplify application management for both classification and reporting.

FNF integrates seamlessly with NBAR and is enabled to gather data by using “application name” as a key field within a FNF flow
record (Note: Point this it in the Flow Record output). The application identification provided by NBAR is more effective than using
the TCP/UDP well-known-port mapping. If leveraging FNF w/ NBAR2 you would leverage the following steps:

Figure 137. FNF with NBAR2

Procedure 1 Create flexible NetFlow flow record

Flexible NetFlow (FNF) requires the explicit configuration of a flow record that consists of both key fields and non-key fields. This
procedure provides guidance on how to configure a user-defined flow record that includes all of the TNF fields (key and non-key)
as well as additional FNF fields (key and non-key). The resulting flow record includes the full subset of TNF fields used in classic
NetFlow deployments.

Procedure 2 Create flow exporter

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 75 of 152
 Cisco dCloud

The NetFlow data that is stored in the cache of the network device can be more effectively analyzed when exported to an external
collector. Creating a flow exporter is only required when exporting data to an external collector. This procedure may be skipped if
data is analyzed only on the network device.

Most external collectors use Simple Network Management Protocol (SNMP) to retrieve the interface table from the network device.
Ensure that you have completed the relevant SNMP procedures for your platform.

NOTE: Different NetFlow collector applications support different export version formats (v5, v9 IPFIX) and expect to receive the
exported data on a particular UDP or TCP port (ports 2055, 9991, 9995, 9996 are popular). The NetFlow RFC 3954 does not
specify a specific port for collectors to receive Netflow data.

Figure 138. NBAR Exporters

Procedure 3 Create a flow monitor

The network device must be configured to monitor the flows through the device on a per-interface basis. The flow monitor must
include a flow record and optionally one or more flow exporters if data is to be collected and analyzed. After the flow monitor is
created, it is applied to device interfaces. The flow monitor stores flow information in a cache, and the timer values for this cache
are modified within the flow monitor configuration. It is recommended that you set the timeout active timer to 60 seconds, which
exports flow data on existing long-lived flows.

Procedure 4 Apply flow monitor to WAN and LAN

A best practice for NetFlow is to monitor all inbound and outbound traffic to the network device. This method covers all traffic
regardless of encryption or application optimization.

NOTE: Be sure to apply the flow monitor to all device interfaces, including port-channel, tunnel, and sub-interfaces.

Go back to your RDP session for PC11 in branch 1.

Once you have logged in launch Google Chrome and perform a search for Cisco IWAN YouTube and click on any of the links to
play a video.

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 76 of 152
 Cisco dCloud

Figure 139. Launch Chrome and go to YouTube

Now that this is playing go back to PC01 terminal window for HQ-DC-MC and either up arrow key or type in show domain 10
master traffic-classes summary.

Now go back to PC01 and launch Cisco Prime Infrastructure by double clicking the Firefox shortcut on the desktop. Leveraging
Firefox for Prime will ensure a consistent experience and will prevent you from running into issues. If you forget and naturally go
back to Chrome and to the second tab you will see a reminder to use Firefox for Cisco Prime Infrastructure. Please use Chrome for
everything else.

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 77 of 152
 Cisco dCloud

Figure 140. Access PI GUI

You will need to click on I Understand the Risks.

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 78 of 152
 Cisco dCloud

Figure 141. Add Exception and Confirm Security Exception

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 79 of 152
 Cisco dCloud

Figure 142. Log into PI

Log into Prime Infrastructure with the username/password of root/cpiCPI123

Go to Dashboard  General

Figure 143. Dashboard -> General GUI

th
Clicking on the Service Assurance option 6 from the left should provide additional visibility into the applications such as webex,
youtube, rtp and http that are running. It might take a while for Youtube to show up.

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 80 of 152
 Cisco dCloud

Figure 144. Service Assurance GUI

You can click on the specific application to get more details:

Figure 145. Details of specific application

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 81 of 152
 Cisco dCloud

Figure 146. Performance view.

You might also want to look at the Service Health tab located under the Overview tab header.

Figure 147. Service Health GUI

Clicking on healthy/problem applications areas provide detail.

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 82 of 152
 Cisco dCloud

Figure 148. Drill into details

Close out with a quick review of AVC Readiness Assessment and NBAR protocol pack details under the services menu before
moving on to WAAS and Akamai.

Hover over Services menu and then click on Readiness Assessment to view device capabilities:

Figure 149. Device Capabilities GUI

This output provides us with visibility into whether AVC is supported and activated on the device. Let us also take a moment to
explore one click AVC and QoS activation.

Under the Services menu we see an option for Interface Configuration:

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 83 of 152
 Cisco dCloud

Figure 150. Interface Configuration GUI

Within this services section we can enable and disable AVC and QoS with a single click of a button. You will not go through this
now, but will take a closer look at this simplified deployment when we configure BR3 using the IWAN Wizard.

Let us move onto WAN Optimization and Application Acceleration.

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 84 of 152
 Cisco dCloud

Figure 151. Power Point Slide

For those who are not familiar with Cisco Wide Area Application Services (WAAS), it is a comprehensive, cost-effective, cloud-
ready WAN optimization solution, which accelerates applications (and is vendor validated), optimizes bandwidth, provides local
hosting of branch IT services, and enables cloud services, all with comprehensive network integration options.
®
Cisco Intelligent WAN (IWAN) with Akamai Connect is a fully integrated solution from Cisco and Akamai that provides the next
generation application and network optimization. It integrates the best-in-class advanced WAN optimization and intelligent caching
techniques directly into the Cisco Integrated Services Routers with Application Experience (ISR-AX) at the branch office. It
effectively extends the Akamai Intelligent Platform across the last mile from the Internet directly into the branch office with edge
caching, thus significantly offloading traffic from the WAN and providing an unparalleled user experience over bandwidth-
constrained networks. Akamai Connect turbo charges the application optimization features of IWAN, providing faster content
delivery regardless of device, connectivity, or cloud, including the corporate private cloud and the public Internet cloud, where most
business traffic traverses.

Cisco WAAS provides the following capabilities to improve application performance over the WAN:

1. Transport optimization - Cisco WAAS uses a variety of Transport Flow Optimization (TFO) features to optimize TCP
traffic intercepted by the WAAS devices

2. Compression – Cisco WAAS use Data Redundancy Elimination and persistent Lempel-Ziv (LZ) compression to minimize
the amount of bandwidth consumed by data transmitted over your WAN.

3. Application Acceleration – Cisco WAAS provides application specific acceleration capabilities to minimize the impact of
latency in key business applications.

4. HTTP(s) Object caching – Cisco WAAS has integrated Akamai caching functions into its software stack to provide
significant WAN offload in addition to the compression techniques above.

The result of all of the above improves the user experience and enables consolidation of costly distributed infrastructures. Cisco
WAAS is deployed on the Cisco Wide Area Virtualization Engine (WAVE) family of appliances, on a virtual instance on any ESXi
4.1 and later platform (vWAAS), or as part of ISR-AX which can be deployed virtually on Cisco UCS-E or natively on an ISR-4000
series router (ISR-WAAS). On ISRG2 routers we also support a native deployment option on a Service Ready Engine (SRE). A
WAAS deployment typically involves the following recommended elements:

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 85 of 152
 Cisco dCloud

• One Central Manager

• One or more Application Accelerators in each of the remote branch offices

• AppNav functionality to handle asymmetric flows and load sharing across multiple virtualization engine instances

• One or more Application Accelerators located at the data center

Although deploying WAAS on the ISR is the most commonly chosen deployment option by our customers, we are unable to
demonstrate that deployment within this topology. Our lab is built from virtual routers, switches and workstations and therefore we
are not in a position to display integrated engines given that we do not have real hardware. This will not impact us as we can
leverage all appliances integrated in the real world and since they all run the same software everything outside of the deployment
at branch 2 will look the same.

Bring up the topology diagram and have the attendees look at the printouts. It is very important for you to understand that this lab
environment has been setup to show the seamless integration of WAAS/Akamai as part of the overall IWAN solution. The setup is
not intended to showcase performance testing and impact associated with files be downloaded and speed of page loads. The
WAN links are set with high bandwidth and there is minimal delay in this lab environment to showcase performance benefits
outside of the reporting framework.

As yo can see our central manager is running in HQ/DC as a virtual instance. You have two virtual engines in this location, running
AppNav-XE capability on the edge routers in software. Again, AppNav allows us to address asymmetric flows and load sharing
across multiple virtualization engine instances. The edge routers form a cluster for optimal integration of application optimization
into the IWAN design. You then have a virtual appliance out at Branch 2 to optimize traffic going from the site to HQ/DC and out
through the directly attached Internet. Cisco WAAS supports transparent interception and redirection using AppNav, WCCP, vPath,
or PBR. This is great for introducing optimization capabilities without having disrupted services by putting appliances in line.
AppNav is the preferred deployment option on ISR 4Ks, ASRs and CSRs, but since we don’t have real hardware we are using
WCCP redirection at branch 2.

You will start by looking at the Central Manager, which is the third automatically loaded tab from the left in your Chrome browser on
PC01.

Figure 152. Access WAAS-CM

Click advanced and Proceed to was-cm.dcloud.cisco.com (unsafe)

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 86 of 152
 Cisco dCloud

Log in with the username/password of admin/C1sco12345

Figure 153. Log into WAAS-CM

Once you have logged in navigate to the AppNav Clusters menu option and click on HQ-DC.

Figure 154. AppNav Clusters GUI

As can see your Hub Border edge routers are part of a cluster and have full connectivity to both appliances. You have a lot of
flexibility in how you configure the appliances and can dedicate them for specific functions if you choose to do so as we have done
here. This is obviously not a requirement and we just want to demonstrate that it is possible.

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 87 of 152
 Cisco dCloud

Figure 155. AppNav Cluster Layout

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 88 of 152
 Cisco dCloud

Let us navigate to the Devices menu next and click on All Devices.

Figure 156. All Devices

As you can see, all devices are operational and healthy. You can also see that Akamai connect has been enabled for our
optimization engine in Branch 2.

Figure 157. View Devices’ Health

Enabling Akamai integration was simply done with a click of a button. Let us look at that next. Click on the icon next to br2-waas.

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 89 of 152
 Cisco dCloud

Figure 158. Edit br2-waas device

Next navigate to Configure and select Akamai Connect

Figure 159. Navigate to Akamai Connect

Checking the box next to Enable Akamai Connect is all you have to do.

Figure 160. Enable Akamai Connect

Let us look at some of the dashboards and reports next to see how we the optimization solution is performing in our environment.

As a reminder, this lab environment has been setup to show the seamless integration of WAAS/Akamai as part of the overall IWAN
solution. The setup is not intended to showcase performance testing and impact associated with files be downloaded and speed of

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 90 of 152
 Cisco dCloud

page loads. The WAN links are set with high bandwidth and there is minimal delay in this lab environment to effectively showcase
performance benefits outside of the reporting framework.

Navigate to the Devices menu, expand br2-waas and click on Dashboard.

Figure 161. View br2-waas Dashboard

NOTE: Cisco WAAS Central Manager Device Dashboard can be used to display a series of reports. There are toggles on many
of these reports that you can explore. Below are some of sample reports that can be generated from Cisco WAAS CM. You will
want to choose which reports to run through given session time constraints. Perhaps a brief overview of each report displayed will
suffice.

Traffic Analysis:

1. Traffic Summary over period of time

a. This report displays the top nine applications with

the highest percent of traffic. Each section in the chart represents
an application as a percent of the total traffic on your network or
device.

b. Non-classified, non-monitored, and applications with

less than 2 percent of the total traffic are grouped together
into the Other category.

2. Original / Optimized Traffic Over Time

a. The Original Traffic over Time chart displays a graph of the amount
of original and pass-through traffic.

3. Throughput Summary

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 91 of 152
 Cisco dCloud

a. The Throughput Summary displays immediate throughput of the

traffic on the WAAS device. These graphs are good charts to
show the difference between WAN and LAN bandwidth usage
after optimization.

b. There is link to toggle between LAN to WAN (upload) direction,

and WAN to LAN (download) direction. Each chart shows the
original throughput (before WAAS optimization), as contrasted to
the optimized throughput (after WAAS optimization).

Optimization Charts:

This section describes these charts:

1. Compression Summary

a. The Compression Summary chart displays a bar chart of

the percentage of traffic reduction (excluding pass-
through traffic) for the top ten applications by either the
highest percentage of traffic reduction, by traffic
volume, or the bottom 10 applications by traffic reduction

2. Traffic Volume and Reduction

a. The Traffic Volume and Reduction chart compares

the amount of original and optimized traffic in a bar chart
and displays the percentage of traffic reduction as a line.
Pass-through traffic is excluded. The traffic units
(bytes, KB, MB, or GB) at the right side depend upon the
range. The percentage of traffic reduction is shown at
the left side of the chart. You can customize the chart
by choosing specific applications to include; the default is
all traffic.

b. Formula: % Reduction excluding pass-through = (Original excluding pass-through -

Optimized) / (Original excluding pass-through)

3. Compression Summary Over Time

a. The Compression Summary Over Time chart displays a

graph of the percentage of total traffic that was reduced
by using the WAAS optimization techniques. This chart
excludes pass-through traffic in the results. You can
customize the chart by choosing specific
applications to include; the default is all traffic.

b. Formula: % Reduction = (Original Excluding Pass-

Through - Optimized) / (Original Excluding Pass-Through)

4. Traffic Summary Over Time

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 92 of 152
 Cisco dCloud

a. The Traffic Summary Over Time chart displays a graph of the amount of original or optimized traffic, depending on
the selected tab, and you can include pass-through traffic by checking the Pass-Through check box. You can
customize the chart by choosing specific applications to include; the default is all traffic.

5. Effective WAN Capacity

a. The Effective WAN Capacity chart displays the effective

increased bandwidth capacity of the WAN link as a
result of WAAS optimization, as a value between
1X (times) and 100X.

b. You can choose which applications to include; the

default is all traffic.

c. Formula: Effective WAN Capacity = 1 / (1-% Reduction Excluding Pass-Through)

One of the nice features here is that you can change the timeframe from the last hour to the last day, week, month or to a custom
duration. You can also choose to download reports in either Excel or PDF formats to share with others. Let us do it now. Click on
the PDF icon in the toolbar.

This will open the file in a separate tab. Do the same for Excel. This will download a Statistics.zip file to the download folder.

For Akamai Connect Caching results we can navigate to Monitor and click on Akamai Connect.

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 93 of 152
 Cisco dCloud

Here will find additional reports to see the impact that Akamai connect is having. You can also download the PDF like we did for
the previous report to check it out.

NOTE: Encourage follow up one-on-one design session workshops if this overview is part of a demand generation event.

You have obviously not covered many aspects of this solution given time constraints. You would love to come out to your site to
show you how leveraging application optimization capabilities as part of the IWAN solution will create an improved and consistent
experience for your remote site workers.

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 94 of 152
 Cisco dCloud

Lab 6: Security and Distributed Internet

• Reset Terminal and Clear Scrollback.

• Load script 011_Perimeter_ACL. Select BR1-WAN1.

Discuss the purpose of each verification command prior to sending the script and reviewing.

show ip access-list ACL-INET-PUBLIC

show run interface e0/0 | include interface|access

Figure 162. Load 011 MTPuTTY script

Whenever we have public facing interfaces touching the Internet, security is obviously a big concern. Depending on whether or not
there are plans for direct Internet access we can choose between deploying Access-Lists (ACLs) or move forward with a full blown
firewall configuration to protect our edge. You are going to start by looking at BR1-WAN1 as we are not allowing direct Internet

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 95 of 152
 Cisco dCloud

access from this remote site. Under these circumstances we have addressed security concerns by leveraging an ACL in the
inbound direction under our G0/0 interface. Let us look at the access-list and its application under the interface now.

• Send script 011. Once complete review the verification output on BR2-WAN1.

BR2-WAN1

Figure 163. Verification Output

The first three lines of configuration are to accommodate encryption. Line 40 permit udp any nay eq bootpc has no application in
our lab, but would be required if receiving DHCP addressing from the provider. The next four lines are to optionally allow ICMP
traffic. Line 90 is also optional and configured to allow traceroute. Line 100 closes out the ACL with an explicit vs. implicit deny ip
any. This has been configured in the lab for troubleshooting purposes and is obviously not required. As you can see the ACL is
applied to the interface using the ip access-group ACL-INET-PUBLIC in command. Rather than using a simple ACL it might be
beneficial to configure a Zone Based Policy Firewall configuration to protect traffic going from the router and coming to the router.
This ensures a consistent configuration across all sites and allows us to simply add Direct Internet Attach capability if it becomes
important in the future.

Let us jump over to Branch 2, BR2-WAN1, and look. Branch 2 has been configured to allow for direct Internet Access for the
internal and Guest Networks. You will focus our attention on the Guest Network VLAN and traffic coming from host PC22 first.
Under these circumstances the Cisco Stateful IOS Zone Based Policy Firewall (ZFW) replaces the static ACL configured on the outside public
interface of this router. The e0/3 internal facing interface is mapped to the same VRF as the outside interface to ensure they share the same
routing table. Each of these two interfaces has then been assigned as a Zone member of a unique Zone. You have configured INSIDE-GUEST
and OUTSIDE as our two Zones. Other interfaces including e0/2, e0/4, Tunnel 100, Tunnel 200 are all configured to be part of zone INSIDE. All
interfaces that belong to the same zone pass traffic without the need for rules or permissions. All interfaces not assigned to a Zone belong to
the default Zone. For our configuration Segments belonging to the same Zone, default or otherwise will allow us to pass traffic between
segments without any issues. Zone to zone traffic such as INSIDE-GUEST to OUTSIDE, OUTSIDE to INSIDE-GUEST, INSIDE to OUTSIDE and
OUTSIDE to INSIDE must be explicitly permitted leveraging a class-map inspect and policy-map inspect configuration framework very similar to
what we are used to with Modular QoS configuration. Notice the keywords type inspect. Let us look at this configuration next.

• Reset Terminal and Clear Scrollback.

• Load script 012_Zone_Based_Policy_Firewall.

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 96 of 152
 Cisco dCloud

• Unselect BR1-WAN1 and select BR2-WAN1.

Discuss the purpose of each verification command prior to sending the script and reviewing.

• sh run | sec zone sec

• sh run | sec class-map type inspect match-any INSIDE-GUEST_TO_OUTSIDE_CMAP

• sh run | sec policy-map type inspect INSIDE-GUEST_TO_OUTSIDE_PMAP

• sh run | sec zone-pair security INSIDE-GUEST_TO_OUTSIDE source INSIDE-GUEST destination OUTSIDE

• sh run int e0/0 | in interface|zone

• sh run int e0/3 | in interface|zone

Figure 164. Load 012 MTPuTTY script

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 97 of 152
 Cisco dCloud

You will start by looking at how the Zones are defined and then we will examine the class-map policy-map configuration
framework. Rather than applying a service policy to an interface like we do with QoS, we apply a service policy to a Zone-Pair, so
we will look at that next. Last we will look at how the configuration is activated by applying the zones to the interfaces.

• Send script 012. Once complete review the verification output on BR2-WAN1.

BR2-WAN1

Figure 165. show run | sec zone sec output

Outside of configuring the zone by issuing zone security followed by a unique name, there isn’t much more we need to do as part
of this step.

Figure 166. show run | sec class-map type inspect match-any INSIDE-GUEST output

The only difference between this class-map configuration and the one that we use for QoS are the keywords ‘type inspect’ which
mean that this class-map is to be used with Zone Based Policy Firewall. You can see that we have used match-any vs. match all
and have decided to match on protocols http, https, DNS and ICMP. You have allowed ICMP, but you can be very specific with this
configuration matching on applications or even ACLs to limit what is accessible.

Figure 167. show run | sec policy-map type inspect INSIDE-GUEST output

Again, the only difference between this policy-map configuration and the one that we use for QoS are the keywords ‘type inspect’
which mean that this policy-map is to be used with Zone Based Policy Firewall. After calling on the class-map under the policy-map
we can define the action that we want to take. You can Drop, Pass or Inspect. The difference between Pass and Inspect is
whether we maintain state information for the traffic flows to accommodate return traffic. You have allowed RDP traffic in from the
outside to host PC22 as part of an Outside to Inside classification given that it is completely isolated from our internal network. You
will look at that configuration in just a bit. All other traffic coming from the OUTSIDE will not be allowed to come in unless there is
state information and therefore leverage inspect within this policy going from INSIDE-GUEST to OUTSIDE. Typically you will want
to inspect traffic going between zones. Notice that under the default class class-default we explicitly drop all traffic that does not
match. Dropping traffic for class class-default is the default behavior.

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 98 of 152
 Cisco dCloud

Figure 168. show run | sec zone-pair security INSIDE-GUEST output

A zone pair represents two defined zones and identifies the source and destination zones where a unidirectional firewall policy-
map is applied. This configuration uses zone-pair INSIDE-GUEST and this is where our policy-map is applied. Without defining a
class-map, policy-map and zone-pair for OUTSIDE source to INSIDE-GUEST destination, we are only allowing established traffic
originating from INSIDE-GUEST to OUTSIDE to return back through from the OUTSIDE to the INSIDE-GUEST zone segment.

Although we have the classification and policy configured and ready to be applied leveraging our zone-pair, we have yet to assign
interfaces to zones to complete the configuration.

Figure 169. show run int g0/0/X | in interface|zone output

The last step is to enable the firewall by applying the configuration to the interface using the zone-member security zone name
command.

It is important to note that the router itself is defined by Cisco IOS Software using the fixed name self as a separate security Zone.

The Self Zone is the exception to the default deny-all policy. All traffic destined to or originating from the router itself (local traffic)
on any interface is allowed until traffic is explicitly denied using Zone Based Policy firewall rules. In other words, any traffic flowing
directly between defined zones and the router’s IP interface addresses is implicitly allowed and is not initially controlled by zone
firewall policies.

This default behavior of the Self Zone ensures that connectivity to the router’s management interfaces and the function of routing
protocols is maintained when an initial Zone Firewall configuration is applied to the router. Specific rules that control traffic to the
Self Zone are required. When we configure a Zone Based Policy Firewall rule that includes the self zone, traffic between the self
zone and the other defined zones is immediately restricted in both directions. You have this configured since the previous ACL
protection on the external facing interface is no longer valid or relevant. Let us look.

• Reset Terminal and Clear Scrollback.

• Load script 013_ZFW_Self_Zone_In. Select BR2-WAN1.

Discuss the purpose of each verification command prior to sending the script and reviewing.

• sh ip access-list | sec RTR-IN

• sh ip access-list | sec DHCP-IN

• sh ip access-list | sec ESP-IN

• sh run | sec class-map type inspect match-any PASS-ACL-IN-CLASS

• sh run | sec class-map type inspect match-any INSPECT-ACL-IN-CLASS

• sh run | sec policy-map type inspect ACL-IN-POLICY

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 99 of 152
 Cisco dCloud

• sh run | sec zone-pair security TO-ROUTER

Figure 170. Load 013 MTPuTTY script

You will start by taking a look at the ACLs leveraged to classify INSPECT and PASS traffic. You will then see how these are
applied to the class-maps that are then configured under the policy-map ACL-IN-POLICY. Last we will look at the zone-pair
specific to traffic coming in from the OUTSIDE to the external interface Self Zone.

• Send script 013. Once complete review the verification output on BR2-WAN1.

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 100 of 152
 Cisco dCloud

BR2-WAN1

Figure 171. show ip access-list output | sec -IN output

You can quickly see from the output that we have three ACLs configured:

• ACL-RTR-IN

• DHCP-IN

• ESP-IN

DHCP and ESP have intentionally been broken out as they cannot be inspected and must be passed. Let us look at the class-map
configuration next followed by the policy-map configuration for a clearer look.

Figure 172. show run | sec class-map type inspect match-any PASS-ACL-IN output

Figure 173. show run | sec class-map type inspect match-any INSPECT-ACL-IN output

There is nothing new to discuss with this portion of the configuration. You are simply mapping the ACLs to the class-maps for
policy-map assignment.

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 101 of 152
 Cisco dCloud

Figure 174. show run | sec policy-map type inspect ACL-IN-POLICY output

You inspect the traffic classified in our inspect ACL tied to this first class-map and pass ESP and DHCP traffic as part of the
second class-map as it cannot be inspected and needs to be configured with a “pass” action in the policy, using separate ACL and
class-maps. You have configured log in addition to drop under the default class. You will want to avoid doing this in production.

Figure 175. show run | sec zone-pair security TO-ROUTER output

You need a Zone-Pair to bring this firewall policy to life.

Next we will look at our policy configuration From Self Zone to Outside.

• Reset Terminal and Clear Scrollback.

• Load script 014_ZFW_Self_Zone_Out.

• Select BR2-WAN1.

Discuss the purpose of each verification command prior to sending the script and reviewing.

• show ip access-list | sec -OUT

• show run | sec class-map type inspect match-any PASS-ACL-OUT-CLASS

• show run | sec class-map type inspect match-any INSPECT-ACL-OUT-CLASS

• show run | sec policy-map type inspect ACL-OUT-POLICY

• show run | sec zone-pair security FROM-ROUTER

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 102 of 152
 Cisco dCloud

Figure 176. Load 014 MTPuTTY script

You will start by taking a look at the ACLs leveraged to classify INSPECT and PASS traffic. You will then see how these are
applied to the class-maps that are then configured under the policy-map ACL-OUT-POLICY. Last we will look at the zone-pair
specific to traffic going from the routers Self-Zone to the OUTSIDE Zone.

• Send script 014. Once complete review the verification output on BR2-WAN1.

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 103 of 152
 Cisco dCloud

BR2-WAN1

Figure 177. show ip access-list output | sec -OUT output

You can quickly see from the output that we have three ACLs configured:

• ACL-RTR-OUT

• DHCP-OUT

• ESP-OUT

DHCP and ESP have intentionally been broken out as they cannot be inspected and must be passed. ISAKMP should be
configured with the “inspect” action and thus needs to be broken out with a separate ACL and class-maps for inbound and
outbound policies. Port TCP 8080 is being leveraged for communications to Cisco Youb Security (CWS). This Access-list entry
(ACE) could be locked down further and has been left loose given that this is a lab environment. Let us look at the class-map
configuration next followed by the policy-map configuration for a more detailed look.

Figure 178. show run | sec class-map type inspect match-any PASS-ACL-OUT output

Figure 179. show run | sec class-map type inspect match-any INSPECT-ACL-OUT output

There is nothing new to discuss with this portion of the configuration. You are simply mapping the ACLs to the class-maps for
policy-map assignment.

Figure 180. show run | sec policy-map type inspect ACL-OUT-POLICY output

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 104 of 152
 Cisco dCloud

You inspect the traffic classified in our inspect ACL tied to this first class-map and pass ESP and DHCP traffic as part of the
second class-map as it cannot be inspected and needs to be configured with a “pass” action in the policy, using separate ACL and
class-maps.

Figure 181. show run | sec zone-pair security FROM-ROUTER output

You need a Zone-Pair to bring this firewall policy to life.

With the firewall configuration in place we are now protected and ready to allow guest users Internet access. The only challenge
that remains is that we are using non-routable 198.19.2.128/25 addressing internally and therefore need to use NAT to overload to
the outside E0/0 interface IP address.

• Reset Terminal and Clear Scrollback.

• Load script 015_NAT_Configuration.

• Select BR2-WAN1.

Discuss the purpose of each verification command prior to sending the script and reviewing.

show run | sec GUEST-NAT

show run interface e0/3 | in interface|nat

sh run int e0/0 | in interface|address|vrf|nat

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 105 of 152
 Cisco dCloud

Figure 182. Load 015 MTPuTTY script

You will start by looking at the global NAT configuration and then will look under the interfaces to see how interfaces are enabled
to take part in NAT.

• Send script 015. Once complete review the verification output on BR2-WAN1.

BR2-WAN1

Figure 183. show run | sec GUEST-NAT output

You can see that we are using traditional NAT and have configured an Inside to Outside translation. Notice that we are referencing
a source list GUEST-NAT which is the classification ACL matching 198.19.2.128/25. At the end of the NAT statement prior to
specifying the overload command, we specify that this configuration is tied to the VRF ISP1.

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 106 of 152
 Cisco dCloud

Figure 184. show run interface X/X | in interface|nat|other output

The last step is to specify the ip nat inside and ip nat outside statements under the interfaces.

Our next step is to perform verification. Leverage the RDP shortcut on jumpbox PC01 to connect to PC22 in BR2 by double
clicking on it. Access to this PC is actually going out of our simulated Internet in HQ-DC and to a NAT translation for RDP on the
BR2-WAN1 Router as this host is completed isolated from the rest of our network for security purposes.

Figure 185. RDP to PC22

Open up a browser and perform some Google searches. You can also navigate to your favorite site or join the WebEx that you
started on PC011 in Branch 1.

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 107 of 152
 Cisco dCloud

Figure 186. Launch Google searches

Time to jump back to PC01 and the BR2-WAN1 terminal window.

• Reset Terminal and Clear Scrollback.

• Load script 016_NAT_ZFW_Verification.

• Select BR2-WAN1.

Discuss the purpose of each verification command prior to sending the script and reviewing.

• show ip nat translations vrf ISP1

• show policy-map type inspect zone-pair INSIDE-GUEST_TO_OUTSIDE sessions

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 108 of 152
 Cisco dCloud

Figure 187. Load 016 MTPuTTY script

You will start by looking at the NAT translations and specifically those for VRF ISP1. Next we will issue the show policy-map type
inspect zone-pair sessions command to see what sessions are in the works.

• Send script 016. Once complete review the verification output on BR2-WAN1.

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 109 of 152
 Cisco dCloud

BR2-WAN1

Figure 188. show ip nat translations vrf ISP1 output

You can see that we are effectively PATing to outside interface from host 198.19.2.222.

Figure 189. show policy-map type inspect zone-pair sessions output (Truncated)

You can see from the output that we are hitting the classes and currently have sessions open and established.

Let us review the Direct Internet Attach configuration for the internal network use case next.

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 110 of 152
 Cisco dCloud

You saw Cisco Cloud Youb Security working already as we performed Google searches on Guest PC22, but Let us look at this a
little more closely by navigating to some blocked sites. You will also review the configuration that made this solution integration
possible.

Open up a new tab in Chrome on Guest PC22 and do a search for gambling usa

Figure 190. Search Ahead

As you can see, sites on the history of gambling or gambling law are permitted while gambling sites are blocked. Click on one of

the links with a next to it to view the error that you get.

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 111 of 152
 Cisco dCloud

Figure 191. Blocked site by CWS

As you can see, access has been denied.

• Reset Terminal and Clear Scrollback.

• Load script 017_CWS_Configuration.

• Select BR2-WAN1.

Discuss the purpose of each verification command prior to sending the script and reviewing.

sh run | sec cws global

sh run interface e0/0 | in interface|cws

sh cws session active

sh cws session history 10

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 112 of 152
 Cisco dCloud

Figure 192. Load 017 MTPuTTY script

Now that we have seen content security capabilities in action, Let us look at the configuration on the router. You will start by
looking at the global configuration followed by how we apply it to the external interface. You will then run a few verification
commands.

• Send script 017. Once complete review the verification output on BR2-WAN1.

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 113 of 152
 Cisco dCloud

BR2-WAN1

Figure 193. show run | sec zone sec output

As you can see we have already created the ‘INSIDE’ zone. You have put a note in the description of the zone to ensure that we
don’t forget to add the security zone to the tunnels.

Figure 194. show run | sec class-map type inspect match-any INSIDE_TO_OUTSIDE_CMAP

You have classified the majority of the traffic out there with this class-map.

Figure 195. show run | sec policy-map type inspect INSIDE_TO_OUTSIDE_PMAP

Next we added the class-map to the policy-map and turned on inspection.

Figure 196. Show run | sec zone-pair security INSIDE_TO_OUTSIDE source INSIDE destination OUTSIDE

Last to final step in the firewall configuration prior to assigning the zone configuration to the interfaces was to create the zone-pair
which is where we apply the policy.

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 114 of 152
 Cisco dCloud

Figure 197. Show run int e0/2 | in interface|zone

The last step was to apply the configuration under the interface using the zone-member security command.

Even the firewall is in place for the internal users, we are not using it. The default route is being learned via EIGRP and points back
out of the tunnel interface. Even after we add that static route pointing out of the interface and to the next hop PE address, we still
will not be able to translate the internal addressing to external addressing without configuring NAT. Also, remember, we need to
leverage PBR to get the return traffic back in from the VRF table into the global table.

Let us look at some command line output.

• Reset Terminal and Clear Scrollback.

• Load script 019_Internal_NAT_Configuration.

• Select BR2-WAN1.

Discuss the purpose of each verification command prior to sending the script and reviewing.

• sh ip access-list VLAN-INT

• sh run | sec ip nat

• sh ip access-list INET-VLAN-INTVRF-RETURN-FROM-NAT

• sh run | sec route-map INET-VLANS-VRF-RETURN-FROM-NAT

• sh run int e0/0 | in int|policy

Load 019 MTPuTTY script

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 115 of 152
 Cisco dCloud

You will look at the access-list leveraged to classify internal traffic for NAT and then at our ip nat statement that is overloading to
the e0/0 interface. You will then look at the access-list being leveraged as part of the PBR route-map to look at the originating
source IP information to that will be set to return to the global routing table.

• Send script 019. Once complete review the verification output on BR2-WAN1.

BR2-WAN1

Figure 198. show ip access-list VLAN-INT output

As you can see we are matching on the internal networks 198.19.2.0 and 198.20.2.0.

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 116 of 152
 Cisco dCloud

Figure 199. show run | sec ip nat output

You have added inside to outside NAT/PAT statement to overload to e0/0. It is important to note we have yet to include a default
route pointing out of this interface to the next hop IP, so this statement along with adding ip nat inside to e0/2 and e1/0 does
nothing at this time.

Figure 200. show run ip access-list (for PBR) and PBR configuration output

Once we do decide to add the ip route pointing out locally we will need to bring the traffic back from the VRF into the global table
after passing Zone Based Policy Firewall and NAT rules. Notice the set global command.

Figure 201. show run int e0/0 | int|policy output

Applying PBR is as simple using ip policy route-map to apply the route-map under the interface where the traffic ingresses.

• Reset Terminal and Clear Scrollback.

• Load script 020_Add_Internal_DIA_Default_Route_BR2.

• Select BR2-WAN1.

Discuss the purpose of each verification command prior to sending the script and reviewing.

• sh ip route

• config t

• ip route 0.0.0.0 0.0.0.0 Ethernet0/0 198.51.100.9 track 1

• sh ip route

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 117 of 152
 Cisco dCloud

Figure 202. Load 020 MTPuTTY script

Script 20 and 21 are used to add and remove the static route pointing out of the direct Internet attached interface. Let us add the
route now, test connectivity out and then remove the route once we are done.

• Send script 020. Once complete review the verification output on BR2-WAN1.

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 118 of 152
 Cisco dCloud

BR2-WAN1

Figure 203. show run | sec cws global and sh run interface e0/0 | in int|cws output

As you can see the configuration matches what we reviewed in the PowerPoint portion of this design clinic. You are leveraging the
group ‘iwan-lab’ to get our policy from the CWS portal.

Figure 204. show cws session active and show cws session history X output

It makes more sense to view the session information from the CWS portal, but at least you can see that it is working from the
router itself and CLI can be used to troubleshoot if absolutely necessary.
th
After launching Chrome on Guest PC22 the 4 tab from the left will be a CWS verification provided by navigating to
http://whoami.scansafe.net again we see that we are leveraging the ‘iwan-lab’ group to obtain our policy.

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 119 of 152
 Cisco dCloud

Figure 205. whoami.scansafe.net

th
Let us navigate to the CWS portal next by looking at the 5 and last tab from the left. The username and password information to
log into CWS with the username/password of [email protected] / %C1sco12345

Figure 206. Access and log into CWS towers

When we first login we will presented with three main areas of focus:

• Reports

• Dashboard

• Youb Policy

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 120 of 152
 Cisco dCloud

Figure 207. CWS main page

Click on the > after Reports and expand the IWAN Mega Lab folder. Click the download button to download and review each of
the reports briefly. These are some custom reports that filter the output to be specific to this demo’s instance. (Several dCloud
demos use the CWS account. The normal reports will return results encompassing all of these accounts. These custom reports will
focus on this demo’s traffic.)

Figure 208. IWAN Mega Lab reports

Next we will click on the Dashboard selection within the menu at the top to see All Blocks. You can also leverage the drop down
menu in the right hand corner to view Facebook Usage, Spyware Blocks, Youb Filter Blocks and Youb Virus Blocks.

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 121 of 152
 Cisco dCloud

Figure 209. View report

Let us click on the Youb Filtering option within the menu at the top next. From this output we see that group “iwan-lab” uses filter
“iwan2” for controlling content. Let us choose the filters selection under the Management sub-menu to see what has been
configured under this filter.

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 122 of 152
 Cisco dCloud

Click on iwan2 from the column on the left.

Here you can see that we are filtering the common stuff, but have many filtering options available.

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 123 of 152
 Cisco dCloud

Up until now we have been centralizing all Internet connectivity for our inside users and forcing them to come back to HQ-DC
through the gateway there. Let us review the Zone Based Policy Firewall configuration we have in place for preparation of the
Direct Internet Attach Internal User use case.

• Reset Terminal and Clear Scrollback.

• Load script 018_Internal_Zone_Based_Policy_Firewall.

• Select BR2-WAN1.

Discuss the purpose of each verification command prior to sending the script and reviewing.

• sh run | sec zone sec

• sh run | sec class-map type inspect match-any INSIDE_TO_OUTSIDE_CMAP

• sh run | sec policy-map type inspect INSIDE_TO_OUTSIDE_PMAP

• sh run | sec zone-pair security INSIDE_TO_OUTSIDE source INSIDE destination OUTSIDE

• sh run int e0/2 | in interface|zone

• sh run int e1/0 | in interface|zone

• sh run int tunnel100 | in interface|zone

• sh run int tunnel200 | in interface|zone

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 124 of 152
 Cisco dCloud

Figure 210. Load 018 MTPuTTY script

• Send script 018. Once complete review the verification output on BR2-WAN1.

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 125 of 152
 Cisco dCloud

BR2-WAN1

Figure 211. show ip route output

The original route points out of the tunnel.

Figure 212. ip route and show ip route output

You add the route that points out of the interface and to the next hop IP address of the PE. You have also leveraged a track
statement that is configured on this router and that tracks reachability so we can use the route through the tunnel in situations
where the interface might still be up, but reachability is down. Notice that the new route is now static.

Go to PC21, open DOS and do a tracert –d 198.51.100.9 to the next hop PE. Browse the net if you want.

Figure 213. tracert –d 198.51.100.9

Load and send script 021_Remove_Internal_DIA_Default_Route_BR2 to BR2-WAN1 and verify everything is back to normal.

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 126 of 152
 Cisco dCloud

Figure 214. Load and send 021 MTPuTTY script

Figure 215. Remove default route

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 127 of 152
 Cisco dCloud

NOTE: Encourage a follow up one-on-one design workshops if this overview is part of a demand generation event.

Again, we can’t cover everything today, but we would love to come in to show you how to leverage distributed Internet for your
workforce in addition to your guest users. There are many design points we can cover based on your needs. Keep in mind that we
are still working to get the cloud connector functionality on the ISR4K and availability is right around the corner. This has been a
journey and although we have been doing the CWS Cloud Connector on ISRG2s and ASAs for quite some time we are finalizing
QA testing on the ISR4K line. “

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 128 of 152
 Cisco dCloud

Lab 7: Simplified Management

The following figures provide an overview of Simplified Management. Use them to highlight some of the management capabilities
included within Prime Infrastructure, referring to the GUI if necessary.

1. Highlight the Dynamic Network Topology view and the IWAN wizard deployment of BR3 WAN edge to illustrate how the
repetitive nature of the configuration is used to simplify the deployment.

Figure 216. Cisco IWAN Management

Figure 217. Cisco IWAN Workflows

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 129 of 152
 Cisco dCloud

Figure 218. Cisco IWAN LiveAction

BR3-WAN1

1. Enter sh ip int br to confirm that the BR3-WAN1 configuration is leveraging the base configuration.

Figure 219. show ip int br

2. If you see Tunnel interfaces, reset and reload the base configuration by sending the script
_Reset_Branch3_To_Base_Configuration

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 130 of 152
 Cisco dCloud

Figure 220. Optional script to reset BR3

Figure 221. Reset the base configuration

3. Once the router is back up, navigate to the Network Device List in Prime Infrastructure. Check the box next to BR3-WAN1 and
click Sync.

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 131 of 152
 Cisco dCloud

Figure 222. Sync BR3-WAN1 in PI

4. Wait for the synchronization to complete.

Figure 223. Synchronization

5. Point out the Network Topology found under Maps. BR3 is not connected.

Figure 224. Network Topology in PI

6. Select Services > IWAN to open the IWAN configuration wizard.

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 132 of 152
 Cisco dCloud

Figure 225. Services > IWAN

7. Click Next at the bottom of the screen.

Figure 226. Deploy IWAN on BR3

8. Choose to deploy an IWAN Branch and Single Router and select the CUSTOM templates.

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 133 of 152
 Cisco dCloud

Figure 227. Select IWAN Branch, Single Router

NOTE: There are several options built in and more customized options that can be defined and available for selection based on
individual use cases. This lab allows you to deploy some or all of the IWAN building blocks. This example deploys all using custom
templates built using the repetitive configuration for each spoke.

9. Select BR3-WAN1 from the list. Click Next at the bottom of the screen.

Figure 228. Select BR3-WAN1

10. On the feature tab, enter unique information for BR3-WAN1. The tab includes default information, which can be adjusted
depending on the branch and bandwidth value.

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 134 of 152
 Cisco dCloud

Figure 229. Prepopulated Settings

11. Click Apply and then click on the CLI Preview Tab to review the choices.

Figure 230. CLI Preview

12. Click Next.

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 135 of 152
 Cisco dCloud

Figure 231. Config Interface IPs

13. The PfR configuration section displays. Select BR3-WAN1 from the list.

14. Select the Feature tab and enter the IP address of the loopback of the MC – 172.31.0.5 and the PfRv3 Authentication
password (CISCO).

15. Click Apply and select CLI Preview.

Figure 232. Config PfR

16. Click Next.

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 136 of 152
 Cisco dCloud

Figure 233. Config QoS and AVC

17. Select BR3-WAN1 from the list.

18. Select the Feature tab. Defaults values exist for the interface role (LAN/WAN) and the Bandwidth parameters for the Internet
and MPLS Links.

19. Click Apply and switch to CLI Preview.

Figure 234. CLI Preview

20. Click Next to move onto AVC.

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 137 of 152
 Cisco dCloud

Figure 235. Config AVC

21. AVC needs no configuration. Review the CLI Preview and click Next.

Figure 236. Review CLI

22. Review the selections and click Deploy.

NOTE: The configuration is applied in the terminal window of BR3-WAN1. Do not leave the IWAN Wizard page until the
deployment has completed.

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 138 of 152
 Cisco dCloud

Figure 237. Watch BR3-WAN1 console output

23. When deployment complete, navigate to your Network Device List in Prime Infrastructure and sync BR3-WAN1.

Figure 238. Sync BR3-WAN1

24. Wait for the synchronization to complete

Figure 239. Synchronization

25. When the sync is complete, navigate to the Network topology view under Maps.

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 139 of 152
 Cisco dCloud

Figure 240. View Maps

Let us change the layout to Hierarchical and Expand the view by clicking the + icon.

Figure 241. Change layout to Hierarchical

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 140 of 152
 Cisco dCloud

26. This should be a powerful demonstration of the ability of Prime Infrastructure to simplify the configuration and deployment.
Issue a few of the scripts on BR3-WAN1 (000, 001, 002, 003, 004, 005, etc.) for further illustration.

Figure 242. Load and Run 000, 001, 002, 003, 004, 005 scripts

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 141 of 152
 Cisco dCloud

LiveAction

1. RDP to PC11 in Branch 2, 198.19.2.11 by leveraging the RDP shortcut on PC01. If prompted, login as
administrator/C1sco12345.

2. The WAN Impairment application should be up and running. If it is not, double click the WAN Impairment Toggle icon on the
desktop of PC11. The window toggles the WAN impairment On/Off throughout this demonstration.

Figure 243. WAN Impairment GUI

NOTE: The WAN Impairment window might not properly load its first time started. If it shows up as just a grey screen or if the
countdown timer reads 0 seconds, close the script and re-launch it per the shortcut on the desktop. If possible, check the state of
the WAN Impairment Toggle window an hour prior to presenting this demonstration, as this application is what causes PfR to make
changes to the routing paths in the network.

By default, the WAN Impairment Toggle application is set to add and then remove packet loss impairment for DSCP ef and af41
traffic to the MPLS path through the network from Branch 1 to simulate a brownout condition. This creates periods of optimal and
suboptimal routing through the network for PfRv3 to manage and for LiveAction to report on. If you need to turn the impairment off,
bear in mind that it may take a few minutes for PfR to change the network’s pathing state. This is by design and leveraged to avoid
impact associated with flapping situations. You will simply need to make sure that the Cycle Toggling the Impairment is
unchecked and that the WAN Impairment State is Off to bring the MPLS network back to a healthy state.

3. Return to Jumpbox PC01 and double click the LiveAction icon on the desktop. This application takes a while to load. If
possible, login to it prior to presenting the workshop.

Figure 244. Launch LiveAction and log in

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 142 of 152
 Cisco dCloud

LiveAction is Cisco’s preferred management platform for IWAN end-to-end flow visualization. LiveAction supports PfRv3 and adds
PfR dashboard, workflows, and configuration function - in addition to PfR path change visualization. This functionality allows
businesses to take advantage of the improved path control in PfRv3, faster troubleshooting, and large-scale configuration and
change management functions.

4. After login, navigate to the flow tab located just below the high-level menu options and within the topology preview window.

Figure 245. Click Flow tab

5. Navigate to View > Fit to View.

Figure 246. Fit to View

Each large circle represents a networking device (e.g., router or switch).

Each smaller circle within the large circle represents an interface. The top half of the smaller circle is ingress and the bottom half is
egress.

NOTE: If no flows are present, or the nodes are grayed out, right click each node and select Refresh Device.

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 143 of 152
 Cisco dCloud

6. Right click on the circle and choose Zoom to Device to make it appear bigger. Use the +/- magnifier icon buttons to zoom
back out or back in.

Figure 247. Zoom to Device

7. Select to Fit to View again.

Figure 248. Fit to View

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 144 of 152
 Cisco dCloud

8. From the Flow tab, select the *DefaultFilterGroup option from the Filter dropdown menu. Click the Refresh icon available
as one of the Flow tab options to update the topology with flows.

Figure 249. Select DefaultFilterGroup and Refresh

9. The arrows between the devices represent traffic flows going through the network. Mouse over a merged flow for more
information about these conversations (source, destination, port number, bytes, etc.).

Figure 250. View flow details

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 145 of 152
 Cisco dCloud

10. Click on the Table icon next to the Refresh icon for a tabular list of all of the flows.

Figure 251. View Table view

11. Click on the All Flow Types dropdown to display the different flow filters available. Select All Flow Types.

Figure 252. Select All Flow Types

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 146 of 152
 Cisco dCloud

Real traffic flows display activity in the environment. You can create custom filters to target (or remove) certain traffic patterns from
the LiveAction topology display.

12. On the Filter dropdown menu, select the *PfR-Default-HideSmartProbes filter to remove any flows related to PfR’s smart
probes.

Figure 253. Select the PfR-Default-HideSmartProbes filter

13. With the traffic filter set, select the color pattern used to identify the different flows. Select DSCP from the Color Filter
dropdown menu to organize and color the flows displayed by their DSCP values.

Figure 254. Select the DSCP filter

14. If the screen does not automatically refresh, click the Refresh button to update the LiveAction topology.

Figure 255. Refresh the topology view

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 147 of 152
 Cisco dCloud

During normal operations, we can see that traffic is being load balanced (default PfR behavior) across both the Internet and MPLS
networks between the branch locations and HQ. At this point, there are several traffic flows between each location and HQ-DC.

15. Point out the direction EF traffic (shown in dark blue), is taking as it intelligently routes through the network. Light blue
represents the best effort (BE) class.

NOTE: This might vary if you have not turned off the WAN Impairment tool. You may want to turn off WAN impairment prior to the
PfRv3 Live portion of the design workshop.

Figure 256. View Topology

16. Look at the Dashboard view to for PfR details. Click on Dashboard in the upper left-hand side of the screen.

Figure 257. Click Dashboard

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 148 of 152
 Cisco dCloud

17. From there we will click on the WAN-PfR Dashboard option at the very right. Select the 1hr or 4hr time range in the upper
right-hand corner of the dashboard.

Figure 258. Select WAN-PfR tab

Let us review a simple three-step process for troubleshooting a service provider brownout and how PfRv3 reroutes the application
traffic over the backup path.

18. In the Top 10 Alerts by Site Pair section of this Dashboard (in the upper right-hand corner), double-click the Branch-1 to HQ
Alert bar option.

Figure 259. Top 10 Alerts by Site Pair

19. This Alerts by Site Pair report shows periods of normal and impaired traffic flow. Your display will be different as this report is
depending on when the WAN Impairment Toggle script toggled the impairment on and off.

20. For best viewing, select 1h or 6h from the time ranges in the top right corner of the window and then click Execute Report.

Figure 260. Alerts by Site Pair

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 149 of 152
 Cisco dCloud

21. In the lower part of the window right-click Branch-1 and navigate to Drill Down on Specific Flow > Alerts by App Group
(DSCP) Report.

Figure 261. Select Alerts by App Group (DSCP) Report

22. Select a time range, 1h or 6h, and click Execute Report. This shows VIDEO and VOICE traffic having packet loss.

Figure 262. Alerts by App Group (DSCP)

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 150 of 152
 Cisco dCloud

23. Right-click VOICE and navigate to Drill Down on Specific Flow > Alerts by Service Provider Report to find out which
service provider is causing the issue.

Figure 263. Select Alerts by Service Provider Report

24. The Alert by Service Provider report shows that MPLS service provider is the one having the packet loss problem.

Figure 264. View Alerts by Service Provider

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 151 of 152
 Cisco dCloud

25. The following workflow identifies the site-to-site alert characteristic, the applications affected and the service provider having
the network issues.

26. Close out the session with the Next Steps slide. Provide the link to the survey and information on how customers can go about
scheduling a follow up one-on-one design session with the team. Let the customer know that we will be sending them the Box
Folder invitation to access all of the presentation content (PDF format of PPT, Diagrams, Running Configurations) based on
survey responses.

Figure 265. Power Point Slide

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 152 of 152