Intersite L3Out

Intersite L3Out Overview

Prior to Release 2.2(1), each site managed by the Nexus Dashboard Orchestrator required its own local L3Out configured in order to route traffic out of the fabric, which often resulted in lack of communication between endpoints in one site and a service (such a firewall, server load balancer, or mainframe) connected to the L3Out of another site.

Release 2.2(1) adds a feature that enables a number of scenarios in which endpoints located in one site are able to establish connectivity with entities, such as external network, mainframe, or service nodes, reachable through a remote L3Out.

These include the following:

  • L3Out across sites—endpoints in an application EPG in one site using an L3Out in another site (both part of the same VRF).

  • Intersite transit routing—establishing communication between entities (such as endpoints, network devices, service nodes) connected behind L3Outs deployed in different sites (both L3Outs part of the same VRF).

  • Shared services for intersite L3Out—application EPG to remote L3Out or intersite transit routing.

The following sections are divided into the generic GUI procedures you can follow to create the objects required to implement intersite L3Out use cases followed by overview and workflows specific to each supported use case scenario.


Note

The term "intersite L3Out" refers to the functionality allowing communication to external resources reachable via the L3Out connection of a remote site. However, in this document, the term may also be used to indicate the specific remote L3Out object.

Intersite L3Out Guidelines and Limitations

When configuring intersite L3Out, you must consider the following:

  • Intersite L3Out is supported for IPv4 and IPv6.

  • With intersite L3Out, in addition to the BGP eVPN sessions that are always established between sites in Multi-Site topology, MP BGP VPNv4 (or VPNv6) sessions are created to support the intersite L3Out feature.

  • If you are upgrading from a release prior to Release 2.2(1), any existing External EPG to L3Out association at the site-local level will be preserved. In addition, the Nexus Dashboard Orchestrator will now support creation of an L3Out and associating it with an External EPG at the template level.

    When creating a new L3Out in a schema template and associating it to an existing External EPG:

    • If the L3Out has the same name as the L3Out already defined in the APIC, the Orchestrator will take ownership of that L3Out but will not manage the configuration of L3Out node profiles, interface profiles, protocol settings, or route control settings.


      Note

      If the L3Out already exists in APIC, we recommend importing it into Nexus Dashboard Orchestrator along with any associated external EPG instead of creating a new L3Out with the same name from NDO.

      If you then choose to delete this L3Out from the Orchestrator, it will no longer be managed by the Orchestrator, but any previously existing L3Out configuration will be preserved in the APIC.

    • If the L3Out has a different name than the APIC defined L3Out the external EPG will be removed from the APIC defined L3Out and added to the L3Out defined in the Orchestrator. If this is the only external EPG under the APIC defined L3Out this can cause the configuration to be removed from the border leaves and can impact traffic.

  • If you choose to downgrade to a release prior to Release 2.2(1), the L3Outs created in the Orchestrator NDO will no longer exist in the template so any template-level association between External EPG and L3Out will be removed. In this case, you will need to manually re-configure the External EPG to L3Out association at the site-local level. Any site-local associations will be preserved during the downgrade.

  • You can now associate a bridge domain in one site with the L3Out in another site, however they must both be in the same VRF.

    This association is performed at the site-local level and is required to advertise the BD subnet out of the remote L3Out and ensure that inbound traffic to the BD can be maintained even if the local L3Out failed.

  • The Policy Control Enforcement direction for the VRF associated to the intersite L3Out must be kept configured in the default ingress mode.

  • The following scenarios are not supported with intersite L3Out and remote leaf (RL):

    • Transit routing between L3Outs deployed on RL pairs associated to separate sites

    • Endpoints connected to a RL pair associated to a site communicating with the L3Out deployed on the RL pair associated to a remote site

    • Endpoints connected to the local site communicating with the L3Out deployed on the RL pair associated to a remote site

    • Endpoints connected to a RL pair associated to a site communicating with the L3Out deployed on a remote site

  • The following other features are not supported with intersite L3Out in Multi-Site:

    • Multicast receivers in a site receiving multicast from an external source via another site L3Out. Multicast received in a site from an external source is never sent to other sites. When a receiver in a site receives multicast from an external source it must be received on a local L3Out.

    • An internal multicast source sending multicast to an external receiver with PIM-SM any source multicast (ASM). An internal multicast source must be able to reach an external Rendezvous Point (RP) from a local L3Out

    • GOLF

    • Preferred Groups for External EPG

Configuring External TEP Pool

