WAN Architectures and Design Principles Adam Groudan – Technical Solutions Architect Agenda

. WAN Technologies & Solutions • WAN Transport Technologies • WAN Overlay Technologies • WAN Optimisation • Wide Area Network Quality of Service . WAN Architecture Design Considerations • WAN Design and Best Practices • Secure WAN Communication with GETVPN • Intelligent WAN Deployment . Summary The Challenge

. Build a network that can adapt to a quickly changing business and technical environment

. Realise rapid strategic advantage from new technologies • IPv6: global reachability • Cloud: flexible diversified resources • of Things • Fast-IT • What’s next?

. Adapt to business changes rapidly and smoothly • Mergers & divestures • Changes in the regulatory & security requirements • Changes in public perception of services Network Design Modularity East Theater West Theater Global

IP/MPLS Core Tier 1 Tier

In-Theater

IP/MPLS Core Tier 2 Tier West Region East Region

Internet Cloud

Public Voice/Video Mobility Tier 3 Tier

Metro Metro Service Private Service Public IP IP Service Service Hierarchical Network Principle

. Use hierarchy to manage network scalability and complexity while reducing algorithm overhead

. Hierarchical design used to be… • Three routed layers • Core, distribution, access • Only one hierarchical structure end-to-end

. Hierarchical design has become any design that… • Splits the network up into “places,” or “regions” • Separates these “regions” by hiding information • Organises these “regions” around a network core • “hub and spoke” at a macro level MPLS L3VPN Topology Definition

Spoke Site 1 Spoke Spoke Site 2 Site Y Hub Site (The Network) SP-Managed Equivalent to MPLS IP WAN

Spoke Spoke Spoke Spoke Spoke Spoke Spoke Site 1 Site 2 Site X Site Y Site N Site X Site N

. MPLS WAN is provided by a service provider . As seen by the enterprise network, every site is one IP “hop” away . Equivalent to a full mesh, or to a “hubless” hub-and-spoke Virtual Routing and Forwarding Instance (VRF) Provides Network Virtualisation and Path Isolation

VRF VRF VRF VRF VRF VRF

. Virtualisation at Layer 3 forwarding ! PE – Multiple VRFs ip vrf blue . Associates to Layer 3 interfaces on router/switch rd 65100:10 . Each VRF has its own route-target import 65100:10 route-target export 65100:10 Forwarding table (CEF) ip vrf yellow rd 65100:20 Routing process (RIP, OSPF, BGP) route-target import 65100:20 route-target export 65100:20 . VRF-Lite ! interface GigabitEthernet0/1.10 Hop-by-hop ip vrf forwarding blue . MPLS VPN interface GigabitEthernet0/1.20 ip vrf forwarding yellow Multi-hop Wide Area Network Design Trends

Single Provider Design Dual Providers Design Overlay Network Design

. Enterprise will home all sites . Enterprise will single or dual home . Overlay tunnelling technologies into a single carrier to sites into one or both carriers to with encryption for provider provide L3 MPLS VPN provide L3 MPLS VPN connectivity. transport agnostic design connectivity. . Pro: Protects against MPLS service . Pro: Can use commodity . Pro: Simpler design with failure with Single Provider broadband services for lower consistent features cost higher bandwidth service . Pro: Potential business leverage for . Con: Bound to single carrier better competitive pricing . Pro: Flexible overlay network for feature velocity topology that couples from the . Con: Increased design complexity physical connectivity . Con: Does not protect due to service implementation against MPLS cloud failure differences (e.g. QoS, BGP AS . Con: Increased design with Single Provider Topology) complexity

. Con: Feature differences between . Con: Additional technology providers could force customer to use needed for SLA over commodity least common denominator features. transport services Single Carrier Site Types (Non-Transit) . Dual Homed Non Transit AS 64517 Only advertise local prefixes (^$) CE3 CE4 Typically with Dual CE routers CE5 BGP design: eBGP to carrier AS 200 iBGP between CEs Redistribute cloud learned routes into site IGP CE1 CE2 . Single Homed Non Transit Site IGP

C1 C2 Advertise local prefixes and AS 64512 optionally use default route. Dual Carrier: Transit vs. Non Transit

. To guarantee single homed site reachability to a dual homed site experiencing a failure, transit CE3 CE4 sites had to be elected. CE5 . Transit sites would act as a BGP Transit AS 64545 bridge transiting routes between AS 100 AS 200 the two provider clouds. . To minimise latency costs of

transits, transits need to be CE1 CE2 Site selected with geographic IGP diversity (e.g. from the East, C1 C2

West and Central US.) Prefix X Prefix Y

Prefix Z Metro Ethernet Service (L2VPN)

E-Line (Point-to-Point) E-LAN (Point-to-Multipoint) . Replaces TDM private line . Offers point to multipoint for any-to- . Point-to-point EVCs offer predictable any connectivity performance for applications . Transparent to VLANs and Layer 2 . One or more EVCs allowed per control protocols single physical interface (UNI) . 4 or 6 classes of QoS support . Ideal for voice, video, and real-time . Ideal for LAN-to-LAN bulk data data MPLS (L3VPN) vs. Metro Ethernet (L2VPN) MPLS Layer 3 Service MetroE Layer 2 Service

. dependent on the . Flexibility of routing protocol and carrier network topology independent of the carrier . Layer 3 capability depends on carrier offering . Customer manages layer 3 QoS • QoS (4 classes/6 classes) . Capable of transport IP and • IPv6 capability non-IP traffic. . Transport IP protocol only . Routing protocol determines . Highly scalable and ideal for large scalability in point-to-multipoint network topology Agenda

. WAN Technologies & Solutions • WAN Transport Technologies • WAN Overlay Technologies • WAN Optimisation • Wide Area Network Quality of Service . WAN Architecture Design Considerations • WAN Design and Best Practices • Secure WAN Communication with GETVPN • Intelligent WAN Deployment . Summary Types of Overlay Service

Layer 2 Overlays Layer 3 Overlays • Layer 2 Tunnelling Protocol—Version 3 • IPSec—Encapsulating Security Payload (L2TPv3) (ESP) – Layer 2 payloads (Ethernet, Serial,…) – Strong encryption – Pseudowire capable – IP Unicast only • Other L2 overlay technologies – • Generic Routing Encapsulation (GRE) OTV, VxLAN – IP Unicast, Multicast, Broadcast – Multiprotocol support • Other L3 overlay technologies – MPLSomGRE, LISP, OTP Tunnelling GRE and IPSec Transport and Tunnel Modes

IP HDR IP Payload

GRE packet with new IP header: Protocol 47 (forwarded using new IP dst) IP HDR GRE IP HDR IP Payload

20 bytes 4 bytes

IPSec Transport mode 2 bytes ESP ESP IP HDR ESP HDR IP Payload Trailer Auth 20 bytes 30 bytes Encrypted Authenticated

IPSec Tunnel mode 2 bytes ESP ESP IP HDR ESP HDR IP HDR IP Payload Trailer Auth 20 bytes 54 bytes Encrypted Authenticated Locator/Identifier Separation Protocol (LISP) Dynamic Tunnelling Analogous to a DNS but for Network Infrastructure

