BRKRST-2041-WAN Architectures and Design Principles

BRKRST-2041
WAN Architectures and

Design Principles
Stephen Lynn
Consulting Systems Architect
stlynn@cisco.com
CCIE 5507 (R&S/WAN/Security)
CCDE 2013::56
@netw0rkStlynn
Cisco Spark
Questions?
Use Cisco Spark to communicate
with the speaker after the session
How
1. Find this session in the Cisco Live Mobile App
2. Click “Join the Discussion”
3. Install Spark or go directly to the space
4. Enter messages/questions in the space
cs.co/ciscolivebot#BRKRST-2041
© 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public
Agenda
 WAN Technologies & Solutions
• WAN Transport Technologies
• WAN Overlay Technologies
• WAN Optimization
• Wide Area Network Quality of Service
• WAN Extension into the Cloud
 WAN Architecture Design
Considerations
• WAN Design and Best Practices
• SD-WAN
 Summary
WAN Transport Technologies
The WAN Technology Continuum
Early Networking Early-Mid 1990s Mid 1990s-Late 2000s Today
Global Scale
Flat/Bridged Multiprotocol Large Scale
IP Ubiquity
Experimental Networks Business Enabling Mission Critical
Business Survival
Architectural Architectural Architectural

Planning
Lessons Lessons Lessons
Protocols required for Route First, Redundancy
Scale & Restoration Bridge only if Must
Build to Scale
?
DMVPN
X.25 Frame-Relay IPv6
Internet 4G/LTE
Protocol BGP GRE
1960 1980 2000 Future
1970 RIP (BSD) 1990 2010

ARPAnet Metro-Ethernet
1960 OSPF, Tag
TCP/IP Switching SDN
ISDN,
ATM BRKRST-2041 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 6
The Challenge
 Build a network that can adapt to a quickly changing business and technical
environment
 Realize rapid strategic advantage from new technologies
• IPv6: global reachability
• Cloud: flexible diversified resources
• Internet 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
BRKRST-2041 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 7
Network Design Modularity East Theater
West Theater
Tier 1
Global
IP/MPLS Core
Tier 2
In-Theater
IP/MPLS Core
West Region East Region
Internet
Cloud
Public Voice/Video Mobility
Tier 3
Metro Metro
Service Service
Private Public
IP IP
Service Service
Hierarchical Network Principle
 Use hierarchy to manage network scalability and complexity
while reducing routing algorithm overhead
 Hierarchical design used to be…
• Three routed layers
• Core, aggregation, 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
• Organizes 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 Virtualization and Path Isolation
VRF VRF
VRF VRF
VRF VRF
 Virtualization at Layer 3 forwarding ! PE Router – 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
interface GigabitEthernet0/1.20
 MPLS VPN 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 tunneling 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
Advertise local prefixes and
C1 C2 optionally use default route.
AS 64512
Dual Carrier: Transit vs. Non Transit
 To guarantee single homed site
reachability to a dual homed site
experiencing a failure, transit sites CE3 CE4
had to be elected. CE5
 Transit sites would act as a BGP Transit

bridge transiting routes between the AS 64545
two provider clouds. AS 100 AS 200
 To minimize latency costs of transits,

transits need to be selected with
geographic diversity (e.g. from the CE1 CE2
East, West and Central US.) Site
IGP
C1 C2
Prefix X Prefix Y
Prefix Z
Single vs. Dual Carriers
Single Provider Dual Providers
Pro: Common QoS support
Pro: More fault domains
model
Pro: More product offerings to
Pro: Only one carrier to “tune”
business
Pro: Ability to leverage vendors
Pro: Reduced head end circuits
for better pricing
Pro: Nice to have a second
Pro: Overall simpler design
vendor option
Con: Carrier failure could be Con: Increased Bandwidth
catastrophic “Paying for bandwidth twice”
Con: Do not have another Con: Increased overall design
carrier “in your pocket” complexity
Con: May be reduced to
“common denominator” between
carriers
Resiliency Drivers vs. Simplicity
Metro Ethernet Service (L2VPN)
E-Line (Point-to-Point) E-LAN (Point-to-Multipoint)

 Replaces TDM private line and  Offers point to multipoint connectivity
