A Switched Virtual Interface (SVI) is a virtual local area network (VLAN) of switch ports that have a single interface to a routing or bridging system. In the context of a Layer 3 Out (L3Out) configuration, you configure an (SVI) to provide connectivity between the Cisco Application Centric Infrastructure (ACI) leaf switch and a router.

By default, when you configure a single L3Out with SVI interfaces, the VLAN encapsulation spans multiple nodes within the fabric. The spanning occurs because the Cisco ACI fabric configures the same bridge domain (VXLAN VNI) across all the nodes in the fabric where the L3Out SVI is deployed. The bridge domain configuration occurs as long as all SVI interfaces use the same external encapsulation (SVI). However, when different L3Outs are deployed, the Cisco ACI fabric uses different bridge domains even if they use the same external encapsulation (SVI).

Note

Beginning with Cisco Application Policy Infrastructure Controller (APIC) Release 5.1(1), Cisco APIC supports a dual stack on SVI networks; that is, it now supports IPv6 and IPv4 connections. This feature enables Border Gateway Protocol (BGP) peering over L3Outs for IPv6 routes and IPv4 routes if you enable them. See the section Configure SVI Integration with Dual-Stack IP Addressing.

OpenStack supports dual-stack IP addressing—the ability configure IPv4 and IPv6 traffic at the same time—on Switched Virtual Interface (SVI) networks. Using dual-stack IP addressing provides the advantages of IPv6—increased network efficiency and larger address space—while supporting hosts or applications that do not support IPv6.

Because of dual-stack IP addressing, the Cisco Application Centric Infrastructure (ACI) ML2 plug-in adds support for Border Gateway Protocol (BGP) peering for IPv6 connections and IPv4 connections if you enable BGP. OpenStack previously supported BGP peering for IPv4 connections.

Configuring SVI integration with dual-stack IP addressing is similar to configuring SVI integration without dual-stack. With IPv4 only, you create an SVI-type network, define a static IP address for the leaf switch, and enable DHCP. However, for dual-stack, you add both IPv4 and IPv6 subnets to the SVI-type network. You can have only one IPv4 subnet and one IPv6 subnet on the SVI network.

Adding subnets creates a bound DHCP port on Cisco Application Policy Infrastructure Controller (APIC). Bringing up a virtual machine (VM) also creates a bound port on Cisco APIC. The presence of a bound port, regardless of origin, prompts the OpenStack plug-in to create the required interface profiles. The profiles enable traffic to flow through the leaf switch.

To use BGP peering, you must enable BGP on the Neutron network creation command. For example:

neutron net-create LBSVI --provider:network_type vlan \
--provider:physical_network physnet1 --apic:svi True --apic:bgp_enable True \
--apic:bgp_asn 2010

The option --apic:bgp_asn 2010 prepares the Layer 3 outside connection (L3Out) definition for BGP peering to the OpenStack workload. BGP configuration on the L3Out is dynamically configured only when the first OpenStack virtual machine (VM) is attached to this Neutron network. Until VMs exist, the SVI and related BGP configuration does not exist in Cisco Application Centric Infrastructure (ACI).

Note	You must manually define the BGP configuration on the OpenStack workload because it is outside of the ACI ML2 plug-in control.

This section describes how to troubleshoot SVI networks.

• Make sure that the l3 domain DN is configured properly. The l3 domain DN pointing to a working external routed domain in APIC in the neutron config file and neutron-server has been restarted on all the controller nodes.

• Make sure that there are no faults in either the pre-existing l3-outs or the auto l3-outs created by our mechanism driver.

• Make sure that SVI interface is being created properly with the right path and the VLAN ID of the SVI network when DHCP or VM endpoints are getting created.

  • In a VPC setup, the primary IP of site A and site B will be allocated from the SVI subnet by our mechanism driver and consistent per VPC pair across the SVI interfaces. The secondary IP will always be the Gateway IP of the SVI subnet.

• Make sure that nodes are getting created properly under node profile in the l3-out.

  • When SVI interface is being created, our mechanism_driver will create the corresponding nodes also. The nodes info is in the SVI path itself. In a VPC setup, each SVI interface will have 2 nodes in its path.

• Bgp_asn parameter that is specified at the time of network create or update should be the same as the one used for peering by the guest machine acting as a bgp peer and it should not match the AS number that is used by ACI for internal fabric BGP peering. Also ensure that provider and consumer BGP peers have different AS numbers in order to redistribute routes from one peer to the other.

  Note	Directly connected subnets are never redistributed as is the common use case with eBGP. If needed, these subnets can be exported with an explicit permit route-map outside of openstack, by posting to APIC.

• Minimal config to establish BGP session and import/export prefixes that are learned by peering to other peers is exposed with openstack integration, for all advanced route-map/community/password configuration, use the APIC API directly.

• Use the aimctl manager command to debug if you think things should be created under that l3-out but you do not see it in APIC or vice versa.

  • Just type aimctl manager | grep out and aimctl manager | grep external then it will list all the l3-out and external-network related CLI commands available to use.

  • If sync_status shows some failure, check the /var/log/aim-aid.log file for more details.

Note	If you use OSP16 or later, you must execute the aimctl commands from inside the ciscoaci_aim container. The container can be entered from a controller node by running the following command: docker exec -itu root ciscoaci_aim bash. To exit the container, type exit.