. DNS resolves IP addresses for URLs

[ who is www.cisco.com] ? DNS DNS host Server URL Resolution [153.16.5.29, 2610:D0:110C:1::3 ]

. LISP resolves locators for queried identities

[ where is 2610:D0:110C:1::3] ? LISP LISP LISP Mapping Identity-to-location router [ location is 128.107.81.169 ] System Map Resolution

This Topic Is Covered in Detail in BRKRST-3045 LISP Overview - Terminologies . EID (Endpoint Identifier) is the IP address of a host – just as it is today . RLOC (Routing Locator) is the IP address of the LISP router for the host . EID-to-RLOC mapping is the distributed architecture that maps EIDs to RLOCs

ITR – Ingress Tunnel Router ETR – Egress Tunnel Router • Receives packets from site-facing interfaces • Receives packets from core-facing interfaces • Encap to remote LISP sites, or native-fwd to • De-cap, deliver packets to local EIDs at site non-LISP sites

Provider A Provider X xTR-1 xTR-1 10.0.0.0/8 12.0.0.0/8 ETR ETR

ITR ITR

packet flow packet flow S ETR ETR ITR ITR D Provider Y xTR-2 Provider B xTR-2 11.0.0.0/8 13.0.0.0/8

LISP Site 1 LISP Site 2 LISP Operation Example LISP Data Plane - Unicast Packet Forwarding

Map-Cache Entry

3 EID-prefix: 2001:db8:2::/48 Locator-set: This policy controlled 12.0.0.2, priority: 1, weight: 50 (D1) by the destination site 13.0.0.2, priority: 1, weight: 50 (D2) PI EID-prefix PI EID-prefix 2001:db8:1::/48 6 2001:db8:2::/48 11.0.0.2 -> 12.0.0.2 7 LISP Site 1 2001:db8:1::1 -> 2001:db8:2::1 LISP Site 2 2001:db8:1::1 -> 2001:db8:2::1 Provider A Provider X xTR-1 xTR-1 2 2001:db8:1::1 -> 2001:db8:2::1 10.0.0.0/8 12.0.0.0/8 ETR 5 ETR

ITR 10.0.0.2 4 12.0.0.2 ITR 11.0.0.2 -> 12.0.0.2 2001:db8:1::1 -> 2001:db8:2::1 ETR ETR S 11.0.0.2 13.0.0.2 ITR ITR D Provider Y xTR-2 Provider B xTR-2 11.0.0.0/8 13.0.0.0/8

1 DNS entry: D.abc.com AAAA 2001:db8:2::1 LISP Use Cases IPv6 Transition Efficient Multi-Homing

v6 PxTR v4 v6 IPv4 Core IPv6 Internet Internet v6 service xTR IPv4 Internet LISP LISP v6 Site routers

. IPv6-over-IPv4, IPv6-over-IPv6 . IP Portability . IPv4-over-IPv6, IPv4-over-IPv4 . Ingress Traffic Engineering Without BGP Virtualisation/Multi-tenancy Data Centre/ VM Mobility

Legacy Site Legacy Site Legacy Site Data Internet Data Centre 1 Centre 2 LISP Site PxTR LISP LISP Mapping routers routers IP Network DB VM move

VM VM West East a.b.c.1 DC DC a.b.c.1

. Large Scale Segmentation . Cloud / Layer 3 VM Move EIGRP Over-the-Top (OTP) Overview EIGRP OTP extend end-to-end network visibility over WAN EIGRP RR

CE1 172.16.2.1 172.16.1.1 CE3

EIGRP MPLS – L3 VPN EIGRP AS 100 AS 100 192.168.2.1 192.168.1.1 CE2 CE4 LISP Encapsulation

EIGRP Control Plane LISP data plane  EIGRP “over the top” of provider IPv4/IPv6 networks  NO tunnels to configure or manage  Route Reflector or Point to Point Peering  GETVPN for data privacy  VRF and SGTs carried in LISP header  CEs learn remote CE next-hops, prefixes & metrics  Provider network only includes CE next-hops (RLOC) EIGRP OTP Operation

Routing Table Routing Table 10.10.20.0/24 next-hop 172.16.2.1 metric 100 10.10.10.0/24 next-hop 172.16.1.1, metric 100 10.10.20.0/24 next-hop 192.168.2.1 metric 200 10.10.10.0/24 next-hop 192.168.1.1, metric 200

EIGRP RR

SRC172.16.2.1 DST172.16.1.1 = DP PE PE = CP

CE1 CE3 172.16.2.1 172.16.1.1

EIGRP MPLS – L3 VPN EIGRP AS 100 AS 100 192.168.2.1 192.168.1.1 10.10.20.0/24 CE2 PE PE CE4 10.10.10.0/24

SRC192.168.2.1 DST192.168.1.1 WAN Virtualisation using OTP Enterprise Benefits

• Single routing protocol solution • Simple configuration and deployment for both IPv4 and IPv6 • Convergence is not depending on Service Provider • Only the CE needs to be upgraded

• Routes are carried over the Service Provider’s network, not though it • No artificial limitation on number of routes being exchanged between sites • Convergence speed not impacted by BGP timers

• Works with both traditional managed and non-managed internet connections • Compliments an L3 Any-to-Any architecture (optional hair pinning of traffic) • Support for multiple MPLS VPN connections • Support for connections not part of the MPLS VPN (“backdoor” links) VPN Technology Positioning EzVPN/FlexVPN, DMVPN, GETVPN

EzVPN FlexVPN DMVPN GETVPN • LAN-like Encrypted VPN experience • On-demand point to multipoint • Tunnel-less Encrypted VPNs for a diverse set of VPN client Encrypted VPNs • Any-to-Any VPN connectivity suitable including software clients • Simplified branch to branch for IP VPNs • Enhances interoperability by connectivity solutions • No overlay routing consolidating tunnels from • OPEX reduction using zero-touch • Simplified QoS integration with Crypto teleworkers, retail stores, or branch deployment • Reduced latency and jitter due to offices • Resilient VPN solution combining both direct communication with no central • Centralised policy and management crypto and routing control plane hub control • Eliminates P2P IKE relationship with Group Encryption Keys Cisco Site to Site VPN Technologies Comparison Features DMVPN FlexVPN GET VPN . Public or Private Transport . Private IP Transport . Public or Private Transport . Overlay Routing . Flat/Non-Overlay IP Infrastructure Network . Overlay Routing . IPv4/IPv6 dual Stack Routing . Large Scale Hub and Spoke . Converged Site to Site and . Any-to-Any; Network Style with dynamic Any-to-Any Remote Access (Site-to-Site)

. Dynamic Routing or IKEv2 Route . Active/Active based on . Transport Routing Distribution Failover Redundancy Dynamic Routing . COOP Based on GDOI . Server Clustering

. Unlimited . Unlimited . 8000 GM total Scalability . 3000+ Client/Srv . 3000+ Client/Srv . 4000 GM/KS

. Multicast replication in . Multicast replication at hub . Multicast replication at hub IP Multicast IP WAN network

