About Fabric Transactions


Transactions are used to synchronize configuration changes across the fabric or cluster. The originator sends the configuration change request from the client to other nodes in the fabric. Clients are the primary initiators of transactions, and clients can be a CLI user, a REST API user, or an OpenStack client.


Netvisor One sends transactions over a TCP socket on port 23399 on the fabric network, and Netvisor One opens a new socket for each transaction and phase of a transaction. Sockets are not persistent and are closed after each phase of the transaction.


Netvisor One uses status updates to distribute information across the fabric. Unlike transactions, Netvisor One does not require the data to be synchronized across the fabric, although it is usually synchronized.


The following states are sent from the local node to other nodes in the fabric:


  • Node State
  • Port State
  • VLAN State
  • Owned vPort State
  • Layer 3 Entry State


The following states are only sent to a cluster peer:


  • All Local vPort State
  • Spanning Tree State
  • Configuration File Hash Keys
  • vRouter state
  • vRouter Interface State
  • Bridge Domain State
  • Tunnel State


A node only sends updates to vPorts, a host is directly connected to the node, and you can display this information using the command, vport-show. 


Cluster nodes share a larger data set in order to act as a single node for redundancy.


More Information on Status Updates


Status updates are sent whenever a state changes on the fabric. For example, if a port goes down, or a new VLAN is created, that port or VLAN sends an update. Only the changed object, for example, VLAN10, is sent.


The entire object is sent, not just the changed field on the object. If sending data fails, Netvisor One continue attempting to resend every 250ms.


More About Transactions


Netvisor One uses transactions to synchronize configuration changes in a Netvisor One fabric. Only create, delete, modify, add, and remove commands are transactional.


The scope defines the participating nodes in the transaction:


  • Local - only a local node participates in the transaction.
  • Cluster - only the two nodes in a cluster participate in the transaction.
  • Fabric - all nodes in a fabric participate in the transaction.


Rolling Back and Rolling Forward Transactions


The Netvisor One transaction log contains both the command and the undo command(s) for a transaction, used to redo the transaction, roll forward, or undo the transaction, roll back.


You can roll back a transaction roll back using the command, transaction-rollback-to. Any scope can be rolled back. Transactions are rolled back from the latest, to a specified older transaction, in order. After successfully rolling back the transaction, the local change is undone, and the transaction removed from the transaction log.


You can roll forward a transaction using the command, transaction-rollforward-to. Netvisor One only supports the scope fabric and cluster, because the local node needs to get the transaction from somewhere. Transactions are rolled forward from the next transaction in order to the target transaction ID. Changes are applied locally and the transaction log updated.


CLI (network-admin@switch) > fabric-node-show


id:                  167772619

name:                Leaf2

fab-name:            fab1

fab-id:              a0001c8:53e2601b

cluster-id:          0:0

fab-mcast-ip:        239.4.10.94

local-mac:           64:0e:94:28:06:f2

mgmt-nic:            

mgmt-ip:             192.168.1.14/24

...

in-band-ip:          192.168.254.14/24

...

fab-tid:             9

out-port:            0

version:             2.1.201015836,pn-ONVLnvOS-2.0.2-2000212196

state:               online

firmware_upgrade:    not-required

device_state:        ok

ports:               72

id:                  201326827

name:                Leaf1

fab-name:            fab1

fab-id:              a0001c8:53e2601b

cluster-id:          0:0

fab-mcast-ip:        239.4.10.94

local-mac:           64:0e:94:30:03:97

mgmt-nic:            

mgmt-ip:             192.168.1.11/24

...

in-band-ip:          192.168.254.11/24

...

fab-tid:             9

out-port:            129

version:             2.1.201015836,pn-ONVLnvOS-2.0.2-2000212196

state:               online

firmware_upgrade:    not-required

device_state:        ok

ports:               72

id:                  167772618

name:                Spine2

fab-name:            fab1

fab-id:              a0001c8:53e2601b

cluster-id:          0:0

fab-mcast-ip:        239.4.10.94

local-mac:           64:0e:94:28:06:ee

mgmt-nic:            

mgmt-ip:             192.168.1.13/24

 

An example of a fabric that is out of sync for two nodes in the fabric:


CLI (network-admin@switch) > fabric-node-show format all layout vertical


id:                  100663365

name:                CBF-switch

fab-name:            pn-CBF4

fab-id:              a0000c5:53ab701e

cluster-id:          0:0

fab-mcast-ip:        239.4.10.111

local-mac:           64:0e:94:18:01:03

mgmt-nic:            

mgmt-ip:             192.168.1.61/24

...

in-band-ip:          192.168.77.61/24

...

fab-tid:             328

out-port:            128

version:             2.1.201005800,pn-ONVL-2.0.2-2000212196

state:               online

firmware_upgrade:    not-required

device_state:        ok

ports:               68

id:                  201326771

name:                CBF-Leaf-1

fab-name:            corp-CBF4

fab-id:              a0000c5:53ab701e

cluster-id:          0:0

fab-mcast-ip:        239.4.10.111

local-mac:           64:0e:94:30:02:4d

mgmt-nic:            

mgmt-ip:             192.168.1.53/24

...

in-band-ip:          192.168.77.53/24

...

fab-tid:             329

out-port:            128

version:             2.1.201005800,pn-ONVLnvOS-2.0.2-2000212196

state:               online

firmware_upgrade:    not-required

device_state:        ok

ports:               72

id:                  167772357

name:                CBF-Spine1

fab-name:            pn-CBF4

fab-id:              a0000c5:53ab701e

cluster-id:          0:0

fab-mcast-ip:        239.4.10.111

local-mac:           64:0e:94:28:02:de

mgmt-nic:            

mgmt-ip:             192.168.1.51/24

...

in-band-ip:          192.168.77.51/24


If you apply a configuration to the fabric, and a node does not respond to it, you can evict the node from the fabric, and then troubleshoot the problem. To evict a node, use the following command:


CLI (network-admin@switch) > fabric-node-evict name pleiades25


or


CLI (network-admin@switch) > fabric-node-evict id b000021:52a1b620