Issue with Assigning a Provided Contract to vzANY in Cisco ACI

[kekkophone]

Hello everyone,

I'm reaching out to the Cisco community for assistance with a problem I'm encountering regarding the assignment of a Provided Contract to vzANY in Cisco ACI. I've tried various solutions but so far haven't been able to resolve this issue.

I've carefully followed the Cisco ACI documentation and ensured that I'm correctly following the steps to assign the Contract, yet it seems the system isn't accepting it for vzANY.

Has anyone else faced a similar situation? Do you have any suggestions on what I could check or any potential workarounds I could try?

APIC Version: 4.2(7f)

I greatly appreciate any input or suggestions from you all.

Thank you in advance for your help!

Best regards,

[RedNectar]

Hi @kekkophone ,

Why do you want vzAny to PROVIDE a contract? The only time this makes sense is if vzAny is consuming the SAME contract, such as a contract for EstablishedTCP traffc (an old kludge used to reduce TCAM usage on 1st generation switches)

Having vzAny PROVIDE a contract is saying that you expect every EPG linked to that VRF to be providing the SAME service. A VERY unusual situation.

Since I see the common tenant in your diagram, I suspect you have an EPG in the common tenant that you want to provide a service.  If that is the case, let the EPG provide it as normal, keep right away from vzAny in the common tenant, and then have vzAny consume that contract in any tenant/VRF that you want.

Apart from that, a little more information about what you are trying to do, and a reference to the documentation you have been following would be nice.

And one last tip:

When you add pictures,  if it is a screenshot, you'll probably then want to click on the image and make the image large - like this.

You can also re-size the object by clicking and draging the corners

[kekkophone]

Hi RedNectar,

My need to associate a contract with vzANY provider arises from the need to implement a new infrastructure rule where everyone must be able to be contacted by an EPG on specific ports.

I realize that it may be an unusual type of traffic but in fact I prefer to use a vzANY rather than associate the same contract with each existing and subsequent EPG within my TENANT.

I am inside the Tenant common because that is where my reference VRF resides.

The documentation on entering vzANY type contracts can be found in the following link: vzAny Contracts 

In the meantime, using another user, I noticed that I can associate the contract correctly and therefore I would like to understand why I have the problem on my user (both accounts have the same privileges).

Thank you for the support you are providing me.

[RedNectar]

Hi @kekkophone ,

My need to associate a contract with vzANY provider arises from the need to implement a new infrastructure rule where everyone must be able to be contacted by an EPG on specific ports.

I'll lock that one away as a use case for using vzAny as a provider!

But, it will only work for the VRF where the EPGs that need to be contacted are. So, IF you have implemented it so that 