. Per SA QoS, Hub to Spoke . Per Tunnel QoS, Hub to Spoke . Transport QoS QoS . Per SA QoS, Spoke to Spoke Policy Control . Locally Managed . Centralised Policy Management . Locally Managed . Tunneled VPN . Tunneled VPN . Tunnel-less VPN Technology . Multi-Point GRE Tunnel . Point to Point Tunnels . Group Protection . IKEv1 & IKEv2 . IKEv2 Only . IKEv1 Dynamic Multipoint VPN (DMVPN)

• Branch spoke sites establish an IPsec tunnel to and SECURE ON-DEMAND TUNNELS register with the hub site • IP routing exchanges prefix information for each site ASR 1000 Hub • BGP or EIGRP are typically used for scalability IPsec Branch n • With WAN interface IP address as the tunnel VPN ISR G2 source address, provider network does not need to route customer internal IP prefixes ISR G2 ISR G2 • Data traffic flows over the DMVPN tunnels Branch 1 Branch 2 • When traffic flows between spoke sites, the hub assists the spokes to establish a site-to-site tunnel Traditional Static Tunnels • Per-tunnel QOS is applied to prevent hub site DMVPN On-Demand Tunnels oversubscription to spoke sites Static Known IP Addresses Dynamic Unknown IP Addresses DMVPN – How it Works • Spokes build a dynamic permanent GRE/IPsec tunnel to the Dual DMVPN Design hub, but not to other spokes. They register as clients of the Single mGRE tunnel on Hub, NHRP server (hub) and register their NBMA address two mGRE tunnels on Spokes 192.168.0.0/24 • Active-Active redundancy model—two or more hubs per spoke Physical: 172.17.0.5 Physical: 172.17.0.1 • All configured hubs are active and are routing neighbours Tunnel0: 10.0.1.1 Tunnel0: 10.0.0.1 with spokes • Routing protocol routes are used to determine traffic forwarding Physical: (dynamic) Tunnel0: 10.0.0.12 • A spoke will initially send a packet to a destination (private) Tunnel1: 10.0.1.12 subnet behind another spoke via the hub, and the hub will send it an NHRP redirect. • The redirect triggers the spoke to send an NHRP query for the data packet destination address behind the destination spoke .1 • The destination spoke initiates a dynamic GRE/IPsec tunnel to 192.168.3.0/24 the source spoke (it now knows its NBMA address) and sends Physical: (dynamic) Tunnel0: 10.0.0.11 the NHRP reply. Tunnel1: 10.0.1.11

• The dynamic spoke-to-spoke tunnel is built over the mGRE .1 .1 interface 192.168.1.0 /24 192.168.2.0 /24 • When traffic ceases then the spoke-to-spoke tunnel is removed DMVPN Network Designs Spoke-to-hub tunnels Spoke-to-spoke tunnels

2547oDMVPN tunnels Increase inIncreaseScale

Hub and spoke Spoke-to-spoke VRF-lite

Server Load Balancing Hierarchical 2547oDMVPN Any-to-Any Encryption Before and After GETVPN Public/Private WAN Private WAN Before: IPSec P2P Tunnels After: Tunnel-Less VPN

WAN

Multicast . Scalability—an issue (N^2 problem) . Scalable architecture for any-to-any . Overlay routing connectivity and encryption . Any-to-any instant connectivity can’t . No overlays—native routing be done to scale . Any-to-any instant connectivity . Limited QoS . Enhanced QoS . Inefficient Multicast replication . Efficient Multicast replication Group Security Functions Routing Member Key Server . Forwarding Key Server . Replication . Validate Group Members . Routing . Manage Security Policy . Create Group Keys . Distribute Policy/Keys Group Member Routing Members

Group Member Group Group Member Member . Encryption Devices . Route Between Secure/ Unsecure Regions Group . Multicast Participation Member Group Security Elements KS Cooperative Key Servers Group Policy Protocol

Key Encryption Key (KEK) Traffic Encryption Key (TEK) Group Member Routing Members

Group Member Group Member RFC3547: Group Domain of Interpretation Group (GDOI) Member GETVPN - Group Key Technology Operation Example GM3 GM4 GM2 . Step 1: Group Members (GM) GM5 “register” via GDOI (IKE) with the GM1 Key Server (KS) GM6 GM9 KS • KS authenticates and authorises the GM GM8 GM7 • KS returns a set of IPsec SAs GM3 for the GM to use GM4 GM2

. Step 2: Data Plane Encryption GM5 GM1 • GM exchange encrypted traffic using the group keys GM6 • The traffic uses IPSec Tunnel Mode with GM9 KS “address preservation” GM8 GM7 GM3 GM4 . Step 3: Periodic Rekey of Keys GM2 GM5 • KS pushes out replacement IPsec GM1

keys before current IPsec keys expire; GM6 This is called a “rekey” GM9 KS GM8 GM7 GETVPN Virtualisation Deployment Model GETVPN Segmented WAN CE PE PE CE

MPLS VPN

LISP with GETVPN CE PE PE CE

GET Encrypted LISP

LISP over GETVPN MACsec Layer 2 Encryption for WAN

• Ethernet is not only in the campus and data centre any longer ASR 1001-X XE3.14

• Ethernet is growing rapidly as a WAN & Metro “transport” service

• WAN/Metro SP offerings are replacing existing T1, ATM/FR, and SONET OC-x options

• Ethernet services apply to many areas of the WAN/MAN: • WAN links for core, edge, remote branch • PE-CE links (leveraging L3 VPN services) • Metro-E service hand-offs (P2P, P2MP)

• Cisco’s goal is to integrate MACsec as part of new Ethernet interface/LC development moving forward on routers leveraged in WAN, MAN, Branch

Market Transition – Ethernet WAN Transport MACSec - Line Rate Encryption L2 Solution What is MACSec? IEEE 802.1AE standard for strong cryptographic protection at Layer 2

Authenticated ß Encrypted DMAC SMAC 802.1Q 802.1AE Header CMD ETYPE PAYLOAD ICV CRC

802.1Q tag in clear Simple • Easy to configure. Simple configuration on interface level only. No GRE Tunnel establishment. • Reduced interoperability issues with other L3 Features Secure • Leverage Advanced Encryption Standard Galios/Counter Mode (AES-GCM-128) Line Rate Encryption • Leverages “line rate” Ethernet performance of the port (PHY). Speeds 1/10G, 40G, 100G • Ethernet WAN deployments driving increasing need for higher crypto bandwidths. MACsec Deployment Model Ring Topology P-t-P E-LINE IPv4/v6 IPv4/v6 IPv4/v6 IPv4/v6 CE2

Routers peer per VLAN sub- interface per PW Point-to-point dark fibre

CE4 CE3 IPv4/v6 Ethernet Sub-interface with IPv4/v6 IPv4/v6 IPv4/v6 802.1q support

Clear-Tag Feature: Leverage 802.1Q tag support for full/partial-mesh over Metro-Ethernet Agenda

. WAN Technologies & Solutions • WAN Transport Technologies • WAN Overlay Technologies • WAN Optimisation • Wide Area Network Quality of Service . WAN Architecture Design Considerations • WAN Design and Best Practices • Secure WAN Communication with GETVPN • Intelligent WAN Deployment . Summary The WAN Is the Barrier to Branch Application Performance . Applications are designed to work Round Trip Time ~ 0ms well on LAN’s • High bandwidth • Low latency Client LAN Switch Server • Reliability