Intersite L3Out requires a external TEP address for the border leaf switches in each pod. If you already have an external TEP pool configured, for example for another feature such as Remote Leaf, the same pool can be used. The existing TEP pool will be inherited by the Nexus Dashboard Orchestrator and shown in the GUI as part of the infra configuration. Otherwise, you can add a TEP pool in the GUI, as described in this section.


Note

Every pod must be assigned a unique TEP pool and it must not overlap with any other TEP pool in the fabric

Procedure

Step 1

Log in to your Nexus Dashboard Orchestrator.

Step 2

In the left navigation menu, select Infrastructure > Site Connectivity.

Step 3

In the top right of the main pane, click Configure.

Step 4

In the left sidebar, select the site you want to configure.

Step 5

In the main window, click a pod in the site.

Step 6

In the right sidebar, click +Add TEP Pool.

Step 7

In the Add TEP Pool window, specify the external TEP pool you want to configure for that site.

Note

 

You must ensure that the TEP pool you are adding does not overlap with any other TEP pools or fabric addresses.

Step 8

Repeat the process for each site and pod where you plan to use intersite L3Outs.

Creating or Importing Intersite L3Out and VRF

This section describes how to create an L3Out and associate it to a VRF in the Orchestrator GUI, which will then be pushed out to the APIC site, or import an existing L3Out from one of your APIC sites. You will then associate this L3Out with an external EPG and use that external EPG to configure specific intersite L3Out use cases.


Note

The VRF you assign to the L3Out can be in any template or schema, but it must be in the same tenant as the L3Out.

Procedure

Step 1

Log in to your Nexus Dashboard Orchestrator.

Step 2

From the left navigation pane, select Application Management > Schemas.

Step 3

Select the schema and then the template where you want to create or import the VRF and L3Out.

We recommend creating the L3Out in a template that is associated with a single site, in which case the L3Out will be created in that site only.

Alternatively, you can choose to create the L3Out in a template that is associated to multiple sites. In this case the L3Out will be created with the same name across all sites, which may bring some functional restrictions, as explained later in this chapter

Step 4

Create a new VRF and L3Out.

If you want to import an existing L3Out, skip this step.

Note

 

While you can create the L3Out object in the Orchestrator and push it out to the APIC, the physical configuration of the L3Out must be done in the APIC.

  1. Scroll down to the VRF area and click the + icon to add a new VRF.

    If you already have the VRF you plan to use for the L3Out, skip this substep.

    In the right sidebar, provide the name for the VRF, for example vrf-l3out

  2. Scroll down to the L3Out area and click the + icon to add a new L3Out.

    In the right sidebar, provide the required information.

  3. Provide the name for the L3Out, for example l3out-intersite.

  4. From the Virtual Routing & Forwarding dropdown, select the VRF.

    Select the VRF you created in the first substep or choose a previously existing VRF.

Step 5

Import an existing VRF and L3Out.

If you created a new L3Out in previous step, skip this step.

Click Import in the main window pane to open at the

  1. At the top of the main template view, click Import.

  2. Select the site from which you want to import the L3Out.

  3. In the import window's Policy Type menu, select L3Out.

  4. Check the L3Out you want to import.

    By default, importing the L3Out will also import the corresponding VRF. This may not be desirable when importing the L3Out in a site specific template as you would typically define the VRF in a stretched template associated to multiple sites. In this case, disable the Include Relations option before importing the L3Out. In this case, you will also need to re-map the L3Out to the correct VRF after importing it.

  5. Click Import.

  6. If you imported only the L3Out, select it in the template view and associate it to the appropriate VRF.

Configuring External EPG to Use Intersite L3Out

This section describes how to create an external EPG that will be associated to the intersite L3Out. You can then use this external EPG and contracts to configure specific use cases for endpoints in one site to use an L3Out in another site.

Before you begin

Create the L3Out and associate it with a VRF as described in Creating or Importing Intersite L3Out and VRF.

Procedure

Step 1

Select the template where you want to create the external EPG.

If you create the external EPG in a template that is associated to multiple sites, the external EPG will be created on all of those sites. This is recommended when the external EPG's L3Outs provide access to a set of common external resources, for example the WAN.

If you create the external EPG in a template that is associated with a single site, the external EPG will be created in that site only. This is recommended when the external EPG's L3Out provides access to external resources accessible only from that site.

Step 2

Scroll down to the External EPG area and click the + icon to add an external EPG.

