Working with Contracts

Transcription

1 Contracts, page 1 Filters, page 9 Taboo Contracts, page 12 Inter-Tenant Contracts, page 15 Contracts Contracts provide a way for the Cisco Application Centric Infrastructure (ACI) administrator to control traffic flow within the ACI fabric between endpoint groups. These contracts are built using a provider-consumer model where one endpoint group provides the services it wants to offer and another endpoint group consumes them. Contracts are assigned a scope of Global, Tenant, VRF, or Application Profile, which limit the accessibility of the contract. In brief, contracts consist of 1 or more subjects. Each subject contains 1 or more filters. Each filter contains 1 or more entries. Each Entry is equivalent to a line in an Access Control List (ACL) that is applied on the leaf 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, protocol type, 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) 1

2 Contracts Labels (Optional) Used to group objects such as subjects and endpoint groups for the purpose of increasing granularity in policy enforcement. While different endpoint groups can only communicate with other endpoint groups based upon the contract rules defined, there is no contract required for intra-endpoint group communication. Intra-endpoint group communication from endpoint to endpoint in the same endpoint group is allowed by default. If a filter allows traffic from any consumer port to a provider port (e.g. 8888), if reverse port filtering is enabled and the contract is applied both directions (say for TCP traffic), either the consumer or the provider can initiate communication. The provider could open up a TCP socket to the consumer using port 8888, whether the provider or consumer sent traffic first. If you do not configure a contract, traffic is permitted only for the following types of packets as well as the types that are permitted by default for multicast traffic and class equal traffic: DHCP v4 (prot 0x11, sport 0x44, dport 0x43) DHCP v4 (prot 0x11, sport 0x43, dport 0x44) DHCP v6 (prot 0x11, sport 0x222, dport 0x223) 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 in a 3-tiered application containing a group of web servers in one endpoint group, a group of application servers in a second endpoint group, and a group of database servers in a third endpoint group. The Web endpoint group (provider) provides a contract (contract1) which is consumed by the L3Out endpoint group (traffic external to the ACI fabric). This allows for web traffic to reach the web servers from outside the ACI fabric. The Application endpoint group (provider) provides a contract (contract2) for communications which the Web endpoint group (consumer) consumes. This allows the web server to call applications on the application 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 the database for the applications. For un-acked UDP traffic, reverse port filtering is not necessary. But, for TCP traffic, the 2

3 Contract Configuration Parameters responder cannot set up a TCP session without reverse port filtering enabled or a different contract that allows any established traffic from the responder. Figure 1: Contract Policies Between End Point Groups The following types of Contracts that can be applied in 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-band management is configured for the ACI fabric and certain endpoint groups are to be allowed to access it Out-of-band contracts apply only to out-of-band traffic from the management tenant. Taboo contracts are used to deny and log traffic related to regular contracts and are configured into the hardware before the regular contract. For example, if the objective was to allow traffic with source ports 50 through 500 with the exception of port 305, then the regular contract would allow all ports in the range of 50 through 500 while the taboo contract would have a single entry denying port 305. The taboo contract denying port 305 would be programmed into the hardware before the regular contract allowing ports 50 through 500. Contract Configuration Parameters When configuring contracts you can define the following options: Application-profile This contract can be applied to any endpoint groups in the same application profile. Contract Scope The scope of a service contract between two or more participating peer entities or endpoint groups. The contract will not be applied to any consumer endpoint group outside the scope of the provider endpoint group. The states are: 3

4 Create/Modify/Remove Regular Contracts 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 tag allows you to group multiple objects by a descriptive name. You can assign the same tag name to multiple objects and you can assign one or more tag names to an object. When contracts are assigned to an endpoint group as either a consumer or provider, by default all subjects within a contract apply to the endpoint group. With tags, only endpoint groups in application profiles with matching criteria will implement the subject of the contract. Match -The subject match criteria across consumer endpoint groups. Labels can be applied to a variety of provider and consumer managed objects, including endpoint groups, contracts, bridge domains, DHCP relay 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 labels are considered a match. AtmostOne Matches only when all labels on the endpoint groups are exactly the same. Blank labels 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 Contracts 3 In the Navigation pane choose Tenant_Name > Security Policies > Contracts. 4 In the Work pane, choose Actions > Create Contract. 4