. WANs have Round Trip Time ~ Many milliseconds opposite characteristics • Low bandwidth LAN Client LAN Switch • High latency Switch WAN Server • Packet loss

WAN Packet Loss and Latency = Slow Application Performance = Keep and manage servers in branch offices ($$$) TCP Behaviour

Return to maximum throughput could take a very long time!

Window Packet loss Packet loss Packet loss Packet loss TCP Size

Slow start Congestion avoidance Time (RTT)

RFC1323 - TCP Extensions for High Performance WAAS—TCP Performance Improvement . Transport Flow Optimisation (TFO) overcomes TCP and WAN bottlenecks . Shields nodes connections from WAN conditions – Clients experience fast acknowledgement – Minimise perceived packet loss – Eliminate need to use inefficient congestion handling

WAN

Window Scaling LAN TCP Large Initial Windows LAN TCP Behaviour Congestion Mgmt Behaviour Improved Retransmit WAAS Advanced Compression DRE and LZ Manage Bandwidth Utilisation

Data Redundancy Elimination •Application-agnostic compression (DRE) •Up to 100:1 compression •WAAS 4.4: Context Aware DRE

Benefits •Session-based compression Persistent LZ Compression • Application-agnostic compression ••UpUp to to 10:1 100:1 compression compression ••WorksWAAS even 4.4: duringContext cold Aware DRE DRE cache

LZ WAN LZ

DRE DRE Synchronised Compression History Comparing TCP and Transport Flow Optimisation

Cisco TFO Provides Significant Throughput Improvements over Standard TCP Implementations

Window TFO Size

TCP

Slow start Congestion avoidance Time (RTT) TFO is using RFC2018, RFC1323, RFC3390 and BIC-TCP http://netsrv.csc.ncsu.edu/export/bitcp.pdf Cisco WAAS: WAN Optimisation Deployment

Virtual Private Cloud vWAAS Server WAAS WAE VMs Branch Office Express

Nexus 1000v vPATH

VMware ESXi Server

WAAS Service Branch Office Module/ UCSe WAN Nexus 1000v VSM UCS /x86 Server FC SAN

Data Centre or WAAS Private Cloud WAAS Branch Office Appliance Appliances Internet AppNav + WAAS

WAAS vWAAS Server VMs Regional Office Appliance Appliances VMware ESXi

WAAS-XE Regional Office on 4451 Agenda

. WAN Technologies & Solutions • WAN Transport Technologies • WAN Overlay Technologies • WAN Optimisation • Wide Area Network Quality of Service . WAN Architecture Design Considerations • WAN Design and Best Practices • Secure WAN Communication with GETVPN • Intelligent WAN Deployment . Summary Quality of Service Operations How Does It Work and Essential Elements Classification and Queuing and Post-Queuing Marking Dropping Operations

. Classification and Marking: • The first element to a QoS policy is to classify/identify the traffic that is to be treated differently. Following classification, marking tools can set an attribute of a frame or packet to a specific value. . Policing: • Determine whether packets are conforming to administratively-defined traffic rates and take action accordingly. Such action could include marking, remarking or dropping a packet. . Scheduling (including Queuing and Dropping): • Scheduling tools determine how a frame/packet exits a device. Queuing algorithms are activated only when a device is experiencing congestion and are deactivated when the congestion clears. Enabling QoS in the WAN Traffic Profiles and SLA Requirements

Voice SD Video Conf Telepresence Data

. Smooth . Bursty . Bursty . Smooth/bursty . Benign . Greedy . Drop sensitive . Benign/greedy . Drop sensitive . Drop sensitive . Delay sensitive . Drop insensitive . Delay sensitive . Delay sensitive . Jitter sensitive . Delay insensitive . UDP priority . UDP priority . UDP priority . TCP retransmits

Bandwidth per Call SD/VC has the Same HD/VC has Tighter Traffic patterns for Depends on Codec, Requirements as Requirements than Data Vary Among Sampling-Rate, VoIP, but Has VoIP in terms of jitter, Applications and Layer 2 Media Radically Different and BW varies based Traffic Patterns on the resolutions . Latency ≤ 150 ms (BW Varies Greatly) . Data Classes: . Jitter ≤ 30 ms . Latency ≤ 150 ms . Latency ≤ 200 ms . Mission-Critical Apps . Loss ≤ 1% . Jitter ≤ 30 ms . Jitter ≤ 20 ms . Transactional/Interactive Apps . Bandwidth (30-128Kbps) . Loss ≤ 0.05% . Loss ≤ 0.10% . Bulk Data Apps One-Way Requirements . Best Effort Apps (Default) . Bandwidth (1Mbps) . Bandwidth (5.5-16Mbps) One-Way Requirements One-Way Requirements Scheduling Tools policy-map CBWFQ LLQ/CBWFQ Subsystems class NETWORK-CONTROL IOS Interface Buffers bandwidth percent 5 class CALL-SIGNALING bandwidth percent 5 class OAM Network Control CBWFQ bandwidth percent 5 class MM-CONFERENCING Call Signalling CBWFQ bandwidth percent 10 fair-queue FQ … Packets Multimedia Conferencing CBWFQ In FQ CBWFQ Multimedia Streaming CBWFQ Scheduler Tx-Ring FQ Packets Transactional Data CBWFQ Out FQ Bulk Data CBWFQ

FQ FQ Best Effort / Default CBWFQ Pre-Sorters

Scavenger CBWFQ Scheduling Tools LLQ/CBWFQ Subsystems

IOS Interface Buffers policy-map MULTI-LLQ class VOIP 1 Mbps VoIP priority 1000 Policer class REALTIME-INTERACTIVE LLQ 5 Mbps priority 5000 RT-Interactive … Policer

Packets Packets In Out CBWFQ Scheduler Tx-Ring

CBWFQ Traffic Shaping

Without Traffic Shaping Line Rate With Traffic Shaping Shaped Rate

Traffic Shaping Limits the Transmit Rate to a Value Lower Than Line Rate

. Policers typically drop traffic

. Shapers typically delay excess traffic, smoothing bursts and preventing unnecessary drops

. Very common with Ethernet WAN, as well as Non- Broadcast Multiple-Access (NBMA) network topologies such as Frame-Relay and ATM Hierarchical QoS For Subrate Service H-QoS Policy on WAN Interface, Shaper = CIR

Two Levels MQC

Policy-map PARENT Gig 0/1 class class-default shape average 150000000 Service Level service-policy output CHILD

Policy-map CHILD class Voice police cir percent 10 Best Effort priority level 1 150 Mbps class Video police cir percent 20 Video priority level 2 class Control bandwidth remaining ration 1 Control class class-default Voice bandwidth remaining ratio 9

Interface gigabitethernet 0/1 service-policy output PARENT MPLS VPN QoS Considerations MPLS VPN Port QoS Roles Campus VPN Block Branch 1 E F F E MPLS VPN E F F E

Branch 2 CE Routers PE Routers CE Routers Enterprise Subscriber (Unmanaged CE Routers)

