cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
4993
Views
25
Helpful
7
Replies

ACI Contract Confusion

Could someone explain what seems to be a paradox in this document to me:

https://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/1-x/Operating_ACI/guide/b_Cisco_Operating_ACI/b_Cisco_Operating_ACI_chapter_01000.html

 

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.

 

But the example in figure 4 seems to dispute that...what am I missing?

Figure 4. Default Bi-directional Contract with Reverse Filter

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. The Web server in EPG-1 will not have access to port 80 of the Web client in EPG-2.

 

1 ACCEPTED SOLUTION

Accepted Solutions
RedNectar
Advocate

Hi @joseph1.blanchard ,

There may be a couple of points my previous answer does not cover, so let me make sure no gaps are left

Could someone explain what seems to be a paradox in this document to me:

https://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/1-x/Operating_ACI/guide/b_Cisco_Operating_ACI/b_Cisco_Operating_ACI_chapter_01000.html

 

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.

This is indeed true, but let me make two points:

  1. If the PROVIDER initiates the communication, the provider must use a SOURCE PORT of 8888 in your example, and a destination port in the range of whatever the source port range is in the filter (usually any).  So unless the PROVIDER is sending a TCP SYN to an open port AND has crafted the TCP SYN to use source port 8888, it won't get through
  2. If the Stateful flag is set on the filter, then ALL traffic from the PROVIDER to the CONSUMER MUST have the ACK flage set, thus negating the possibility of #1 above.
The provider could open up a TCP socket to the consumer using port 8888, whether the provider or consumer sent traffic first.

NO, it couldn't - as per #1 above

But the example in figure 4 seems to dispute that...what am I missing?

Figure 4. Default Bi-directional Contract with Reverse Filter

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. The Web server in EPG-1 will not have access to port 80 of the Web client in EPG-2.

I'm not going to try and interpret Cisco's document. My previous answer does a much better job of explaining the concepts.

[Edit: Cisco's document - at least the bit quoted above is ABSOLUTELY WRONG. I've informed the documentation team via the Feedback option on the page.  If it is STILL wrong when you read this, please give more feedback. 2021.01.19]

RedNectar
aka Chris Welsh


Don't forget to mark answers as correct if it solves your problem. This helps others find the correct answer if they search for the same problem

View solution in original post

7 REPLIES 7
RedNectar
Advocate

Hi @joseph1.blanchard ,

Here is a direct cut-and-paste from another answer I gave - I think it might clear up the confusion.

RedNectar
aka Chris Welsh


Don't forget to mark answers as correct if it solves your problem. This helps others find the correct answer if they search for the same problem.


Great question - and touches on a topic that you really need to understand to get the best out of TCAM resources.

Let's start with an example. Assume you have an EPG called Web providing a contract called HTTP being consumed by EPG User.  The HTTP contract is built on a filter specifying Destination Port=80 - no specify source port.

The most straightforward way to apply this contract is with both the Apply Both Directions and Reversse Filter Ports options checked, as shown below:

Contract-Both-Reverse.png

The way the contract works is that the chosen filter is applied to traffic coming from the Consumer to the Provider, so traffic with a DP=80 is permitted.  By checking the Apply Both Directions, the filter is also used for traffic travelling from the Provider to the Consumer, but because the Reverse Filter Ports option is checked, the contract will be allowing traffic with a SP=80 rather than DP=80.

By in large, this is what you want a contract to do - permit forward traffic from the Consumer to the Provider and return traffic in the opposite direction.

Now let's play with those options.  Assume you remove the Reverse Filter Ports option.  Now the contract is still applied in both directions, but with DP=80 in each direction - essentially removing the whole idea of Consumer and Provider as only traffic with DP=80 would be allowed. No return traffic would get through, unless you added another contract to allow say SP=80 to pass.

Contract-BothOnly.png

What you end up is with a pretty useless contract, and in my opinion, one that shouldn't even be supported in the GUI configuration.

However, the last possible variation (you clearly can't  Reverse Filter Ports if you don't Apply in Both Directions) is to only apply in one direction.  This option only uses a single TCAM entry rather than two as shown in the above examples.

Contract-Neither.png

Again, like the previous example, you will need a different contract and filter to allow the return traffic with SP=80, but there is more clever way of doing this using a special EPG* called vzAny.

vzAny represents the collection of EPGs that belong to the same VRF.  Instead of associating contracts to each individual EPG, you can configure a contract to the vzAny EPG which is found under your VRF configuration's EPG Collection for VRF. (Tenant > tenant > Networking > VRF > vrf > EPG Collection for VRF)

