Unknown deny with ISE in SDA setup

[junk1]

Hi all, While rolling out traditional ISE policies to SDA policies in a customer network, we were hit by this issue:

The setup is: ISE running on 2.3 patch 5, DNAC on 1.2.6.

There are SXP tunnels from each PSN to each border per VN, to transmit the Static IP-SGT mappings for North South traffic from endpoints.

Assume setup is enabled as below:

• SGT:8, 9 – Endpoints connecting Edge switch
• SGT: 20, 21 – Static IP-SGT mappings outside fabric.
• SDA policies: 8 to 9 = Basic_icmp, 8 to 20 = Basic_AD, 8 to 21 = Basic_VDI are configured.

• In border, we could see policies 8 to 20, 8 to 21.
• In border, we could see 20, 21 – Static IP-SGT mappings
• In edge, there are no policies seen – 8 to 20, 8 to 21, even when an endpoint authorized with SGT:8 connects.
• In edge, there are no Static IP-SGT mappings seen.
• In edge, we could see policy 8 to 9.

Till now, things are working fine.

When we configure a policy SGT:8 to Unknown deny, edge switch gets that policy downloaded and denies all traffic even to SGT:20 and 21. In short, all North South traffic is denied. Can’t even ping default gateway from the endpoint. Somehow, the endpoint gets DHCP IP address, not sure how.

When we have SXP tunnels configured to edge switch also from ISE, edge switch gets 20, 21 – Static IP-SGT mappings, and relevant policies. Now, the SGT:8 to Unknown works as expected, while 8 to 20 & 8 to 21 works.

Forming SXP tunnels to each switch per VN per PSN is not going to scale at this customer place.

Please suggest an optimal way to enforce Unknown deny policy in SDA setup.

Thanks and Regards

V Vinodh.

[hslai]

Please start by reviewing the info at Segmentation Resources.

I believe "Unknown" has a special meaning so might be better done using the default egress rule or the final Catch-all rule.

[jeaves@cisco.com · Accepted solution]

Hi Vinodh,

discussed via email but posting here as well for completeness.

It has come to light that there is a difference in behaviour between the Cat4k and other SDA Fabric Edge switch types.

In your case, you are using a Cat4k Fabric Edge.

The Cat4k carries out a destination SGT lookup before routing to the VXLAN interface. When a deny policy to Unknown is used or a default deny then the Cat4k Edge will download those policies and enforce. As you have stated, any permit policies to other remote destinations will not be downloaded because the Edge will not be aware of any of those classifications.

For other Fabric Edge device types, the destination SGT lookup does NOT occur before routing to the VXLAN interface. So in those cases, there is never enforcement carried out for traffic routed out of the VXLAN interface.

So there is an order of operation difference.

A DDTS has been opened to fix this inconsistency and the SDA architects will need to decide on the best course of action:

CSCvn69167, Cat4k DGT Lookup Order of Operation with Whitelist Denies traffic in SDA.

The only work arounds that I can think of are to not use default deny or deny to an Unknown destination when using a Cat4k Edge, use a different Edge device type or manually configure 'no cts role-based enforcement' on the Cat4k VXLAN interface. The latter is not a recommended practice due to the fact that this is an SDA environment and orchestration should be carried out via Cisco DNA Center.