E Outbound Policies: Inbound Policies: HQoS Shaper (if required) ≤ 33% + LLQ for VoIP (EF) Trust DSCP of BW + LLQ or CBWFQ for RT-Interactive (CS4) + Remark RTI (if necessary) + Restore RT-Interactive to CS4 (if necessary) + CBWFQ for Signalling (CS3) + Remark Signalling (if necessary) + Restore Signalling to CS3 (if necessary)

Service Provider: Outbound Policies: Inbound Policies: F + LLQ for Real-Time Trust DSCP + CBWFQ for Critical Data Police on a per-Class Basis GRE/IPSec QoS Consideration ToS Byte Preservation

ToS byte is copied to

the new IP Header IP HDR IP Payloaad ToS

GRE Tunnel GRE

IP HDR IP HDR IP Payload ToS

HDR ToS

IPSec Tunnel mode

ESP ESP

IP HDR ESP HDR IP HDR IP Payload Trailer Auth

ToS ToS GRE and IPsec Network QoS Design

Direction of Packet Flow

DSCP CS5 DSCP CS5 DSCP AF41 DSCP CS5 DSCP CS5 DSCP CS5 Packet initially marked to Packet decapsulated to By default, ToS values are Topmost ToS value is DSCP AF41according to reveal the original ToS byte copied to IPsec header rewritten on egress to match RFC-4594 service provider classes policy-map WAN-SP-CLASS-OUTPUT . Remark DSCP on egress to align with each SP’s class VOICE SLA class of service requirements priority percent 10 class VIDEO-INTERACTIVE priority percent 23 set dscp af41 . H-QOS with shaping to offered rate on egress class NETWORK-MGMT bandwidth percent 5 service-policy MARK-BGP . Hub per tunnel QOS to minimise spoke class class-default bandwidth percent 25 oversubscription random-detect Re-marks the DSCP value on the ! encrypted and encapsulated header on policy-map Int-Gig-Agg-HE class class-default the egress interface shape average 1000000000 service-policy WAN-Out Agenda

. WAN Technologies & Solutions • WAN Transport Technologies • WAN Overlay Technologies • WAN Optimisation • Wide Area Network Quality of Service . WAN Architecture Design Considerations • WAN Design and Best Practices • Secure WAN Communication with GETVPN • Intelligent WAN Deployment . Summary Cisco Validate Design MPLS WAN Technology Design Guide WAN Aggregation Reference Design

Campus/ Data Data Centre Centre/ Campus WAAS Service

WAN Key Services/ Servers Distribution

VPN Termination

WAN Edge MPLS A MPLS B

Internet Remote Branch Transport & Redundancy Options

Non-Redundant Redundant-Links Redundant-Links & Routers

MPLS MPLS MPLS MPLS MPLS MPLS WAN

MPLS Internet MPLS + MPLS Internet Internet WAN

Internet Internet Internet

Internet WAN Routing Topology at WAN Aggregation

Campus/ Core Layer Data Centre

WAN Distribution Layer EIGRP AS 100

Summaries+ Default

DMVPN Hub Routers EIGRP AS = 100 EIGRP AS = 100 iBGP EIGRP AS = 100 Internet Edge

BGP AS = 65511 EIGRP AS = 200 MPLS CE BGP AS = 65511 Layer 2 WAN Routers CE Router

eBGP Layer 2 DMVPN 1 DMVPN 2 Internet MPLS A MPLS B WAN WAN Edge

Connection Methods Compared Recommended

Multi-Chassis EtherChannel VSS/3850 Stacks Shared Si Layer 3 LAN P-to-P Link

WAN WAN WAN

. No Static Routes . No First Hop Redundancy Protocols Optimise Convergence and Redundancy Multi-chassis EtherChannel

VSS/3850 Stacks

Si Layer 3 P-to-P Link Channel Member Removed IGP recalc

. Link redundancy achieved through . Provide Link Redundancy and reduce redundant L3 paths peering complexity . Flow based load-balancing through CEF . Tune L3/L4 load-balancing forwarding across hash to achieve maximum utilisation . Routing protocol reconvergence when uplink . No L3 reconvergence required when failed member link failed . Convergence time may depends on routing . No individual flow can go faster than protocol used and the size of routing entries the speed of an individual member of the link Link Recovery Comparison ECMP vs. Multichassis EtherChannel

. ECMP convergence is dependent on the number of Si Layer 3 routes P-to-P Link

. MEC convergence is consistent, independent of the number of routes

2.5

2 ECMP MEC Max 1.5 VSS/3850 Stacks

1

0.5 sec of of lostsecvoice

0 1000 3000 6000 9000 12000 Number of Routes - Sup720C Redundancy vs. Convergence Time More Is Not Always Better

. In principle, redundancy is easy . Any system with more parallel paths through the system will fail less often . The problem is a network isn’t really a single system but a group of 2.5 interacting systems . Increasing parallel paths increases routing complexity, therefore increasing convergence times Seconds

0 Routes 10000 Best Practice — Summarise at Service Distribution

. It is important to force summarisation Campus/ Summary at the distribution towards WAN Edge Data Centre 10.5.0.0/16 and towards campus & data centre

. Summarisation provides topology change isolation.

. Summarisation reduce routing table Summaries + Default size. 10.4.0.0/16 0.0.0.0/0.0.0.0 interface Port-channel1 description Interface to MPLS-A-CE no switchport ip address 10.4.128.1 255.255.255.252 ip pim sparse-mode ip summary-address eigrp 100 10.5.0.0 255.255.0.0

MPLS A MPLS B Best Practice – Preventing Routing Loops with Route Tag and Filter . Mutual route redistribution between protocols can cause routing loops without preventative measures IGP Domain . Use route-map to set tags and then redistribute (EIGRP/OSPF) based on the tags . Routes are implicitly tagged when distributed from Campus eBGP to EIGRP/OSPF with carrier AS . Use route-map to block re-learning of WAN routes via the distribution layer (already known via iBGP)

router eigrp 100 distribute-list route-map BLOCK-TAGGED-ROUTES in default-metric [BW] 100 255 1 1500 MPLS WAN redistribute bgp 65500

route-map BLOCK-TAGGED-ROUTES deny 10 BGP Domain match tag 65401 65402

route-map BLOCK-TAGGED-ROUTES permit 20 Dual Carriers with BGP as CE-PE Protocol Use iBGP for Path Selection

. Run iBGP between the CE routers to exchange prefixes associated with each Campus carrier

. CE routers will use only BGP path selection information to select both the primary and secondary preferences for any destinations 10.5.128.0/21 announced by the IGP and BGP iBGP

. Use IGP (OSPF/EIGRP) for prefix re- advertisement will result in equal-cost paths at remote-site MPLS A MPLS B bn-br200-3945-1# sh ip bgp 10.5.128.0/21 BGP routing table entry for 10.5.128.0/21, version 71 Paths: (2 available, best #2, table default, RIB-failure(17)) Not advertised to any peer 65401 65402, (aggregated by 65511 10.5.128.254) 10.4.142.26 from 10.4.142.26 (192.168.100.3) Origin IGP, localpref 100, valid, external, atomic- A B aggregate 65402, (aggregated by 65511 10.5.128.254) iBGP 10.4.143.26 (metric 51456) from 10.5.0.10 (10.5.0.253) 10.5.128.0/21 Origin IGP, metric 0, localpref 100, valid, internal, atomic-aggregate, best Best Practice - Implement AS-Path Filter Prevent Branch Site Becoming Transit Network

