Working with Contracts - Cisco€¦ · Step2 IntheWorkpane,doubleclickthetenant'sname. Step3...

Working with Contracts

• Contracts, on page 1• Filters, on page 9• Taboo Contracts, on page 13• Inter-Tenant Contracts, on page 16

ContractsContracts provide a way for the Cisco Application Centric Infrastructure (ACI) administrator to control trafficflowwithin the Cisco ACI fabric between endpoint groups. These contracts are built using a provider-consumermodel where one endpoint group provides the services it wants to offer and another endpoint group consumesthem. Contracts are assigned a scope of Global, Tenant, VRF, or Application Profile, which limit theaccessibility of the contract.

In brief, contracts consist of 1 or more subjects. Each subject contains 1 or more filters. Each filter contains1 or more entries. Each Entry is equivalent to a line in an Access Control List (ACL) that is applied on theleaf switch to which the endpoint within the endpoint group is attached.

In detail, contracts are comprised of the following items:

• Subjects—A group of filters for a specific application or service.

• Filters—Used to classify traffic based upon layer 2 to layer 4 attributes (such as Ethernet type, protocoltype, TCP flags and ports).

• Actions—Action to be taken on the filtered traffic. The following actions are supported:

• Permit the traffic (regular contracts, only)

• Mark the traffic (DSCP/CoS) (regular contracts, only)

• Redirect the traffic (regular contracts, only, through a service graph)

• Copy the traffic (regular contracts, only, through a service graph or SPAN)

• Block the traffic (taboo contracts, only)

• Log the traffic (taboo contracts, only)

• Labels—(Optional) Used to group objects such as subjects and endpoint groups for the purpose ofincreasing granularity in policy enforcement.

Working with Contracts1

While different endpoint groups can only communicate with other endpoint groups based upon the contractrules defined, there is no contract required for intra-endpoint group communication. Intra-endpoint groupcommunication from endpoint to endpoint in the same endpoint group is allowed by default.

If a contract is defined with a subject and a filter with any source port and destination port 80 between twoendpoint groups (EPGs), one as a consumer and another as a provider, a Cisco ACI fabric allows a packetfrom the consumer EPG to the provider EPG with the destination port 80 and source port any. However, areturn packet from the provider to the consumer is not allowed yet. One option to allow the return packet isto enable Apply Both Direction and Reverse Filter Port in the subject for the filter. These two options areby default enabled when you create a subject.

Apply Both Direction will create a rule to allow packets in the opposite direction with the same Layer 4 portcombination, that is packets from the provider EPG to the consumer EPG with the destination port 80 andany source port. Then, Reverse Filter Port will flip the destination and source port for this new rule. Thiswill result in a rule to allow a packet from the provider EPG to the consumer EPG with any destination portand the source port 80, which should match the return packet from the provider EPG.

However, Cisco ACI contracts are not stateful and packets from the provider EPG to the consumer EPG doesnot have to be a return packet. This means that if the provider EPG initiates traffic toward the consumer EPG,the Cisco ACI fabric allows it for any destination ports if the source port is 80. The Stateful option in thefilter can be used to avoid such an issue for TCP traffic. When the Stateful option is enabled, the rule for thereturn direction (provider to consumer) will check the TCPACK flag on top of the TCP ports (any destinationport and source port 80 in this example) to block traffic initiated from the provider EPG.

If you do not configure a contract, traffic is permitted only for the following types of packets as well as thetypes that are permitted by default for multicast traffic and class equal traffic:

• DHCP v4 (prot 0x11, sport 0x44, dport 0x43)



• OSPF (prot 0x59)

• EIGRP (prot 0x58)

• PIM (prot 0x67)

• IGMP (prot 0x2)

• ND-Sol ICMPv6 (prot 0x3a dport 0x0087)

• ND-Advt ICMPv6 (prot 0x3a dport 0x0088)