In the right sidebar, provide the required information.

  1. Provide the name for the external EPG, for example eepg-intersite-l3out.

  2. From the Virtual Routing & Forwarding dropdown, select the VRF you created and used for the L3Out.

Step 3

Map the external EPG to the L3Out.

You can map the external EPG to an L3Out at the site level or at the template level. We recommend creating the mapping at the site level because commonly each site defines a local L3Out with a unique name so the external EPG can be selectively mapped to each site specific L3Out independent of whether the external EPG itself is stretched.

To associate an L3Out with the external EPG at the site-local level:

  1. In the left sidebar of the schema view, select the site where the external EPG is deployed.

  2. Scroll down to the External EPG area and select the external EPG.

  3. In the right sidebar, scroll down to the L3Out dropdown and choose the intersite L3Out you created.

    In this case, both the APIC-managed and the Orchestrator-managed L3Outs will be available for selection. You can select either the L3Out you have created in the previous section specifically for this or pick an L3Out that exists in the site's APIC.

Alternatively, you can map the external EPG to an L3Out at the template level. While this could ease the configuration in deployments where multiple sites have defined the same L3Out name, we do not recommend this approach as it allows less flexibility for the type of connectivity that can be established between the fabrics that are part of the Multi-Site domain and the external routed network. For example, it would not be possible to control where a specific BD's subnets are advertised because mapping the BD to the L3Out would cause the BD subnet to be advertised out of all the L3Outs in all the sites since all the L3Outs have the same name.

To associate an L3Out with the external EPG at the template level:

  1. In the left sidebar of the schema view, select the template where the external EPG is located

  2. Scroll down to the External EPG area and select the external EPG.

  3. In the right sidebar, scroll down to the L3Out dropdown and choose the intersite L3Out you created.

In addition, it is possible to migrate the configuration of an external EPG initially associated to the L3Out at the template level to a site-level mapping by removing the VRF association on the external EPG, re-associating the external EPG to the same VRF, then mapping the L3Outs at the site level. If this process is completed at once before deploying the template, there would be no traffic impact when pushing the new configuration as no changes are actually applied on the APIC side.

Step 4

Configure one or more subnets for the external EPG.

  1. Select the external EPG.

  2. In the right sidebar, click +Add Subnet.

  3. In the Add Subnet window, provide the classification subnet and the required options.

    The prefixes and options you configure depend on the specific use cases:

    • To classify the inbound traffic as belonging to the external EPG, select the External Subnets for External EPG flag for the specified prefix. Depending on the specific use case, this allows you to apply a contract with an internal EPG or with the external network domain reachable via a remote L3Out.

    • To advertise the external prefixes learned from another L3Out (in the same site or in a remote site) out of this L3Out, select the Export Route Control flag for the specified prefix. When specifying the 0.0.0.0/0 prefix, the Aggregate Export flag can be selected to advertise all prefixes out of the L3Out; if the Aggregate Export flag is not enabled, only the default route 0.0.0.0/0 would be advertised, if present in the routing table of the border leaf nodes.

    • To filter out specific routes received from the external network, select the Import Route Control flag for the specified prefix. If specifying the 0.0.0.0/0, you can also choose the Aggregate Import option.

      Note that this is possible only when peering BGP with the external routers.

    • To leak routes to different VRFs, select the Shared Route Control and the associated Aggregate Shared Routes flags, as well as the Shared Security Import flag. These options are required for the specific use case of inter-VRF shared L3Out and inter-VRF intersite transit routing.

Creating a Contract for Intersite L3Out

This section describes how to create a filter and a contract you will use to enable communication between an application EPG deployed in a site and the external EPG associated to an L3Out in a different site (intersite L3Out functionality).

Procedure

Step 1

Select the template where you want to create contract and filter.

You can use the same schema and template where you created the L3Out, VRF, and the external EPG or you can choose a different schema and template.

Because the contract is applied to objects (EPGs and external EPGs) deployed in different sites, we recommend defining it in a template associated to multiple sites. However, this is not strictly required and even if the contract and filters are defined only as local objects in Site1, NDO will create the corresponding shadow objects in a remote Site2 when a local EPG or external EPG in Site2 needs to consume or provide that contract.

Step 2

Create a filter.

  1. In the middle pane, scroll down to the Filter area, then click + to create a filter.

  2. In the right pane, provide the Display Name for the filter.

  3. In the right pane, click + Entry.

Step 3

Provide the filter details.

  1. Provide the Name for the filter.

  2. Choose the Ether Type.

    For example, ip.

  3. Choose the IP Protocol.

    For example, icmp.

  4. Leave other properties unspecified.

  5. Click Save to save the filter.