5 Create/Modify/Remove Regular Contracts 5 In the Create Contract dialog box, perform the following actions: a b c d Enter a Contract Name. Choose a Contract Scope (optional). Choose a QoS Class (optional). Click + next to the Subject to add a Contract Subject. a 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 Contracts 3 In the Navigation pane choose Tenant_Name > Security Policies > Contracts > Contract_Name. 4 In the Work pane, choose the Policy tab. a b c Choose a Contract Scope (optional). Choose a Qos Class (optional). Click + next to the Subject field. to add a Contract Subject. a In the Create Contract Subject dialog box, perform the following actions: a Enter a Contract Subject Name. b Click + next to Filter Chain. Note: For information regarding filter creation, see the "Filters" section. 5 Click Update. 6 Click OK. 7 Click Submit. Remove Contracts 3 In the Navigation pane choose Tenant_Name > Security Policies > Contracts > Contract_Name. 4 In the Work pane, choose Actions > Delete. 5

6 Apply/Remove EPG Contracts Verify Contracts REST :: /api/node/class/vzbrcp.xml CLI :: moquery -c vzbrcp Apply/Remove EPG Contracts Apply a Contract to an EPG 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 b c Enter a Contract_Name. Choose a QOS policy (optional). Choose a Label (optional). 6 Click Submit. Remove a Contract from an EPG 3 In the Navigation pane choose Tenant_Name > Application Profiles > Application_Profile_Name > Application EPGs > EPG_Name > Contracts > Contract_Name. 4 In the Work pane, choose Actions > Delete. 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 6

7 Apply/Remove External Network Contracts Apply/Remove External Network Contracts Apply a Contract to an External Network 3 In the Navigation pane choose Tenant_Name > Networking > External Routed Networks > Routed Outside_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 b c Choose a Contract_Name. Choose a QOS Type. Choose a Match Criteria. 5 Click Update. Remove a Contract from an External Network 3 In the Navigation pane choose Tenant_Name > Networking > External Routed Networks > Routed Outside_Name > Networks > External_Network_Instance_Profile. 4 In the Work pane, choose the Contract_Name and click x. Verify External Network Contracts Provider REST :: /api/node/class/fvrsprov.xml CLI :: moquery -c fvrsprov Consumer REST :: /api/node/class/fvrscons.xml CLI :: moquery -c fvrscons Applying or Removing VRF Contracts To apply contracts to all endpoint groups within a VRF, contracts can be applied directly to the VRF. This concept is also referred as "vzany" endpoint group. It eases contract management by allowing the contract configuration for all endpoint groups within a VRF from a single location as well as optimizing hardware resource consumption. 7

8 Applying or Removing VRF Contracts For example, if an Cisco Application Centric Infrastructure (ACI) administration has 100 endpoint groups that are all part of the same VRF, they can apply the contracts to this one vzany group under the VRF, rather than to each endpoint group. VRF-wide contracts are traditionally contracts that allow established traffic allowing endpoint group contracts to only define traffic in one direction, from consumer to provider, without the need to have reverse port forwarding enabled for TCP traffic. Since all endpoint groups within the VRF allow established traffic, 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 in an ACI fabric is to unenforce the VRF. This allows communication between all endpoint groups within the VRF without the need for contracts. This is equivalent to applying the common tenant contract vzany to the VRF endpoint group. Note If there is a very large number of contracts within the VRF, it can take up to an hour or more to re-implement the contracts in the leaf switches when the VRF is moved back to enforced. Applying a Contract to a VRF (vzany) Using the GUI 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. Note: Make a selection depending on how the contract is to be deployed. a b c Enter a Contract_Name. Choose a QOS Type. Choose a Match Criteria. 5 Click Update. Removing a Contract from a VRF (vzany) Using the GUI 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 Contracts The 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 8

