The policy universe contains all the tenant-managed objects where the policy for each tenant is defined.

<polUni>

This starting tag, <polUni>, in the first line indicates the beginning of the policy universe element. This tag is matched with </polUni> at the end of the policy. Everything in between is the policy definition.

The <fvTenant> tag identifies the beginning of the tenant element.

<fvTenant name="solar">

All of the policies for this tenant are defined in this element. The name of the tenant in this example is solar. The tenant name must be unique in the system. The primary elements that the tenant contains are filters, contracts, outside networks, bridge domains, and application profiles that contain EPGs.

The filter element starts with a <vzFilter> tag and contains elements that are indicated with a <vzEntry> tag.

The following example defines "Http" and "Https" filters. The first attribute of the filter is its name and the value of the name attribute is a string that is unique to the tenant. These names can be reused in different tenants. These filters are used in the subject elements within contracts later on in the example.

      <vzFilter name="Http">
          <vzEntry name="e1" etherT="ipv4" prot="tcp" dFromPort="80" dToPort="80"/>
      </vzFilter>
 
      <vzFilter name="Https">
          <vzEntry name="e1" etherT="ipv4" prot="tcp" dFromPort="443" dToPort="443"/>
      </vzFilter>

This example defines these two filters: Http and Https. The first attribute of the filter is its name and the value of the name attribute is a string that is unique to the tenant, i.e. these names can be reused in different tenants. These filters will be used in the subject elements within contracts later on in the example.

Each filter can have one or more entries where each entry describes a set of Layer 4 TCP or UDP port numbers. Some of the possible attributes of the <vzEntry> element are as follows:

• name

• prot

• dFromPort

• dToPort

• sFromPort

• sToPort

• etherT

• ipFlags

• arpOpc

• tcpRules

In this example, each entry’s name attribute is specified. The name is an ASCII string that must be unique within the filter but can be reused in other filters. Because this example does not refer to a specific entry later on, it is given a simple name of “e1”.

The EtherType attribute, etherT, is next. It is assigned the value of ipv4 to specify that the filter is for IPv4 packets. There are many other possible values for this attribute. Common ones include ARP, RARP, andIPv6. The default is unspecified so it is important to assign it a value.

Following the EtherType attribute is the prot attribute that is set to tcp to indicate that this filter is for TCP traffic. Alternate protocol attributes include udp, icmp, and unspecified (default).

After the protocol, the destination TCP port number is assigned to be in the range from 80 to 80 (exactly TCP port 80) with the dFromPort and dToPort attributes. If the from and to are different, they specify a range of port numbers.

In this example, these destination port numbers are specified with the attributes dFromPort and dToPort. However, when they are used in the contract, they should be used for the destination port from the TCP client to the server and as the source port for the return traffic. See the attribute revFltPorts later in this example for more information.

The second filter does essentially the same thing, but for port 443 instead.

Filters are referred to by subjects within contracts by their target distinguished name, tDn. The tDn name is constructed as follows:

uni/tn-<tenant name>/flt-<filter name>

For example, the tDn of the first filter above is uni/tn-coke/flt-Http. The second filter has the name uni/tn-coke/flt-Https. In both cases, solar comes from the tenant name.

The contract element is tagged vzBrCP and it has a name attribute.

         <vzBrCP name="webCtrct">
            <vzSubj name="http" revFltPorts="true" provmatchT="All">
                <vzRsSubjFiltAtt tnVzFilterName="Http"/>
                <vzRsSubjGraphAtt graphName="G1" termNodeName="TProv"/>
                <vzProvSubjLbl name="openProv"/>
                <vzConsSubjLbl name="openCons"/>
            </vzSubj>
            <vzSubj name="https" revFltPorts="true" provmatchT="All">
                <vzProvSubjLbl name="secureProv"/>
                <vzConsSubjLbl name="secureCons"/>
                <vzRsFiltAtt tnVzFilterName="Https "/>
                <vzRsOutTermGraphAtt graphName="G2" termNodeName="TProv"/>  
            </vzSubj>           
        </vzBrCP>

