cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
30311
Views
86
Helpful
15
Replies

ACI Contract

AirBorn
Level 1
Level 1

Hi,

Can someone tell me if my uderstanding regarding the 2 options Reverse Filter Ports and Apply Both Direction found in subject configuration is correct ?

 

A/ Reverse Filter Ports option: unchecked ; Apply Both Direction:checked

      - Return traffic from Provider to consumer is not permitted, unless a reverse filter is created manually

      - Access from Provider to consumer (new sessions) is not permitted, unless a reverse filter is created manually

 

B/ Apply Both Direction:Unchecked

       - Return traffic from Provider to consumer is not permitted, unless a reverse filter is created manually

       - Access from Provider to consumer (new sessions) is not permitted, even if a reverse filter is created manually. If this 
          behaviour is correct, what should be done to permet access (new session) from Provider to consumer? should we creat
          another contract in the opposite direction ?

 

Regards 

1 Accepted Solution

Accepted Solutions

RedNectar
VIP
VIP

Hi @AirBorn ,

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.
Forum Tips: 1. Paste images inline - don't attach. 2. Always mark helpful and correct answers, it helps others find what they need.

View solution in original post

15 Replies 15

Remi Astruc
Level 1
Level 1

Hi AirBorn,

Not really.

 

Example filter is Source port X, Destination port Y.

 

A/ Reverse Filter Ports option: unchecked ; Apply Both Direction:checked:

- Allows Consumer port X to Provider port Y

- Allows Provider port X to Consumer port Y

 

B/ Apply Both Direction:Unchecked:

- Allows Consumer port X to Provider port Y

 

In both cases, TCP return traffic is dropped.

 

You forgot the third variant, which may be of your interest to allow TCP bidirectional:

Reverse Filter Ports option: checked ; Apply Both Direction: checked:

- Allows Consumer port X to Provider port Y

- Allows Provider port Y to Consumer port X

 

Remi Astruc

RedNectar
VIP
VIP

Hi @AirBorn ,

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.
Forum Tips: 1. Paste images inline - don't attach. 2. Always mark helpful and correct answers, it helps others find what they need.

Hi Chris,

You mentioned in the second example that "No return traffic would get through, unless you added another contract to allow say SP=80 to pass", what about  adding, to the same contract,  a second filter to allow SP=80, will this permit return traffic ? 

 

Regards

It would but it would also waste TCAM because you would still have the entry programmed with destination port 80. 

Hi @AirBorn ,

@richmond is absolutely correct - adding a second filter to allow SP=80 to the same contract with the Apply Both Dircections checked but not the Reverse Filter Ports will permit return traffic and as my friend pointed out, take up an exxtra TCAM entry.

But it would also allow a complete TCP session on port 80 to be established in the opposite direction to which you probably intended (which is why I believe this option should not even be able to be selected).  I.e. allow a TCP session from a Web server to a User machine on port 80.  Now the user machine probably shouldn't be listening on port 80, and a server machine should probably not be trying to access port 80 on a user machine. But if all network traffic always did what was probably intended, we wouldn't need filters.

So best practice as far as simplicity of configuration goes is option #1 from my example. Best practice as far as conserving TCAM entries goes is option #3 from my example.  And since option #3 is not really that much harder, it is what I would suggest always.

As a side note, I have used option #2 for port 22 when two EPGs needed to be able to ssh to each other (along with the established contract for the vzAny EPG), but really I did this to prove to myself that it actually worked in the way I believed it did.  In doing so, I lost the flexibility to ever remove the traffic on one direction and didn't save any TCAM, so I would have been better off implementing the contract in both directions to make it more obvious to those that come after me the intention of the contract in terms of consumed and provided.

RedNectar aka Chris Welsh.
Forum Tips: 1. Paste images inline - don't attach. 2. Always mark helpful and correct answers, it helps others find what they need.

Hi RedNectar, I usually don't recommend the vzAny unidirectional contract workaround unless absolutely necessary. It's simpler just to use the option 1 solution. If you have generation 1 leaves then yes, option 3 might need to be used.

 

With EX and later leaves on 3.2+ you can forgo directional statistics and achieve the same kind of TCAM saving as you get from the vzAny trick. See Optimize Contract Performance at this link.

FX take it a step further with policy indirection which is also documented in the link above under the heading Policy Compression. This requires 4.0+ and is a relatively new feature so I would recommend testing it carefully.

 

