Over the Top Routing Protocols Joe Harris Consulting

Agenda • • • Overview of Current Solutions How OTP works Peering over the

Overview of Current WAN Solution PE-CE Overview PE 1 MPLS VPN Cloud PE 2

Overview of Current WAN Solution PE-CE Issues for the Service Provider • Service Provider

Overview of Current WAN Solution PE-CE Issues for the Enterprise • Managed services is

Overview of Current WAN Solution PE-CE Issues with Backdoor Links • Route redistribution adds

Problem Solution Customer Site 1 Service Provider MPLS VPN = Control Plane = Data

WAN Virtualization using OTP EIGRP OTP supports transparent CE to CE Routing • EIGRP

WAN Virtualization using OTP Service Provider Benefits • No additional routing protocol to administer

WAN Virtualization using OTP Enterprise Benefits • Single routing protocol solution – Simple configuration

WAN Solution Overview EIGRP OTP DMVPN / Internet MPLS VPN MPLS+DMVPN Provider Dependence No

OTP – How it Works • CE Routers have ‘private’ and ‘public’ interfaces &

OTP – How it Works EIGRP, LISP, and RIB – Oh My! • EIGRP

OTP – Data Plane LISP Data Encapsulation • Why use LISP to encapsulate the

OTP – Data Plane LISP Data Encapsulation Properties • Path MTU needs to be

OTP – Data Plane LISP Header Format (IPv 4 example) LISP 0 Internal Interface

OTP – How it Works Modes of Deployment • EIGRP OTP is deployed in

Peering over the WAN • Remote Routers • Route Reflectors • Redundant Remote Routers

Remote Routers Point to Point Peers • Control Plane peering is accomplished with EIGRP

Remote Routers Remote Peers CE 2# 00: 01: 57: %DUAL-5 -NBRCHANGE: EIGRP-IPv 4 4453:

Remote Routers Remote Peers address properties • In order to form peers, the Public

CSCuj 68811: Route Reflectors 15. 4(1. 16)S 0. 2, 15. 4(1. 16)S 0. 3

Route Reflectors Point to Multi-Point – Adding Branch Sites • EIGRP Route Reflector simplifies

Route Reflectors router eigrp ROCKS address-family ipv 4 auto 4453 af-interface Serial 0/0 no

Redundant Remote Routers Multiple Next Hops • In an OTP setup, an RR can

Redundant Remote Routers Multiple Next Hops • While this isn't a route propagation problem,

Redundant Remote Routers Solution: Add-Path • To avoid this situation and enable Remotes to

Redundant Route Reflectors Adding second RR • Adding a second Route Reflector does not

Redundant Route Reflectors Exchanging routes between RR’s • If the Route Reflectors are in

Redundant Route Reflectors Support for Multiple Providers • Support for additional Service Providers is

Deployment Considerations • Route Filtering • Backdoor Links © 2014 Cisco and/or its affiliates.

Route Filtering Limiting leaking of public routes into the LAN • When you setup

Route Filtering Limiting leaking of public routes into the LAN • Looking on the

Route Filtering Public routes subnets in the LAN can result in recursion issues •

Route Filtering Solution – filter public routes from being reached via the LAN •

Deployment Considerations Site to Site - Backdoor Links • The use of “back-door” links

Case Study © 2014 Cisco and/or its affiliates. All rights reserved. Cisco Public 43

The Acme Corporation Requirements: – Fast convergence (<1 s if possible) – Direct Spoke-to-spoke

The Acme Corporation Sweden … … … MPLS VPN … France MPLS VPN Corporate

The Acme Corporation Route Exchange RR RR WAN Hubs 2 x ASR 1000 MPLS

The Acme Corporation WAN Security with GET VPN KEY SERVER WAN Services 2 x

Summary: What Have We Learned? • WAN deployments are greatly simplified with OTP •

For more Information on OTP • EIGRP OTP: – http: //www. cisco. com/en/US/docs/ios-xml/ios/iproute_eigrp/configuration/xe-3 s/ire-eigrpover-the-top.

Slides: 52

Download presentation

Over the Top Routing Protocols Joe Harris Consulting Systems Engineer