. Dual carrier sites can unintentionally become Campus transit network during network failure event and causing network congestion due to transit traffic

. Design the network so that transit path between two carriers only occurs at sites with enough bandwidth

. Implement AS-Path filter to allow only locally originated routes to be advertised on the

outbound updates for branches that should not MPLS B be transit MPLS A

router bgp 65511 neighbor 10.4.142.26 route-map NO-TRANSIT-AS out ! ip as-path access-list 10 permit ^$ A B ! route-map NO-TRANSIT-AS permit 10 iBGP match as-path 10 For Your Golden Rules Reference Route Preference for EIGRP & OSPF EIGRP OSPF

. Internal EIGRP – Admin Dist. 90 . Admin Dist. 110

. External EIGRP – Admin Dist. 170 . Route Preference 1. Intra-Area . Metric Calculation 2. Inter-Area metric = bandwidth + delay 3. External E1 (Internal + External Cost) • Bandwidth (in kb/s) 4. External E2 (External Cost) • Delay (in microseconds) . Cost Calculation Cost= Reference BW / Interface BW Default Reference BW = 100Mbps Best Practice – Use Delay Parameter to Influence EIGRP Path Selection

. EIGRP uses the minimum bandwidth along the path and the total delay to compute routing metrics . Does anything else use these values? • EIGRP also uses interface Bandwidth parameter to avoid congestion by pacing routing updates (default is 50% of bandwidth) • Interface Bandwidth parameter is also used for QoS policy calculation • Performance Routing (PfR) leverages Bandwidth parameter for traffic load sharing

. Delay parameter should always be used to influence EIGRP routing decision MPLS + Internet WAN Prefer the MPLS Path over Internet

Campus . eBGP routes are redistributed into EIGRP 100 as EIGRP external routes with default Admin Distance 170 AS100

10.4.128.2 . Running same EIGRP AS for both campus and DMVPN network would result in Internet path preferred

eBGP over MPLS path

MPLS A Internet

EIGRP AS100

10.5.48.0/21 MPLS + Internet WAN Use Autonomous System for IGP Path Differentiation

Campus D EX 10.5.48.0/21 [170/28416] via 10.4.128.2 . eBGP routes are redistributed into EIGRP 100 as external routes with default Admin Distance 170 EIGRP AS100 . Running same EIGRP AS for both campus and 10.4.128.2 DMVPN network would result in Internet path preferred

over MPLS path eBGP . Multiple EIGRP AS processes can be used to provide control of the routing . EIGRP 100 is used in campus location EIGRP 200 over DMVPN tunnels Internet MPLS A . Routes from EIGRP 200 redistributed into EIGRP 100 appear as external route (distance = 170)

EIGRP . Routes from both WAN sources are equal-cost paths. AS200 To prefer MPLS path over DMVPN use eigrp delay to modify path preference MPLS CE router#

router eigrp 100 10.5.48.0/21 default-metric 1000000 10 255 1 1500 MPLS VPN BGP Path with IGP Backdoor Path

. eBGP as the PE-CE Routing Protocol Campus

. MPLS VPN as preferred path learned via EIGRP AS100 eBGP

. Secondary path via backdoor IGP link R1 R2 eBGP (EIGRP or OSPF) over tunneled connection IGP

(DMVPN over Internet) BackupLink

. Default configuration the failover to backup MPLS A Internet path works as expected

10.4.160.0/24 MPLS VPN BGP Path with IGP Backdoor Path

Campus . After link restore, MPLS CE router receives EIGRP BGP advertisement for remote-site route. AS100 . Does BGP route get (re)installed in the route

table? R1 R2

eBGP IGP

D EX 10.4.160.0/24 [170/3584].... BackupLink

MPLS A Internet

R1# show ip route B 10.4.144.0/24 [20/0] via 10.4.142.2, 01:30:06 B 10.4.145.0/24 [20/0] via 10.4.142.2, 01:30:06 D EX 10.4.160.0/24 [170/3584] via 10.4.128.9, 00:30:06

B 10.4.160.0/24 [20/0].... 10.4.160.0/24 For Your BGP Route Selection Algorithm Reference BGP Prefers Path with: 1. Highest Weight 2. Highest Local Preference 3. Locally originated (via network or aggregate BGP) 4. Shortest AS_PATH 5. Lowest Origin type IGP>EGP>INCOMPLETE (redistributed into BGP) 6. Lowest Multi-Exit Discriminator (MED) 7. Prefer Externals (eBGP over iBGP paths) 8. Lowest IGP metric to BGP next hop (exit point) 9. Lowest Router ID for exit point BGP Prefers Path with Highest Weight

. Routes redistributed into BGP are considered locally originated and get a default weight of 32768

. The eBGP learned prefix has default weight of 0

. Path with highest weight is selected

ASR1004-1#show ip bgp 10.4.160.0 255.255.255.0 BGP routing table entry for 10.4.160.0/24, version 22 Paths: (3 available, best #3, table default) Advertised to update-groups: 4 5 65401 65401 10.4.142.2 from 10.4.142.2 (192.168.100.3) Origin IGP, localpref 200, valid, external Local 10.4.128.1 from 0.0.0.0 (10.4.142.1) Origin incomplete, metric 26883072, localpref 100, weight 32768, valid, sourced, best Prefer the eBGP Path over IGP Set the eBGP weight > 32768

. To resolve this issue set the weights on route learned via eBGP peer higher than 32768

neighbor 10.4.142.2 weight 35000

ASR1004-1#show ip bgp 10.4.160.0 255.255.255.0 BGP routing table entry for 10.4.160.0/24, version 22 Paths: (1 available, best #1, table default) Not advertised to any peer 65401 65401 10.4.142.2 from 10.4.142.2 (192.168.100.3) Origin IGP, metric 0, localpref 100, weight 35000, valid, external, best

ASR1004-1#show ip route .... B 10.4.160.0/24 [20/0] via 10.4.142.2, 05:00:06 Agenda

. WAN Technologies & Solutions • WAN Transport Technologies • WAN Overlay Technologies • WAN Optimisation • Wide Area Network Quality of Service . WAN Architecture Design Considerations • WAN Design and Best Practices • Secure WAN Communication with GETVPN • Intelligent WAN Deployment . Summary Dual Carrier GETVPN Topology COOP Key Server

Key Servers

GM GM

MPLS A MPLS B MPLS A MPLS B

GM GM GM GM GM GM Best Practice - High Availability with Cooperative Key Servers

• Two or more KSs known as COOP KSs manage a common set of keys and security policies for GETVPN group members

• Group members can register to any one of the available KSs

• Cooperative KSs periodically exchange and synchronise group’s database, policy and keys

• Primary KS is responsible to generate and distribute group keys Cooperative KS1 Cooperative KS2

Subnet 1 Subnet 2 GM 1 GM 2 IP Network

Subnet 4 Subnet 3

