Over the Top Routing Protocols

Over the Top Routing Protocols Joe HarrisConsulting Systems Engineer

Agenda • Overview of Current Solutions • How OTP works • Peering over the WAN • Considerations • Case Study

Overview of Current WAN Solution PE-CE Overview MPLS VPN Cloud • 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) PE1 PE2 Backdoor Link CE1 CE2 Site 2 Site 1

MPLS VPN Core PE1 PE2 Site 1 Site 2 CE1 CE2 Overview of Current WAN Solution PE-CE Issues for the Service Provider • Service Provider must redistribute and carry Enterprise routes via MP-iBGP; • Route flaps within sites results in BGP convergence events • Route metric changes results in new extended communities flooded into the core • Either EIGRP or eBGP must be run between the PE/CE • Provider had to have trained staff on hand to managePE/CE Link • Provider’s often prefer vender flexibility • Provider must be be involved with deploymentchanges in enterprise customer’s network

MPLS VPN Core PE1 PE2 Site 1 Site 2 CE1 CE2 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 impactssite to site convergence • Redistribution at the edge leads to additional complexity and operational costs for an Enterprise. • Carrier involvement restricts network design change and evolution

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 SoO (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 SoO MPLS VPN Cloud PE1 PE2 C3 C4 CE2 CE2 CE1 CE2 CE1 Site 1 Site 2 Backdoor Link

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 L3-VPN costs by reducing the required customer routes in the VPNv4/v6 address family. Problem Solution = Control Plane = Data Plane Service Provider MPLS VPN Customer Site 1 Customer Site 2

WAN Virtualization using OTP EIGRPOTPsupports transparent CE to CE Routing • EIGRP “end-to-end” 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 • Availability • ISR 4451-X, ASR 1KSeries – IOS-XE 3.10 • ISR, ISR G2, 7200 Series – IOS 15.4(1)T

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

WAN Virtualization using OTP Enterprise Benefits • Single routing protocol solution • Simple configuration and deployment for both IPv4 and IPv6 • Convergence is not depending on Service Provider • Only the CE needs to be upgraded • Routes are carried over the Service Provider’s network, not though it • No artificial limitation on number of routes being exchanged between sites • Convergence speed not impacted by BGP timers • Works with both traditional managed and non-managed internet connections • Compliments an L3 Any-to-Any architecture (optional hair pinning of traffic) • Support for multiple MPLS VPN connections • Support for connections not part of the MPLS VPN (“backdoor” links)

WAN Solution Overview

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 IPv4) • 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

OTP – How it Works EIGRP, LISP, and RIB – Oh My! • EIGRP creates the LISP0 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 interface LISP0 • Traffic that arrives on the router destined for the remote side, is first sent to LISP0 • LISP encaps the traffic and then sends it to the Public interface EIGRP RouteUpdates DefaultTraffic RIB InsideInterface PublicInterface Site to SiteTraffic LISP0

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 IPv4 and IPv6 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

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 IPv4(56 bytes for IPv6) • This could be significant for small packets (e.g., a VoIP 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.

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 • Route Reflectors • Used to configure a router as a ‘hub’ • Forms a Hub and Spoke topology • Configured with the command neighbor [ipv4/v6 address] [interface] remote[max-hops] lisp-encap [lisp-id] • remote-neighbors source [interface]unicast-listen lisp-encap

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

LISP DATA 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) • Data Plane packet delivery is accomplished with LISP encapsulation CE-1 CE-2 router eigrp ROCKS address-family ipv4 unicast auto 4453 neighbor 192.168.2.2 Serial1/0 remote 100 lisp-encap ... router eigrp ROCKS address-family ipv4 unicast auto 4453 neighbor 192.168.1.1 Serial1/0 remote 100 lisp-encap ... Service Provider MPLS VPN DATA DATA EIGRPAS 4453 Hello Hello EIGRPAS 4453

Remote Routers Remote Peers CE2# 00:01:57: %DUAL-5-NBRCHANGE: EIGRP-IPv4 4453: Neighbor 192.168.2.2 (Serial1/0) is up: new adjacency CE2# CE2#show eigrp address-family ipv4 neighbors detail EIGRP-IPv4 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 Se1/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 CE2#

Remote Routers Remote Peers address properties • In order to form peers, the Public interface must be enabled for EIGRP • For IPv4, 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 • The interface is used to send packets,sothe IP address of the remote peerjust has to be reachable via the WAN interface Serial1/0 description Service Provider ip address 172.16.0.1 255.255.255.0 ! router eigrp ROCKS ! address-family ipv4 unicast auto 4453 ! topology base exit-af-topology neighbor 192.168.2.2 Serial1/0 remote 100 lisp-encap network 172.16.0.0 0.0.0.255 network 10.1.0.0 0.0.255.255 exit-address-family