Overview of Current WAN Solution PE-CE Overview PE 1 MPLS VPN Cloud PE 2 CE 1 CE 2 Backdoor Link Site 1 Site 2 • Allow customers to segment their network using an MPLS VPN backbone • Impose little requirements or no restrictions on customer networks – Customer sites may be same or different Autonomous Systems – Customer sites may consist of multiple connections to the MPLS VPN backbone – Customer sites may consist of one or more connections not part of the MPLS VPN backbone (“backdoor” links) © 2014 Cisco and/or its affiliates. All rights reserved. Cisco Public 3

Overview of Current WAN Solution PE-CE Issues for the Service Provider • Service Provider must redistribute and carry Enterprise routes via MP-i. BGP; – Route flaps within sites results in BGP convergence events – Route metric changes results in new extended communities flooded into the core • Either EIGRP or e. BGP must be run between the PE/CE – Provider had to have trained staff on hand to manage PE/CE Link – Provider’s often prefer vender flexibility • Provider must be be involved with deployment changes in enterprise customer’s network © 2014 Cisco and/or its affiliates. All rights reserved. Cisco Public 4 PE 1 CE 1 MPLS VPN Core Site 1 Site 2 PE 2 CE 2

Overview of Current WAN Solution PE-CE Issues for the Enterprise • Managed services is required, even if not needed – Provider often limits number of routes being redistributed • Enterprise and Service Provider must co-support deployment – Control of traffic flow using multiple providers is problematic – Changing providers results in migration issues • Service Provider route propagation impacts site to site convergence PE 1 • Redistribution at the edge leads to additional complexity and operational costs for an Enterprise. • Carrier involvement restricts network design change and evolution © 2014 Cisco and/or its affiliates. All rights reserved. Cisco Public 5 CE 1 MPLS VPN Core Site 1 Site 2 PE 2 CE 2

Overview of Current WAN Solution 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 So. O (route) tagging must be used to prevent count-to-infinity issues due to BGP’s slower convergence and all routers between CE an Backdoor must have support for So. O PE 1 MPLS VPN Cloud PE 2 CE 1 CE 1 Site 2 r Link o Backdo C 3 © 2014 Cisco and/or its affiliates. All rights reserved. Cisco Public 6 C 4

Problem Solution Customer Site 1 Service Provider MPLS VPN = Control Plane = Data Plane Customer Site 2 • EIGRP OTP provides a single end-to-end EIGRP routing domain transparent to the underlying Public or Private WAN transport. • EIGRP OTP can hide the complexity of BGP-4 or other routing protocol used as their interface to the network transport provider. • Reduces L 3 -VPN costs by reducing the required customer routes in the VPNv 4/v 6 address family. © 2014 Cisco and/or its affiliates. All rights reserved. Cisco Public

WAN Virtualization using OTP EIGRP OTP supports transparent CE to CE Routing • EIGRP “end-to-end” solution with: ü NO special requirement on Service Provider BGP ü NO special requirement on Enterprise Complexity EIGRP Simplicity ü NO routing protocol on CE/PE link ü NO need for route redistribution Carrier Independence Carrier Involvement ü NO no need for default or static routes PE / CE EIGRP OTP Zero Redistribution Multiple Redistribution Availability - ISR 4451 -X, ASR 1 K Series – IOS-XE 3. 10 ISR, ISR G 2, 7200 Series – IOS 15. 4(1)T © 2014 Cisco and/or its affiliates. All rights reserved. Cisco Public & Unsecure 8 Private & Secure

WAN Virtualization using OTP Service Provider Benefits • No additional routing protocol to administer – No routing protocol is needed on CE to PE link – All user traffic appears and unicast IP data packets • Limit impact on Service Providers Network – 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 • Works with existing PE equipment – Multivendor PE support – No upgrade requirements for PE or any MPLS VPN backbone router © 2014 Cisco and/or its affiliates. All rights reserved. Cisco Public 9

WAN Virtualization using OTP Enterprise Benefits • Single routing protocol solution – Simple configuration and deployment for both IPv 4 and IPv 6 – 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 L 3 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) © 2014 Cisco and/or its affiliates. All rights reserved. Cisco Public 10