The following example shows how different contracts would control traffic flow between endpoint groups ina 3-tiered application containing a group of web servers in one endpoint group, a group of application serversin a second endpoint group, and a group of database servers in a third endpoint group. The Web endpointgroup (provider) provides a contract (contract1) which is consumed by the L3Out endpoint group (trafficexternal to the Cisco ACI fabric). This allows for web traffic to reach the web servers from outside the CiscoACI fabric. The Application endpoint group (provider) provides a contract (contract2) for communicationswhich the Web endpoint group (consumer) consumes. This allows the web server to call applications on theapplication servers. Finally, the Application endpoint group (consumer) consumes a contract (contract3),which the Database endpoint group (provider) provides. This allows the application servers to access thedatabase for the applications. For un-acked UDP traffic, reverse port filtering is not necessary. But, for TCPtraffic, the responder cannot set up a TCP session without reverse port filtering enabled or a different contractthat allows any established traffic from the responder.


Working with ContractsContracts

Figure 1: Contract Policies Between End Point Groups

The following types of Contracts that can be applied in Cisco ACI:

• Regular contracts

• Taboo contracts

• Out-Of-Band (OOB) contracts

Contracts govern the following types of endpoint group communications:

• Between application endpoint groups

• Between application endpoint groups and external networks

• Between application endpoint groups and in-band management endpoint group, for example if in-bandmanagement is configured for the Cisco ACI fabric and certain endpoint groups are to be allowed toaccess it

Out-of-band contracts apply only to out-of-band traffic from the management tenant. Taboo contracts areused to deny and log traffic related to regular contracts and are configured into the hardware before the regularcontract. For example, if the objective was to allow traffic with source ports 50 through 500 with the exceptionof port 305, then the regular contract would allow all ports in the range of 50 through 500 while the taboocontract would have a single entry denying port 305. The taboo contract denying port 305would be programmedinto the hardware before the regular contract allowing ports 50 through 500.

Contract Configuration ParametersWhen configuring contracts you can define the following options:

• Application-profile—This contract can be applied to any endpoint groups in the same application profile.


Working with ContractsContract Configuration Parameters

• Contract Scope—The scope of a service contract between two or more participating peer entities orendpoint groups. The contract will not be applied to any consumer endpoint group outside the scope ofthe provider endpoint group.

The states are:

• Private Network—This contract can be applied to any endpoint groups within the same VRF.• Tenant —This contract can be applied to any endpoint groups within the same tenant.• Global —This contract can be applied to any endpoint groups throughout the fabric.

The default state is Private Network.

• QoS Class—The priority level of the service contract.

The priority level can be:

• Unspecified• Level1—Class 1 Differentiated Services Code Point (DSCP) value.• Level2—Class 2 DSCP value.• Level3—Class 3 DSCP value.

The default is Unspecified.

• Tags (labels)—(Optional) The search keyword or term that is assigned to the application profile. A tagallows you to groupmultiple objects by a descriptive name. You can assign the same tag name to multipleobjects and you can assign one or more tag names to an object.When contracts are assigned to an endpointgroup as either a consumer or provider, by default all subjects within a contract apply to the endpointgroup. With tags, only endpoint groups in application profiles with matching criteria will implement thesubject of the contract.

• Match—-The subject match criteria across consumer endpoint groups. Labels can be applied to a varietyof provider and consumer managed objects, including endpoint groups, contracts, bridge domains, DHCPrelay policies, and DNS policies. When checking for a match of provider labels and consumer labels,the match setting is determined by the provider endpoint group. The different options are:

• AtleastOne—At least 1 label matches on Provider and Consumer endpoint groups. Blank labelsare considered a match.

• AtmostOne—Matches only when all labels on the endpoint groups are exactly the same. Blanklabels are considered a match.

• None—None of the subject labels match.• All—Only matches when both endpoint groups have all labels, excluding blank labels.

The default is AtleastOne.

Create/Modify/Remove Regular Contracts

Create Contracts1. On the menu bar, choose Tenants > ALL TENANTS.

2. In the Work pane, choose the Tenant_Name.

3. In the Navigation pane choose Tenant_Name > Security Policies > Contracts.

4. In the Work pane, choose Actions > Create Contract.


Working with ContractsCreate/Modify/Remove Regular Contracts

5. In the Create Contract dialog box, perform the following actions:

a. Enter a contract name.

b. Choose a contract scope (optional).

c. Choose a QoS class (optional).

d. Click + next to the Subject to add a contract subject.

1. In the Create Contract Subject dialog box, perform the following actions:

a. Enter a contract subject name.

b. Click + in the Filter Chain field.

For information regarding filter creation, see the "Filters" section.

6. Click Update

7. Click OK.

8. Click Submit.

