This Post will describe how you can use the DNA Center Policy Matrix for traffic leaving the fabric. A typical example would be traffic to the Data Center.
I think everybody reading this post is familiar with micro segmentation controlled by the policy matrix in a SDA fabric. Purely at its nature the fabric controls traffic from an edge node to another edge node. Every communication leaving the fabric through the border node is not controlled by that. It is best practice to use a Firewall for that. Preferable a vendor who can work with Cisco's SGTs.
In recent projects i was requested to design topologies with only a firewall on the enterprise perimeter. Therefore it was not inline on the way to local resources. Another requirement was to use the legacy Data center Switches as the role as a fusion device. Especially in smaller environments this is pretty common.
With this requirements the need for an extra policy enforcement point raises. Why not reuse the Policy Matrix within the DNA Center for this? Most of my customer loves the idea heaving a single point of policy control throughout the whole network.
So let´s dig right into it:
First of all: you have to configure quite a lot. But the good news are it is a one time doing. And you can semi-automate this with the template editor!
The first thing to do is to configure the switch in a way that it knows the IP-SGT Mapping and the SGT-ACL derived from the policy matrix.
We can achieve this with SXP (SGT Exchange Protocol).
Which device you use for is up to you. It must be inline the traffic flow and support trustsec SXP. I like to enforcement point to be as close as possible to the source. So we don´t have to much travel time and bandwidth consumption until the packet is dropped anyway.
I personally like to leave the Border Node configuration nice and clean. Completely managed by the DNA Center. So my favorite device to place this is the fusion device. But the Border Node might just be perfect for your environment.
Before i show some command lines, i want to briefly describe the concept behind it.
In the moment a client successfully authenticate itself in the fabric, the Edge Node get some information from ISE it need to onboard the end device. This information include:
SGT
Virtual Network
Network type (data/voice)
IP Pool
---------------------------------------------------------------------------------------------------------------------------
At this point i want to mention, that you must only define the SGT in the authorization result. Not in the authorization rule!
At the current versions of the SDA components the switch will have two SGTs on the port and strange things start to happen.
---------------------------------------------------------------------------------------------------------------------------
After the authentication the client request an IP Address from the DHCP server.
This is the moment when die Edge Node can map the SGT from the ISE response and map it with the received IP Address. This combination is transferred via trustsec to the ISE.
The DNA Center synchronize the policies with the ISE
The new configured SXP Listener request all the SGT and the policies from the SXP Speaker. In this case the ISE.
Be aware that this is a simplified explanation. This approach is not an accurate illustration of how the protocols actually works!
So every time a new client access the network the fusion device will receive the IP-SGT mapping for it.
First of all we have to enable the SXP on the desired PSN(s)
Go to Work Centers -> TrustSec -> Components -> IP SGT Static Mapping
Because the Data center is in the most cases physically access restricted there is no need for 802.1x. But without NAC the IP to SGT Mapping information is missing. Therefore we have to configure the mapping manually.
You can ether configure 1:1 mapping with a /32 mask or declare a whole network with an SGT. This has to be done on the ISE.
after that go to:
Work Centers -> TrustSec -> Settings -> SXP Settings
Please check at the right box. With this mappings learned from the fabric will published to SXP. This check box is necessary if an inline tagging is not possible.
In a large environment this might be too much information sent to the enforcement device. If this is the case, please do not check any of the boxes. We will solve this later.
Under Work Centers -> TrustSec -> Settings -> SXP Devices
Because SXP is VRF aware a SXP connection for every Virtual Network is needed. I usually use a seperate Loopback interface for every VRF.
Make sure, that the IP Addresses of the Device are reachable in every VRF and, if you have a filter device in between, TCP port 64999 is allowed.
The listener role ist just fine for the fusion device. Configured like this the fusion device will only receive bindings but doesn't send any updates to the ISE.
I personally put the fusion device in the DNA Center inventory to have all the advantages that comes with it(automate the next step with the template editor for example :-) ). But if you didn´t do that, you must manually add the device in network devices within the ise.
For the configuration on the chosen enforcement device we need only a few lines. First enable SXP globally, set the default password we configured already on the ISE under the SXP settings und set up a connection for every Virtual Network we want to use.
cts sxp enable
cts sxp default password 7 2NFAWWPMDVUIOT5U
cts sxp connection peer <PSN IP> source <Loopback IP>
password default mode local listener hold-time 0 0 vrf DEAULT_VN
cts sxp connection peer <PSN IP> source <Loopback IP>
password default mode local listener hold-time 0 0 vrf ANOTHER_VN
now lets verify if the connection was established successfully.
show cts sxp connections vrf DEFAULT_VN
SXP : Enabled
Highest Version Supported: 4
Default Password : Set
Default Key-Chain: Not Set
Default Key-Chain Name: Not Applicable
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 : Off
Conn version : 4
Local mode : SXP Listener
Connection inst# : 4
TCP conn fd : -1
TCP conn password: default SXP password
Duration since last state change: 49:17:02:47 (dd:hr:mm:sec)
Total num of SXP Connections = 1do we receiving any mappings?
show cts sxp sgt-map
SXP Node ID(generated):0x0A4C09FE(10.76.9.254)
IP-SGT Mappings as follows:
IPv4,SGT: <8.8.8.8 , 23:Google>
source : SXP;
Peer IP : 192.168.159.5;
Ins Num : 3;
Status : Active;
Seq Num : 23
Peer Seq: C0A89F05,
IPv4,SGT: <192.168.149.16 , 22:Servers>
source : SXP;
Peer IP : 192.168.159.5;
Ins Num : 3;
Status : Active;
Seq Num : 21
Peer Seq: C0A89F05,
Total number of IP-SGT Mappings: 2Perfect!
Trustsec will now selectively download only SGT Access-List entries that include SGTs from the local database.
Lets check:
show cts role-based permissions
IPv4 Role-based permissions default:
Permit IP-00
IPv4 Role-based permissions from group 21:MarcoK to group 22:Servers:
Deny IP-00
IPv4 Role-based permissions from group 21:MarcoK to group 23:Google:
Permit IP-00
RBACL Monitor All for Dynamic Policies : FALSE
RBACL Monitor All for Configured Policies : FALSEEverything behave as expected.
As mentioned at the beginning we might have two steps. Pushing every authenticated IP with its SGT to the enforcement point might be too much information in a larger topology. But if you do not check "Add radius mappings into SXP IP SGT mapping table" only the static mappings gets pushed.
If you are using the Border Node for the enforcement point you only need SXP without the bindings of the NAC process. But if you have chosen the fusion device, per default, the SGT tagging gets lost between the Border Node and the fusion device.
Packets heading out of the fabric to the Data center will arrive at the Border Node encapsulated in a VXLAN tunnel. The SGT tag can be carried in the VXLAN header. But normal ethernet type 0x0800 or with Vlan Tag inserted ethernet type 0x8100 can´t carry this information. Therefor the source SGT gets lost leaving the Border Node. To counteract this behavior we need SGT inline tagging with Cisco Meta Data (CMD). Packets leaving an CMD activated link are now Ethernet Type 0x8909. Not every Device/Vendor supports this type and will drop the traffic because of unknown packet type. This is not a standard ethernet packet! Be aware of that.
One Caveat of the Solution with disabled distribution of radius mappings is, that the enforcement of traffic from the Data center back to the fabric, is regulated on the fabric Edge Node. This is because the Fusion Device only know the static configured SGT-IP Mappings outside the fabric. A Packet passing by will get its SGT based on that mapping. But at this point, the destination SGT is not known. The Packet continue down its path until the Edge Node act of default behavior.
To activate CMD we configure both interfaces facing each other on the Border and the Fusion:
cts manual
policy static sgt 14 trustedIf you are wondering what the purpose of the 14 is:
The device will tag self generated traffic with the SGT defined in the command. In this case 14.
Now we are done and can use the DNA Center policy matrix even for traffic leaving the fabric! I hope I could help you and gave some inspiration for you own Design. Let me know in the comments below, if you have further questions or want me to cover another topic.
Comments