WAN Solution Overview EIGRP OTP DMVPN / Internet MPLS VPN MPLS+DMVPN Provider Dependence No No Yes/No Control Plane EIGRP IGP/BGP + NHRP; LAN IGP e. BGP/i. BGP; LAN IGP/BGP + NHRP; e. BGP; LAN IGP Data Plane LISP m. GRE IP IP + m. GRE Privacy GETVPN IPSec over m. GRE GETVPN + DMVPN Routing Policies EIGRP, EIGRP Stub Redistribution and route filtering EIGRP Stub, Redistribution, filtering, Multiple AS Network Virtualization VRF/EVN to LISP multitenancy DMVPN VRF-Lite; MPLS o DMVPN Multi-VRF CEs and multiple Multi-VRF Ces and IP VPNs 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 XE 3. 14 PIM Hub-n-Spoke PIM MVPN + DMVPN Hub-n. Spoke VRF Support Planned XE 3. 15 Yes No No © 2014 Cisco and/or its affiliates. All rights reserved. Cisco Public 11

OTP – How it Works • CE Routers have ‘private’ and ‘public’ interfaces & routers exchange information using unicast packets – Private interfaces use addresses that are part of the Enterprise network – Public interfaces use addresses that are part of the Service Providers network – For OTP neighbors to form, the Public interface must also be included in the EIGRP topology database (covered by the “network” command in IPv 4) • Packets are sourced from/to the public interface address eliminates the need for static routes – EIGRP packets which are normally sent via multicast (Hello, Update, etc. . ) are sent unicast via the public interface – Site-to-site traffic is encapsulated using LISP and sent unicast from/to the public interface address © 2014 Cisco and/or its affiliates. All rights reserved. Cisco Public 12

OTP – How it Works EIGRP, LISP, and RIB – Oh My! • EIGRP creates the LISP 0 interface, and starts sending Hello packets to remote site via the Public interface • Once neighborship is formed, EIGRP sends and receives routes from the peer, installing the routes into the RIB with the nexthop Inside Interface interface LISP 0 • Traffic that arrives on the router destined for the remote side, is first sent to LISP 0 • LISP encaps the traffic and then sends it to the Public interface © 2014 Cisco and/or its affiliates. All rights reserved. Cisco Public 13 EIGRP Route Updates RIB Site to Site Traffic LISP 0 Default Traffic Public Interface

OTP – Data Plane LISP Data Encapsulation • Why use LISP to encapsulate the data as it traverses the WAN? • Its “stateless” tunneling, so it; – – Requires NO tunnels to configure or manage Is transparent to the endpoints and to the IP core Supports both hair-pin and site-to-site traffic Supports both IPv 4 and IPv 6 traffic • Provides an overlay solution that enables transparent extension of network across WAN – IP-based for excellent transport independence – Service provider picks optimal traffic path for site to site data – Supports multicast and VLANs to allow for future enhancements © 2014 Cisco and/or its affiliates. All rights reserved. Cisco Public 14

OTP – Data Plane LISP Data Encapsulation Properties • Path MTU needs to be considered when deploying OTP – LISP encapsulation adds 36 bytes (20 IP + 8 UDP + 8 LISP) for IPv 4 (56 bytes for IPv 6) – This could be significant for small packets (e. g. , a Vo. IP packet) • LISP handles packet fragmentation – If the DF bit is set, it will generate an ICMP Destination Unreachable message • LISP does not handle packet reassembly – As a consequence, it is required to adjust the MTU to ensure the control plan does not fragment – Best practice - set the MTU is set to to 1444 (or lower) bytes. © 2014 Cisco and/or its affiliates. All rights reserved. Cisco Public 15

OTP – How it Works Modes of Deployment • EIGRP OTP is deployed in one of two ways • Remote Routers – Used for configuring a router to peer with one specific neighbor – Forms a full mesh topology – Configured with the command neighbor [ipv 4/v 6 address] [interface] remote [max-hops] lisp-encap [lisp-id] • Route Reflectors – Used to configure a router as a ‘hub’ – Forms a Hub and Spoke topology – Configured with the command remote-neighbors source [interface] unicast-listen lisp-encap © 2014 Cisco and/or its affiliates. All rights reserved. Cisco Public 17

