Connectivity Guide

Table Of Contents
The following shows the integration of physical and virtual components in controller-provisioned VXLAN environment:
The NSX controller communicates with the OS10 VTEP using the OVSDB management protocol over an Secure Sockets Layer
(SSL) connection. Establishing the communication between the controller and VTEP involves generating the SSL certificate at a
VTEP and copying the certificate to the NSX controller. After SSL authentication, a secure connection over SSL is established
between the controller and the VTEP, and the VTEP receives and processes the configuration data from the controller.
Configuration notes
Consider the following when configuring controller-provisioned VXLAN in OS10:
The network virtualization edge (NVE) source interface needs to be a Loopback interface, which must be a part of the
default VRF.
NSX controller-provisioned VXLAN is not supported when the OS10 switch operates in OpenFlow-only mode.
Only one mode of VxLAN provisioning (NSX Controller or Static or BGP EVPN) is supported at a time.
OS10 switch does not send the VXLAN access port statistics to the NSX controller.
Tthe VLAN IDs of VLAN interfaces created using the OS10 CLI must be different from the VLAN IDs of Port-scoped VLANs
created in the NSX controller for virtual networks.
Standard Compliance
OS10 complies with the RFC5880 for Bidirectional Forwarding Detection (BFD).
Controller-provisioned VXLAN operations
Manually configure the underlay network using OS10 CLI.
The controller provisions the following:
overlay network
virtual networks, and information about the service nodes in the VTEP
access ports membership in a virtual network
Underlay reachability to VTEP peers is provisioned or learned using existing routing protocols.
VXLAN
729