I'm trying to do a new Cisco IWAN setup. I'm trying to imagine how it would look with how the new I'm using is configured. I'll keep it single, here would be the physical setup: http://i.imgur.com/CLuQpUa.png . It's odd because we have one site that has terrible connectivity from ISPs (it's in the middle of no where). Thus we have 3 x ADSL links going to it to get the bandwidth it needs. I want to eventually use Cisco IWAN and PFR to load balance across these 3 links back to the datacenter.
To setup a DMVPN that can I load balance across (e.g all 3 ADSL links are always active), would I try and configure a single DMVPN and then have three tunnel interfaces somehow point into it? Like this http://i.imgur.com/6ANON1h.png If so, how would I setup the tunnel interfaces?
Or would I try and have 3 different DMVPNs configured like this: http://i.imgur.com/1s0g0th.png . If so, would I just create three tunnel interfaces on the Hub and Regular Site Spoke routers and have them share the same tunnel source?
On the spoke I would create three VRF's, and put each ISP's interface into a separate VRF. Then I would create three Tunnel interfaces.
Check out this iWAN validate design guide.
Check out the "front door" vrf.
They talk about it in the context of a hub having multiple ISP connections, but exactly the same applies for a spoke with multiple connections. In your case, you would have three "front door" VRFs.
Yes, you may configure three DMVPN tunnels and PFR would do the magic for you. But the drawback is that you would need to run three BR routers on the Hub (as currently iWAN 2.1.x supports only one tunnel per Hub BR).
Support for Multiple Tunnel Termination (multiple tunnels on Hub BR) comes in iWAN 2.2 (expected around March 2017).
But I would not do such kind of design just for a single site "in the middle of nowhere".
If you're still working on this one; iWAN 2.2 is starting to become available now.
If you've already come to a solution, may I ask what you came up with so far?
If I might hazard to jump into the "iWAN Supported" discussion a bit; I think it's important to understand that iWAN is really a collection of existing technologies, branded together now, but based on things that individually developed over time (much the way DMVPN was developed actually). I think there's an argument to be made for taking parts/pieces of iWAN design and using that to inform the implementation of those other existing technologies. At a base level, DMVPN with fVRF is what you need to get the VPN tunnel across the 3 links. Then you're tyring to layer PfRv3 concepts on top of that to better utilize those links, and reduce delays relying only on routing protocol reconvergence, and route with more intelligence as well, (such as for brownouts). If basic routing and link-detection is all you need, maybe some careful configuration of the routing protocol timers is all you need to get 'good enough' connectivity. Just because a configuration is not 'supported' iWAN based on the CVD, doesn't mean there aren't other working solutions to particular problems. Network engineers have been running networks for decades building solutions by combining technology components without a CVD for the design. But then again maybe another approach is appropriate as well. If you're not already doing DMVPN with multiple sites, and you're not going to scale beyond 2 spokes, another technology might be a better fit. MLPPP on the ISP's multiple lines comes to mind.
iWAN 2.2 is available in 16.3.3+ and 15.6(3)M2 releases.
PS: as far as I know there are no plans to support it on 3.x S train (IOS-XE).
1. Can we have 2951 and 4351 in IWAN hub as two border routers ?
2. Can we use one hub border router as master controller instead of separate router. ?