cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
213
Views
5
Helpful
3
Replies
Highlighted
Beginner

vzAny-vzAny unexpected security behaviour?

Dear community,

 

I came across the contract priority section in the Design White Paper, which mentioned:

- vzAny-vzAny contract with default filter (from my understanding, basically all filters that have EtherType of unspecified, which includes common/default) has a priority of 21

- implicit deny also has a priority of 21 (which seems to be programmed for all VRF as well)

- Deny wins over permit/redirect

 

When I applied vzAny-vzAny Contract with default filter (and no other, more specific Subjects), I was expecting traffic between EPGs to still be blocked. However, quick ping test and web browsing all worked. Show zoning-rule still had both vzAny Contract and implicit deny programmed onto the Leaf, and of course VRF is enforced with no Preferred group.

 

Could anybody give me some insight whether this is an expected behaviour?

1 ACCEPTED SOLUTION

Accepted Solutions
Highlighted
Collaborator

Hi @Timothy ACI 

Interesting observation. I have tested in the lab same scenario, and indeed it seems that the vzAny-to-vzAny takes precedence over implicit deny. Let's take a look why:

View of the zoning rules table in my VRF:

Leaf101# show zoning-rule scope 3080196 
+---------+--------+--------+----------+---------+---------+---------+------+------------+----------------------+
| Rule ID | SrcEPG | DstEPG | FilterID |   Dir   |  operSt |  Scope  | Name |   Action   |       Priority       |
+---------+--------+--------+----------+---------+---------+---------+------+------------+----------------------+
|   4104  |   0    |   0    | implicit | uni-dir | enabled | 3080196 |      |  deny,log  |   any_any_any(21)    |
|   4105  |   0    |   0    | implarp  | uni-dir | enabled | 3080196 |      |   permit   |  any_any_filter(17)  |
|   4106  |   0    |   15   | implicit | uni-dir | enabled | 3080196 |      |  deny,log  | any_vrf_any_deny(22) |
|   4107  |   0    | 32770  | implicit | uni-dir | enabled | 3080196 |      |   permit   |   any_dest_any(16)   |
|   4112  |   0    |   0    | default  | uni-dir | enabled | 3080196 | TEST | log,permit |   any_any_any(21)    |
+---------+--------+--------+----------+---------+---------+---------+------+------------+----------------------+

As it ca be noticed, I only have the vzAny-to-vzAny TEST contract, with default filter applied. 

Looking at the priority columnof the zoning rules, both the implicit deny rule and my TEST rule are equal. So the next logical step is to look at the filters contained by the rules, and see which one has higher priority.

One important thing to highlight here, in the whitepaper it mentions:

Among filtering rules with the same priority, the following applies:
●   Within the same priority, deny wins over permit and redirect.

By this statement, my understanding is that if there are multiple FILTERS which the same priority, the listed rules applies.

But let's look at the "zoning rules" directly in hardware:

Leaf101# vsh_lc
module-1# show system internal aclqos zoning-rules
<snip>
===========================================
Rule ID: 4104 Scope 5 Src EPG: 0 Dst EPG: 0 Filter 65534

  Curr TCAM resource:
  =============================
    unit_id: 0
    === Region priority: 5512 (rule prio: 21 entry: 136)===
        sw_index = 46 | hw_index = 65

===========================================
Rule ID: 4112 Scope 5 Src EPG: 0 Dst EPG: 0 Filter 65535

  Curr TCAM resource:
  =============================
    unit_id: 0
    === Region priority: 5511 (rule prio: 21 entry: 135)===
        sw_index = 60 | hw_index = 63

Looking in hardware, we can see that the Rule ID 4104 (implicit deny) has the TCAM region priority 5512, while the Rule ID 4112 (vzAny) has the TCAM region priority 5511.  This is actually the hardware priority (rule priority + entry) in which the rules takes precedence (lower is better).

The priority is basically the composition of rule priority and hardware entry id (like in an acl):

5511 = 0001 0101 1000 0111 = 21 135

5512 = 0001 0101 1000 1000 = 21 136

Although we do not see from here what is the filter priority, we can confirm that indeed in hardware, the vzany-to-vzany default zoning rule will be checked first compared with the implicit deny.  I think the filter number 65534 - which is the implicit filter, might have a lower priority compared with filter number 65535 (default).

I will come later with further test to prove the theory.

Thanks,

Sergiu

 

View solution in original post

3 REPLIES 3
Highlighted
Collaborator

Hi @Timothy ACI 

Interesting observation. I have tested in the lab same scenario, and indeed it seems that the vzAny-to-vzAny takes precedence over implicit deny. Let's take a look why:

View of the zoning rules table in my VRF:

Leaf101# show zoning-rule scope 3080196 
+---------+--------+--------+----------+---------+---------+---------+------+------------+----------------------+
| Rule ID | SrcEPG | DstEPG | FilterID |   Dir   |  operSt |  Scope  | Name |   Action   |       Priority       |
+---------+--------+--------+----------+---------+---------+---------+------+------------+----------------------+
|   4104  |   0    |   0    | implicit | uni-dir | enabled | 3080196 |      |  deny,log  |   any_any_any(21)    |
|   4105  |   0    |   0    | implarp  | uni-dir | enabled | 3080196 |      |   permit   |  any_any_filter(17)  |
|   4106  |   0    |   15   | implicit | uni-dir | enabled | 3080196 |      |  deny,log  | any_vrf_any_deny(22) |
|   4107  |   0    | 32770  | implicit | uni-dir | enabled | 3080196 |      |   permit   |   any_dest_any(16)   |
|   4112  |   0    |   0    | default  | uni-dir | enabled | 3080196 | TEST | log,permit |   any_any_any(21)    |
+---------+--------+--------+----------+---------+---------+---------+------+------------+----------------------+

As it ca be noticed, I only have the vzAny-to-vzAny TEST contract, with default filter applied. 

Looking at the priority columnof the zoning rules, both the implicit deny rule and my TEST rule are equal. So the next logical step is to look at the filters contained by the rules, and see which one has higher priority.

One important thing to highlight here, in the whitepaper it mentions:

Among filtering rules with the same priority, the following applies:
●   Within the same priority, deny wins over permit and redirect.

By this statement, my understanding is that if there are multiple FILTERS which the same priority, the listed rules applies.

But let's look at the "zoning rules" directly in hardware:

Leaf101# vsh_lc
module-1# show system internal aclqos zoning-rules
<snip>
===========================================
Rule ID: 4104 Scope 5 Src EPG: 0 Dst EPG: 0 Filter 65534

  Curr TCAM resource:
  =============================
    unit_id: 0
    === Region priority: 5512 (rule prio: 21 entry: 136)===
        sw_index = 46 | hw_index = 65

===========================================
Rule ID: 4112 Scope 5 Src EPG: 0 Dst EPG: 0 Filter 65535

  Curr TCAM resource:
  =============================
    unit_id: 0
    === Region priority: 5511 (rule prio: 21 entry: 135)===
        sw_index = 60 | hw_index = 63

Looking in hardware, we can see that the Rule ID 4104 (implicit deny) has the TCAM region priority 5512, while the Rule ID 4112 (vzAny) has the TCAM region priority 5511.  This is actually the hardware priority (rule priority + entry) in which the rules takes precedence (lower is better).

The priority is basically the composition of rule priority and hardware entry id (like in an acl):

5511 = 0001 0101 1000 0111 = 21 135

5512 = 0001 0101 1000 1000 = 21 136

Although we do not see from here what is the filter priority, we can confirm that indeed in hardware, the vzany-to-vzany default zoning rule will be checked first compared with the implicit deny.  I think the filter number 65534 - which is the implicit filter, might have a lower priority compared with filter number 65535 (default).

I will come later with further test to prove the theory.

Thanks,

Sergiu

 

View solution in original post

Highlighted

Hi Sergiu @msdaniluk,

 

Thank you so much for your response. So actually according to your test, the implicit filter is different from the default filter and that is why vzAny-vzAny wins over the implicit deny in my case then (not to mention all the programming onto the hardware).

 

That makes sense.

Highlighted
Collaborator

Hi @Timothy ACI 

Yes, there is a difference between default and implicit filter:

Leaf101# show zoning-filter filter implicit
+----------+----------+-------------+-------------+-------------+-------------+----------+-------------+-------------+-------------+-------------+----------+-------------+-------------+----------+
| FilterId |   Name   |    EtherT   |    ArpOpc   |     Prot    | ApplyToFrag | Stateful |  SFromPort  |   SToPort   |  DFromPort  |   DToPort   |   Prio   |   Icmpv4T   |   Icmpv6T   | TcpRules |
+----------+----------+-------------+-------------+-------------+-------------+----------+-------------+-------------+-------------+-------------+----------+-------------+-------------+----------+
| implicit | implicit | unspecified | unspecified | unspecified |      no     |    no    | unspecified | unspecified | unspecified | unspecified | implicit | unspecified | unspecified |          |
+----------+----------+-------------+-------------+-------------+-------------+----------+-------------+-------------+-------------+-------------+----------+-------------+-------------+----------+
Leaf101# show zoning-filter filter default
+----------+------+-------------+-------------+-------------+-------------+----------+-------------+-------------+-------------+-------------+------+-------------+-------------+----------+
| FilterId | Name |    EtherT   |    ArpOpc   |     Prot    | ApplyToFrag | Stateful |  SFromPort  |   SToPort   |  DFromPort  |   DToPort   | Prio |   Icmpv4T   |   Icmpv6T   | TcpRules |
+----------+------+-------------+-------------+-------------+-------------+----------+-------------+-------------+-------------+-------------+------+-------------+-------------+----------+
| default  | any  | unspecified | unspecified | unspecified |      no     |    no    | unspecified | unspecified | unspecified | unspecified | def  | unspecified | unspecified |          |
+----------+------+-------------+-------------+-------------+-------------+----------+-------------+-------------+-------------+-------------+------+-------------+-------------+----------+

Cheers,

Sergiu