Download Cisco Live 2014

Over the Top Routing Protocols
Joe Harris
Consulting Systems Engineer
Agenda
•
•
•
•
•
Overview of Current Solutions
How OTP works
Peering over the WAN
Considerations
Case Study
© 2014 Cisco and/or its affiliates. All rights reserved.
Cisco Public
2
Overview of Current WAN Solution
PE-CE Overview
PE1
MPLS VPN
Cloud
PE2
CE1
CE2
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-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 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
PE1
CE1
MPLS VPN
Core
Site 1
Site 2
PE2
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 impacts
site to site convergence
PE1
• 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
CE1
MPLS VPN
Core
Site 1
Site 2
PE2
CE2
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
PE1
MPLS VPN
Cloud
PE2
CE2
CE2
CE2
CE1
CE1
Site 1
Site 2
C4
C3
© 2014 Cisco and/or its affiliates. All rights reserved.
Cisco Public
6
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 L3-VPN costs by reducing the required customer routes
in the VPNv4/v6 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 1K Series – IOS-XE 3.10
ISR, ISR G2, 7200 Series – IOS 15.4(1)T
© 2014 Cisco and/or its affiliates. All rights reserved.
Cisco Public
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 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)
© 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
Yes/No
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 multitenancy
DMVPN VRF-Lite; MPLS o
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 XE3.14
PIM Hub-n-Spoke
PIM MVPN
MVPN + DMVPN Hub-nSpoke
VRF Support
Planned XE3.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 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
© 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 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
Route
Updates
• LISP encaps the traffic and then sends it to
the Public interface
Cisco Public
13
Default
Traffic
Inside
Interface
• Traffic that arrives on the router destined
for the remote side, is first sent to LISP0
© 2014 Cisco and/or its affiliates. All rights reserved.
EIGRP
RIB
Site to
Site
Traffic
LISP0
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 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
© 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 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.
© 2014 Cisco and/or its affiliates. All rights reserved.
Cisco Public
15
OTP – Data Plane
LISP Header Format (IPv4 example)
LISP0
Internal Interface
/
External Interface
/
|
|
OH
|
|
\
LISPDATA
DATA
LISP encapsulation (36 bytes) :
\
IP header (20 Bytes)
UDP header (8 Bytes)
LISP header (8 Bytes)
/
UDP
\
OH – Outer Header (LISP Encap packet)
L
I \
S /
P
/
/
|
|
IH
|
|
\
\
Source Routing Locator:
Public address of external Interface
Destination Routing Locator
Public address provided by network configuration
Source Port - Set by LISP
Instance ID - Set by EIGRP
IH – Inner Header (Site Data packet)
Source EID (Site private address)
Destination EID(Site private address)
© 2014 Cisco and/or its affiliates. All rights reserved.
Cisco Public
16
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service|
Total Length
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Identification
|Flags|
Fragment Offset
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol = 17 |
Header Checksum
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Source Routing Locator
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Destination Routing Locator
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Source Port = xxxx
|
Dest Port = 4343
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
UDP Length
|
UDP Checksum
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N|L|E|V|I|flags|
Nonce/Map-Version
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Instance ID/Locator Status Bits
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service|
Total Length
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Identification
|Flags|
Fragment Offset
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live |
Protocol
|
Header Checksum
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Source EID
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Destination EID
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 [ipv4/v6 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
Peering over the WAN
• Remote Routers
• Route Reflectors
• Redundant Remote Routers
• Redundant Route Reflectors
© 2014 Cisco and/or its affiliates. All rights reserved.
Cisco Public
18
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 ipv4 unicast auto 4453
neighbor 192.168.2.2 Serial1/0 remote 100 lisp-encap
...
DATA
LISPDATA
Hello
CE-1
EIGRP
AS 4453
router eigrp ROCKS
address-family ipv4 unicast auto 4453
neighbor 192.168.1.1 Serial1/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
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#
© 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 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
interface Serial1/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.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
21
Peering over the WAN
• Remote Routers
• Route Reflectors
• Redundant Remote Routers
• Redundant Route Reflectors
© 2014 Cisco and/or its affiliates. All rights reserved.
Cisco Public
22
CSCuj68811:
15.4(1.16)S0.2, 15.4(1.16)S0.3
15.4(1.16)S0.4, 15.4(2.1)S
15.4(2.2)S
Route Reflectors
Point to Multi-Point – Multiple Branch Sites
• EIGRP Route-Reflectors simplifies setting up multiple branches
router eigrp ROCKS
address-family ipv4 unicast auto 4453
remote-neighbors source Serial 0/0 unicast-listen lisp-encap
network 10.0.0.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
• Control plane is deployed in a
“Hub-and-spoke” topology
= DP
= CP
Site 1
Site 3
© 2014 Cisco and/or its affiliates. All rights reserved.
Cisco Public
Site 2
23
CSCuj68811:
15.4(1.16)S0.2, 15.4(1.16)S0.3
15.4(1.16)S0.4, 15.4(2.1)S
15.4(2.2)S
Route Reflectors
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 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
• 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 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
= 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
Site 3
of the Route Reflector
© 2014 Cisco and/or its affiliates. All rights reserved.
Cisco Public
= DP
Site 1
Site 2
25
25
CSCuj68811:
15.4(1.16)S0.2, 15.4(1.16)S0.3
15.4(1.16)S0.4, 15.4(2.1)S
15.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 directly
from site to site?
RR
= DP
= CP
• The solution: 3rd 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 ipv4 auto 4453
af-interface Serial0/0
no next-hop-self
3rd Party Nexthops
• Normally the Route Reflector would send the nexthop
as 0.0.0.0 which tells CE1 and CE2 to use it to reach
the destination
RR
.1
• When “no next-hop-self” configured, the RR preserves
the next hop of the peer that sent it the route
• When CE1 and CE2 receives an update from the
RR, they install the route in the RIB with the
supplied nexthop
• Traffic leaving CE1 goes directly to router CE2
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
© 2014 Cisco and/or its affiliates. All rights reserved.
Cisco Public
27
.2
.3
CE1
CE2
10.1.1.0/24
Peering over the WAN
• Remote Routers
• Route Reflectors
• Redundant Remote Routers
• Redundant Route Reflectors
© 2014 Cisco and/or its affiliates. All rights reserved.
Cisco Public
28
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, LISP0
via 192.168.1.6, LISP0
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 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.
© 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
Site 2
• Up to 4 additional Nexthops addresses
(5 total)
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
© 2014 Cisco and/or its affiliates. All rights reserved.
Cisco Public
31
.6
.5
Site 3
10.2.0.0/24
Peering over the WAN
• Remote Routers
• Route Reflectors
• Redundant Remote Routers
• Redundant Route Reflectors
© 2014 Cisco and/or its affiliates. All rights reserved.
Cisco Public
32
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 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
...
© 2014 Cisco and/or its affiliates. All rights reserved.
Cisco Public
33
Site 1
RR-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;
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
...
• 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
34
Site 1
RR-1
Site 2
RR-2
Redundant Route Reflectors
Support for Multiple Providers
• Support for additional Service Providers is
also possible
ISP1
• 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 1
Site 2
RR-2
ISP2
© 2014 Cisco and/or its affiliates. All rights reserved.
Cisco Public
35
Site 3
Deployment Considerations
• Route Filtering
• Backdoor Links
© 2014 Cisco and/or its affiliates. All rights reserved.
Cisco Public
36
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 ipv4 unicast auto 4453
neighbor 192.168.1.1 Serial 0/2 remote 100 lisp-encap
network 192.168.0.0 0.0.255.255
network 10.2.0.0 0.0.255.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
.20.13
.31.14
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..
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
• But we also see an traffic is being drop due to the LISP encapsulation failure
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)
© 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
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
• 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
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
© 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
• Route Filtering
• Backdoor Links
© 2014 Cisco and/or its affiliates. All rights reserved.
Cisco Public
41
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
ISP
Headquarters
CE
CE
C1
Backdoor Link
C2
Remote
Office
interface Serial0/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
Case Study
© 2014 Cisco and/or its affiliates. All rights reserved.
Cisco Public
43
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
© 2014 Cisco and/or its affiliates. All rights reserved.
Cisco Public
The Acme Corporation
Sweden
…
…
…
MPLS
VPN
MPLS
VPN
…
France
MPLS
VPN
MPLS
VPN
MPLS
VPN
MPLS
VPN
Corporate Backbone
MPLS
VPN
MPLS
VPN
…
…
…
USA
England
© 2014 Cisco and/or its affiliates. All rights reserved.
…
Cisco Public
45
The Acme Corporation
• Route Exchange
RR
RR
WAN Hubs
2 x ASR1000
MPLS VPN for
Branches and ATMs
MPLS VPN for
Branches and ATMs
A
B
…
…
Spokes
© 2014 Cisco and/or its affiliates. All rights reserved.
Cisco Public
46
The Acme Corporation
• WAN Security with GET VPN
KEY SERVER
WAN Services
2 x 3945E
MEMBER
RR
RR
WAN Hubs
2 x ASR1000
MPLS VPN for
Branches and ATMs
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 (<1s 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 IPv4 and IPv6 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-3s/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