Aci Contract Labels

VRF instance-wide contracts are traditionally contracts that enable established traffic, so endpoint group contracts can define traffic in only one direction, from consumer to provider, without the need to enable reverse port forwarding for TCP traffic. Because all endpoint groups within the VRF instance allow established traffic, reverse port forwarding is not required in the contract applied directly to the endpoint group. Object MOs define the connectivity to allow or deny through the use of filters, and can include consumer and vendor object labels. The labels will be discussed in a future part. There may be times when the ACI administrator has to reject traffic allowed by another contract. Taboos are a special type of contract that an ACI administrator can use to deny certain traffic that would otherwise be allowed by another contract. Taboos can be used to remove traffic that matches a pattern (any EPG, a specific EPG, a corresponding filter, etc.). In the material, taboo rules are applied before the rules of regular contracts are applied. A contract MO contains several non-configurable MO (some will be defined later in this series because they are useful for troubleshooting) and zero or more subject MO of the vz:Subj class. If there are a very large number of contracts in the VRF, it may take up to an hour or more before the contracts are reimplemented in the sheet switches when the VRF is returned to the forced option. In the following use case, EPG-1 provides a contract with an icmp subject and EPG-2 consumes the contract. This allows the host in EPG-1 to access the host in EPG-2 through icmp. If you use a single topic without using Apply both directions, the user must then configure two filters, one in each direction.

Specifically, contracts are composed of the following points: The best way to visualize this is that the contract has a terminal connected to the consumer, the InTerm and a terminal connected to the provider, the OutTerm. Terminals apply their filters to traffic at the entrance. That is, for packets sent from the consumer to the supplier, the packets enter the InTerm and therefore filters are applied to it (according to the following figure, represented by the red terminal). However, the packages come from the OutTerm and, therefore, the filters associated with outTerm are not applied. A contract is a managed object (MO) of the vz:BrCP class. These managed objects are child elements of a client. This MO itself has few configurable properties: When configuring contracts, you can set the following options: It may happen that the ACI administrator needs to allow traffic between two tenants. Interface contracts are a special type of contract that an ACI administrator can use to authorize specific traffic using a contract export.

The contract is essentially exported to the source tenant and imported into the target tenant. Similar to traditional contracts, the source EPG is a type of provider. However, in the target client, the contract is imported as a type contract interface. A few application examples show the complete process in the next chapter. Managed object classes are named package:class. For a list of defined packages, see Business Information Model Reference: developer.cisco.com/media/mim-ref/mim_help.html in the Package Descriptions table. This table does not seem to have been updated since perhaps version 1.2 – some packages, such as `bfd`, are missing from the table. If we look at the table, we see that the package name `vz` in the class discussed so far means `virtual zones` – supposedly the original name of the contract feature. Label matching is used to determine which EPGs consumers and suppliers can communicate. The subject matter of the contract of a particular manufacturer or consumer of this contract determines that consumers and suppliers may communicate. If you do not configure a contract, traffic is allowed only for the following packet types and for the default allowed types for multicast and traffic of the same class: In the following use case, EPG-1 in Cisco VRF requires communication with EPG-2 in Cisco VRF 2.

This is achieved by using the subnet field in the EPG. By creating the subnet under the EPG and selecting released, the route is disclosed to the VRF specified in the tenant agreement. If EPG and object labels are present, label matching is performed first for EPGs and then for contract subjects. This use case is useful when implementing a contract with the ability to apply the object of the contract in both directions, and without the ability to apply the reverse filter. This allows the end user the greatest granularity in the delivery of contracts, but it is also the most complete. .