wan virtualization using over-the-top (otp) techadvantage webinar

Cisco TechAdvantage Webinars WAN Virtualization using OTP

Donnie Savage – TME Chris Le – PM

Follow us @GetYourBuildOn

We’ll get started a few minutes past the top of the hour.

Note: You may not hear any audio until we get started.

© 2013 Cisco and/or its affiliates. All rights reserved. Presentation_ID Cisco Public

•  Submit questions in Q&A panel and send to “All Panelists” Avoid CHAT window for better access to panelists

•  Please complete the post-event survey

•  For WebEx audio, select COMMUNICATE > Join Audio Broadcast

•  Where can I get the presentation? Or send email to: [email protected]

•  Join us for upcoming TechAdvantage Webinars: www.cisco.com/go/techadvantage

•  For WebEx call back, click ALLOW phone button at the bottom of participants side panel

Housekeeping


Panelists Speaker

Donnie Savage Technical Leader

[email protected]

Saul Adler Technical Leader

[email protected]

Chris Le Product Manager [email protected]

Speaker & Panelists Introduction

Overview


PE-CE Issues

§  Service Provider must redistributed and carry Enterprise routes via MP-iBGP; –  Either EIGRP or eBGP must be run between the CE/PE –  BGP route propagation impacts Site’s convergence –  Provider often limits number of routes being redistributed –  Route flaps within sites results in BGP convergence events –  Route metric changes results in new extended communities flooded into the core

§  Enterprise and Service Provider must co-support deployment –  Managed services is required, even if not needed –  Control of traffic flow using multiple providers is problematic –  Changing providers results in migration issues

5

PE1 PE2

CE1 CE2

MPLS VPN Core

Site 2 Site 1


PE-CE Issues with Backdoor Links

§  Route redistribution adds deployment complications –  Without PE/CE support, back-door must be redistributed into a second instance of EIGRP –  With PE/CE support, use of SoO (route) tagging must be used to prevent count-to-infinity issues

due to BGP’s slower convergence

6

CE1

CE2

Backdoor Link

C3

PE1 PE2

CE1 CE2

MPLS VPN Cloud

Site 2 Site 1

C4

CE2


OTP – Overview WAN Virtualization using OTP §  OTP supports transparent CE to CE Routing §  Single “end-to-end” IGP solution with:

–  NO special requirement on Service Provider

–  NO special requirement on Enterprise

–  NO routing protocol on CE/PE link

–  NO need for route redistribution

–  NO no need for default or static routes

7

PE/CE

BGP Complexity

Carrier Involvement

Multiple Redistribution

Public & Unsecure

EIGRP OTP

EIGRP Simplicity

Carrier Independence

Zero Redistribution

Private & Secure


OTP – Enterprise Benefits

EIGRP Support for WAN Transparency §  EIGRP OTP Enterprise benefits

–  Simple configuration and deployment for both IPv4 and IPv6 –  Single routing protocol solution, convergence is not depending on Service Provider

–  Routes are carried over the Service Provider’s network, not though it –  No artificial limitation on number of routes being exchanged between sites

–  Support for multiple MPLS VPN backbone connections –  Support connections not part of the MPLS VPN backbone (“backdoor” links)

–  Only the CE needs to be upgraded –  Works with both traditional managed and non-managed internet connections

–  Compliments an L3 Any-to-Any architecture (optional hair pinning of traffic)

8


OTP – Service Provider Benefits

EIGRP Support for WAN Transparency §  EIGRP OTP Service Provider benefits

–  Allow customers to segment their network using an MPLS VPN backbone –  All user traffic appears and unicast IP data packets –  No routing protocol is needed on CE to PE link –  Customer routes are NOT carried in MPLS VPN backbone –  Customer route flaps do not generate BGP convergence events –  Smaller BGP routing tables, smaller memory foot print, lower CPU usage –  No upgrade requirements for PE or any MPLS VPN backbone router –  Multivendor PE support

9