GM 4 GM 3 For Your Best Practice - Key Server Recommendations Reference . Maintain reliable KS communication: •Insure multiple routing paths exist between all KS •Use loopback interface for KS registration and Cooperative KS protocol Use IKE keep- alive for KS-KS communication

. Use only globally applicable policies in KS proxy identifiers: •Site specific policies should be applied at the GM •Goal is to create symmetric policies on KS •Exception policy development should be done on GM, not KS

. Use sufficiently long key lifetimes to minimise key transitions: •Traffic Encryption Key (TEK) > 3600 sec •Key Encryption Key (KEK) > 86400 sec

. Insure rekey interval extends longer than routing convergence time Transition from Clear-text to GETVPN SA Receive-Only Method . Goal permit ip 10.1.4.0 0.0.1.255 10.1.4.0 0.0.1.255 • Incrementally deploy infrastructure 10.1.4.0/24 without encryption KS •Immediate transition to encryption 10.1.6.0/24 controlled by KS GM GET . Method GM •Deploy KS with Receive-only SA’s GM (don’t encrypt, allow decryption) GM •Deploy GM throughout infrastructure and monitor rekey processes 10.1.5.0/24 10.1.7.0/24 •Transition KS to Normal SA (encrypt, permit ip 10.1.4.0 0.0.3.255 10.1.4.0 0.0.3.255 decrypt) 10.1.4.0/24 . Assessment KS •Pro: Simple transition to network-wide 10.1.6.0/24 encryption GM GET •Con: Correct policies imperative GM •Con: Deferred encryption until all CE GM are capable of GM functions GM

10.1.5.0/24 10.1.7.0/24 For Your Group Member Reference Secured Group Member Interface interface Serial0/0 ip address 192.168.1.14 255.255.255.252 crypto map svn <- WAN ENCRYPTION access-group pack-filter out <- ALLOW IPsec and Control Packet filter (after encryption) ip access-list extended pack-filter permit esp any any <- ALLOW IPsec permit ip host 192.168.1.14 host 192.168.1.13 <- ALLOW ROUTE ADJACENCY permit tcp host 192.168.1.14 eq ssh any <- ALLOW SECURE SHELL Crypto Map Association to Group Security crypto map svn 10 gdoi<- GROUP CRYPTO MAP ENTRY set group secure-wan <- GROUP MEMBERSHIP match address control_plane <- LOCAL POLICY (EXCLUDE) Group Member Policy Exceptions ip access-list extended control_plane <- CONTROL PLANE PROTOCOLS deny ip host 192.168.1.14 host 192.168.1.13 <- PE-CE LINK (BGP, ICMP) deny tcp host 192.168.1.14 eq ssh any <- MANAGEMENT SECURE SHELL Group Member Association crypto gdoi group secure-wan <- GROUP ENCRYPTION identity number 3333 <- MEMBER’S GROUP IDENTITY server address ipv4 <- KS ADDRESS TO REGISTER server address ipv4 <- ALTERNATE KS REGISTRATION For Your Key Server Reference crypto gdoi group secure-wan identity number 3333 <- GROUP ID server local <- KEY SERVER rekey retransmit 40 number 3 <- REKEY RETRANSMITS rekey authentication mypubkey rsa my_rsa <- KS MSG AUTHENTICATION rekey transport unicast <- Unicast Rekey saipsec 10 <- SECURITY ASSOCIATION profile GETVPN-GDOI-PROFILE <- CRYPTO ATTRIBUTES SELECTION match address ipv4ipsec-policy <- ENCRYPTION POLICY no replay <- NO ANTI-REPLAY address ipv4 <- KS ADDRESS Crypto Attributes crypto ipsec profile GETVPN-GDOI-PROFILE set security-association lifetime seconds 7200 set transform-set AES256/SHA <- AES256 for Encryption and SHA for Hash Encryption IPsec Proxy ID’s (mandatory) ip access-list extended ipv4ipsec-policy <- ENCRYPTION POLICY deny udp any eq 848 any eq 848 <- ALLOW GDOI permit ip 10.0.0.0 0.255.255.255 10.0.0.0 0.255.255.255 <- UNICAST permit ip 10.0.0.0 0.255.255.255 232.0.0.0 0.255.255.255 <- MULTICAST Agenda

. WAN Technologies & Solutions • WAN Transport Technologies • WAN Overlay Technologies • WAN Optimisation • Wide Area Network Quality of Service . WAN Architecture Design Considerations • WAN Design and Best Practices • Secure WAN Communication with GETVPN • Intelligent WAN Deployment . Summary Internet Becoming an Extension of Enterprise WAN

Commodity Transports Viable Now

Dramatic Bandwidth, Price Performance Benefits

Higher Network Availability

Improved Performance Over Internet https://www.google.com/get/videoqualityreport/ Intelligent WAN Solution Components

AVC Private Cloud MPLS Virtual Private Cloud 3G/4G-LTE

Branch Internet Public WAAS PfR Cloud

Control & Management with Automation

Transport Intelligent Application Secure Independent Path Control Optimisation Connectivity

• Consistent operational model • Dynamic Application best • Application visibility with • Certified strong encryption • Simple provider migrations path based on policy performance monitoring • Cloud Managed Security for • Scalable and modular design • Load balancing for full • Application acceleration secure direct Internet access • IPsec routing overlay design utilisation of bandwidth and bandwidth • Comprehensive threat • Improved availability optimisation defence Hybrid WAN Designs Traditional and IWAN

TRADITIONAL HYBRID IWAN HYBRID

Active/Standby Active/Active WAN Paths WAN Paths Primary With Backup Data Centre Data Centre

Two IPsec Technologies ASR 1000 ASR 1000 ASR 1000 ASR 1000 One IPsec Overlay GETVPN/MPLS ISP A SP V ISP A SP V DMVPN/Internet DMVPN

DMVPN GETVPN DMVPN DMVPN Two WAN Routing MPLS MPLS Domains Internet Internet MPLS: eBGP or Static One WAN Internet: iBGP, EIGRP or OSPF Routing Domain Route Redistribution iBGP, EIGRP, or OSPF Route Filtering Loop Prevention Minimal route filtering

Branch ISR-G2 ISR-G2 Branch DMVPN Deployment over Internet Multiple Default Routes for VPN Headend

. VPN Headend has a default route to ASA firewall’s VPN-DMZ interface to reach default Internet

default INSIDE . Remote site policy requires centralised Internet Edge Internet access Block default . Enable EIGRP between VPN headend & Campus core to propagate default to remote VPN-DMZ default OUTSIDE . Static default (admin dist=0) remains active,

. VPN-DMZ is wrong firewall interface for user InternetInternet traffic Internet . Adjust admin distance so EIGRP route installed (to core) default

. VPN tunnel drops DMVPN Deployment over Internet

. Enable FVRF with DMVPN to

separate out the two default routes default EIGRP

default . The RED-VRF contains the default INSIDE route to VPN-DMZ Interface needed Internet Edge for Tunnel Establishment Block default . A 2nd default route exist on the Global Routing Table used by the user data VPN-DMZ default traffic to reach Internet OUTSIDE