Remote Routers Point to Point Peers • Control Plane peering is accomplished with EIGRP “neighbor” statement – CE-1 sends unicast packets to CE-2’s public address (192. 168. 2. 2) – CE-2 sends unicast packets to CE-1’s public address (192. 168. 1. 1) router eigrp ROCKS address-family ipv 4 unicast auto 4453 neighbor 192. 168. 2. 2 Serial 1/0 remote 100 lisp-encap . . . DATA LISP DATA Hello CE-1 EIGRP AS 4453 router eigrp ROCKS address-family ipv 4 unicast auto 4453 neighbor 192. 168. 1. 1 Serial 1/0 remote 100 lisp-encap . . . Service Provider MPLS VPN Hello DATA CE-2 EIGRP AS 4453 • Data Plane packet delivery is accomplished with LISP encapsulation © 2014 Cisco and/or its affiliates. All rights reserved. Cisco Public 19

Remote Routers Remote Peers CE 2# 00: 01: 57: %DUAL-5 -NBRCHANGE: EIGRP-IPv 4 4453: Neighbor 192. 168. 2. 2 (Serial 1/0) is up: new adjacency CE 2#show eigrp address-family ipv 4 neighbors detail EIGRP-IPv 4 VR(ROCKS) Address-Family Neighbors for AS(4453) H Address Interface Hold Uptime SRTT RTO Q Seq (sec) (ms) Cnt Num 0 192. 168. 2. 2 Se 1/0 13 00: 01: 15 171 1026 0 21 Remote Static neighbor (static multihop) (LISP Encap) Version 16. 0/2. 0, Retrans: 0, Retries: 0, Prefixes: 5 Topology-ids from peer - 0 Max Nbrs: 0, Current Nbrs: 0 CE 2# © 2014 Cisco and/or its affiliates. All rights reserved. Cisco Public 20

Remote Routers Remote Peers address properties • In order to form peers, the Public interface must be enabled for EIGRP • For IPv 4, you must include a ‘network’ statement to cover the public interface • This does not mean the ip address of the remote peer has to match the network/mask of the public interface Serial 1/0 • The interface is used to send packets, so the IP address of the remote peer just has to be reachable via the WAN © 2014 Cisco and/or its affiliates. All rights reserved. Cisco Public description Service Provider ip address 172. 16. 0. 1 255. 0 ! router eigrp ROCKS ! address-family ipv 4 unicast auto 4453 ! topology base exit-af-topology neighbor 192. 168. 2. 2 Serial 1/0 remote 100 lisp-encap network 172. 16. 0. 0. 0. 255 network 10. 1. 0. 0. 255 exit-address-family 21

CSCuj 68811: Route Reflectors 15. 4(1. 16)S 0. 2, 15. 4(1. 16)S 0. 3 15. 4(1. 16)S 0. 4, 15. 4(2. 1)S 15. 4(2. 2)S Point to Multi-Point – Multiple Branch Sites • EIGRP Route-Reflectors simplifies setting up multiple branches router eigrp ROCKS address-family ipv 4 unicast auto 4453 remote-neighbors source Serial 0/0 unicast-listen lisp-encap network 10. 0 • 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 RR = DP = CP • Control plane is deployed in a “Hub-and-spoke” topology Site 1 Site 3 © 2014 Cisco and/or its affiliates. All rights reserved. Cisco Public Site 2 23

CSCuj 68811: Route Reflectors 15. 4(1. 16)S 0. 2, 15. 4(1. 16)S 0. 3 15. 4(1. 16)S 0. 4, 15. 4(2. 1)S 15. 4(2. 2)S Point to Multi-Point – Multiple Branch Sites • Question: In the example, if CE in Site 1 advertises a route to the Route Reflector, will the route propagate to other CE routers? router eigrp ROCKS address-family ipv 4 unicast auto 4453 remote-neighbors source Serial 0/0 unicast-listen lisp-encap network 10. 0 af-interface serial 0/0 no split-horizon exit-af-interface • Answer: No! – The split horizon rule prohibits a router from advertising a route through an interface that it uses to reach the destination. • Solution: – In order for the route to be ‘reflected’ to the other sites, use the Site 3 no split-horizon command on the public interface © 2014 Cisco and/or its affiliates. All rights reserved. Cisco Public Site 1 Site 2 24

