- play_arrow Configuring OVSDB and VXLAN
- play_arrow Configuring OVSDB-Managed VXLANs with an SDN Controller
- OVSDB and VXLAN Configuration Workflows for VMware NSX Environment
- Installing OVSDB on Juniper Networks Devices
- Understanding How to Set Up OVSDB Connections on a Juniper Networks Device
- Creating and Installing an SSL Key and Certificate on a Juniper Networks Device for Connection with SDN Controllers
- Setting Up OVSDB on Juniper Networks Devices That Support the Dynamic Configuration of VXLANs
- Understanding Dynamically Configured VXLANs in an OVSDB Environment
- VMware NSX Configuration for Juniper Networks Devices Functioning as Virtual Tunnel Endpoints
- Example: Setting Up a VXLAN Layer 2 Gateway and OVSDB Connections in a VMware NSX Environment (Trunk Interfaces Supporting Untagged Packets)
- Example: Setting Up a VXLAN Layer 2 Gateway and OVSDB Connections in a VMware NSX Environment (Trunk Interfaces Supporting Tagged Packets)
- Verifying That a Logical Switch and Corresponding Junos OS OVSDB-Managed VXLAN Are Working Properly
- play_arrow Configuring VXLANs Without an SDN Controller
-
- play_arrow Troubleshooting
- play_arrow Troubleshooting Tasks
-
- play_arrow Configuration Statements and Operational Commands
Understanding How Layer 2 BUM and Layer 3 Routed Multicast Traffic Are Handled with OVSDB
The Juniper Networks Junos OS implementation of the Open vSwitch Database (OVSDB) management protocol provides a means through which software-defined networking (SDN) controllers and Juniper Networks devices that support OVSDB can communicate.
This topic explains how a Juniper Networks device with Virtual Extensible LAN (VXLAN) and OVSDB management protocol capabilities handles the following types of traffic:
(This scenario applies to all Juniper Networks devices that support VXLAN and OVSDB.) Layer 2 broadcast, unknown unicast, and multicast (BUM) traffic that originates in an OVSDB-managed VXLAN and is forwarded to interfaces within the same VXLAN.
Note:You must explicitly configure the replication of unknown unicast traffic in a Contrail environment.
(This scenario applies only to Juniper Networks devices that can function as a Layer 3 VXLAN gateway in an OVSDB-VXLAN environment.) Layer 3 multicast traffic that is received by an integrated routing and bridging (IRB) interface in an OVSDB-managed VXLAN and is forwarded to interfaces in another OVSDB-managed VXLAN.
By default, Layer 2 BUM traffic that originates in an OVSDB-managed
VXLAN is handled by one or more software virtual tunnel
endpoints (VTEPs), service nodes, or top-of-rack service
nodes (TSNs) in the same VXLAN. (In this topic, software VTEPs, service
nodes, and TSNs are known collectively as replicators.) The table for remote multicast media access control (MAC) addresses
in the OVSDB schema for physical devices contains only one entry that
has the keyword unknown-dst as the MAC string and a list
of replicators.
Given the previously described table entry, Layer 2 BUM traffic received on an interface in the OVSDB-managed VXLAN is forwarded to one of the replicators. The replicator to which a BUM packet is forwarded is determined by the Juniper Networks device on which the OVSDB-managed VXLAN is configured. On receiving the BUM packet, the entity replicates the packet and forwards the replicas to all interfaces within the VXLAN.
Instead of using replicators, you can optionally enable ingress node replication to handle Layer 2 BUM traffic on Juniper Networks devices that support OVSDB.
Ingress node replication is supported on all Juniper Networks devices that support OVSDB except the QFX Series switches.
With ingress node replication enabled, on receiving a Layer 2 BUM packet on an interface in an OVSDB-managed VXLAN, the Juniper Networks device replicates the packet and then forwards the replicas to all software VTEPs included in the unicast MACs remote table in the OVSDB schema. The software VTEPs then forward the replicas to all virtual machines (VMs), except service VMs, or nodes, on the same host.
When Juniper Networks devices replicate Layer 2 BUM packets to a large number of remote software VTEPs, the performance of the Juniper Networks devices can be impacted.
On IRB interfaces that forward Layer 3 multicast traffic from one OVSDB-managed VXLAN to another, ingress node replication is automatically implemented. With ingress node replication, the Juniper Networks device replicates a Layer 3 multicast packet and then the IRB interface forwards the replicas to all hardware and software VTEPs, but not to service nodes, in the other OVSDB-managed VXLAN. For the routing of Layer 3 multicast traffic from one OVSDB-managed VXLAN to another, ingress node replication is the only option and does not need to be configured.
