Skip to main content
Versa Networks

Versa SD-WAN Topology Constructs Based on BGP Attributes

Versa-logo-release-icon.png For supported software information, click here.

Versa SD-WAN uses Layer 3 virtual private network (VPN) technology based on BGP in its control plane to build its topologies on Versa Director. Topologies created using Versa Concerto or Versa Titan might be constructed slightly differently.

Layer 3 VPN is one of the types of Multiprotocol Layer Switching (MPLS) VPN, which are used to create VPNs. Layer 3 VPN uses Layer 3 VPN/virtual routing and forwarding (VRF) to segment routing tables for each customer. The route exchange is facilitated by MP-BGP.

Versa SD-WAN CPE devices act as MP-BGP PE devices, distributing VRF labels and leveraging the BGP route distinguisher and route target attributes to install routes in the appropriate LAN VRFs. Versa SD-WAN also uses MP-BGP to distribute routing information among branch devices, leveraging SD-WAN Controller nodes, which act as route reflectors. Each SD-WAN CPE branch device maintains secure control channels with a set of Controller nodes, for redundancy, and MP-BGP sessions are established over these secure control channels. While maintaining compliance with the RFCs, Versa SD-WAN has augmented its MP-BGP implementation with attributes that allow the distribution of SD-WAN topology information among branches.

Versa SD-WAN creates a flat Layer 2 VXLAN overlay network among all SD-WAN sites. Each SD-WAN sites uses this VXLAN network to communicate, in its control VR, with any other site as if the sites were connected directly to the same switch. On the top of VXLAN overlay, each SD-WAN device establishes a BGP connection to the Versa Controller so that it can use the Controller nodes as route reflectors.

Because of the nature of VXLAN, and because the distance between all SD-WAN devices is a single hop, Versa SD-WAN does not need to use MPLS transport labels. However, Versa SD-WAN uses only the MPLS VPN labels, in conjunction with BGP signaling, to differentiate among VRFs.

Versa SD-WAN leverages the following BGP Layer 3 VPN attributes when building its topologies:

  • Route targets using BGP extended communities
  • Route distinguishers
  • BGP communities
  • AS paths

This article describes how Versa SD-WAN uses MP-BGP to build its SD-WAN topologies.

Exporting Routes

When exporting from the local device's routing table to the SD-WAN network, Versa SD-WAN assigns global VRF IDs, route distinguishers, route targets, and communities to the route depending on the topology. The following table summarizes how the attributes that are associated with exported routes exported from the SD-WAN device into the SD-WAN network. The following sections provide more detail about how the attributes are determined, as well as examples. Note that route distinguisher and route target strings include a capital letter L, which is shown in bold in the table, for clarity.

BGP Attribute Full Mesh Hub LAN Routes Hub Routes Redistributed from Spokes Spokes
Global VRF ID Randomly assigned when VRF is created Randomly assigned when VRF is created

Hub's LAN global-vrf-id + 16000

Randomly assigned when VRF is created
Route distinguisher

global-vrf-idL:site-id

8000 + global-vrf-idL:site-id

1600 + global-vrf-idL:site-id

global-vrf-idL:site-id

Route target

target:vrf-idL:vrf-id

target:8000+vrf-idL:site-id

target:global-vrf-idL:0

target:global-vrf-idL:global-vrf-id

target:16000 + vrf-idL:site-id

target:16000 + vrf-idL:0

target:vrf-idL:vrf-id

Community None attached
  • 8009:8010—Hub global community for hub LAN routes
  • 8012:site-id—This hub

For regional deployments only:

  • 8011:region-id —Any device in region
  • 8012:region-id—This hub
  • 8000:0—Route from spoke re-advertised by hub

For regional deployments only:

  • 8011:region-id —Any device in region
  • 8012:region-id —This hub
  • 8000:1—Global spoke community.
  • 8001 + hub-site-id, 8002 + hub-site-id, and so forth—Prioritize traffic towards hubs
  • 8010:spoke-community—Spoke-to-spoke-direct community
  • 8011:region-id—Any device in region
  • 8000:2—Global spoke-to-hub community
AS path prepend None None

Toward LAN BGP only:

  • No AS prepending for routes with community 8001
  • Routes with community 8002 prepend last AS once; routes with community 8003 prepend last AS twice; and so forth
None

Exporting Routes in a Full-Mesh Topology

