Lists the controls that can be enabled for subnets configured under the L3Out Network Instance Profile.
These controls can be enabled for the subnets that are configured under the L3Out Network Instance Profile.
|
Route control Setting |
Use |
Options |
|---|---|---|
|
Export Route Control |
Controls which external networks are advertised out of the fabric using route-maps and IP prefix lists. An IP prefix list is created on the BL switch for each subnet that is defined. The export control policy is enabled by default and is supported for BGP, EIGRP, and OSPF. |
Specific match (prefix and prefix length). |
|
Import Route Control |
Controls the subnets that are allowed into the fabric. Can include set and match rules to filter routes. Supported for BGP and OSPF, but not for EIGRP. If you enable the import control policy for an unsupported protocol, it is automatically ignored. The import control policy is not enabled by default, but you can enable it on the Create L3Out panel. On the Identity tab, enable Route Control Enforcement: Import. |
Specific match (prefix and prefix length). |
|
Security Import Subnet |
Used to permit the packets to flow between two prefix-based EPGs. Implemented with ACLs. |
Uses the ACL match prefix or wildcard match rules. |
|
Aggregate Export |
Used to allow all prefixes to be advertised to the external peers. Implemented with the 0.0.0.0/ le 32 IP prefix-list. |
Only supported for 0.0.0.0/0 subnet (all prefixes). |
|
Aggregate Import |
Used to allow all prefixes that are inbound from an external BGP peer. Implemented with the 0.0.0.0/0 le 32 IP prefix-list. |
Only supported for the 0.0.0.0/0 subnet (all prefixes). |
You may prefer to advertise all the transit routes out of an L3Out connection. In this case, use the aggregate export option with the prefix 0.0.0.0/0. Using this aggregate export option creates an IP prefix-list entry (permit 0.0.0.0/0 le 32) that the APIC system uses as a match clause in the export route-map. Use the show route-map <outbound route-map> and show IP prefix-list <match-clause> commands to view the output.
If you enable aggregate shared routes, if a route learned in one VRF must be advertised to another VRF, the routes can be shared by matching the subnet exactly, or they can be shared by using an aggregate subnet mask. Multiple subnet masks can be used to determine which specific route groups are shared between VRFs. For example, 10.1.0.0/16 and 12.1.0.0/16 can be specified to aggregate these subnets. Or, 0/0 can be used to share all subnet routes across multiple VRFs.
Routes shared between VRFs function correctly on Generation 2 switches (Cisco Nexus N9K switches with "EX" or "FX" on the end of the switch model name, or later; for example, N9K-93108TC-EX). On Generation 1 switches, however, there may be dropped packets with this configuration, because the physical ternary content-addressable memory (TCAM) tables that store routes do not have enough capacity to fully support route parsing.