Transit

Location in GUI: Provision » SD-Access » Transits

Diagram

Classes

fabric (catalyst_center)

Name	Type	Constraint	Mandatory	Default Value
transits	List	`[transits]`	No

transits (catalyst_center.fabric)

Name	Type	Constraint	Mandatory	Default Value
name	String		Yes
type	Choice	`IP_BASED_TRANSIT`, `SDA_LISP_PUB_SUB_TRANSIT`, `SDA_LISP_BGP_TRANSIT`	Yes	`IP_BASED_TRANSIT`
routing_protocol_name	Choice	`BGP`	No	`BGP`
autonomous_system_number	Integer	min: `1`, max: `4294967295`	No
multicast_over_sda_transit	Boolean	`true`, `false`	No	`false`
control_plane_devices	List	String	No
create_per_site	Boolean	`true`, `false`	No

Transits enable connectivity between SD-Access fabric sites or between a fabric site and external networks. Supported types include IP-based transits (over existing IP/WAN infrastructure) and SDA transits (LISP Pub/Sub or LISP BGP for native fabric-to-fabric connectivity with control plane devices). Transits are referenced by Layer 3 Handoffs on Border Devices. This resource is SDA fabric only.

Examples

Example-1: IP-Based Transit Configuration

This example demonstrates how to configure an IP-based transit for connecting SD-Access fabric sites across traditional IP networks. IP-based transits enable fabric-to-fabric connectivity over existing IP infrastructure without requiring dedicated LISP control plane devices, making them suitable for WAN connectivity and inter-site communication.

The IP-based transit configuration includes:

Transit name (IP_TRANSIT) for identification and policy assignment
Transit type (IP_BASED_TRANSIT) specifying traditional IP routing approach
BGP routing protocol for dynamic route exchange and path selection
Autonomous System Number (65100) for BGP peering and routing policy
Simple deployment model suitable for existing IP network infrastructure

catalyst_center:
  fabric:
    transits:
      - name: IP_TRANSIT
        type: IP_BASED_TRANSIT
        routing_protocol_name: BGP
        autonomous_system_number: 65100

Example-2: SD-Access LISP PUB SUB Transit Configuration

This example shows how to configure an SD-Access LISP BGP transit for native fabric-to-fabric connectivity with full LISP overlay support. SDA transits provide optimized inter-fabric communication with centralized control plane services and advanced SD-Access features.

The SDA LISP PUB SUB transit configuration includes:

Transit name (SDA_TRANSIT) for fabric interconnection
Transit type (SDA_LISP_PUB_SUB_TRANSIT) for native SD-Access overlay connectivity
Multicast support enabled for efficient multicast traffic distribution across fabrics
Control plane device specification (CONTROL01.cisco.eu and CONTROL02.cisco.eu) for LISP services
Advanced fabric services including policy propagation and mobility support

catalyst_center:
  fabric:
    transits:
      - name: SDA_TRANSIT
        type: SDA_LISP_PUB_SUB_TRANSIT
        multicast_over_sda_transit: true
        control_plane_devices:
          - CONTROL01.cisco.eu
          - CONTROL02.cisco.eu

Example-3: Multiple IP-Based Transits for Different Regions

This example demonstrates how to configure multiple IP-based transits for connecting fabric sites across different geographic regions with region-specific routing policies and autonomous system numbers.

catalyst_center:
  fabric:
    transits:
      - name: NORTH_AMERICA_TRANSIT
        type: IP_BASED_TRANSIT
        routing_protocol_name: BGP
        autonomous_system_number: 65001
      - name: EUROPE_TRANSIT
        type: IP_BASED_TRANSIT
        routing_protocol_name: BGP
        autonomous_system_number: 65002
      - name: ASIA_PACIFIC_TRANSIT
        type: IP_BASED_TRANSIT
        routing_protocol_name: BGP
        autonomous_system_number: 65003

Example-4: SDA Transit with Multiple Control Plane Devices

This example shows how to configure an SDA LISP BGP transit with multiple control plane devices for high availability and load distribution in large-scale fabric deployments.

catalyst_center:
  fabric:
    transits:
      - name: ENTERPRISE_SDA_TRANSIT
        type: SDA_LISP_BGP_TRANSIT
        control_plane_devices:
          - CONTROL01.cisco.eu
          - CONTROL02.cisco.eu

Example-5: Hybrid Transit Configuration for Mixed Environments

This example demonstrates how to configure both IP-based and SDA transits within the same environment for supporting different connectivity requirements and migration scenarios.

catalyst_center:
  fabric:
    transits:
      - name: LEGACY_IP_TRANSIT
        type: IP_BASED_TRANSIT
        routing_protocol_name: BGP
        autonomous_system_number: 65100

      - name: MODERN_SDA_TRANSIT
        type: SDA_LISP_PUB_SUB_TRANSIT
        multicast_over_sda_transit: true
        control_plane_devices:
          - CONTROL01.cisco.eu
          - CONTROL02.cisco.eu

Example-6: Service Provider SDA Transit Configuration

This example shows how to configure SDA transits for service provider environments with multicast support and multiple control plane devices for customer fabric interconnection.

catalyst_center:
  fabric:
    transits:
      - name: SP_CUSTOMER_A_TRANSIT
        type: SDA_LISP_PUB_SUB_TRANSIT
        multicast_over_sda_transit: true
        control_plane_devices:
          - SP_CONTROL01.provider.net
          - SP_CONTROL02.provider.net

      - name: SP_CUSTOMER_B_TRANSIT
        type: SDA_LISP_PUB_SUB_TRANSIT
        multicast_over_sda_transit: false
        control_plane_devices:
          - SP_CONTROL03.provider.net

Example-7: Campus-to-Data Center Transit Configuration

This example demonstrates how to configure transits for connecting campus fabric sites to data center fabrics with appropriate routing protocols and control plane distribution.

catalyst_center:
  fabric:
    transits:
      - name: CAMPUS_TO_DC_TRANSIT
        type: SDA_LISP_PUB_SUB_TRANSIT
        multicast_over_sda_transit: true
        control_plane_devices:
          - CAMPUS_CONTROL01.company.local
          - DC_CONTROL01.company.local

      - name: BRANCH_TO_DC_TRANSIT
        type: IP_BASED_TRANSIT
        routing_protocol_name: BGP
        autonomous_system_number: 65200

Example-8: Per-Site Transit Creation in Multistate Deployments

By default a transit is treated as a global object: it is created once in a global apply (manage_global_settings = true) and only referenced (via a data source lookup) in per-site applies (manage_global_settings = false with a non-empty managed_sites). Setting create_per_site: true makes the module create the transit from the site state itself, which is useful when each site owns a unique transit defined in that site’s data. Flagged transit names are excluded from the transit data source lookup, so the per-site apply no longer errors trying to read a not-yet-created transit. The transit name must be unique to the site’s data (do not reuse the same flagged transit name across multiple site states).

create_per_site applies only to IP_BASED_TRANSIT, which requires no control plane devices and is therefore safe to create from a site state. It is ignored for the SDA transit types (SDA_LISP_PUB_SUB_TRANSIT, SDA_LISP_BGP_TRANSIT), which depend on provisioned control plane devices and remain global (created in a global apply and referenced per-site).

catalyst_center:
  fabric:
    transits:
      - name: SITE_A_IP_TRANSIT
        type: IP_BASED_TRANSIT
        routing_protocol_name: BGP
        autonomous_system_number: 65010
        create_per_site: true