pcTag (zoning-rule) & Policy TCAM

Understanding pcTag in Cisco ACI

1. What is pcTag?

• pcTag (Policy Control Tag):

  • A unique identifier assigned to each Endpoint Group (EPG) in Cisco ACI.

    
    

2. Assignment and Purpose

• Assignment:

  • Assigned to an EPG when it is created.

• Purpose:

  • Used in contract rules on leaf switches to control and secure network traffic.

  • These security rules are known as zoning rules.

    
    

3. Components of a Zoning Rule

Each zoning rule includes the following parameters:

1. Source EPG (src pcTag):

   • The pcTag of the EPG where the traffic originates.

2. Destination EPG (dst pcTag):

   • The pcTag of the EPG where the traffic is intended to go.

3. Filter ID:

   • Defines the type of traffic, such as TCP traffic on destination port 3306.

4. Scope:

   • Specifies the Virtual Routing and Forwarding (VRF) and Virtual Network ID (VNID) for both source and destination EPGs.

5. Action:

   • Determines whether to permit or deny the traffic.

     
     

4. Core Parameters of a Zoning Rule

• Source pcTag, Destination pcTag, and Filter ID:

  • These are the main elements that define what kind of traffic is allowed between which EPGs.

    
    

5. Scope Parameter

• Definition:

  • Specifies the VRF in which the zoning rule applies.

• Importance:

  • Ensures that pcTags are unique within each VRF.

    
    

6. Types of pcTags and Their Ranges

1. System Reserved pcTag (1-15):

   • Used for internal system rules.

2. Global pcTag (16-16385):

   • Unique across all VRFs.

   • Used for shared services like VRF route leaking.

3. Local pcTag (16386-65535):

   • Unique only within a single VRF.

   • Default for internal EPGs and L3Out EPGs.

     
     

7. Default Behavior

• EPGs in Different VRFs:

  • May have overlapping local pcTags.

  • This is acceptable because traffic remains within the same VRF.

    
    

8. pcTag Assignment with VRF Route Leaking

• When VRF Route Leaking is Enabled:

  • EPGs that provide shared services are assigned a new global pcTag instead of their original local pcTag.

• Provider EPGs:

  • Only EPGs configured for shared services receive a global pcTag.

    
    

9. Summary of pcTag Types and Usage

• System Reserved (1-15):

  • Internal use.

• Global (16-16385):

  • Across VRFs for shared services.

• Local (16386-65535):

  • Within a single VRF for regular EPGs.

    
    

Key Takeaways

• pcTag: A unique ID for each EPG, essential for defining and enforcing security rules.

• Zoning Rules: Utilize pcTags to control traffic between EPGs based on defined parameters.

• Scope: Ensures pcTags are unique within each VRF, crucial for maintaining proper traffic segregation.

• pcTag Types:

  • System Reserved: For internal operations.

  • Global: For shared services across VRFs.

  • Local: For standard EPGs within a single VRF.

• VRF Route Leaking: Assigns global pcTags to provider EPGs to facilitate shared services and cross-VRF communication.

leaf-a# show zoning-rule scope 2490369

leaf-a# show zoning-rule scope 2424832 src-epg 16386 dst-epg 10931

Class ID and scope can be easily retrieved from the APIC GUI by opening the Tenant >

select the Tenant name on the left > Operational > Resource IDs > EPGs

Leaf # show zoning-rule scope 123456

show zoning-filter

Show zoning-filter 5

Policy TCAM Exhaustion in Cisco ACI

1. What is Policy TCAM Exhaustion?

• TCAM (Ternary Content-Addressable Memory):

  • A type of memory in switch hardware where policies are stored for enforcement.

• Issue:

  • When an Endpoint Group (EPG) uses a contract, the zoning rules on a leaf switch can use up many TCAM entries.

  • Result: This can lead to TCAM exhaustion, where there are no more entries available for new policies.

2. Optimizing Policy CAM Usage

Option 1: Set Policy Control Enforcement to Unenforced in VRF

• Default Behavior:

  • Policy Control Enforcement is enabled by default.

  • Effect: EPGs cannot communicate unless there is a specific contract rule.