When exporting from the local device's routing table to the SD-WAN network in a full-mesh topology, Versa SD-WAN assigns BGP attributes as follows:

  • Global VRF ID—Assign randomly the VRF is created.
  • Route distinguisher—global-vrf-idL:site-id
    • Example
      global-vrf-id 4
      site-id 8
      Route distinguisher 4L:8
  • Route target—target:vrf-idL:vrf-id
    • Example
      vrf-id 6
      Route target target:6L:6
  • Community—No communities are attached.
  • AS prepend—None.

Exporting Hub LAN Routes

When exporting hub LAN routes from the local device's routing table to the SD-WAN network, Versa SD-WAN assigns BGP attributes as follows:

  • Global VRF ID—Assign randomly when the VRF is created.
  • Route distinguisher—8000 + global-vrf-idL:site-id
    • Example
      global-vrf-id 32
      site-id 9
      Route distinguisher 8032L:9
  • Route target—Three route targets are attached:
    • target:8000 + vrf-idL:site-id
      • Example
        vrf-id 4
        site-id 8
        Route target target:8004L:8
    • Route target for the global community to identify the device as a hub so that all other hubs can import routes from it—target:vrf-idL:0
      • Example
        vrf-id 420
        Route target target:420L:0
    • target:global-vrf-idL:global-vrf-id
      • Example
        global-vrf-id 419
        Route target target:419L:419
  • Community
    • 8009:8010—Hub global community for hub LAN routes. All the hub’s LAN routes have this community.
    • 8012:site-id—Identify this specific hub device among other hubs; unique to each hub.
    • For regional deployments:
      • 8011:region-id —Identify any device in this region.
      • 8012:region-id—Identify a hub in this region.
  • AS prepend—None.

Exporting Hub Routes Redistributed from Spokes

When exporting hub routes that have been redistributed from spokes, Versa SD-WAN devices assigns BGP attributes as follows:

  • Global VRF ID—Hub's LAN global-vrf-id + 16000
    • Example
      Hub's LAN global-vrf-id 450
      Global VRF ID 16450
  • Route distinguisher—16000 + global-vrf-idL:site-id
    • Example:
      global-vrf-id of export VR 16020
      site-id 8
      Route distinguisher 16020L:8
  • Route target—Two route targets are attached:
    • target:16000 + vrf-idL:site-id
      • Example
        vrf-id 13
        site-id 8
        Route target target:16013L:8
    • Route target for the global community to identify the device as a hub so that all other hubs can import routes from it—target:16000 + vrf-idL:0
      • Example
        vrf-id 16421
        Route target target:16421L:0
  • Community
    • 8000:0—Route originated on a spoke and was re-advertised by a hub.
    • For regional deployments:
      • 8011:region-id —Identify any device in this region.
      • 8012:region-id—Identify a hub in this region.
  • AS prepend—Towards LAN BGP only:
    • Routes with community 8001 perform no AS prepending.
    • Routes with community 8002 prepend the last AS once, with community 8003 prepend the last AS twice, with community 8004 prepend the last AS three times, and so forth.
    • Note that Versa supports a maximum of 8 hubs.

Exporting Spoke Routes

When exporting routes from the local spoke device's routing table to the SD-WAN network, the Versa SD-WAN software assigns BGP attributes as follows:

  • Global VRF ID—Assign randomly when the VRF is created.
  • Route distinguisher—global-vrf-idL:site-id
    • Example
      global-vrf-id 5
      site-id 15
      Route distinguisher 5L:15
  • Route target—target:vrf-idL:vrf-id
    • Example
      vrf-id 22
      Route target 22L:22
  • Community
    • 8000:1—Global spoke community.
    • To set the priority of hubs to use for routes to the spoke, the spoke uses the following method:
      • To give higher priority for traffic to the spoke to go through the first hub, that is, to prefer the first hub, add community 8001 + hub-site-id
      • To give the next lower priority to a hub, add community 8002 + hub-site-id; and so forth.
      • Example
        Hub 1 site ID 805
        Hub 2 site ID 806
        To have spoke spoke traffic go through hub 1 as primary hub and hub 2 as secondary hub, add these communities “8001:805 8002:806”
    • For spoke-to-spoke-direct topologies:
      • 8010:spoke-community
      • Example
        Spoke device community 100
        Export community 8010:100
    • For regional deployments:
      • 8011:region-id—Identify any device in this region.
    • For spoke-to-hub-only topologies only
      • 8000:2—Global spoke-to-hub community.
  • AS prepend—None.

Import Filtering Rules