Modify Contracts1. On the menu bar, choose Tenants > ALL TENANTS.


3. In the Navigation pane choose Tenant_Name > Security Policies > Contracts > Contract_Name.

4. In the Work pane, choose the Policy tab.

a. Choose a Contract Scope (optional).

b. Choose a Qos Class (optional).

c. Click + next to the Subject field. to add a Contract Subject.

1. In the Create Contract Subject dialog box, perform the following actions:

a. Enter a Contract Subject Name.

b. Click + next to Filter Chain.

For information regarding filter creation, see the "Filters" section.Note

5. Click Update.

6. Click OK.

7. Click Submit.


Working with ContractsModify Contracts

Remove Contracts1. On the menu bar, choose Tenants > ALL TENANTS.

2. In the Work pane, choose the Tenant_Name .


4. In the Work pane, choose Actions > Delete.

Verify Contracts

REST :: /api/node/class/vzBrCP.xml

CLI :: moquery -c vzBrCP

Apply/Remove EPG Contracts

Apply a Contract to an EPG1. On the menu bar, choose Tenants > ALL TENANTS.


3. In the Navigation pane choose Tenant_Name > Application Profiles > Application_Profile_Name >Application EPGs > EPG_Name > Contracts .

4. In the Work pane, choose Actions > Add Provided Contract or Actions > Add Consumed Contract.

Note: Choose the action depending on how the contract is to be deployed.

5. In the Add Contract dialog box, perform the following actions:

a. Enter a Contract_Name.

b. Choose a QOS policy (optional).

c. Choose a Label (optional).

6. Click Submit.

Remove a Contract from an EPG1. On the menu bar, choose Tenants > ALL TENANTS.


3. In the Navigation pane choose Tenant_Name > Application Profiles > Application_Profile_Name >Application EPGs > EPG_Name > Contracts > Contract_Name .



Working with ContractsRemove Contracts

Verify Contract on an EPG

Provider

REST :: /api/node/class/fvRsProv.xml

CLI :: moquery -c fvRsProv

Consumer

REST :: /api/node/class/fvRsCons.xml

CLI :: moquery -c fvRsCons

Apply/Remove External Network Contracts

Apply a Contract to an External Network1. On the menu bar, choose Tenants > ALL TENANTS.


3. In the Navigation pane choose Tenant_Name > Networking > External Routed Networks > RoutedOutside_Name > Networks > External_Network_Instance_Profile .

4. In the Work pane, click + next to either Add Provided Contract or Add Consumed Contract.

Note: Make a selection depending on how the contract is to be deployed.

a. Choose a Contract_Name .

b. Choose a QOS Type.

c. Choose a Match Criteria.

5. Click Update.

Remove a Contract from an External Network1. On the menu bar, choose Tenants > ALL TENANTS.


3. In the Navigation pane choose Tenant_Name > Networking > External Routed Networks > RoutedOutside_Name > Networks > External_Network_Instance_Profile .

4. In the Work pane, choose the Contract_Name and click x.

Verify External Network Contracts

Provider



Working with ContractsVerify Contract on an EPG


Consumer



Applying or Removing VRF ContractsTo apply contracts to all endpoint groups within a VRF instance, contracts can be applied directly to the VRFinstance. This concept is also referred as "vzAny" endpoint group. It eases contract management by allowingthe contract configuration for all endpoint groups within a VRF instance from a single location as well asoptimizing hardware resource consumption.

For example, if an Cisco Application Centric Infrastructure (ACI) administration has 100 endpoint groupsthat are all part of the same VRF instance, they can apply the contracts to this one vzAny group under theVRF instance, rather than to each endpoint group.

VRF instance-wide contracts are traditionally contracts that allow established traffic allowing endpoint groupcontracts to only define traffic in one direction, from consumer to provider, without the need to have reverseport forwarding enabled for TCP traffic. Since all endpoint groups within the VRF instance allow establishedtraffic, reverse port forwarding is unnecessary in the contract applied to the endpoint group directly.

A quick trick to see if contracts, or the lack thereof, are blocking traffic within the VRF instance in an ACIfabric is to unenforce the VRF instance. This allows communication between all endpoint groups within theVRF instance without the need for contracts. This is equivalent to applying the common tenant contract vzAnyto the VRF instance endpoint group.