Route Reflectors Point to Multi-Point – Adding Branch Sites • EIGRP Route Reflector simplifies adding additional branches address-family ipv 4 unicast auto 4453 neighbor 192. 168. 1. 1 Serial 0/2 remote 100 lisp-encap network 10. 0 network 192. 168. 0. 0. 255 . . . Site 4 RR = CP • Configure the new CE to point to the RR • New CE and RR exchange routes, and RR sends new routes to other CEs • Adding additional CE routers does not require changes to configuration of the Route Reflector Site 3 © 2014 Cisco and/or its affiliates. All rights reserved. Cisco Public = DP Site 1 Site 2 25 25

CSCuj 68811: Route Reflectors 15. 4(1. 16)S 0. 2, 15. 4(1. 16)S 0. 3 15. 4(1. 16)S 0. 4, 15. 4(2. 1)S 15. 4(2. 2)S Point to Multi-Point – Any-to-Any Data • Each CE normally shows the Route Reflector (RR) as the next hop – Data will ‘hairpin‘ though the RR to get to other sites – Useful for applying Policy and filtering traffic – Will increase bandwidth requirements for the Route Reflector • What if I want to send traffic directly from site to site? RR = DP = CP • The solution: 3 rd Party Nexthops Site 1 Site 3 © 2014 Cisco and/or its affiliates. All rights reserved. Cisco Public Site 2 26 26

Route Reflectors router eigrp ROCKS address-family ipv 4 auto 4453 af-interface Serial 0/0 no next-hop-self 3 rd Party Nexthops • Normally the Route Reflector would send the nexthop as 0. 0 which tells CE 1 and CE 2 to use it to reach the destination RR • When “no next-hop-self” configured, the RR preserves the next hop of the peer that sent it the route • When CE 1 and CE 2 receives an update from the RR, they install the route in the RIB with the supplied nexthop • Traffic leaving CE 1 goes directly to router CE 2 EIGRP-IPv 4 VR(ROCKS) Topology Table for AS(4453)/ID(10. 0. 0. 1). . P 10. 1. 1. 0/24, 1 successors via 192. 168. 1. 3 © 2014 Cisco and/or its affiliates. All rights reserved. Cisco Public 27 . 2 . 1 . 3 CE 1 CE 2 10. 1. 1. 0/24

Redundant Remote Routers Multiple Next Hops • In an OTP setup, an RR can learn two or more equal-cost paths to a site. 10. 2. 0. 0 [90/18600] via 192. 168. 1. 5, LISP 0 via 192. 168. 1. 6, LISP 0 Site 1 • However, the RR router will only advertise one of the paths to other spokes in the OTP network. RR 10. 2. 0. 0 [90/32600] via 192. 168. 1. 5 Site 2 • Implication: – Site to Site traffic will only be sent to one router – Sites are not able to leverage multi-router setups . 6 . 5 Site 3 10. 2. 0. 0/24 © 2014 Cisco and/or its affiliates. All rights reserved. Cisco Public 29

Redundant Remote Routers Multiple Next Hops • While this isn't a route propagation problem, per se, it's still a situation that may take you by surprise and therefore may be useful to understand • One of the designs being implemented with OTP uses multiple paths from the hub to reach spoke subnets. This could be two paths to the same spoke or through two spokes (as shown on the previous slide) • The problem is that EIGRP still uses normal distance vector rules and sends updates based on the topology table entry. • Even if there are two equal cost paths, EIGRP sends updates based on the top entry, even though there are two paths available. © 2014 Cisco and/or its affiliates. All rights reserved. Cisco Public 30