Step 4

Create a contract

  1. In the middle pane, scroll down to the Contract area and click + to create a contract.

  2. In the right pane, provide the Display Name for the contract

  3. Select the appropriate Scope for the contract.

    If you plan to configure different VRFs for the intersite L3Out and application EPG, you must select tenant for the scope. Otherwise, if both are in the same VRF, you can set the scope to vrf.

  4. Toggle the Apply both directions knob if you want the same filter to apply for both consumer-to-provider and provider-to-consumer directions.

    If you enable this option, you will need to provide the filters only once and they will apply for traffic in both directions. If you leave this option disabled, you will need to provide two sets of filter chains, one for each direction.

Step 5

Assign the filters to the contract

  1. In the right pane, scroll down to the Filter Chain area and click + Filter to add a filter to the contract.

    If you disabled the Apply both directions option, repeat this stem for the other filter chain.

  2. In the Add Filter Chain window that opens, select the filter you added in previous step from the Name dropdown menu.

  3. Click Save to add the filter to the contract.

Use Cases

Intersite L3Out for Application EPGs (Intra-VRF)

This section describes the configuration required to allow endpoints that are part of an application EPG to communicate with the external network domain reachable through an L3Out deployed in another site but within the same VRF (intra-VRF).

The first figure below shows a stretched external EPG and the associated L3Outs which will be created in both sites. An application EPG (EPG1) is created in Site 1 and has a contract with the external EPG. This use case is recommended when the L3Outs in the separate sites provide access to a common set of external resources. It simplifies the policy definition and external traffic classification, while still allowing you to apply route-map policies separately on each L3Out for the independent APIC domains.

Figure 1. Stretched External EPG

The second figure below shows a similar use case but with the external EPG being deployed to only the site where the physical L3Out is located. The application EPG and the contract are configured in the same exact way to allow the traffic flow between the EPG in one site and the physical L3Out in the other.

Figure 2. Non-Stretched (Site-Local) External EPG

The following steps describe the configuration required to implement the use case shown in Figure 1, which represents the most common scenario. If you want to deploy the use case shown in Figure 2, you can adapt the procedure with minor changes.

Before you begin

You need to have the following already configured:

  • A schema with three templates.

    Create a template for each site (for example, template-site1 and template-site2 ) where you will configure the objects unique to that site, such as the application EPG and the L3Outs. In addition, create a separate templates (for example, template-stretched ) that you will use for the stretched objects, which in this case will be the external EPG.

  • The L3Outs in each site, as described in the Creating or Importing Intersite L3Out and VRF section.

    In this use case, a separate L3Out will be imported or created in each site-specific template.

  • The external EPG for the intersite L3Out, as described in Configuring External EPG to Use Intersite L3Out.

    In this use case, the external EPG is configured as a stretched object that is defined in the stretched template (template-stretched). Assuming that the external EPG provides access to the entire external address space, we recommend configuring a 0.0.0.0/0 prefix for classification to avoid specifying a long list of more specific prefixes.

  • The contract you will use between the application EPG and the L3Out external EPG, as described in Creating a Contract for Intersite L3Out.

    We recommend creating the contract and the filter in the stretched template (template-stretched).

Procedure

Step 1

Log in to your Nexus Dashboard Orchestrator.

Step 2

From the left navigation pane, select Application Management > Schemas.

Step 3

Select the schema and template for the application EPG and bridge domain.

In this use case, you will associate the template to Site1.

Step 4

Configure an application EPG and its bridge domain belonging to the same VRF as the L3Out.

If you already have an EPG that will use the intersite L3Out, you can skip this step.

You can create a new or import an existing EPG and bridge domain as you typically would.

Step 5

Assign the contract to the application EPG.

  1. Select the EPG.

  2. In the right sidebar, click +Contract.

  3. Select the contract you created in previous section and its type.

    You can choose whether the application EPG is the consumer or the provider.

Step 6

Assign the contract to the external EPG mapped to the remote L3Out.

  1. Select the template-stretched where the external EPG is located.

  2. Select the external EPG.

  3. In the right sidebar, click +Contract.

  4. Select the contract you created in previous section and its type.

    If you chose the application EPG to be the consumer, choose provider for the external EPG. Otherwise, choose consumer for the external EPG.

Step 7

Associate the application EPG's bridge domain with the L3Out.

