ESG selectors

Selector types

Service EPG traffic

In most service-graph redirect deployments, the fabric redirects traffic to the Layer 4 through Layer 7 (L4-L7) device without requiring a separate contract for traffic addressed directly to the device.

If endpoints must send traffic directly to the L4-L7 device IP address, use a service EPG selector to map the service EPG to a service ESG. Contracts can then control which ESGs are allowed to communicate directly with the device.

Tenant scope

A tag selector can match only policy tags in the same tenant as the ESG. If the ESG is associated with a virtual routing and forwarding (VRF) instance from the common tenant, the selector can also match policy tags in the common tenant.

Note

If a user tenant uses a bridge domain or VRF instance from the common tenant, some related configurations might not be visible from the user tenant.

Supported tagged objects

Bridge domain subnet tags

A policy tag on a bridge domain subnet classifies the IP addresses of endpoints in that subnet into an ESG.

• To classify a subset of a larger subnet, create a smaller bridge domain subnet, enable No Default SVI Gateway, and assign the policy tag to the smaller subnet.

• Policy tags configured under an EPG subnet are not supported by ESG tag selectors.

• A bridge domain subnet tag classifies endpoint IP addresses, not endpoint MAC addresses.

For more information, see Layer 2 traffic limitations with IP-based selectors .

IP endpoint tags

An IP endpoint tag is a user-configurable metadata object that represents an endpoint IP address within a VRF instance.

• You can create and retain the tag before the fabric learns the IP address.

• Configuring the tag does not deploy an endpoint or the specified IP address.

• To deploy the endpoint and IP address before the fabric learns them, configure a static endpoint.

• An IP endpoint tag classifies only the endpoint IP address, not its MAC address.

MAC endpoint tags

A MAC endpoint tag is a user-configurable metadata object that represents an endpoint MAC address.

• The default scope of a MAC endpoint tag is a bridge domain.

• If the MAC address is unique across bridge domains, you can use an Any scope and specify the applicable VRF instance.

• You can create and retain the tag before the fabric learns the MAC address.

• Configuring the tag does not deploy an endpoint or the specified MAC address. Configure a static endpoint if the endpoint must be deployed before it is learned.

VMM MAC endpoint tags

The Cisco APIC automatically creates read-only VMM MAC endpoint policy tags from information learned through VMM integration.

VMM MAC endpoint tags are displayed under Tenants > tenant_name > Policies > Endpoint Tags > Endpoint MAC .

• Enable Allow Micro-Segmentation when associating the VMM domain with the EPG.

• Enable Tag Collection under the applicable VMM domain to collect tags such as VMware vSphere tags.

• Automatically generated tags include the (VMM) suffix to distinguish them from manually configured MAC endpoint tags.

• Policy tags derived from a VM name are created automatically. Other translated policy tags are created on a VMM MAC endpoint tag only after an ESG tag selector matches them.

• If a manually configured MAC endpoint tag and a VMM MAC endpoint tag use the same MAC address and bridge domain, only the policy tags from the manually configured MAC endpoint tag are used.

Note

To select a virtual machine by name, first configure an EPG selector for the EPG associated with the virtual machine.

Static endpoint tags

A policy tag assigned to a static endpoint under an EPG can classify the static endpoint's MAC address into an ESG.

• A static endpoint policy tag eliminates the need to configure a separate MAC endpoint tag for the same MAC address.

• A static endpoint policy tag and a MAC endpoint tag cannot use the same MAC address in the same bridge domain.

• Static endpoint policy tags are supported only for static endpoints of type silent-host.

L3Out external subnet tags

Beginning with Cisco Application Policy Infrastructure Controller (APIC) Release 6.1(4), a policy tag can classify external prefixes associated with an L3Out external EPG.

• You can assign a policy tag to any l3extSubnet object.

• The tag selector is active only when the subnet uses the External Subnets for the External EPG scope, either by itself or together with another scope.

• If the subnet does not use the required scope, the fabric raises a fault and reports that the matched tags are inactive.

Contract inheritance

When an EPG/External EPG selector matches an EPG or external EPG, the ESG inherits the existing provided and consumed contracts from that EPG.

• The inherited contracts continue to provide security policy during migration to the ESG design.

• After the selector is configured, the matched EPG or external EPG cannot provide or consume new contracts.

• Configure new security relationships on the ESG.

Isolation and preferred group settings

Before matching an EPG or external EPG to an ESG, ensure that the following settings are consistent on both objects:

• Intra-EPG or external EPG isolation and intra-ESG isolation

• Contract preferred group membership

After the selector matches the EPG or external EPG, the ESG isolation and preferred group settings override the corresponding settings on the matched object.

Migration considerations

Contract inheritance supports migration from an EPG-based or external EPG-based security design to an ESG-based security design.

Complete the migration by configuring the required security relationships on the ESG. Do not retain inherited EPG or external EPG contracts as the permanent ESG configuration. The Cisco Application Policy Infrastructure Controller (APIC) raises a fault when it detects an incomplete migration.