If there is a very large number of contracts within the VRF, it can take up to an hour or more to re-implementthe contracts in the leaf switches when the VRF is moved back to enforced.

Note

In the case of shared services, you must define the provider EPG shared subnet under the EPG in order toproperly derive the pcTag (classification) of the destination from the consumer (vzAny) side. If you aremigrating from a bridge domain-to-bridge domain shared services configuration, where both the consumerand provider subnets are defined under bridge domains, to vzAny acting as a shared service consumer, youmust take an extra configuration step where you add the provider subnet to the EPG with the shared flags atminimum.

If you add the EPG subnet as a duplicate of the defined bridge domain subnet, ensure that both definitions ofthe subnet always have the same flags defined. Failure to do so can result in unexpected fabric forwardingbehavior.

Note

Applying a Contract to a VRF (vzAny) Using the GUI1. On the menu bar, choose Tenants > ALL TENANTS.


Working with ContractsApplying or Removing VRF Contracts


3. In the Navigation pane choose Tenant_Name > Networking > Private Networks >Private_Network_Name > EPG Collection for Context.

4. In the Work pane, click + next to either Add Provided Contract or Add Consumed Contract.

Make a selection depending on how the contract is to be deployed.

a. Enter a Contract_Name .

b. Choose a QOS Type.

c. Choose a Match Criteria.

5. Click Update.

Removing a Contract from a VRF (vzAny) Using the GUI1. On the menu bar, choose Tenants > ALL TENANTS.


3. In the Navigation pane choose Tenant_Name > Networking > Private Networks >Private_Network_Name > EPG Collection for Context.

4. In the Work pane, choose the Contract_Name and click x.

Verifying VRF ContractsThe following API verifies a VRF's contracts:/api/node/class/vzBrCP.xml

The following iShell command verifies a VRF's contracts:admin@apic1:~> moquery -c vzBrCP

FiltersA filter is a group of filter entries that are aimed to filter traffic. Each filter entry is a rule that allows or deniestraffic that is classified based on TCP/IP header fields, such as Layer 3 protocol type or Layer 4 ports. Thefilter is defined on the contract that is associated with an endpoint group. This can be either incoming towardan endpoint group, outgoing away from an endpoint group, or both. A subject is an entity that connects thefilter to the contract, thereby affecting the traffic between endpoint groups that are provided and consumedby this contract.

Filter Entry Configuration ParametersWhen configuring a filter, the following options can be defined:

• Name: The name of a filter entry.

• EtherType: The EtherType of the filter entry. The EtherTypes are:


Working with ContractsRemoving a Contract from a VRF (vzAny) Using the GUI

• ARP

• FCOE

• IP

• MAC Security

• MPLS Unicast

• Trill

• Unspecified

• ARP Flag: The Address Resolution Protocol flag for a filter entry. The filter entry is a combination ofnetwork traffic classification properties.

• IP Protocol: The IP protocol for a filter entry. The filter entry is a combination of network trafficclassification properties.

• Match Only Fragments: Match only packet fragments.When enabled, the rule applies to any IP fragmentwith an offset that is greater than 0 (all IP fragments except the first). When disabled, the rule will notapply to IP fragments with an offset greater than 0 because TCP/UDP port information can only bechecked in initial fragments.

• Port Ranges (Source, Destination): The port fields for the source and destination. You can define a singleport by specifying the same value in the From and To fields, or you can define a range of ports from 0to 65535 by specifying different values in the From and To fields. Instead of specifying a number, youcan instead choose one of the following server types to use the pre-defined port of that type:

• HTTPS

• SMTP

• HTTP

• FTP-Data

• Unspecified

• DNS

• POP3

• RTSP

The default is Unspecified.

• TCP Flags: This option specifies the TCP flag values to match traffic in addition to EtherType, IPprotocol, source port, and destination port. The available TCP flags are:

• Synchronize: SYN

• Established: ACK or RST

• Acknowledgement: ACK

• Reset: RST

• Finish: FIN


Working with ContractsFilter Entry Configuration Parameters

• Stateful: The Stateful option allows TCP packets from the provider to the consumer only if the ACKflag is set.

Creating Filters Using the GUIThe following procedure creates a filter using the GUI:

Procedure