• Unenforced Mode:

  • Action: Turn off Policy Control Enforcement.

  • Result:

    • No contract rules are applied.

    • Any endpoints can communicate freely as long as they are connected via Layer 2 or Layer 3.

Option 2: Use Contracts with vzAny

• What is vzAny?

  • A managed object that links all EPGs within a VRF to one or more contracts.

  • Benefit: Avoids creating separate contract rules for each EPG.

• How It Works:

  • Automatically applies contract rules to all EPGs in a VRF.

  • When a new EPG is added, vzAny automatically includes it in the contract rules.

• Advantages:

  • Simplifies Configuration: Reduces the number of individual contract rules.

  • Saves TCAM Space: Combines multiple rules into one, lowering TCAM usage.

• Example:

  • Without vzAny:

    • Rule 1: EPG 16401 → EPG 16402 (FTP)

    • Rule 2: EPG 16401 → EPG 16403 (FTP)

    • Rule 3: EPG 16401 → EPG 16404 (FTP)

  • With vzAny:

    • Rule: EPG 16401 → vzAny (All EPGs) (FTP)

  
  

Guidelines and Limitations:

• Represents Everyone in the Same VRF:

  • Includes internal EPGs, external EPGs for L2Outs and L3Outs, and management networks.

• Usage Restrictions:

  • Supported as Consumer: Can consume shared services.

  • Not Supported as Provider: Cannot provide shared services.

• Communication Impact:

  • Using vzAny as a consumer allows any EPG in the consumer VRF to communicate with the provider VRF.

• Scope Considerations:

  • If the contract scope is set to Application Profile, vzAny won’t save TCAM space as it will still create individual zoning rules.

Option 3: Use Contract Preferred Group

• Purpose:

  • Simplifies configurations where multiple EPGs share the same contract.

• Example Scenario:

  • Requirement: Allow EPGs 1 to 4 to communicate with each other without security restrictions.

  • Action: Create a preferred group contract that permits EPGs 1-4 to talk to each other freely.

  • Effect: Other EPGs will still follow the allow list model, maintaining security for the rest of the network.

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).

Preferred Group in Cisco ACI

• Included and Excluded Members:

  • Included Members:

    • Specific Endpoint Groups (EPGs) are marked as "Included".

    • Example: EPG 1 to EPG 4 are designated as Included members.

  • Excluded Members:

    • All other EPGs that are not Included are grouped as "Excluded" members.

• Communication Rules:

  • No Contracts Needed for Included Members:

    • EPGs within the Included group do not require any contract rules to communicate.

  • Free Communication:

    • Included EPGs can freely talk to each other without any security enforcement or restrictions.

To configure Contract Preferred Group, follow these steps:

1. Enable the Preferred Group under the VRF.

1. 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.

Tools - To identify policy drop / packet drop

A) show system internal policy-mgr stats

The command "show system internal policy-mgr stats" is used to verify the number of hits per zoning rule.

leaf# show system internal policy-mgr stats

Requested Rule Statistics

Rule (4131) DN (sys/actrl/scope-2818048/rule-2818048-s-16410-d-25-f-424) Ingress: 0, Egress: 0, Pkts: 0 RevPkts: 0

Rule (4156) DN (sys/actrl/scope-2818048/rule-2818048-s-25-d-16410-f-425) Ingress: 0, Egress: 0, Pkts: 0 RevPkts: 0

Breakdown of Key Elements:

1. Rule Identification

Each rule is assigned a unique rule number (e.g., 4131, 4156) and a Distinguished Name (DN), which defines its scope and parameters.

The DN follows the structure:

sys/actrl/scope-<scope_id>/rule-<rule_id>-s-<source_id>-d-<destination_id>-f-<flow_id>

sys/actrl → This refers to the Access Control subsystem within the system (sys).

s-16410 → Represents the source

d-25 → Represents the destination

f-424 / f-425 → Internal flow identifiers

2. Counters Explained

Each rule contains four key counters that help track packet flow:

Ingress: Number of packets matching the rule entering the system.

Egress: Number of packets matching the rule leaving the system.

Pkts: Total number of packets processed by the rule.

RevPkts: Packets flowing in the reverse direction, if applicable.

Understanding f-424 and f-425

The "f-xxx" values (e.g., f-424, f-425) are internally generated identifiers that the policy manager uses to distinguish individual rule instances.