• The contract is PROVIDED by vzAny in EVERY VRF in EVERY Tenant (i.e. provided multiple times, once per VRF)
• and the contract is CONSUMED by an EPG in the common tenant (the one referred to by "everyone must be able to be contacted by an EPG", then it should work - although I have not built this to test.

It will be easiest if you create the Filters and Contract in the common tenant, which I guess you have already done.

If this is indeed what you have implemented and are still having a problem, I'll try and build it when I get a chance (which is unlikely before next Wednesday)

---

BTW - did you know this about the common tenant?

Let's say you have a contract called XYZ_Ct in the common tenant, and you use that contract within your tenant  (which is quite an efficient way of having consistency of contracts across all tenants)

Now, if you create a new contract WITHIN YOUR TENANT called XYZ_Ct - and I mean simply create the contract - no need to apply it anywhere

Then the contract created in your tenant will be the one used by your tenant - NOT the XYZ_Ct in the common tenant.

What this actually illustrates is how the common tenant actually acts as a "catch all" for things in your tenant - if you don't define a policy or contract or filter in your own tenant, by default your tenant will use the one in the common tenant - typically with the name default - but it also applies to all other names as well!

[kekkophone]

Hi @RedNectar 

I'll explain everything briefly to you. in tenant common I have different VRFs depending on the traffic. In this case, I have to apply to my production traffic (which I will call VRF-PROD) I will have to apply an infrastructure contract for Domain Joins therefore, I created an AD-Ports filter and I created a contract which therefore allows all the EPGs of the VRF-PROD to be contacted by Domain Controllers residing in a specific EPG. So, as I said, my contract will be with Consumed EPG-DomainController and Provider vzANY.

The Contract, as well as the filters, were all created in the Tenant Common otherwise I would not have had the opportunity to hook the contract to the VRF-PROD.

My problem, however, is not inherent to the functionality of the contract because I am sure that it works, but rather to the impossibility of associating any contract as a Provider within the VRF-PROD EPG because the new line appears completely white and without input form ( as can be seen in the photo I attached in the initial thread).

[RedNectar]

Hi @kekkophone ,

OK. I think you have found this limitation of vzAny, as described in this document entitled Use vzAny to Automatically Apply Communication Rules to all EPGs in a VRF. You'll find something similar in the multisite guide for vzAny

---

vzAny Guidelines and Limitations

Observe the following guidelines when using vzAny:

• All EPGs in a VRF can take the role of a provider, a consumer, or both depending on the configuration.

• In addition to application profile EPGs, vzAny providers and consumers include external EPGs such as l2extOut and l3extOut, and endpoint groups for out-of-band (mgmtOoB) or in-band (mgmtInB) access.

• vzAny is supported as a consumer of a shared service but is not supported as a provider of a shared service.

• vzAny implicitly permits all subnets. When vzAny is in use for a VRF, it also includes the L3out, hence it is equivalent to having created a L3external classification that includes the subnets specified in the VRF itself.

• If an EPG, within a VRF, is consuming a shared service contract from an EPG of a different VRF (that we call provider VRF), the traffic from the EPG of the provider VRF is filtered within the consumer VRF. vzAny is equivalent to a wildcard for the source or destination EPG. Be careful when you configure a contract with a vzAny in the consumer VRF because the vzAny contracts may also apply to the traffic between the EPG of the provider VRF and the EPG of the consumer VRF.

---

In other words, ACI does not support what you are trying to do.

However, from my very, VERY poor understanding of AD, I would have thought that the AD servers would be contacting the Domain Controllers residing in a specific EPG (as you would if you are using the Domain Controllers as Domain Name Servers), rather than Domain Controllers residing in a specific EPG contacting every AD server. 

In which case the specific Domain Controllers EPG would need to PROVIDE the contract, and vzAny CONSUME the contract, just like you would for any Domain Name Service.

But, as I said, AD is not my thing and I really have no idea if my hunch is right or not.  But I can tell you my method is definitely the correct way to implement DNS.

[kekkophone]

Hi @RedNectar ,

Yes, for AD communication there is a need for both the contract where all the EPGs contact the Domain Controllers and for the Domain Controllers to contact all the EPGs therefore I had to create two different contracts and correctly associate the Consumer and Provider.

The strange thing, in fact, is that from my user it was not possible to associate the contract with vzAny but from another user I was able to carry out the operation without problems.

[RedNectar]

Hi @kekkophone ,

Looks like you've got it sorted.  But your problem got me thinking. [Over several days clearly - since this reply is so late]

I've long told people that when creating contracts, you should ALWAYS leave both the [x] Apply Both Directions, and [x] Reverse Filter Ports options checked, unless you are trying to conserve TCAM on first generation switches in which case you leave both unchecked and have a separate contract for Established traffic.  And I have emphasised that having just the [x] Apply Both Directions option checked and the [  ] Reverse Filter Ports option unchecked made no sense at all.

BUT, perhaps the Active Directory use case you describe is the exception that legitimises the ability to even configure the [x] Apply Both Directions option checked and the [  ] Reverse Filter Ports option unchecked.  But to make this work, TWO entries will be required for every  TCP/UDP port required, one where the permitted port is the Destination port, and one where the permitted port is the Source port so return traffic can also flow.

Here's what I created in a lab that seems to work, although I don't have any AD servers available to me to test.

Step #1 - Create filters for the ports used by AD

I used this website's list of ports required for AD. I assume it is correct. And then created a filter in the common tenant with all those ports, with those two entries for every  TCP/UDP port (so return traffic can also flow).

I called the filter AD.BiDirPorts_Fltr, and I used the CLI to create it (something I tell people to NEVER do - this question is really making me break my own rules). Soooo much clicking in the GUI to do this!

apic1# configure
apic1(config)# tenant common
apic1(config-tenant)# access-list AD.BiDirPorts_Fltr
apic1(config-tenant-acl)# match tcp dest 53
apic1(config-tenant-acl)# match tcp src 53
apic1(config-tenant-acl)# match udp dest 53
apic1(config-tenant-acl)# match udp src 53
apic1(config-tenant-acl)# match tcp dest 88
apic1(config-tenant-acl)# match tcp src 88
apic1(config-tenant-acl)# match udp dest 88
apic1(config-tenant-acl)# match udp src 88
apic1(config-tenant-acl)# match tcp dest 135
apic1(config-tenant-acl)# match tcp src 135
apic1(config-tenant-acl)# match udp dest 135
apic1(config-tenant-acl)# match udp src 135
apic1(config-tenant-acl)# match tcp dest 137-138
apic1(config-tenant-acl)# match tcp src 137-138
apic1(config-tenant-acl)# match udp dest 137-138
apic1(config-tenant-acl)# match udp src 137-138
apic1(config-tenant-acl)# match tcp dest 389
apic1(config-tenant-acl)# match tcp src 389
apic1(config-tenant-acl)# match udp dest 389
apic1(config-tenant-acl)# match udp src 389
apic1(config-tenant-acl)# match tcp dest 445
apic1(config-tenant-acl)# match tcp src 445
apic1(config-tenant-acl)# match udp dest 445
apic1(config-tenant-acl)# match udp src 445
apic1(config-tenant-acl)# match tcp dest 464
apic1(config-tenant-acl)# match tcp src 46
apic1(config-tenant-acl)# match udp dest 464
apic1(config-tenant-acl)# match udp src 464
apic1(config-tenant-acl)# match tcp dest 636
apic1(config-tenant-acl)# match tcp src 636
apic1(config-tenant-acl)# match udp dest 636
apic1(config-tenant-acl)# match udp src 636
apic1(config-tenant-acl)# match tcp dest 3268-3269
apic1(config-tenant-acl)# match tcp src 3268-3269
apic1(config-tenant-acl)# match tcp dest 80
apic1(config-tenant-acl)# match tcp src 80
apic1(config-tenant-acl)# match tcp dest 443
apic1(config-tenant-acl)# match tcp src 443
apic1(config-tenant-acl)# match tcp dest 49443
apic1(config-tenant-acl)# match tcp src 49443
apic1(config-tenant-acl)# end

Step #2 - Create an AD Contract in the common tenant

I called the contract AD_Ct. Note that the contract needs the Scope set to Global if the consumer EPGs are to be in a regular tenant.

When adding the subject to this contract I made sure the [  ] Reverse Filter Ports option was unchecked and added the  AD.BiDirPorts_Fltr

Step #3 - Configure the contract provider in the common tenant

Presuming that the EPG where the Domain Controllers live is also in the common tenant, there are three things that have to be done with the DomainControllers_EPG

1. Have the EPG provide the AD_Ct contract
2. Have a subnet assigned to that EPG that encompasses all Domain Controller IPs
3. Mark that subnet as [x] Shared Between VRFs
   • Note: If the subnet is ALSO defined on the associated BD, then this option will ALSO have to be configured on the BD subnet FIRST

Step #4 - Configure the consumers (vzAny) in each VRF/Tenant

Presuming that the VRFs that need to interact with the DomainControllers_EPG are in different tenants, there are a couple of things you'll have to configure in each tenant.

1. For every VRF that has servers that need to interact with the DomainControllers_EPG 
   • Have the vzAny object consume the AD_Ct
2. For every subnet where servers that need to interact with the DomainControllers_EPG exist
   • Configure the subnet (under the BD or EPG) to enable the [x] Shared Between VRFs option.

---

Validation

I built my lab like this

As I said, I don't have AD servers, but I do have a DNS server, and I ran netcat on the DNS server to listen on port 389 as a test, and on port 88 (and 389) on the AppServerBM, and the WebServerBM was already listening on port 80.

From the AppServerBM, I could hit port 389 on the DNS - and the name dns  was also resolved (testing UDP port 53)

Same story from the WebServerBM

And from the DNS itself, a test on some ports in the reverse direction (simulating Domain Controller contacting AD Server). I used a different message here and a simpler command - on the AppServerBM I ran 
echo "Welcome to port 88, normally Kerberos authentication" | sudo nc -l 88 and later
echo "Welcome to port 389, normally LDAP" | sudo nc -l 389

And finally, from the DNS, a test of the webserver.

---

Conclusion

I was able to create a contract that worked for the purpose of allowing AD communication initiated either by an AD server or a Domain Controller

The contract subject was configured with the Apply Both Directions option set, but without the Reverse Filter Ports option.  Essentially, I manually created the reverse filter ports by configuring a filter that included the target port numbers in two filters each (one as Source Port, one as Destination Port) per protocol (TCP and UDP).

Although not an exhaustive testing, I think the model above will do what you want. If you actually test it out, please let us know on the forum how it went.  If I get some positive responses, I'll write this up as a blog post.

[kekkophone]

Hi @RedNectar ,

Forgive the wait but I was very busy in this period.
In any case, my problem was not related to the creation of the contract, but the impossibility of associating it with vzAny because it is impossible by GUI. In any case, I solved my problem using another user.

As for your analysis and, disabling the item Reverse Filter Port, you will only prevent the provider (in this case the clients under Vzany) from being able to respond to the consumer through the contract created by you thus preventing the correct join to the domain.

The solution you can take is double:

• Create a contract inverting consumer and provider by applying the necessary filters that uses the Domain Controller to respond to clients;
• Enable the Reverse Filter Port within the only contract;

In this case the choice is very personal.
I hope I was also helpful as you have been in your explanations

[RedNectar]

Hi @kekkophone ,

Thanks for your response. And your solution will work. My last answer was a little experiment that should also work - I just haven't had a chance to test it in a real-world scenario.  But from you comments, I think you missed some of the key features of my solution, in particular:

disabling the item Reverse Filter Port, you will only prevent the provider (in this case the clients under Vzany) from being able to respond to the consumer through the contract created by you thus preventing the correct join to the domain.

I don't believe this would be the case if you use the filter I provided, which essentially has two entries for every port-number. One where the port is a destination TCP port (for the TCP SYN) and one where the port is a source TCP port (for the TCP SYN/ACK) - thereby simulating the action of the [x] Reverse Filter Ports option and removing the need to apply the contract in the reverse direction, which I believe was the crux of your problem because you can't make vzAny the provider of a shared service.

However, since you've found another work-around for the problem, WELL DONE.

[kekkophone]

Hi @RedNectar ,

Forgive if I have misinterpreted your previous message.

Analyzing it better I confirm that your scenario can make much sense and could also give the desired results without having to create a double contract. Unfortunately such an action would not like to apply it in production for an infrastructure rule but I could carry out this test in production on contracts that require a bidirectional connection.

As for the hazel of the speech, since it is a rule compulsory infrastructure for each VM created within the datacenter, I prefer to use the Vzany otherwise I would be forced to insert the domain join contract each time