SXP between C9300 and C2960X

[p11l]

Hello everyone,

We would like to use our “old” C2960X devices, which we have in large numbers, to connect simple devices such as printers or PCs that do not require PoE.

The goal is to use SGT for these devices. I have already read that it is not possible to use the full range of functions for working with SGT with a C2960X. However, it is listed with Note 3: “Tier III  does not have a full group base.” Policy functionality and support for classification and SXP-based propagation only.

So my question is how can I achieve this in an already usable SDA deployment? I drew a little picture.

The only SXP connection already used there is between DNA and ISE. Is it right? So I think I need to configure SXP between 2960X and 9300 in Edge mode. But how do I achieve this? Is it necessary to configure a trunk connection between these two devices or should it be a routed connection? All SDA devices connected in the underlay use IS-IS, the 2960X is not suitable for this.

I hope someone can help clarify this.

Thank you

[andy!doesnt!like!uucp]

Hi
1. The only SXP connection already used there is between DNA and ISE. Is it right? 
Not exactly. this integration is REST&pxGrid only.
2.  Is it necessary to configure a trunk connection between these two devices (2960X and 9300 in Edge mode) or should it be a routed connection?
If it could be routed connection (coz technically u can reuse arbitrary EN's underlay to integrate another EN to the fabric) that another EN (2960X in your case) should support LISP&VXLAN :0) Thus u stay with trunk here.
3. Now about SXP. Basically there would be couple of options for u:
3.1. create SXP sessions between EN & downstream 2960X(s). i'd predict it to be quite scalable with regard to number of SXP-sessions u need to have.
3.2. use ISE to propagate SGTs by SXP to 2960Xs but pay attention to scalability (https://www.cisco.com/c/en/us/td/docs/security/ise/performance_and_scalability/b_ise_perf_and_scale.html#Cisco_Reference.dita_0dea43a2-2e42-43fa-99c3-65beb4fc95c3:~:text=Table%2010.%20SXP%20Scaling%20for%20Different%20Deployments)
3.3. Use intermediate SXP speaker to grab SGT-mapping from ISE with single session & propagate it to your 296Xs (https://www.cisco.com/c/dam/en/us/solutions/collateral/enterprise-networks/trustsec/policy-platform-capability-matrix.pdf)

& yeah... SXP configuration on the 2960 (& ENs if u choose 3.1) u will do manually/via network templates

Hopefully this'll help

[p11l]

Thanks for your answer!

So the C9300 (Edge) and the entire fabric are is-is routed.

When I add the C2960X you said to use a trunk connection. Now I need to create a VLAN interface on C9300 and C2960x so that the two devices can be configured for SXP peer connection?

Is it necessary for the C2960x to be accessible across the entire fabric, or is it sufficient to only be accessible via the directly connected neighbor (C9300)?

Can I use the management interface to achieve peer connectivity - without create any vlan interface for underlay?

[andy!doesnt!like!uucp]

SXP session requires IP-addresses on the both side of connection. u may use SVI or routed inter-switch link for this.
C2960x has to be accessible from SXP-peer, but pragmatically u would like to have it accessible from DNAC & ISE-deployment as well.
i guess u can use OoB mgmt interface on the C2960C for both managability from DNAC, AAA with ISE & SXP with C9K. suggest u to check SXP-topic with documentation for your C2960X SW or simply test it. Though i'd expect OoB mgmt LAN to be protected from accessing it from INFRA_VN on the FWs. it could be relevant to DNAC mgmt & AAA topics as well.

[p11l]

OK great.

Is it necessary to configure SXP bindings in the whole chain?

I mean 2960X with 9300, 9300 with 9500 and 9500 with 9500 ?

[andy!doesnt!like!uucp]

let's look on the topic from another perspective: C2960X doesnt support enforcement. Only it can do for you is to assign SGT to authorized endpoint & communicate this mapping to SXP-listener which is either or both able to enforce configured policies for given pair of src&dst SGTs or/& to communicate it further to another Trustsec device. is it what u want to achieve? 

[p11l]

yes thats what i try to do

[andy!doesnt!like!uucp]

then u have to identify where u will enforce RBAC; then build SXP between C2960Xs (publisher) & IP-to-SGT reflector (listener&publisher); then build SXP between between RBAC enforcer (listener &potentially publisher) &  IP-to-SGT reflector;
RBAC enforcer may also be pxGrid subscriber, in this way SXP is not needed at all coz AAA-sessions from C2960Xs will trigger entries in pxGrid DB with mapping of assigned by ISE SGT to an endpoint's IP & pxGrid subscribers will be able to obtain this mapping in almost real-time manner.
Most predictive way to do this (with either pxGrid or SXP) is to do enforcement on the FWs compatible with SXP or pxGrid. doing enforcement on switches will be painful. 
at the end it's worth to notice that developing of this stuff is non-trivial job requiring architector to count for many details. 

[bernardo-odige]

Sound good

[jedolphi]

There's a number of complications that are created when there's SXP between SDA Edge Node and downstream L2 switches, that's why we designed SD-Access with end-to-end data plane SGT propagation. Consequently we do not support SXP sessions on the SDA Edge Node. You can configure this scenario as a lab experiment, but please do not move to production network as TAC may not be able to support. An alternative design is to use static VLAN-to-SGT mapping within the Fabric Site which is already supported in the SD-Access user interface and automation, Regards, Jerome

[andy!doesnt!like!uucp]

Hi Jerome
w/o LISP Extranet there is no end-to-end SGT propagation as inter-VN routing takes place in FN & to transfer src SGT to egress FE one must have configure inline tagging between BNs & FNs manually.

[jedolphi]

Hi Andy. Agree. BN to Fusion Device data plane SGT propagation is supported. SXP is also supported on BN (as opposed to EN where SXP is not supported), however SXP brings scale considerations and design complexity, so BN to Fusion data plane SGT propagation is generally preferred. Cheers! Jerome

[p11l]

Hi Andy and Jerome,
thanks again for your answers!
I understand it like that:
-2960X doesn't support lisp/vxlan/sgt enforcement, so i need to configure it as a trunk (L2) link to the c9300
- c9300 in Fabric Edge Node doesn't support SXP downstream to devices like 2960X

Instructions:
- establish ip connectivity between 2960X and 9300. Like a trunk with SVI at each side
- enable and Configure SXP between this device, 2960X as publisher and 9300 as listener&publisher

At this point I am unsure. Jerome said 9300 as Edge Node do not support SXP downstream to L2 devices.

I don't really understood the earlier example you've noticed with the pxGrid point.

Pleas, can u explain it a litte bit more in detail what needs to be done and where?

-----------

Here you can see what i've already done:

-----

2960X (has 172.16.128.14)
#conf t
#cts sxp enable
#cts sxp default source-ip 172.16.128.14
#cts sxp connection peer 172.16.128.13 password none mode local speaker

following log message appear:
May 7 14:15:32 Summer-: %CTS-3-SXP_CONN_STATE_CHG_OFF: Connection <172.16.128.13, 172.16.128.14>-1 state changed from Pending_On to Off.

9300 (has 172.16.128.13)
#conf t
#cts sxp enable
#cts sxp default source-ip 172.16.128.13
#cts sxp connection peer 172.16.128.14 password none mode local listener

following log message appear:
003303: May 7 12:17:21.188: %CTS-3-SXP_CONN_STATE_CHG_OFF: Connection <172.16.128.14, 172.16.128.13>-1 state changed from Pending_On to Off.

...but...
2960X
#show cts sxp connections
SXP : Enabled
Highest Version Supported: 4
Default Password : Not Set
Default Source IP: 172.16.128.14
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 : 172.16.128.13
Source IP : 172.16.128.14
Conn status : On
Conn version : 4
Conn capability : IPv4-IPv6-Subnet
Conn hold time : 120 seconds
Local mode : SXP Speaker
Connection inst# : 1
TCP conn fd : 1
TCP conn password: none
Keepalive timer is running
Duration since last state change: 0:00:00:07 (dd:hr:mm:sec)

Total num of SXP Connections = 1

9300
#show cts sxp connections
SXP : Enabled
Highest Version Supported: 5
Default Password : Not Set
Default Key-Chain: Not Set
Default Key-Chain Name: Not Applicable
Default Source IP: 172.16.128.13
Connection retry open period: 120 secs
Reconcile period: 120 secs
Retry open timer is not running
Peer-Sequence traverse limit for export: Not Set
Peer-Sequence traverse limit for import: Not Set
----------------------------------------------
Peer IP : 172.16.128.14
Source IP : 172.16.128.13
Conn status : On
Conn version : 4
Conn capability : IPv4-IPv6-Subnet
Conn hold time : 120 seconds
Local mode : SXP Listener
Connection inst# : 1
TCP conn fd : 1
TCP conn password: none
Hold timer is running
Duration since last state change: 0:00:00:38 (dd:hr:mm:sec)

Total num of SXP Connections = 1

[andy!doesnt!like!uucp]

as i understood Jerom, SXP on the EdgeNodes is something officially unsupported in SDA, but it's officially supported on the C9K if it's BN. let Jerom to correct me if i missed something. 
I dont see your idea to build SXP between C2960X & you Fabric switches viable.  
As a finish note: answer to yourself how r u going to use BNs for the RBAC enforcement?

[p11l]

OK, why I need the Border Node from the Site to enforce RBAC? The BN in my case is the C9500.

I thought RBAC is carried out by the 2960X by forwarding the clients' requests to the ISE and implementing the rules according to the ISE's rules and regulations.
I thought the only problem now was having the SGT information sent by the ISE available on the 2960X.
And so I thought if the 9300 SGT knows and can process information then an SXP connection will be established between the 2960X and 9300 so that this information can also be used on the 2960X.
Since the 2960X itself doesn't support enforcment, I thought the route would be via the 9300.