Step 1 On the menu bar, choose Tenants > All Tenants.Step 2 In the Work pane, double click the tenant's name.Step 3 In the Navigation pane, choose Tenant tenant_name > Security Policies > Filters.Step 4 In the Work pane, choose Actions > Create Filter.Step 5 In the Create Filter dialog box, fill in the fields as required, except as specified below:

a) In the Name field, enter a name for the filter.b) On the Entries table, click +.

Step 6 In the Entries table, fill in the fields as specified below:a) In the Name field, enter a name for the filter entry.b) In the Ethertype drop-down list, choose an ethertype.c) (Optional) In the ARP Flag drop-down list, choose an ARP flag.d) (Optional) In the IP Protocol drop-down list, choose an IP protocol.e) (Optional) If required, put a check in the Match Only Fragments check box.f) (Optional) In the Source Port From drop-down list, choose a source port.g) (Optional) In the Source Port To drop-down list, choose a source port.h) (Optional) In the Destination Port From drop-down list, choose a destination port.i) (Optional) In the Destination Port To drop-down list, choose a destination port.j) (Optional) In the TCP Flags drop-down list, choose a TCP flag.k) (Optional) If required, put a check in the Stateful check box.l) Click Update.

Step 7 Click Submit.

Modifying Filters Using the GUIThe following procedure modifies a filter using the GUI:

Procedure

Step 1 On the menu bar, choose Tenants > All Tenants.Step 2 In the Work pane, double click the tenant's name.Step 3 In the Navigation pane, choose Tenant tenant_name > Security Policies > Filters > filter_name.Step 4 In the Navigation pane, in the Entries table, double click on the filter entry that you want to modify.


Working with ContractsCreating Filters Using the GUI

Step 5 Modify the values.Step 6 Click Update.

Removing Filters Using the GUI1. On the menu bar, choose Tenants > ALL TENANTS.


3. In the Navigation pane choose Tenant_Name > Security Policies > Filters > Filter_Name .


Configuring Filters Using the NX-OS-Style CLIThe filters can be created and accessed in the NX-OS-style CLI through the tenant shell.

Procedure

Step 1 SSH to an APIC in the fabric.# ssh admin@node_name

Step 2 Enter the configure mode:apic1# configure

Step 3 Go to the desired tenant:apic1(config)# tenant tenant1

Step 4 Create a filter called "FilterHTTPS" with the entries of "match tcp dest 80" and "match ip":apic1(config-tenant)# access-list FilterHTTPSapic1(config-tenant-acl)# match tcp dest 80apic1(config-tenant-acl)# match ipapic1(config-tenant-acl)# exit

Step 5 Access the contract to which you want to apply the "FilterHTTPS" filter:apic1(config-tenant)# contract WebHTTPS

Step 6 Create a subject "SubjectHTTPS", which will connect the filter to the contract. This way we can impose thesame filter on several contracts without having to create multiple filters with identical entries.apic1(config-tenant-contract)# subject SubjectHTTPS

Step 7 Tie the filter to the contract. You can use the filter to match traffic that is incoming to the endpoint group thatis tied to the contract "WebHTTPs", to match traffic that is outgoing from the endpoint group that is tied tothe contract, or for both.apic1(config-tenant-contract-subj)# access-group FilterHTTPSboth match traffic in both directionin match traffic from provider to consumer


Working with ContractsRemoving Filters Using the GUI

out match traffic from consumer to providerapic1(config-tenant-contract-subj)# access-group FilterHTTPS both

Removing and Deleting Filters Using the NX-OS-Style CLI

Procedure

Step 1 The following command removes the filter association:apic1(config-tenant-contract-subj)# no access-group FilterHTTPS both

Step 2 The following command deletes the entire filter:apic1(config-tenant)# no access-list FilterHTTPS

Verifying FiltersYou can use any of the following methods to verify the filters:

• In the GUI, navigate to the following location:

Tenant_Name > Security Policies > Filters > Filter_Name

• Use the following API:

/api/node/class/vzFilter.xml

• Enter the following NX-OS-style CLI command:apic1# show run

• Enter the following object model CLI command:admin@apic1:~> moquery -c vzFilter

Taboo ContractsThere may be times when the ACI administrator might need to deny traffic that is allowed by another contract.Taboos are a special type of contract that an ACI administrator can use to deny specific traffic that wouldotherwise be allowed by another contract. Taboos can be used to drop traffic matching a pattern (any EPG, aspecific EPG, matching a filter, and so forth). Taboo rules are applied in the hardware before the rules ofregular contracts are applied.

