Deploying IWAN

Fred · May 18, 2015, 09:53:47 PM

Who's deployed IWAN or is in the process of? Any experience or advice to share?

We are about to migrate to IWAN globally, though we're waiting on the PfRv3 part. Fortunately, this will be after Cisco Live, so I'll have a lot of brains to pick before we do it. Our plan is to get a good stable L3 network, and then add PfR if it makes sense.

burnyd · May 19, 2015, 05:10:23 PM

It has not been a solid process for us. I can tell you that much. If you want email me burnyd at gmail.com. I would highly suggest looking at viptella.

wintermute000 · May 20, 2015, 04:44:04 PM

viptella looks interesting, thanks for flagging it.

Fred, if you take out PfRv3, what makes it IWAN - just looks like a DMVPN to me? (except some of the NBMA endpoints are in private not public links - but the DMVPN overlay looks same as any other phase 3?)

burnyd · May 20, 2015, 09:32:25 PM

^^ Pretty much. iwan requires DMVPN. I just dont like it as it is. Some new improvements are coming but I am not a fan. PM me or you have my email up top lol.

LynK · May 21, 2015, 09:37:16 AM

Quote from: burnyd on May 20, 2015, 09:32:25 PM
^^ Pretty much. iwan requires DMVPN. I just dont like it as it is. Some new improvements are coming but I am not a fan. PM me or you have my email up top lol.

Carrier Independent controller based VPN service essentially? Are you using it in your network burnyd?

Fred · May 21, 2015, 08:05:18 PM

Quote from: wintermute000 on May 20, 2015, 04:44:04 PM
Fred, if you take out PfRv3, what makes it IWAN - just looks like a DMVPN to me? (except some of the NBMA endpoints are in private not public links - but the DMVPN overlay looks same as any other phase 3?)

Yeah, pretty much just redundant, carrier-independent DMVPN using front-door VRF. Recommendations from our consulting companies are to make sure you have that layer 3 overlay solid before implementing PfR, so it's coming, but probably not in 2015/2016.

wintermute000 · May 21, 2015, 11:34:47 PM

Enjoy phase three!!!

burnyd · May 22, 2015, 12:22:38 PM

Quote from: LynK on May 21, 2015, 09:37:16 AM
Quote from: burnyd on May 20, 2015, 09:32:25 PM
^^ Pretty much. iwan requires DMVPN. I just dont like it as it is. Some new improvements are coming but I am not a fan. PM me or you have my email up top lol.

Carrier Independent controller based VPN service essentially? Are you using it in your network burnyd?

I guess you can call it that? There are 2 physical paths. One MPLS one internet. But two different internets and two different head ends for the MPLS. So 4 tunnels in total for vpns.

LynK · May 22, 2015, 03:57:38 PM

I was looking into this as an option, but I found out our service provider will allow us to form VPNs on our broadband connection to their edge firewalls. From their they label in MPLS , and whammo we have a secondary connection which can technically run SIP as well as a complete data backup!

wintermute000 · May 22, 2015, 06:48:24 PM

I'm interested in any IWAN related feedback - I have a feeling I'll be doing some of that over the next few months. Might take you up on it burnyd if it comes down to it.

I know my phase 3 DMVPN very well and some WaaS but nothing about PfRv3 (thank you Cisco for removing it from the CCIEv5 lab syallabus lol). not sure if its worth learning PfRv3 in depth with the milliion other SDN or related technologies coming down the pipe... esp. if APIC-EM / onePK based controllers ends up superceding it... surely Cisco would never push something out in a half-assed way then throw it in the bin a year or two later for a newer shinier thingy....

wintermute000 · May 23, 2015, 08:09:11 PM

Guys, if you get onto dcloud, there is a full blown demo/lab - Cisco IWAN 4D Lab v1

You have the full thing pre-built - WAN/Internet, full phase 3 DMVPN overlay, EIGRP, PfRv3 and WAAS deployed and with a dummy branch site to build.
A very thorough workbook/walkthrough as well, even if its a bit slow going if you already know the DMVPN/EIGRP side of things.

its more of a walkthrough (look at the pretty show commands) than a lab but its still miles ahead of just watching slideware.
Together with reading the docwiki articles, I feel much better grounded on this topic than previously.

Can build a iWAN topology in VIRL but the trouble will be generating enough 'real' traffic to make PfR do its thing. I also haven't (shamefully) quite worked out how to bridge the VIRL virtual network with my 'real' or 'real virtual' environment. I will say that just from the demo alone it looks like a bit of a nightmare to configure/deploy unless you template the heck out of it via Prime - and if you don't have Prime, you're going to struggle to find engineers good enough to drive it without screwing something up, there's a LOT of config and its all inter-related.