. To prevent split tunnelling the default default route is advertised to spokes via Internet Tunnel Internet . Spoke’s tunnel drops due to 2nd default route conflict with the one default learned from ISP Best Practice – VRF-aware DMVPN Keeping the Default Routes in Separate VRFs

Same Technique default . Enable FVRF DMVPN on the Spokes EIGRP default INSIDE . Allow the ISP learned Default Route in the Internet RED-VRF and used for tunnel Edge Block establishment default

. Global VRF contains Default Route VPN-DMZ default learned via tunnel. User data traffic follow OUTSIDE Tunnel to INSIDE interface on firewall default . Allow for consistency for implementing Internet corporate security policy for all users Internet

default DMVPN and FVRF Configuration Example DMVPN Tunnel Global Interface Routing Table Global

Branch LAN Traffic

F-VRF Internet VRFs have independent Front Side routing and forwarding planes Provider VRF

ip vrf RED interface GigabitEthernet0/1 rd 65512:1 ip vrf forwarding RED ! ip address dhcp crypto keyring DMVPN-KEYRING vrf RED ! pre-shared-key address 0.0.0.0 0.0.0.0 key cisco123 interface Tunnel10 ! ip address 10.4.132.201 255.255.254.0 ! crypto isakmp policy 10 …. encr aes 256 tunnel mode gre multipoint authentication pre-share tunnel vrf RED group 2 tunnel protection ipsec profile DMVPN-PROFILE ! ! crypto isakmp keepalive 30 5 router eigrp 200 ! network 10.4.132.0 0.0.0.255 crypto isakmp profile FVRF-ISAKMP-RED network 10.4.163.0 0.0.0.127 keyring DMVPN-KEYRING eigrp router-id 10.4.132.201 match identity address 0.0.0.0 RED ! Increase Routing Scalability and Stability EIGRP Stub

. Marking the spokes as stubs allows the STUBs to signal hub A and B that they are not valid transit paths A BB

. A will not query stubs, reducing the total number of queries in this example to one

. Marking the remotes as stubs also reduces the complexity of this topology

. Router B now believes it only has one path to 10.1.1.0/24 (through A), rather than five

router#config t router(config)#router eigrp 100 router(config-router)#eigrp stub connected router(config-router)# Best Practices — Avoid Fragmentation with IPSec VPN

GRE+IPsec MTU 1400 MTU 1500 MTU 1500

Tunnel Setting (AES256+SHA) Minimum MTU Recommended MTU

GRE/IPSec (Tunnel Mode) 1414 bytes 1400 bytes GRE/IPSec (Transport Mode) 1434 bytes 1400 bytes . IP fragmentation will cause CPU and memory overhead and resulting in lowering throughput performance . When one fragment of a datagram is dropped, the entire original IP datagram will have to be resent . Use ‘mode transport’ on transform-set • NHRP needs for NAT support and saves 20 bytes . Avoid MTU issues with the following best practices • ip mtu 1400 • ip tcp adjust-mss 1360 Best Practices — Enable Dead Peer Detection (DPD) Improve DMVPN Network Convergence

. Dead Peer Detection (DPD) is a mechanism for detecting unreachable IKE peers

. Each peer’s DPD state is independent of the others

. Without DPD spoke routers will continue to encrypt tun10 traffic using old SPI which would be dropped at the hub. May take up to 60 minutes for spokes to reconverge

. Use ISAKMP keepalives on spokes Internet crypto isakmp keepalives • ISAKMP invalid-SPI-recovery is not useful with DMVPN • ISAKMP keepalive timeout should be greater than routing protocol hellos

. Not recommended for Hub routers – may cause an increase of CPU overhead with large number of peers

Informational RFC 3706 Best Practices — Enable PIM NBMA-Mode Multicast over DMVPN . By default router uses OIL to correlate multicast group join to interface PIM Multicast Prune . This causes problem when hub is connected to towards multiple spokes over NBMA network RP . Any spoke that leaves a multicast group would case all the spokes to be pruned off the multicast group . Enable PIM NBMA mode under tunnel interface on hubs and spokes Internet . ip pim nbma-mode . Allows the router to track multicast joins based on IP address instead of interface PIM Prune . Applies only to PIM sparse-mode . Router treats NBMA network as a collection of point- to-point circuits, allowing remote sites to be pruned off traffic flows IGMP Leave Receiver Receiver IWAN Transport Best Practices

. Private peering with Internet providers IWAN HYBRID • Use same Internet provider for hub and spoke sites • Avoids Internet Exchange bottlenecks between providers • Reduces round trip latency . DMVPN Phase 3 Data Centre • Separate DMVPN network per provider for path diversity • Per tunnel QOS ISP A SP V • NG Encryption – IKEv2 + AES-GCM-256 encryption

. Transport settings DMVPN DMVPN Purple Green • Use the same MTU size on all WAN paths Internet MPLS • Bandwidth settings should match offered rate . Routing overlay

• iBGP or EIGRP for high scale (1000+ sites) Branch • Single routing process, simplified operations • Front-side VRF to isolate external interfaces

99 Agenda

. WAN Technologies & Solutions • WAN Transport Technologies • WAN Overlay Technologies • WAN Optimisation • Wide Area Network Quality of Service . WAN Architecture Design Considerations • WAN Design and Best Practices • Secure WAN Communication with GETVPN • Intelligent WAN Deployment . Summary Modern Hierarchical Global WAN Design East Theater West Theater Global

IP/MPLS Core Tier 1 Tier

In-Theater

IP/MPLS Core Tier 2 Tier West Region East Region

Internet Cloud

Public Voice/Video Mobility Tier 3 Tier

Metro Metro Service Private Service Public IP IP Service Service Key Takeaways

. Understand how WAN characteristics can affect your applications. • Bandwidth, latency, loss

. A modular hierarchical network infrastructure is the foundation for a solid WAN architecture. Good WAN design have many well-utilised component

. Encryption is a foundation component of all WAN designs and can be deployed transparently.

. Understand how to build wide area network leveraging Internet transport with Intelligent WAN.

. Design a network with consistent behaviour that provides predictable performance.

. More is not always better. Keep it simple! Suggested Sessions

. BRKRST-2309 Introduction to WAN MACsec

. BRKRST-3336 WAN Virtualisation using OTP

. BRKRST-2514 Application Optimisation and Provisioning the IWAN

. BRKCRS-2000 Intelligent WAN 2.0 Update

. BRKRST-3045 LISP A Next Generation Networking Architecture Continue Your Education

• Demos at the Cisco stand

• Walk-in Self-Paced Labs

• Table Topics

• Meet the Expert 1:1 meetings

• Related sessions Q & A Complete Your Online Session Evaluation Give us your feedback and receive a Cisco 2016 T-Shirt by completing the Overall Event Survey and 5 Session Evaluations. – Directly from your mobile device on the Cisco Live Mobile App – By visiting the Cisco Live Mobile Site http://showcase.genie-connect.com/ciscolivemelbourne2016/ – Visit any Cisco Live Internet Station located throughout the venue Learn online with Cisco Live! T-Shirts can be collected Friday 11 March Visit us online after the conference for full access to session videos and at Registration presentations. www.CiscoLiveAPAC.com Thank you