CSCuj68811: 15.4(1.16)S0.2, 15.4(1.16)S0.315.4(1.16)S0.4, 15.4(2.1)S15.4(2.2)S Route Reflectors Point to Multi-Point – Multiple Branch Sites • EIGRP Route-Reflectors simplifies setting up multiple branches • Chose one of the CE routers to function asRoute Reflector (RR) • Purpose of the Route Reflector is to‘reflect’, or advertise routes received toother CE routers • Control plane is deployed in a“Hub-and-spoke” topology router eigrp ROCKS address-family ipv4 unicast auto 4453 remote-neighbors source Serial 0/0 unicast-listen lisp-encap network 10.0.0.0 RR Site 3 Site 2 Site 1 = DP = CP

CSCuj68811: 15.4(1.16)S0.2, 15.4(1.16)S0.315.4(1.16)S0.4, 15.4(2.1)S15.4(2.2)S Route Reflectors Point to Multi-Point – Multiple Branch Sites • Question:In the example, if CE in Site 1 advertises aroute to the Route Reflector, will the routepropagateto other CE routers? • Answer: No! • The split horizon rule prohibits a routerfromadvertising a route through aninterface that it uses to reach thedestination. • Solution: • In order for the route to be ‘reflected’tothe other sites, use theno split-horizon command on thepublic interface router eigrp ROCKS address-family ipv4 unicast auto 4453 remote-neighbors source Serial 0/0 unicast-listen lisp-encap network 10.0.0.0 af-interface serial 0/0 no split-horizon exit-af-interface Site 3 Site 2 Site 1

Route Reflectors Point to Multi-Point – Adding Branch Sites • EIGRP Route Reflector simplifies adding additional branches address-family ipv4 unicast auto 4453 neighbor 192.168.1.1 Serial 0/2 remote 100 lisp-encap network 10.0.0.0 network 192.168.0.0 0.0.255.255 ... Site 4 RR Site 3 Site 2 Site 1 • 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 configurationof the Route Reflector = DP = CP 25 25

CSCuj68811: 15.4(1.16)S0.2, 15.4(1.16)S0.315.4(1.16)S0.4, 15.4(2.1)S15.4(2.2)S Route Reflectors 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 directlyfrom site to site? • The solution: 3rd Party Nexthops RR Site 3 Site 2 Site 1 = DP = CP 26

Route Reflectors router eigrp ROCKS address-family ipv4 auto 4453 af-interface Serial0/0 no next-hop-self 3rd Party Nexthops • Normally the Route Reflector would send the nexthopas 0.0.0.0 which tells CE1 and CE2 to use it to reachthe destination • When “no next-hop-self” configured, the RR preservesthe next hop of the peer that sent it the route • When CE1 and CE2 receives an update from theRR, they install the route in the RIB with thesupplied nexthop • Traffic leaving CE1 goes directly to router CE2 RR .1 .2 .3 CE2 CE1 10.1.1.0/24 EIGRP-IPv4 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

Redundant Remote Routers Multiple Next Hops 10.2.0.0 [90/18600] via 192.168.1.5, LISP0 via 192.168.1.6, LISP0 • In an OTP setup, an RR can learn two or more equal-cost paths to a site. • However, the RR router will only advertise one of the paths to other spokes in the OTP network. • Implication: • Site to Site traffic will only be sent to one router • Sites are not able to leverage multi-router setups RR 10.2.0.0 [90/32600] via 192.168.1.5 Site 2 Site 1 Site 3 .5 .6 10.2.0.0/24

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 top 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.

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) • Add Path Support enables the Route Reflector to advertise multiple best paths • Up to 4 additional Nexthops addresses(5 total) RR 10.2.0.0 [90/32600] via 192.168.1.5 via 192.168.1.6 Site 2 Site 1 Site 3 .5 .6 router eigrp ROCKS address-family [ipv4 or ipv6] 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 10.2.0.0/24

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 remoteneighbor configuration for the new Route Reflector • Remotes do not have to be configure to connectto all Route Reflectors RR-2 RR-1 Site 1 router eigrp ROCKS address-family ipv4 unicast auto 4453 neighbor 192.168.10.1 Serial0/1 remote 100 lisp-encap neighbor 192.168.20.2 Serial0/2 remote 100 lisp-encap ...

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; • Don’t! This is not supported. • Instead, consider adding a GRE tunnel betweenthe Route Reflectors, and share routing information RR-2 RR-1 Site 1 Site 2 router eigrp ROCKS address-family ipv4 unicast auto 4453 remote-neighbors source Serial 0/0 unicast-listen lisp-encap neighbor 192.168.2.2 Seral0/2 remote 100 lisp-encap ...

