Best practices
This article outlines deployment best practices for the Citrix SD-WAN solution. It provides general guidance, advantages, use cases for the following Citrix SD-WAN deployment mode.
Edge/Gateway Mode
Recommendations
The following are the recommendations for the Gateway mode deployment:
-
The Gateway mode is best used for SD-WAN branches where router consolidation happens and customers are ready to allow SD-WAN to be the edge device terminating connections.
-
A great network architecture can be rendered with a scrupulous design when a project is built from scratch.
Note
The Gateway mode can be used on the data center side for the existing projects with some infrastructure disruption.
Advantages/Use cases
The following are the advantages/use cases for the Gateway mode deployment:
-
Best use case for Router/Firewall/Network element consolidation at the customer branch.
-
Simple and easy LAN host management via DHCP.
- Allows SD-WAN to become the next-hop and offer DHCP based IP addressing to all LAN hosts for data ports.
-
All connections terminate at the SD-WAN edge/gateway and management becomes easy.
-
SD-WAN is the focal point of edge routing and is steered of all traffic. The decisions are made on the edge to breakout or backhaul or overlay including the bandwidth/capacity accounting.
-
All LAN subnets hosts as the LAN hosts are allowed to have SD-WAN LAN VIP as the next-hop. If SD-WAN LAN connects to a core switch, you can run dynamic routing to get visibility to all LAN subnets.
-
Great flexibility for High Availability (HA) - Strict recommendation for the gateway mode so that the site operates with an Active/Standby mode. Also, it helps to prevent traffic blackhole if the SD-WAN device goes down.
-
Switches available at the branch - Parallel high availability can work in gateway mode.
-
Switches not available at the branch - SD-WAN can also operate on SD-WAN edge high availability mode (fail-to-wire high availability mode) where the two SD-WAN boxes are daisy-chained to make use of fail-to-wire ports to act as a converged high availability pair.
-
-
Allow the Internet to be defined as UNTRUSTED interfaces which automatically create a dynamic NAT for breakout and source NAT the connection so the response comes back to SD-WAN.
-
Security considerations to UNTRUSTED interfaces are implied naturally, in that only ICMP/ARP/UDP control packets on 4980 are allowed.
Cautions
The following are the information that you need to be careful about in the Gateway mode:
-
Careful design and Network Architecture - Gateway mode might need careful design and networking considerations as the entire branch/edge networking is in SD-WAN. What to block, what to route, how to network LAN, how to terminate WANs, and so on.
-
Failure of Device - Edge mode cannot have the fail-to-wire capability. The entire branch goes down when the device is down.
-
Security Posture - As the routing is managed at the edge, the security postures such as firewall, breakout/backhaul considerations are crucial and that must be conceived with the customer.
-
High Availability – Fail-to-wire high availability must have some port availability considerations and depending on deployments might become tricky to design.
- SD-WAN 110 is NOT an option as it does not have fail-to-wire ports.
For instance, if you need 2 WAN Links to operate, you need 5 ports including a dedicated port for the high availability interface including the LAN interface.
Inline Mode – Fail-to-wire/Fail-to-block
Recommendations
The following are the recommendations for the Inline mode deployment:
-
The inline mode is best for the branches where the existing infrastructure is not to be changed and SD-WAN sits transparently inline to the LAN segment.
-
Data center’s can also employ inline fail-to-wire or inline parallel high availability as it is immensely important to ensure that the data center workloads are not blackholed due to device down/crash.
Advantages and use-cases
The following are the advantages/use cases for the Inline mode deployment:
-
Keeping the MPLS router therefore fail-to-wire is a lovely feature. Fail-to-wire capable devices enable seamless failover to underlay infrastructure if the box went down.
-
If your devices support fail-to-wire (SD-WAN 210 and above), this allows placing a single SD-WAN inline to hardware bypass the LAN traffic to the customer edge router when the SD-WAN crashes/goes down.
-
If the MPLS Links are present that yield a natural extension to the customer’s LAN/Intranet, the fail-to-wire bridge-pair port is the best choice (fail-to-wire capable pairs) such that, when the device crashes or goes down the LAN traffic is hardware bypassed to the customer edge router (still maintained the next hop).
-
-
Networking is simple.
-
SD-WAN sees all traffic through the inline mode, so it is the best-case scenario for the proper bandwidth/capacity accounting.
-
Few integration requirements as you need only an IP of the L2 segment. LAN segments are well known as you have an arm to the LAN interface. If you connect to a core switch, you can also run dynamic routing to get visibility to all LAN subnets.
-
Customer’s expectations are that SD-WAN must blend into the existing infrastructure as a new network node (nothing else changes).
-
Proxy ARP – In inline mode, it is a blessing for SD-WAN to proxy ARP requests to LAN next-hop if the gateway went down or the SD-WAN interface towards next-hop went down.
-
Generally, in inline mode with bridge-pair (fail-to-block or fail-to-wire) with multiple WAN connections (MPLS/Internet), it is recommended to enable Proxy ARP for the bridge pair interface that connects the LAN hosts to their next-hop gateway.
-
For any reason when the next-hop is down or the SD-WAN interface to the next-hop is down rendering the gateway unreachable, SD-WAN acts as a proxy for ARP requests allowing the LAN hosts to still seamlessly send packets and use the remaining WAN connections that keep the virtual path up.
-
-
High availability - If fail-to-wire is not an option, devices can be placed in parallel high availability (common LAN and WAN interfaces for the Active/Standby) devices to achieve redundancy.
- If your appliances don’t support fail-to-wire, like the SD-WAN 110, you have to go with inline parallel high availability that enables to have a standby device kick in if the primary went down.
Cautions
The following are the information that you need to be careful about in the Inline mode:
-
Plumbing network with two arms to the SD-WAN (LAN and WAN side), needs some downtime as the network must be plumbed in two arms.
-
Must ensure if fail-to-wire is used, it is behind a customer edge router/firewall in a TRUSTED zone so that security is not compromised.
-
MPLS QoS changes a little in this as the previous QoS policies might have depended on the source IP addresses or DSCP based which will now be masked because of an overlay.
-
Care must be taken to repurpose the MPLS router with a well-designed SD-WAN specific reserved bandwidth with a specific DSCP tag, such that SD-WAN’s QoS takes care of prioritizing traffic and sends out high priority applications immediately followed by other classes (but be able to account for the overall bandwidth reserved for SD-WAN on the MPLS router). MPLS queues are an alternative or MPLS with a single DSCP set on the auto path group that can take care of this.
-
If the Internet interfaces are TRUSTED as the links terminate on the customer edge router, to use Internet service, you must write an exclusive dynamic NAT rule to enable internet breakout from the appliance.
-
If the Internet links are the only WAN connections and still terminate on the customer edge router, it is still fine to bypass the connections if the customer edge router takes precautions to steer the packets via their existing underlay infrastructure.
- Proper care must be taken to account for the flow of bypassing LAN traffic over bridge-pair with an Internet connection and when the appliance is down. Since this is a sensitive enterprise Intranet traffic, in the eve of failure, the customer must know how to handle it.
Virtual Inline/One-arm mode
Recommendations
The following are the recommendations for the Virtual Inline mode deployment:
-
The virtual inline mode is best for data center networking as the SD-WAN network plumbing can be worked on parallel while the data center is serving its existing workloads with existing infrastructure.
-
SD-WAN is in a one-arm interface that is managed with an SLA tracking on VIPs. If the tracking goes down, the traffic resumes routing via existing underlay infrastructure.
-
Branches can also be deployed in virtual inline mode, however are more predominant with Inline/Gateway deployments.
Advantages and Use-cases
The following are the advantages/use cases for the Virtual Inline mode deployment:
-
Simplest and recommended way to network SD-WAN in the data center.
-
The virtual inline mode allows parallel network plumbing of SD-WAN with the head-end core router.
-
The virtual inline mode allows us to easily define PBRs to divert LAN traffic must go through SD-WAN and get overlay benefits.
-
-
Seamless failover to underlying infrastructure if SD-WAN is to fail, and seamless forwarding to SD-WAN for overlay benefits under normal conditions.
-
Simple Networking and Integration requirements. The single one-arm interface from headend router to SD-WAN in virtual inline.
-
Easy to deploy dynamic routing in Import only mode (export nothing) to get visibility of LAN subnets so they can be sent to remote SD-WAN peer appliances.
-
Easy to define PBR on the routers (1 per WAN VIP) to indicate how to choose the physical.
Cautions
The following are the information that you need to be careful about in the Virtual Inline mode:
-
Proper care must be taken to distinctly MAP the SD-WAN logical VIP of a WAN link defined to the right physical interface (else this might cause undesirable issues in WAN metric assessment and choice of wan paths).
-
Proper design considerations are to be made to know if all traffic is diverted via SD-WAN or only specific traffic.
-
This means SD-WAN must be dedicated some share of bandwidth exclusively for itself that must be set on the interfaces such that SD-WAN’s capacity is not used by other non-SD-WAN traffic causing undesirable outcomes.
- Bandwidth accounting issues and congestion issues might occur if SD-WAN WAN links capacity is defined incorrectly.
-
Dynamic routing can cause some issues if improperly designed where if the SD-WAN routes data center and branch VIPs are exported to the headend and if routing is influenced towards SD-WAN, overlay packets start looping and cause undesirable outcomes.
-
Dynamic routing must be properly administered considering all potential factors of what to learn/what to advertise.
-
One-arm physical interface might become a bottleneck sometimes. Needs some design considerations in those lines as it caters to both upload/download and also acts as LAN to LAN and LAN to WAN/WAN to LAN traffic from SD-WAN.
-
Excessive LAN to LAN traffic might be a point to note during design.
-
If the dynamic routing is not used, there must be proper care if administering all LAN subnets, which if not, might cause undesirable routing issues.
-
There are potential routing loop issues if you define some default route (0.0.0.0/0) on the SD-WAN in the virtual inline to point back to the headend router. In such situations, if the virtual path went down, any traffic coming from the data center LAN (like monitoring traffic) is looped back to the headend and back to SD-WAN causing undesirable routing issues (If the virtual path is down, the remote branch subnets become reachable NO causing the default route to be HIT, that causes the loop issues).