VSX peer switches and REST API access

If Virtual Switching Extension (VSX) is enabled, you can access the REST API of a peer switch without having to separately log into or manage a session cookie from that peer switch.

To access a peer REST API from your connected switch, insert /vsx-peer in the URI path after the server URL and before the REST API and version identifier.

For example: 

https://192.0.2.5/vsx-peer/rest/v10.04/...

Notes:

  • VSX must be enabled on both switches, and the interswitch link (ISL) must be up.

  • REST API access must be enabled on the switch to which you are connected.

  • For write access, the REST API access mode must be set to read/write on the switch to which you are connected.

  • You must be logged in to the switch to which you are connected. For example, if you are connected to the primary VSX switch, you must be logged in to the primary switch.

  • The following uses of /vsx-peer in the URI path are not supported:

    • You cannot specify the login resource. Requests to /vsx-peer/rest/v10.04/login are not required because logging in to one device automatically gives you access to the peer device.

    • You cannot access the Web UI of a VSX peer switch. Setting the browser address to https://<connected_switch_ip>/vsx-peer is not supported.

    • You cannot specify a VSX peer switch in the URIs in topic subscription messages in the real-time notifications framework. However, you can access the real-time notifications framework on the VSX peer switch by setting the connection address to the following: 

      wss://<connected_switch_ip>/vsx-peer/rest/v10.04/notification

  • Audit messages are logged on the peer device with user information from the switch to which the user connected.

  • When configuration synchronization is enabled, supported configuration changes on the primary VSX switch are replicated on the secondary VSX switch. Changing the configuration of a secondary VSX switch might cause the configurations to be out of synchronization.

For more information about VSX, see the Virtual Switching Extension (VSX) Guide.

Examples:

  • Getting the VSX status of the secondary VSX switch while connected to the primary VSX switch at IP address 192.0.2.5: 

    $ curl --noproxy "192.0.2.5" -k GET \
-b /tmp/primary_auth_cookie \
"https://192.0.2.5/vsx-peer/rest/v10.04/system/vsx?attributes=oper_status"

  • Getting the VSX status of the primary VSX switch while connected to the secondary VSX switch at IP address 192.0.2.6: 

    $ curl --noproxy "192.0.2.6" -k GET \
-b /tmp/secondary_auth_cookie \
"https://192.0.2.6/vsx-peer/rest/v10.04/system/vsx?attributes=oper_status"

  • Getting the name and IP addresses of interfaces on secondary VSX switch while connected to the primary VSX switch at IP address 192.0.2.5: 

    $ curl --noproxy "192.0.2.5" -k GET \
-b /tmp/primary_auth_cookie \
"https://192.0.2.5/vsx-peer/rest/v10.04/system/interfaces?attributes=name,ipv4_address"