9 Filters Filters A filter is a group of filter entries that are aimed to filter traffic. Each filter entry is a rule that allows or denies traffic that is classified based on TCP/IP header fields, such as Layer 3 protocol type or Layer 4 ports. The filter is defined on the contract that is associated with an endpoint group. This can be either incoming toward an endpoint group, outgoing away from an endpoint group, or both. A subject is an entity that connects the filter to the contract, thereby affecting the traffic between endpoint groups that are provided and consumed by this contract. Filter Entry Configuration Parameters When 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: 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 of network traffic classification properties. IP Protocol The IP protocol for a filter entry. The filter entry is a combination of network traffic classification properties. Match Only Fragments Match only packet fragments. When enabled, the rule applies to any IP fragment with an offset that is greater than 0 (all IP fragments except the first). When disabled, the rule will not apply to IP fragments with an offset greater than 0 because TCP/UDP port information can only be checked in initial fragments. Port Ranges (Source, Destination) The port fields for the source and destination. You can define a single port by specifying the same value in the From and To fields, or you can define a range of ports from 0 to by specifying different values in the From and To fields. Instead of specifying a number, you can instead choose one of the following server types to use the pre-defined port of that type: HTTPS SMTP HTTP FTP-Data Unspecified 9

10 Creating Filters Using the GUI DNS POP3 RTSP The default is Unspecified. TCP Session Rules The TCP session rules for a filter entry. The filter entry is a combination of network traffic classification properties. Creating Filters Using the GUI The following procedure creates a filter using the GUI: Procedure Step 1 Step 2 Step 3 Step 4 Step 5 Step 6 Step 7 On the menu bar, choose Tenants > All Tenants. In the Work pane, double click the tenant's name. In the Navigation pane, choose Tenant tenant_name > Security Policies > Filters. In the Work pane, choose Actions > Create Filter. 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 +. 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 Session Rules drop-down list, choose a TCP session rule. k) Click Update. Click Submit. Modifying Filters Using the GUI The following procedure modifies a filter using the GUI: 10

11 Removing Filters Using the GUI Procedure Step 1 Step 2 Step 3 Step 4 Step 5 Step 6 On the menu bar, choose Tenants > All Tenants. In the Work pane, double click the tenant's name. In the Navigation pane, choose Tenant tenant_name > Security Policies > Filters > filter_name. In the Navigation pane, in the Entries table, double click on the filter entry that you want to modify. Modify the values. Click Update. Removing Filters Using the GUI 3 In the Navigation pane choose Tenant_Name > Security Policies > Filters > Filter_Name. 4 In the Work pane, choose Actions > Delete. Configuring Filters Using the NX-OS-Style CLI The filters can be created and accessed in the NX-OS-style CLI through the tenant shell. Procedure Step 1 Step 2 Step 3 Step 4 Step 5 Step 6 SSH to an APIC in the fabric. # ssh admin@node_name Enter the configure mode: apic1# configure Go to the desired tenant: apic1(config)# tenant tenant1 Create a filter called "FilterHTTPS" with the entries of "match tcp dest 80" and "match ip": apic1(config-tenant)# access-list FilterHTTPS apic1(config-tenant-acl)# match tcp dest 80 apic1(config-tenant-acl)# match ip apic1(config-tenant-acl)# exit Access the contract to which you want to apply the "FilterHTTPS" filter: apic1(config-tenant)# contract WebHTTPS Create a subject "SubjectHTTPS", which will connect the filter to the contract. This way we can impose the same filter on several contracts without having to create multiple filters with identical entries. apic1(config-tenant-contract)# subject SubjectHTTPS 11