Frame-Relay or ATM L2VPN  Transparent to VLANs and Layer 2
 Point-to-point EVCs offer predictable control protocols
performance for applications
 4 or 6 classes of QoS support
 One or more EVCs allowed per
 Supports service multiplexing (Ex.
single physical interface (UNI)
Internet access and corporate VPN
 Supports “hub & spoke” topology via one UNI)
MPLS (L3VPN) vs. Metro Ethernet (L2VPN)
MPLS Layer 3 Service MetroE Layer 2 Service
 Routing protocol 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
WAN Overlay Technologies
Types of Overlay Service
Layer 2 Overlays Layer 3 Overlays

 IPSec—Encapsulating Security Payload
 Layer 2 Tunneling Protocol—Version 3 (ESP)
(L2TPv3)
– Strong encryption
– Layer 2 payloads (Ethernet, Serial,…)
– IP Unicast only
– Pseudowire capable
 Generic Routing Encapsulation (GRE)
 Other L2 overlay technologies – – IP Unicast, Multicast, Broadcast
OTV, VxLAN – 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
2 bytes
IPSec Transport mode
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 / ID Separation Protocol (LISP)
LISP “Mapping System” is analogous to a DNS lookup
‒ DNS resolves IP addresses for queried URL Answers the “WHO IS” question
[ Who is www.cisco.com ] ?
DNS
DNS Name -to- IP
Host Server URL Resolution
[ Address is 153.16.5.29, 2610:D0:110C:1::3 ]
‒ LISP resolves locators for queried identities Answers the “WHERE IS” question
[ Where is 2610:D0:110C:1::3 ] ?
LISP LISP Map
LISP
Router System ID -to- Locator
Map Resolution
[ Locator is 128.107.81.169, 128.107.81.170 ]
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
• Receives packets from site-facing interfaces
ETR – Egress Tunnel Router
• Receives packets from core-facing interfaces
• Encap to remote LISP sites, or native-fwd to
non-LISP sites • De-cap, deliver packets to local EIDs at site
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 B Provider Y
xTR-2 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
LISP Site 1 2001:db8:1::1 -> 2001:db8:2::1 LISP Site 2 7
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
S ETR
11.0.0.2 13.0.0.2
ETR
ITR ITR D
Provider B Provider Y
xTR-2 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 Efficient Multi-Homing
IPv6 Transition
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
Virtualization/Multi-tenancy Data Center/ VM Mobility

Legacy Site Legacy Site Legacy Site
Data Internet Data
Center 1 Center 2
LISP Site PxTR
LISP LISP
Mapping
routers routers
IP Network DB
VM move
VM VM
West East
DC a.b.c.1 a.b.c.1
DC
 Large Scale Segmentation  Cloud / Layer 3 VM Move

Cisco Site to Site VPN Technologies Comparison
Features DMVPN FlexVPN GET VPN
 Public or Private Transport  Private IP Transport
 Public or Private Transport
Infrastructure Network  Overlay Routing  Flat/Non-Overlay IP
 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
Failover Redundancy Distribution
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
IP Multicast  Multicast replication at hub  Multicast replication at hub
IP WAN network
 Per SA QoS, Hub to Spoke

QoS  Per Tunnel QoS, Hub to Spoke  Transport QoS
 Per SA QoS, Spoke to Spoke
Policy Control  Locally Managed  Centralized 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
source address, provider network does not need
to route customer internal IP prefixes ISR
ISR
 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
Static Known IP Addresses
oversubscription to spoke sites
Dynamic Unknown IP Addresses
DMVPN – How it Works
 Spokes build a dynamic permanent GRE/IPsec tunnel to the hub, Dual DMVPN Design
