With the MTT (Multiple Tunnel Termination) feature enabled from the IOS XE software (Everest 16.4.1), We would like to know what the scalability of sites supported with 3 WAN Links (DMVPN's) in each Border Router?
We have ASR1001X (IOS XE 03.16.05.S) as both MC and Border router.
I have a similar question to the OP, and would be interested to see if you are able to provide any insight.
I am currently building a Dual DC Hybrid IWAN deployment for a customer, and would like to understand capacity for the ASR1001X's when using MTT. First some background:
The solution will eventually support approx 300 sites. Half will have dual 4331 routers (single transport per router), the remainder will be single 4331 with dual transports (MPLS & INET).
This is a multi-VRF design; each spoke will have the following 'user' VRF's: CORP (5 prefixes), SCADA (4 prefixes, non-summarisable), CONTROL (2-3 prefixes), GUEST (1 prefix), as well as the 2x FVRF's (INET/MPLS)
Each spoke site would typically have 2-3 of these VRF's active at any time.
Hub would obviously have all VRF's active at all times. Each VRF has a DMVPN cloud per transport, totaling 8x DMVPN clouds. Each is running EIGRP over tunnels.
Cisco haven't yet released the mVRF IWAN CVD; so hopefully my design is in line with their eventual CVD...
My build has:
Hub MPLS BR - ASR1k
Hub INET BR - ISR4451
Hub MC - currently 4331, but will be replaced with ASR1001x to support roll out
Transit MPLS BR - ASR1k
Transit INET BR - ISR4451
Transit MC - currently 4331, but will be replaced with ASR1001x to support roll out
Cisco advise that all BR's must be same platform to be a supported IWAN design (this is a WAAS requirement I think).
My question is whether the ASR1001X would cope if I built using MTT at each DC (ie, 1x ASR BR per DC, terminating both MPLS & INET Tunnels. I.e, can we get away without purchasing a third pair of ASR1k's to replace the 4451's.
EDIT: I should add that DC's have stretched L2, so all services would remain available if we lost one BR.
That is unfortunate about MTT / VRF support - I was just assuming I would be able to use MTT in this fashion (with 16.3.4).
2400IPSec SA's would be the maximum; Most sites will only require 2 or 3 VRF's, so in reality it may be closer to 1500-1800 SA's / EIGRP neighbours (total).
EIGRP end to end; one instance per VRF.
I have to admit I am only just starting on the PFR component - I have it up and running, but am yet to fully understand all aspects, and do not yet have a view as to what the eventual policy will look like.I currently have the standard CVD (IWAN 2.2) policy configured, and am yet to start adjusting it.
The CORP VRF will probably have the most policy requirements; SCADA and CONTROL VRF's have fairly basic needs and numbers of TC's. PFR for the GUEST VRF is not required, and will simply rely on EIGRP routing info.
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
Table of Contents Introduction:This document describes details on how
NAT-T works. Background: ESP encrypts all critical information,
encapsulating the entire inner TCP/UDP datagram within an ESP header.
ESP is an IP protocol in the same sense that TCP an...