Contracts in ACI: Lesson 2: Contracts Concept and Deployment in ACI part 2

     

     

    Lesson 2: Contracts Concept and Deployment in ACI part 2

     

    Lesson 2: Contracts Concept and Deployment in ACI part 2

     

     

    In this free ACI training video, John Meng demonstrates Contracts Concept and Deployment in ACI. The following additional informational resources are provided in this lesson. Show Additional Information

     

    Apply Contracts to EPG

    • Consumer EPG
    • Provider EPG

     

    Contracts – EPG Labels and Subject Labels

    • Requirement
      • EPG-Web provides HTTP to EPG-Client
      • EPG-DB provides SSH to EPG-mgmt
      • Contract with subjects HTTP and SSH exists
    • Resolution
      • EPG Labels – Contract is applied to EPGs with same EPG label
      • Subject Labels – Subject is only applied to EPGs with same subject labels as defined isubject label in contract.

     

    Inside a VRF, Enforced or Unenforced?

    • Policy Enforced: no communication without contracts
    • Policy Unenforced: all communication allowed without contracts. Good for TCAM, but weak of security.

     

    vzAny

    • vzAny represents the collection of EPGs that belong to the same VRF
    • Instead of configuring contracts to each individual EPG you can configure a contract to the vzAny for a particular service if applicable

     

    Configuration

    • The EPGs under the same VRF/context are: WEB, APP, DB, USW
    • The SSH entry is common across “most” contracts

     

    vzAny consuming shared services

    • Tenant ONE
    • Tenant Shared Services
    • Note
      • vzAny includes also the L3 External
      • With Cross-VRF contracts, vzAny can be a consumer not a provider

     

    vzAny in combination with TCP Established flag

    • The idea is to reduce the number of contracts that use TCP by:
      • Change all contracts to be unidirectional
      • Create a contract for the established flag that is associated with vzAny

     

    Two unidirectional contracts + vzAny

    • TCAM
      • One contract per VRF for the established traffic
        • permit vzAny to vzAny srcPort=any dstPort=any established
      • Unidirectional contracts
        • permit EPG1 to EGP2 srcPort=any dstPort=22
        • permit EPG1 to EGP2 srcPort=any dstPort=22

     

    Two contracts: SSH and HTTP with the regular configuration (bi-direction)

    • TCAM
      • permit EPG1 to EGP2 srcPort=any dstPort=22
      • permit EPG2 to EGP1 srcPort=22 dstPort=any
      • permit EPG1 to EGP2 srcPort=any dstPort 80
      • permit EPG2 to EGP1 srcPort=80 dstPort=any

     

    Making the Contract Unidirectional reduces the TCAM utilization by half but it is not enough

     

    Two unidirectional contracts

    • This can be configured once for the entire VRF under vzAny
      • permit EPG2 to EGP1 srcPort=any dstPort=any established
      • permit EPG2 to EGP1 srcPort=any dstPort=any established

     

    Contract Preferred Group (Started from 2.2.1)

    • Inside the Preferred Group there is unrestricted communication
    • Excluded EPGs can NOT communicate without contracts

     

    Preferred Group Configuration

    • At VRF and EPG Level:
      • First, enable Preferred Group feature for the VRF at the vzAny configuration
      • Then configure for each EPG

     

    VRF Policy control Point for EPG-to-Outside

    • Egress
      • Derive source EPG. Set source EPG in VXLAN header
      • External LPM table lookup with destination IP. Find border leaf VTEP IP AND EPG
      • Apply policy based on source, destination EPG and configured contract

     

    Restrictions of Ingress filtering

    • To avoid the stale remote Endpoint entry
      • When using non–EX hard \ware
        • Use dedicated Border Leaf for L3Out
    • When using non-EX and -EX hardware in fabric:
      • Upgrading all APICs and switches to 2.2(2e) or above,
      • Enable “Disable Remote EP Learn“
        • Fabric → Access Policies → Global Policies - Fabric Wide Setting Policy

     

    Inter-VRF Leaking

    • Subnet must be leaked across VRFs “Shared between VRF”
    • Contract must being place to allow traffic and enforce policy in VRF
      • Contract must be configured in provider tenant with proper scope
        • If same tenant but different vrf, the scope is “Tenant”
        • If cross tenants, scope is “Global” scope and exported to consumer tenant
      • OR:
        • Contract created in common tenant with scope Global.

     

    Steps to Config

    • Configure Subnet under EPG which is to be leaked (instead of BD) and check flag “ shared between VRF”
    • Create a Global scope contract and export, or use contract defined in common tenant
    • Add flag shared in consumer side BD subnet
    • Apply contract provided by EPG-Dev03 and consumed by EPG-Web in another VRF

     

    Taboo Contract

    • A Taboo Contract defines ports that should be blocked in a Regular Contract.
    • Taboo contracts are programmed with higher priority than Regular Contracts.

     

    Lesson 1: Contracts Concept and Deployment in ACI part 1

    Lesson 2: Contracts Concept and Deployment in ACI part 2

    Lesson 3: Contracts Verification

    Lesson 4: Demo and Best Practice

    Review ACI Certification Options

    ACI Discussions

    Watch more ACI Training Videos

    ACI Training Resources