but not to other spokes. They register as clients of the NHRP Single mGRE tunnel on Hub,
two mGRE tunnels on Spokes
server (hub) and register their NBMA address
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 neighbors 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
Tunnel1: 10.0.1.12
 A spoke will initially send a packet to a destination (private)
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
192.168.3.0/24
 The destination spoke initiates a dynamic GRE/IPsec tunnel to the
source spoke (it now knows its NBMA address) and sends the Physical: (dynamic)
Tunnel0: 10.0.0.11
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 in Scale
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RFC6407:
Group Domain of Group
Interpretation (GDOI) Member
GETVPN - Group Key Technology
Operation Example GM3
GM4
GM2
 Step 1: Group Members (GM) GM5

GM1
“register” via GDOI (IKE) with the GM6
Key Server (KS)
GM9 KS
• KS authenticates and authorizes 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
GM6
group keys
GM9
• The traffic uses IPSec Tunnel Mode with KS
GM8 GM7
“address preservation”
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
GM7
GM8 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public
GETVPN Virtualization 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 center any longer
 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 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public
What is “WAN MACsec?
Secure Ethernet Link(s) over Public Ethernet Transport
MKA Session
Service Provider
Owned Routers/Bridges
Data Data
Center Public Carrier Center
Ethernet
Service Central
Remote
Campus/DC Campus/DC
• Leverage “public” standard-based Ethernet transport

MACsec MKA Session
• Optimize MACsec + WAN features to accommodate running
over public Ethernet transport MACsec Secured Path / MKA
Session
• Target “line-rate” encryption for high-speed applications MACsec Capable Router
• Inter DC, MPLS WAN links, massive data projects MACsec Capable PHY
• Targets 100G, but support 1/10/40G as well SP Owned Ethernet

Transport Device
What is “WAN” MACsec?
New Enhancements to 802.1AE for WAN/Metro-E Transport
• AES-256 (AES/GCM) support – 1/10/40 and 100G rates
• Target Next Generation Encryption (NGE) profile that currently leverages public NSA Suite B
• Standards Based MKA key framework
• (defined in 802.1X-2010) within Cisco security development (Cisco “NGE”)
• Ability to support 802.1Q tags in clear
• Offset 802.1Q tags in clear before encryption (2 tags is optional)
• Vital Network Features to Interoperate over Public Carrier Ethernet Providers
• 802.1Q tag in the clear
• Ability to change MKA EAPoL Destination Address type
• Ability to change MKA Ether-type value
• Ability to configure Anti-replay window sizes
• System Interoperability
• Create a common MACsec integration among all MACsec platforms in Cisco and Open Standards
MACsec Deployment Model
Ring Topology P-t-P E-LINE
IPv4/v6 P-t-MP E-LAN IPv4/v6
IPv4/v6 IPv4/v6 CE2
Metro E Routers peer per

VLAN sub-
interface per PW
Point-to-point dark fiber
CE4IPv4/v6 CE3
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
WAN Optimization
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
opposite Round Trip Time ~ Many milliseconds
characteristics
• Low bandwidth
• High latency LAN
Client WAN LAN Switch Server
• Packet loss Switch
WAN Packet Loss and Latency =

Slow Application Performance =
Keep and manage servers in branch offices ($$$)
TCP Behavior
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 Optimization (TFO) overcomes TCP and WAN bottlenecks
 Shields nodes connections from WAN conditions
– Clients experience fast acknowledgement
– Minimize perceived packet loss
– Eliminate need to use inefficient congestion handling
WAN
Window Scaling
LAN TCP Large Initial Windows LAN TCP
Behavior Congestion Mgmt Behavior
Improved Retransmit
WAAS Advanced Compression
DRE and LZ Manage Bandwidth Utilization
Data Redundancy Elimination •Application-agnostic compression