These are not manually configured but rather assigned automatically by the system to track, count, and report on specific rule instances.

f-424 appears to handle one direction of traffic (likely ingress).

f-425 likely handles the opposite direction (egress).

B) show logging ip access-list internal packet-log deny

A switch level command that can be run at iBash level which reports ACL (contract) related drops and flow-related information.

leaf# show logging ip access-list internal packet-log deny

[ Tue Oct 1 10:34:37 2019 377572 usecs]: CName: Prod1:VRF1(VXLAN: 2654209), VlanType: Unknown, Vlan-Id: 0, SMac: 0x000c0c0c0c0c,

DMac:0x000c0c0c0c0c, SIP: 192.168.21.11, DIP: 192.168.22.11, SPort: 0, DPort: 0, Src Intf: Tunnel7, Proto: 1, PktLen: 98

[ Tue Oct 1 10:34:36 2019 377731 usecs]: CName: Prod1:VRF1(VXLAN: 2654209), VlanType: Unknown, Vlan-Id: 0, SMac: 0x000c0c0c0c0c,

DMac:0x000c0c0c0c0c, SIP: 192.168.21.11, DIP: 192.168.22.11, SPort: 0, DPort: 0, Src Intf: Tunnel7, Proto: 1, PktLen: 98

Breaking Down the Output:

Each log entry provides detailed packet information that was denied. Let's analyze the key fields in detail:

Timestamp :

[ Tue Oct 1 10:34:37 2019 377572 usecs ]

Tue Oct 1 10:34:37 2019 → The date and time when the packet was denied.

377572 usecs → The precise microsecond timestamp of the event.

Context and VRF Information:

CName: Prod1:VRF1(VXLAN: 2654209)

CName: Prod1 → This is the tenant or fabric context name where the rule was applied.

VRF1 → The Virtual Routing and Forwarding (VRF) instance in which the packet was observed.

VXLAN: 2654209 → The VXLAN Network Identifier (VNI) for the encapsulated overlay network.

VLAN Information:

VlanType: Unknown, Vlan-Id: 0

VlanType: Unknown → This suggests the packet is encapsulated (such as VXLAN) and not associated with a traditional VLAN.

Vlan-Id: 0 → No explicit VLAN tag is associated.

MAC Addresses (Layer 2 Information):

SMac (Source MAC): 0x000c0c0c0c0c → The MAC address of the sender.

DMac (Destination MAC): 0x000c0c0c0c0c → The MAC address of the receiver.

IP Information (Layer 3):

SIP: 192.168.21.11, DIP: 192.168.22.11

SIP: 192.168.21.11 → The Source IP Address of the denied packet.

DIP: 192.168.22.11 → The Destination IP Address of the denied packet.

Port Information (Layer 4):

SPort: 0, DPort: 0

SPort: 0 (Source Port) and DPort: 0 (Destination Port) → Ports are set to 0, which usually indicates ICMP traffic (ping, traceroute, etc.).

If it were TCP/UDP, these would reflect actual port numbers.

Interface Information:

Src Intf: Tunnel7 → The denied packet was received on Tunnel7.

This suggests the traffic is part of an encapsulated tunnel, likely a VXLAN tunnel.

Protocol & Packet Size:

Proto: 1, PktLen: 98

Proto: 1 → Protocol 1 refers to ICMP (used for ping requests).

PktLen: 98 → The packet size was 98 bytes.

C) contract_parser.py

A Python script running on the leaf generates an output that aligns zoning rules,

filters, and hit statistics during ID-to-name lookups. This script is particularly valuable as it simplifies a multi-step procedure into a single command, which can be filtered for specific EPGs/VRFs or other contract-related values.

leaf# contract_parser.py

Key:

[prio:RuleId] [vrf:{str}] action protocol src-epg [src-l4] dst-epg [dst-l4] [flags][contract:{str}] [hit=count]

[7:4131] [vrf:common:default] permit ip tcp tn-Prod1/ap-Services/epg-NTP(16410) tn-Prod1/l3out-L3Out1/instP-extEpg(25) eq 123

[contract:uni/tn-Prod1/brc-external_to_ntp] [hit=0]