To imitate the traditional networking concepts, an "allow-all-traffic" contract can be applied, with taboocontracts configured to restrict certain types of traffic.


Working with ContractsRemoving and Deleting Filters Using the NX-OS-Style CLI

Taboo Contract Configuration ParametersWhen configuring Taboo Contracts you can define the following options:

• Name - The name of the contract or contract object.

• Subjects - The network domain name label. Labels enable classification of the objects which can andcannot communicate with one another (optional).

• Directive - The filter directives assigned to the taboo contract.

Create/Modify/Delete Taboo Contracts

Create Taboo Contracts1. On the menu bar, choose Tenants > ALL TENANTS.


3. In the Navigation pane choose Tenant_Name > Security Policies > Taboo Contracts .

4. In the Work pane, choose Action > Create Taboo Contract.

5. In the Create Taboo Contract dialog box, perform the following actions:

a. Enter a Taboo Contract Name.

b. Click + to next to the Subject field to add a Taboo Subject.

1. Enter a Filter Name.

2. Choose Directives.

6. Click Update.

7. Click OK.

8. Click Submit.

Modify Taboo Contracts1. On the menu bar, choose Tenants > ALL TENANTS.


3. In the Navigation pane choose Tenant_Name > Security Policies > Taboo Contracts >Taboo_Contract_Name .

4. In the Work pane, choose policy.

a. Click + to next to the Subject field.

b. In the Create Taboo Contract Subject dialog box, perform the following actions:

1. Enter a Taboo Contract Subject Name.

2. Click + in the Filter Chain field.


Working with ContractsTaboo Contract Configuration Parameters

a. Enter a Filter Name.

b. Choose Directives.

5. Click Submit.

Delete Taboo Contracts1. On the menu bar, choose Tenants > ALL TENANTS.


3. In the Navigation pane choose Tenant_Name > Security Policies > Taboo Contracts >Taboo_Contract_Name .

4. In the Work pane, choose Action > Delete.

Verify Taboo Contracts

REST :: /api/node/class/vzTaboo.xml

CLI :: moquery -c vzTaboo

Apply/Remove Taboo Contracts

Apply a Taboo Contract to an EPG1. On the menu bar, choose Tenants > ALL TENANTS.


3. In the Navigation pane choose Tenant_Name > Application Profiles > Application_Profile_Name >Application EPGs > EPG_Name > Contracts.

4. In the Work pane, choose Actions > Add Taboo Contract.

5. In the Add Taboo Contract dialog box,

a. Choose the Taboo Contract.

6. Click Submit.

Remove a Taboo Contract from an EPG1. On the menu bar, choose Tenants > ALL TENANTS.


3. In the Navigation pane choose Tenant_Name > Application Profiles > Application_Profile_Name >Application EPGs > EPG_Name > Contracts.

4. In the Work pane, choose the Taboo Contract_Name > Actions > Delete.


Working with ContractsDelete Taboo Contracts

Verify Taboo Contracts Applied to an EPG

Provider



Consumer



Inter-Tenant ContractsThere may be times when the ACI administrator might need to allow traffic between two tenants. Interfacecontracts are a special type of contract that an ACI administrator can use to allow specific traffic through theuse of a contract export. The contract in essence is exported in the source tenant and imported into the targettenant. Similar to traditional contracts, the source EPG will be of type provider. However, in the target tenant,the contract is imported as type contract interface. Some use case examples show the complete process in thenext chapter.

Configuration ParametersWhen importing a contract, the following options can be defined:

• Name - The name of the contract interface.

• Global Contract - Name of a service contract to be shared between two or more participating peerentities.

• Tenant - The Tenant name of the targeted Export contract.

Create/Modify/Remove Export Contracts

Export Contract1. On the menu bar, choose Tenants > ALL TENANTS.


3. In the Navigation pane choose Tenant_Name > Security Policies > Contracts.

4. In the Work pane, choose Actions > Export Contract.

5. In the Export Contract dialog box, perform the following actions:

a. Enter an Export Contract Name.

b. Choose the Global Contract.


Working with ContractsVerify Taboo Contracts Applied to an EPG

c. Enter the Tenant Name.

6. Click Finish.