(DRE) •Up to 100:1 compression
•WAAS 4.4: Context Aware DRE
Benefits
•Session-based compression
• Application-agnostic compression
Persistent LZ Compression •Up
• Uptoto10:1 compression
100:1 compression
•Works
• WAASeven4.4: during
Contextcold DREDRE
Aware cache
LZ WAN LZ
DRE DRE
Synchronized
Compression
History
Comparing TCP and Transport
Flow Optimization
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
WAN Quality of Service
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)  Bulk Data Apps
 Loss ≤ 0.05%  Loss ≤ 0.10%
One-Way Requirements  Best Effort Apps (Default)
 Bandwidth (1Mbps)  Bandwidth (5.5-16Mbps)
One-Way Requirements One-Way Requirements
policy-map WAN
class VOICE
Scheduling Tools priority percent 10
class VIDEO
LLQ/CBWFQ Subsystems priority percent 23
class CRITICAL-DATA
IOS Interface Buffers bandwidth percent 15
random-detect dscp-based
class DATA
1 Mbps
VoIP bandwidth percent 19
Policer random-detect dscp-based
LLQ class SCAVENGER
5 Mbps
RT-Interactive bandwidth percent 5
Policer class NETWORK-CRITICAL
bandwidth percent 3
service-policy MARK-BGP
class class-default
Packets
bandwidth percent 25
Packets random-detect Out
In
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 Policy-map CHILD Gig 0/1
class class-default class VOICE
Service Level
shape average 150000000 priority percent 10
service-policy output CHILD class VIDEO
priority percent 23 Best Effort
Interface gigabitethernet 0/1 class CRITICAL-DATA
service-policy output PARENT bandwidth percent 15
random-detect dscp-based
class DATA Scavenger 150 Mbps
random-detect dscp-based Video
class SCAVENGER Critical Data
bandwidth percent 5
class NETWORK-CRITICAL
Voice Network
bandwidth percent 3
Critical
service-policy MARK-BGP
class class-default
random-detect
GRE/IPSec QoS Consideration
ToS Byte Preservation
ToS byte is copied to
ToS
the new IP Header IP HDR IP Payloaad
GRE Tunnel
GRE
ToS
ToS
IP HDR HDR
IP HDR IP Payload
IPSec Tunnel mode

ESP ESP
ToS
ToS
IP HDR ESP HDR IP HDR IP Payload Trailer Auth
WAN Extension into the Cloud
Cloud Migration Trend
Secure Agile Exchange at Colocations Facilities
Cloud
SaaS
Customers Secure Agile
Exchange Customers
Colocation
Centers
Private
Secure Agile Data Center
Employees Exchange
Employees
Partners DMZ
Applications Partners Public Cloud
Private
Data Center
BRKDCT-2409 Building The Secure Agile Hybrid Cloud Network

Connectivity Options into AWS Cloud
Corporate DC
AWS Managed VPN
Internet Cisco
ISR/ASR
VGW
Private
Network
CSR 1000V Corporate DC

AWS Direct
Connect
Colocation Facility
Cisco
ISR/ASR
CSR 1000V
AWS Virtual Private Cloud (VPC) Overview
 Represents logically isolated network
 Separate IP range, Subnet, Routes, and
Security
 Overlap IP address allowed
 NO Support for Multicast/Broadcast traffic, Internet GW
VLANs, and Transit Routing

Subnet
Router
 Network Controls Available to you:
 Route Tables, aka VRFs  Internet gateway forward traffic to
 Internet Gateway (IGW), aka an Internet Router outsides and in between VPCs
 Security Groups and Network ACLs  Subnet Router forward traffic within
 VPNaaS the VPC
AWS VPC Peering Transit Routing Limitations
 You have a VPC peering connection
between VPC A and VPC B
 And between VPC A and VPC_C C

B
 But you cannot route packets X