12 Removing and Deleting Filters Using the NX-OS-Style CLI Step 7 Tie the filter to the contract. You can use the filter to match traffic that is incoming to the endpoint group that is tied to the contract "WebHTTPs", to match traffic that is outgoing from the endpoint group that is tied to the contract, or for both. apic1(config-tenant-contract-subj)# access-group FilterHTTPS both match traffic in both direction in match traffic from provider to consumer out match traffic from consumer to provider apic1(config-tenant-contract-subj)# access-group FilterHTTPS both Removing and Deleting Filters Using the NX-OS-Style CLI Procedure Step 1 Step 2 The following command removes the filter association: apic1(config-tenant-contract-subj)# no access-group FilterHTTPS both The following command deletes the entire filter: apic1(config-tenant)# no access-list FilterHTTPS Verifying Filters You 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 Contracts There 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 would otherwise be allowed by another contract. Taboos can be used to drop traffic matching a pattern (any EPG, a specific EPG, matching a filter, and so forth). Taboo rules are applied in the hardware before the rules of regular contracts are applied. 12

13 Taboo Contract Configuration Parameters To imitate the traditional networking concepts, an "allow-all-traffic" contract can be applied, with taboo contracts configured to restrict certain types of traffic. Taboo Contract Configuration Parameters When 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 and cannot communicate with one another (optional). Directive - The filter directives assigned to the taboo contract. Create/Modify/Delete Taboo Contracts Create Taboo Contracts 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 b Enter a Taboo Contract Name. Click + to next to the Subject field to add a Taboo Subject. a Enter a Filter Name. b Choose Directives. 6 Click Update. 7 Click OK. 8 Click Submit. Modify Taboo Contracts 3 In the Navigation pane choose Tenant_Name > Security Policies > Taboo Contracts > Taboo_Contract_Name. 4 In the Work pane, choose policy. a b Click + to next to the Subject field. In the Create Taboo Contract Subject dialog box, perform the following actions: a Enter a Taboo Contract Subject Name. b Click + in the Filter Chain field. 13

14 Apply/Remove Taboo Contracts a b Enter a Filter Name. Choose Directives. 5 Click Submit. Delete Taboo Contracts 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 EPG 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 EPG 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. 14

15 Inter-Tenant Contracts Verify Taboo Contracts Applied to an EPG Provider REST :: /api/node/class/fvrsprov.xml CLI :: moquery -c fvrsprov Consumer REST :: /api/node/class/fvrscons.xml CLI :: moquery -c fvrscons Inter-Tenant Contracts Configuration Parameters There may be times when the ACI administrator might need to allow traffic between two tenants. Interface contracts are a special type of contract that an ACI administrator can use to allow specific traffic through the use of a contract export. The contract in essence is exported in the source tenant and imported into the target tenant. 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 the next chapter. When 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 peer entities. Tenant - The Tenant name of the targeted Export contract. Create/Modify/Remove Export Contracts Export Contract 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 b c Enter an Export Contract Name. Choose the Global Contract. Enter the Tenant Name. 15

16 Ingress-Based ACLs 6 Click Finish. Modify Exported Contracts 3 In the Navigation pane choose Tenant_Name > Security Policies > Contracts > Contract_Name. 4 In the Work pane, choose policy. a b c Enter an Export Contract Name. Choose the Global Contract. Enter the Tenant Name. 5 Click Finish. Remove Exported Contracts 3 In the Navigation pane choose Tenant_Name > Security Policies > Contracts > Imported Contracts > Contact_Name. 4 In the Work pane, choose Actions > Delete. Verify Exported Contracts REST :: /api/node/class/vzcpif.xml CLI :: moquery -c vzcpif Ingress-Based ACLs The main purpose of the ingress-based ACL feature is to save resources on the border leaf. In this policy enforcement model, the policy will be only applied on non-border leafs, thereby reducing zone-rule consumption on border leafs. This enforcement direction policy is applied at the VRF level and allows for backward compatibility with the previous policy enforcement model. The policy enforcement direction for this new model is as follows: 1 Host to WAN The policy is applied on the non-border leaf 2 WAN to Host The policy is applied on non-border leaf regardless of whether or not the endpoint group is learned on the border leaf 3 WAN to WAN The policy is applied on ingress border leaf This feature is not compatible with the transit routing, vzany, and taboo contract use cases. Transit routing rules are already applied at ingress. 16