The idea is, you create a contract that allows all TCP traffic with the ACK flag set - there is a pre-defined filter for that you can use defined in the common tenant called est.  You then make the vzAny EPG both a Consumer and a Provider of this contract which then allows every EPG in that VRF to accept traffic with the ACK flag set but uses only a single TCAM entry for all EPGs. 

In the following diagram, the HTTP and SQL contracts allow traffic from the consuming EPGs to reach the providing EPGs, while the Established contract allows universal traffic between EPGs so long as the TCP session is established.  Essentially, the HTTP and SQL contracts are only needed to allow the initial TCP SYN packet through to establish the session. all other traffic is handled by the vzAny EPG and its Established contract.

Contract-vzAny.png

I hope this helps


Don't forget to mark answers as correct if it solves your problem. This helps others find the correct answer if they search for the same problem


* I've been taken to task be a colleague for calling vzAny an EPG. Strictly speaking he's correct of course. It is in fact a special child object of a VRF that can consume and provide contracts just like an EPG. So in the context of providing and consuming contracts, it makes it much easier to undersand by calling it an EPG.

RedNectar
aka Chris Welsh


Don't forget to mark answers as correct if it solves your problem. This helps others find the correct answer if they search for the same problem

RedNectar
Advocate

Hi @joseph1.blanchard ,

There may be a couple of points my previous answer does not cover, so let me make sure no gaps are left

Could someone explain what seems to be a paradox in this document to me:

https://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/1-x/Operating_ACI/guide/b_Cisco_Operating_ACI/b_Cisco_Operating_ACI_chapter_01000.html

 

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.

This is indeed true, but let me make two points:

  1. If the PROVIDER initiates the communication, the provider must use a SOURCE PORT of 8888 in your example, and a destination port in the range of whatever the source port range is in the filter (usually any).  So unless the PROVIDER is sending a TCP SYN to an open port AND has crafted the TCP SYN to use source port 8888, it won't get through
  2. If the Stateful flag is set on the filter, then ALL traffic from the PROVIDER to the CONSUMER MUST have the ACK flage set, thus negating the possibility of #1 above.
The provider could open up a TCP socket to the consumer using port 8888, whether the provider or consumer sent traffic first.

NO, it couldn't - as per #1 above

But the example in figure 4 seems to dispute that...what am I missing?

Figure 4. Default Bi-directional Contract with Reverse Filter

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. The Web server in EPG-1 will not have access to port 80 of the Web client in EPG-2.

I'm not going to try and interpret Cisco's document. My previous answer does a much better job of explaining the concepts.

[Edit: Cisco's document - at least the bit quoted above is ABSOLUTELY WRONG. I've informed the documentation team via the Feedback option on the page.  If it is STILL wrong when you read this, please give more feedback. 2021.01.19]

RedNectar
aka Chris Welsh


Don't forget to mark answers as correct if it solves your problem. This helps others find the correct answer if they search for the same problem

View solution in original post

Thank you, this is what I was missing. 

1. Thanks for the very helpful response and diagrams. They helped me visualize what is happening.

2. Today [2021.09.03] the section copied above appears to have been fixed and now reads:


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 named as "www" that has a filter for TCP traffic with source port any and destination port 80 (HTTP) along with the Apply Both Direction and Reverse Filter Port options. This allows the Web client in EPG-2 to start an HTTP session with port 80 on the Web server in EPG-1. That is, EPG-1 is providing a service to EPG-2. However, this also allows EPG-1 to initiate TCP sessions from port 80 to any ports on EPG-2, which is typically not the intent of the configuration. By enabling the Stateful option in the same filter, only the traffic with the TCP 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 an SYN + ACK attack from the provider, unlike a stateful firewall.

RedNectar
Advocate

@joseph1.blanchard ,

I've had a bit more of a look at the CRAP Cisco document you referred to. THAT STATEMENT YOU QUOTED IS 100% WRONG - and a disgrace to Cisco documentation team. I've accessed the document and clicked the feedback button to let Cisco know - you might be well advised to do the same.

 

RedNectar
aka Chris Welsh


Don't forget to mark answers as correct if it solves your problem. This helps others find the correct answer if they search for the same problem

Yes, I've provided similar feedback...FYI: This information is pretty much copy/pasted into the Official Cert Guide too. 

The Cert Guide is worse... but let's not go there - also have posted about that on the CCSI forum

RedNectar
aka Chris Welsh


Don't forget to mark answers as correct if it solves your problem. This helps others find the correct answer if they search for the same problem