directly from VPC B to VPC C
through VPC
A
Inter-VPN Design using Transit VPCs with CSR1000v
 End to end routings between
App VPC Shared Services VPC 3rd Party VPC
VPCs in all regions and other
none AWS network
 Used for hierarchical designs VGW
VPC
• Scaling beyond VPC peering peering
limits VPC
peering
• Security/Monitoring Services in
Transit VPC
Availability Availability
Zone 1 Zone 2
 Redundant CSRs for HA and Transit VPC
fast convergence
Direct
 Can use VRFs to resolve Connect
recursive routing issues
Corporate Network/DC
Transit VPC to Interconnect AWS Regions
AZ 1 AZ 2
Transit VPC
US-West-2 AZ 1 AZ 2
Transit VPC
US-East-2
Corporate Network/DC
WAN Architecture Design
and Best Practices
Cisco Validate Design
MPLS WAN Technology Design Guide
BRKRST-2041 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public
WAN Aggregation Reference Design
Campus/
Data Center
Data
Center/
Campus WAAS Service
WAN
Key
Services/
Servers
Distribution
VPN Termination
WAN Edge
MPLS A MPLS B
Internet
Routing Topology at WAN Aggregation
Campus/
Core Layer
Data Center
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 Internet
MPLS A MPLS B DMVPN 1 DMVPN 2
WAN
WAN Edge
Connection Methods Compared Recommended
Multi-Chassis
EtherChannel
VSS/3850
Stacks
Si Shared Si Si Layer 3 Si
LAN P-to-P Link
WAN
WAN WAN
 No Static Routes
 No First Hop Redundancy Protocols
Optimize Convergence and Redundancy
Multi-chassis EtherChannel
VSS/3850
Stacks
Si Layer 3 Si
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  Tune L3/L4 load-balancing
CEF forwarding across hash to achieve maximum utilization
 Routing protocol reconvergence when  No L3 reconvergence required when
uplink failed member link failed
 Convergence time may depends on  No individual flow can go faster than
routing protocol used and the size of the speed of an individual member of
routing entries the link
Link Recovery Comparison
ECMP vs. Multichassis EtherChannel
 ECMP convergence is dependent on the number of Si Layer 3 Si
routes P-to-P Link
 MEC convergence is consistent, independent of the

number of routes
2.5
2 ECMP
MEC Max
sec of lost voice
1.5 VSS/3850
Stacks
1
0.5
0
1000 3000 6000 9000 12000
Number of Routes
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
Seconds
 Increasing parallel paths increases
routing complexity, therefore
increasing convergence times
0 Routes 10000
Best Practice —
Summarize at Service Distribution
 It is important to force summarization Campus/ Summary

at the distribution towards WAN Edge Data Center 10.5.0.0/16
and towards campus & data center
 Summarization provides topology
change isolation.
 Summarization 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
MPLS WAN
default-metric [BW] 100 255 1 1500
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 10.5.128.0/21
secondary preferences for any destinations
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-
aggregate A B
65402, (aggregated by 65511 10.5.128.254) iBGP
10.4.143.26 (metric 51456) from 10.5.0.10 (10.5.0.253)
Origin IGP, metric 0, localpref 100, valid, internal, 10.5.128.0/21
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 A MPLS B
be transit
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
Golden Rules For Your
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
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
over MPLS path
eBGP
MPLS A Internet
EIGRP
AS100
10.5.48.0/21
MPLS + Internet WAN
Use Autonomous System for IGP Path Differentiation
D EX 10.5.48.0/21 [170/28416] via 10.4.128.2
Campus
 eBGP routes are redistributed into EIGRP 100 as
EIGRP
external routes with default Admin Distance 170
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
MPLS A Internet
 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
(EIGRP or OSPF) over tunneled connection
eBGP
IGP Backup Link

(DMVPN over Internet)
 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

R1 R2
table?
eBGP
IGP Backup Link