This enables the BD subnet to be advertised out of the L3Out toward the external network domain. Note that the subnet(s) associated to the BD must be configured with the Advertised Externally option to be advertised out of the L3Out

  1. In the left sidebar, under Sites, select the application EPG's template.

  2. Select the bridge domain associated with the application EPG.

  3. In the right sidebar, click +L3Out.

  4. Select the intersite L3Out you created.

    For the use case shown in Figure 1, associate the BD to both the L3Outs defined in Site1 and Site2 to ensure that the external network can have access to the EPG from both paths. Specific policies can be associated to the L3Out or to the external routers to ensure that a specific L3Out path is normally preferred for inbound traffic. We recommend this when the EPG and BD are local to a site (as in the specific example) to avoid suboptimal inbound traffic path via the remote site's L3Out.

Step 8

Deploy the schema.

Shared Services with Intersite L3Out for Application EPGs (Inter-VRF)

This section describes the configuration required to allow endpoints that are part of an application EPG in one VRF to communicate with the external network domain reachable through an L3Out deployed in another site and different VRF, this is also known as "Shared Services".

This scenario is recommended when the L3Outs in separate sites provide access to a common set of external resources. It simplifies the policy definition and external traffic classification, while still allowing you to apply route-map policies separately on each L3Out for the independent APIC domains.

Figure 3. Stretched External EPG, Site-Local L3Outs and Application EPGs

The following steps describe the configuration required to implement the use case shown in Figure 3.

Before you begin

You need to have the following already configured:

  • A schema with three templates.

    Create a template for each site (for example, template-site1 and template-site2 ) where you will configure the objects unique to that site, such as the application EPGs and the L3Outs. In addition, create a separate templates (for example, template-stretched ) that you will use for the stretched objects, which in this case will be the external EPG.

  • The L3Outs in each site, as described in the Creating or Importing Intersite L3Out and VRF section.

    In this use case, a separate L3Out will be imported or created in each site-specific template.

  • The external EPG for the intersite L3Out, as described in Configuring External EPG to Use Intersite L3Out.

    In this use case, the external EPG is configured as a stretched object that is defined in the stretched template (template-stretched). Assuming that the external EPG provides access to the entire external address space, we recommend configuring a 0.0.0.0/0 prefix for classification to avoid specifying a long list of more specific prefixes.

    For this specific shared services use case, you are also required to enable the Shared Route Control and the Shared Security Import flags for the subnet(s) associated to the external EPG(s) of the remote L3Out. If you are using the 0.0.0.0/0 prefix for classification on the external EPG, in addition to the Shared Route Control flag, also enable the Aggregate Shared Routes flag.

  • The contract you will use between the application EPG and the L3Out external EPG, as described in Creating a Contract for Intersite L3Out.

    We recommend creating the contract and the filter in the stretched template (template-stretched).

Procedure

Step 1

Log in to your Nexus Dashboard Orchestrator.

Step 2

From the left navigation pane, select Application Management > Schemas.

Step 3

Select the schema and template for the application EPG and bridge domain.

In this use case, you will associate the template to Site1.

Step 4

Configure an application EPG and its bridge domain belonging to a separate VRF from the L3Out's.

If you already have an EPG that will use the intersite L3Out, you can skip this step.

You can create a new or import an existing EPG and bridge domain as you typically would.

Step 5

Assign the contract to the application EPG.

  1. Select the EPG.

  2. In the right sidebar, click +Contract.

  3. Select the contract you created in previous section and its type.

    You can choose whether the application EPG is the consumer or the provider.

    Note

     

    If the application EPG is configured as provider, you need to configure the subnet already defined under the BD also under the EPG in order to leak that route into the L3Out VRF. The same flags used under the BD for the subnet should also be set under the EPG. In addition to that, for the subnet under the EPG the flag No default SVI Gateway should also be enabled, since the default gateway function is enabled at the BD level.

Step 6

Assign the contract to the external EPG mapped to the L3Outs.

  1. Select the template-stretched where the external EPG is located.

  2. Select the external EPG.

  3. In the right sidebar, click +Contract.

  4. Select the contract you created in previous section and its type.

    If you chose the application EPG to be the consumer, choose provider for the external EPG. Otherwise, choose consumer for the external EPG.

Step 7

Associate the application EPG's bridge domain with the L3Out.