Redundant Route Reflectors Support for Multiple Providers • Support for additional Service Providers is also possible • Choose a Route Reflector per Service Provider to ensure each CE hasreachability to other sites • Normal EIGRP metric selection and costing will influence path selection RR-1 RR-2 ISP1 Site 2 Site 1 Site 3 ISP2

Deployment Considerations • Route Filtering • Backdoor Links

Route Filtering address-family ipv4 unicast auto 4453 neighbor 192.168.1.1 Serial 0/2 remote 100 lisp-encap network 192.168.0.0 0.0.255.255network 10.2.0.0 0.0.255.255 ... Limiting leaking of public routes into the LAN • When you setup an OTP peer, you must add a network statement covering the public interface • 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 advertiseto EIGRP neighbors on the LAN interface • EIGRP will advertiseany public address it receives via the LAN from another neighbor over the WAN • Generally this is not an issue… however… .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.. • But we also see an traffic is being drop due to the LISP encapsulation failure CE1# 02:24:05: %DUAL-5-NBRCHANGE: EIGRP-IPv4 4453: Neighbor 192.168.31.14 (Serial1/0) is up: new adjacency 02:24:07: %CFC_LISP-5-ADJ_STACK: Stacking adjacency IP adj out of LISP0, addr 192.168.31.14 (incomplete) onto other LISP adjacency IP midchain out of LISP0, addr 192.168.20.13 F0732BB8 forcing drop • CE3#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)

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, thepacket 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 • Peers are not effected by the LISP encap failure as EIGRP sends packets directly to the public interface CE1#show ip route … D 192.168.20.0/24 [90/114980571] via 192.168.31.14, 00:00:29, LISP0 D 192.168.31.0/24 [90/114980571] via 192.168.20.13, 00:23:10, LISP0

CE2b#sh run ... router eigrp ROCKS ! address-family ipv4 unicast autonomous-system 4453 ! topology base distribute-list 10 out exit-af-topology neighbor 192.168.10.12 Serial1/0 remote 100 lisp-encap network 10.0.0.0 network 192.168.0.0 0.0.255.255 exit-address-family ! access-list 10 deny 192.168.0.0 0.0.255.255 access-list 10 permit any 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 addressfrom leaking into customer site Site 3 .20.13 .31.14 10.2.0.0/24

Deployment Considerations • Route Filtering • Backdoor Links

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 CE CE C1 ISP C2 Headquarters RemoteOffice Backdoor Link interface Serial0/0 delay 40000 . . . • Use “distribute-list out” on CE’s to prevent address from leaking between sites

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

The Acme Corporation MPLS VPN MPLS VPN Corporate Backbone MPLS VPN MPLS VPN MPLS VPN MPLS VPN MPLS VPN MPLS VPN … … … … … … … … France Sweden England USA

The Acme Corporation Route Exchange RR RR WAN Hubs 2 x ASR1000 MPLS VPN for Branches and ATMsA MPLS VPN for Branches and ATMsB … … Spokes

The Acme Corporation WAN Security with GET VPN KEY SERVER WAN Services 2 x 3945E RR RR MEMBER MEMBER WAN Hubs 2 x ASR1000 MPLS VPN for Branches and ATMsA MPLS VPN for Branches and ATMsB … … MEMBERS

The Acme Corporation – 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

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 IPv4 and IPv6 deployments • EIGRP’s scalability is an important factor in OTP deployment • OTP can work over traditional WAN and LAN networks

For more Information on OTP • EIGRPOTP: • http://www.cisco.com/en/US/docs/ios-xml/ios/iproute_eigrp/configuration/xe-3s/ire-eigrp-over-the-top.html • Open EIGRP (IETF Draft): • ftp://ftp.ietf.org/internet-drafts/draft-savage-eigrp-02.txt • OTPOSPF(IETF Draft): • http://www.ietf.org/staging/draft-white-ospf-otc-01.txt

Over the Top Routing Protocols

Over the Top Routing Protocols

Presentation Transcript

Routing Protocols

Routing/Routed Protocols

Routing Protocols

Routing Protocols

Intradomain Routing Protocols

Routing Protocols

Routing Protocols

Routing Protocols

Routing Protocols

Routing Protocols

Routing Protocols

Routing Protocols

Routing protocols

ROUTING PROTOCOLS

Routing and Routing Protocols

Routing and Routing Protocols

Routing protocols

Routing Protocols

Routing Protocols

Routing protocols