Monitoring vPort-based Activity

In Netvisor ONE virtual ports, in short vPorts, are software-based Layer 2 entries associated to any ports a switch performs MAC address learning on.

While a plain-vanilla hardware Layer 2 table is limited in its capacity by a switch’s dedicated ASIC memory size, the Netvisor ONE software runs in the control plane processor’s much larger DRAM memory space and hence is capable of tracking a large list of Layer 2 entries. Such list can grow much larger than what can fit into the limited space of a hardware table. This logical software extension of the Layer 2 table is the vPort database.

vPort database entries are persistent and are synchronized across the fabric so that every fabric member is aware of every other Layer 2 table entry. This capability is particularly useful for instance to track (physical or virtual) mobile end-points as well as users so as to make sure that movements are legitimate.  (See also the Understanding Fabric Status Updates, vPorts and Keepalives section.)

In a nutshell, the vPort database can be considered the authoritative distributed endpoint directory and switching activity history book of the entire Pluribus fabric. Its innate flexibility lends itself very well to security applications, for example in the case of ARP spoofing attacks.

Let’s first see what a portion of the vPort datable may look like. The output of a vport-show command is displayed below with the two key columns in bold typeface (in this example, the inspected forwarding context is a VLAN, but can also be a VXLAN domain):

CLI network-admin@switch > vport-show format ip, mac, hostname, vlan, last-active

ip          mac               vlan hostname last-active

----------  ----------------- ---- -------- -------------------

192.168.1.3 00:50:56:b2:73:e1    7 db-serv1 2014-08-07,12:25:11

192.168.1.6 12:5c:19:69:25:30  123 db-serv2 now

192.168.1.9 d6:f9:8a:29:25:44   42 db-serv1 2014-08-07,12:25:11

In case of ARP poisoning attacks, the dynamically populated IP-to-MAC-address-binding entries (shown above) may be corrupted by a malicious end-point pretending to be someone else and sending a (series of) forged ARP packet(s) to overwrite legitimate gleaned information.

A simple protection for this exploit is to proactively create (with the vport-create command) or reactively make (as shown below) a forge-proof static binding in the vPort database. An ARP spoofing detection syslog message is printed when someone attempts the now-blocked forgery, as exemplified below:

CLI (network-admin@switch) > vport-modify mac 00:50:56:b2:73:e1 vlan 7 ip 192.168.1.3 intf 11

[…]

ARP spoofing detection syslog message:

mac/ip access denied: mac=00:50:56:b6:f9:10 ip=192.168.1.3 caller=ARP