Fabric-in-a-Box (FIAB) Operation with SXP

[jeaves@cisco.com]

Use-case: Endpoint in one VN needing group-based policy enforcement to an endpoint in another VN within a FIAB platform, e.g. Users permitted/denied to access IOT Devices

Condition1: Single platform FIAB

Condition2: Fusion not supporting Group-Based Policy Functions e.g. 3rd party platform and at the time of writing, the vEdge and cEdge

When traffic flows from a User in 'VN People' to a PLC in 'VN IOT', the source SGT classification (e.g. Admin SGT 18) is lost between the Border and Fusion.

That is due to no Group-Based Policy functions being supported on the Fusion in this example; any enforcement requirements need to be implemented on the fabric devices.

N.B. If the Fusion did support the inline tagging Group-Based Policy function (carrying the source SGT in the L2 frame), then that would be the recommended way to transport the source SGT to the destination VN.

In this example though, inline tagging is not supported on the Fusion so when traffic re-enters into the FIAB from the Fusion, it enters the VN IOT without a group classification. This is where the source IP (e.g. 10.6.5.100) needs to be re-classified back into the source group i.e. Admin SGT 18.

This re-classification can be added to the FIAB by utilizing templates in Cisco DNA Center to add IP:SGT or Subnet:SGT mappings. However, these mappings would be static in nature and although effective in certain circumstances, does not make use of the dynamic software-defined methods available.

Using SXP from ISE to the FIAB would allow dynamic re-classification:

Now, when Users authenticate onto the network, their assigned IP:SGT mappings will be sent by ISE to the IOT VN and will be available to re-classify traffic as it enters that VN via the Fusion.

Once re-classified, traffic then flows within the FIAB to the egress access port where enforcement will take place.

There is a 'gotcha' here though which I will explain.

When ISE assigns the SGT to the users, it places the IP:SGT mapping into the ISE SXP table and by default marks it as being sourced from the FIAB. It uses the FIAB SXP Node-ID for this marking. ISE also marks the mapping with its own SXP Node-ID.

This is a function of SXPv4 where loop detection and prevention is a function.

The following is a list of the current SXP versions with the supported functions:

•SXPv1 Propagates IPv4 address – SGT bindings

•Used in Nexus 1kv (prior to 5.2(1)SV3(2.1)), N5k and N7k (prior to 7.3)

•SXPv2 Propagates IPv4 & IPv6 address/group bindings, version negotiation

•Used in WLC and ASA (prior to 9.6.1), older IOS versions

•SXPv3 Added support for Subnet-SGT bindings and subnet expansion.

•If talking to v1 or v2 listener will expand subnet into host bindings

•Used in Nexus N7k NX-OS 7.3 and on ASA in 9.6.1

•SXPv4 Introduced bidirectional with loop detection and prevention, built in keepalive mechanism

•Used in routers, switches, N1kv in 5.2(1)SV3(3.1), N7k in 8.0

•Used in Wave1 and Wave2 AP’s in 8.4

•Used by Bayshore Networks, Open Daylight, Cisco ISE

Switch (FIAB) showing its Node-ID:

Kernow-Cat9300-b#show cts sxp sgt-map
SXP Node ID(generated):0x01010108(1.1.1.8)

ISE SXP table showing the SXP Node-ID's of the SXP Nodes 'traversed' (1.1.1.8 for the FIAB and 10.1.101.71 for ISE):

It is this SXP Node-ID path which causes the gotcha in this use-case. When ISE sends the mapping via SXP to the FIAB, the FIAB SXP process detects that its own SXP Node-ID is already in the mapping path and therefore drops the mapping as per the SXPv4 loop detection and prevention mechanisms.

N.B The SXP Node-ID is set platform-wide and cannot be set per VRF (as the CLI below shows). Enabling a Node-ID per VRF would be a suitable remedy but that enhancement has not yet been committed.

Kernow-Cat9300-b(config)#cts sxp node-id ipv4 1.1.1.8 ?
<cr>

Loop detection and prevention is enabled by default because the default SXP version set when adding an SXP device/connection in ISE is SXPv4.

A work-around for this is to set the ISE SXP device/connection to use SXPv3 instead:

The FIAB will negotiate the SXP version upon connection establishment, resulting in the highest version available being selected i.e. SXPv3.

The mapping will then show up in the IOT VN and will be used for re-classification:

N.B. SXPv3 does not support bidirectional SXP connections with loop detection and prevention and as such should not be used when SXP loops are possible. In this use-case example though, we are purely enabling SXPv3 on the connection from ISE to this FIAB VN.