D EX 10.4.160.0/24 [170/3584]....
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
Reference
BGP Route Selection Algorithm
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

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

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
Cisco SD-WAN
Cisco SD-WAN Solution Philosophy
Application Traffic Per-Segment Secure Cloud Cloud Transport
SLA Engineering Topologies Perimeter Path Accel Hub
Analytics
Application Policies
Routing Security Segmentation QoS Multicast Svc Insertion Survivability

Monitoring
Delivery Platform
Operations
Broadband MPLS Cellular
Transport Independent Fabric

Cisco SD-WAN Secure Extensible Network
Orchestration Plane vOrchestrator
vBond MANAGEMENT
Management Plane API
(Multi-tenant or Dedicated)
ORCHESTRATION
vManage
ANALYTICS
Control Plane CONTROL

(Containers or VMs)
INTERNET MPLS 4G
vSmart
Data Plane
(Physical or Virtual)
Data Center Campus Branch Home Office

vEdge
Cisco SD-WAN Solution Elements
Orchestration Plane Orchestration Plane
vManage
Cisco vBond
APIs
3rd Party
vAnalytics  Orchestrates connectivity
Automation
 First point of authentication
vBond (white-list model)
 Distributes list of vSmarts/
vSmart Controllers vManage to all vEdge routers
 Requires public IP Address
MPLS 4G
[could be behind 1:1 NAT]
INET  Facilitates NAT traversal
vEdge Routers
 Highly resilient
Cloud Data Center Campus Branch SOHO
Management Plane Management Plane
vManage
Cisco vManage
APIs
 Single pane of glass for Day0,
3rd Party
vAnalytics Day1 and Day2 operations
Automation
 Multitenant with web scale
vBond  Centralized provisioning
vSmart Controllers  Policies and Templates
 Troubleshooting and
4G Monitoring
MPLS
INET
 Software upgrades
vEdge Routers  GUI with RBAC
 Programmatic interfaces
(REST, NETCONF)
Cloud Campus Branch SOHO
Data Center  Highly resilient
Control Plane Control Plane
vManage
Cisco vSmart
APIs
3rd Party  Centralized brain of the operation

vAnalytics
Automation  Facilitates fabric discovery
 Dissimilates control plane
vBond
information between vEdges
vSmart Controllers  Distributes data plane and app-
aware routing policies to the
4G
vEdge routers
MPLS
 Implements control plane policies
INET
vEdge Routers such as
o Traffic Engineering
o Service Chaining,
o Multi-topology (hub/spoke,
partial, or full mesh)
Cisco SD-WAN Solution Elements Data Plane
Physical/Virtual
Data Plane
vManage Cisco vEdge
APIs  WAN edge router

 Leverages traditional routing
3rd Party
vAnalytics protocols like OSPF, BGP and
Automation
VRRP
vBond  Provides secure data plane with
remote vEdge routers
vSmart Controllers  Establishes secure control plane
with vSmart controllers (OMP)
MPLS 4G  Apply application aware routing
INET policies
vEdge Routers
 Support Zero Touch Deployment
 Physical or Virtual form factor
(VNF) support
Overlay Management Protocol (OMP)
Unified Control Plane
vSmart  TCP based TLS/DTLS control plane protocol
 Runs between vEdge routers and vSmart
controllers and between the vSmart controllers
 Advertises control plane context, i.e. TLOCs,
unicast/multicast destinations, service routes (L4-
L7), BFD stats (TE and H-SDWAN) and Cloud
onRamp for SaaS probe stats (gateway)
vSmart vSmart
 Distributes IPSec encryption keys, and data and
app-aware policies (embedded NETCONF)
VS
vEdge vEdge
Note: vEdge routers need not connect to all vSmart Controllers
Secure Segmentation
End-to-End Segmentation
VPN 1
Interface VPN1 SD-WAN VPN1 Interface
IPSec VPN 2
VLAN VPN2 Tunnel VPN2 VLAN
VPN 3
Ingress Egress
vEdge vEdge
IP UDP ESP VPN Data