Just getting the DMVPN right as you've mentioned is going to be a mission in itself, before you overlay all the rest of it - I have seen enough weird bugs/behaviours in standard DMVPN to be wary about overlaying everything with it just because - though in my case a lot of these weird issues are related to poor quality internet links (satellite... african ISPs.... i've seen it all, and learnt that you do not blindly deploy a Cisco enterprise architecture onto a 3rd world topology, but hey I wasn't the architect, so sucks to be me lol).

LynK · May 26, 2015, 08:27:41 AM

Quote from: wintermute000 on May 23, 2015, 08:09:11 PM
Guys, if you get onto dcloud, there is a full blown demo/lab - Cisco IWAN 4D Lab v1

You have the full thing pre-built - WAN/Internet, full phase 3 DMVPN overlay, EIGRP, PfRv3 and WAAS deployed and with a dummy branch site to build.
A very thorough workbook/walkthrough as well, even if its a bit slow going if you already know the DMVPN/EIGRP side of things.

its more of a walkthrough (look at the pretty show commands) than a lab but its still miles ahead of just watching slideware.
Together with reading the docwiki articles, I feel much better grounded on this topic than previously.

Can build a iWAN topology in VIRL but the trouble will be generating enough 'real' traffic to make PfR do its thing. I also haven't (shamefully) quite worked out how to bridge the VIRL virtual network with my 'real' or 'real virtual' environment. I will say that just from the demo alone it looks like a bit of a nightmare to configure/deploy unless you template the heck out of it via Prime - and if you don't have Prime, you're going to struggle to find engineers good enough to drive it without screwing something up, there's a LOT of config and its all inter-related.

Just getting the DMVPN right as you've mentioned is going to be a mission in itself, before you overlay all the rest of it - I have seen enough weird bugs/behaviours in standard DMVPN to be wary about overlaying everything with it just because - though in my case a lot of these weird issues are related to poor quality internet links (satellite... african ISPs.... i've seen it all, and learnt that you do not blindly deploy a Cisco enterprise architecture onto a 3rd world topology, but hey I wasn't the architect, so sucks to be me lol).

What are your thoughts on IWAN from an administrative burden? I am very interested in deploying something like this, but I do not have all the time in the day to be solely focused on my remote site infrastructure.

Also, I have never heard of dcloud, what is it?

wintermute000 · May 26, 2015, 06:33:57 PM

Not having deployed it in production, so take this with a massive grain of salt

- once (if?) you have Prime setup and properly integrated and assuming no bugs hit (ha!), the provisioning looks automated
- without the automation, there is several screen-fulls of extra config which is also easy to get wrong if you're doing it by hand
- the benefits boil down to basically: You have really neat netflow reports, and your network will dynamically shift guest wireless and youtube over to the backup link (thats basically the real life effect most enterprises will gain) to free up the main link, and you can order internet circuits at will and the overlay will mesh them into your production WAN seamlessly. THe last point isn't that big a deal in my book, as once you have a MPLS-VPN setup, here in Oz at least its actually cheaper to get a private link than internet in may cases. Also you need one hub/tunnel network per provider, so you're not entirely provider independent (with the internet counting as 1 virtual provider)
- you need ISR4ks - you'll be getting something really crappy with ISRG2s - I think setit (or another regular) was quoted 45M on a 3925 lol - god help you if you also consolidate voice, I have no idea whether it plays nice or not with CUBE functions and/or your regular CUCM services - instinct is to run away rofl
- your routing team had better be on board with phase 3 DMVPN and NHRP troubleshooting
- your routing design/arch team had better not be redistribution crazy and/or really think through the overlay design before implementing (hint hint: my services will run you half that of your local friendly VAR

and yes I have run a production, two tier phase 3 DMVPN and have more than 1 bug to my name lol )

Dcloud is cisco's demo cloud for remote 'labs' though I find them more demos than labs (like powerpoint presentations where you can actually do show runs yourself....). Talk to your friendly local Cisco AM/SE for access (I work for a gold partner)

http://dcloud.cisco.com/

routerdork · May 27, 2015, 10:11:52 AM

This came up today. I declined the join the call. So many issues to deal with before we could even think of taking on something like this.

wintermute000 · May 28, 2015, 05:43:15 AM

I'm starting a new role next week doing professional services/presales and I have a feeling I'll be dragged into IWAN, esp. as during my interview they pretty much had me pegged as a WAN guy, fingers crossed this isn't going to end up as a big stinking pile of ----.

The whole dependency upon DMVPN/NHRP and dynamic hidden ACLs/PBRs just gives any old school router guy the heebie jeebies. I've already seen more than two random NHRP (WAN outage causing) issues in production that were eventually traced back to 'oops our bad, software bug, upgrade pls' - but not until after a week of pain/TAC validation of course.