This enables the BD subnet to be advertised out of the L3Out toward the external network domain. Note that the subnet(s) associated to the BD must be configured with the Advertised Externally option to be advertised out of the L3Out

  1. In the left sidebar, under Sites, select the application EPG's template.

  2. Select the bridge domain associated with the application EPG.

  3. In the right sidebar, click +L3Out.

  4. Select the intersite L3Out you created.

    For the use case shown in Figure 1, associate the BD to both the L3Outs defined in Site1 and Site2 to ensure that the external network can have access to the EPG from both paths. Specific policies can be associated to the L3Out or to the external routers to ensure that a specific L3Out path is normally preferred for inbound traffic. We recommend this when the EPG and BD are local to a site (as in the specific example) to avoid suboptimal inbound traffic path via the remote site's L3Out.

Step 8

Deploy the schema.

Intersite Transit Routing

This section describe the use cases where the Multi-Site domain acts as a distributed router allowing communication between entities (endpoints, network devices, service nodes, etc.) connected behind L3Outs deployed in different sites, a functionality normally referred to as intersite transit routing. The intersite transit routing is supported for intra-VRF as well as inter-VRF use cases.

The figure below shows two L3Outs (L3Out1 and L3Out2) configured in different sites. Each L3Out is associated with a respective external EPG (External EPG1 and External EPG2). A contract between the two external EPGs allows communication between entities connected behind two different L3Outs in two different sites.

Figure 4. Intra-VRF Intersite Transit Routing

A similar configuration can be used when each site's L3Outs are in different VRFs.

Figure 5. Inter-VRF Intersite Transit Routing

The figures above show the two scenarios where the external EPGs and associated L3Outs are deployed as site-local objects; intersite transit routing can support all the combinations where neither external EPG is stretched, one of them is stretched, or both are stretched between sites.

When deploying intersite transit routing, the assumption is that the different external EPGs defined across sites are providing access to different external address spaces (obviously not overlapping). A couple of options are hence possible for the configuration of the prefix used for classification:

  • Define the same 0.0.0.0/0 prefix on both external EPGs to ensure that inbound traffic received on the border leaf nodes of L3Out1 gets mapped to Ext-EPG1, whereas inbound traffic received on L3Out2 gets mapped to Ext-EPG2. Because the L3Outs are defined in separate fabrics, there are no conflict issues with this configuration.

    The external prefixes received on L3Out1 must be advertised out of L3Out2 and vice versa. If you are using 0.0.0.0/0 as classification subnet on both external EPGs, it is sufficient to enable the Export Route Control and the Aggregate Export flags.

  • Define specific prefixes for each external EPG. In this case, you must ensure that the prefixes are not overlapping to avoid a fault from being raised by the site's APIC when the shadow external EPG is created in that site for a contract between the local and remote external EPGs.

    When using specific prefixes, the same prefixes configured for classification on External EPG1 must be configured with the Export Route Control flag set on External EPG2 and vice versa.


Note

No matter which of the two classification approaches you deploy, for the inter-VRF scenario you must also set the Shared Route Control (in addition to Aggregate Shared Routes if using 0.0.0.0/0) and the Shared Security Import flags.

Before you begin

You need to have the following already configured:

  • A schema with three templates.

    Create a template for each site (for example, template-site1 and template-site2 ) where you will configure the objects unique to that site, such as the application EPGs and the L3Outs. In addition, create a separate templates (for example, template-stretched ) that you will use for the stretched objects, which in this case will be the external EPG.

  • The L3Outs in each site, as described in the Creating or Importing Intersite L3Out and VRF section.

    In this use case, a separate L3Out will be imported or created in each site-specific template.

  • Two different external EPGs for two different L3Outs in different sites. You can use the same procedure to create both external EPGs, as described in Configuring External EPG to Use Intersite L3Out.

  • The contract you will use between the L3Out external EPGs defined in each site, as described in Creating a Contract for Intersite L3Out.

    We recommend creating the contract and the filter in the stretched template (template-stretched).

Procedure

Step 1

Log in to your Nexus Dashboard Orchestrator.

Step 2

From the left navigation pane, select Application Management > Schemas.

Step 3

Assign the contract to one of the external EPGs.

  1. Select the schema and template where the external EPG is located.

  2. Select the external EPG.

  3. In the right sidebar, click +Contract.

  4. Select the contract you created in previous section and its type.

    Choose consumer or provider.

Step 4

Assign the contract to the other external EPG.

  1. Select the schema and template where the external EPG is located.

  2. Browse to the template where the external EPG is located.

  3. Select the external EPG.

  4. In the right sidebar, click +Contract.

  5. Select the contract you created in previous section and its type.

    Choose provider or consumer.

Step 5

Deploy the templates to appropriate sites.