20 8 36 4 …
• Segment connectivity across fabric w/o • Labels are used to identify VPN for
reliance on underlay transport destination route lookup
• vEdge routers maintain per-VPN routing • Interfaces and sub-interfaces (802.1Q tags)
table are mapped into VPNs
Fabric Operation Walk-Through
OMP Update:
OMP
vSmart  Reachability – IP Subnets, TLOCs
 Security – Encryption Keys
DTLS/TLS Tunnel
 Policy – Data/App-route Policies
IPSec Tunnel
OMP OMP
BFD Update Update
Policies
OMP OMP
Update Update
vEdge Transport 1 vEdge
TLOCs TLOCs
VPN1 VPN2 Transport 2 VPN1 VPN2
BGP, OSPF, BGP, OSPF,
Connected, Connected,
Static A B C D Static
Subnets Subnets
Cisco SD-WAN Migration Strategy
Gateway/DC Site Deployment  Identify Gateway/DC Sites
providing connectivity between
BGP/OSPF SD-WAN and legacy sites
 Legacy sites talk to each other

DC/Gateway Site directly
 SD-WAN sites talk to each other

directly
Internet SD-WAN MPSL
Secure Fabric  Legacy router/connectivity is
dropped in the DC/Gateway sites
once migration is complete
Legacy/MPLS Sites
SD-WAN Sites
SD-WAN TCP Maximum Segment Size Adjustment
Packet Fragmentation Avoidance for TCP Traffic
Link IP MTU
IPSec
Link IP MTU
1500 Bytes 1500 Bytes
Host vEdge vEdge Application
Secure Fabric
Router Router Servers
Signaled MSS Signaled MSS
1460B MSS Adjust 1320B Send MSS
to 1320B 1320B
Signaled MSS Signaled MSS
1320B MSS Adjust 1460B
Send MSS
1320B to 1320B
 Tunneling introduces additional overhead and increases packet size

 Send TCP MSS is min (local link IP MTU - 40B*, signaled MSS value)
- Signaled in SYN packets
 vEdge Router TCP MSS adjustment overrides signaled MSS value
- Each side determines its own MSS value, not synchronized
* 20B IP header + 20B TCP header. Does not include TCP options.
Summary
Modern Hierarchical Global WAN Design
East Theater
West Theater
Tier 1
Global
IP/MPLS Core
Tier 2
In-Theater
IP/MPLS Core
West Region East Region
Internet
Cloud
Public Voice/Video Mobility
Tier 3
Metro Metro
Service Service
Private 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-utilized 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
SD-WAN.
 Design a network with consistent behavior that provides predictable
performance.
 More is not always better. Keep it simple!
Recommended Reading
Abstract:
Virtual Routing in the Cloud are key enablers of
today’s revolutionary shift to elastic cloud
applications and low-cost virtualized networking.
The book covers every essential building block,
present key use cases and configuration
examples, illuminate design and deployment
scenarios, and show how the CSR 1000V
platform and APIs can enable state-of-the-art
software-defined networks (SDN). Drawing on
extensive early adopter experience, they
illuminate crucial OS and hypervisor details, help
you overcome migration challenges, and offer
practical guidance for monitoring and operations.
http://bit.ly/2l8UAod
Suggested Sessions
• BRKRST-2042 Highly Available WAN Design
• BRKRST-2309 Introduction to WAN MACsec
• BRKRST-2514 Application Optimization and Provisioning the IWAN
• BRKRST-3045 LISP A Next Generation Networking Architecture
• BRKCRS-2000 Intelligent WAN 2.0 Update
• BRKSEC-4054 Advanced Concepts of DMVPN
Cisco Spark
Questions?
Use Cisco Spark to communicate
with the speaker after the session
How
1. Find this session in the Cisco Live Mobile App
2. Click “Join the Discussion”
3. Install Spark or go directly to the space
4. Enter messages/questions in the space
cs.co/ciscolivebot#BRKRST-2041
• Please complete your Online Complete Your Online
Session Evaluations after each
session
Session Evaluation
• Complete 4 Session Evaluations
& the Overall Conference
Evaluation (available from
Thursday) to receive your Cisco
Live T-shirt
• All surveys can be completed via
the Cisco Live Mobile App or the
Communication Stations
Don’t forget: Cisco Live sessions will be
available for viewing on-demand after the
event at CiscoLive.com/Online.
Continue Your Education
• Demos in the Cisco campus
• Walk-in Self-Paced Labs
• Tech Circle
• Meet the Engineer 1:1 meetings
• Related sessions
Thank you