@richmond - point taken. I guess I'm kind of stuck in first geration switch thinking mode.  So I'll concede to say that the best pracice if you don't have any first generation switches in the fabric is to use my original option #1 but with Policy Compression enabled if you wish to conserve TCAM - which shouldn't be such an issue on later model switches.

So here's a new diagram for my original Option #1 to conserve TCAM.

Contract-BothPlusPolCompr.png

Note that by enabling policy compression, contract statistics for both directions will be aggregated.

 

RedNectar aka Chris Welsh.
Forum Tips: 1. Paste images inline - don't attach. 2. Always mark helpful and correct answers, it helps others find what they need.

Slight correction on your slide, the option that removes bi directional stats and reduces TCAM like the vzAny config is referred to as Optimize Contract Performance and you configure it in the Subject by checking the “no-stats” box. This option is a bit misleading in the GUI. 

 

Policy Compression is on FX and later and you set it on the filter.

@richmond  - Thanks mate ...

...But:

  • There is no No-stats box - even though the guide DOES say "When configuring the contract subjects, enable the no stats directive."  Instead, the only options to set for directive are: None; Log; Enable Policy Compression

ContractSubj.png

  • When you set the Enable Policy Compression directive (as shown in the diagram), a  moquery -c actrlRule
     shows that the no_stats option is set. (See below)
# actrl.Rule
scopeId            : 2818053
sPcTag             : 32771
dPcTag             : 16386
fltId              : 257
action             : no_stats,permit
actrlCfgFailedBmp  :
actrlCfgFailedTs   : 00:00:00:00.000
actrlCfgState      : 0
childAction        :
ctrctName          : ChrisTest
descr              :
direction          : uni-dir-ignore
dn                 : topology/pod-1/node-102/sys/actrl/scope-2818053/rule-2818053-s-32771-d-16386-f-257
id                 : 4311
lcOwn              : implicit
markDscp           : unspecified
modTs              : 2019-05-18T11:34:59.354
monPolDn           : uni/tn-common/monepg-default
name               :
nameAlias          :
operSt             : enabled
operStQual         :
prio               : fully_qual
qosGrp             : unspecified
rn                 : rule-2818053-s-32771-d-16386-f-257
status             :
type               : tenant

Above examples are from ACI verison 4.01 - perhaps the No Stats option is from a previous version.

RedNectar aka Chris Welsh.
Forum Tips: 1. Paste images inline - don't attach. 2. Always mark helpful and correct answers, it helps others find what they need.

When policy compression is enabled, stats are not collected by default.

=== here is from the GUI === 

Some features will be unavailable while Policy Compression is active! 
- Statistics are disabled 
- Filters containing prio, qos and markDscp directives are not considered for compression

====

 

I'm working on a L3 Out contract

We want any Outbound traffic from ACI to be allowed, and obviously the return traffic.

However, our current contract: permit ip any/any apply both directions, reverse filter allows all inbound traffic from outside to ACI (this is not desired)

 

With the L3 Out being the provider
EPG being the consumer

would enabling the "stateful" flag on the any/any filter fix the Outside to ACI piece of the traffic flow so only any return traffic is permitted?

I think this question has been answered. If you have a new question, ask
a new question
RedNectar aka Chris Welsh.
Forum Tips: 1. Paste images inline - don't attach. 2. Always mark helpful and correct answers, it helps others find what they need.

Hello Guys! Good explanation @RedNectar . But i got a doubdt.

It is possible to configure the Subject (not in both directions) but under the CLI enable the reverse port-filter? It has any sence to do that?

Thanks!

Hi @ojleal007 ,

It is possible to configure the Subject (not in both directions) but under the CLI enable the reverse port-filter?

I'm sure the answer is "yes" - but for me to find out the actual CLI commands to do it I would first have to create a Contract/Subject and filters in the GUI, then look at the resulting CLI output (from a show run command)

So I suggest that's how you work out how to do it :)

As it happens, I happen to have one that some students did the other day. 

    access-list AppServices_Fltr
      match raw TCP5000 dFromPort 5000 dToPort 5000 etherT ip prot 6 stateful yes
      exit
    contract AppService_Ct
      subject AppService_subj
        access-group AppServices_Fltr both
        exit
      exit

I hope this helps

 

As for Q2:

 

YES it certainly does make sense to do the reverse-filter ports - if that's what you mean. Does it make sense to do it from CLI? Well, that's a personal choice.


 

RedNectar aka Chris Welsh.
Forum Tips: 1. Paste images inline - don't attach. 2. Always mark helpful and correct answers, it helps others find what they need.
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Save 25% on Day-2 Operations Add-On License