[7:4156] [vrf:common:default] permit ip tcp tn-Prod1/l3out-L3Out1/instP-extEpg(25) eq 123 tn-Prod1/ap-Services/epg-NTP(16410)

[contract:uni/tn-Prod1/brc-external_to_ntp] [hit=0]

[12:4169] [vrf:common:default] deny,log any tn-Prod1/l3out-L3Out1/instP-extEpg(25) epg:any [contract:implicit] [hit=0]

[16:4167] [vrf:common:default] permit any epg:any tn-Prod1/bd-Services(32789) [contract:implicit] [hit=0]

The output of contract_parser.py provides a parsed view of contract rules within Cisco ACI. It shows the priority, rule ID, VRF, action, protocol, EPGs, contracts, and hit counts for policy enforcement. Let's break down the key elements.

Understanding the Key Structure

[prio:RuleId] [vrf:{vrf-name}] action protocol src-epg [src-l4] dst-epg [dst-l4] [flags] [contract:{contract-name}] [hit=count]

[prio:RuleId] → Priority level and rule ID.

[vrf:{vrf-name}] → The VRF where the rule is applied.

action → Permit/Deny.

protocol → TCP, UDP, or any.

src-epg [src-l4] → Source EPG (Endpoint Group) and optional Layer 4 (L4) port.

dst-epg [dst-l4] → Destination EPG and optional Layer 4 (L4) port.

[flags] → Additional actions (like logging).

[contract:{contract-name}] → The contract defining the policy.

[hit=count] → Number of times the rule matched traffic.

Rule 1: NTP Traffic Allowed from Internal to External

[7:4131] [vrf:common:default] permit ip tcp tn-Prod1/ap-Services/epg-NTP(16410) tn-Prod1/l3out-L3Out1/instP-extEpg(25) eq 123 [contract:uni/tn-Prod1/brc-external_to_ntp] [hit=0]

Priority: 7

Rule ID: 4131

VRF: common:default

Action: permit

Protocol: IP TCP

Source EPG: tn-Prod1/ap-Services/epg-NTP(16410) (NTP service inside ACI fabric)

Destination EPG: tn-Prod1/l3out-L3Out1/instP-extEpg(25) (External EPG)

Port: eq 123 (NTP traffic)

Contract: brc-external_to_ntp

Hit Count: 0 (No matching packets yet)

Rule 2: NTP Traffic Allowed from External to Internal

[7:4156] [vrf:common:default] permit ip tcp tn-Prod1/l3out-L3Out1/instP-extEpg(25) eq 123 tn-Prod1/ap-Services/epg-NTP(16410) [contract:uni/tn-Prod1/brc-external_to_ntp] [hit=0]

Priority: 7

Rule ID: 4156

VRF: common:default

Action: permit

Protocol: IP TCP

Source EPG: tn-Prod1/l3out-L3Out1/instP-extEpg(25) (External EPG)

Destination EPG: tn-Prod1/ap-Services/epg-NTP(16410) (NTP service inside ACI fabric)

Port: eq 123 (NTP traffic)

Contract: brc-external_to_ntp

Hit Count: 0

Rule 3: Deny All Traffic from External EPG

[12:4169] [vrf:common:default] deny,log any tn-Prod1/l3out-L3Out1/instP-extEpg(25) epg:any [contract:implicit] [hit=0]

Priority: 12

Rule ID: 4169

VRF: common:default

Action: deny,log

Protocol: any

Source EPG: tn-Prod1/l3out-L3Out1/instP-extEpg(25) (External EPG)

Destination EPG: epg:any (All internal endpoints)

Contract: implicit

Hit Count: 0

Rule 4: Allow All Traffic to Services BD

[16:4167] [vrf:common:default] permit any epg:any tn-Prod1/bd-Services(32789) [contract:implicit] [hit=0]

Priority: 16

Rule ID: 4167

VRF: common:default

Action: permit

Protocol: any

Source EPG: epg:any (Any endpoint group)

Destination BD: tn-Prod1/bd-Services(32789) (Bridge domain for services)

Contract: implicit

Hit Count: 0

This peoblem is with me as well & what i believe is it's because I worry more about how you’re being perceived, in front of very good looking people leading to tension and anxiety & that most probably due to lack of confidence which is basically for me is because of past negative experience.