BRKRST-2041-WAN Architectures and Design Principles

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

BRKRST-2041-WAN Architectures and Design Principles

Uploaded by

Copyright:

Available Formats

BRKRST-2041

WAN Architectures and

Architectural Architectural Architectural

1970 RIP (BSD) 1990 2010

West Region East Region

 Hierarchical design has become any design that…

Spoke Spoke Spoke Spoke Spoke

 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

 Virtualization at Layer 3 forwarding ! PE Router – Multiple VRFs

 Transit sites would act as a BGP Transit

 To minimize latency costs of transits,

E-Line (Point-to-Point) E-LAN (Point-to-Multipoint)

Layer 2 Overlays Layer 3 Overlays

 Other L3 overlay technologies –

IPSec Tunnel mode 2 bytes

This Topic Is Covered in Detail in BRKRST-3045

packet flow packet flow

LISP Site 1 LISP Site 2

2001:db8:1::1 -> 2001:db8:2::1

ITR 10.0.0.2 4 12.0.0.2 ITR

 IPv6-over-IPv4, IPv6-over-IPv6  IP Portability

Virtualization/Multi-tenancy Data Center/ VM Mobility

 Large Scale Segmentation  Cloud / Layer 3 VM Move

 Dynamic Routing or IKEv2 Route

 Unlimited  Unlimited  8000 GM total

 Per SA QoS, Hub to Spoke

 The dynamic spoke-to-spoke tunnel is built over the mGRE .1 .1

 When traffic ceases then the spoke-to-spoke tunnel is removed

Server Load Balancing Hierarchical 2547oDMVPN

 Scalability—an issue (N^2 problem)  Scalable architecture for any-to-any

Key Encryption Key

 Step 1: Group Members (GM) GM5

• KS returns a set of IPsec SAs

 Step 2: Data Plane Encryption GM5

 Step 3: Periodic Rekey of Keys GM2

LISP with GETVPN

GET Encrypted LISP

LISP over GETVPN

• Leverage “public” standard-based Ethernet transport

• Targets 100G, but support 1/10/40G as well SP Owned Ethernet

Metro E Routers peer per

Clear-Tag Feature: Leverage 802.1Q tag support

WAN Packet Loss and Latency =

Slow start Congestion avoidance Time (RTT)

RFC1323 - TCP Extensions for High Performance

Data Redundancy Elimination •Application-agnostic compression

Cisco TFO Provides Significant Throughput

Slow start Congestion avoidance Time (RTT)

TFO is using RFC2018, RFC1323, RFC3390 and BIC-TCP

 Classification and Marking:

 Smooth  Bursty  Bursty  Smooth/bursty

Without Traffic Shaping

 Policers typically drop traffic

ToS byte is copied to

IPSec Tunnel mode

IP HDR ESP HDR IP HDR IP Payload Trailer Auth

BRKDCT-2409 Building The Secure Agile Hybrid Cloud Network

AWS Managed VPN

CSR 1000V Corporate DC

 NO Support for Multicast/Broadcast traffic, Internet GW

VLANs, and Transit Routing

 And between VPC A and VPC_C C