Policy control tag replacement

When an EPG selector assigns an EPG to an ESG, the fabric replaces the EPG policy control tag (pcTag) with the ESG pcTag.

• The replacement can cause a brief traffic disruption for endpoints in the EPG.

• The behavior is similar to other pcTag update events, such as enabling shared services through route leaking.

• A pcTag identifies an EPG or ESG for data-plane contract enforcement. It is different from the policy tag, also called a tagTag, that a tag selector uses for endpoint classification.

Address matching

IP subnet selectors primarily classify endpoint IP addresses. Use an external subnet selector to classify external prefixes learned through a Layer 3 Outside (L3Out) connection.

Layer 2 traffic limitation

An IP subnet selector classifies only the IP address of an endpoint into the ESG. It does not classify the endpoint MAC address.

For more information, see Layer 2 traffic limitation with IP-based selectors .

L3Out security classification

An external subnet selector can provide ESG classification for prefixes that would otherwise be represented by an L3Out external subnet using the External Subnets for the External EPG scope.

If many L3Out external subnets must be migrated, you can use an External EPG selector instead of reconfiguring each prefix as an external subnet selector.

Shared security information

The shared flag allows the ESG and prefix mapping to be used by other virtual routing and forwarding (VRF) instances through contracts.

• The shared flag is equivalent to the Shared Import Security Subnet scope on an L3Out external subnet.

• The flag shares security-classification information only. Configure route leaking separately at the VRF level.

For more information, see Configure route leaking of external prefixes by using the GUI .

Configuration precedence

If an ESG external subnet selector and an L3Out external subnet define the same prefix and subnet mask, and the L3Out subnet uses the External Subnets for the External EPG scope, the ESG external subnet selector takes precedence.

• Cisco APIC raises a fault on the conflicting L3Out external endpoint group (EPG).

• The precedence behavior allows migration to ESG external subnet selectors before the conflicting L3Out configuration is removed.

External EPG requirements

When ESG external subnet selectors provide security classification, an L3Out external EPG might not be required for that purpose.

• Retain the required external EPG configuration when using features such as route summarization or Export Route Control Subnet.

• At least one external EPG must exist for each L3Out so that the fabric deploys the routing configuration to the switches.

Service EPG mapping

Cisco Application Centric Infrastructure (ACI) automatically creates a service EPG from the connector in a device selection policy. The service EPG is created in the tenant where the Layer 4 through Layer 7 (L4-L7) device is defined.

A service EPG selector maps the service device connector and its service EPG to a service ESG. Zoning rules associated with the service EPG are inherited by the ESG.

The service EPG selector can also exclude a service device interface from a vzAny-to-vzAny permit contract.

Alternatives without a service EPG selector

Before service EPG selectors were available, the following options could provide connectivity to a service EPG:

• The Direct Connect option adds a permit rule between the service EPG and the consumer or provider EPG. EPGs that are not consumers or providers still require a vzAny contract or preferred group to communicate with the service EPG.

• A vzAny-to-vzAny contract can permit traffic between the service EPG and other EPGs in the virtual routing and forwarding (VRF) instance, but it might permit more communication than required.

• A contract preferred group allows its EPGs to communicate without contracts, but it can permit more communication than required and might increase ternary content-addressable memory (TCAM) usage.

Supported tenant placements

The following tenant placements are supported:

• The L4-L7 device and the service EPG-to-ESG mapping are defined in the same tenant.

• The L4-L7 device is defined in the common tenant and exported to a user tenant, and the service EPG-to-ESG mapping is defined in that user tenant.

The following placement is not supported:

• The L4-L7 device is defined in the common tenant and shared across multiple user tenants, resulting in service EPG-to-ESG mappings in multiple tenants.

Connector mapping requirements

• The service EPG and service ESG must belong to the same VRF instance.

• All service device connectors (LifCTx) on the same device that use the same bridge domain must map to the same ESG.

• If connectors in the same bridge domain map to different ESGs, Cisco APIC raises a fault and the service graph deployment fails.

• A service device interface can be reused by multiple service graph deployments.

For example, the consumer and provider connectors of a one-arm firewall using a policy-based redirect (PBR) service graph must map to the same ESG when they use the same bridge domain.

Guidelines and limitations

• When a service EPG is mapped to an ESG, its class identifier changes to a global class identifier. The change can cause temporary traffic loss.

• Cisco Nexus Dashboard Orchestrator (NDO) does not support ESGs; therefore, service EPG selectors are not supported with NDO.

• Service EPG selectors support only Layer 3 PBR when the PBR destination is in a bridge domain.

• A PBR destination in an L3Out is not supported. You can manually configure contracts with an L3Out EPG.

• Layer 1 and Layer 2 PBR are not supported because Layer 1 and Layer 2 device interfaces do not communicate directly with servers.