Modify Exported Contracts1. On the menu bar, choose Tenants > ALL TENANTS.



4. In the Work pane, choose policy.

a. Enter an Export Contract Name.

b. Choose the Global Contract.

c. Enter the Tenant Name.

5. Click Finish.

Remove Exported Contracts1. On the menu bar, choose Tenants > ALL TENANTS.


3. In the Navigation pane choose Tenant_Name > Security Policies > Contracts > Imported Contracts> Contact_Name.


Verify Exported Contracts

REST :: /api/node/class/vzCPif.xml

CLI :: moquery -c vzCPif

Ingress-Based ACLsThe main purpose of the ingress-based ACL feature is to save resources on the border leaf. In this policyenforcementmodel, the policywill be only applied on non-border leafs, thereby reducing zone-rule consumptionon border leafs. This enforcement direction policy is applied at the VRF level and allows for backwardcompatibility with the previous policy enforcement model. The policy enforcement direction for this newmodel is as follows:

1. Host to WAN—The policy is applied on the non-border leaf2. WAN to Host—The policy is applied on non-border leaf regardless of whether or not the endpoint group

is learned on the border leaf3. WAN to WAN—The policy is applied on ingress border leaf


Working with ContractsModify Exported Contracts

This feature is not compatible with the transit routing, vzAny, and taboo contract use cases. Transit routingrules are already applied at ingress.

Configuring Ingress-Based ACLs Using the GUIPolicy control enforcement direction is applied on the VRF.

Procedure

Step 1 On the menu bar, choose Tenant > All TENANTS.Step 2 In the Work pane, double click the tenant's name.Step 3 In the Navigation Pane, choose Networking > VRFs > VRF Name.Step 4 In the Work pane, set Policy Control Enforcement Direction to Ingress.Step 5 Click Submit.Step 6 Verify the policy usage, then click Submit Changes.

Verifying Ingress-Based ACLsThe following iShell command verifies the ingress-based ACLs:admin@apic1:~> moquery -c fv.Ctx -f ‘fv.Ctx.name==”vrf-name”’

The following hardware CLI commands verify the ingress-based ACLs:# vsh_lcmodule-1# show system internal eltmc info vrf name

Contracts Use CasesThese use cases all assume the objective is for a host in EPG-1 to talk to a host in EPG-2, achieving bidirectionaltraffic. How these scenarios are implemented will depend on the operational model chosen, and whether thesystem is more focused on object re-use or tenant autonomy. Review the Contracts section on Contract Scopingfor a more detailed discussion.

These are some common scenarios:

1. Inter-Tenant Contracts2. Inter-Private Network Contracts3. Single Contract Bidirectional forwarding with reverse filter4. Single Contract Unidirectional with multiple Filters5. Multiple Contracts Unidirectional with single Filter

Inter-Tenant ContractsACME Inc., as with most companies, makes use of shared services such as DNS for name resolution andActive Directory for user management. These services will be used across most of their tenants and so ACMEInc. must allow this traffic across the whole fabric. Communication between EPGs that belong to differenttenants is only allowedwhen they share the same contract. To use the same contract, it will need to be exportedfrom the source tenant to the appropriate destination tenant. That contract will appear under the ImportedContract section in the Security Policies of the destination tenant.


Working with ContractsConfiguring Ingress-Based ACLs Using the GUI

AConsumed Contract Interface will be used to associate an EPG from the destination tenant with the importedcontract.

Note: A contract consumption interface represents one or more subjects defined under the contract. Byassociating to an interface, an endpoint group starts consuming all the subjects represented by the interface.

In the use case below, EPG-1 in tenant Cisco-1 requires communication with EPG-2 in tenant Cisco-2. Thisis accomplished by utilizing contact interfaces. In tenant Cisco-1 the user will export the intended contractinterfaces. In tenant Cisco-1 the user will export the intended contract and select provider to provide thecontrast to EPG-2. The user will then confirm the imported contract in tenant Cisco-2 and select the contractas consumed. To advertise the routes from the source VRF to the intended VRF, the user must create thesubnet within the EPG.

Figure 2: Exporting Contracts Between Tenants

Tenant Cisco-1/EPG-1

1. Create an Export Contract under security policies.2. Create the host subnet (default Gateway IP) under EPG1 - subnet scope shared.3. Add the Contract under EPG1 - contract type provider.4. Create the host subnet under the bridge domain - subnet scope private/public.