Redundant Remote Routers Solution: Add-Path • To avoid this situation and enable Remotes to use all paths, configure the “add-path” option on the RR (hub) Site 1 RR 10. 2. 0. 0 [90/32600] via 192. 168. 1. 5 via 192. 168. 1. 6 • Add Path Support enables the Route Reflector to advertise multiple best paths • Up to 4 additional Nexthops addresses (5 total) router eigrp ROCKS address-family [ipv 4 or ipv 6] unicast auto 4453 af-interface serial 0/0 no split-horizon no next-hop-self add-path 1 exit-af-interface remote-neighbors source Serial 0/0 unicast-listen lisp-encap © 2014 Cisco and/or its affiliates. All rights reserved. Site 2. 6 . 5 Site 3 10. 2. 0. 0/24 Cisco Public 31

Redundant Route Reflectors Adding second RR • Adding a second Route Reflector does not change the original Route Reflector’s, configuration • On the Remote Routers, add the new remote neighbor configuration for the new Route Reflector • Remotes do not have to be configure to connect to all Route Reflectors router eigrp ROCKS address-family ipv 4 unicast auto 4453 neighbor 192. 168. 10. 1 Serial 0/1 remote 100 lisp-encap neighbor 192. 168. 20. 2 Serial 0/2 remote 100 lisp-encap . . . © 2014 Cisco and/or its affiliates. All rights reserved. Cisco Public 33 Site 1 RR-2

Redundant Route Reflectors Exchanging routes between RR’s • If the Route Reflectors are in different sites, you may want to exchange routing information between the Route Reflectors • You might be tempted to setup a remote neighbor; RR-1 router eigrp ROCKS address-family ipv 4 unicast auto 4453 remote-neighbors source Serial 0/0 unicast-listen lisp-encap neighbor 192. 168. 2. 2 Seral 0/2 remote 100 lisp-encap . . . • Don’t! This is not supported. • Instead, consider adding a GRE tunnel between the Route Reflectors, and share routing information © 2014 Cisco and/or its affiliates. All rights reserved. Cisco Public Site 1 34 Site 2 RR-2

Redundant Route Reflectors Support for Multiple Providers • Support for additional Service Providers is also possible ISP 1 • Choose a Route Reflector per Service Provider to ensure each CE has reachability to other sites • Normal EIGRP metric selection and costing will influence path selection RR-1 Site 2 RR-2 ISP 2 © 2014 Cisco and/or its affiliates. All rights reserved. Cisco Public 35 Site 3

Route Filtering Limiting leaking of public routes into the LAN • When you setup an OTP peer, you must add a network statement covering the public interface address-family ipv 4 unicast auto 4453 neighbor 192. 168. 1. 1 Serial 0 /2 remote 100 lisp-encap network 192. 168. 0. 0. 255 network 10. 2. 0. 0. 255 . . . • This means the public network will show up in the EIGRP topology database; – EIGRP will split-horizon the local public address out the public interface – EIGRP will advertise to EIGRP neighbors on the LAN interface – EIGRP will advertise any public address it receives via the LAN from another neighbor over the WAN • Generally this is not an issue… however… © 2014 Cisco and/or its affiliates. All rights reserved. Cisco Public 37 . 31. 14 . 20. 13 Site 2 10. 2. 0. 0/24

Route Filtering Limiting leaking of public routes into the LAN • Looking on the Route Reflector we see the new peer come up. . CE 1# 02: 24: 05: %DUAL-5 -NBRCHANGE: EIGRP-IPv 4 4453: Neighbor 192. 168. 31. 14 (Serial 1/0) is up: new adjacency 02: 24: 07: %CFC_LISP-5 -ADJ_STACK: Stacking adjacency IP adj out of LISP 0, addr 192. 168. 31. 14 (incomplete) onto other LISP adjacency IP midchain out of LISP 0, addr 192. 168. 20. 13 F 0732 BB 8 forcing drop • But we also see an traffic is being drop due to the LISP encapsulation failure CE 3#ping 192. 168. 31. 14 Type escape sequence to abort. Sending 5, 100 -byte ICMP Echos to 192. 168. 31. 14, timeout is 2 seconds: . . . Success rate is 0 percent (0/5) © 2014 Cisco and/or its affiliates. All rights reserved. Cisco Public 38