OTP WAN Solution Analysis Overview EIGRP OTP DMVPN / Internet MPLS VPN MPLS+DMVPN

Control Plane EIGRP IGP/BGP + NHRP; LAN IGP

eBGP/iBGP; LAN IGP

IGP/BGP + NHRP; eBGP; LAN IGP

Data Plane LISP mGRE IP IP + mGRE

Privacy GETVPN IPSec over mGRE GETVPN GETVPN + DMVPN

Routing Policies EIGRP, EIGRP Stub EIGRP Stub Redistribution and route filtering

EIGRP Stub, Redistribution, filtering, Multiple AS

Network Virtualization VRF/EVN to LISP multi-tenancy

DMVPN VRF-Lite; MPLS or DMVPN

Multi-VRF CEs and multiple IP VPNs

Multi-VRF CEs and DMVPN VRF-Lite

Convergence Branch/Hub

Branch Fast; Hub – Fast

Branch Fast; Hub - Fast

Branch / Hub carrier dependent

Carrier and DMVPN hub dependent

Multicast Support Planned PIM Hub-n-Spoke PIM MVPN MVPN + DMVPN Hub-n-Spoke

Provider Dependence

No No Yes Yes/No

10


OTP – How it Works

§  CE routers exchange information using unicast packets –  Internal site routes are passed “Over the ToP” to other Sites –  Routes are not redistributed into the WAN

§  Unicast packets are sourced FROM the public interface –  No static routes are needed –  No default routes are needed

§  Data packet delivery is accomplished using LISP to encapsulate site-to-site traffic

11

Service Provider MPLS VPN

EIGRP AS 4453

CE-1 CE-2

EIGRP AS 4453


OTP Configuration Overview

§ Checking for support (IOS/XR, ISR): show eigrp plugins detail

§ Configuration used by OTP 1.  configure terminal 2.  router eigrp virtual-name 3.  address-family ipv4 autonomous-system as-number 4.  af-interface interface-type interface-number 5.  no split-horizon 6.  no next-hop-self 7.  exit-af-interface 8.  neighbor {ip-address | ipv6-address} interface-type interface-number [remote maximum-hops [lisp-encap [lisp-id]]] 9.  end

§ Cisco Configuration Guide: http://www.cisco.com/en/US/docs/ios-xml/ios/iproute_eigrp/configuration/xe-3s/ire-eigrp-over-the-top.html

13

CE4#show eigrp plugins detailed !EIGRP feature plugins:::! eigrp-release : 15.00.00 : Portable EIGRP Release ! : 4.00.00 : Source Component Release(dev15)! + HMAC-SHA-256 Authentication! parser : 2.02.00 : EIGRP Parser Support ! igrp2 : 2.00.00 : Reliable Transport/Dual Database ! + Wide Metrics! bfd : 2.00.00 : BFD Platform Support ! mtr : 1.00.01 : Multi-Topology Routing(MTR) ! eigrp-pfr : 1.00.01 : Performance Routing Support ! + IPv4 PFR! EVN/vNets : 1.00.00 : Easy Virtual Network (EVN/vNets) ! + IPv4 EVN/vNets! ipv4-af : 2.01.01 : Routing Protocol Support ! + Dynamic Remote Neighbors! ipv6-af : 1.02.00 : Service Distribution Support ! + Dynamic Remote Neighbors!

Point to Point Peering


DATA LISP

OTP – Deployment Point-to-Point

§  Control Plane peering is accomplished with EIGRP “neighbor” statement –  CE-1 sends unicast packets to CE-2’s public address (172.16.2.2) –  CE-2 sends unicast packets to CE-1’s public address (172.16.1.1)

§  Data Plane packet delivery is accomplished with LISP encapsulation –  Encapsulation happens on the CE routers

15


EIGRP AS 4453

EIGRP AS 4453

Hello Hello

interface Ethernet0/2 ip address 172.16.1.1 255.255.255.0 ! router eigrp ROCKS address-family ipv4 unicast auto 4453 neighbor 172.16.2.2 Ethernet0/2 remote 10 lisp-encap ...

