Versa SD-WAN Topology Constructs Based on BGP Attributes

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.

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.