In this edition of our SD-WAN series I’m going to take a step away from our lab environment and attempt to address a question I get a lot from our customers. “How do we integrate a SD-WAN router or pair of SD-WAN routers into our current environment?” Well the answer I’m afraid is the networking consultants classic line of “It depends”. And it really does, Cisco’s SD-WAN solution was created by engineers with a background in routing and this routing foundation really gives us a lot of flexibility when positioning our SD-WAN routers into our existing environment.
My plan with this blog post is to show you some of the more common deployments that I have seen, but before we jump in we need to get the answers to the below four questions. These answers will drive what deployment options we have at our disposal:
Does the site require SD-WAN high availability? In other words, will we be deploying one or two cEdge routers.
What WAN transports do we have at the site? And how much address space is available on each transport.
Do we have a layer 2 or layer 3 LAN side (Service Side) topology? If Layer 3 what routing protocols are currently running at the site.
Does traffic from and to the WAN need to be inspected by any 3rd party appliances? E.g. WAN Optimization or Security appliances?
It should be noted that the designs in this series of posts only show two WAN transports. All the designs support additional WAN transports (up to the maximum of 7).
Single cEdge Complete Customer Edge (CE) Replacement with Layer 2 LAN
These deployments are ideal for greenfield sites or smaller branch sites (10 to 50 users). Here in our first option we have a single cEdge which terminates our two WAN transport handoffs. This cEdge could replace our existing CE router in brownfield environments. If our existing CE router is a Cisco ISR1K or 4K router then we have the option of reutilizing this hardware, by reimaging it with an XE SD-WAN image and thus converting it to a SD-WAN router. Note that reimaging leads to a longer cutover window.
Subnets A and B have a /30 IPv4 prefix length that are assigned from the provider. Two default routes (one for each transport) pointing to their respective provider PE addresses are used to build our tunnels.
This site does not have a local firewall, so internet traffic is either backhauled to a central site or is tunneled from our cEdge to a cloud hosted firewall service such as Cisco Umbrella or Zscaler.
LAN side (VPN 1) routing (Subnet X) is performed by our cEdge, which hosts our client default gateway addresses. In the above diagram we only have a single subnet X at this site, but this can be increased with the creation of sub interfaces for each additional VLAN. These connected routes are redistributed into OMP and advertised up to our vSmart controllers and onto other sites in our environment.
Dual cEdge Complete Customer Edge (CE) Replacement with Layer 2 LAN (Option 1)
Here we added a second cEdge to our site to give us hardware redundancy. We have split our WAN transports (both of which have /30 addressing) across our two cEdges with our private transport terminating on cEdge 1 and our public transport terminating on cEdge 2. To enable intelligent routing of traffic across the appropriate link, each of our two cEdges need access to all of our site WAN transports. To achieve this, we extend our WAN transports between the two routers using TLOC extensions. cEdge 2 now has access to the private WAN transport through cEdge 1, while cEdge 1 can access the public transport through cEdge 2. Two new private subnets C and D have been added to the design to be used on these TLOC extension links. Subnet C needs to be advertised to the Provider Edge (PE) router of the private circuit so that remote SD-WAN routers can build tunnels across the private WAN to cEdge 2. To achieve this, we enable BGP on our cEdge 1 and advertise subnet C to our PE neighbor.
To enable Subnet D to be reachable across our public WAN transport we enable NAT on our cEdge 2 interface connected to our provider. Remember we only have a single public routable address available to us on our Public WAN transport so NAT is used to share this single address between our two SD-WAN routers. An alternative design where we have additional public addressing is shown in our next example.
Finally, our LAN side still hosts our client default gateways, but here we have enabled the first hop redundancy protocol VRRP so that our LAN ip address is virtual and can be shared between our two cEdges.
Dual cEdge Complete Customer Edge (CE) Replacement with Layer 2 LAN (Option 2)
This third option is the same as option two above, but here we have additional public wan ipv4 addresses available, so subnet B is now a /29 or /28. With these additional addresses we can assign cEdge 1 its own public address and remove the requirement of enabling NAT on cEdge 2. Here the public WAN handoff from the provider is split using a layer 2 switch (not shown in the diagram).
Ok this post has gone on a little longer than I first expected so I am going to break it into smaller parts. In this part we have covered our options for a complete CE replacement with layer 2 LAN side routing and no local firewall. In our next part I’ll introduce a local site firewall and layer 3 LAN side routing options. After that we can look at designs where integrating into sites with WAN optimization or IDS/IPS appliances are present.
Until then may your overlays and underlays routing never get leaked and your WAN bandwidth be plentiful and lossless.
Written By: Chris Marshall, LookingPoint Senior Solutions Architect - CCIE #29940