interface Ethernet0/2 ip address 172.16.2.2 255.255.255.0 ! router eigrp ROCKS address-family ipv4 unicast auto 4453 neighbor 172.16.1.1 Ethernet0/2 remote 10 lisp-encap ...

DATA DATA CE-1 CE-2

Route Reflector Peering


OTP – Deployment Point to Multi-Point – Multiple Branch Sites

§ Use EIGRP Route-Reflectors when setting up multiple branches

17

router eigrp ROCKS address-family ipv4 unicast auto 4453 remote-neighbors source Serial 0/0 unicast-listen lisp-encap af-interface serial 0/0 no split-horizon exit-af-interface ...

RR

EIGRP AS 4453

= DP

= CP

§  Chose one of the CE routers to function as Route Reflector (RR)

§  Purpose of the Route Reflector is to ‘reflect’, or advertise routes received to other CE routers

§  Control plane is deployed in a “Hub-and-spoke” topology

§  Data from CE routers will ‘hairpin’ though RR Q  : In the example, if CE-1 advertises a route to

the RR, will the Route Reflector propagate it to CE-2 and CE-3?

A  : Only if split horizon is disabled on the interface!

EIGRP AS 4453 EIGRP

AS 4453

© 2013 Cisco and/or its affiliates. All rights reserved. Presentation_ID Cisco Public 18

RR

EIGRP AS 4453

= DP

= CP

EIGRP AS 4453 EIGRP

AS 4453

OTP – Deployment Point to Multi-Point – Adding Branch Sites

§  EIGRP Route Reflector simplifies adding additional branches

§  Configure the new CE to point to the RR §  Adding additional CE routers does not

require a change to the configuration of the Route Reflector (RR)

address-family ipv4 unicast auto 4453 neighbor 172.16.1.1 Serial 0/2 remote 10 lisp-encap ... exit-address-family

EIGRP AS 4453

18 18


OTP – Deployment Point to Multi-Point – Any-to-Any Data

§  Any-to-Any data is accomplished using 3rd Party Next hop support

19

§  Each CE normally shows the Route Reflector (RR) as the next hop, and data will ‘hairpin‘ though the RR to get to other sites

§  Configuring “no next-hop-self” on the Route Reflector will cause the original next-hop to be preserved when route updates are sent

§  When a CE gets an update with a non-zero next-hop address install it in the RIB

§  Traffic will be forwarded directly to the remote CE will be sent to that next-hop

router eigrp ROCKS address-family ipv4 unicast auto 4453 remote-neighbors source Serial 0/0 unicast-listen lisp-encap af-interface serial 0/0 no split-horizon no next-hop-self exit-af-interface ...

EIGRP-IPv4 VR(ROCKS) Topology Table for AS(4453)/ID(10.1.0.1) .... P 10.1.1.0/24, 1 successors via 10.1.2.1

19

EIGRP AS 4453

= DP

= CP

EIGRP AS 4453 EIGRP

AS 4453

RR

Backdoor Links


OTP – Backdoor Links

§  Use MPLS-VPN core for the site-to-site connectivity §  Use “back-door” link in case of a failure (these are usually are low-speed links)

21

§  EIGRP end-to-end ensures -  Prefixes appear as native routes in across ISP network -  Internal routes show up as internal

§  Normal path selection using ‘delay’ on interface to influence path selection

Remote Office

Headquarters


Backdoor Link

CE

CE

C2 C1

EIGRP-OTP Session


OTP – Backdoor Links

22

interface Serial0/0 delay 40000 . . .

interface Serial0/0 delay 40000 . . .

Remote Office

Headquarters


Backdoor Link

CE

CE

C2 C1

§  Convergence events in Customer’s network: -  Are not depend on MPLS convergence -  Do not impact the MPLS Core

§  Routing works as expected in event of outage via Service Provider

OTP Deployment Considerations