Tenant Cisco-2/EPG-2

1. Confirm the exported contract is listed under Imported Contracts.2. Create the host subnet (default Gateway IP) under EPG2 - subnet scope shared.3. Add the Interface Contract under EPG2 - contract type consumed.4. Create the host subnet (default Gateway IP) under the bridge domain - subnet scope private/public.

Inter-Private Network Contracts CommunicationIn the use case below, EPG-1 in VRF Cisco-1 requires communication with EPG-2 in VRF Cisco-2. This isaccomplished by utilizing the subnet field within the EPG. By creating the subnet under the EPG and selectingshared, the route will be leaked to the VRF noted within the Tenant scoped contract.


Working with ContractsInter-Private Network Contracts Communication

Figure 3: Exporting Contracts Between Private Networks

1. Create the contract under Security Policies - contract scope Tenant.2. (Tenant Cisco-1/EPG-1) Create the host subnet (default Gateway IP) under EPG1 - subnet scope shared.3. Add the Contract under EPG1 - contract type provider.4. (Tenant Cisco-1/EPG-2) Create the host subnet (default Gateway IP) under EPG2 - subnet scope shared.5. Add the Contract under EPG2 - contract type provider.

Single Contract Bidirectional Reverse FilterThis use case is useful when implementing a contract with the option to apply the contract subject in bothdirections and with the option to apply the reverse filter. This is the most common of the use cases and allowsfor a single subject/filter to be implemented with a single provider/consumer relationship.

In the use case below, EPG-1 is providing a contract with a subject named as "www" that has a filter for TCPtraffic with source port any and destination port 80 (HTTP) along with theApply Both Direction andReverseFilter Port options. This allows the Web client in EPG-2 to start an HTTP session with port 80 on the Webserver in EPG-1. That is, EPG-1 is providing a service to EPG-2. However, this also allows EPG-1 to initiateTCP sessions from port 80 to any ports on EPG-2, which is typically not the intent of the configuration. Byenabling the Stateful option in the same filter, only the traffic with theTCP ACK flag is allowed from EPG-1(provider) to ensure that the traffic is initiated from the consumer side first. However, it does not prevent anSYN + ACK attack from the provider, unlike a stateful firewall.

Figure 4: Default Bi-directional Contract with Reverse Filter

Result:


Working with ContractsSingle Contract Bidirectional Reverse Filter

A single contract with (1) subject and (1) filter with a single provider and a single consumer. In this example,www.

Single Contract Unidirectional with Multiple FiltersThis use case involves implementing a contract without the option to apply the contract subject in bothdirections. When selecting this option the user no longer has the option to select the reverse filter option.

In the use case below, EPG-1 is providing a contract with a subject of icmp and EPG-2 is consuming thecontract. This allows the Host in EPG-1 to access the Host in EPG-2 via icmp. When utilizing a single subjectwithout the use of "Apply Both Directions," the user must then configure two filters, one in each direction.

Figure 5: Single Contract, Single Unidirectional Subject, Multiple Filters

Result:

A single contract with (1) Subject (2) Filters and a single provider and a single consumer. In this example,icmp.

Multiple Contracts Uni-Directional Single FilterThis use case is useful when implementing a contract with the option to apply the contract subject in bothdirections, and without the option to apply the reverse filter. This allows the end-user the most granularitywhen deploying contracts, but is also the most comprehensive.

In the use case below, EPG-1 is providing a contract with a subject of www and EPG-2 is consuming thecontract. This allows theWeb Client in EPG-2 to access theWeb Server in EPG-1. That is, EPG-1 is providinga service to EPG-2.


Working with ContractsSingle Contract Unidirectional with Multiple Filters

Figure 6: Multiple Contracts, Unidirectional Subjects, Single Filters

Result:

Two contracts with (1) Subject (1) Filters. Each contract will have a single provider and a single consumerreferencing the same contract. The difference here is that the contract is explicitly applied in BOTH directions.


Working with ContractsMultiple Contracts Uni-Directional Single Filter

Working with Contracts - Cisco€¦ · Step2 IntheWorkpane,doubleclickthetenant'sname. Step3...

Documents

Transcript of Working with Contracts - Cisco€¦ · Step2 IntheWorkpane,doubleclickthetenant'sname. Step3...