Contracts are the policy elements between EPGs. They contain all of the filters that are applied between EPGs that produce and consume the contract. The contract element is tagged vzBrCP and it has a name attribute. Refer to the object model reference documentation for other attributes that can be used in the contract element. This example has one contract named webCtrct.

The contract contains multiple subject elements where each subject contains a set of filters. In this example, the two subjects are http and https.

The contract is later referenced by EPGs that either provide or consume it. They reference it by its name in in the following manner:

uni/tn-[tenant-name]/brc-[contract-name]

tenant-name is the name of the tenant, “solar” in this example, and the contract-name is the name of the contract. For this example, the tDn name of the contract is uni/tn-solar/brc-webCtrct.

The subject element starts with the tag vzSubj and has three attributes: name, revFltPorts, and matchT. The name is simply the ASCII name of the subject.

revFltPorts is a flag that indicates that the Layer 4 source and destination ports in the filters of this subject should be used as specified in the filter description in the forward direction (that is, in the direction of from consumer to producer EPG), and should be used in the opposite manner for the reverse direction. In this example, the “http” subject contains the “Http” filter that defined TCP destination port 80 and did not specify the source port. Because the revFltPorts flag is set to true, the policy will be TCP destination port 80 and any source port for traffic from the consumer to the producer, and it will be TCP destination port any and source port 80 for traffic from the producer to the consumer. The assumption is that the consumer initiates the TCP connection to the producer (the consumer is the client and the producer is the server).

The default value for the revFltPrts attribute is false if it is not specified.

The match type attribute, provmatchT (for provider matching) and consmatchT (for consumer matching) determines how the subject labels are compared to determine if the subject applies for a given pair of consumers and producers. The following match type values are available:

• All

• AtLeastOne (default)

• None

• ExactlyOne

When deciding whether a subject applies to the traffic between a producer and consumer EPG, the match attribute determines how the subject labels that are defined (or not) in those EPGs should be compared to the labels in the subject. If the match attribute value is set to All, it only applies to the providers whose provider subject labels, vzProvSubjLbl, match all of the vzProvSubjLbl labels that are defined in the subject. If two labels are defined, both must also be in the provider. If a provider EPG has 10 labels, as long as all of the provider labels in the subject are present, a match is confirmed. A similar criteria is used for the consumers that use the vzConsSubjLbl. If the matchT attribute value is AtLeastOne, only one of the labels must match. If the matchT attribute is None, the match only occurs if none of the provider labels in the subject match the provider labels of the provider EPGs and similarly for the consumer.

If the producer or consumer EPGs do not have any subject labels and the subject does not have any labels, a match occurs for All, AtLeastOne, and None (if you do not use labels, the subject is used and the matchT attribute does not matter).

An optional attribute of the subject not shown in the example is prio where the priority of the traffic that matches the filter is specified. Possible values are gold, silver, bronze, or unspecified (default).

In the example, the subject element contains references to filter elements, subject label elements, and graph elements. <vzRsSubjFiltAtt tDn=“uni/tn-coke/flt-Http”/> is a reference to a previously defined filter. This element is identified by the vzRsSubjFiltAtt tag.

<vzRsSubjGraphAtt graphName=“G1” termNodeName=“TProv”/> defines a terminal connection.

<vzProvSubjLbl name=“openProv”/> defines a provider label named “openProv”. The label is used to qualify or filter which subjects get applied to which EPGs. This particular one is a provider label and the corresponding consumer label is identified by the tag vzConsSubjLbl. These labels are matched with the corresponding label of the provider or consumer EPG that is associated with the current contract. If a match occurs according to the matchT criteria described above, a particular subject applies to the EPG. If no match occurs, the subject is ignored.

Multiple provider and consumer subject labels can be added to a subject to allow more complicated matching criteria. In this example, there is just one label of each type on each subject. However, the labels on the first subject are different from the labels on the second subject, which allows these two subjects to be handled differently depending on the labels of the corresponding EPGs. The order of the elements within the subject element does not matter.

The Virtual Routing and Forwarding (VRF) (also known as a context or private network) is identified by the fvCtx tag and contains a name attribute.