OTP – Deployment Route Reflector – Redundancy

24

OTP Dual Hub, Dual Service Provider §  OTP is able to handle Dual Hub and Dual Service Provider

connections §  Stub Co-Existence Allows for Dual Hubs

–  Support for dual Hubs for redundancy for load-balancing –  Spoke to spoke load balancing and redundancy

§  Equal Cost MultiPath (15.2(3)T, 15.2(1)S) –  Destination network is reachable via more than one peer on the same

interface, the ip next-hop needs to be preserved over both paths §  Add-path (15.3(1)S)

–  Spoke site has multiple spoke routers and want to be able to load-balance spoke-spoke tunnels going into this spoke site

–  Up to 4 additional Nexthops addresses (5 total)

Hub 1

Service Provider 1

Service Provider 2

Hub 2

Site1 Site2


OTP – Deployment Route Reflector – Scaling

EIGRP Hub and Spoke (STUBs) §  EIGRP offers the best scaling performance of all IGPs §  If these spokes are remote sites, they have two

connections for resiliency, not so they can transit traffic between A and B

§  A should never use the spokes as a path to anything, so there’s no reason to learn about, or query for, routes through these spokes

§  What happens when a route or link is lost? →  EIGRP query's ALL neighbors →  Each neighbors using it to reach the destination will also

query their neighbors

B A

Don’t Use These Paths

RR-2 RR-1

10.1

.1.0

/24

25



§  Marking sites as “stubs” allows them to signal the Route Reflector they are not valid transit paths

§  The Route Reflector will not query other sites which are marked as “stubs”, reducing the total number of queries

§  The “stub” keyword can not be used of the remote sites contains complex topologies (multiple routes)

§  The back-up routes can be deployed at remotes using “leak-maps”

Router eigrp ROCKS address-family ipv4 unicast auto 4453 neighbor 172.16.1.2 Serial 0/2 remote 10 lisp-encap eigrp stub ...

26

B A RR-2 RR-1

10.1

.1.0

/24



§  Most EIGRP Neighbors Recommended –  Maximum of 500 deployed in live, working networks –  2500 (Stubs) is the largest number ever tested in a lab environment

§  Key Strategy for achieving scalability is design! –  Minimize advertisements between sites –  Use summaries with static summary metric option –  Stubs to create a hub and spoke environments –  Use any-to-any traffic to reduce bandwidth and load on Route Reflector –  Use add-path feature to better utilize redundancy

27


OTP – Deployment Route Reflector – Security

Hash-based Message Authentication Code (HMAC) §  EIGRP offers Secure Hash Algorithms SHA2-256 bit Algorithms §  The addition of SHA2-256 HMAC authentication to EIGRP packets ensures that

your routers only accept routing updates from other routers that know the same pre-shared key.

§  This prevents someone from purposely or accidentally adding another router to the network and causing a problem.

§  The SHA2 key is a concatenation of the user-configured shared secret key along with the IPv4/IPv6 address from which this particular packet is sent. This prevents Hello Packet DOS replay attacks with a spoofed source address.

ü  Simpler configuration mode using a common ‘password’

ü  Keychain support when additional security is needed

RR

CE1 CE2

28


•  Simple configuration using only one password

•  Additional security can be added with key-chains

router eigrp DC012-md5 address-family ipv4 auto 4453 af-interface default authentication key-chain DC012-CHAIN exit-af-interface af-interface Ethernet0 authentication mode hmac-sha-256 ADMIN exit-af-interface af-interface Ethernet1 authentication mode hmac-sha-256 CAMPAS exit-af-interface af-interface Ethernet2 authentication mode hmac-sha-256 LAB authentication key-chain DC012-LAB exit-af-interface!

router eigrp ROCKS address-family ipv4 auto 4453 af-interface default authentication mode hmac-sha-256 my-password exit-af-interface!

