Hi Dusty, Full Disclosure, I work for Telstra Purple, who do a lot of different SDWAN deployments.
TL;DR It’ll come down to your business requirements, your environment, your users’ traffic patterns and your business/IT strategy. Choose based on the outcome, not the tech. There are so many SDWAN technologies out in the wild that it truly is a buyer’s market at the moment. They range from portals front ending a scripting engine, to full control, management and data plane segregation, which are arguably the pureplay SDWAN solutions. They can be point solutions (Software Defined policy just for a WAN, or they can work within a larger ecosystem such as Cisco Viptela, Fortinet, VMWare velocloud, Juniper and Aruba do with integrating into LAN and WLAN and DC, which are moving to a Software Defined world too.. So these wider considerations are probably worthwhile to look into (SASE is a Gartner term, but it is worth reading up on because I can bet my boots any CIO worth their salt will know about it). And because there’s loads to choose from, it will come down to what are your business goals (sometimes these do not align to technology goals) – although it is often the job of the IT Manager, the IT Girl or Guy or ‘smart-basement-residing-coder’ to determine how a business goal is enabled by the infrastructure + policy supporting the company. Sometimes this works, sometimes it doesn’t. But I cannot stress this enough, the tech is great, but if it doesn’t meet your business needs then it is not great. So if you want to know “why” or “why not” for any SDWAN technology (or any technology at all for that matter), it will be worthwhile you understanding what the business wants and you marrying a technology piece to it.. and then assessing the tech against that or those.. there should be enough info out in the wild wicked web at that point. Interestingly, I don’t see many SDWAN rollouts fully removing MPLS or private “guaranteed” services (there are definitely a few though where MPLS was nix’d in favour or Internet only, and it worked well). Mainly though I see companies using both Internet and private links (reduced MPLS BW with a new high bandwidth Internet service), and using them far more intelligently.. using app recognition to push traffic one way or the other. This means a ‘reduction’ in private link costs, with a small cost for a cheaper higher bandwidth Internet link. Yes, QoS comes into it, however the SDWAN vendors all agree that once you let the software do the smarts, underlay QoS mechanisms aren’t as ‘critical’.. still important, but not critical. They can still mark packets with DSCP/CS on the tunnel headers to ensure it hits queues on the underlay if needed, and some really good tech can provide full queues within the overlay too which is a nice touch, but the smarts in the software work out the best or most appropriate path and send the traffic along it. Some SDWAN tech works better with no underlying QoS.. yes you read that correctly. Clearly though the internet doesn’t do QoS, or not well in any case, however if you have an SLA defined in the SDWAN promising you it will deliver the experience using its ‘smarts’ then that reduces the importance of per link QoS. Some of them have smart SD functions which uses things like contracts or SLAs to intelligently push traffic around the available links. QoS concerns are real however which is why I see most SDWAN adopters keep an MPLS circuit there, albeit at reduced BW. Would I put a full Internet based SD-WAN solution out there for a customer? Yes and No, it depends on their requirements.. it all comes down to the business requirements. The benefits of SDWAN? Done correctly it can: * provide a greater user experience by utilising direct internet breakout (yes that means a change in view on using things like on-prem proxies and so on) * provide a significant cost savings by reducing MPLS private bandwidth and replacing expensive MPLS bandwidth with cheaper internet bandwidth – although in my experience, companies tend to spend that $$ on other things, rather than banking them * provide secure redundancy (albeit I’m sure some networkers out there wouldn’t consider an Internet circuit as a suitable ‘redundant’ path for a MPLS circuit, but it is – however one always has the issue of physical redundancy – back hoe fade is a thing!) with more than one circuit, sometime with 4G/5G even. * provide greater uptime and this kind of ensues from the previous point, but by utilising 4G/5G as one of the active paths, or failover path. * commoditise the underlay, effectively giving you the choice of any carrier to be used as transport (This makes things like contract and vendor management more onerous, but hey it’s a benefit in some people’s eyes). The SD in SDWAN obfuscates the underlay, moving all smarts into the SDWAN overlay.. Think of it as a HAL back in WinNT days, providing that easier to understand layer which translates into the machine language underneath. This obfuscation makes it so you don’t really need to know about the underlay, what’s important is in the SDWAN overlay and that’s the thing you now interact with. * Facilitate cloud adoption by providing a secure tunnel into the IaaS of your choice, making that ‘DC’ part of your WAN, or edge. * Provide a single point of control and management for your entire WAN.. vastly reducing the CLI wizardry required. A single config can be pushed to every device (especially powerful if you have control and data plane separation). * Provide a secure network with segmentation.. where before you might have needed a few IPVPNs to provide your vrfs, you can now have a single IPVPN which can be segmented at the software layer in the SDWAN, again, and depending on tech, this can theoretically provide multiple segmented VPNs utilising a single IPVPN circuit, Internet circuit even. * Northbound APIs.. if you’re moving your environment into things like AWS or Azure or wanting to orchestrate other things with APIs, SDWAN theoretically provides a single place to send APIs too.. making it far easier to integrate into a wider M2M environment * Provide cloud based security options (Zscaler, Cisco Umbrella, PA Prisma, NetSkope, the list goes on), and think of these as proxies in the cloud.. way cool! It should be noted that one doesn’t need an SDWAN to make use of these, but an SDWAN makes utilising them easier when at scale. * Provide a greater visibility because SDWAN tech generally wants to route based on application type, and not on IP subnets (IP subnets are still there, don’t get me wrong, they’re just obfuscated by the SD layer) and as such it has a far better understanding of what applications are running over the network. It of course doesn’t help that a lot of it is TLS these days, but still, using the quintuple and ML they can make an educated guess as to what is in the packet; and send it accordingly. There’s a lot more, but again it all comes down to your business requirements. Some pretty big requirements these days are security, OPEX payments and moving to the cloud. Meaning an uptick in SaaS and IaaS and PaaS on the enterprise network. These are forcing a change in traffic patterns on your network.. what used to be the centre of the world for companies was the DC, with all apps and access being provided from it or through it.. that’s no longer the case with a lot of internet based applications being the flavour of the year (I’m looking at you Office365, and you Salesforce, and you Concur..) it doesn’t make financial sense to maintain a full BW cost to use a DC as transit only. It makes a lot of sense to send the traffic directly to it via a directly connected internet circuit, so doing that securely and to company policy is key, and that’s were SDWAN can step in. SDWAN though is a symptom of changing traffic patterns and user needs, which makes it only one thing to look at when adapting to those needs. Security enforcement, Zero Trust Network, identity.. the list goes on.. go read up on SASE if you haven’t already, SDWAN is just one part of a whole, and unfortunately, it’s not the most important part in a business’ view.. the apps are. I’m sure there is a lot of reasons why SDWAN is bad or good to some people’s eyes. Some of the things I’ve listed here are things I’ve seen from my customers, take what you like out of it, ignore what you don’t like. It will always come back to what your business requirement is.. My 2c.. well maybe my 20c Brad From: AusNOG <ausnog-boun...@lists.ausnog.net> On Behalf Of dusty Sent: Monday, 31 May 2021 12:49 PM To: aus...@ausnog.net (ausnog@lists.ausnog.net) <ausnog@lists.ausnog.net> Subject: [AusNOG] SDWAN Security [External Email] This email was sent from outside the organisation – be cautious, particularly with links and attachments. Hi Folks, After a number of years being more managerial than technical, I find myself staring at a proposal to swap a perfectly good MPLS network with some Meraki shenanigans. This, frankly, gives me the heebie jeebies. I've done a bunch of poking around but, alas, it is remarkably difficult to locate reliable analyses of the actual security (or lack thereof) of these solutions - plenty of glossy marketing and whizzbang, not a lot of facts. Can anyone point me in the direction of some decent whitepapers, blogs, etc about the relative merits of these things? Thanks! --dusty (in Brisbane)
_______________________________________________ AusNOG mailing list AusNOG@lists.ausnog.net http://lists.ausnog.net/mailman/listinfo/ausnog
