pcTag
All EPGs have their own ID called policy control Tag (pcTag).
The pcTag is assigned to an EPG when it is created and used when a contract rule is applied for a packet on a leaf switch. The security rules that use pcTag and that are created from contracts on leaf switches are called zoning rules.
Each zoning rule has the following parameters:
Src EPG (src pcTag)
DST EPG (DST pcTag)
Filter ID (traffic type such as TCP DST port 3306)
Scope (VRF VNID for the src and DST EPGs)
Action (permit or deny)
The first three parameters (src/dst pcTag and filter) are the core of the rule that defines what kind of traffic from which EPG to which EPG should use this rule.
The fourth parameter Scope is to define in which VRF this rule should be applied. It is important because pcTag is by default unique only within a VRF. The following is the pcTag types and its range:
System reserved pcTag (1-15): This pcTag is used for system internal rules.
Global pcTag (16-16385): This pcTag is unique across VRFs and used for shared service (VRF route leaking).
Local pcTag (16386-65535): This pcTag is unique only within a VRF and is the default pcTag for internal EPGs and L3Out EPGs.
By default, EPGs in different VRFs may have overlapping local pcTag, which is not a problem since the traffic should be always within the same VRF.
However, when the VRF route leaking is configured EPGs with shared service (VRF route leaking) configuration are assigned a new global pcTag as a replacement of the original local pcTag.
Precisely speaking, only the provider EPGs with shared service configuration are assigned a global pcTag.
leaf-a# show zoning-rule scope 2490369
leaf-a# show zoning-rule scope 2424832 src-epg 16386 dst-epg 10931
Leaf # show zoning-rule scope 123456
show zoning-filter
Show zoning-filter 5
Policy TCAM Exhaustion
The physical ternary content-addressable memory (TCAM) in which policy is stored for enforcement is a critical component of switch hardware. When an EPG is associated with a contract, zoning rules that are applied on a leaf switch can consume a lot of entries in TCAM, which can lead to TCAM exhaustion.
Options to optimize policy CAM usage and simplify the configuration:
Policy Control Enforcement in VRF set to Unenforced
VRF provides an option “Policy Control Enforcement” . By default, it is enforced and no communication between EPGs is allowed without a contract rule. Once it’s unenforced, no contract rules will be applied, and any endpoints can talk to anyone as long as there is Layer 2 or Layer 3 reachability.
2. Contract with vzAny:
The vzAny managed object provides a way of associating all EPGs in a VRF instance to one or more contracts (vzBrCP), instead of creating separate contract relations for each EPG.
In the Cisco ACI fabric, EPGs can only communicate with other EPGs according to contract rules.
By dynamically applying contract rules to all EPGs in a VRF, vzAny automates the process of configuring EPG contract relationships. Whenever a new EPG is added to a VRF, vzAny contract rules automatically apply. The vzAny one-to-all EPG relationship is the most efficient way of applying contract rules to all EPGs in a VRF.
vzAny simplify the configuration & also save a lot of space in the policy TCAM on leaf switches by consolidating multiple rules between individual pcTags into one. In the example above, let’s say pcTag of EPG 1 – 4 are pcTag 16401 – 16404. Then, the zoning rules without vzAny look like this:
Rule 1 - 16401 -> 16402 (filter FTP)
Rule 2 - 16401 -> 16403 (filter FTP)
Rule 3 - 16401 -> 16404 (filter FTP)
With vzAny, the rule is consolidated into one:
Rule 1 - 16401 -> 0 (filter FTP)
When using vzAny, follow these guidelines and limitations:
The vzAny represents everybody in the same VRF, such as internal EPGs under application profiles, external EPGs for L2Outs, L3Outs, and out-of-band or in-band EPGs (External Management Network Instance Profile in the APIC user interface) in tenant mgmt and so on.
The vzAny represents everybody in the same VRF as a consumer and/or a provider.
vzAny is supported as a consumer of a shared service but is not supported as a provider of a shared service.
Be aware that using vzAny as a consumer for a shared service contract means that anybody in the consumer VRF can communicate with the provider application in the provider VRF.
If the scope of the contract that is provided or consumed by the vzAny is Application Profile, the leaf switches will not consolidate zoning rules with pcTag 0 but instead program multiple zoning rules with individual pcTag of each EPG, still helping to simplify the configuration but does not help to save the policy TCAM usage.
3. Contract Preferred Group
As we saw with vzAny, certain configurations, such as all EPGs in the given VRF shares the same contract, can be simplified.
The requirement here is that EPG 1 – 4 should be allowed to talk to each other without any security rules, while the rest should follow the allow list model.
To simplify such a configuration requirement to partially unenforced contract policies in the given VRF, ACI introduced Contract Preferred Group in the APIC release 2.2(1).
With Preferred Group, ACI defines some EPGs as the “Included” members. All the other EPGs are grouped as “Excluded” members. In the example picture, EPG 1 – 4 are defined as the “Included” members. Within the “Included” members, there are no contracts that are required. They can talk to each other without any security enforcement.
To configure Contract Preferred Group, follow these steps:
Enable the Preferred Group under the VRF.
Add EPGs in the “Included” member. By default, all EPGs are defined as the “Excluded” member.
Note : When adding a L3Out EPG in the “Included” member, 0.0.0.0/0 with “External Subnets for the External EPG” scope is not supported. Use 0.0.0.0/1 and 128.0.0.0/1 instead.
Kommentare