Route Filtering Public routes subnets in the LAN can result in recursion issues • From “show ip route” We can see the public address is recursive though another public address – To get to 192. 168. 20. 0/24, the packet needs to be sent to 192. 168. 32. 14 though the LISP interface – To get to 192. 168. 31. 14, the route lookup for 192. 168. 0. 0/24 also goes though LISP interface CE 1#show ip route … D 192. 168. 20. 0/24 [90/114980571] via 192. 168. 31. 14, 00: 29, LISP 0 D 192. 168. 31. 0/24 [90/114980571] via 192. 168. 20. 13, 00: 23: 10, LISP 0 • Peers are not effected by the LISP encap failure as EIGRP sends packets directly to the public interface © 2014 Cisco and/or its affiliates. All rights reserved. Cisco Public 39

Route Filtering Solution – filter public routes from being reached via the LAN • Best practice is to prevent the public networks from entering the LAN by filtering it at each CE • Use “distribute-list out” to prevent public address from leaking into customer site CE 2 b#sh run. . . router eigrp ROCKS ! address-family ipv 4 unicast autonomous-system 4453 ! topology base distribute-list 10 out exit-af-topology neighbor 192. 168. 10. 12 Serial 1/0 remote 100 lisp-encap network 10. 0 network 192. 168. 0. 0. 255 exit-address-family ! access-list 10 deny 192. 168. 0. 0. 255 access-list 10 permit any © 2014 Cisco and/or its affiliates. All rights reserved. Cisco Public 40 . 20. 13 . 31. 14 Site 3 10. 2. 0. 0/24

Deployment Considerations Site to Site - Backdoor Links • The use of “back-door” links for OTP does not require special handling – Path selection determined by setting ‘delay’ on backdoor links Headquarters ISP CE CE C 1 Backdoor Link C 2 Remote Office interface Serial 0/0 delay 40000 . . . • Use “distribute-list out” on CE’s to prevent address from leaking between sites © 2014 Cisco and/or its affiliates. All rights reserved. Cisco Public 42

The Acme Corporation Requirements: – Fast convergence (<1 s 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 © 2014 Cisco and/or its affiliates. All rights reserved. Cisco Public

The Acme Corporation WAN Security with GET VPN KEY SERVER WAN Services 2 x 3945 E MEMBER RR RR WAN Hubs 2 x ASR 1000 MPLS VPN for Branches and ATMs A B … … MEMBERS © 2014 Cisco and/or its affiliates. All rights reserved. Cisco Public 47 MEMBER

The Acme Corporation Requirements: – Fast convergence (<1 s if possible) – Direct Spoke-to-spoke traffic – 1600+ sites across four countries – Active/active load balancing – Encryption across WAN – 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 Nice to have: – Easy provisioning § No config changes on hubs as new sites are added – Route Reflectors § Zero touch deployment of branch wan router (CE) – Route Reflectors – Provider flexibility § Multiple providers in each country – Multiple neighbor configs supported § Easy migration between providers – Built into OTP § No routing exchange of internal addresses – Built into OTP © 2014 Cisco and/or its affiliates. All rights reserved. Cisco Public

Summary: What Have We Learned? • WAN deployments are greatly simplified with OTP • Both the Enterprise and Service Provide benefits from OTP • EIGRP OTP supports both IPv 4 and IPv 6 deployments • EIGRP’s scalability is an important factor in OTP deployment • OTP can work over traditional WAN and LAN networks © 2014 Cisco and/or its affiliates. All rights reserved. Cisco Public 49

For more Information on OTP • EIGRP OTP: – http: //www. cisco. com/en/US/docs/ios-xml/ios/iproute_eigrp/configuration/xe-3 s/ire-eigrpover-the-top. html • Open EIGRP (IETF Draft): – ftp: //ftp. ietf. org/internet-drafts/draft-savage-eigrp-02. txt • OTP OSPF (IETF Draft): – http: //www. ietf. org/staging/draft-white-ospf-otc-01. txt © 2014 Cisco and/or its affiliates. All rights reserved. Cisco Public 50

Related presentations