- Description
- Diagram
- Summary of Operation
- Configuration
- Verify Initial Communications
- Adding Policy
- Mechanism 1) Statically/manually added to the Border via CLI.
- Mechanism 2) Manually added to the IP:SGT mapping table in ISE and use SXP to send the mapping to the Border.
- Mechanism 3) Statically adding to any device (like DC access switch outside the fabric) and propagating to the Border via SXP.
Description
When the Cisco Digital Network Architecture Center (Cisco DNAC) provisions the SDA fabric, the Fabric Edge (FE) devices have enforcement enabled automatically ('cts role-based enforcement' and 'cts role-based enforcement vlan-list <vlans>').
However, enforcement is not enabled on the Border. Flows between the FE devices and devices outside the fabric which traverse the Border are not enforced by default.
Depending on the Border device type, the best place to enforce Fabric to non-Fabric flows may well be in the Fusion device. Device type, function, load, scale required etc. all need to be taken into account when deciding where best to enforce.
Enforcement on the Border is possible by using the configuration described below.
Diagram
Summary of Operation
The Building Access Control system is provisioned into the Campus VN called BuildingSecurity and has been assigned the Scalable Group Tag (SGT) of Bldg_Acc_Ctrl (SGT 23).
The aim is to deny the Building Access Control systems access to the Production Servers (one of which has an IP address of 10.1.140.2 which is in the company network outside the fabric). The Production Server will be placed into the Production_Servers scalable group (SGT 11). Restricting access to production servers from the likes of control systems is best practice to provide protection contingency in the event of control system compromise.
Configuration
Verify Initial Communications
Firstly, is there connectivity from the Building Access Control system to the server before we start?
For this to occur you may need to redistribute routes between routing protocols and leak routes between the BuildingSecurity VN/VRF and the Global Routing Table (GRT). This is manual configuration on the Fusion device.
Route Redistribution and Leaking are the topics of another discussion, but once in place, the Building Access Control system can initially ping the Server:
To enforce on the Border, the Border device needs to understand the destination group mapping for the production server. That IP:SGT mapping is 10.1.140.2:11. The source mapping for the Building Access Control system will be learned on the Border via packets received from the endpoint via VXLAN.
The destination mapping for the server can be learned on the Border by a number of mechanisms:
- Statically/manually added to the Border via CLI.
- Manually added to the IP:SGT mapping table in ISE and use SXP to send the mapping to the Border.
- Statically adding to any device (like DC access switch outside the fabric) and propagating to the Border via SXP.
We cannot use SSH from ISE to push the mapping because that ISE function is not VRF aware.
Adding Policy
Whichever method is best for the customer, a policy must be added to satisfy the security needs (deny traffic from Bldg_Acc_Ctrl SGT to Production_Servers SGT in this case).
This policy is added into Cisco DNA Center:
Once the policy has been added, it can be displayed within Cisco DNA Center:
When created, Cisco DNA Center pushes this policy into ISE. Navigate to Work Centers > TrustSec > TrustSec Policy > Egress Policy > Matrix in ISE to display the policy:
When the Border learns of a Scalable Group mapping, it will request policies from ISE that are protecting that group (the matrix column for that group). It will only do this however, if enforcement is enabled on the Border. Cisco DNA Center does not enable this enforcement so this needs to be added manually:
Kernow-ASR1kx#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Kernow-ASR1kx(config)#cts role-based enforcement
Note: In my case the Border is a router (ASR1kx) so enforcement is enabled globally using the above command. If your border is a switch then enforcement would also be needed on the VLAN using 'cts role-based enforcement vlan-list <vlan>'
Mechanism 1) Statically/manually added to the Border via CLI.
Add the server mapping statically on the Border using CLI (remember the mapping has to be provisioned into the VN/VRF):
Kernow-ASR1kx#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Kernow-ASR1kx(config)#cts role-based sgt-map vrf BuildingSecurity 10.1.140.2 sgt 11
Kernow-ASR1kx#show cts role-based sgt-map vrf BuildingSecurity all
%IPv6 protocol is not enabled in VRF BuildingSecurity
Active IPv4-SGT Bindings Information
IP Address SGT Source
============================================
10.1.140.2 11 CLI
10.3.16.5 2 INTERNAL
10.4.1.254 2 INTERNAL
IP-SGT Active Bindings Summary
============================================
Total number of CLI bindings = 1
Total number of INTERNAL bindings = 2
Total number of active bindings = 3
Once the mapping is known to the Border, it requests policy from ISE that is protecting that group:
Kernow-ASR1kx#show cts role permissions
IPv4 Role-based permissions default:
Permit IP-00
IPv4 Role-based permissions from group 23:Bldg_Acc_Ctrl to group 11:Production_Servers:
Deny IP-00
RBACL Monitor All for Dynamic Policies : FALSE
RBACL Monitor All for Configured Policies : FALSE
This results in the Building Access Control system to Production Server traffic successfully being enforced and denied:
Enforcement is happening on the Border device:
Mechanism 2) Manually added to the IP:SGT mapping table in ISE and use SXP to send the mapping to the Border.
Cisco DNA Center should have enabled SXP in ISE. You can check whether it is enabled via Administration > System > Deployment > (Hostname) >
Navigate to Work Centers > TrustSec > Settings > SXP Settings and enter a Global Password to be matched when adding the other end of the SXP connection on the Border device.
To just send specific mappings to the Border via SXP, create an SXP Domain in ISE. Navigate to Work Centers > TrustSec > SXP > SXP Devices and select 'Assign SXP Domain' at the top of the table:
Under the Assign page, there is a link to create a new Domain:
Click to 'Create New SXP Domain'.
In the following pop-up, enter a name for the domain (I have entered 'border-mappings') and click 'Create'
Before we add the SXP Device/Connection, the IP address of the Border has to be reachable from ISE and it has to be in the VN/VRF that the Building Access Control system has been provisioned into. In my case, that is VN BuildingSecurity.
There are two IP addresses which could be used on the Border within that VN. One is the IP on the interface towards the Fusion (can be seen to be 10.3.16.5 in the diagram) and the other is the Anycast IP that Cisco DNA Center provisions into the VN.
Either IP can be used as long as Route Leaking and Redistribution has been configured such that ISE can communicate with that IP.
I will use the Anycast IP address that Cisco DNA Center provisioned on the Border in the VN:
Kernow-ASR1kx#sh run int Lo1021
Building configuration...
Current configuration : 146 bytes
!
interface Loopback1021
description Loopback Border
vrf forwarding BuildingSecurity
ip address 10.4.1.254 255.255.255.255
dhcp-border-relay
end
Now, under Work Centers > TrustSec > SXP > SXP Devices, we can add a new Device/Connection to the Border using the newly created domain:
We now need to go to the Border and add SXP configuration there (remember to add it in the BuildingSecurity VN/VRF):
Kernow-ASR1kx#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Kernow-ASR1kx(config)#cts sxp enable
Kernow-ASR1kx(config)#cts sxp default password <password to match the global SXP password set in ISE>
Kernow-ASR1kx(config)#cts sxp connection peer 10.1.101.60 source 10.4.1.254 password default mode local listener vrf BuildingSecurity
Kernow-ASR1kx#show cts sxp connections vrf BuildingSecurity brief
SXP : Enabled
Highest Version Supported: 4
Default Password : Set
Default Source IP: Not Set
Connection retry open period: 120 secs
Reconcile period: 120 secs
Retry open timer is running
Peer-Sequence traverse limit for export: Not Set
Peer-Sequence traverse limit for import: Not Set
----------------------------------------------------------------------------------------------------------------------------------
Peer_IP Source_IP Conn Status Duration
----------------------------------------------------------------------------------------------------------------------------------
10.1.101.60 10.4.1.254 On 0:00:00:35 (dd:hr:mm:sec)
Total num of SXP Connections = 1
Navigating back to ISE Work Centers > TrustSec > SXP > SXP Devices, we can also see the connection is ON/up:
Now we can add a mapping in ISE for the Production Server and send it to the SXP domain:
Navigate to Work Centers > TrustSec > Components > IP SGT Static Mapping. We will add a static mapping for the production server and send it to the SXP Domain to be sent to the Border. In ISE, click the Add button and complete the details for the IP address (of the production server), SGT (of the production server) and send to the 'border-mappings' SXP Domain; then Save:
You should see that mapping in the SXP database in ISE if you navigate to Work Centers > TrustSec > SXP > All SXP Mappings:
As there is an active SXP connection from that ISE Domain to the Border BuidlingSecurity VN, we should see that mapping in the Border VN learned via SXP:
Kernow-ASR1kx#show cts role-based sgt-map vrf BuildingSecurity all
%IPv6 protocol is not enabled in VRF BuildingSecurity
Active IPv4-SGT Bindings Information
IP Address SGT Source
============================================
10.1.140.2 11 SXP
10.3.16.5 2 INTERNAL
10.4.1.254 2 INTERNAL
IP-SGT Active Bindings Summary
============================================
Total number of SXP bindings = 1
Total number of INTERNAL bindings = 2
Total number of active bindings = 3
Once the Border device learns of that group mapping, it requests policy from ISE protecting that group:
Kernow-ASR1kx#show cts role-based permissions
IPv4 Role-based permissions default:
Permit IP-00
IPv4 Role-based permissions from group 23:Bldg_Acc_Ctrl to group 11:Production_Servers:
Deny IP-00
RBACL Monitor All for Dynamic Policies : FALSE
RBACL Monitor All for Configured Policies : FALSE
The Building Access Control system traffic is now successfully enforced, it cannot contact the production server:
Enforcement is happening on the Border device:
Mechanism 3) Statically adding to any device (like DC access switch outside the fabric) and propagating to the Border via SXP.
This is a just a combination of the other mechanisms already discussed.
Short and concise. Only the details needed. Screen caps and sample configs add visuals, and clarify the text. Well done! 
My only improvement would be to add a 'Table of Contents', for easier navigation.