A tenant can contain multiple VRFs. For this example, the tenant uses one VRF named “solartx1”. The name must be unique within the tenant.

The VRF defines a Layer 3 address domain. All of the endpoints within the Layer 3 domain must have unique IPv4 or IPv6 addresses, because it is possible to directly forward packets between these devices if the policy allows it.

Although a VRF defines a unique IP address space, the corresponding subnets are defined within bridge domains. Each bridge domain is then associated with the VRF.

The bridge domain element is identified with the fvBD tag and has a name attribute.

        <fvBD name="solarBD1">
            <fvRsCtx tnFvCtxName="solarctx1" />         
            <fvSubnet ip="11.22.22.20/24">
                <fvRsBDSubnetToProfile  
                     tnL3extOutName="rout1" 
                     tnRtctrlProfileName="profExport" />
            </fvSubnet>
            <fvSubnet ip="11.22.23.211/24">
                <fvRsBDSubnetToProfile  
                     tnL3extOutName="rout1" 
                     tnRtctrlProfileName="profExport"/>
            </fvSubnet>                  
        </fvBD>

Within the bridge domain element, subnets are defined and a reference is made to the corresponding Virtual Routing and Forwarding (VRF) instance (also known as a context or private network). Each bridge domain must be linked to a VRF and have at least one subnet.

This example uses one bridge domain named “solarBD1”. In this example, the “solarctx1” VRF is referenced by using the element tagged fvRsCtx and the tnFvCtxName attribute is given the value “solarctx1”. This name comes from the VRF defined above.

The subnets are contained within the bridge domain and a bridge domain can contain multiple subnets. This example defines two subnets. All of the addresses used within a bridge domain must fall into one of the address ranges that is defined by the subnets. However, the subnet can also be a supernet which is a very large subnet that includes many addresses that might never be used. Specifying one giant subnet that covers all current future addresses can simplify the bridge domain specification. However, different subnets must not overlap within a bridge domain or with subnets defined in other bridge domains that are associated with the same VRF. Subnets can overlap with other subnets that are associated with other VRFs.

The subnets described above are 11.22.22.xx/24 and 11.22.23.xx/24. However, the full 32 bits of the address is given even though the mask says that only 24 are used, because this IP attribute also identifies the full IP address for the router in that subnet. In the first case, the router IP address (default gateway) is 11.22.22.20 and for the second subnet, it is 11.22.23.211.

The entry 11.22.22.20/24 is equivalent to the following, but in compact form:

• Subnet: 11.22.22.00

• Subnet Mask: 255.255.255.0

• Default gateway: 11.22.22.20

The start of the application profile is indicated by the fvAp tag and has a name attribute.

<fvAp name="sap">

This example has one application network profile and it is named “sap.”

The application profile is a container that holds the EPGs. EPGs can communicate with other EPGs in the same application profile and with EPGs in other application profiles. The application profile is simply a convenient container that is used to hold multiple EPGs that are logically related to one another. They can be organized by the application they provide such as “sap,” by the function they provide such as “infrastructure,” by where they are in the structure of the data center such as “DMZ,” or whatever organizing principle the administrator chooses to use.

The primary object that the application profile contains is an endpoint group (EPG). In this example, the “sap” application profile contains 4 EPGs: web1, web2, app, and db.

EPGs begin with the tag fvAEPg and have a name attribute.

            <fvAEPg name="web1">
                <fvRsBd tnFvBDName="solarBD1" />
                <fvRsDomAtt tDn="uni/vmmp-VMware/dom-mininet" />
                <fvRsProv tnVzBrCPName="webCtrct" matchT ="All">
	             	     <vzProvSubjLbl name="openProv"/>                 
	  	                <vzProvSubjLbl name="secureProv"/>                
                    <vzProvLbl name="green"/>
                </fvRsProv>                    
            </fvAEPg> 

The EPG is the most important fundamental object in the policy model. It represents a collection of endpoints that are treated in the same fashion from a policy perspective. Rather than configure and manage those endpoints individually, they are placed within an EPG and are managed as a collection or group.

