Citrix SD-WAN virtual inline architectures are flexible to implement and require fewer networking changes. But maintaining a large number of static routes, access lists, and PBRs can be challenging.

Dynamic routing protocols exist to overcome the route-management challenge and can be helpful for medium-to-large networks. BGP and OSPF are both available options in the SD-WAN 9.3 and 10.0 builds.

With dynamic routing, SD-WAN can be configured for route learning only, but you have the option to advertise your SD-WAN routes into the DC/branch router(s). You can also configure your DC routers to prefer Citrix SD-WAN routes instead of your WAN router. So if one of the remote sites becomes unavailable, SD-WAN will automatically flush that remote site prefix from the routing table, sending a route update to its neighbors.

Establishing Basic BGP Communication with Your Router

Citrix SD-WAN supports a wide set of BGP filters and policies, along with many different BGP attributes used to influence inbound and outbound traffic, such as local preference, MED, AS-prepend, and community strings.

Here, I’ll show you how to establish basic BGP communication with your router in three easy steps using SD-WAN firmware 10.0. If you are using 9.3.x, the steps are a little bit different, but the overall process is exactly the same.

Remember that configuring BGP in a production environment requires some background in dynamic routing, so this tutorial requires a basic understanding of BGP. Enabling routing protocols without the proper settings might cause network issues such as routing loops. So try to play in a lab environment first using a Citrix SD-WAN Virtual Appliances (VPX) along with a virtual router software that supports BGP.

This tutorial requires that you have at least two SD-WAN sites, one master control node (MCN) and one client remote site. We are going to configure BGP between the MCN and the router, and you must have a router directly connected to the SD-WAN LAN interface to exchange routes with the DC router. The diagram below shows how the lab was configured.

Let’s get started with the configuration.

Step 1 – Configure BGP Basic Parameters.

On your SD-WAN Active configuration, click Connections, then BGP.

On your right frame, you have to configure your own BGP Basic Properties.

  • Enable: Enabling the BGP protocol process in the SD-WAN.
  • Advertise NetScaler SD-WAN Routes: If enabled, SD-WAN will advertise routes to its neighbors. Otherwise, it will be in route-learning mode only.
  • Router ID: A router ID is the unique identifier of a BGP router in an AS.
  • Local Autonomous System Number: This is the SD-WAN local autonomous system number. Both eBGP and iBGP are supported. If using iBGP, your neighbor router will use the same ASN as the SD-WAN.

Your screen should look like this.

Step 2 – Setting up BGP Neighbors on the SD-WAN Side.

You have to configure the necessary parameters to establish a BGP session with your BGP peer (core router).

  • Virtual Interface: You have to specify which interface your neighbor is reachable.
  • Source IP: SD-WAN will automatically set the VIP available on that virtual interface.
  • Neighbor IP: Your router BGP neighbor IP address.
  • Hold Time(s): Failing to receive keepalives will make the hold-down timer reach 180 seconds (default), which will mean the neighbor is considered down and routes from this neighbor are flushed. The BGP hold timer can be tweaked for faster convergence.

Of course, there are many other parameters that can be refined on a case-by-case basis. For the sake of this test, we are only covering a standard scenario. Your configuration should look like this.

Now you have to configure the router side to establish BGP peering with your Citrix SD-WAN. Below is an example configuration used that can be easily translated to any router syntax (in this case Vyatta):

# Configure the Router Interfaces.
set interfaces ethernet eth1 address ‘10.23.0.1/29’
set interfaces ethernet eth2 address ‘10.0.0.1/24’
#  Configure BGP Neighbor.
set protocols bgp 65207 neighbor 10.23.0.4 remote-as ‘65407’
#  Configure route redistribution (required only for the Lab testing to advertise local routes into BGP)
set protocols bgp 65207 redistribute ‘connected’
set protocols bgp 65207 redistribute ‘static’

This configuration may vary depending on the router and covers a basic setupl. Real-world configurations can include BGP filters, many different BGP attribute configurations, and dual-homed routers.

Step 3 – Activate your config and check the BGP Status.

Now you can save and export your config to the Change Management inbox and activate it.

After activating your new config, click on Monitoring and select Routing Protocols. If your configuration was done correctly on both sides (SD-WAN and Router), you should be able to see your session status as Established in the Info field. Any state different from Established (such as Active, Refused) means that there’s something wrong. Usually, problems are related to adding the wrong AS number or incorrect peer address.

The table shows some useful information, such as the number of routes imported/exported, and timers.

Now click on Statistics. In the drop-down menu, select Routes as shown below.

Notice that you’re able to see the BGP routes in the SD-WAN routing table. The Protocol column shows that it’s a BGP route being learned from the peer router (10.23.0.1).

In the router routing table below, we see that the MCN BGP peer (10.23.0.4) is advertising the remote site network (10.178.240.0/21) to the router.  Remember to avoid looping the VIP network back to the MCN.

Now you are exchanging routes with the DC and have potentially saved hours by preventing the need for manual configs. Additionally, you don’t need to rely on multiple access lists, PBRs, IPSLA and other manual configurations needed for virtual inline; however a BGP misconfiguration can lead to routing loops. It’s always recommended to configure you BGP parameters to be as specific as possible, including import/export filters on both sides (Router and SD-WAN).

Keep an eye out for our next post, where we will cover more features and protocols.