key chain DC012-CHAIN key 1 key-string securetraffic ! router eigrp ROCKS address-family ipv4 auto 4453 af-interface default authentication mode hmac-sha-256 my-password authentication key-chain DC012-CHAIN exit-af-interface!

•  Interface inheritance can simplify configuration


29



30

Group Encrypted Transport VPN (GETVPN) Encryption §  OTP offers secure site to site encryption using GETVPN §  The addition of GETVPN ensures that data and control plane

traffic sent from site to site is not decodable to outside sources

§  IPsec or GETVPN can be used

-  Apply crypto maps to either public interface, or the LISP0 (virtual Interface)

-  EIGRP forms peers over the ‘public’ interface, so control traffic will be encrypted

§  Split encryption can be accomplished by peering to a loopback

-  Applying encryption to the loopback

-  Default traffic would be forward to the physical interface un-encrypted

EIGRP

GETVPN

Public Interface

Inside Interface

Default Traffic

Site to Site

Traffic

LISP0

RIB

Route Updates

Case Study


The Acme Corporation

Requirements: –  Fast convergence (<1s if possible) –  Direct Spoke-to-spoke traffic –  1600+ sites across four countries –  Active/active load balancing –  Encryption across WAN

Nice to have: –  Easy provisioning § No config changes on hubs as new sites are added §  Zero touch deployment of branch wan router (CE)

–  Provider flexibility § Multiple providers in each country § Easy migration between providers § No routing exchange of internal addresses



33

Corporate Backbone

France

… …

MPLS VPN MPLS

VPN

Sweden

… …

MPLS VPN MPLS

VPN

England

… …

MPLS VPN

MPLS VPN

USA

… …

MPLS VPN

MPLS VPN


The Acme Corporation Route Exchange

34

Spokes

WAN Hubs 2 x ASR1000

… …

MPLS VPN for Branches and ATMs

B


A

RR RR


The Acme Corporation WAN Security with GET VPN

35

KEY SERVER

MEMBER MEMBER

WAN Services 2 x 3945E

WAN Hubs 2 x ASR1000

MEMBERS

… …

RR RR


B


A



– IGP speeds via end-to-end EIGRP solution – Use of no nexthop-self on RR – Up to 500 EIGRP spokes per RR – Ability to add 4 additional ECMP via addpath – GET VPN

– Route Reflectors – Route Reflectors – Multiple neighbor configs supported – Built into OTP – Built into OTP

Requirements: –  Fast convergence (<1s if possible) –  Direct Spoke-to-spoke traffic –  1600+ sites across four countries –  Active/active load balancing –  Encryption across WAN

Nice to have: –  Easy provisioning § No config changes on hubs as new sites are added §  Zero touch deployment of branch wan router (CE)

–  Provider flexibility § Multiple providers in each country § Easy migration between providers § No routing exchange of internal addresses


Additional Information § OTP Availability

–  ASR 1000 Series – IOS-XE 3.10 ISR, ISR G2, 7200 Series – IOS 15.4(3)

§ For more information on EIGRP visit: – EIGRP

§  http://www.cisco.com/go/eigrp – Open EIGRP (IETF Draft):

§  http://tools.ietf.org/html/draft-savage-eigrp

– OTP: §  http://www.cisco.com/en/US/docs/ios-xml/ios/iproute_eigrp/configuration/xe-3s/ire-eigrp-over-the-

top.html §  https://techzone.cisco.com/t5/EIGRP/EIGRP-OTP-Over-the-ToP/ta-p/317994

– GETVPN: §  http://www.cisco.com/en/US/prod/collateral/vpndevc/ps6525/ps9370/ps7180/

GETVPN_DIG_version_1_0_External.pdf


•  Thank you! •  Please complete the post-event survey •  Join us for upcoming webinars:

Register: www.cisco.com/go/techadvantage Follow us @GetYourBuildOn

wan virtualization using over-the-top (otp) techadvantage webinar

Technology

cisco andor

otp otp

cisco public5

cisco public6

cisco public7

cisco public10

service provider routes

pece issues service