The EPG object is where labels are defined that govern what policies are applied and which other EPGs can communicate with this EPG. It also contains a reference to the bridge domain that the endpoints within the EPG are associated with as well as which virtual machine manager (VMM) domain they are associated with. VMM allows virtual machine mobility between two VM servers instantaneously with no application downtime.

The first EPG in the example is named “web1.” The fvRsBd element within the EPG defines which bridge domain that it is associated with. The bridge domain is identified by the value of the tnFxBDName attribute. This EPG is associated with the “solarBD1” bridge domain named in the “Bridge Domain” section above. The binding to the bridge domain is used by the system to understand what the default gateway address should be for the endpoints in this EPG. It does not imply that the endpoints are all in the same subnet or that they can only communicate through bridging. Whether an endpoint’s packets are bridged or routed is determined by whether the source endpoint sends the packet to its default gateway or the final destination desired. If it sends the packet to the default gateway, the packet is routed.

The VMM domain used by this EPG is identified by the fvRsDomAtt tag. This element references the VMM domain object defined elsewhere. The VMM domain object is identified by its tDn name attribute. This example shows only one VMM domain called “uni/vmmp-VMware/dom-mininet.”

The next element in the “web1” EPG defines which contract this EPG provides and is identified by the fvRsProv tag. If “web1” were to provide multiple contracts, there would be multiple fvRsProv elements. Similarly, if it were to consume one or more contracts, there would be fvRsCons elements as well.

The fvRsProv element has a required attribute that is the name of the contract that is being provided. “web1” is providing the contract “webCtrct” that was defined earlier that was called tDn=“uni/tn-coke/brc-webCtrct”.

The next attribute is the matchT attribute, which has the same semantics for matching provider or consumer labels as it did in the contract for subject labels (it can take on the values of All, AtLeastOne, or None). This criteria applies to the provider labels as they are compared to the corresponding consumer labels. A match of the labels implies that the consumer and provider can communicate if the contract between them allows it. In other words, the contract has to allow communication and the consumer and provider labels have to match using the match criteria specified at the provider.

The consumer has no corresponding match criteria. The match type used is always determined by the provider.

Inside the provider element, fvRsProv, an administrator needs to specify the labels that are to be used. There are two kinds of labels, provider labels and provider subject labels. The provider labels, vzProvLbl, are used to match consumer labels in other EPGs that use the matchT criteria described earlier. The provider subject labels, vzProvSubjLbl, are used to match the subject labels that are specified in the contract. The only attribute of the label is its name attribute.

In the “web1” EPG, two provider subject labels, openProv and secureProv, are specified to match with the “http” and “https” subjects of the “webCtrct” contract. One provider label, “green” is specified with a match criteria of All that will match with the same label in the “App” EPG.

The next EPG in the example, “web2,” is very similar to “web1” except that there is only one vzProvSubjLbl and the labels themselves are different.

The third EPG is one called “app” and it is defined as follows:

            <fvAEPg name="app">
                <fvRsBd tnFvBDName="solarBD1" />
                <fvRsDomAtt tDn="uni/vmmp-VMware/dom-mininet" />
                <fvRsCons tnVzBrCPName="webCtrct"> 
		                  <vzConsSubjLbl name="openCons"/>          
		                  <vzConsSubjLbl name="secureCons"/>      
                    <vzConsLbl name="green"/>
                 </fvRsCons>                        
            </fvAEPg>

The first part is nearly the same as the “web1” EPG. The major difference is that this EPG is a consumer of the “webCtrct” and has the corresponding consumer labels and consumer subject labels. The syntax is nearly the same except that “Prov” is replaced by “Cons” in the tags. There is no match attribute in the FvRsCons element because the match type for matching the provider with consumer labels is specified in the provider.

In the last EPG, “db” is very similar to the “app” EPG in that it is purely a consumer.

While in this example, the EPGs were either consumers or producers of a single contract, it is typical for an EPG to be at once a producer of multiple contracts and a consumer of multiple contracts.

        </fvAp>             
    </fvTenant>
</polUni>

The final few lines complete the policy.