Protocols Joe Harris Consulting Systems Engineer Agenda Overview of Current Solutions How OTP works Peering over the WAN Considerations Case Study 2 Overview of Current WAN Solution Allow customers to segment their network using an MPLS VPN backbone ID: 383372
Download Presentation The PPT/PDF document "Over the Top Routing" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Slide1
Over the Top Routing Protocols
Joe Harris
Consulting Systems EngineerSlide2
Agenda
Overview of Current Solutions
How OTP works
Peering over the WANConsiderationsCase Study
2Slide3
Overview of Current WAN Solution
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)
PE-CE Overview
3
PE1
PE2
CE1
CE2
MPLS VPN
Cloud
Backdoor Link
Site
1
Site
2Slide4
Overview of Current WAN Solution
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 coreEither EIGRP or eBGP must be run between the PE/CEProvider had to have trained staff on hand to managePE/CE LinkProvider’s often prefer vender flexibilityProvider must be be involved with deployment
changes in enterprise customer’s network
PE-CE Issues for the Service Provider
4
PE1
PE2
CE1
CE2
MPLS VPN
Core
Site 2
Site 1Slide5
Overview of Current WAN Solution
Managed services is required, even if not needed
Provider often limits number of routes being redistributed
Enterprise and Service Provider must co-support deploymentControl of traffic flow using multiple providers is problematicChanging providers results in migration issuesService Provider route propagation impactssite to site convergenceRedistribution at the edge leads to additional
complexity and operational costs
for an Enterprise.
Carrier involvement restricts network design
change
and evolution
PE-CE Issues for the Enterprise5
PE1
PE2
CE1
CE2
MPLS VPN
Core
Site 2
Site 1Slide6
Overview of Current WAN Solution
Route redistribution adds
deployment complications
Without PE/CE support, back-door must be redistributed into a second instance of EIGRPWith 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
PE-CE Issues with Backdoor Links
6
CE1
CE2
Backdoor Link
C3
PE1
PE2
CE1
CE2
MPLS VPN
Cloud
Site
2
Site
1
C4
CE2Slide7
Problem Solution
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.
Service Provider
MPLS VPN
=
Data Plane
=
Control Plane
Customer Site 1
Customer Site 2Slide8
WAN Virtualization using OTP
EIGRP
“end-to-end” solution with:
NO special requirement on Service ProviderNO special requirement on EnterpriseNO routing protocol on CE/PE link
NO need for route redistribution
NO no need for default or static routes
EIGRP
OTP
supports transparent CE to CE Routing8
Availability
ISR
4451-X, ASR
1K
Series –
IOS-XE 3.10ISR, ISR G2, 7200 Series –
IOS 15.4(1
)TSlide9
WAN Virtualization using OTP
No additional routing protocol to administer
No routing protocol is needed on CE to PE link
All user traffic appears and unicast IP data packetsLimit impact on Service Providers NetworkCustomer routes are NOT carried in MPLS VPN backboneCustomer route flaps do not generate BGP convergence eventsSmaller BGP routing tables, smaller memory foot print, lower CPU usageWorks with existing PE equipmentMultivendor PE support
No upgrade requirements for PE or any MPLS VPN backbone router
Service Provider Benefits
9Slide10
WAN Virtualization using OTP
Single routing protocol solution
Simple configuration and deployment for both IPv4 and IPv6
Convergence is not depending on Service ProviderOnly the CE needs to be upgradedRoutes are carried over the Service Provider’s network, not though itNo artificial limitation on number of routes being exchanged between sitesConvergence speed not impacted by BGP timersWorks with both traditional managed and non-managed internet connectionsCompliments 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)
Enterprise Benefits
10Slide11
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 PlaneLISP
mGRE
IP
IP + mGREPrivacy
GETVPN
IPSec over mGRE
GETVPNGETVPN + DMVPN
Routing PoliciesEIGRP, EIGRP Stub
EIGRP Stub
Redistribution and route filteringEIGRP
Stub, Redistribution, filtering, Multiple ASNetwork Virtualization
VRF/EVN to LISP multi-tenancy
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-n-Spoke
VRF
Support
Planned XE3.15
Yes
No
No
11Slide12
OTP – How it Works
CE Routers have ‘private’ and ‘public’ interfaces &
routers exchange information using
unicast packetsPrivate interfaces use addresses that are part of the Enterprise networkPublic 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 interfaceSite-to-site traffic is encapsulated using LISP and sent unicast from/to the public interface address12Slide13
OTP – How it Works
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 LISP0LISP encaps the traffic and then sends it to the Public interfaceEIGRP, LISP, and RIB – Oh My!
13
EIGRP
Public
Interface
Inside
Interface
Default
Traffic
Site to Site
Traffic
RIB
Route
Updates
LISP0Slide14
OTP – Data Plane
Why
use LISP
to encapsulate the data as it traverses the WAN?Its “stateless” tunneling, so it;Requires NO tunnels to configure or manageIs transparent to the endpoints and to the IP coreSupports both hair-pin and site-to-site trafficSupports both IPv4 and IPv6 trafficProvides an overlay solution that enables transparent extension of network across WANIP-based for excellent transport independenceService provider picks optimal traffic path for site to site data
Supports multicast and VLANs to allow for future enhancements
LISP
Data Encapsulation
14Slide15
OTP – Data Plane
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.LISP Data Encapsulation Properties15Slide16
OTP – Data Plane
LISP Header Format (IPv4 example)
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 |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
OH | Time to Live | Protocol = 17 | Header Checksum |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Source Routing Locator |
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | Destination Routing Locator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Source Port = xxxx | Dest Port =
4343
|
UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L |N|L|E|V|I|flags| Nonce/Map-Version |
I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
S / | Instance ID/Locator Status Bits |
P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / |Version| IHL |Type of Service| Total Length |
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Identification |Flags| Fragment Offset |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IH | Time to Live | Protocol | Header Checksum |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Source EID | \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | Destination EID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
DATA
LISP
DATA
External Interface
Internal Interface
LISP0
LISP
encapsulation (36 bytes)
:
IP header (20 Bytes)
UDP header (8 Bytes)
LISP header (8 Bytes)
OH – Outer Header (LISP Encap packet)
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)Slide17
OTP – How it Works
EIGRP OTP is deployed in one of two ways
Remote Routers
Used for configuring a router to peer with one specific neighborForms a full mesh topologyConfigured with the commandRoute ReflectorsUsed to configure a router as a ‘hub’ Forms a Hub and Spoke topology
Configured with the command
Modes of Deployment
17
remote
-
neighbors
source [interface]
unicast-listen
lisp-encap
n
eighbor [ipv4/v6 address] [
interface] remote
[max-hops] lisp-encap [lisp-id]Slide18
Peering over the WAN
Remote Routers
Route Reflectors
Redundant Remote RoutersRedundant Route Reflectors18Slide19
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
DATA
LISP
Remote Routers
Point to
Point Peers
19
Service Provider
MPLS VPN
EIGRP
AS 4453
EIGRP
AS 4453
Hello
Hello
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
...
DATA
DATA
CE-1
CE-2Slide20
Remote Routers
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 Num0 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 Peers
20Slide21
Remote Routers
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 interfaceThis does not mean the ip address of the remote peer has to match the network/mask of the public interfaceThe interface is used to send packets,
so
the IP address of the remote peer
just has to be reachable via the WAN
Remote Peers address properties
21interface 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.255exit
-address-familySlide22
Peering over the WAN
Remote Routers
Route Reflectors
Redundant Remote RoutersRedundant Route Reflectors22Slide23
Route
Reflectors
EIGRP Route-Reflectors simplifies setting up multiple branches
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 routersControl plane is deployed in a“Hub-and-spoke” topologyPoint to Multi-Point – Multiple Branch Sites23
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
= DP
= CP
Site 3
Site 2
Site 1
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 Slide24
Route
Reflectors
Question:
In the example, if CE in Site 1 advertises a
route to the Route Reflector, will the route
propagate
to other CE routers?
Answer:
No!The split horizon rule prohibits a routerfrom advertising a route through aninterface that it uses to reach thedestination.Solution:In order for the route to be ‘reflected’
to the other sites, use the
no split-horizon command on the
public interfacePoint to Multi-Point – Multiple Branch Sites
24
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
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 Slide25
25
Site 3
Route
Reflectors
EIGRP Route Reflector simplifies adding additional branches
Point to Multi-Point – Adding Branch Sites
25
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
25
Site 2
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
= DP
= CP
Site 1Slide26
Route Reflectors
Each CE normally shows the Route Reflector (RR) as the next hop
Data
will ‘hairpin‘ though the RR to get to other sitesUseful for applying Policy and filtering trafficWill increase bandwidth requirements for the Route ReflectorWhat if I want to send traffic directlyfrom site to site?The solution: 3rd
Party Nexthops
Point to Multi-Point – Any-to-Any Data
26
26
Site 3
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
Site 2
RR
= DP
= CP
Site 1Slide27
Route Reflectors
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
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
3rd Party Nexthops
27
RR
CE1
CE2
10.1.1.0
/24
.3
.2
.1
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
router eigrp ROCKS
address-family ipv4 auto 4453
af-interface Serial0/0
no next-hop-self
Slide28
Peering over the WAN
Remote
Routers
Route ReflectorsRedundant Remote RoutersRedundant Route Reflectors28Slide29
Redundant
Remote Routers
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
Multiple Next Hops29
10.2.0.0
[90/18600] via
192.168.1.5
,
LISP0
via
192.168.1.6
,
LISP0
10.2.0.0
[90/32600] via
192.168.1.5
Site 2
10.2.0.0/
24
.
5
.6
Site 3
Site 1
RRSlide30
Redundant Remote Routers
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.
Multiple Next Hops
30Slide31
Redundant Remote Routers
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)
Solution: Add-Path 31
Site 2
10.2.0.0/
24
.
5
.6
Site 3
Site 1
RR
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
[90/32600] via
192.168.1.5
via
192.168.1.6Slide32
Peering over the WAN
Remote
Routers
Route ReflectorsRedundant Remote RoutersRedundant Route Reflectors32Slide33
Redundant Route Reflectors
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
Adding second RR
33
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 ...
RR-2
RR-1
Site 1Slide34
Redundant Route Reflectors
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 between
the Route Reflectors, and share routing information
Exchanging routes between RR’s
34
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 ...
Site 1
Site 2
RR-2
RR-1Slide35
Redundant Route Reflectors
Support for additional Service Providers is also possible
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
Support for Multiple Providers
35
ISP1
RR-1
Site 1
Site 2
Site 3
ISP2
RR-2Slide36
Deployment Considerations
Route
Filtering
Backdoor Links36Slide37
Route Filtering
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 interfaceEIGRP 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 WANGenerally this is not an issue… however
…Limiting leaking of public routes into the LAN37
10.2.0.0/
24
.20.13
Site 2
.31.14
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
...Slide38
Route Filtering
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 failureLimiting leaking of public routes into the LAN
38
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)Slide39
Route Filtering
From “
show ip route
” We can see the public address is recursive though another public addressTo get to 192.168.20.0/24, the packet needs to be sent to 192.168.32.14 though the LISP interfaceTo 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
Public routes subnets in the LAN can result in recursion issues
39
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, LISP0Slide40
Route Filtering
Best practice is
to
prevent the public networks from entering the LAN by filtering it at each CEUse “distribute-list out” to prevent public addressfrom leaking into customer siteSolution – filter public
routes
from being reached via the
LAN
40
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
10.2.0.0/
24
.20.13
.31.14
Site 3Slide41
Deployment Considerations
Route Filtering
Backdoor Links
41Slide42
Deployment Considerations
The use of “back-door” links for OTP does not require special handling
Path selection determined by setting ‘delay’ on backdoor links
Site to Site - Backdoor Links42
Use
“
distribute-list out
” on CE’s to prevent address from leaking
between sites
Remote
Office
Headquarters
ISP
Backdoor Link
CE
CE
C2
C1
interface Serial0/0
delay 40000
. . . Slide43
Case Study
43Slide44
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 provisioningNo 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 providersNo routing exchange of internal
addressesSlide45
The Acme Corporation
45
Corporate Backbone
France
…
…
MPLS VPN
MPLS VPN
Sweden
…
…
MPLS VPN
MPLS VPN
England
…
…
MPLS VPN
MPLS VPN
USA
…
…
MPLS VPN
MPLS VPNSlide46
The Acme Corporation
Route Exchange
46
Spokes
WAN Hubs
2 x ASR1000
…
…
MPLS VPN for Branches and ATMs
B
MPLS VPN for Branches and ATMs
A
RR
RRSlide47
The Acme
Corporation
WAN Security with GET VPN
47
KEY SERVER
MEMBER
MEMBER
WAN Services
2 x 3945E
WAN Hubs
2 x ASR1000
MEMBERS
…
…
RR
RR
MPLS VPN for Branches and ATMs
B
MPLS VPN for Branches and ATMs
ASlide48
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 addressesSlide49
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 deploymentsEIGRP’s scalability is an important factor in OTP deployment OTP can work over traditional WAN and LAN networks49Slide50
For more Information on OTP
EIGRP
OTP:http://www.cisco.com/en/US/docs/ios-xml/ios/iproute_eigrp/configuration/xe-3s/ire-eigrp-over-the-top.htmlOpen 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
50Slide51Slide52