SXP and use of SXP Reflectors
Table of Contents
SXP and use of SXP Reflectors
Introduction
SXP Peering
SXP Versions
SXP Connections: Unidirectional versus Bidirectional
SXP and use of SXP Reflectors
Introduction
SXP or Scalable group tag eXchange Protocol is a TCP-based, control plane protocol used to exchange IP to SGT bindingsthat have been created on a network device through either dynamic assignment (802.1X, MAB, WebAuth) or statically via CLI with peer networking devices. SXP is supported on most Cisco Routers, Switches, Firewalls, and the Cisco Identity Services Engine or ISE. Information regarding SXP support can be found in the TrustSec Platform and Capability Matrix at
SXP Peering Overview
SXP is typically used in those scenarios where a network is incapable of supporting inline tagging.Inline tagging is the process where the Security Group Tag is carried within a special field known as CMD (Cisco Meta Data) that can be inserted in an L2 header, whether that be Ethernet, IPsec or Tunnel as in GRE/DMVPN. Often times a customer network may contain either older Cisco switches and routers or another vendor’s device which do not support this capability. In these situations, SXP is used to propagate the IP-SGT information over this part of the network for use elsewhere. Another extremely common scenario for the use of SXP is over a Service Provider network where inline tagging is not supported and a technology capable of supporting inline tagging such as IPsec, GETVPN, DMVPN or even GRE has not be implemented.
An SXP connection may be a single or multiple hops away from the source as seen in Figure 1.
Figure 1SXP Single Hop versus Multi-Hop
In Figure 1 on the left, an SXP connection is established and IP-SGT bindings advertised between the two network devices as a single hop, while on the right, a second SXP connection is established with a third device. In a multi-hop SXP implementation as on the right, the middle device in Figure 1 receives the advertised IP-SGT bindings and installs them in what is referred to as its “Bindings Database” while subsequently advertising those bindings to the third device on the right.
As SXP is TCP-based, an SXP connection can be established between devices separated by multiple hops over an IP network and can also be forwarded through firewalls. In building an SXP connection across a Service Provider network for example, the SXP source may be a branch router or switch while the destination may be at the head end router terminating the connections from the remote sites as depicted in Figure 2.
Figure 2SXP over SP Network
SXP Connections: Unidirectional versus Bidirectional
In the two diagrams contained in Figure 1, the SXP advertisements are propagated from left to right. The network device advertising the bindings is referred to as a “Speaker” while the device receiving the advertisement is a referred to as a “Listener”. This is considered to be a unidirectional SXP connection. These “Roles”, as they are referred to are interchangeable and a device may if fact be both a speaker and listener with its peer which is referred to as a bidirectional SXP connection.
With a unidirectional SXP connection all of the IP-SGT bindings resident in the speaker’s database are advertised to any and all of its peers configured as listeners. These bindings will be added to any existing IP-SGT bindings in the listener’s SXP bindings database. The following command output from a Catalyst 3850 switch provides an example of how SXP bindings are added to the existing mappings on the switch. The binding for 10.2.1.10 was created for a device authenticated on the switch via 802.1X while the bindings with a “Source” of “Internal” are for interfaces on the Catalyst switch and assigned through configuration of a “Network Device Tag”.
3850-2#show cts role-based sgt-map all
Active IPv4-SGT Bindings Information
IP Address SGT Source
======
10.2.1.2 2 INTERNAL
10.2.1.10 4 LOCAL
10.86.30.121 2 INTERNAL
10.100.10.11 11 SXP
10.100.10.13 11 SXP
10.100.20.11 12 SXP
10.100.20.13 12 SXP
10.100.30.11 13 SXP
10.100.40.13 14 SXP
10.150.10.2 2 SXP
10.150.10.127 4 SXP
IP-SGT Active Bindings Summary
======
Total number of SXP bindings = 8
Total number of LOCAL bindings = 1
Total number of INTERNAL bindings = 2
Total number of active bindings = 11
With a bidirectional SXP connection, each peer advertises its IP-SGT bindings to the other. As previously discussed, a peers bindings are added to those that may already be present in a network devices bindings database.
One important point to consider is that bidirectional SXP connections should never be attempted unless both peers support SXP version four which will be discussed in the next section. Prior to SXPv4 there was no means by which the source of an advertised IP-SGT binding could be determined. As a result the possibility of an SXP loop exists. An SXP loop should not be considered as analogous to a spanning tree loop. With a spanning tree loop, a broadcast storm ensues resulting in a seriously degraded network where communications may and typically do become impossible. The result of a SXP loop however does not create any kind of an actual broadcast storm but results in completely stale IP-SGT binding information being advertised and maintained in the bindings database.
SXP Versions
SXP has gone through three revisions since its inceptionwith each revision including additional functionality culminating with the current release, SXPv4. The original release, SXPv1 introduced the
SXP has been supported for a number of years and over time has been revised to include additional capabilities with SXPv4 being the latest. Today all Cisco, TrustSec-capable, routers and Catalyst switches as well as Cisco ISE support SXPv4. The Cisco Nexus 7000 and 1000V data center switches support SXPv3 and will gain support for SXPv4 in early 2017 with NX-OS 8.X for the Nexus 7000 and NX-OS5.2(1)SV3(3.1) for the Nexus 1000V. The Nexus 6000 and 5000 series of switches only support SXPv1 and can only be configured as SXP Speakers. There are no plans to support anything other than SXPv1 Speaker mode in the future for the Nexus 6000 and 5000 family of switches. The ASA firewalls now support SXPv3 in version 9.6.1.
In order to better understand SXP versions Table 1below provides a quick summary of the various versions and the unique functionality found in each.
Version / IPv4 Bindings / IPv6 Bindings / Subnet Binding Expansion / Loop Detection / SXP Capability Exchange1 / Yes / No / No / No / No
2 / Yes / Yes / No / No / No
3 / Yes / Yes / Yes / No / No
4 / Yes / Yes / Yes / Yes / Yes
Table 1 SXP Versions
ADDITIONAL INFO
In addition, a recent behavior around SXP has been identified. This behavior is unique to the Nexus 7K platform and is relevant to ONLY versions of NX-OS preceding version 8.0(1), hence 7.3(2). In SXPv4 with bidirectional loop detection, it is necessary to be able as a SXP Listener to collect all advertisements from each of its peers, some of which may be configured for bidirectional peering. As a result there may be numerous IP-SGT mapping learned from various SXP speakers for a single IP-SGT binding. This may occur as a result of bidirectional or unidirectional SXP connections. Also advertisements may be learned by new speakers. To accommodate all of these bindings with the ultimate goal of selecting the “best” advertisement through an election process, the concept of a “contributor” database was developed and which is more commonly known as the SXP database. In the SXP database, all of the advertisements from various SXP peers are collected and then analyzed in can what be described as an election process. The result of this election process is that the “best” advertisement is selected and stored in what is best known as the RBM (Role-Based Manager Database). It is the RBM that is used for propagating SGTs through SXP or inline tagging as well as policy enforcement decisions locally on the network device. This contributor database had developed and fully implemented in Catalyst switching platforms, routers, and the ASA in advance of SXPv4.
So what is the significance of this database regardless of SXP version?
This contributor database is used to collect all of the bindings as discussed previously and in the event that the source of the “best binding” went down , an election process would occur resulting in the “second best binding” being installed in the RBM of the network device as a listener. So, for example, where the Nexus 7K is a listener, the intent would be that through the use of its “contributor database”, if the “best binding” was lost as a result of the SXP peer advertising that binding going down, that lost binding would be replaced by another peer. Unfortunately this functionality was not fully implemented in the Nexus 7K platform until SXPv4 was introduced in NX-OS v8.0(1) as it is absolutely necessary in order to evaluate bindings learned via bidirectional SXP connections and the inherent loop detection mechanisms introduced in SXPv4.
Cisco Systems © 2018 / Page 1