17 Contracts Use Cases Configuring Ingress-Based ACLs Using the GUI Policy control enforcement direction is applied on the VRF. Procedure Step 1 Step 2 Step 3 Step 4 Step 5 Step 6 On the menu bar, choose Tenant > All TENANTS. In the Work pane, double click the tenant's name. In the Navigation Pane, choose Networking > VRFs > VRF Name. In the Work pane, set Policy Control Enforcement Direction to Ingress. Click Submit. Verify the policy usage, then click Submit Changes. Verifying Ingress-Based ACLs The 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_lc module-1# show system internal eltmc info vrf name Contracts Use Cases These use cases all assume the objective is for a host in EPG-1 to talk to a host in EPG-2, achieving bidirectional traffic. How these scenarios are implemented will depend on the operational model chosen, and whether the system is more focused on object re-use or tenant autonomy. Review the Contracts section on Contract Scoping for a more detailed discussion. These are some common scenarios: 1 Inter-Tenant Contracts 2 Inter-Private Network Contracts 3 Single Contract Bidirectional forwarding with reverse filter 4 Single Contract Unidirectional with multiple Filters 5 Multiple Contracts Unidirectional with single Filter Inter-Tenant Contracts ACME Inc., as with most companies, makes use of shared services such as DNS for name resolution and Active Directory for user management. These services will be used across most of their tenants and so ACME Inc. must allow this traffic across the whole fabric. Communication between EPGs that belong to different tenants is only allowed when they share the same contract. To use the same contract, it will need to be exported from the source tenant to the appropriate destination tenant. That contract will appear under the Imported Contract section in the Security Policies of the destination tenant. 17

18 Contracts Use Cases A Consumed Contract Interface will be used to associate an EPG from the destination tenant with the imported contract. Note: A contract consumption interface represents one or more subjects defined under the contract. By associating 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. This is accomplished by utilizing contact interfaces. In tenant Cisco-1 the user will export the intended contract interfaces. In tenant Cisco-1 the user will export the intended contract and select provider to provide the contrast to EPG-2. The user will then confirm the imported contract in tenant Cisco-2 and select the contract as consumed. To advertise the routes from the source VRF to the intended VRF, the user must create the subnet 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. 18

19 Contracts Use Cases Inter-Private Network Contracts Communication In the use case below, EPG-1 in VRF Cisco-1 requires communication with EPG-2 in VRF Cisco-2. This is accomplished by utilizing the subnet field within the EPG. By creating the subnet under the EPG and selecting shared, the route will be leaked to the VRF noted within the Tenant scoped contract. 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 Filter This use case is useful when implementing a contract with the option to apply the contract subject in both directions and with the option to apply the reverse filter. This is the most common of the use cases and allows for 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 of www and EPG-2 is consuming the contract. This allows the Web Client in EPG-2 to access the Web Server in EPG-1. i.e. EPG-1 is providing a service to EPG-2. Figure 4: Default Bi-directional Contract with Reverse Filter Result: 19

20 Contracts Use Cases 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 Filters This use case involves implementing a contract without the option to apply the contract subject in both directions. 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 the contract. This allows the Host in EPG-1 to access the Host in EPG-2 via icmp. When utilizing a single subject without 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 Filter This use case is useful when implementing a contract with the option to apply the contract subject in both directions, and without the option to apply the reverse filter. This allows the end-user the most granularity when 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 the contract. This allows the Web Client in EPG-2 to access the Web Server in EPG-1. That is, EPG-1 is providing a service to EPG-2. Figure 6: Multiple Contracts, Unidirectional Subjects, Single Filters Result: 20

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

22 Contracts Use Cases 22