When importing into the local device's routing table from the SD-WAN network, Versa SD-WAN software uses the following filtering rules.

Importing Routes on Full-Mesh Topology Devices

When importing routes on devices configured in a full-mesh topology, all routes are imported with no filtration except for the following:

  • Route target import settings—Import routes as follows:
    • Import all routes with target:vrf-idL:vrf-id so that all routes from the local VRF are processed next and filtered based on regular BGP communities.
    • Deny everything else.

Note that because almost all routes are imported, it is recommended that you do not mix full-mesh topology devices with hub-and-spoke technology devices.

Importing Routes on Hub Devices into the LAN VRF

When importing routes into the hub's LAN VRF, the routes are filtered as follows:

  • Communities—Apply the following rules in order. The first rule that matches is executed, and all subsequent rules are ignored.
    1. Reject all routes from itself, based on the community 8012:site-id.
    2. Reject all routes that have already been re-advertised by other hubs, based on the community "8000:0". If you see the community “8000:0” twice in the same route, this means that it was first advertised by a local hub and then re-advertised by a hub in another region. Rejecting this route avoids going through another region as a transit region.
    3. Reject all routes that originated from any hub’s LAN VR and were re-advertised through the export VR, based on the presence of both the 8009:8010 and 8000:0 communities.
    4. Accept routes from other hubs that carry LAN routes from the LAN VR or spoke routes from the export VR, based on either the 8000:0 or 8009:8010 community. For all routes based with these communities, set the local preference to 99.
    5. Allow all remaining routes with the local region’s community, based on the community 8011:region-id.
    6. Reject all other spokes from other regions by filtering everything, based on matching community 8011:*.
    7. Allow all other routes, assuming they come from full-mesh devices.
  • Route target import settings—Import routes as follows:
    • Import all routes with target:vrf-idL:vrf-id so that all routes from the local VRF are processed next and filtered based on regular BGP communities.
    • Import all routes from other hubs. The system statically allows only routes based on target:16000+vrf-id:0, which corresponds to all hubs.
    • Deny everything else.
  • Attach communities on all routes imported from SD-WAN routes—Attach community 8009:8009.

Importing Routes from the LAN VRF into the Export-LAN VRF

When redistributing routes from the hub LAN-VR into the hub Export-LAN VRF, which are then advertised to spokes, the routes are filtered as follows:

  • Communities—Apply the following rules in order. The first rule that matches is executed, and all subsequent rules are ignored.
    1. Reject all routes from the local region, based on the community 8012:region-id.
    2. Allow all spoke routes, based on the community 8000:1.
    3. Allow routes from other regional hubs, based on the community 8009:8010.
  • Extended communities (route targets)—Apply no filtering rules.
  • Attach communities on all routes imported from SD-WAN routes—Attach no communities.

Importing Routes on Spoke Devices

When importing routes on spoke devices, the routes are filtered as follows:

  • Communities—Apply the following rules:
    • For spoke-to-hub-only topologies only—Reject routes with community 8000:1 or 8000:2 so as not to import routes from other spokes.
    • For spoke-to-spoke via hub topologies only— Reject routes with community 8000:1 to block routes from other spokes and to install only hub routes.
    • For spoke-to-spoke-direct routes only—Allow routes from other spokes in the same spoke group, based on community 8010:spoke-community. One affect of this is that devices in different regions but with the same spoke community can communicate with each other.
  • Extended communities (route targets)—Import filtering occurs in two circumstances;
    • BGP import rules in the control VR—Set a priority in the route based on the hub’s extended community. This rule is statically configured for all spoke groups.
      For example:
      • Hub 1 has extended communities target:16419L:659 and target:8419L:659.
      • Hub 2 has extended communities target:16419L:660 and target:8419L:660.
      • Two rules are applied:
        • Match on both route targets from Hub 1 and set the local preference to 102.
        • Match on both route targets from Hub 2, and set the local preference to 101.
    • Route target import settings—Import routes as follows:
      • Import all routes with target:vrf-idL:vrf-id so that all routes from the local VRF are processed next and filtered based on regular BGP communities.
      • Import all routes from hubs in the local spoke group. The system statically allows only routes specified in the spoke group hubs, based on target:16000+vrf-id:site-id.
      • Deny everything else.
  • Attach communities on all routes imported from SD-WAN routes—Attach community 8009:8009.

Supported Software Information

Releases 21.2.1 and later support all content described in this article.

  • Was this article helpful?