Junos® OS OVSDB and VXLAN Feature Guide - Juniper Networks

Junos® OS
OVSDB and VXLAN Feature Guide
Release
14.1
Published: 2014-11-04
Copyright © 2014, Juniper Networks, Inc.
Juniper Networks, Inc.
1194 North Mathilda Avenue
Sunnyvale, California 94089
USA
408-745-2000
www.juniper.net
Juniper Networks, Junos, Steel-Belted Radius, NetScreen, and ScreenOS are registered trademarks of Juniper Networks, Inc. in the United
States and other countries. The Juniper Networks Logo, the Junos logo, and JunosE are trademarks of Juniper Networks, Inc. All other
trademarks, service marks, registered trademarks, or registered service marks are the property of their respective owners.
Juniper Networks assumes no responsibility for any inaccuracies in this document. Juniper Networks reserves the right to change, modify,
transfer, or otherwise revise this publication without notice.
®
Junos OS OVSDB and VXLAN Feature Guide
14.1
Copyright © 2014, Juniper Networks, Inc.
All rights reserved.
The information in this document is current as of the date on the title page.
YEAR 2000 NOTICE
Juniper Networks hardware and software products are Year 2000 compliant. Junos OS has no known time-related limitations through the
year 2038. However, the NTP application is known to have some difficulty in the year 2036.
END USER LICENSE AGREEMENT
The Juniper Networks product that is the subject of this technical documentation consists of (or is intended for use with) Juniper Networks
software. Use of such software is subject to the terms and conditions of the End User License Agreement (“EULA”) posted at
http://www.juniper.net/support/eula.html. By downloading, installing or using such software, you agree to the terms and conditions of
that EULA.
ii
Copyright © 2014, Juniper Networks, Inc.
Table of Contents
About the Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Documentation and Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Supported Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Using the Examples in This Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Merging a Full Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii
Merging a Snippet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii
Documentation Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Documentation Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
Requesting Technical Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
Self-Help Online Tools and Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
Opening a Case with JTAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvi
Part 1
Overview
Chapter 1
OVSDB Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Open vSwitch Database Support on Juniper Networks Devices . . . . . . . . . . . . . . . 3
Understanding the Junos OS Implementation of VXLAN and OVSDB in a VMware
NSX for Multi-Hypervisor Environment for the Data Center . . . . . . . . . . . . . . . 4
Understanding the Open vSwitch Database Management Protocol Running on
Juniper Networks Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Understanding How to Set Up Open vSwitch Database Connections Between
Juniper Networks Devices and Controllers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Understanding How Layer 2 BUM Traffic and Layer 3 Routed Multicast Traffic
Are Handled in VXLANs Managed by OVSDB . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Understanding How to Set Up Virtual Extensible LANs in an Open vSwitch
Database Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Understanding How to Set Up OVSDB-Managed VXLANs On All Juniper
Networks Devices Except QFX5100 Switches . . . . . . . . . . . . . . . . . . . . . 10
Understanding How to Set Up OVSDB-Managed VXLANs On QFX5100
Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Understanding Automatically Created OVSDB-Managed VXLANs on a
QFX5100 Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Understanding How to Determine the State of an OVSDB-Managed
VXLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Open vSwitch Database Schema For Physical Devices . . . . . . . . . . . . . . . . . . . . . 14
Chapter 2
VXLAN Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Understanding VXLANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
VXLAN Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
What is a VXLAN? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Using a QFX5100 Switch with VXLANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Copyright © 2014, Juniper Networks, Inc.
iii
OVSDB and VXLAN Feature Guide
Using an MX Series Router as a VTEP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Manual VXLANs Require PIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Load Balancing VXLAN Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
VXLAN Constraints on QFX5100 Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
VXLAN Constraints on QFX5100 Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Part 2
Configuration
Chapter 3
Configuration Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Example: Setting Up a VXLAN Layer 2 Gateway and OVSDB Connections
Between Virtual and Physical Entities in a Data Center . . . . . . . . . . . . . . . . . 25
Example: Setting Up Inter-VXLAN Routing and OVSDB Connections in a Data
Center . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Example: Configuring VXLAN on MX Series Routers . . . . . . . . . . . . . . . . . . . . . . . 42
Examples: Configuring VXLANs on QFX Series Switches . . . . . . . . . . . . . . . . . . . . 51
Example: Configuring a VXLAN Transit Switch . . . . . . . . . . . . . . . . . . . . . . . . 52
Example: Configuring a VXLAN Layer 2 Gateway . . . . . . . . . . . . . . . . . . . . . . 53
Chapter 4
Configuration Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Installing Open vSwitch Database Components on Juniper Networks Devices . . . 61
Creating and Installing an SSL Key and Certificate on a Juniper Networks Device
for Connection with VMware NSX Controllers . . . . . . . . . . . . . . . . . . . . . . . . . 62
Setting Up the Open vSwitch Database Management Protocol on Juniper
Networks Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
VMware NSX Configuration for Juniper Networks Devices That Function as Virtual
Tunnel Endpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Creating a Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Creating a Gateway Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Creating a Logical Switch Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Configuring OVSDB-Managed VXLANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Configuring VXLANs on a QFX5100 Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Configuring a Source IP Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Configuring PIM for VXLANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Configuring VXLANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Chapter 5
OVSDB Configuration Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
controller (OVSDB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
inactivity-probe-duration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
ingress-node-replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
interfaces (OVSDB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
maximum-backoff-duration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
ovsdb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
ovsdb-managed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
port (OVSDB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
protocol (OVSDB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
traceoptions (OVSDB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Chapter 6
VXLAN Configuration Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
decapsulate-accept-inner-vlan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
encapsulate-inner-vlan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
iv
Copyright © 2014, Juniper Networks, Inc.
Table of Contents
multicast-group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
ovsdb-managed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
unreachable-vtep-aging-timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
vni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
vtep-source-interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
vxlan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Part 3
Administration
Chapter 7
OVSDB Monitoring Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
show bridge mac-table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
show ovsdb controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
show ovsdb interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
show ovsdb logical-switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
show ovsdb mac . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
show ovsdb statistics interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
show ovsdb virtual-tunnel-end-point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
show vpls mac-table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Chapter 8
VXLAN Monitoring Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
show bridge mac-table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
show vpls mac-table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Verifying VXLAN Reachability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Verifying That a Local VXLAN VTEP is Configured Correctly . . . . . . . . . . . . . . . . 126
Verifying MAC Learning from a Remote VTEP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Monitor a Remote VTEP Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Part 4
Troubleshooting
Chapter 9
Troubleshooting Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Troubleshooting a Nonoperational VMware NSX Logical Switch and
Corresponding Junos OS OVSDB-Managed VXLAN . . . . . . . . . . . . . . . . . . . . 131
Copyright © 2014, Juniper Networks, Inc.
v
OVSDB and VXLAN Feature Guide
vi
Copyright © 2014, Juniper Networks, Inc.
List of Figures
Part 1
Overview
Chapter 1
OVSDB Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Figure 1: High-Level NSX for Multi-Hypervisor Architecture . . . . . . . . . . . . . . . . . . . 5
Figure 2: Integration of Juniper Networks Device That Implements VXLAN and
OVSDB into NSX for Multi-Hypervisor Environment . . . . . . . . . . . . . . . . . . . . . 5
Chapter 2
VXLAN Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Figure 3: VXLAN Packet Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Part 2
Configuration
Chapter 3
Configuration Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Figure 4: VXLAN/OVSDB Layer 2 Gateway Topology . . . . . . . . . . . . . . . . . . . . . . . 27
Figure 5: Inter-VXLAN Routing and OVSDB Topology . . . . . . . . . . . . . . . . . . . . . . 35
Figure 6: QFX5100 Acting as a VXLAN Transit Switch . . . . . . . . . . . . . . . . . . . . . . 53
Figure 7: QFX5100 Acting as a VTEP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Copyright © 2014, Juniper Networks, Inc.
vii
OVSDB and VXLAN Feature Guide
viii
Copyright © 2014, Juniper Networks, Inc.
List of Tables
About the Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Table 1: Notice Icons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Table 2: Text and Syntax Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv
Part 1
Overview
Chapter 1
OVSDB Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Table 3: OVSDB Support on Junos OS Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Table 4: NSX Multi-Hypervisor Components and Products That Can Be
Implemented . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Table 5: Summary of Configuration Tasks for Setting Up An OVSDB-Managed
VXLAN on All Juniper Networks Devices Except QFX5100 Switches . . . . . . . . 11
Table 6: Summary of Configuration Tasks for Setting Up An OVSDB-Managed
VXLAN on QFX5100 Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Table 7: OVSDB Schema Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Part 2
Configuration
Chapter 3
Configuration Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Table 8: Components of the Topology for Setting Up a VXLAN Layer 2 Gateway
and OVSDB Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Table 9: Components of the Topology for Setting Up Inter-VXLAN Routing and
OVSDB Connections in a Data Center . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Chapter 4
Configuration Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Table 10: Create a Gateway in NSX Manager: Key Configurations . . . . . . . . . . . . . 65
Table 11: Create a Gateway Service in NSX Manager: Key Configurations . . . . . . . 65
Table 12: Create a Logical Switch Port in NSX Manager: Key Configurations . . . . 66
Part 3
Administration
Chapter 7
OVSDB Monitoring Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Table 13: show bridge mac-table Output fields . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Table 14: show ovsdb controller Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Table 15: show ovsdb interface Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Table 16: show ovsdb logical-switch Output Fields . . . . . . . . . . . . . . . . . . . . . . . 102
Table 17: show ovsdb mac Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Table 18: show ovsdb statistics interface Output Fields . . . . . . . . . . . . . . . . . . . . 107
Table 19: show ovsdb virtual-tunnel-end-point Output Fields . . . . . . . . . . . . . . . 109
Table 20: show vpls mac-table Output fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Chapter 8
VXLAN Monitoring Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Copyright © 2014, Juniper Networks, Inc.
ix
OVSDB and VXLAN Feature Guide
Table 21: show bridge mac-table Output fields . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Table 22: show vpls mac-table Output fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
x
Copyright © 2014, Juniper Networks, Inc.
About the Documentation
•
Documentation and Release Notes on page xi
•
Supported Platforms on page xi
•
Using the Examples in This Manual on page xi
•
Documentation Conventions on page xiii
•
Documentation Feedback on page xv
•
Requesting Technical Support on page xv
Documentation and Release Notes
®
To obtain the most current version of all Juniper Networks technical documentation,
see the product documentation page on the Juniper Networks website at
http://www.juniper.net/techpubs/.
If the information in the latest release notes differs from the information in the
documentation, follow the product Release Notes.
Juniper Networks Books publishes books by Juniper Networks engineers and subject
matter experts. These books go beyond the technical documentation to explore the
nuances of network architecture, deployment, and administration. The current list can
be viewed at http://www.juniper.net/books.
Supported Platforms
For the features described in this document, the following platforms are supported:
•
EX Series
•
MX Series
•
QFX Series standalone switches
Using the Examples in This Manual
If you want to use the examples in this manual, you can use the load merge or the load
merge relative command. These commands cause the software to merge the incoming
configuration into the current candidate configuration. The example does not become
active until you commit the candidate configuration.
Copyright © 2014, Juniper Networks, Inc.
xi
OVSDB and VXLAN Feature Guide
If the example configuration contains the top level of the hierarchy (or multiple
hierarchies), the example is a full example. In this case, use the load merge command.
If the example configuration does not start at the top level of the hierarchy, the example
is a snippet. In this case, use the load merge relative command. These procedures are
described in the following sections.
Merging a Full Example
To merge a full example, follow these steps:
1.
From the HTML or PDF version of the manual, copy a configuration example into a
text file, save the file with a name, and copy the file to a directory on your routing
platform.
For example, copy the following configuration to a file and name the file ex-script.conf.
Copy the ex-script.conf file to the /var/tmp directory on your routing platform.
system {
scripts {
commit {
file ex-script.xsl;
}
}
}
interfaces {
fxp0 {
disable;
unit 0 {
family inet {
address 10.0.0.1/24;
}
}
}
}
2. Merge the contents of the file into your routing platform configuration by issuing the
load merge configuration mode command:
[edit]
user@host# load merge /var/tmp/ex-script.conf
load complete
Merging a Snippet
To merge a snippet, follow these steps:
1.
From the HTML or PDF version of the manual, copy a configuration snippet into a text
file, save the file with a name, and copy the file to a directory on your routing platform.
For example, copy the following snippet to a file and name the file
ex-script-snippet.conf. Copy the ex-script-snippet.conf file to the /var/tmp directory
on your routing platform.
commit {
file ex-script-snippet.xsl; }
xii
Copyright © 2014, Juniper Networks, Inc.
About the Documentation
2. Move to the hierarchy level that is relevant for this snippet by issuing the following
configuration mode command:
[edit]
user@host# edit system scripts
[edit system scripts]
3. Merge the contents of the file into your routing platform configuration by issuing the
load merge relative configuration mode command:
[edit system scripts]
user@host# load merge relative /var/tmp/ex-script-snippet.conf
load complete
For more information about the load command, see the CLI User Guide.
Documentation Conventions
Table 1 on page xiii defines notice icons used in this guide.
Table 1: Notice Icons
Icon
Meaning
Description
Informational note
Indicates important features or instructions.
Caution
Indicates a situation that might result in loss of data or hardware damage.
Warning
Alerts you to the risk of personal injury or death.
Laser warning
Alerts you to the risk of personal injury from a laser.
Tip
Indicates helpful information.
Best practice
Alerts you to a recommended use or implementation.
Table 2 on page xiv defines the text and syntax conventions used in this guide.
Copyright © 2014, Juniper Networks, Inc.
xiii
OVSDB and VXLAN Feature Guide
Table 2: Text and Syntax Conventions
Convention
Description
Examples
Bold text like this
Represents text that you type.
To enter configuration mode, type the
configure command:
user@host> configure
Fixed-width text like this
Italic text like this
Italic text like this
Represents output that appears on the
terminal screen.
user@host> show chassis alarms
•
Introduces or emphasizes important
new terms.
•
•
Identifies guide names.
A policy term is a named structure
that defines match conditions and
actions.
•
Identifies RFC and Internet draft titles.
•
Junos OS CLI User Guide
•
RFC 1997, BGP Communities Attribute
No alarms currently active
Represents variables (options for which
you substitute a value) in commands or
configuration statements.
Configure the machine’s domain name:
Represents names of configuration
statements, commands, files, and
directories; configuration hierarchy levels;
or labels on routing platform
components.
•
To configure a stub area, include the
stub statement at the [edit protocols
ospf area area-id] hierarchy level.
•
The console port is labeled CONSOLE.
< > (angle brackets)
Encloses optional keywords or variables.
stub <default-metric metric>;
| (pipe symbol)
Indicates a choice between the mutually
exclusive keywords or variables on either
side of the symbol. The set of choices is
often enclosed in parentheses for clarity.
broadcast | multicast
# (pound sign)
Indicates a comment specified on the
same line as the configuration statement
to which it applies.
rsvp { # Required for dynamic MPLS only
[ ] (square brackets)
Encloses a variable for which you can
substitute one or more values.
community name members [
community-ids ]
Indention and braces ( { } )
Identifies a level in the configuration
hierarchy.
; (semicolon)
Identifies a leaf statement at a
configuration hierarchy level.
Text like this
[edit]
root@# set system domain-name
domain-name
(string1 | string2 | string3)
[edit]
routing-options {
static {
route default {
nexthop address;
retain;
}
}
}
GUI Conventions
xiv
Copyright © 2014, Juniper Networks, Inc.
About the Documentation
Table 2: Text and Syntax Conventions (continued)
Convention
Description
Examples
Bold text like this
Represents graphical user interface (GUI)
items you click or select.
•
In the Logical Interfaces box, select
All Interfaces.
•
To cancel the configuration, click
Cancel.
> (bold right angle bracket)
Separates levels in a hierarchy of menu
selections.
In the configuration editor hierarchy,
select Protocols>Ospf.
Documentation Feedback
We encourage you to provide feedback, comments, and suggestions so that we can
improve the documentation. You can provide feedback by using either of the following
methods:
•
Online feedback rating system—On any page at the Juniper Networks Technical
Documentation site at http://www.juniper.net/techpubs/index.html, simply click the
stars to rate the content, and use the pop-up form to provide us with information about
your experience. Alternately, you can use the online feedback form at
https://www.juniper.net/cgi-bin/docbugreport/.
•
E-mail—Send your comments to [email protected]. Include the document
or topic name, URL or page number, and software version (if applicable).
Requesting Technical Support
Technical product support is available through the Juniper Networks Technical Assistance
Center (JTAC). If you are a customer with an active J-Care or JNASC support contract,
or are covered under warranty, and need post-sales technical support, you can access
our tools and resources online or open a case with JTAC.
•
JTAC policies—For a complete understanding of our JTAC procedures and policies,
review the JTAC User Guide located at
http://www.juniper.net/us/en/local/pdf/resource-guides/7100059-en.pdf.
•
Product warranties—For product warranty information, visit
http://www.juniper.net/support/warranty/.
•
JTAC hours of operation—The JTAC centers have resources available 24 hours a day,
7 days a week, 365 days a year.
Self-Help Online Tools and Resources
For quick and easy problem resolution, Juniper Networks has designed an online
self-service portal called the Customer Support Center (CSC) that provides you with the
following features:
Copyright © 2014, Juniper Networks, Inc.
xv
OVSDB and VXLAN Feature Guide
•
Find CSC offerings: http://www.juniper.net/customers/support/
•
Search for known bugs: http://www2.juniper.net/kb/
•
Find product documentation: http://www.juniper.net/techpubs/
•
Find solutions and answer questions using our Knowledge Base: http://kb.juniper.net/
•
Download the latest versions of software and review release notes:
http://www.juniper.net/customers/csc/software/
•
Search technical bulletins for relevant hardware and software notifications:
http://kb.juniper.net/InfoCenter/
•
Join and participate in the Juniper Networks Community Forum:
http://www.juniper.net/company/communities/
•
Open a case online in the CSC Case Management tool: http://www.juniper.net/cm/
To verify service entitlement by product serial number, use our Serial Number Entitlement
(SNE) Tool: https://tools.juniper.net/SerialNumberEntitlementSearch/
Opening a Case with JTAC
You can open a case with JTAC on the Web or by telephone.
•
Use the Case Management tool in the CSC at http://www.juniper.net/cm/.
•
Call 1-888-314-JTAC (1-888-314-5822 toll-free in the USA, Canada, and Mexico).
For international or direct-dial options in countries without toll-free numbers, see
http://www.juniper.net/support/requesting-support.html.
xvi
Copyright © 2014, Juniper Networks, Inc.
PART 1
Overview
•
OVSDB Overview on page 3
•
VXLAN Overview on page 17
Copyright © 2014, Juniper Networks, Inc.
1
OVSDB and VXLAN Feature Guide
2
Copyright © 2014, Juniper Networks, Inc.
CHAPTER 1
OVSDB Overview
•
Open vSwitch Database Support on Juniper Networks Devices on page 3
•
Understanding the Junos OS Implementation of VXLAN and OVSDB in a VMware NSX
for Multi-Hypervisor Environment for the Data Center on page 4
•
Understanding the Open vSwitch Database Management Protocol Running on Juniper
Networks Devices on page 6
•
Understanding How to Set Up Open vSwitch Database Connections Between Juniper
Networks Devices and Controllers on page 7
•
Understanding How Layer 2 BUM Traffic and Layer 3 Routed Multicast Traffic Are
Handled in VXLANs Managed by OVSDB on page 8
•
Understanding How to Set Up Virtual Extensible LANs in an Open vSwitch Database
Environment on page 10
•
Open vSwitch Database Schema For Physical Devices on page 14
Open vSwitch Database Support on Juniper Networks Devices
Supported Platforms
MX Series, QFX Series standalone switches
Table 3 on page 3 lists the Juniper Networks devices that support the Open vSwitch
Database (OVSDB) management protocol. For each device, the table also includes the
OVSDB software package and the initial Junos OS release that must be installed for
OVSDB support. The OVSDB software package release must be the same as the Junos
OS release running on the device.
Table 3: OVSDB Support on Junos OS Devices
Junos OS Device
OVSDB Software Package
Junos OS Release
MX80 3D Universal Edge Router
jsdn-powerpc-release
14.1R2
MX240, MX480, MX960 3D Universal Edge Routers
jsdn-i386-release
14.1R2
QFX5100 Ethernet Switch
jsdn-i386-release
14.1X53-D10
Related
Documentation
•
Installing Open vSwitch Database Components on Juniper Networks Devices on page 61
Copyright © 2014, Juniper Networks, Inc.
3
OVSDB and VXLAN Feature Guide
Understanding the Junos OS Implementation of VXLAN and OVSDB in a VMware NSX
for Multi-Hypervisor Environment for the Data Center
Supported Platforms
MX Series, QFX Series standalone switches
Some Juniper Networks devices support Virtual Extensible LAN (VXLAN) and the Open
vSwitch Database (OVSDB) management protocol. (For information about the Juniper
Networks devices on which OVSDB is supported and the Junos OS release in which
support is introduced, see “Open vSwitch Database Support on Juniper Networks Devices”
on page 3.) Support for VXLAN and OVSDB enables the Juniper Networks devices in a
physical network to be integrated into a virtual network.
The implementation of VXLAN and OVSDB on Juniper Networks devices is supported in
a VMware NSX for Multi-Hypervisor environment for the data center. Table 4 on page 4
outlines the components that compose this environment and products that are typically
deployed for each component.
Table 4: NSX Multi-Hypervisor Components and Products That Can Be Implemented
Component
Products
Cloud management platform (CMP)
CloudStack
OpenStack
Custom CMP
Network virtualization platform
NSX for Multi-Hypervisor
Hypervisor
Kernel-based Virtual Machine (KVM)
Red Hat
VMware ESXi
Xen
NOTE: Juniper Networks supports KVM and ESXi only.
Virtual switch
Open vSwitch (OVS)
NSX vSwitch
SDN controller
NSX multi-hypervisor controller
NOTE: Juniper Networks supports NSX multi-hypervisor controller version
4.0.3.
4
Overlay protocol
VXLAN
MAC learning protocol
OVSDB
Copyright © 2014, Juniper Networks, Inc.
Chapter 1: OVSDB Overview
Figure 1 on page 5 shows a high-level view of the architecture into which the NSX for
Multi-Hypervisor platform fits, while Figure 2 on page 5 provides a more detailed
representation of the components in the virtual and physical networks.
Figure 1: High-Level NSX for Multi-Hypervisor Architecture
Figure 2: Integration of Juniper Networks Device That Implements VXLAN
and OVSDB into NSX for Multi-Hypervisor Environment
In the data center topology shown in Figure 2 on page 5, the physical and virtual servers
need to communicate. To facilitate this communication, a Juniper Networks device that
supports VXLAN is strategically deployed so that it serves as a gateway, which is also
known as a hardware virtual tunnel endpoint (VTEP), at the edge of the physical network.
Working in conjunction with the software VTEP, which is deployed at the edge of the
virtual network, the hardware VTEP encapsulates packets from resources on physical
Copyright © 2014, Juniper Networks, Inc.
5
OVSDB and VXLAN Feature Guide
server 1 with a VXLAN header, and after the packets traverse the Layer 3 transport network,
the software VTEP removes the VXLAN header from the packets and forwards the
packets to the appropriate virtual machines (VMs). In essence, the encapsulation and
de-encapsulation of packets by the hardware and software VTEPs enables components
in the physical and virtual networks to coexist without one needing to understand the
workings of the other.
The same Juniper Networks device that acts as hardware VTEP in Figure 2 on page 5
implements OVSDB, which enables this device to learn the MAC addresses of physical
server 1 and other physical servers, and publish the addresses in the OVSDB schema,
which was defined for physical devices. In the virtual network, one or more NSX controllers
collect the MAC addresses of HOST 1 and other virtual servers, and publish the addresses
in the OVSDB schema. Using the OVSDB schema, components in the physical and virtual
networks can exchange MAC addresses, as well as statistical information, enabling the
components to learn about and reach each other in their respective networks.
Related
Documentation
•
Understanding the Open vSwitch Database Management Protocol Running on Juniper
Networks Devices on page 6
•
Open vSwitch Database Schema For Physical Devices on page 14
Understanding the Open vSwitch Database Management Protocol Running on Juniper
Networks Devices
Supported Platforms
MX Series, QFX Series standalone switches
The Juniper Networks Junos operating system (Junos OS) implementation of the Open
vSwitch Database (OVSDB) management protocol provides a means through which
VMware NSX controllers and Juniper Networks devices that support OVSDB can
communicate. In an NSX multi-hypervisor environment, NSX controllers and Juniper
Networks devices exchange control and statistical information, thereby enabling virtual
machine (VM) traffic from entities in a virtual network to be forwarded to entities in a
physical network and vice versa.
To enable communication between NSX controllers and Juniper Networks devices, the
Junos OS implementation of OVSDB includes an OVSDB server and an OVSDB client,
both of which run on each Juniper Networks device that supports OVSDB.
The OVSDB server on a Juniper Networks device can communicate with an OVSDB client
on one or more NSX controllers. To establish a connection between a Juniper Networks
device and an NSX controller, you must specify information about the controller (IP
address) and the connection (port over which the connection occurs and the
communication protocol to be used) on each Juniper Networks device. After the
configuration is successfully committed, the connection is established between the
management port (fxp0) of the Juniper Networks device and the NSX controller port
that you specify in the Junos OS configuration.
The OVSDB server stores and maintains an OVSDB database schema, which is defined
for physical devices. This schema contains control and statistical information provided
by the OVSDB client on the Juniper Networks devices and NSX controllers. This information
6
Copyright © 2014, Juniper Networks, Inc.
Chapter 1: OVSDB Overview
is stored in various tables in the schema. The OVSDB client on the Juniper Networks
devices and NSX controllers monitors the schema for additions, deletions, and
modifications to this information, and the information is used for various purposes such
as learning the MAC addresses of virtual hosts and physical servers.
The schema provides a means through which the Juniper Networks devices and the NSX
controllers can exchange information. For example, the Juniper Networks devices capture
MAC routes to entities in the physical network and push this information to a table in the
schema so that NSX controllers with connections to these Juniper Networks devices can
access the MAC routes. Conversely, NSX controllers capture MAC routes to entities in
the virtual network and push this information to a table in the schema so that Juniper
Networks devices with connections to the NSX controllers can access the MAC routes.
Some of the OVSDB table names include the words local or remote, for example, unicast
MACs local table and unicast MACs remote table. Information in local tables is learned
by a Juniper Networks device that functions as a hardware virtual tunnel endpoint (VTEP),
while information in remote tables is learned from other software or hardware VTEPs.
Related
Documentation
•
Understanding How to Set Up Open vSwitch Database Connections Between Juniper
Networks Devices and Controllers on page 7
•
Open vSwitch Database Schema For Physical Devices on page 14
Understanding How to Set Up Open vSwitch Database Connections Between Juniper
Networks Devices and Controllers
Supported Platforms
MX Series, QFX Series standalone switches
The Juniper Networks Junos operating system (Junos OS) implementation of the Open
vSwitch Database (OVSDB) management protocol provides a means through which
VMware NSX controllers and Juniper Networks devices that support OVSDB can
communicate. This implementation of OVSDB supports one cluster of NSX controllers,
which includes three or five controllers as recommended by VMware.
To implement the OVSDB management protocol on a Juniper Networks device, you must
explicitly configure a connection to one NSX controller, using the Junos OS CLI. If the NSX
controller to which you explicitly configure a connection is in a cluster, the controller
pushes information about other controllers in the same cluster to the device, and the
device establishes connections with the other controllers. However, you can also explicitly
configure connections with the other controllers in the cluster, using the Junos OS CLI.
A Juniper Networks device exchanges control and statistical data with each NSX controller
to which it is connected. Therefore, the benefits of connecting a Juniper Networks device
to multiple NSX controllers include redundancy and load-balancing of the controller
workload.
Connections to all NSX controllers are made on the management interface of the Juniper
Networks device. (The management interface on MX Series routers is fxp0 and on
QFX5100 switches is em0 or em1.) To set up a connection between a Juniper Networks
device and an NSX controller, you need to configure the following parameters on the
Juniper Networks device:
Copyright © 2014, Juniper Networks, Inc.
7
OVSDB and VXLAN Feature Guide
•
IP address of the NSX controller.
•
The protocol that secures the connection. Secure Sockets Layer (SSL) is the supported
protocol.
NOTE: The SSL connection requires a private key and certificates, which
must be stored in the /var/db/certs directory of the Juniper Networks device.
For more information about the files, including actions you must take to
create and install some of the files, see “Creating and Installing an SSL Key
and Certificate on a Juniper Networks Device for Connection with VMware
NSX Controllers” on page 62.
•
Number of the port over which the connection is made. The port number of the default
port is 6632.
Optionally, you can configure the following connection timers on the Juniper Networks
device:
Related
Documentation
•
Inactivity probe duration—The maximum amount of time, in milliseconds, that the
connection can be inactive before an inactivity probe is sent. The default value is 0
milliseconds, which means that an inactivity probe is never sent.
•
Maximum backoff duration—If an attempt to connect to an NSX controller fails, the
maximum amount of time, in milliseconds, before the device can make the next attempt.
The default value is 1000 milliseconds.
•
Setting Up the Open vSwitch Database Management Protocol on Juniper Networks
Devices on page 63
•
Understanding the Open vSwitch Database Management Protocol Running on Juniper
Networks Devices on page 6
Understanding How Layer 2 BUM Traffic and Layer 3 Routed Multicast Traffic Are
Handled in VXLANs Managed by OVSDB
Supported Platforms
8
EX Series, MX Series
Copyright © 2014, Juniper Networks, Inc.
Chapter 1: OVSDB Overview
The Juniper Networks Junos operating system (Junos OS) implementation of the Open
vSwitch Database (OVSDB) management protocol provides a means through which
VMware NSX 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:
•
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.
•
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 service nodes in the same VXLAN. When this option is used, the table for
remote multicast 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 software
virtual tunnel endpoints (VTEPs) that host the service nodes.
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 software VTEPs. The software
VTEP, and therefore, the service node 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 service node replicates the packet and forwards the replicas
to all interfaces within the VXLAN.
Instead of using service nodes, you can optionally enable ingress node replication to
handle Layer 2 BUM traffic on Juniper Networks devices that support OVSDB.
NOTE: Ingress node replication is supported on all Juniper Networks devices
that support OVSDB except the QFX5100 switch.
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.
NOTE: 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
Copyright © 2014, Juniper Networks, Inc.
9
OVSDB and VXLAN Feature Guide
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.
Related
Documentation
•
Configuring OVSDB-Managed VXLANs on page 66
•
Open vSwitch Database Schema For Physical Devices on page 14
Understanding How to Set Up Virtual Extensible LANs in an Open vSwitch Database
Environment
Supported Platforms
MX Series, QFX Series
The Juniper Networks Junos operating system (Junos OS) implementation of the Open
vSwitch Database (OVSDB) management protocol provides a means through which
VMware NSX controllers and Juniper Networks devices that support OVSDB can
communicate.
In a Junos OS environment, the concept of an OVSDB-managed Layer 2 broadcast domain
in which data flows are limited to that domain is known as a VXLAN. In an NSX
environment, the same concept is known as a logical switch. Understanding the different
terminology in turn enables you to better understand the configuration tasks required
for setting up OVSDB-managed VXLANs.
The following sections explain what you need to do to set up OVSDB-managed VXLANs
properly for each Juniper Networks device that supports OVSDB and VXLAN:
•
Understanding How to Set Up OVSDB-Managed VXLANs On All Juniper Networks
Devices Except QFX5100 Switches on page 10
•
Understanding How to Set Up OVSDB-Managed VXLANs On QFX5100
Switches on page 11
•
Understanding Automatically Created OVSDB-Managed VXLANs on a QFX5100
Switch on page 12
•
Understanding How to Determine the State of an OVSDB-Managed VXLAN on page 13
Understanding How to Set Up OVSDB-Managed VXLANs On All Juniper Networks Devices
Except QFX5100 Switches
For each VXLAN that you plan to implement, you must first configure a logical switch,
using NSX Manager or the NSX API. Based on the name and the VXLAN network identifier
(VNI) that you specify, NSX automatically generates a universally unique identifier (UUID)
for the logical switch. You must retain the UUID of the logical switch for later use.
Next, on the Juniper Networks device, you must configure the corresponding VXLAN,
including the same VNI specified for the logical switch, using the Junos OS CLI. For the
name of the VXLAN, you must specify the UUID for the logical switch.
When configuring a logical switch and a corresponding VXLAN, it is important that the
UUID and VNI in both configurations are the same. If these elements are not the same,
10
Copyright © 2014, Juniper Networks, Inc.
Chapter 1: OVSDB Overview
the logical switch and VXLAN cannot become operational, which means they cannot
exchange MAC addresses learned in the NSX and Junos OS environments, respectively.
Table 5 on page 11 provides a summary of the procedure that you must perform for each
OVSDB-managed VXLAN on each Juniper Networks device, where to get more information
about the configuration task, and the configuration statements that you must use to
configure the VXLAN.
Table 5: Summary of Configuration Tasks for Setting Up An OVSDB-Managed VXLAN on All
Juniper Networks Devices Except QFX5100 Switches
Juniper Networks
Device That
Supports OVSDB
and VXLAN
Configure Logical
Switch, Using
NSX Manager or
the NSX API?
Where to Find
More
Configuration
Information
MX Series routers
Yes
See the
documentation
that accompanies
NSX Manager or
the NSX API.
Configure
Corresponding
VXLAN on
Juniper Networks
Device?
Junos OS
Statement to
Configure the
OVSDB-Managed
VXLAN
Yes
ovsdb-managed
statement in the
[edit
bridge-domains
domain-name
vxlan] hierarchy.
Where to Find
More
Configuration
Information
“Configuring
OVSDB-Managed
VXLANs” on
page 66
For the name of
the VXLAN, specify
the UUID for the
logical switch
configured in NSX
Manager or in the
NSX API.
Understanding How to Set Up OVSDB-Managed VXLANs On QFX5100 Switches
For each OVSDB-managed VXLAN that you plan to implement, we recommend a
particular configuration workflow. First, you must specify a few statements in the Junos
OS CLI of the QFX5100 switch. Then, you must configure a logical switch, using NSX
Manager or the NSX API. Based on the name and the VNI that you specify, NSX
automatically generates a UUID for the logical switch.
After you create a logical switch in NSX Manager or in the NSX API, the NSX controller
pushes relevant information to the logical switch table in the OVSDB schema for physical
devices. This schema resides in the QFX5100 switch. Based on the information pushed
by the NSX controller, the switch then automatically creates a corresponding VXLAN,
thereby eliminating the need for you to perform this task, using the Junos OS CLI. For the
name of the VXLAN, the switch uses the UUID of the logical switch. For more information
about automatically created VXLANs, see “Understanding Automatically Created
OVSDB-Managed VXLANs on a QFX5100 Switch” on page 12.
Table 6 on page 12 provides a summary of the procedure that you must perform for each
OVSDB-managed VXLAN on a QFX5100 switch, where to get more information about
the configuration task, and the configuration statements that you must use to configure
the VXLAN.
Copyright © 2014, Juniper Networks, Inc.
11
OVSDB and VXLAN Feature Guide
Table 6: Summary of Configuration Tasks for Setting Up An OVSDB-Managed VXLAN on
QFX5100 Switches
Required Junos OS
Configuration
Configure Logical
Switch, Using NSX
Manager or the NSX
API?
•
Yes
Enter the set
switch-options
ovsdb-managed
configuration mode
command.
•
Use the set
Where to Find More
Configuration
Information
See the
documentation that
accompanies NSX
Manager or the NSX
API.
Configure
Corresponding
VXLAN on Juniper
Networks Device?
Junos OS Statement
to Configure the
OVSDB-Managed
VXLAN
No. The QFX5100
switch automatically
creates a
corresponding
OVSDB-managed
VXLAN.
–
interfaces
interface-name unit
logical-unit-number
family
ethernet-switching
interface-mode
access configuration
mode command to
configure each
interface that you
want to associate
with the VXLAN.
As described in Table 6 on page 12, you must issue the set switch-options ovsdb-managed
statement in the Junos OS CLI of the switch. Issuing this statement and committing the
configuration enable the QFX5100 switch to automatically configure an OVSDB-managed
VXLAN after the NSX controller pushes relevant information about the corresponding
logical switch to the QFX5100 switch. Upon receipt of a logical switch information, if the
QFX5100 switch does not detect the presence of this statement, it cannot start the
automatic configuration of the corresponding VXLAN.
Understanding Automatically Created OVSDB-Managed VXLANs on a QFX5100 Switch
After a QFX5100 switch creates a VXLAN, you can issue the show configuration operational
mode command in the Junos OS CLI, and a configuration similar to the following sample
appears:
set vlans 28805c1d-0122-495d-85df-19abd647d772 vxlan vni 100
set vlans 28805c1d-0122-495d-85df-19abd647d772 vlan-id 75
Also, if you specified the following command in the Junos OS CLI of the switch to configure
interface ge-1/0/0 unit 0:
set interfaces ge-1/0/0 unit 0 family ethernet-switching interface-mode access
The switch automatically associates the interface with the VXLAN as shown:
set interfaces ge-1/0/0 unit 0 family ethernet-switching interface-mode access vlan
members 28805c1d-0122-495d-85df-19abd647d772
Note the following about this sample configuration:
12
Copyright © 2014, Juniper Networks, Inc.
Chapter 1: OVSDB Overview
•
The name of the VXLAN is 28805c1d-0122-495d-85df-19abd647d772, which assumes
that the logical switch UUID generated by NSX is
28805c1d-0122-495d-85df-19abd647d772.
•
The QFX5100 switch automatically generated the VLAN ID of 75 for the VXLAN. In
general, when generating a VLAN ID, the switch uses a VLAN ID that is not currently
used either by NSX Manager or the NSX API, or by the QFX5100 switch.
Furthermore, if the switch detects an already used VLAN ID in a configuration performed
in the Junos OS CLI, the switch displays an error message.
•
After the switch automatically associates interface ge-1/0/0 unit 0 with VXLAN
28805c1d-0122-495d-85df-19abd647d772, keep in mind that you must also configure
the interface as OVSDB-managed in the Junos OS CLI. For information about configuring
an interface as OVSDB-managed, see “Setting Up the Open vSwitch Database
Management Protocol on Juniper Networks Devices” on page 63.
•
The QFX5100 switch can automatically associate access interfaces with the VXLAN.
It cannot automatically associate trunk interfaces with the VXLAN.
If you need to modify or delete an OVSDB-managed VXLAN that was automatically
created by a QFX5100 switch, you must modify or delete the corresponding logical switch
configuration in NSX Manager or in the NSX API. After you update the logical switch
configuration, the NSX controller pushes the update to the QFX5100 switch, and the
switch modifies or deletes its configuration accordingly. Modifying or deleting the VXLAN
configuration by using the Junos OS CLI on the switch does not work.
Understanding How to Determine the State of an OVSDB-Managed VXLAN
Regardless of the Juniper Networks device and the procedure that you follow to set up
OVSDB-managed VXLANs, after configuring one or more logical switches in NSX Manager
or in the NSX API, the NSX controller pushes relevant information to the logical switch
table in the OVSDB schema, which resides on the respective devices.
To determine the state of a VXLAN and corresponding logical switch, you can use the
show ovsdb logical-switch command. The following are possible states:
Created by Controller—A logical switch was configured in NSX Manager or in the NSX
API, but the corresponding VXLAN is not yet created on the Juniper Networks device.
In this state, the VXLAN and corresponding logical switch are not yet operational.
Created by L2ALD—A VXLAN was created, but the corresponding logical switch is not yet
configured in NSX Manager or in the NSX API. In this state, the VXLAN and
corresponding logical switch are not yet operational.
Created by both—A logical switch was configured in NSX Manager or in the NSX API, and
a corresponding VXLAN was created. In this state, the VXLAN and corresponding
logical switch are operational.
Tunnel key mismatch—The VNIs specified in the logical switch and corresponding VXLAN
configurations do not match. In this state, the VXLAN and corresponding logical
switch are not yet operational.
Copyright © 2014, Juniper Networks, Inc.
13
OVSDB and VXLAN Feature Guide
Related
Documentation
•
show ovsdb logical-switch on page 101
•
Troubleshooting a Nonoperational VMware NSX Logical Switch and Corresponding
Junos OS OVSDB-Managed VXLAN on page 131
Open vSwitch Database Schema For Physical Devices
Supported Platforms
MX Series, QFX Series standalone switches
An Open vSwitch Database (OVSDB) server runs on a Juniper Networks device that
supports the OVSDB management protocol. When this device is connected to one or
more VMware NSX controllers, the connections provide a means through which the
Juniper Networks device and the controllers can communicate.
In an NSX multi-hypervisor environment, Juniper Networks devices that support OVSDB
and NSX controllers exchange control and statistical data. This data is stored in the
OVSDB database schema, which was defined for physical devices, and the schema
resides in the OVSDB server. The schema includes several tables. Juniper Networks
devices and NSX controllers, which are both OVSDB clients, can add rows to the tables
as well as monitor for the addition, deletion, and modification of rows.
For example, the OVSDB client on a Juniper Networks device or NSX controller can collect
MAC routes learned by entities in the physical or virtual networks, respectively, and publish
the routes to the appropriate table in the schema. By using the MAC routes and other
information provided in the table, Juniper Networks devices in the physical network and
entities in the virtual network can determine where to forward virtual machine (VM)
traffic.
Some of the OVSDB table names include the words local or remote, for example, the
unicast MACs local table and the unicast MACs remote table. Information in local tables
is learned by a Juniper Networks device that functions as a hardware virtual tunnel
endpoint (VTEP), while information in remote tables is learned from other software or
hardware VTEPs.
Table 7 on page 14 describes the tables in the schema, the physical or virtual entity that
is the source of the data provided in the table, and the command that you can enter in
the CLI of the Juniper Networks device to get similar information.
Table 7: OVSDB Schema Tables
Table Name
Description
Source of Information
Command
Global table
Includes the top-level
configuration for the Juniper
Networks device.
Juniper Networks device
None
Manager table
Includes information for each
NSX controller that is
connected to the Juniper
Networks device.
•
Juniper Networks device
show ovsdb controller
•
NSX controller
14
Copyright © 2014, Juniper Networks, Inc.
Chapter 1: OVSDB Overview
Table 7: OVSDB Schema Tables (continued)
Table Name
Description
Source of Information
Command
Physical switch table
Includes information about
the Juniper Networks device
on which a hardware VTEP is
implemented. This table
includes information only for
the device on which the table
resides.
Juniper Networks device
None
Physical port table
Includes information about
OVSDB-managed interfaces.
Juniper Networks device
show ovsdb interface
Logical switch table
Includes information about
logical switches, which you
configured in NSX Manager or
the NSX API, and the
corresponding Virtual
Extensible LANs (VXLANs),
which was configured on the
Juniper Networks device.
Juniper Networks device
show ovsdb logical-switch
Logical binding statistics
table
Includes statistics for
OVSDB-managed interfaces.
Juniper Networks device
show ovsdb statistics interface
Physical locator table
Includes information about
Juniper Networks devices
configured as hardware
VTEPs, software VTEPs, and
service nodes.
Juniper Networks device
show ovsdb
virtual-tunnel-end-point
Physical locator set table
Includes a list of service nodes
for a logical switch.
Juniper Networks device
None
Unicast MACs remote table
Reachability information,
including unicast MAC
addresses, for entities in the
virtual network.
NSX controller
show ovsdb mac
Unicast MACs local table
Reachability information,
including unicast MAC
addresses, for entities in the
physical network.
Juniper Networks device that
is configured as a hardware
VTEP.
show ovsdb mac
Multicast MACs remote table
Includes only one row. In this
row, the MAC column includes
the keyword unknown dst
along with a list of software
VTEPs that host a cluster of
service nodes, which handle
multicast traffic.
NSX controller
show ovsdb mac
Related
Documentation
•
Understanding the Open vSwitch Database Management Protocol Running on Juniper
Networks Devices on page 6
Copyright © 2014, Juniper Networks, Inc.
15
OVSDB and VXLAN Feature Guide
16
•
Understanding How to Set Up Open vSwitch Database Connections Between Juniper
Networks Devices and Controllers on page 7
•
Understanding How to Set Up Virtual Extensible LANs in an Open vSwitch Database
Environment on page 10
Copyright © 2014, Juniper Networks, Inc.
CHAPTER 2
VXLAN Overview
•
Understanding VXLANs on page 17
•
VXLAN Constraints on QFX5100 Switches on page 22
Understanding VXLANs
Supported Platforms
EX Series, MX Series, QFX Series standalone switches
•
VXLAN Benefits on page 17
•
What is a VXLAN? on page 18
•
Using a QFX5100 Switch with VXLANs on page 19
•
Using an MX Series Router as a VTEP on page 19
•
Manual VXLANs Require PIM on page 20
•
Load Balancing VXLAN Traffic on page 20
•
VXLAN Constraints on QFX5100 Switches on page 21
VXLAN Benefits
Virtual Extensible Local Area Network (VXLAN) is a technology that allows you to segment
your networks (as VLANs do) but that also solves the scaling limitation of VLANs and
provides benefits that VLANs cannot. Here are the most important benefits of using
VXLANs:
•
•
You can theoretically create as many as 16 million VXLANs in an administrative domain
(as opposed to 4094 VLANs on a Juniper Networks device).
•
MX Series routers support as many as 32K VXLANs. This means that VXLANs provide
network segmentation at the scale required by cloud builders to support very large
numbers of tenants.
•
QFX 5100 switches support 4K VXLANs.
You can enable migration of virtual machines between servers that exist in separate
Layer 2 domains by tunneling the traffic over Layer 3 networks. This functionality allows
you to dynamically allocate resources within or between data centers without being
constrained by Layer 2 boundaries or being forced to create large or geographically
stretched Layer 2 domains.
Copyright © 2014, Juniper Networks, Inc.
17
OVSDB and VXLAN Feature Guide
Using VXLANs to create smaller Layer 2 domains that are connected over a Layer 3
network means that you don’t need to use STP to converge the topology but can use
more-robust routing protocols in the Layer 3 network instead. In the absence of STP,
none of your links are blocked, which means you can get full value from all the ports that
you purchase. Using routing protocols to connect your Layer 2 domains also allows you
to load balance the traffic to ensure that you get the best use of your available bandwidth.
Given the amount of east-west traffic that often flows within or between data centers,
maximizing your network performance for that traffic is very important.
The video Why Use an Overlay Network in a Data Center? presents a brief overview of the
advantages of using VXLANs.
Video: Why Use an Overlay Network in a Data Center?
What is a VXLAN?
VXLAN is often described as an overlay technology because it allows you to stretch Layer
2 connections over an intervening Layer 3 network by encapsulating (tunneling) Ethernet
frames in a VXLAN packet that includes IP addresses. The devices that encapsulate
traffic that must be transported over a VXLAN and de-encapsulate traffic when it must
leave the VXLAN tunnel are virtual tunnel endpoints (VTEPs), which can be end hosts
or network switches or routers. To encapsulate an Ethernet frame, VTEPs add a number
of fields, including the following:
•
Outer MAC destination address (MAC address of the tunnel endpoint VTEP)
•
Outer MAC source address (MAC address of the tunnel source VTEP)
•
Outer IP destination address (IP address of the tunnel endpoint VTEP)
•
Outer IP source address (IP address of the tunnel source VTEP)
•
Outer UDP header
•
A VXLAN header that includes a 24-bit field—called the VXLAN network identifier
(VNI)—that is used to uniquely identify the VXLAN. The VNI is similar to a VLAN ID, but
having 24 bits allows you to create many more VXLANs than VLANs.
Figure 3 on page 18 shows the VXLAN packet format.
Figure 3: VXLAN Packet Format
18
Copyright © 2014, Juniper Networks, Inc.
Chapter 2: VXLAN Overview
Using a QFX5100 Switch with VXLANs
You can configure a QFX5100 switch to perform all of the following roles:
•
Act as a transit Layer 3 switch for downstream hosts acting as VTEPs. In this
configuration, you do not need to configure any VXLAN functionality on the switch.
You do need to configure IGMP and PIM so that the switch can form the multicast trees
for the VXLAN multicast groups. (See Manual VXLANs Require PIM on page 20 for
more information.)
•
Act as a Layer 2 gateway between virtualized and non-virtualized networks in the same
data center or between data centers. For example, you can use a QFX5100 switch to
connect a network that uses VXLANs to one that uses VLANs.
•
Act as a Layer 2 gateway between virtualized networks in the same or different data
centers and allow virtual machines to move (VMotion) between those networks and
data centers. For example, if you want to allow VMotion between devices in two
different networks, you can create the same VLAN in both networks and put both
devices on that VLAN. The QFX5100 switches connected to these devices, acting as
VTEPs, can map that VLAN to the same VXLAN, and the VXLAN traffic can then be
routed between the two networks.
NOTE: A QFX 5100 switch cannot route traffic between different VXLANs.
To connect devices in different VXLANs you need a VXLAN-capable Layer 3
gateway, such as a Juniper Networks MX Series router.
Using an MX Series Router as a VTEP
You can configure an MX Series router to act as a VTEP and perform all of the following
roles:
•
Act as a Layer 2 gateway between virtualized and non-virtualized networks in the same
data center or between data centers. For example, you can use an MX Series router to
connect a network that uses VXLANs to one that uses VLANs.
•
Act as a Layer 2 gateway between virtualized networks in the same or different data
centers and allow virtual machines to move (VMotion) between those networks and
data centers.
•
Act as a Layer 3 gateway to route traffic between different VXLANs in the same data
center.
•
Act as a Layer 3 gateway to route traffic between different VXLANs in different data
centers over a WAN or the Internet using standard routing protocols or VPLS tunnels.
NOTE: If you want an MX Series router to be a VXLAN Layer 3 gateway, you
must configure integrated routing and bridging (IRB) interfaces to connect
the VXLANs, just as you do if you want to route traffic between VLANs.
Copyright © 2014, Juniper Networks, Inc.
19
OVSDB and VXLAN Feature Guide
Manual VXLANs Require PIM
You can use a controller (such as VMware’s NSX) to provision VXLANs on a Juniper
Networks device. A controller also provides a control plane that VTEPs use to advertise
their reachability and learn about the reachability of other VTEPs. You can also manually
create VXLANs on Juniper Networks devices instead of using a controller. If you use this
approach, you must also configure PIM on the VTEPs so that they can create VXLAN
tunnels between themselves.
You must also configure each VTEP in a given VXLAN to be a member of the same
multicast group. (If possible, you should assign a different multicast group address to
each VXLAN, though this is not required. Multiple VXLANs can share the same multicast
group.) The VTEPs can then forward ARP requests they receive from their connected
hosts to the multicast group. The other VTEPs in the group de-encapsulate the VXLAN
information, and (assuming they are members of the same VXLAN) they forward the
ARP request to their connected hosts. When the target host receives the ARP request,
it responds with its MAC address, and its VTEP forwards this ARP reply back to the source
VTEP. Through this process, the VTEPs learn the IP addresses of the other VTEPs in the
VXLAN and the MAC addresses of the hosts connected to the other VTEPs.
The multicast groups and trees are also used to forward broadcast, unknown unicast,
and multicast (BUM) traffic between VTEPs. This prevents BUM traffic from being
unnecessarily flooded outside the VXLAN.
NOTE: Multicast traffic that is forwarded through a VXLAN tunnel is sent
only to the remote VTEPs in the VXLAN. That is, the encapsulating VTEP
does not copy and send copies of the packets according to the multicast
tree—it only forwards the received multicast packets to the remote VTEPs.
The remote VTEPs de-encapsulate the encapsulated multicast packets and
forward them the appropriate Layer 2 interfaces. The remote VTEPs also do
not copy and send copies of the packets according to the multicast tree.
Load Balancing VXLAN Traffic
On QFX5100 switches, the Layer 3 routes that form VXLAN tunnels use per-packet load
balancing by default, which means that load balancing is implemented if there are ECMP
paths to the remote VTEP. This is different from normal routing behavior in which
per-packet load balancing is not used by default. (Normal routing uses per-prefix load
balancing by default.)
The source port field in the UDP header is used to enable ECMP load balancing of the
VXLAN traffic in the Layer 3 network. This field is set to a hash of the inner packet fields,
which results in a variable that ECMP can use to distinguish between tunnels (flows).
(None of the other fields that flow-based ECMP normally uses are suitable for use with
VXLANs. All tunnels between the same two VTEPs have the same outer source and
destination IP addresses, and the UDP destination port is set to port 4789 by definition.
Therefore, none of these fields provide a sufficient way for ECMP to differentiate flows.)
20
Copyright © 2014, Juniper Networks, Inc.
Chapter 2: VXLAN Overview
VXLAN Constraints on QFX5100 Switches
Supported Platforms
QFX Series standalone switches
When configuring VXLANs on QFX5100 switches, be aware of the constraints listed
below. In this list, “Layer 3 side” refers to a network-facing interface that performs VXLAN
encapsulation and de-encapsulation, and “Layer 2 side” refers to a server-facing interface
that is a member of a VLAN that is mapped to a VXLAN.
•
QFX 5100 switches support as many as 4K VXLANs.
•
You can use VXLANs on a Virtual Chassis or Virtual Chassis Fabric if all of the members
are QFX5100 switches. You cannot use VXLANs if any of the members are not QFX5100
switches.
•
VXLAN configuration is supported only in the default routing instance.
•
A QFX 5100 switch cannot route traffic between different VXLANs.
•
A physical interface cannot be a member of a VLAN and a VXLAN. That is, an interface
that performs VXLAN encapsulation and de-encapsulation cannot also be a member
of a VLAN.
•
Multichassis link aggregation groups are not supported with VXLAN.
•
IP fragmentation and defragmentation are not supported on the Layer 3 side.
•
The following features are not supported on the Layer 2 side:
•
Related
Documentation
•
STP (any variant)
•
IGMP snooping
•
storm control
Access port security features are not supported with VXLAN. For example, the following
features are not supported:
•
DHCP snooping
•
dynamic ARP inspection
•
MAC limiting and MAC move limiting
•
Ingress node replication is not supported. (You must use PIM to advertise and learn
about reachability if you do not use VMware’s NSX controller.)
•
PIM-BIDIR and PIM-SM are not supported with VXLANs.
•
Examples: Configuring VXLANs on QFX Series Switches on page 51
•
Example: Configuring VXLAN on MX Series Routers on page 42
•
Open vSwitch Database Support on Juniper Networks Devices on page 3
Copyright © 2014, Juniper Networks, Inc.
21
OVSDB and VXLAN Feature Guide
VXLAN Constraints on QFX5100 Switches
Supported Platforms
QFX Series standalone switches
When configuring VXLANs on QFX5100 switches, be aware of the constraints listed
below. In this list, “Layer 3 side” refers to a network-facing interface that performs VXLAN
encapsulation and de-encapsulation, and “Layer 2 side” refers to a server-facing interface
that is a member of a VLAN that is mapped to a VXLAN.
•
QFX 5100 switches support as many as 4K VXLANs.
•
You can use VXLANs on a Virtual Chassis or Virtual Chassis Fabric if all of the members
are QFX5100 switches. You cannot use VXLANs if any of the members are not QFX5100
switches.
•
VXLAN configuration is supported only in the default routing instance.
•
A QFX 5100 switch cannot route traffic between different VXLANs.
•
A physical interface cannot be a member of a VLAN and a VXLAN. That is, an interface
that performs VXLAN encapsulation and de-encapsulation cannot also be a member
of a VLAN.
•
Multichassis link aggregation groups are not supported with VXLAN.
•
IP fragmentation and defragmentation are not supported on the Layer 3 side.
•
The following features are not supported on the Layer 2 side:
•
Related
Documentation
22
•
STP (any variant)
•
IGMP snooping
•
storm control
Access port security features are not supported with VXLAN. For example, the following
features are not supported:
•
DHCP snooping
•
dynamic ARP inspection
•
MAC limiting and MAC move limiting
•
Ingress node replication is not supported. (You must use PIM to advertise and learn
about reachability if you do not use VMware’s NSX controller.)
•
PIM-BIDIR and PIM-SM are not supported with VXLANs.
•
Understanding VXLANs on page 17
•
Examples: Configuring VXLANs on QFX Series Switches on page 51
•
Configuring VXLANs on a QFX5100 Switch on page 69
Copyright © 2014, Juniper Networks, Inc.
PART 2
Configuration
•
Configuration Examples on page 25
•
Configuration Tasks on page 61
•
OVSDB Configuration Statements on page 71
•
VXLAN Configuration Statements on page 83
Copyright © 2014, Juniper Networks, Inc.
23
OVSDB and VXLAN Feature Guide
24
Copyright © 2014, Juniper Networks, Inc.
CHAPTER 3
Configuration Examples
•
Example: Setting Up a VXLAN Layer 2 Gateway and OVSDB Connections Between
Virtual and Physical Entities in a Data Center on page 25
•
Example: Setting Up Inter-VXLAN Routing and OVSDB Connections in a Data
Center on page 33
•
Example: Configuring VXLAN on MX Series Routers on page 42
•
Examples: Configuring VXLANs on QFX Series Switches on page 51
Example: Setting Up a VXLAN Layer 2 Gateway and OVSDB Connections Between
Virtual and Physical Entities in a Data Center
Supported Platforms
QFX Series standalone switches
In a physical network, a Juniper Networks device that supports Virtual Extensible LAN
(VXLAN) can function as a hardware virtual tunnel endpoint (VTEP), which enables
software applications running directly on physical servers to communicate with virtual
machines (VMs) in a virtual network.
In this environment, you can also include VMware NSX controllers and implement the
Open vSwitch Database (OVSDB) management protocol on the Juniper Networks device
that functions as a hardware VTEP. The Junos OS implementation of OVSDB provides
a means through which VMware NSX controllers and Juniper Networks devices that
support OVSDB can communicate. These components serve the following purposes:
•
Centralized configuration (QFX5100 switch only)—After you configure a logical switch,
using NSX Manager or the NSX API, the NSX controller pushes relevant information
about the configuration to the switch (the QFX5100 switch in this example) that
functions as a hardware VTEP. Using the relevant configuration information, the switch
automatically creates the configuration of a VXLAN, which is the Junos OS-equivalent
of the logical switch.
•
Centralized storage and exchange of MAC route information—Availability of MAC routes
enables the hardware VTEP in the physical network and the software VTEP in the
virtual network to forward VM traffic between entities in the physical and virtual
networks.
Copyright © 2014, Juniper Networks, Inc.
25
OVSDB and VXLAN Feature Guide
This example explains how to configure a QFX5100 switch as a hardware VTEP, which
serves as a Layer 2 gateway, and set up this device with an OVSDB connection to an NSX
controller.
•
Requirements on page 26
•
Overview and Topology on page 27
•
Configuration on page 29
•
Verification on page 31
Requirements
The topology for this example includes the following hardware and software components:
•
A physical server on which software applications directly run.
•
A QFX5100 switch that is running Junos OS release 14.1X53-D10 or later and an OVSDB
software package. The OVSDB software package release must be the same as the
Junos OS release running on the device. This switch is configured to function as a
hardware VTEP.
•
A cluster of five NSX controllers, each of which is running NSX software version 4.0.3.
(In this example, you explicitly configure a connection with one NSX controller.)
•
NSX Manager version 4.0.3.
•
A service node that handles the replication and forwarding of Layer 2 broadcast,
unknown unicast, and multicast (BUM) traffic in the VXLAN used in this example.
•
A host that includes VMs managed by a hypervisor, which includes a software VTEP.
Before you begin the configuration, you need to perform the following tasks:
26
•
Using NSX Manager version 4.0.3, specify the IP address of the service node.
•
Create an SSL private key and certificate, and install them in the /var/db/certs directory
of the QFX5100 switch. For more information, see “Creating and Installing an SSL Key
and Certificate on a Juniper Networks Device for Connection with VMware NSX
Controllers” on page 62.
•
Issue the set switch-options ovsdb-managed configuration mode command in the
Junos OS CLI on the QFX5100 switch. Issuing this command and committing the
configuration enable the QFX5100 switch to automatically create OVSDB-managed
VXLANs.
•
For each interface that you want to associate with the OVSDB-managed VXLAN, issue
the set interfaces interface-name unit logical-unit-number family ethernet-switching
interface-mode access configuration mode command in the Junos OS CLI on the
QFX5100 switch. In this example, interface ge-1/0/0.0 is associated with the VXLAN,
so the command is issued once with ge-1/0/0 specified as the interface name and 0
specified as the logical unit number.
•
Using NSX Manager version 4.0.3, configure a logical switch for each VXLAN that
OVSDB will manage. This example implements one OVSDB-managed VXLAN; therefore,
you must configure one logical switch. After you configure the logical switch, the
Copyright © 2014, Juniper Networks, Inc.
Chapter 3: Configuration Examples
QFX5100 switch creates the configuration of a Junos OS-equivalent VXLAN. The name
of the VXLAN is derived from the universally unique identifier (UUID) that the NSX
controller automatically generated for the logical switch. A sample UUID is
28805c1d-0122-495d-85df-19abd647d772.
For more information about logical switches, VXLANs, and the automatic creation of
VXLANs by the QFX5100 switch, see “Understanding How to Set Up Virtual Extensible
LANs in an Open vSwitch Database Environment” on page 10.
For information about using NSX Manager, see the documentation that accompanies
these products.
Overview and Topology
Figure 4 on page 27 shows a topology in which a software application running directly
on Physical Server 1 in the physical network needs to communicate with virtual machine
VM 1 in VXLAN 1 and vice versa. To enable this communication, a QFX5100 switch is
configured as Hardware VTEP 1.
Figure 4: VXLAN/OVSDB Layer 2 Gateway Topology
Based on the configuration of a logical switch in NSX Manager, the QFX5100 switch
automatically creates a configuration for a Junos OS-equivalent VXLAN. A sample
configuration using the UUID of 28805c1d-0122-495d-85df-19abd647d772 is as follows:
set vlans 28805c1d-0122-495d-85df-19abd647d772 vxlan vni 100
set vlans 28805c1d-0122-495d-85df-19abd647d772 vlan-id 75
NOTE: In the sample configuration, the switch automatically generates a
VLAN ID of 75. In general, when generating a VLAN ID, the switch uses a VLAN
ID that is not currently used by either NSX Manager or the NSX API, or by the
QFX5100 switch.
Copyright © 2014, Juniper Networks, Inc.
27
OVSDB and VXLAN Feature Guide
Also, the following command was specified in the Junos OS CLI to configure interface
ge-1/0/0 unit 0:
set interfaces ge-1/0/0 unit 0 family ethernet-switching interface-mode access
The switch automatically associates the interface with the VXLAN as shown:
set interfaces ge-1/0/0 unit 0 family ethernet-switching interface-mode access vlan
members 28805c1d-0122-495d-85df-19abd647d772
NOTE: Keep in mind that you must also configure this interface as
OVSDB-managed in the Junos OS CLI. This example provides information
about performing this step.
The purpose of VXLAN 28805c1d-0122-495d-85df-19abd647d772 is to provide a means
of mapping physical server 1 to VXLAN 1 using VXLAN 1’s VNI of 100.
On the management interface em0 or em1 of the QFX5100 switch, a connection with an
NSX controller is explicitly configured, by using the Junos OS CLI.
Each VXLAN-encapsulated packet must include a source IP address, which identifies
the source hardware or software VTEP, in the outer IP header. In this example, the IP
address of the loopback interface (lo0) on the QFX5100 switch is used for hardware
VTEP 1.
Within VXLAN 28805c1d-0122-495d-85df-19abd647d772, Layer 2 BUM packets are
replicated by the service node, which then forwards the replicas to all interfaces in the
VXLAN. Having the service node handle the Layer 2 BUM traffic is the default behavior,
and no configuration is required on the QFX5100 switch.
In this example, the tracing of all OVSDB events is configured. The output of the OVSDB
events is placed in a file named ovsdb, which is stored in the /var/log directory. By default,
a maximum of 10 trace files can exist, and the configured maximum size of each file is
10 MB.
The components of the topology for this example are shown in Table 8 on page 28.
Table 8: Components of the Topology for Setting Up a VXLAN Layer 2 Gateway and OVSDB
Connections
Property
Settings
OVSDB-managed VXLAN
NOTE: The QFX5100 switch automatically creates this VXLAN configuration,
which is based on the NSX-equivalent logical switch configuration in NSX
Manager. Therefore, no configuration is required.
VXLAN name: 28805c1d-0122-495d-85df-19abd647d772
VLAN ID: 100
VNI: 100 (VXLAN 1)
28
Copyright © 2014, Juniper Networks, Inc.
Chapter 3: Configuration Examples
Table 8: Components of the Topology for Setting Up a VXLAN Layer 2 Gateway and OVSDB
Connections (continued)
Property
Settings
OVSDB-managed interface
Interface name: ge-1/0/0.0
Interface type: access
NOTE: We recommend that you configure this interface in the Junos OS CLI
before you create the logical switch in NSX Manager. After you configure the
logical switch, the NSX controller pushes relevant information to the QFX5100
switch, and the switch automatically associates the interface with the VXLAN.
You must then specify this interface as an OVSDB-managed interface in the
Junos OS CLI.
NSX controller
IP address: 10.94.184.1
Handling of Layer 2 BUM traffic in VXLAN
28805c1d-0122-495d-85df-19abd647d772
Service node
NOTE: By default, one or more service nodes handle Layer 2 BUM traffic in a
VXLAN; therefore, no configuration is required.
Hardware VTEP source identifier
Source interface: loopback (lo0.0)
Source IP address: 10.17.17.17/32
OVSDB tracing operations
Filename: /var/log/ovsdb
File size: 10 MB
Flag: All
Configuration
Perform this task:
•
CLI Quick
Configuration
Configuring the QFX5100 Switch as Hardware VTEP 1 on page 30
To quickly configure this example, copy the following commands, paste them into a text
file, remove any line breaks, change any details necessary to match your configuration,
copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter
commit from configuration mode.
set chassis network-services enhanced-ip
set interfaces ge-1/0/9 unit 0 family inet address 10.40.40.1/24
set routing-options static route 10.19.19.19/32 next-hop 10.40.40.2
set routing-options router-id 10.17.17.17
set protocols ospf area 0.0.0.0 interface lo0.0
set protocols ospf area 0.0.0.0 interface ge-1/0/9.0
set interfaces lo0 unit 0 family inet address 10.17.17.17/32 primary
set interfaces lo0 unit 0 family inet address 10.17.17.17/32 preferred
set switch-options vtep-source-interface lo0.0
set protocols ovsdb traceoptions file ovsdb
set protocols ovsdb traceoptions file size 10m
set protocols ovsdb traceoptions flag all
Copyright © 2014, Juniper Networks, Inc.
29
OVSDB and VXLAN Feature Guide
set protocols ovsdb interfaces ge-1/0/0.0
set protocols ovsdb controller 10.94.184.1
NOTE: After completing this configuration, you must configure a gateway,
which is the NSX-equivalent of a hardware VTEP. This example implements
one hardware VTEP; therefore, you must configure one gateway, a gateway
service, and a logical switch port by using NSX Manager or the NSX API. For
more information about the tasks you must perform and key NSX Manager
configuration details, see “VMware NSX Configuration for Juniper Networks
Devices That Function as Virtual Tunnel Endpoints” on page 64.
Configuring the QFX5100 Switch as Hardware VTEP 1
Step-by-Step
Procedure
To configure a QFX5100 switch as hardware VTEP 1 and with an OVSDB connection to
an NSX controller, follow these steps:
1.
Configure the Layer 3 network.
[edit chassis]
user@switch# set network-services enhanced-ip
[edit interfaces]
user@switch# set ge-1/0/9 unit 0 family inet address 10.40.40.1/24
[edit routing-options]
user@switch# set static route 10.19.19.19/32 next-hop 10.40.40.2
user@switch# set router-id 10.17.17.17
[edit protocols]
user@switch# set ospf area 0.0.0.0 interface lo0.0
user@switch# set ospf area 0.0.0.0 interface ge-1/0/9.0
2.
Specify an IP address for the loopback interface. This IP address serves as the source
IP address in the outer header of any VXLAN-encapsulated packets.
[edit interfaces]
user@switch# set lo0 unit 0 family inet address 10.17.17.17/32 primary
user@switch# set lo0 unit 0 family inet address 10.17.17.17/32 preferred
3.
Set the loopback interface as the interface that identifies hardware VTEP 1.
[edit switch-options]
user@switch# set vtep-source-interface lo0.0
4.
Set up OVSDB tracing operations.
[edit protocols]
user@switch# set ovsdb traceoptions file ovsdb
user@switch# set ovsdb traceoptions file size 10m
user@switch# set ovsdb traceoptions flag all
5.
Specify that the interface between hardware VTEP 1 and physical server 1 is managed
by OVSDB.
[edit protocols]
user@switch# set ovsdb interfaces ge-1/0/0.0
30
Copyright © 2014, Juniper Networks, Inc.
Chapter 3: Configuration Examples
6.
Configure a connection with an NSX controller.
[edit protocols]
user@switch# set ovsdb controller 10.94.184.1
NOTE: After completing this configuration, you must configure a
gateway, which is the NSX-equivalent of a hardware VTEP. This example
implements one hardware VTEP; therefore, you must configure one
gateway, a gateway service, and a logical switch port by using NSX
Manager or the NSX API. For more information about the tasks you must
perform and key NSX Manager configuration details, see “VMware NSX
Configuration for Juniper Networks Devices That Function as Virtual
Tunnel Endpoints” on page 64.
Verification
•
Verifying the Logical Switch on page 31
•
Verifying the MAC Address of VM 1 on page 32
•
Verifying the NSX Controller Connection on page 32
•
Verifying the OVSDB-Managed Interface on page 32
Verifying the Logical Switch
Purpose
Action
Verify that the configuration of the logical switch with the UUID of
28805c1d-0122-495d-85df-19abd647d772 is present in the OVSDB schema for physical
devices and that the state (Flags) of the logical switch is Created by both.
Issue the show ovsdb logical-switch operational mode command.
user@switch> show ovsdb logical-switch
Logical switch information:
Logical Switch Name: 28805c1d-0122-495d-85df-19abd647d772
Flags: Created by both
VNI: 100
Num of Remote MAC: 1
Num of Local MAC: 0
Meaning
The output verifies that the configuration for the logical switch is present. The Created
by both state indicates that the logical switch was configured in NSX Manager, and that
the QFX5100 switch automatically created the corresponding VXLAN. In this state, the
logical switch and VXLAN are operational.
If the state of the logical switch is something other than Created by both, see
“Troubleshooting a Nonoperational VMware NSX Logical Switch and Corresponding
Junos OS OVSDB-Managed VXLAN” on page 131.
Copyright © 2014, Juniper Networks, Inc.
31
OVSDB and VXLAN Feature Guide
Verifying the MAC Address of VM 1
Purpose
Action
Verify that the MAC address of VM 1 is present in the OVSDB schema.
Issue the show ovsdb mac remote operational mode command.
user@switch> show ovsdb mac remote
Logical Switch Name: 28805c1d-0122-495d-85df-19abd647d772
Mac
IP
Encapsulation
Address
Address
a8:59:5e:f6:38:90
0.0.0.0
Vxlan over Ipv4
Meaning
Vtep
Address
10.17.17.17
The output shows that the MAC address for VM 1 is present and is associated with the
logical switch with the UUID of 28805c1d-0122-495d-85df-19abd647d772. Given that
the MAC address is present, VM 1 is reachable through the QFX5100 switch, which
functions as a hardware VTEP.
Verifying the NSX Controller Connection
Purpose
Action
Verify that the connection with the NSX controller is up.
Issue the show ovsdb controller operational mode command, and verify that the controller
connection state is up.
user@switch> show ovsdb controller
VTEP controller information:
Controller IP address: 10.94.184.1
Controller protocol: ssl
Controller port: 6632
Controller connection: up
Controller seconds-since-connect: 542325
Controller seconds-since-disconnect: 542346
Controller connection status: active
Meaning
The output shows that the connection state of the NSX controller is up, in addition to
other information about the controller. By virtue of this connection being up, OVSDB is
enabled on the QFX5100 switch.
Verifying the OVSDB-Managed Interface
Purpose
32
Verify that interface ge-1/0/0.0 is managed by OVSDB.
Copyright © 2014, Juniper Networks, Inc.
Chapter 3: Configuration Examples
Action
Issue the show ovsdb interface operational mode command, and verify that interface
ge-1/0/0.0 is managed by OVSDB.
user@switch> show ovsdb interface
Interface
VLAN ID
ge-1/0/0.0
Meaning
Bridge-domain
The output shows that interface ge-1/0/0.0 is managed by OVSDB and that the VLAN
ID and VLAN are correctly configured.
Example: Setting Up Inter-VXLAN Routing and OVSDB Connections in a Data Center
Supported Platforms
MX Series
This example shows a data center in which virtual machines (VMs) in different Virtual
Extensible LANs (VXLANs) need to communicate. The Juniper Networks device that is
integrated into this environment functions as a hardware virtual tunnel endpoint (VTEP)
that can route VM traffic from one VXLAN (Layer 2) environment to another.
The Juniper Networks device implements the Open vSwitch Database (OVSDB)
management protocol and has a connection with a VMware NSX controller, both of
which enable these two entities to exchange MAC routes to and from VMs in the physical
and virtual networks. .
This example explains how to configure a Juniper Networks device as hardware VTEPs
and set up OVSDB connections to an NSX controller.
•
Requirements on page 33
•
Overview and Topology on page 34
•
Configuration on page 37
•
Verification on page 40
Requirements
In this example, the topology includes the following hardware and software components:
•
A cluster of five NSX controllers, each of which is running NSX software version 4.0.3.
•
NSX Manager.
•
A service node that handles broadcast, unknown unicast, and multicast (BUM) traffic
within each of the two VXLANs.
•
Two hosts, each of which includes VMs managed by a hypervisor. Each hypervisor
includes a software VTEP. The VMs on each of the hosts belong to different VXLANs.
•
A Juniper Networks device that routes VM traffic between the two VXLANs. For example,
an MX Series router running Junos OS Release 14.1R2 or later. The Juniper Networks
device must also run an OVSDB software package, and the release of this package
must be the same as the Junos OS release running on the device. This device is
configured to function as a hardware VTEP.
Copyright © 2014, Juniper Networks, Inc.
33
OVSDB and VXLAN Feature Guide
Before you start the configuration of the Juniper Networks device, you need to perform
the following tasks:
•
In NSX Manager version 4.0.3 or the NSX API, specify the IP address of the service node.
•
In NSX Manager version 4.0.3 or the NSX API, configure a logical switch for each VXLAN
that OVSDB will manage. This example implements two OVSDB-managed VXLANs;
therefore, you must configure two logical switches. After the configuration of each
logical switch, NSX automatically generates a universally unique identifier (UUID) for
the logical switch. If you have not already, retrieve the UUID for each logical switch. A
sample UUID is 28805c1d-0122-495d-85df-19abd647d772. When configuring the
equivalent VXLANs on the Juniper Networks device, you must use the UUID of the
logical switch as the bridge domain or VLAN name.
For more information about logical switches and VXLANs, see “Understanding How
to Set Up Virtual Extensible LANs in an Open vSwitch Database Environment” on
page 10.
•
Create an SSL private key and certificate, and install them in the /var/db/certs directory
of the Juniper Networks device. For more information, see “Creating and Installing an
SSL Key and Certificate on a Juniper Networks Device for Connection with VMware
NSX Controllers” on page 62.
For information about using NSX Manager or the NSX API to perform these configuration
tasks, see the documentation that accompanies these respective products.
Overview and Topology
In the topology shown in Figure 5 on page 35, VM 1 in VXLAN 1 needs to communicate
with VM 3 in VXLAN 2. To enable this communication, hardware VTEP 1, which can be
an MX Series router, is configured to route VM traffic between the two VXLANs.
34
Copyright © 2014, Juniper Networks, Inc.
Chapter 3: Configuration Examples
Figure 5: Inter-VXLAN Routing and OVSDB Topology
On hardware VTEP 1, a routing instance (virtual switch) is set up. Within the routing
instance, two VXLANs are configured: VXLAN 1 and VXLAN 2. Both of the VXLANs are
associated with an integrated routing and bridging (IRB) interface, over which VM traffic
is routed between the VXLANs.
On hardware VTEP 1, a connection with an NSX controller is configured on the
management interface fxp0. This configuration enables the NSX controller to push MAC
routes for VM 1 and VM 3 to the hardware VTEP by way of the table for remote unicast
MAC addresses in the OVSDB schema for physical devices.
Each VXLAN-encapsulated packet must include a source IP address, which identifies
the source hardware or software VTEP, in the outer IP header. In this example, for
hardware VTEP 1, the IP address of the loopback interface (lo0) is used.
Within each of the two VXLANs, a service node replicates Layer 2 BUM packets then
forwards the replicas to all interfaces in the VXLANs. Having the service node handle the
Layer 2 BUM traffic is the default behavior, and no configuration is required for this Juniper
Networks device.
Copyright © 2014, Juniper Networks, Inc.
35
OVSDB and VXLAN Feature Guide
Between the two VXLANs, ingress node replication is automatically implemented and
does not need to be configured. With this feature, hardware VTEP 1 replicates a Layer 3
multicast packet, then the IRB interface associated with the VXLAN that originated the
packet forwards the replicas to all hardware and software VTEPs, but not to service
nodes, in the other OVSDB-managed VXLAN.
In this example, the tracing of all OVSDB events are configured. The output of the OVSDB
events are placed in a file named ovsdb, which is stored in the /var/log directory. By
default, a maximum of 10 trace files can exist, and the configured maximum size of each
file is 50 MB.
Table 8 on page 28 describes the components of the example topology.
Table 9: Components of the Topology for Setting Up Inter-VXLAN Routing and OVSDB
Connections in a Data Center
Property
Settings
Routing instance
Name: vx1
Type: virtual switch
OVSDB-managed VXLANs included: VXLAN 1 and VXLAN 2
VXLAN 1
Bridge domain or VLAN associated with:
28805c1d-0122-495d-85df-19abd647d772
Interface: xe-0/0/2.0
VLAN ID: 100
VNI: 100
IRB for inter-VXLAN traffic: irb.0; 10.20.20.1/24
VXLAN 2
Bridge domain or VLAN associated with:
96a382cd-a570-4ac8-a77a-8bb8b16bde70
Interface: xe-1/2/0.0
VLAN ID: 200
VNI: 200
IRB for inter-VXLAN traffic: irb.1; 10.10.10.3/24
Handling of BUM traffic in each VXLAN
Service node
NOTE: By default, one or more service nodes handle Layer 2
BUM traffic in a VXLAN; therefore, no configuration is required.
Handling of Layer 3 multicast traffic between VXLANs
Ingress node replication
NOTE: On IRB interfaces that forward Layer 3 multicast traffic
from one OVSDB-managed VXLAN to another, ingress node
replication is automatically implemented; therefore, no
configuration is required.
36
Copyright © 2014, Juniper Networks, Inc.
Chapter 3: Configuration Examples
Table 9: Components of the Topology for Setting Up Inter-VXLAN Routing and OVSDB
Connections in a Data Center (continued)
Property
Settings
Hardware VTEP source identifier
Source interface: loopback (lo0.0)
Source IP address: 10.19.19.19/32
NSX controller
IP address: 10.94.184.1
OVSDB tracing operations
Filename: /var/log/ovsdb
File size: 50 m
Flag: All
Configuration
An MX Series router can function as hardware VTEP 1 in this example.
To configure inter-VXLAN routing and OVSDB connections in a data center topology,
you need to perform this task:
•
CLI Quick
Configuration
Configuring an MX Series Router as a Hardware VTEP with an OVSDB
Connection on page 38
To quickly configure this example, copy the following commands, paste them into a text
file, remove any line breaks, change any details necessary to match your configuration,
copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter
commit from configuration mode.
NOTE: After completing this configuration, you must configure a gateway,
which is the NSX-equivalent of a hardware VTEP. This example implements
one hardware VTEP; therefore, you must configure one gateway, a gateway
service, and a logical switch port using NSX Manager or the NSX API. For
more information about the tasks you must perform and key NSX Manager
configuration details, see “VMware NSX Configuration for Juniper Networks
Devices That Function as Virtual Tunnel Endpoints” on page 64.
MX Series router configuration:
set chassis network-services enhanced-ip
set interfaces xe-0/0/3 unit 0 family inet address 10.50.50.2/24
set interfaces ge-1/0/0 unit 0 family inet address 10.100.100.99/24
set routing-options router-id 10.19.19.19
set protocols ospf area 0.0.0.0 interface xe-0/0/3.0
set protocols ospf area 0.0.0.0 interface ge-1/0/0.0
set protocols ospf area 0.0.0.0 interface lo0.0
set interfaces xe-0/0/2 unit 0 family bridge interface-mode access
set interfaces xe-0/0/2 unit 0 family bridge vlan-id 100
Copyright © 2014, Juniper Networks, Inc.
37
OVSDB and VXLAN Feature Guide
set interfaces xe-1/2/0 unit 0 family bridge interface-mode access
set interfaces xe-1/2/0 unit 0 family bridge vlan-id 200
set interfaces irb unit 0 family inet address 10.20.20.1/24
set interfaces irb unit 1 family inet address 10.10.10.3/24
set routing-instances vx1 vtep-source-interface lo0.0
set routing-instances vx1 instance-type virtual-switch
set routing-instances vx1 interface xe-0/0/2.0
set routing-instances vx1 interface xe-1/2/0.0
set routing-instances vx1 bridge-domains 28805c1d-0122-495d-85df-19abd647d772
vlan-id 100
set routing-instances vx1 bridge-domains 28805c1d-0122-495d-85df-19abd647d772
routing-interface irb.0
set routing-instances vx1 bridge-domains 28805c1d-0122-495d-85df-19abd647d772
vxlan ovsdb-managed
set routing-instances vx1 bridge-domains 28805c1d-0122-495d-85df-19abd647d772
vxlan vni 100
set routing-instances vx1 bridge-domains 96a382cd-a570-4ac8-a77a-8bb8b16bde70
vlan-id 200
set routing-instances vx1 bridge-domains 96a382cd-a570-4ac8-a77a-8bb8b16bde70
routing-interface irb.1
set routing-instances vx1 bridge-domains 96a382cd-a570-4ac8-a77a-8bb8b16bde70
vxlan ovsdb-managed
set routing-instances vx1 bridge-domains 96a382cd-a570-4ac8-a77a-8bb8b16bde70
vxlan vni 200
set interfaces lo0 unit 0 family inet address 10.19.19.19/32 primary
set interfaces lo0 unit 0 family inet address 10.19.19.19/32 preferred
set protocols ovsdb traceoptions file ovsdb
set protocols ovsdb traceoptions file size 50m
set protocols ovsdb traceoptions flag all
set protocols ovsdb controller 10.94.184.1
set protocols ovsdb interfaces xe-0/0/2.0
set protocols ovsdb interfaces xe-1/2/0.0
Configuring an MX Series Router as a Hardware VTEP with an OVSDB Connection
Step-by-Step
Procedure
To configure an MX Series router as hardware VTEP 1 with an OVSDB connection to an
NSX controller, follow these steps:
1.
Create the Layer 3 network.
[edit chassis]
user@router# set network-services enhanced-ip
[edit interfaces]
user@router# set xe-0/0/3 unit 0 family inet address 10.50.50.2/24
user@router# set ge-1/0/0 unit 0 family inet address 10.100.100.99/24
[edit routing-options]
user@router# set router-id 10.19.19.19
[edit protocols]
user@router# set ospf area 0.0.0.0 interface xe-0/0/3.0
user@router# set ospf area 0.0.0.0 interface ge-1/0/0.0
user@router# set ospf area 0.0.0.0 interface lo0.0
2.
Create an access interface for VXLAN 1, and associate the interface with the VXLAN.
[edit interfaces]
user@router# set xe-0/0/2 unit 0 family bridge interface-mode access
38
Copyright © 2014, Juniper Networks, Inc.
Chapter 3: Configuration Examples
user@router# set xe-0/0/2 unit 0 family bridge vlan-id 100
3.
Create an access interface for VXLAN 2, and associate the interface with the VXLAN.
[edit interfaces]
user@router# set xe-1/2/0 unit 0 family bridge interface-mode access
user@router# set xe-1/2/0 unit 0 family bridge vlan-id 200
4.
Create an IRB interface to handle inter-VXLAN traffic for VXLAN 1.
[edit interfaces]
user@router# set irb unit 0 family inet address 10.20.20.1/24
5.
Create an IRB interface to handle inter-VXLAN traffic for VXLAN 2.
[edit interfaces]
user@router# set irb unit 1 family inet address 10.10.10.3/24
6.
Set up the virtual switch routing instance.
[edit routing-instances]
user@router# set vx1 vtep-source-interface lo0.0
user@router# set vx1 instance-type virtual-switch
user@router# set vx1 interface xe-0/0/2.0
user@router# set vx1 interface xe-1/2/0.0
user@router# set vx1 bridge-domains 28805c1d-0122-495d-85df-19abd647d772
vlan-id 100
user@router# set vx1 bridge-domains 28805c1d-0122-495d-85df-19abd647d772
routing-interface irb.0
user@router# set vx1 bridge-domains 28805c1d-0122-495d-85df-19abd647d772
vxlan ovsdb-managed
user@router# set vx1 bridge-domains 28805c1d-0122-495d-85df-19abd647d772
vxlan vni 100
user@router# set vx1 bridge-domains 96a382cd-a570-4ac8-a77a-8bb8b16bde70
vlan-id 200
user@router# set vx1 bridge-domains 96a382cd-a570-4ac8-a77a-8bb8b16bde70
routing-interface irb.1
user@router# set vx1 bridge-domains 96a382cd-a570-4ac8-a77a-8bb8b16bde70
vxlan ovsdb-managed
user@router# set vx1 bridge-domains 96a382cd-a570-4ac8-a77a-8bb8b16bde70
vxlan vni 200
7.
Specify an IP address for the loopback interface. This IP address serves as the source
IP address in the outer header of any VXLAN-encapsulated packets.
[edit interfaces]
user@router# set lo0 unit 0 family inet address 10.19.19.19/32 primary
user@router# set lo0 unit 0 family inet address 10.19.19.19/32 preferred
8.
Set up OVSDB tracing operations.
[edit protocols]
user@router# set ovsdb traceoptions file ovsdb
user@router# set ovsdb traceoptions file size 50m
user@router# set ovsdb traceoptions flag all
9.
Configure a connection with an NSX controller.
[edit protocols]
user@router# set ovsdb controller 10.94.184.1
Copyright © 2014, Juniper Networks, Inc.
39
OVSDB and VXLAN Feature Guide
10.
Configure interfaces xe-0/0/2.0 and xe-1/2/0.0 to be managed by OVSDB.
[edit protocols]
user@router# set ovsdb interfaces xe-0/0/2.0
user@router# set ovsdb interfaces xe-1/2/0.0
NOTE: After completing this configuration, you must configure a
gateway, which is the NSX-equivalent of a hardware VTEP. This example
implements one hardware VTEP; therefore, you must configure one
gateway, a gateway service, and a logical switch port by using NSX
Manager or the NSX API. For more information about the tasks you must
perform and key NSX Manager configuration details, see “VMware NSX
Configuration for Juniper Networks Devices That Function as Virtual
Tunnel Endpoints” on page 64.
Verification
•
Verifying the Logical Switches on page 40
•
Verifying the MAC Addresses of VM 1 and VM 3 on page 41
•
Verifying the NSX Controller Connection on page 41
Verifying the Logical Switches
Purpose
Action
Verify that logical switches with the UUIDs of 28805c1d-0122-495d-85df-19abd647d772
and 96a382cd-a570-4ac8-a77a-8bb8b16bde70 are configured in NSX Manager or the
NSX API, and that information about the logical switches is published in the OVSDB
schema.
Issue the show ovsdb logical-switch operational mode command.
user@host> show ovsdb logical-switch
Logical switch information:
Logical Switch Name: 28805c1d-0122-495d-85df-19abd647d772
Flags: Created by both
VNI: 100
Num of Remote MAC: 1
Num of Local MAC: 0
Logical Switch Name: 96a382cd-a570-4ac8-a77a-8bb8b16bde70
Flags: Created by both
VNI: 200
Num of Remote MAC: 1
Num of Local MAC: 1
Meaning
40
The output verifies that information about the logical switches is published in the OVSDB
schema. The Created by both state indicates that the logical switches are configured in
NSX Manager or the NSX API, and the corresponding VXLANs are configured on the
Juniper Networks device. In this state, the logical switches and VXLANs are operational.
Copyright © 2014, Juniper Networks, Inc.
Chapter 3: Configuration Examples
If the state of the logical switches is something other than Created by both, see
“Troubleshooting a Nonoperational VMware NSX Logical Switch and Corresponding
Junos OS OVSDB-Managed VXLAN” on page 131.
Verifying the MAC Addresses of VM 1 and VM 3
Purpose
Action
Verify that the MAC addresses of VM 1 and VM 3 are present in the OVSDB schema.
Issue the show ovsdb mac remote operational mode command, and verify that the MAC
addresses for VM 1 and VM 3 are present.
user@host> show ovsdb mac remote
Logical Switch Name: 28805c1d-0122-495d-85df-19abd647d772
Mac
IP
Encapsulation
Address
Address
08:33:9d:5f:a7:f1
0.0.0.0
Vxlan over Ipv4
Logical Switch Name: 96a382cd-a570-4ac8-a77a-8bb8b16bde70
Mac
IP
Encapsulation
Address
Address
a8:59:5e:f6:38:90
0.0.0.0
Vxlan over Ipv4
Meaning
Vtep
Address
10.19.19.19
Vtep
Address
10.19.19.10
The output shows that the MAC addresses for VM 1 and VM 3 are present and are
associated with logical switches with the UUIDs of
28805c1d-0122-495d-85df-19abd647d772 and
96a382cd-a570-4ac8-a77a-8bb8b16bde70, respectively. Given that the MAC addresses
are present, VM 1 and VM 3 are reachable through hardware VTEP 1.
Verifying the NSX Controller Connection
Purpose
Action
Verify that the connection with the NSX controller is up.
Issue the show ovsdb controller operational mode command, and verify that the controller
connection state is up.
user@host> show ovsdb controller
VTEP controller information:
Controller IP address: 10.94.184.1
Controller protocol: ssl
Controller port: 6632
Controller connection: up
Controller seconds-since-connect: 542325
Controller seconds-since-disconnect: 542346
Controller connection status: active
Meaning
Related
Documentation
The output shows that the connection state of the NSX controller is up, in addition to
other information about the controller. By virtue of this connection being up, OVSDB is
enabled on the Juniper Networks device.
•
Example: Setting Up a VXLAN Layer 2 Gateway and OVSDB Connections Between
Virtual and Physical Entities in a Data Center on page 25
Copyright © 2014, Juniper Networks, Inc.
41
OVSDB and VXLAN Feature Guide
•
Understanding How Layer 2 BUM Traffic and Layer 3 Routed Multicast Traffic Are
Handled in VXLANs Managed by OVSDB on page 8
•
Open vSwitch Database Schema For Physical Devices on page 14
Example: Configuring VXLAN on MX Series Routers
Supported Platforms
MX Series
Virtual Extensible Local Area Network (VXLAN) is a Layer 3 encapsulation protocol that
enables MX Series routers to push Layer 2 or Layer 3 packets through a VXLAN tunnel to
a virtualized data center or the Internet. Communication is established between two
virtual tunnel endpoints (VTEPs). VTEPs encapsulate the virtual machine traffic into a
VXLAN header and strip off the encapsulation.
This example shows how to configure VXLAN on MX Series routers using switch options
in a default bridge domain.
•
Requirements on page 42
•
Overview on page 42
•
Configuring VXLAN on MX Series Routers on page 43
•
Verification on page 49
Requirements
This example uses the following hardware and software components:
•
An MX Series router
•
A VXLAN capable peer router
•
Junos OS Release 14.1
Overview
In this example, VXLAN is configured to run on a default bridge domain. VTEP interfaces
sources are configured to the loopback address, and VLAN groups are configured under
bridge domains with VXLAN enabled. Interfaces are configured for VLAN tagging and
encapsulation, and IRB is enabled. OSPF and PIM protocols are configured to facilitate
unicast and multicast routing. The chassis is configured for GRES and enhanced IP
services.
42
Copyright © 2014, Juniper Networks, Inc.
Chapter 3: Configuration Examples
Topology
Figure 1: VXLAN Topology
Configuring VXLAN on MX Series Routers
CLI Quick
Configuration
To quickly configure this example, copy the following commands, paste them into a text
file, remove any line breaks, change any details necessary to match your network
configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy
level.
set switch-options vtep-source-interface lo0.0
set bridge-domains vlan-5 vxlan vni 100
set bridge-domains vlan-5 vxlan multicast-group 239.1.1.1
set bridge-domains vlan-5 vlan-id 100
set bridge-domains vlan-5 routing-interface irb.0
set bridge-domains vlan-5 interface xe-1/0/0.0
Copyright © 2014, Juniper Networks, Inc.
43
OVSDB and VXLAN Feature Guide
set bridge-domains vlan-6 vxlan vni 200
set bridge-domains vlan-6 vxlan multicast-group 239.1.1.1
set bridge-domains vlan-6 vlan-id 200
set bridge-domains vlan-6 routing-interface irb.1
set bridge-domains vlan-6 interface xe-2/0/0.0
set interfaces xe-1/0/0 vlan-tagging
set interfaces xe-1/0/0 encapsulation flexible-ethernet-services
set interfaces xe-1/0/0 unit 0 encapsulation vlan-bridge
set interfaces xe-1/0/0 unit 0 vlan-id 100
set interfaces xe-2/0/0 vlan-tagging
set interfaces xe-2/0/0 encapsulation flexible-ethernet-services
set interfaces xe-2/0/0 unit 0 encapsulation vlan-bridge
set interfaces xe-2/0/0 unit 0 vlan-id 200
set interface irb unit 0 family inet address 5.5.5.1/24
set interface irb unit 1 family inet address 6.6.6.1/24
set interfaces lo0 unit 0 family inet address 3.3.3.3/32
set protocols ospf area 0.0.0.0 interface ge-8/3/8.0
set protocols ospf area 0.0.0.0 interface lo0.0
set protocols ospf area 0.0.0.0 interface xe-0/1/3.0
set protocols ospf area 0.0.0.0 interface ge-8/3/2.0
set protocols pim rp static address 10.2.1.3
set protocols pim interface lo0.0 mode bidirectional-sparse
set protocols pim interface ge-8/3/8.0 mode bidirectional-sparse
set protocols pim interface xe-0/1/3.0 mode bidirectional-sparse
set protocols pim interface ge-8/3/2.0 mode bidirectional-sparse
set chassis redundancy graceful-switchover
set chassis aggregated-devices ethernet device-count 10
set chassis fpc 1 pic 0 tunnel-services bandwidth 10g
set chassis network-services enhanced-ip
Configuring VXLAN
Step-by-Step
Procedure
The following example show how to set up a basic VXLAN configuration with default
bridge domains and switch options. To configure VXLAN on an MX Series router, follow
these steps:
1.
Configure VTEP interface sources under switch-options for the default-switch.
[edit]
user@router# set switch-options vtep-source-interface lo0.0
2.
Set up a VLAN group named vlan-5 and set its VXLAN Network Identifier (VNI) to
100.
[edit]
user@router# set bridge-domains vlan-5 vxlan vni 100
3.
Configure the vlan-5 multicast group address for VXLAN.
[edit]
user@router# set bridge-domains vlan-5 vxlan multicast-group 239.1.1.1
4.
Set the VLAN ID to 100 for vlan-5.
[edit]
user@router# set bridge-domains vlan-5 vlan-id 100
44
Copyright © 2014, Juniper Networks, Inc.
Chapter 3: Configuration Examples
5.
Configure integrated bridging and routing (IRB) for vlan-5.
[edit]
user@router# set bridge-domains vlan-5 routing-interface irb.0
6.
Assign the xe-1/0/0.0 interface to vlan-5.
[edit]
user@router# set bridge-domains vlan-5 interface xe-1/0/0.0
7.
Set up a VLAN group named vlan-6 and set its VXLAN Network Identifier (VNI) to
200.
[edit]
user@router# set bridge-domains vlan-6 vxlan vni 200
8.
Configure the vlan-6 multicast group address for VXLAN.
[edit]
user@router# set bridge-domains vlan-6 vxlan multicast-group 239.1.1.1
9.
Set the VLAN ID to 100 for vlan-6.
[edit]
user@router# set bridge-domains vlan-6 vlan-id 200
10.
Configure IRB for vlan-6.
[edit]
user@router# set bridge-domains vlan-6 routing-interface irb.1
11.
Assign the xe-2/0/0.0 interface to vlan-6.
[edit]
user@router# set bridge-domains vlan-6 interface xe-2/0/0.0
12.
Set up VLAN tagging for xe-1/0/0.
[edit]
user@router# set interfaces xe-1/0/0 vlan-tagging
13.
Configure flexible Ethernet service encapsulation on xe-1/0/0.
[edit]
user@router# set interfaces xe-1/0/0 encapsulation flexible-ethernet-services
14.
Set up VLAN bridging encapsulation for xe-1/0/0 unit 0˙.
[edit]
user@router# set interfaces xe-1/0/0 unit 0 encapsulation vlan-bridge
15.
Set the xe-1/0/0 unit 0 VLAN ID to 100.
[edit]
user@router# set interfaces xe-1/0/0 unit 0 vlan-id 100
16.
Configure VLAN tagging for xe-2/0/0
[edit]
user@router# set interfaces xe-2/0/0 vlan-tagging
Copyright © 2014, Juniper Networks, Inc.
45
OVSDB and VXLAN Feature Guide
17.
Set up flexible Ethernet service encapsulation on xe-2/0/0.
[edit]
user@router# set interfaces xe-2/0/0 encapsulation flexible-ethernet-services
18.
Configure VLAN bridging encapsulation for xe-2/0/0 unit 0˙.
[edit]
user@router# set interfaces xe-2/0/0 unit 0 encapsulation vlan-bridge
19.
Set the xe-2/0/0 unit 0 VLAN ID to 200.
[edit]
user@router# set interfaces xe-2/0/0 unit 0 vlan-id 200
20.
Configure the IRB unit 0 family inet address.
[edit]
user@router# set interface irb unit 0 family inet address 5.5.5.1/24
21.
Configure the IRB unit 1 family inet address.
[edit]
user@router# set interface irb unit 1 family inet address 6.6.6.1/24
22.
Set the family inet address for the loopback unit 0.
[edit]
user@router# set interfaces lo0 unit 0 family inet address 3.3.3.3/32
23.
Set up OSPF for the ge-8/3/8.0 interface.
[edit]
user@router# set protocols ospf area 0.0.0.0 interface ge-8/3/8.0
24.
Configure OSPF for the loopback interface.
[edit]
user@router# set protocols ospf area 0.0.0.0 interface lo0.0
25.
Set up OSPF for the xe-0/1/3.0 interface.
[edit]
user@router# set protocols ospf area 0.0.0.0 interface xe-0/1/3.0
26.
Configure OSPF for the ge-8/3/2.0 interface.
[edit]
user@router# set protocols ospf area 0.0.0.0 interface ge-8/3/2.0
27.
Set up the static address for the physical interface module (PIM) rendezvous point
(RP).
[edit]
user@router# set protocols pim rp static address 10.2.1.3
28.
Configure the loopback interface to bidirectional sparse mode for the PIM protocol.
[edit]
user@router# set protocols pim interface lo0.0 mode bidirectional-sparse
46
Copyright © 2014, Juniper Networks, Inc.
Chapter 3: Configuration Examples
29.
Set the ge-8/3/8.0 interface to bidirectional sparse mode for the PIM protocol.
[edit]
user@router# set protocols pim interface ge-8/3/8.0 mode bidirectional-sparse
30.
Configure the xe-0/1/3.0 interface to bidirectional sparse mode for the PIM protocol.
[edit]
user@router# set protocols pim interface xe-0/1/3.0 mode bidirectional-sparse
31.
Set the ge-8/3/2.0 interface to bidirectional sparse mode for the PIM protocol.
[edit]
user@router# set protocols pim interface ge-8/3/2.0 mode bidirectional-sparse
32.
Configure redundant graceful switchover on the chassis.
[edit]
user@router# set chassis redundancy graceful-switchover
33.
Set the aggregated ethernet device count to 10.
[edit]
user@router# set chassis aggregated-devices ethernet device-count 10
34.
Configure the tunnel services bandwidth for FPC 1/PIC 0.
[edit]
user@router# set chassis fpc 1 pic 0 tunnel-services bandwidth 10g
35.
Enable enhanced IP for network services on the chassis.
[edit]
user@router# set chassis network-services enhanced-ip
Results
From configuration mode, confirm your configuration by entering the following commands.
If the output does not display the intended configuration, repeat the instructions in this
example to correct the configuration.
user@router# show switch-options
switch-options {
vtep-source-interface lo0.0;
}
user@router# show bridge-domains
bridge-domains {
vlan-5 {
vxlan {
vni 100;
multicast-group 239.1.1.1;
}
vlan-id 100;
routing-interface irb.0;
interface xe-1/0/0.0;
}
Copyright © 2014, Juniper Networks, Inc.
47
OVSDB and VXLAN Feature Guide
vlan-6 {
vxlan {
vni 200;
multicast-group 239.2.1.1;
}
vlan-id 200;
routing-interface irb.1;
interface xe-2/0/0.0;
}
}
user@router# show interfaces
interfaces {
xe-1/0/0 {
vlan-tagging;
encapsulation flexible-ethernet-services;
unit 0 {
encapsulation vlan-bridge;
vlan-id 100;
}
}
xe-2/0/0 {
vlan-tagging;
encapsulation flexible-ethernet-services;
unit 0 {
encapsulation vlan-bridge;
vlan-id 200;
}
}
irb {
unit 0 {
family inet {
address 5.5.5.1/24;
}
}
unit 1 {
family inet {
address 6.6.6.1/24;
}
}
}
lo0 {
unit 0 {
family inet {
address 3.3.3.3/32;
}
}
}
}
user@router# show protocols ospf
area 0.0.0.0 {
interface ge-8/3/8.0;
interface lo0.0;
interface xe-0/1/3.0;
interface ge-8/3/2.0;
48
Copyright © 2014, Juniper Networks, Inc.
Chapter 3: Configuration Examples
}
user@router# show protocols pim
rp {
static {
address 10.2.1.3;
}
}
user@router# show chassis
redundancy {
graceful-switchover;
}
aggregated-devices {
ethernet {
device-count 10;
}
}
fpc 1 {
pic 0 {
tunnel-services {
bandwidth 10g;
}
}
}
network-services enhanced-ip;
Verification
Confirm that the configuration is working properly.
•
Verifying Reachability on page 49
•
Verifying VXLAN on page 50
Verifying Reachability
Purpose
Verify that the network is up and running with the proper interfaces and routes installed.
Copyright © 2014, Juniper Networks, Inc.
49
OVSDB and VXLAN Feature Guide
Action
user@router> show interfaces terse irb
Interface
Admin Link Proto
Local
irb
up
up
irb.0
up
up
inet
5.5.5.1/24
multiservice
irb.1
up
up
inet
6.6.6.1/24
multiservice
Remote
user@router> ping 5.5.5.1/24
PING 5.5.5.1 (5.5.5.1): 56 data bytes
64 bytes from 5.5.5.1: icmp_seq=0 ttl=64 time=0.965 ms
64 bytes from 5.5.5.1: icmp_seq=1 ttl=64 time=0.960 ms
64 bytes from 5.5.5.1: icmp_seq=2 ttl=64 time=0.940 ms
^C
--- 1.1.1.1 ping statistics --3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.940/0.955/0.965/0.011 ms
Meaning
Use the show interfaces terse irb command to verify that the IRB interface has been
properly configured. The irb.0 and irb.1 interfaces should display the proper multiservice
inet addresses.
Use the ping command to confirm that the network is connected to the IRB multiservice
address.
Verifying VXLAN
Purpose
50
Verify that VXLAN is working and the proper protocols are enabled.
Copyright © 2014, Juniper Networks, Inc.
Chapter 3: Configuration Examples
Action
user@router> show interfaces vtep
Physical interface: vtep, Enabled, Physical link is Up
Interface index: 133, SNMP ifIndex: 575
Type: Software-Pseudo, Link-level type: VxLAN-Tunnel-Endpoint, MTU: 1600, Speed:
Unlimited
Device flags
: Present Running
Interface flags: SNMP-Traps
Link type
: Full-Duplex
Link flags
: None
Last flapped
: Never
Input packets : 0
Output packets: 0
Logical interface vtep.32768 (Index 334) (SNMP ifIndex 607)
Flags: Up SNMP-Traps Encapsulation: ENET2
VXLAN Endpoint Type: Source, VXLAN Endpoint Address: 10.255.187.32, L2 Routing
Instance: default-switch, L3 Routing Instance: default
Input packets : 0
Output packets: 0
user@router> show l2-learning vxlan-tunnel-end-point remote mac-table
MAC flags (S -static MAC, D -dynamic MAC, L -locally learned, C -Control MAC
SE -Statistics enabled, NM -Non configured MAC, R -Remote PE MAC)
Logical system
Routing instance
Bridging domain
Bridging domain
:
:
:
:
<default>
default-switch
vlan-5+100, VLAN : 100, VNID : 100
vlan-6+200, VLAN : 200, VNID : 200
user@router> show l2-learning vxlan-tunnel-end-point source
Logical System Name
Id SVTEP-IP
IFL
L3-Idx
<default>
0
10.255.187.32
lo0.0
0
L2-RTT
Bridge Domain
VNID
default-switch
vlan-5+100
100
default-switch
Meaning
vlan-6+200
200
MC-Group-IP
239.1.1.1
239.1.1.1
Use the show interface vtep command to displays information about VXLAN endpoint
configuration. Make sure the routing instance is assigned to the default-switch..
Use the show l2-learning vxlan-tunnel-end-point remote mac-table command to confirm
that the bridging domain VLAN groups were configured correctly.
Use the show l2-learning vxlan-tunnel-end-point source command to confirm the multicast
IP addresses for bridging domain VLAN groups.
Related
Documentation
•
Understanding VXLANs on page 17
•
show bridge mac-table on page 92
•
show vpls mac-table on page 111
Examples: Configuring VXLANs on QFX Series Switches
Supported Platforms
QFX Series standalone switches
Copyright © 2014, Juniper Networks, Inc.
51
OVSDB and VXLAN Feature Guide
These examples show how to configure VXLANs on QFX Series Switches for several use
cases.
•
Example: Configuring a VXLAN Transit Switch on page 52
•
Example: Configuring a VXLAN Layer 2 Gateway on page 53
Example: Configuring a VXLAN Transit Switch
Supported Platforms
QFX Series standalone switches
If a QFX switch acts as a transit switch for downstream devices acting as VTEPs, you do
not need to configure any VXLAN information on the QFX switch. You do need to configure
PIM on the switch so that it can form the multicast tree required so that the VTEPs can
establish reachablity with each other.
•
Requirements on page 52
•
Overview on page 52
•
Configuring PIM on the Transit Switches on page 53
Requirements
This example uses the following hardware and software components:
•
Two QFX5100 switches
•
Junos OS 14.1X53-D10
Overview
This example shows a simple use case in which QFX switches are connected to
downstream servers acting as VTEPs and need to forward VXLAN packets between VM
1 on Server 1 and VM 2 on Server 2. Because this configuration allows Layer 2 connectivity
between the VMs through the VXLAN tunnels, applications can VMotion between the
VMs.
Topology
Figure 6 on page 53 shows a QFX 5100 switch configured to forward VXLAN packets for
downstream VTEPs.
52
Copyright © 2014, Juniper Networks, Inc.
Chapter 3: Configuration Examples
Figure 6: QFX5100 Acting as a VXLAN Transit Switch
Configuring PIM on the Transit Switches
CLI Quick
Configuration
To quickly configure this example, copy the following commands, paste them into a text
file, remove any line breaks, change any details necessary to match your network
configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy
level.
set protocols pim interface all
set protocols pim rp static address ip-address
Step-by-Step
Procedure
If you are not using a controller to create a VXLAN control plane, you must enable PIM
on each switch so that the VTEP can use multicast groups to advertise its existence and
to learn about other VTEPs. (Configuring PIM automatically enables IGMP.) You do not
need to perform any VXLAN-specific configuration. Note that you also do not need to
configure VLAN 1 or 2 on either switch.
1.
Enable PIM:
[edit]
user@switch# set protocols pim interface all
2.
Configure the address of a PIM rendezvous point:
[edit]
user@switch# set protocols pim rp static address ip-address
Example: Configuring a VXLAN Layer 2 Gateway
Supported Platforms
QFX Series standalone switches
Copyright © 2014, Juniper Networks, Inc.
53
OVSDB and VXLAN Feature Guide
If a QFX switch is connected to a downstream server that hosts a VM that needs Layer
2 connectivity with another VM that is reachable only through a Layer 3 network, you
must configure the switch to act as a VTEP—that is, a Layer 2 gateway for downstream
Layer 2 devices. You also need to configure PIM on the switch so that it can form the
multicast tree required for reachability with other VTEPs and to allow BUM traffic to be
forwarded between the VTEPs.
•
Requirements on page 54
•
Overview on page 54
•
Configuring the Switches on page 55
•
Verification on page 58
Requirements
This example uses the following hardware and software components:
•
Two QFX5100 switches
•
Junos OS 14.1X53-D10
Overview
This example shows a use case in which QFX switches are connected to downstream
VTEPs and need to allow Layer 2 connectivity between VM 1 on Server 1 and VM 2 on
Server 2 so that VMotion can occur between the VMs. The servers in this example can
be in the same or different data centers—the only constraint is that there must be Layer
3 connectivity between the QFX switches. This allows your network to be very agile in
response to demand for server usage or changes in bandwidth requirements.
Note that because the same VLAN exists in both Layer 2 domains and both switches
encapsulate the VLAN traffic into the same VXLAN, you do not need a gateway for the
VXLAN traffic in the Layer 3 network. The Layer 3 VXLAN packets are routed normally
and no de-encapsulation or re-encapsulation is required..
Topology
Figure 7 on page 55 shows a QFX 5100 switch configured to act as a VTEP.
54
Copyright © 2014, Juniper Networks, Inc.
Chapter 3: Configuration Examples
Figure 7: QFX5100 Acting as a VTEP
Configuring the Switches
CLI Quick
Configuration
To quickly configure the QFX5100-96S 1 in this example, copy the following commands,
paste them into a text file, remove any line breaks, change any details necessary to match
your network configuration, and then copy and paste the commands into the CLI at the
[edit] hierarchy level.
set interfaces lo0 unit 0 family inet address 10.1.1.1
set switch-options vtep–source-interface lo0.0
set protocols pim interface xe-0/0/0.0
set protocols pim rp static address 10.2.2.2
set vlans VLAN1 vlan-id 100 vxlan vni 100 multicast-group 234.1.2.3
set vlans VLAN1 vxlan encapsulate-inner-vlan
set vlans VLAN1 vxlan decapsulate-inner-vlan
set vlans VLAN1 vxlan unreachable-vtep-aging-timer 600
set interfaces xe-0/0/0 unit 0 family inet address 10.2.2.100/24
set interfaces xe-0/0/1 unit 0 family ethernet-switching interface-mode trunk
set interfaces xe-0/0/1 unit 0 family ethernet-switching vlan members all
The configuration for QFX5100-96S 2 is almost identical. The only changes a few of the
addresses:
set interfaces lo0 unit 0 family inet address 10.1.1.2
set switch-options vtep–source-interface lo0.0
set protocols pim interface xe-0/0/0.0
set protocols pim rp static address 10.2.2.2
set vlans VLAN1 vlan-id 100 vxlan vni 100 multicast-group 234.1.2.3
set vlans VLAN1 vxlan encapsulate-inner-vlan
set vlans VLAN1 vxlan decapsulate-inner-vlan
set vlans VLAN1 vxlan unreachable-vtep-aging-timer 600
Copyright © 2014, Juniper Networks, Inc.
55
OVSDB and VXLAN Feature Guide
set interfaces xe-0/0/0 unit 0 family inet address 10.2.2.200/24
set interfaces xe-0/0/1 unit 0 family ethernet-switching interface-mode trunk
set interfaces xe-0/0/1 unit 0 family ethernet-switching vlan members all
NOTE: You must configure the same multicast group address for VLAN1 on
both switches.
Step-by-Step
Procedure
Perform the following procedure on both switches to set up the example configuration.
Note that you do not need to configure VLAN 1 or 2 on either switch.
1.
Create a reachable IPv4 address on the loopback interface.
[edit]
user@switch# set interfaces lo0.0 unit 0 family inet address 10.1.1.1
For switch QFX5100-96S 2, use address 10.1.1.2.
2.
Configure the loopback interface—and therefore, its associated address—to be
used as the tunnel source address:
[edit]
user@switch# set switch-options vtep-source-interface lo0.0
3.
Enable PIM on the interface that connects to the Layer 3 network:
[edit]
user@switch# set protocols pim interface xe-0/0/0.0
4.
Configure the address of a PIM rendezvous point:
[edit]
user@switch# set protocols pim rp static address 10.2.2.2
5.
Create a VLAN, map it to a VXLAN, and assign a multicast group address to the
VXLAN. All members of a VXLAN must use the same multicast group address:
[edit]
user@switch# set vlans VLAN1 vlan-id 100 vxlan vni 100 multicast-group 234.1.2.3
In this example, the vlan-id and vni are both set to 100. This is done only for simplicity
and clarity. You do not need to set the vlan-id and vni to the same value.
6.
(Optional) Configure the switch to retain the original VLAN tag (in the inner Ethernet
packet) after VXLAN encapsulation. By default, the original tag is dropped when
the packet is encapsulated:
[edit]
user@switch# set vlans VLAN1 vxlan encapsulate-inner-vlan
7.
(Optional) Configure the switch to de-encapsulate and accept original VLAN tags
in VXLAN packets. By default, a preserved VLAN tag is dropped when the packet is
de-encapsulated:
[edit]
user@switch# set vlans VLAN1 vxlan decapsulate-accept-inner-vlan
(Optional) Configure the system to age out the address for the remote VTEP (the
other QFX5100 switch) if all the MAC addresses learned from that VTEP age out.
The address for the remote VTEP expires the configured number of seconds after
the last learned MAC address expires.
[edit]
56
Copyright © 2014, Juniper Networks, Inc.
Chapter 3: Configuration Examples
user@switch# set vlans VLAN1 vxlan unreachable-vtep-aging-timer 600
8.
Configure the interface that connects to the Layer 3 network:
[edit]
user@switch# set interfaces xe-0/0/0 unit 0 family inet address 10.2.2.100/24
For switch QFX5100-96S 2, use address 10.2.2.200.
9.
Configure the server-facing interface to support multiple VLANs:
[edit]
user@switch# set interfaces xe-0/0/1 unit 0 family ethernet-switching interface-mode
trunk
[edit]
user@switch# set interfaces xe-0/0/1 unit 0 family ethernet-switching vlan members all
NOTE: Because this example shows only one VLAN, this step is not
required for the example. In a real-world configuration, however, it would
be required in order to support multiple VMs connected to multiple
VLANs. In this case you would also need to configure additional VLAN
to VXLAN mappings.
Results
From configuration mode, confirm your configuration by entering the following commands
on QFX5100-96S 1. If the output does not display the intended configuration, repeat the
instructions in this example to correct the configuration.
user@switch# show switch-options
vtep-source-interface lo0.0;
user@switch# show vlans
VLAN1 {
vlan-id 100;
vxlan {
vni 100;
multicast-group 234.1.2.3;
encapsulate-inner-vlan;
}
}
user@switch# show interfaces
xe-0/0/0 {
unit 0 {
family inet {
address 10.2.2.100/24;
}
}
}
xe-0/0/1 {
unit 0 {
family ethernet-switching {
interface-mode trunk;
vlan {
Copyright © 2014, Juniper Networks, Inc.
57
OVSDB and VXLAN Feature Guide
members all;
}
}
}
}
lo0 {
unit 0 {
family inet {
address 10.1.1.1/32;
}
}
}
user@switch# show protocols pim
rp {
static {
address 10.2.2.2;
}
}
interface xe-0/0/0.0
Verification
Confirm that the configuration is working properly.
•
Verifying VXLAN Reachability on page 58
•
Verifying That the Local VTEP is Configured Correctly on page 58
•
Verifying MAC Learning from the Remote VTEP on page 59
•
Monitor the Remote Interface on page 59
Verifying VXLAN Reachability
Purpose
Action
Meaning
On QFX5100-96S 1, verify that there is connectivity with the remote VTEP (QFX5100-96S
2).
user@switch> show ethernet-switching vxlan-tunnel-end-point remote
Logical System Name
Id SVTEP-IP
IFL
L3-Idx
<default>
0
10.1.1.2
lo0.0
0
RVTEP-IP
IFL-Idx
NH-Id
10.1.1.2
559
1728
VNID
MC-Group-IP
100
234.1.2.3
The VTEP on QFX5100-96S 2 is reachable because its IP address (the address assigned
to the loopback interface) appears in the output. The output also shows that the VXLAN
(VNI 100) and corresponding multicast group are configured correctly on the remote
VTEP.
Verifying That the Local VTEP is Configured Correctly
Purpose
58
On QFX5100-96S 1, verify that the tunnel endpoint is correct..
Copyright © 2014, Juniper Networks, Inc.
Chapter 3: Configuration Examples
Action
user@switch> show ethernet-switching vxlan-tunnel-end-point source
Logical System Name
<default>
L2-RTT
default-switch
Meaning
Id SVTEP-IP
0
10.1.1.1
Bridge Domain
VLAN1+100
IFL
lo0.0
L3-Idx
0
VNID
100
MC-Group-IP
234.1.2.3
The VTEP on QFX5100-96S 1 shows the correct tunnel source IP address (assigned to
the loopback interface), VLAN, and multicast group for the VXLAN.
Verifying MAC Learning from the Remote VTEP
Purpose
Action
On QFX5100-96S 1, verify that it is learning MAC addresses from the remote VTEP.
user@switch> show ethernet-switching table
MAC flags (S - static MAC, D - dynamic MAC, L - locally learned, P - Persistent
static
SE - statistics enabled, NM - non configured MAC, R - remote PE MAC)
Ethernet switching table : 2 entries, 2 learned
Routing instance : default-switch
Vlan
MAC
MAC
Age
Logical
name
address
flags
interface
VLAN1
00:00:00:ff:ff:ff
D
vtep.12345
VLAN1
00:10:94:00:00:02
D
xe-0/0/0.0
Meaning
This shows the MAC addresses learned from the remote VTEP (in addition to those
learned on the normal Layer 2 interfaces). It also shows the logical name of the remote
VTEP interface (vtep.12345 in the above output).
Monitor the Remote Interface
Purpose
On QFX5100-96S 1, monitor traffic details for the remote VTEP interface.
Copyright © 2014, Juniper Networks, Inc.
59
OVSDB and VXLAN Feature Guide
Action
user@switch> show interface vtep.12345 detail
M
Flags: Up SNMP-Traps Encapsulation: ENET2
VXLAN Endpoint Type: Remote, VXLAN Endpoint Address: 10.1.1.2, L2 Routing
Instance: default-switch, L3 Routing Instance: default
Traffic statistics:
Input bytes :
228851738624
Output bytes :
0
Input packets:
714162415
Output packets:
0
Local statistics:
Input bytes :
0
Output bytes :
0
Input packets:
0
Output packets:
0
Transit statistics:
Input bytes :
228851738624
0 bps
Output bytes :
0
0 bps
Input packets:
714162415
0 pps
Output packets:
0
0 pps
Protocol eth-switch, MTU: 1600, Generation: 277, Route table: 5
Meaning
Related
Documentation
60
This shows traffic details for the remote VTEP interface. To get this information, you
must supply the logical name of the remote VTEP interface (vtep.12345 in the above
output), which you can learn by using the show ethernet-switching table command.
•
Understanding VXLANs on page 17
Copyright © 2014, Juniper Networks, Inc.
CHAPTER 4
Configuration Tasks
•
Installing Open vSwitch Database Components on Juniper Networks Devices on page 61
•
Creating and Installing an SSL Key and Certificate on a Juniper Networks Device for
Connection with VMware NSX Controllers on page 62
•
Setting Up the Open vSwitch Database Management Protocol on Juniper Networks
Devices on page 63
•
VMware NSX Configuration for Juniper Networks Devices That Function as Virtual
Tunnel Endpoints on page 64
•
Configuring OVSDB-Managed VXLANs on page 66
•
Configuring VXLANs on a QFX5100 Switch on page 69
Installing Open vSwitch Database Components on Juniper Networks Devices
Supported Platforms
MX Series, QFX Series standalone switches
To install Open vSwitch Database (OVSDB) components on a Juniper Networks device,
you must copy the OVSDB software package to the Juniper Networks device and then
install the package. The OVSDB software package name uses the following format:
jsdn-packageID-release
where:
•
packageID identifies the package that should run on each Juniper Networks device.
•
release identifies the OVSDB release; for example, 14.1R2. The OVSDB software release
and the Junos OS release running on the device must be the same.
For information about OVSDB support on Juniper Networks devices and the software
package for each device, see “Open vSwitch Database Support on Juniper Networks
Devices” on page 3.
To install the OVSDB software package on a Juniper Networks device:
1.
Download the software package to the Juniper Networks device.
2. If an OVSDB software package already exists on the Juniper Networks device, remove
the package by issuing the request system software delete operational mode command.
user@device> request system software delete existing-ovsdb-package
Copyright © 2014, Juniper Networks, Inc.
61
OVSDB and VXLAN Feature Guide
3. Install the new software package by using the request system software add operational
mode command.
user@device> request system software add path-to-ovsdb-package
Related
Documentation
•
Understanding the Open vSwitch Database Management Protocol Running on Juniper
Networks Devices on page 6
Creating and Installing an SSL Key and Certificate on a Juniper Networks Device for
Connection with VMware NSX Controllers
Supported Platforms
MX Series, QFX Series standalone switches
To secure a connection between a Juniper Networks device that supports the Open
vSwitch Database (OVSDB) management protocol and one or more VMware NSX
controllers, the following Secure Sockets Layer (SSL) files must be present in the
/var/db/certs directory on the device:
•
vtep-privkey.pem
•
vtep-cert.pem
•
ca-cert.pem
You must create the vtep-privkey.pem and vtep-cert.pem files for the device, and then
install the two files in the /var/db/certs directory on the device.
Upon the initial connection between a Juniper Networks device with OVSDB implemented
and an NSX controller, the ca-cert.pem file is automatically generated, and then installed
in the /var/db/certs directory on the device.
The procedure provided in this topic uses the OpenFlow public key infrastructure (PKI)
management utility ovs-pki on a Linux computer to initialize a public key infrastructure
(PKI) and create the vtep-privkey.pem and vtep-cert.pem files. (If you have an existing
PKI on your Linux computer, you can skip the step to initialize a new one.) By default, the
utility initializes the PKI and places these files in the /usr/local/share/openvswitch/pki
directory of the Linux computer.
To create and install an SSL key and certificate on a Juniper Networks device:
1.
Initialize a PKI if one does not already exist on your Linux computer.
# ovs-pki init
2. On the same Linux computer on which the PKI exists, create a new key and certificate
for the Juniper Networks device.
# ovs-pki req+sign vtep
3. Copy only the vtep-privkey.pem and vtep-cert.pem files from the Linux computer to
the /var/db/certs directory on the Juniper Networks device.
Related
Documentation
62
•
Understanding How to Set Up Open vSwitch Database Connections Between Juniper
Networks Devices and Controllers on page 7
Copyright © 2014, Juniper Networks, Inc.
Chapter 4: Configuration Tasks
•
Setting Up the Open vSwitch Database Management Protocol on Juniper Networks
Devices on page 63
Setting Up the Open vSwitch Database Management Protocol on Juniper Networks
Devices
Supported Platforms
MX Series, QFX Series standalone switches
To implement the Open vSwitch Database (OVSDB) management protocol on a Juniper
Networks device, you must explicitly configure a connection to at least one VMware NSX
controller, using the Junos OS CLI.
All NSX controller connections are made on the management interface (fxp0, em0, or
em1) of the Juniper Networks device. This connection is secured by using the Secure
Sockets Layer (SSL) protocol. The default port number over which the connection is
made is 6632.
You must also specify that any interface with a physical server is managed by OVSDB.
By performing this configuration, you are essentially disabling the Juniper Networks device
from learning about other Juniper Networks devices that function as hardware virtual
tunnel endpoints (VTEPs) and the MAC addresses learned by the hardware VTEPs, and
enabling OVSDB to learn about these elements.
Before setting up OVSDB on a Juniper Networks device, you must do the following:
•
Ensure that the Juniper Networks device has an OVSDB software package installed,
and that the OVSDB software package release is the same as the Junos OS release
running on the device.
•
Determine the IP address of the NSX controller.
•
Create an SSL private key and certificate, and install them in the /var/db/certs directory
of the Juniper Networks device. For more information, see “Creating and Installing an
SSL Key and Certificate on a Juniper Networks Device for Connection with VMware
NSX Controllers” on page 62.
To set up OVSDB on a Juniper Networks device:
1.
Specify the IP address of the NSX controller.
[edit protocols ovsdb]
user@host# set controller ip-address
2. Specify SSL as the protocol that secures the connection.
[edit protocols ovsdb controller ip-address]
user@host# set protocol ssl
3. Set the number of the port over which the connection to the NSX controller is made.
[edit protocols ovsdb controller ip-address protocol ssl]
user@host# set port number
4. (Optional) Specify (in milliseconds) how long the connection can be inactive before
an inactivity probe is sent.
[edit protocols ovsdb controller ip-address]
Copyright © 2014, Juniper Networks, Inc.
63
OVSDB and VXLAN Feature Guide
user@host# set inactivity-probe-duration milliseconds
5. (Optional) Specify (in milliseconds) how long the device must wait before it can try
to connect to the NSX controller again if the previous attempt failed.
[edit protocols ovsdb controller ip-address]
user@host# set maximum-backoff-duration milliseconds
6. (Optional) Repeat steps 1 through 5 to explicitly configure a connection to an additional
NSX controller in the same cluster.
7. Specify the interfaces that you want OVSDB to manage.
[edit protocols ovsdb]
user@host# set interfaces interface-name unit logical-unit-number
NOTE: After completing this procedure, you must set up OVSDB-managed
VXLANs. For more information, see “Configuring OVSDB-Managed VXLANs”
on page 66.
Related
Documentation
•
Understanding How to Set Up Open vSwitch Database Connections Between Juniper
Networks Devices and Controllers on page 7
VMware NSX Configuration for Juniper Networks Devices That Function as Virtual
Tunnel Endpoints
Supported Platforms
MX Series, QFX Series standalone switches
For each Juniper Networks Junos operating system (Junos OS) network device that you
plan to deploy as a hardware virtual tunnel endpoint (VTEP) in a physical network, you
must create a VMware NSX-equivalent entity, which is known as a gateway, in NSX
Manager version 4.0.3 or in the NSX API. You must also map the gateway to a logical
switch, which is the NSX equivalent of an Open vSwitch Database (OVSDB)-managed
Virtual Extensible LAN (VXLAN) in the physical network. Performing this configuration
enables connectivity between physical servers in the physical network and virtual
machines (VMs) in the virtual network.
This topic provides a high-level summary of the tasks that you must perform to create
a gateway. Although you can create a gateway either in NSX Manager or in the NSX API,
this topic describes the necessary tasks from the perspective of NSX Manager. Also, this
topic does not include a complete procedure for each task. Rather, it includes key NSX
Manager configuration details for ensuring the correct configuration of the virtual entities
so that they function properly with the physical entities. For complete information about
performing the tasks described in this topic, see the documentation that accompanies
NSX Manager.
For each hardware VTEP that you deploy in the physical network, you must perform the
following tasks:
64
•
Creating a Gateway on page 65
•
Creating a Gateway Service on page 65
•
Creating a Logical Switch Port on page 66
Copyright © 2014, Juniper Networks, Inc.
Chapter 4: Configuration Tasks
Creating a Gateway
In NSX Manager, you must create a gateway for each hardware VTEP that you implement
in the physical network. Table 10 on page 65 provides a summary of key configuration
fields in NSX Manager and how to configure them when creating a gateway.
Before you begin this task, you must configure a logical switch in NSX Manager or in the
NSX API for each OVSDB-managed VXLAN that you plan to implement in the physical
network. For information about configuring a logical switch, see the documentation that
accompanies NSX Manager or the NSX API.
Table 10: Create a Gateway in NSX Manager: Key Configurations
NSX Manager Configuration
Page/Dialog Box
NSX Manager Configuration
Field
How to Configure
Type
Transport Node Type
Select Gateway.
Properties
VTEP Enabled
Select VTEP Enabled.
Credential
Type
Select Management Address.
Credential
Management Address
Specify the management IP address of the Juniper
Networks device.
Connections/Create Transport
Connector
Transport Type
Select VXLAN.
Connections/Create Transport
Connector
Transport Zone UUID
Select the UUID of an existing transport zone, or
create a new transport zone.
Connections/Create Transport
Connector
IP Address
Specify the IP address of the loopback interface
(lo0) of the Juniper Networks device.
Creating a Gateway Service
In NSX Manager, you must create a gateway service for each hardware VTEP that you
implement in the physical network. Table 11 on page 65 provides a summary of key
configuration fields in NSX Manager and how to configure them when creating a gateway
service.
Before you start this task, make sure that you have configured the OVSDB-managed
interfaces on the hardware VTEP. For information about configuring OVSDB-managed
interfaces, see “Setting Up the Open vSwitch Database Management Protocol on Juniper
Networks Devices” on page 63.
Table 11: Create a Gateway Service in NSX Manager: Key Configurations
NSX Manager Configuration
Page/Dialog Box
NSX Manager Configuration
Field
How to Configure
Type
Gateway Service Type
Select VTEP L2 Gateway Service.
Copyright © 2014, Juniper Networks, Inc.
65
OVSDB and VXLAN Feature Guide
Table 11: Create a Gateway Service in NSX Manager: Key Configurations (continued)
NSX Manager Configuration
Page/Dialog Box
NSX Manager Configuration
Field
Transport Nodes/Edit Gateway
Transport Node
Select the gateway that you created for the
hardware VTEP.
Transport Nodes/Edit Gateway
Port ID
Select an OVSDB-managed interface configured
on the hardware VTEP.
How to Configure
Creating a Logical Switch Port
In NSX Manager, you must create a logical switch port for each hardware VTEP that you
implement in the physical network. Table 12 on page 66 provides a summary of key
configuration fields in NSX Manager and how to configure them when creating a logical
switch port.
Before you start this task, you must configure a logical switch in NSX Manager or in the
NSX API for each OVSDB-managed VXLAN that you plan to implement in the physical
network. For information about configuring a logical switch, see the documentation that
accompanies NSX Manager or the NSX API.
Table 12: Create a Logical Switch Port in NSX Manager: Key Configurations
NSX Manager Configuration
Page/Dialog Box
NSX Manager Configuration Field
How to Configure
Logical Switch
Logical Switch UUID
Select the UUID of the logical switch that
corresponds to the hardware VTEP.
Attachment
Attachment Type
Select VTEP L2 Gateway.
Attachment
VTEP L2 Gateway Service UUID
Select the UUID of the gateway service you created
for the hardware VTEP.
Related
Documentation
•
Configuring OVSDB-Managed VXLANs on page 66
Configuring OVSDB-Managed VXLANs
Supported Platforms
66
MX Series
Copyright © 2014, Juniper Networks, Inc.
Chapter 4: Configuration Tasks
NOTE: This topic does not apply to QFX5100 switches that support Open
vSwitch Database (OVSDB) and Virtual Extensible LAN (VXLAN). The
QFX5100 switch automatically creates OVSDB-managed VXLANs, thereby
eliminating the need for you to configure them, using the Junos OS CLI. In
addition, the QFX5100 switch does not support ingress node replication,
which is described in this topic. However, there are other configuration tasks
that must be performed to set up OVSDB on a QFX5100 switch. For more
information, see “Understanding How to Set Up Virtual Extensible LANs in
an Open vSwitch Database Environment” on page 10.
To implement the OVSDB management protocol on a Juniper Networks device, you must
configure OVSDB-managed VXLANs.
For 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, you
can optionally enable ingress node replication. With this feature enabled, the Juniper
Networks device handles the replication of these packets and the forwarding of the
replicas to interfaces within the same OVSDB-managed VXLAN. For more information
about using ingress node replication or a service node, which is the default way to handle
Layer 2 BUM traffic, see “Understanding How Layer 2 BUM Traffic and Layer 3 Routed
Multicast Traffic Are Handled in VXLANs Managed by OVSDB” on page 8.
NOTE: When Juniper Networks devices replicate Layer 2 BUM packets to a
large number of remote software virtual tunnel endpoints (VTEPs), the
performance of the Juniper Networks devices can be impacted.
Before you configure VXLANs on a Juniper Networks device, using the Junos OS CLI:
•
For each OVSDB-managed VXLAN that you plan to configure on a Juniper Networks
device, you must configure a logical switch in VMware NSX Manager version 4.0.3 or
the NSX API. (For information about configuring a logical switch, see the documentation
that accompanies NSX Manager or the NSX API.) Based on the name and VXLAN
network identifier (VNI) that you configure for the logical switch, NSX automatically
generates a universally unique identifier (UUID) for the logical switch. You must retain
the UUID of the logical switch for use when configuring a corresponding VXLAN on the
Juniper Networks device as described in the following procedure.
•
You must perform the configuration described in “Setting Up the Open vSwitch
Database Management Protocol on Juniper Networks Devices” on page 63.
To configure an OVSDB-managed VXLAN on a Juniper Networks device:
1.
Configure the VXLANs that you want OVSDB to manage. You can configure the VXLANs
in the context of a bridge domain, routing instance, or switching instance.
NOTE: For the name of the bridge domain, you must specify the UUID for
the logical switch configured in NSX Manager or the NSX API.
Copyright © 2014, Juniper Networks, Inc.
67
OVSDB and VXLAN Feature Guide
Bridge domains:
[edit bridge-domains bridge-domain-name vxlan]
user@host# set ovsdb-managed
Bridge domains within the specified routing instance:
[edit routing-instances routing-instance-name bridge-domains bridge-domain-name
vxlan]
user@host# set ovsdb-managed
VLANs within the specified routing instance:
[edit routing-instances routing-instance-name vlans vlan-name vxlan]
user@device# set ovsdb-managed
Default switching instance within the specified routing instance:
[edit routing-instances routing-instance-name switch-options]
user@host# set ovsdb-managed
All VXLAN entities within the specified routing instance:
[edit routing-instances routing-instance-name vxlan]
user@host# set ovsdb-managed
2. (Optional) Enable ingress node replication to handle Layer 2 BUM traffic on interfaces
in the same VXLAN in which the traffic originated. You can configure ingress node
replication in the context of a bridge domain or routing instance.
Bridge domains:
[edit bridge-domains bridge-domain-name vxlan]
user@host# set ingress-node-replication
Bridge domains or all VXLAN entities, respectively, within the specified routing instance:
[edit routing-instances routing-instance-name bridge-domains bridge-domain-name
vxlan]
[edit routing-instances routing-instance-name vlans vlan-name vxlan]
[edit routing-instances routing-instance-name vxlan]
user@host# set ingress-node-replication
3. For each Juniper Networks device that you plan to implement as a hardware VTEP,
you must perform some configuration tasks in NSX Manager or in the NSX API.
For more information about the tasks you must perform and key NSX Manager
configuration details, see “VMware NSX Configuration for Juniper Networks Devices
That Function as Virtual Tunnel Endpoints” on page 64.
Related
Documentation
68
•
Understanding How to Set Up Virtual Extensible LANs in an Open vSwitch Database
Environment on page 10
•
Example: Setting Up a VXLAN Layer 2 Gateway and OVSDB Connections Between
Virtual and Physical Entities in a Data Center on page 25
•
Example: Setting Up Inter-VXLAN Routing and OVSDB Connections in a Data Center
on page 33
Copyright © 2014, Juniper Networks, Inc.
Chapter 4: Configuration Tasks
Configuring VXLANs on a QFX5100 Switch
Supported Platforms
QFX Series standalone switches
Follow these steps to configure a QFX5100 switch to act as a VTEP. (If the switch is
acting as a transit Layer 3 switch for downstream VTEPs, you do not need to perform
these steps. No special configuration is needed in this case.)
•
Configuring a Source IP Address on page 69
•
Configuring PIM for VXLANs on page 69
•
Configuring VXLANs on page 70
Configuring a Source IP Address
On a switch that will act as a VTEP, you must configure an IP address that will be used
as the source address in the outer IP header of the VXLAN packet. This is the VXLAN
tunnel source address.
1.
Create a reachable IPv4 address on the loopback interface and configure it to be used
as the tunnel source address:
[edit]
user@switch# set interfaces lo0.0 unit 0 family inet address ip-address
[edit]
user@switch# set switch-options vtep-interface-source lo0.0
Configuring PIM for VXLANs
If you are not using a controller to create a VXLAN control plane, you must enable PIM
on the switch so that the VTEP can use multicast groups to establish reachability with
other VTEPs and forward BUM traffic.
1.
Enable PIM on the interface that connects to the Layer 3 network. This is the interface
the performs the VXLAN encapsulation and de-encapsulation.
[edit]
user@switch# set protocols pim interface interface-name
2. Configure the address of a PIM rendezvous point:
[edit]
user@switch# set protocols pim rp static address ip-address
Copyright © 2014, Juniper Networks, Inc.
69
OVSDB and VXLAN Feature Guide
Configuring VXLANs
You configure VXLANs under the vlan stanza (which is why a QFX5100 switch supports
4K VLANs). You must also configure the server-facing interfaces to be VLAN members.
1.
Create a VLAN to VXLAN mapping and assign a multicast group address to the VXLAN.
All members of a VXLAN must use the same multicast group address:
[edit]
user@switch# set vlans name vlan-id ID vxlan vni ID multicast-group multicast-group-address
2. (Optional) Configure the switch to retain the original VLAN tag (in the inner Ethernet
packet) after VXLAN encapsulation. By default, the original tag is dropped when the
packet is encapsulated:
[edit]
user@switch# set vlans name vxlan encapsulate-inner-vlan
3. (Optional) Configure the switch to de-encapsulate and accept original VLAN tags in
VXLAN packets. By default, the original tag is dropped when the packet is
encapsulated:
[edit]
user@switch# set protocols l2-learning decapsulate-accept-inner-vlan
4. Configure server-facing interfaces to support multiple VLANs:
[edit]
user@switch# set interfaces interface unit unit family ethernet-switching interface-mode
trunk
[edit]
user@switch# set interfaces interface unit unit family ethernet-switching vlan members all
You must create a VLAN to VXLAN mapping for each VLAN that will need Layer 2
connectivity over the Layer 3 network.
Related
Documentation
70
•
Understanding VXLANs on page 17
•
Examples: Configuring VXLANs on QFX Series Switches on page 51
•
VXLAN Constraints on QFX5100 Switches on page 21
Copyright © 2014, Juniper Networks, Inc.
CHAPTER 5
OVSDB Configuration Statements
•
controller (OVSDB) on page 72
•
inactivity-probe-duration on page 73
•
ingress-node-replication on page 74
•
interfaces (OVSDB) on page 75
•
maximum-backoff-duration on page 76
•
ovsdb on page 77
•
ovsdb-managed on page 78
•
port (OVSDB) on page 79
•
protocol (OVSDB) on page 80
•
traceoptions (OVSDB) on page 81
Copyright © 2014, Juniper Networks, Inc.
71
OVSDB and VXLAN Feature Guide
controller (OVSDB)
Supported Platforms
Syntax
Hierarchy Level
Release Information
Description
MX Series, QFX Series standalone switches
controller ip-address {
inactivity-probe-duration milliseconds;
maximum-backoff-duration milliseconds;
protocol protocol {
port number;
}
}
[edit protocols ovsdb]
Statement introduced in Junos OS Release 14.1R2.
Statement introduced in Junos OS Release 14.1X53-D10 for QFX Series switches.
Configure a connection between a Juniper Networks device and a VMware NSX controller.
The Junos OS device must be running a release that supports the Open vSwitch Database
(OVSDB) management protocol and have the OVSDB software package installed. The
OVSDB software package release must be the same as the Junos OS release running on
the device.
The Junos OS implementation of OVSDB supports one cluster of NSX controllers, which
includes three or five controllers as per VMware recommendations.
To implement OVSDB on a Junos OS device, you must explicitly configure a connection
to at least one NSX controller, using the Junos OS CLI. If the NSX controller to which you
explicitly configure a connection is in a cluster, the controller pushes information about
other controllers in the same cluster to the device, and the device establishes connections
with the other controllers. However, you can also explicitly configure connections with
the other controllers in the cluster, using the Junos OS CLI.
Options
ip-address —IPv4 address of the NSX controller.
The remaining statements are explained separately.
Required Privilege
Level
Related
Documentation
72
admin—To view this statement in the configuration.
admin-control—To add this statement to the configuration.
•
Setting Up the Open vSwitch Database Management Protocol on Juniper Networks
Devices on page 63
•
Understanding How to Set Up Open vSwitch Database Connections Between Juniper
Networks Devices and Controllers on page 7
Copyright © 2014, Juniper Networks, Inc.
Chapter 5: OVSDB Configuration Statements
inactivity-probe-duration
Supported Platforms
Syntax
Hierarchy Level
Release Information
Description
Options
MX Series, QFX Series standalone switches
inactivity-probe-duration milliseconds;
[edit protocols ovsdb controller]
Statement introduced in Junos OS Release 14.1R2.
Statement introduced in Junos OS Release 14.1X53-D10 for QFX Series switches.
Configure the maximum amount of time, in milliseconds, that the connection between
a Juniper Networks device that supports the Open vSwitch Database (OVSDB)
management protocol and a VMware NSX controller can be inactive before an inactivity
probe is sent.
milliseconds—Number of milliseconds that the connection can be inactive before an
inactivity probe is sent.
Range: 0 through 4,294,967,295
Default: 0. This value indicates that an inactivity probe is never sent.
Required Privilege
Level
Related
Documentation
admin—To view this statement in the configuration.
admin-control—To add this statement to the configuration.
•
Setting Up the Open vSwitch Database Management Protocol on Juniper Networks
Devices on page 63
•
Understanding How to Set Up Open vSwitch Database Connections Between Juniper
Networks Devices and Controllers on page 7
Copyright © 2014, Juniper Networks, Inc.
73
OVSDB and VXLAN Feature Guide
ingress-node-replication
Supported Platforms
Syntax
Hierarchy Level
Release Information
Description
MX Series
ingress-node-replication;
[edit bridge-domains bridge-domain-name vxlan],
[edit routing-instances routing-instance-name bridge-domains bridge-domain-name vxlan],
[edit routing-instances routing-instance-name vlans vlan-name vxlan],
[edit routing-instances routing-instance-name vxlan]
[edit vlans vlan-name vxlan]
Statement introduced in Junos OS Release 14.1R2.
Enable ingress node replication for a specified Virtual Extensible LAN (VXLAN) that is
managed by the Open vSwitch Database (OVSDB) management protocol.
With this feature enabled, instead of service nodes, Juniper Networks devices with OVSDB
implemented handle incoming broadcast, unknown unicast, or multicast (BUM) traffic.
For more information about the scenarios in which you can use ingress node replication
and how it works, see “Understanding How Layer 2 BUM Traffic and Layer 3 Routed
Multicast Traffic Are Handled in VXLANs Managed by OVSDB” on page 8.
NOTE: 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.
Default
Required Privilege
Level
Related
Documentation
74
If you do not include the ingress-node-replication statement, one or more service nodes
handle BUM traffic.
admin—To view this statement in the configuration.
admin-control—To add this statement to the configuration.
•
Configuring OVSDB-Managed VXLANs on page 66
Copyright © 2014, Juniper Networks, Inc.
Chapter 5: OVSDB Configuration Statements
interfaces (OVSDB)
Supported Platforms
Syntax
Hierarchy Level
Release Information
Description
Options
MX Series, QFX Series standalone switches
interfaces interface-name;
[edit protocols ovsdb]
Statement introduced in Junos OS Release 14.1R2.
Statement introduced in Junos OS Release 14.1X53-D10 for QFX Series switches.
Specify the interfaces to be managed by the Open vSwitch Database (OVSDB)
management protocol. Typically, the only interfaces that need to be managed by OVSDB
are interfaces with physical servers.
interface-name—Name of the interface, including the logical unit number—for example,
xe-1/1/0.0.
Required Privilege
Level
Related
Documentation
admin—To view this statement in the configuration.
admin-control—To add this statement to the configuration.
•
Configuring OVSDB-Managed VXLANs on page 66
Copyright © 2014, Juniper Networks, Inc.
75
OVSDB and VXLAN Feature Guide
maximum-backoff-duration
Supported Platforms
Syntax
Hierarchy Level
Release Information
Description
Options
MX Series, QFX Series standalone switches
maximum-backoff-duration milliseconds;
[edit protocols ovsdb controller]
Statement introduced in Junos OS Release 14.1R2.
Statement introduced in Junos OS Release 14.1X53-D10 for QFX Series switches.
Specify (in milliseconds) how long a Juniper Networks device that supports the Open
vSwitch Database (OVSDB) management protocol waits before it re-attempts to connect
with a VMware NSX controller if a previous attempt failed.
milliseconds—Number of milliseconds a Juniper Networks device waits before it
re-attempts to connect with an NSX controller.
Range: 1000 through 4,294,967,295
Default: 1000
Required Privilege
Level
Related
Documentation
76
admin—To view this statement in the configuration.
admin-control—To add this statement to the configuration.
•
Setting Up the Open vSwitch Database Management Protocol on Juniper Networks
Devices on page 63
•
Understanding How to Set Up Open vSwitch Database Connections Between Juniper
Networks Devices and Controllers on page 7
Copyright © 2014, Juniper Networks, Inc.
Chapter 5: OVSDB Configuration Statements
ovsdb
Supported Platforms
Syntax
Hierarchy Level
Release Information
Description
MX Series, QFX Series standalone switches
ovsdb {
controller ip-address {
inactivity-probe-duration milliseconds;
maximum-backoff-duration milliseconds;
protocol protocol {
port number;
}
}
interfaces interface-name;
traceoptions {
file <filename> <files number> <match regular-expression> <no-world-readable |
world-readable> <size size>;
flag flag;
no-remote-trace;
}
}
[edit protocols]
Statement introduced in Junos OS Release 14.1R2.
Statement introduced in Junos OS Release 14.1X53-D10 for QFX Series switches.
Configure support for the Open vSwitch Database (OVSDB) management protocol on
a Juniper Networks device. The Juniper Networks device must be running a release that
supports OVSDB and have the OVSDB software package installed. The OVSDB software
package release must be the same as the Junos OS release that is running on the device.
The remaining statements are explained separately.
Default
Required Privilege
Level
Related
Documentation
The OVSDB management protocol is disabled on Juniper Networks devices.
admin—To view this statement in the configuration.
admin-control—To add this statement to the configuration.
•
Understanding the Open vSwitch Database Management Protocol Running on Juniper
Networks Devices on page 6
•
Configuring OVSDB-Managed VXLANs on page 66
Copyright © 2014, Juniper Networks, Inc.
77
OVSDB and VXLAN Feature Guide
ovsdb-managed
Supported Platforms
Syntax
Hierarchy Level
Release Information
Description
MX Series, QFX Series standalone switches
ovsdb-managed;
[edit bridge-domains bridge-domain-name vxlan],
[edit routing-instances routing-instance-name bridge-domains bridge-domain-name vxlan],
[edit routing-instances routing-instance-name switch-options],
[edit routing-instances routing-instance-name vlans vlan-name vxlan],
[edit routing-instances routing-instance-name vxlan],
[edit switch-options]
[edit vlans vlan-name vxlan]
Statement introduced in Junos OS Release 14.1R2.
Statement introduced in Junos OS Release 14.1X53-D10 for QFX Series switches.
Disable a Junos OS device from learning about other Junos OS devices that function as
hardware virtual tunnel endpoints (VTEPs) in a specified Virtual Extensible LAN (VXLAN)
and the MAC addresses learned by the hardware VTEPs. Instead, the Junos OS device
uses the Open vSwitch Database (OVSDB) management protocol to learn about the
hardware VTEPs in the VXLAN and the MAC addresses learned by the hardware VTEPs.
The specified VXLAN must have a VXLAN Network Identifier (VNI) configured, using the
vni statement in the [edit bridge-domains bridge-domain-name vxlan], [edit routing-instance
routing-instance-name vxlan], or [edit vlans vlan-name vxlan] hierarchy.
Also, this implementation of OVSDB uses the multicast scheme described in
“Understanding How Layer 2 BUM Traffic and Layer 3 Routed Multicast Traffic Are Handled
in VXLANs Managed by OVSDB” on page 8. Therefore, specifying the multicast-group
statement in the [edit bridge-domains bridge-domain-name vxlan], [edit routing-instances
routing-instance-name vxlan], or [edit vlans vlan-name vxlan] hierarchy has no effect.
Required Privilege
Level
Related
Documentation
78
admin—To view this statement in the configuration.
admin-control—To add this statement to the configuration.
•
Configuring OVSDB-Managed VXLANs on page 66
Copyright © 2014, Juniper Networks, Inc.
Chapter 5: OVSDB Configuration Statements
port (OVSDB)
Supported Platforms
Syntax
Hierarchy Level
Release Information
Description
Options
MX Series, QFX Series standalone switches
port number;
[edit protocols ovsdb controller protocol]
Statement introduced in Junos OS Release 14.1R2.
Statement introduced in Junos OS Release 14.1X53-D10 for QFX Series switches.
Specify the VMware NSX controller port to which a Juniper Networks device that supports
the Open vSwitch Database (OVSDB) management protocol connects.
number—Port number of NSX controller port.
Range: 1024 through 65,535
Default: 6632
Required Privilege
Level
Related
Documentation
admin—To view this statement in the configuration.
admin-control—To add this statement to the configuration.
•
Setting Up the Open vSwitch Database Management Protocol on Juniper Networks
Devices on page 63
•
Understanding How to Set Up Open vSwitch Database Connections Between Juniper
Networks Devices and Controllers on page 7
Copyright © 2014, Juniper Networks, Inc.
79
OVSDB and VXLAN Feature Guide
protocol (OVSDB)
Supported Platforms
Syntax
Hierarchy Level
Release Information
Description
MX Series, QFX Series standalone switches
protocol protocol {
port number;
}
[edit protocols ovsdb controller]
Statement introduced in Junos OS Release 14.1R2.
Statement introduced in Junos OS Release 14.1X53-D10 for QFX Series switches.
Configure the security protocol that protects the connection between a Juniper Networks
device that supports the Open vSwitch Database (OVSDB) management protocol and
a VMware NSX controller.
The Secure Sockets Layer (SSL) connection requires a private key and certificates, which
must be stored in the /var/db/certs directory of the Juniper Networks device. For more
information about the files, including actions you must take to create and install some
of the files, see “Creating and Installing an SSL Key and Certificate on a Juniper Networks
Device for Connection with VMware NSX Controllers” on page 62.
Options
protocol—Establish a secure connection to the NSX controller, using SSL or the
Transmission Control Protocol (TCP).
NOTE: SSL is the only supported connection protocol.
Default: ssl
The remaining statement is explained separately.
Required Privilege
Level
Related
Documentation
80
admin—To view this statement in the configuration.
admin-control—To add this statement to the configuration.
•
Setting Up the Open vSwitch Database Management Protocol on Juniper Networks
Devices on page 63
•
Understanding How to Set Up Open vSwitch Database Connections Between Juniper
Networks Devices and Controllers on page 7
Copyright © 2014, Juniper Networks, Inc.
Chapter 5: OVSDB Configuration Statements
traceoptions (OVSDB)
Supported Platforms
Syntax
Hierarchy Level
Release Information
MX Series, QFX Series standalone switches
traceoptions {
file <filename> <files number> <match regular-expression> <no-world-readable |
world-readable> <size size>;
flag flag;
no-remote-trace;
}
[edit protocols ovsdb]
Statement introduced in Junos OS Release 14.1R2.
Statement introduced in Junos OS Release 14.1X53-D10 for QFX Series switches.
Description
Define tracing operations for the Open vSwitch Database (OVSDB) management protocol,
which is supported on Juniper Networks devices.
Default
If you do not include this statement, OVSDB-specific tracing operations are not performed.
Options
file filename—Name of file in which the system places the output of the tracing operations.
By default, the system places all files in the /var/log directory.
Default: /var/log/vgd
files number—(Optional) Maximum number of trace files. When a trace file reaches the
size specified by the size option, the filename is appended with 0 and compressed.
For example, a trace file named trace-file.gz would be renamed trace-file.0.gz. When
trace-file.0.gz reaches the specified size, it is renamed trace-file.1.gz and its contents
are compressed to trace-file.0.gz. This renaming scheme continues until the maximum
number of trace files is reached. Then the oldest trace file is overwritten.
If you specify a maximum number of files, you also must specify a maximum file size
with the size option and a filename.
Range: 2 through 1000 files
Default: 10 files
flag flag—Tracing operation to perform. You can include one or more of the following
flags:
all—All OVSDB events.
configuration—OVSDB configuration events.
core—OVSDB core events.
function—OVSDB function events.
interface—OVSDB interface events.
l2-client—OVSDB Layer 2 client events.
ovs-client—OVSDB client events.
Copyright © 2014, Juniper Networks, Inc.
81
OVSDB and VXLAN Feature Guide
match regular-expression—(Optional) Only log lines that match the regular expression.
no-remote-trace—(Optional) Disable tracing and logging operations that track normal
operations, error conditions, and packets that are generated by or passed through
the Juniper Networks device.
no-world-readable—Restrict access to the trace files to the owner.
Default: no-world-readable
size size—(Optional) Maximum size of each trace file in bytes, kilobytes (KB), megabytes
(MB), or gigabytes (GB). If you do not specify a unit, the default is bytes. If you specify
a maximum file size, you also must specify a maximum number of trace files by using
the files option and a filename by using the file option.
Syntax: size to specify bytes, sizek to specify KB, sizem to specify MB, or sizeg to
specify GB.
Range: 10,240 through 1,073,741,824 bytes
Default: 128 KB
world-readable—Enable any user to access the trace files.
Required Privilege
Level
Related
Documentation
82
admin—To view this statement in the configuration.
admin-control—To add this statement to the configuration.
•
Example: Setting Up a VXLAN Layer 2 Gateway and OVSDB Connections Between
Virtual and Physical Entities in a Data Center on page 25
•
Example: Setting Up Inter-VXLAN Routing and OVSDB Connections in a Data Center
on page 33
Copyright © 2014, Juniper Networks, Inc.
CHAPTER 6
VXLAN Configuration Statements
•
decapsulate-accept-inner-vlan on page 83
•
encapsulate-inner-vlan on page 84
•
multicast-group on page 84
•
ovsdb-managed on page 85
•
unreachable-vtep-aging-timer on page 86
•
vni on page 86
•
vtep-source-interface on page 87
•
vxlan on page 87
decapsulate-accept-inner-vlan
Supported Platforms
Syntax
Hierarchy Level
Release Information
Description
Required Privilege
Level
Related
Documentation
QFX Series standalone switches
decapsulate-accept-inner-vlan
[edit protocols l2-learning]
Statement modified in Junos OS 14.1X53 for the QFX Series.
Configure the switch to de-encapsulate and accept original VLAN tags in VXLAN packets.
routing—To view this statement in the configuration.
routing-control—To add this statement to the configuration.
•
Understanding VXLANs on page 17
•
encapsulate-inner-vlan on page 84
Copyright © 2014, Juniper Networks, Inc.
83
OVSDB and VXLAN Feature Guide
encapsulate-inner-vlan
Supported Platforms
QFX Series standalone switches
Syntax
encapsulate-inner-vlan
Hierarchy Level
[edit vlans VLAN vxlan]
Release Information
Description
Default
Required Privilege
Level
Related
Documentation
Statement introduced in Junos OS Release 14.1X53-D10.
Configure the switch to preserve the original VLAN tag (in the inner Ethernet packet)
when performing VXLAN encapsulation.
The original tag is dropped when the packet is encapsulated.
routing—To view this statement in the configuration.
routing-control—To add this statement to the configuration.
•
Understanding VXLANs on page 17
•
Configuring VXLANs on a QFX5100 Switch on page 69
•
Examples: Configuring VXLANs on QFX Series Switches on page 51
•
decapsulate-accept-inner-vlan on page 83
multicast-group
Supported Platforms
Syntax
Hierarchy Level
Release Information
Description
Required Privilege
Level
Related
Documentation
84
QFX Series standalone switches
multicast-group
[edit vlans VLAN vxlan]
Statement introduced in Junos OS Release 14.1X53-D10.
Assign a multicast group address to a VXLAN. All members of a VXLAN must use the
same multicast group address
routing—To view this statement in the configuration.
routing-control—To add this statement to the configuration.
•
Understanding VXLANs on page 17
•
Configuring VXLANs on a QFX5100 Switch on page 69
•
Examples: Configuring VXLANs on QFX Series Switches on page 51
Copyright © 2014, Juniper Networks, Inc.
Chapter 6: VXLAN Configuration Statements
ovsdb-managed
Supported Platforms
Syntax
Hierarchy Level
Release Information
Description
MX Series, QFX Series standalone switches
ovsdb-managed;
[edit bridge-domains bridge-domain-name vxlan],
[edit routing-instances routing-instance-name bridge-domains bridge-domain-name vxlan],
[edit routing-instances routing-instance-name switch-options],
[edit routing-instances routing-instance-name vlans vlan-name vxlan],
[edit routing-instances routing-instance-name vxlan],
[edit switch-options]
[edit vlans vlan-name vxlan]
Statement introduced in Junos OS Release 14.1R2.
Statement introduced in Junos OS Release 14.1X53-D10 for QFX Series switches.
Disable a Junos OS device from learning about other Junos OS devices that function as
hardware virtual tunnel endpoints (VTEPs) in a specified Virtual Extensible LAN (VXLAN)
and the MAC addresses learned by the hardware VTEPs. Instead, the Junos OS device
uses the Open vSwitch Database (OVSDB) management protocol to learn about the
hardware VTEPs in the VXLAN and the MAC addresses learned by the hardware VTEPs.
The specified VXLAN must have a VXLAN Network Identifier (VNI) configured, using the
vni statement in the [edit bridge-domains bridge-domain-name vxlan], [edit routing-instance
routing-instance-name vxlan], or [edit vlans vlan-name vxlan] hierarchy.
Also, this implementation of OVSDB uses the multicast scheme described in
“Understanding How Layer 2 BUM Traffic and Layer 3 Routed Multicast Traffic Are Handled
in VXLANs Managed by OVSDB” on page 8. Therefore, specifying the multicast-group
statement in the [edit bridge-domains bridge-domain-name vxlan], [edit routing-instances
routing-instance-name vxlan], or [edit vlans vlan-name vxlan] hierarchy has no effect.
Required Privilege
Level
Related
Documentation
admin—To view this statement in the configuration.
admin-control—To add this statement to the configuration.
•
Configuring OVSDB-Managed VXLANs on page 66
Copyright © 2014, Juniper Networks, Inc.
85
OVSDB and VXLAN Feature Guide
unreachable-vtep-aging-timer
Supported Platforms
Syntax
Hierarchy Level
Release Information
Description
Required Privilege
Level
Related
Documentation
QFX Series standalone switches
unreachable-vtep-aging-timer [300–1800]
[edit vlans VLAN vxlan]
Statement introduced in Junos OS Release 14.1X53-D10.
Configure the system to age out the address for the remote VTEP if all the MAC addresses
learned from that VTEP age out. The address for the remote VTEP expires the configured
number of seconds after the last learned MAC address expires.
routing—To view this statement in the configuration.
routing-control—To add this statement to the configuration.
•
Understanding VXLANs on page 17
•
Configuring VXLANs on a QFX5100 Switch on page 69
•
Examples: Configuring VXLANs on QFX Series Switches on page 51
vni
Supported Platforms
Syntax
Hierarchy Level
Release Information
Description
Required Privilege
Level
Related
Documentation
86
QFX Series standalone switches
vni [1–16777214]
[edit vlans VLAN vxlan]
Statement introduced in Junos OS Release 14.1X53-D10.
Assign a numeric value to identify a VXLAN. All members of a VXLAN must use the same
VNI.
routing—To view this statement in the configuration.
routing-control—To add this statement to the configuration.
•
Understanding VXLANs on page 17
•
Configuring VXLANs on a QFX5100 Switch on page 69
•
Examples: Configuring VXLANs on QFX Series Switches on page 51
Copyright © 2014, Juniper Networks, Inc.
Chapter 6: VXLAN Configuration Statements
vtep-source-interface
Supported Platforms
Syntax
Hierarchy Level
Release Information
Description
Required Privilege
Level
Related
Documentation
QFX Series standalone switches
vtep-source-interface logical-interface;
[edit switch-options,
Statement introduced in Junos OS Release 14.1X53-D10.
Configure a source interface for a VXLAN tunnel. You must provide the name of a logical
interface configured on the loopback interface.
routing—To view this statement in the configuration.
routing-control—To add this statement to the configuration.
•
Understanding VXLANs on page 17
•
Configuring VXLANs on a QFX5100 Switch on page 69
•
Examples: Configuring VXLANs on QFX Series Switches on page 51
vxlan
Supported Platforms
Syntax
Hierarchy Level
Release Information
QFX Series standalone switches
vxlan {
encapsulate-inner-vlan
multicast-group
ovsdb-managed
unreachable-vtep-aging-timer
vni
}
}
[edit vlans],
Statement introduced in Junos OS Release 14.1X53-D10.
Description
Options
Required Privilege
Level
Related
Documentation
The remaining statements are explained separately.
routing—To view this statement in the configuration.
routing-control—To add this statement to the configuration.
•
Understanding VXLANs on page 17
•
Configuring VXLANs on a QFX5100 Switch on page 69
•
Examples: Configuring VXLANs on QFX Series Switches on page 51
Copyright © 2014, Juniper Networks, Inc.
87
OVSDB and VXLAN Feature Guide
88
Copyright © 2014, Juniper Networks, Inc.
PART 3
Administration
•
OVSDB Monitoring Commands on page 91
•
VXLAN Monitoring Commands on page 117
Copyright © 2014, Juniper Networks, Inc.
89
OVSDB and VXLAN Feature Guide
90
Copyright © 2014, Juniper Networks, Inc.
CHAPTER 7
OVSDB Monitoring Commands
•
show bridge mac-table
•
show ovsdb controller
•
show ovsdb interface
•
show ovsdb logical-switch
•
show ovsdb mac
•
show ovsdb statistics interface
•
show ovsdb virtual-tunnel-end-point
•
show vpls mac-table
Copyright © 2014, Juniper Networks, Inc.
91
OVSDB and VXLAN Feature Guide
show bridge mac-table
Supported Platforms
Syntax
Release Information
Description
Options
MX Series
show bridge mac-table
<brief | count | detail | extensive>
<bridge-domain (all | bridge-domain-name)>
<global-count>
<interface interface-name>
<mac-address>
<vlan-id (all-vlan | vlan-id)>
Command introduced in Junos OS Release 8.4.
(MX Series routers only) Display Layer 2 MAC address information.
none—Display all learned Layer 2 MAC address information.
brief | count | detail | extensive—(Optional) Display the specified level of output.
bridge-domain (all | bridge-domain-name)—(Optional) Display learned Layer 2 MAC
addresses for all bridging domains or for the specified bridging domain.
global-count—(Optional) Display the total number of learned Layer 2 MAC addresses
on the system.
instance instance-name—(Optional) Display learned Layer 2 MAC addresses for the
specified routing instance.
interface interface-name—(Optional) Display learned Layer 2 MAC addresses for the
specified interface.
mac-address—(Optional) Display the specified learned Layer 2 MAC address information.
vlan-id (all-vlan | vlan-id)—(Optional) Display learned Layer 2 MAC addresses for all
VLANs or for the specified VLAN.
Additional Information
Required Privilege
Level
List of Sample Output
Output Fields
92
When Layer 2 protocol tunneling is enabled, the tunneling MAC address 01:00:0c:cd:cd:d0
is installed in the MAC table. When the Cisco Discovery Protocol (CDP), Spanning Tree
Protocol (STP), or VLAN Trunk Protocol (VTP) is configured for Layer 2 protocol tunneling
on an interface, the corresponding protocol MAC address is installed in the MAC table.
view
show bridge mac-table on page 93
show bridge mac-table (with VXLAN enabled) on page 94
show bridge mac-table count on page 94
show bridge mac-table detail on page 95
Table 13 on page 93 describes the output fields for the show bridge mac-table command.
Output fields are listed in the approximate order in which they appear.
Copyright © 2014, Juniper Networks, Inc.
Chapter 7: OVSDB Monitoring Commands
Table 13: show bridge mac-table Output fields
Field Name
Field Description
Routing instance
Name of the routing instance.
Bridging domain
Name of the bridging domain.
MAC address
MAC address or addresses learned on a logical interface.
MAC flags
Status of MAC address learning properties for each interface:
•
S—Static MAC address is configured.
•
D—Dynamic MAC address is configured.
•
L—Locally learned MAC address is configured.
•
C—Control MAC address is configured.
•
SE—MAC accounting is enabled.
•
NM—Non-configured MAC.
•
R—Remote PE MAC address is configured.
Logical interface
Name of the logical interface.
MAC count
Number of MAC addresses learned on the specific routing instance or
interface.
Learning interface
Name of the logical interface on which the MAC address was learned.
Learning VLAN
VLAN ID of the routing instance or bridge domain in which the MAC address
was learned.
VXLAN ID/VXLAN
VXLAN Network Identifier (VNI)
Layer 2 flags
Debugging flags signifying that the MAC address is present in various lists.
Epoch
Spanning Tree Protocol epoch number identifying when the MAC address
was learned. Used for debugging.
Sequence number
Sequence number assigned to this MAC address. Used for debugging.
Learning mask
Mask of the Packet Forwarding Engines where this MAC address was learned.
Used for debugging.
IPC generation
Creation time of the logical interface when this MAC address was learned.
Used for debugging.
Sample Output
show bridge mac-table
user@host> show bridge mac-table
MAC flags (S -static MAC, D -dynamic MAC, L -locally learned, C -Control MAC
SE -Statistics enabled, NM -Non configured MAC, R -Remote PE MAC)
Copyright © 2014, Juniper Networks, Inc.
93
OVSDB and VXLAN Feature Guide
Routing instance : default-switch
Bridging domain : test1, VLAN : 1
MAC
MAC
Logical
address
flags
interface
01:00:0c:cc:cc:cc
S,NM
NULL
01:00:0c:cc:cc:cd
S,NM
NULL
01:00:0c:cd:cd:d0
S,NM
NULL
64:87:88:6a:17:d0
D
ae0.1
64:87:88:6a:17:f0
D
ae0.1
NH
Index
RTR
ID
show bridge mac-table (with VXLAN enabled)
user@host> show bridge mac-table
MAC flags (S -static MAC, D -dynamic MAC, L -locally learned
SE -Statistics enabled, NM -Non configured MAC, R -Remote PE MAC)
Routing instance : default-switch
Bridging domain : vlan-1, VLAN : 1
VXLAN: Id : 100, Multicast group: 226.1.1.1
MAC
MAC
Logical
address
flags
interface
00:01:01:00:01:f7
D,SE
vtep.1052010
00:03:00:32:01:f7
D,SE
vtep.1052011
00:00:21:11:11:10
DL
ge-1/0/0.0
00:00:21:11:11:11
DL
ge-1/1/0.0
Routing instance : default-switch
Bridging domain : vlan-2, VLAN : 2, VXLAN : 200
VXLAN: Id : 200, Multicast group: 226.1.1.2
MAC
MAC
Logical
address
flags
interface
00:02:01:33:01:f7
D,SE
vtep.1052010
00:04:00:14:01:f7
D,SE
vtep.1052011
00:00:21:11:21:10
DL
ge-1/0/0.1
00:00:21:11:21:11
DL
ge-1/1/0.1
show bridge mac-table count
user@host> show bridge mac-table count
2 MAC address learned in routing instance vs1 bridge domain vlan100
MAC address count per interface within routing instance:
Logical interface
MAC count
ge-11/0/3.0
1
ge-11/1/4.100
0
ge-11/1/1.100
0
ge-11/1/0.100
0
xe-10/2/0.100
1
xe-10/0/0.100
0
MAC address count per learn VLAN within routing instance:
Learn VLAN ID
MAC count
0
2
0 MAC address learned in routing instance vs1 bridge domain vlan200
MAC address count per interface within routing instance:
Logical interface
MAC count
94
Copyright © 2014, Juniper Networks, Inc.
Chapter 7: OVSDB Monitoring Commands
ge-11/1/0.200
ge-11/1/1.200
ge-11/1/4.200
xe-10/0/0.200
xe-10/2/0.200
0
0
0
0
0
MAC address count per learn VLAN within routing instance:
Learn VLAN ID
MAC count
0
0
show bridge mac-table detail
user@host> show bridge mac-table detail
MAC address: 00:00:00:19:1c:db
Routing instance: vs1
Bridging domain: vlan100
Learning interface: ge-11/0/3.0
Learning VLAN: 0
Layer 2 flags: in_ifd, in_ifl, in_vlan, kernel
Epoch: 4
Sequence number: 0
Learning mask: 0x800
IPC generation: 0
MAC address: 00:00:00:59:3a:2f
Routing instance: vs1
Bridging domain: vlan100
Learning interface: xe-10/2/0.100
Learning VLAN: 0
Layer 2 flags: in_ifd, in_ifl, in_vlan, kernel
Epoch: 7
Sequence number: 0
Learning mask: 0x400
IPC generation: 0
Copyright © 2014, Juniper Networks, Inc.
95
OVSDB and VXLAN Feature Guide
show ovsdb controller
Supported Platforms
Syntax
Release Information
Description
Options
MX Series, QFX Series standalone switches
show ovsdb controller
<address ip-address>
Command introduced in Junos OS Release 14.1R2.
Command introduced in Junos OS Release 14.1X53-D10 for QFX Series switches.
Display information and connection status for VMware NSX controllers to which the
Juniper Networks device is connected. This command displays information for NSX
controllers with connections to a Juniper Networks device that are made in the following
ways:
•
With explicit configuration—The connection is explicitly configured using the Junos OS
CLI.
•
Without explicit configuration—An NSX controller to which the Juniper Networks device
is connected pushes information about other controllers in the same cluster to the
device. With this method, the Juniper Networks device learns about the other controllers
in the same cluster and connections to these controllers are established without explicit
configuration.
none—Display information about all NSX controllers to which the Juniper Networks device
is connected.
address ip-address—Display information about the NSX controller at the specified IP
address.
Required Privilege
Level
Related
Documentation
List of Sample Output
Output Fields
admin
•
Setting Up the Open vSwitch Database Management Protocol on Juniper Networks
Devices on page 63
•
Understanding How to Set Up Open vSwitch Database Connections Between Juniper
Networks Devices and Controllers on page 7
show ovsdb controller on page 97
show ovsdb controller address on page 97
Table 14 on page 96 lists the output fields for the show ovsdb controller command. Output
fields are listed in the approximate order in which they appear.
Table 14: show ovsdb controller Output Fields
Field Name
Field Descriptions
Controller IP address
IP address of an NSX controller to which the Juniper Networks device is connected.
96
Copyright © 2014, Juniper Networks, Inc.
Chapter 7: OVSDB Monitoring Commands
Table 14: show ovsdb controller Output Fields (continued)
Field Name
Field Descriptions
Controller protocol
Protocol used by the Juniper Networks device to initiate a connection with an NSX
controller.
Controller port
NSX controller port to which the Juniper Networks device is connected.
Controller connection
State of the connection between the Juniper Networks device and an NSX controller.
Controller seconds-since-connect
Number of seconds since the connection between the Juniper Networks device and
NSX controller was established.
Controller seconds-since-disconnect
Number of seconds since the connection between the Juniper Networks device and
NSX controller was dropped.
Controller connection status
Status of the connection between the Juniper Networks device and an NSX controller.
Sample Output
show ovsdb controller
user@host> show ovsdb controller
VTEP controller information:
Controller IP address: 10.168.66.189
Controller protocol: ssl
Controller port: 6632
Controller connection: up
Controller seconds-since-connect: 56290
Controller seconds-since-disconnect: 0
Controller connection status: active
Controller
Controller
Controller
Controller
Controller
Controller
Controller
IP address: 10.168.181.54
protocol: ssl
port: 6632
connection: up
seconds-since-connect: 56292
seconds-since-disconnect: 0
connection status: active
Controller
Controller
Controller
Controller
Controller
Controller
Controller
IP address: 10.168.182.45
protocol: ssl
port: 6632
connection: up
seconds-since-connect: 56292
seconds-since-disconnect: 0
connection status: active
show ovsdb controller address
user@host> show ovsdb controller address 10.168.182.45
VTEP controller information:
Controller IP address: 192.168.182.45
Controller protocol: ssl
Controller port: 6632
Controller connection: up
Copyright © 2014, Juniper Networks, Inc.
97
OVSDB and VXLAN Feature Guide
Controller seconds-since-connect: 56347
Controller seconds-since-disconnect: 0
Controller connection status: active
98
Copyright © 2014, Juniper Networks, Inc.
Chapter 7: OVSDB Monitoring Commands
show ovsdb interface
Supported Platforms
Syntax
Release Information
Description
Options
MX Series, QFX Series standalone switches
show ovsdb interface
<interface-name>
Command introduced in Junos OS Release 14.1R2.
Command introduced in Junos OS Release 14.1X53-D10 for QFX Series switches.
Display information about Open vSwitch Database (OVSDB)-managed interfaces
configured by using the interfaces interface-name statement in the [edit protocols ovsdb]
hierarchy.
none—Display information about all OVSDB-managed interfaces.
interface-name—Display information about the specified OVSDB-managed interface.
Required Privilege
Level
Related
Documentation
List of Sample Output
Output Fields
admin
•
Configuring OVSDB-Managed VXLANs on page 66
•
show ovsdb statistics interface on page 107
show ovsdb interface on page 99
show ovsdb (Specific Interface) on page 100
Table 15 on page 99 lists the output fields for the show ovsdb interface command. Output
fields are listed in the approximate order in which they appear.
Table 15: show ovsdb interface Output Fields
Field Name
Field Description
Interface
Name of interface.
VLAN ID
ID of Virtual Extensible LAN (VXLAN) with which the interface is associated.
NOTE: This field is not supported by MX Series routers..
Bridge domain or VLAN under which the VXLAN is created.
Bridge domain or VLAN
NOTE: This field is not supported by MX Series routers.
Sample Output
show ovsdb interface
user@host> show ovsdb interface
Interface
VLAN ID
ge-7/0/9.0
ge-7/0/9.1
Copyright © 2014, Juniper Networks, Inc.
Bridge-domain
99
OVSDB and VXLAN Feature Guide
irb.11
irb.12
irb.2
irb.3
xe-10/3/0.0
xe-10/3/0.1
show ovsdb (Specific Interface)
user@host> show ovsdb interface ge-7/0/9.0
Interface
VLAN ID
Bridge-domain
ge-7/0/9.0
100
Copyright © 2014, Juniper Networks, Inc.
Chapter 7: OVSDB Monitoring Commands
show ovsdb logical-switch
Supported Platforms
Syntax
Release Information
Description
MX Series, QFX Series standalone switches
show ovsdb logical-switch
<logical-switch-name>
Command introduced in Junos OS Release 14.1R2.
Command introduced in Junos OS Release 14.1X53-D10 for QFX Series switches.
Display information about logical switches, which you configured in NSX Manager or the
NSX API, and the corresponding Virtual Extensible LANs (VXLANs), which were configured
on the Juniper Networks device.
In the command output, each logical switch is identified by a universally unique identifier
(UUID), which in the context of this command, is also known as a logical switch name.
The show ovsdb logical-switch command displays the state of the logical switch (Flags),
which can be one of the following:
Created by Controller—A logical switch was configured in NSX Manager. In this state, the
logical switch and corresponding VXLAN are not yet operational.
Created by L2ALD—A VXLAN was configured on a Juniper Networks device. In this state,
the logical switch-VXLAN are not yet operational.
Created by both—A logical switch was configured in NSX Manager, and a corresponding
VXLAN was configured on a Juniper Networks device. In this state, the logical
switch-VXLAN are operational.
Tunnel key mismatch—The VNIs specified in the logical switch and corresponding VXLAN
configurations do not match. In this state, the logical switch-VXLAN are not yet
operational.
For more information about configuring the logical switch and corresponding VXLAN,
see “Understanding How to Set Up Virtual Extensible LANs in an Open vSwitch Database
Environment” on page 10.
Options
none—Display information about all logical switches that are present in the OVSDB
schema for physical devices.
logical-switch-name—Display information about the specified logical switch.
Required Privilege
Level
Related
Documentation
admin
•
Open vSwitch Database Schema For Physical Devices on page 14
•
Troubleshooting a Nonoperational VMware NSX Logical Switch and Corresponding
Junos OS OVSDB-Managed VXLAN on page 131
Copyright © 2014, Juniper Networks, Inc.
101
OVSDB and VXLAN Feature Guide
List of Sample Output
Output Fields
show ovsdb logical-switch on page 102
show ovsdb logical-switch (Specific Logical Switch) on page 102
Table 16 on page 102 lists the output fields for the show ovsdb logical-switch command.
Output fields are listed in the approximate order in which they appear.
Table 16: show ovsdb logical-switch Output Fields
Field Name
Field Description
Logical Switch Name
UUID that is automatically generated by NSX and assigned to the logical switch after you configure
it in NSX Manager or the NSX API. When configuring the corresponding VXLAN in the Junos OS
CLI, the same UUID must be specified as the VXLAN name.
Flags
State of the logical switch. For possible states, see the Description section of this topic.
VNI
VNI that is configured for the logical switch and corresponding VXLAN.
Num of Remote MAC
The total number of remote MAC addresses associated with the logical switch. These addresses
are learned by software and hardware virtual tunnel endpoints (VTEPs) in the NSX environment.
Num of Local MAC
The total number of local MAC addresses associated with the logical switch. Local MAC addresses
are addresses learned on the local physical ports.
Sample Output
show ovsdb logical-switch
user@host> show ovsdb logical-switch
Logical switch information:
Logical Switch Name: 24a76aff-7e61-4520-a78d-3eca26ad7510
Flags: Created by both
VNI: 3
Num of Remote MAC: 13
Num of Local MAC: 12
Logical Switch Name: 9b4f880e-dac8-4612-a832-97ad9dec270f
Flags: Created by Controller
VNI: 50
Num of Remote MAC: 0
Num of Local MAC: 0
Logical Switch Name: bc0da2da-6c16-44bf-b655-442484294ded
Flags: Created by Controller
VNI: 51
Num of Remote MAC: 0
Num of Local MAC: 0
show ovsdb logical-switch (Specific Logical Switch)
user@host> show ovsdb logical-switch 24a76aff-7e61-4520-a78d-3eca26ad7510
Logical switch information:
Logical Switch Name: 24a76aff-7e61-4520-a78d-3eca26ad7510
Flags: Created by both
VNI: 3
Num of Remote MAC: 13
Num of Local MAC: 12
102
Copyright © 2014, Juniper Networks, Inc.
Chapter 7: OVSDB Monitoring Commands
show ovsdb mac
Supported Platforms
Syntax
Release Information
MX Series, QFX Series standalone switches
show ovsdb mac
<address mac-address>
<local>
<logical-switch logical-switch-uuid>
<multicast>
<remote>
<unicast>
Command introduced in Junos OS Release 14.1R2.
Command introduced in Junos OS Release 14.1X53-D10 for QFX Series switches.
Description
Display MAC addresses, as well as information about the MAC addresses, learned by a
Juniper Networks device that functions as a hardware virtual tunnel endpoint (VTEP).
Using the Open vSwitch Database (OVSDB) management protocol, this hardware VTEP
can learn about MAC addresses directly or from other software or hardware VTEPs. The
MAC addresses learned directly by the hardware VTEP are known as local addresses,
while the addresses learned from other software or hardware VTEPs are known as remote
addresses.
Options
Use one or more of the following options to display a more specific list of MAC addresses
and information about the MAC addresses. For example, to display a list of local unicast
MAC addresses, you can issue the show ovsdb mac local unicast command.
none—Display all MAC addresses, which includes all local, remote, unicast, and multicast
addresses associated with all logical switches.
address mac-address—Display the specified MAC address.
local—Display all local MAC addresses.
logical-switch logical-switch-uuid—Display all MAC addresses associated with the specified
logical switch.
multicast—Display all multicast MAC addresses.
remote—Display all remote MAC addresses.
unicast—Display all unicast MAC addresses.
Required Privilege
Level
Related
Documentation
List of Sample Output
admin
•
Open vSwitch Database Schema For Physical Devices on page 14
show ovsdb mac on page 104
show ovsdb mac address on page 105
show ovsdb mac logical-switch on page 105
Copyright © 2014, Juniper Networks, Inc.
103
OVSDB and VXLAN Feature Guide
show ovsdb mac local unicast on page 105
Output Fields
Table 17 on page 104 lists the output fields for the show ovsdb mac command. Output
fields are listed in the approximate order in which they appear.
Table 17: show ovsdb mac Output Fields
Field Name
Field Description
Logical Switch Name
Universally unique identifier (UUID) of the logical switch. For more information about logical
switches and UUIDs, see “Understanding How to Set Up Virtual Extensible LANs in an Open
vSwitch Database Environment” on page 10.
MAC Address
MAC addresses of virtual machines (VMs).
IP Address
IP address of VMs.
NOTE: If the IP addresses of VMs are not published by the NSX controller, this field displays
0.0.0.0.
Encapsulation
Encapsulation type.
VTEP Address
IP address of the hardware or software VTEP from which the MAC address was learned.
Further, this VTEP can forward VM traffic to the associated host.
Sample Output
show ovsdb mac
104
user@host> show ovsdb mac
Logical Switch Name: 24a76aff-7e61-4520-a78d-3eca26ad7510
Mac
IP
Encapsulation
Address
Address
02:00:00:00:03:01
0.0.0.0
Vxlan over Ipv4
02:00:00:00:03:02
0.0.0.0
Vxlan over Ipv4
02:00:00:00:03:03
0.0.0.0
Vxlan over Ipv4
02:00:00:00:03:04
0.0.0.0
Vxlan over Ipv4
02:00:00:00:03:05
0.0.0.0
Vxlan over Ipv4
04:00:00:00:03:05
0.0.0.0
Vxlan over Ipv4
06:00:00:00:03:01
0.0.0.0
Vxlan over Ipv4
06:00:00:00:03:02
0.0.0.0
Vxlan over Ipv4
06:00:00:00:03:03
0.0.0.0
Vxlan over Ipv4
06:00:00:00:03:04
0.0.0.0
Vxlan over Ipv4
06:00:00:00:03:05
0.0.0.0
Vxlan over Ipv4
40:b4:f0:06:6f:f0
0.0.0.0
Vxlan over Ipv4
ff:ff:ff:ff:ff:ff
0.0.0.0
Vxlan over Ipv4
Vtep
Address
10.255.18.22
10.255.18.22
10.255.18.22
10.255.18.22
10.255.18.22
10.255.18.22
10.255.18.22
10.255.18.22
10.255.18.22
10.255.18.22
10.255.18.22
10.255.18.22
10.100.100.1
Logical Switch Name: bf6d4fd4-f5f6-430c-8c37-4033ef1c55ab
Mac
IP
Encapsulation
Address
Address
02:00:00:00:11:01
0.0.0.0
Vxlan over Ipv4
02:00:00:00:11:02
0.0.0.0
Vxlan over Ipv4
02:00:00:00:11:03
0.0.0.0
Vxlan over Ipv4
02:00:00:00:11:04
0.0.0.0
Vxlan over Ipv4
02:00:00:00:11:05
0.0.0.0
Vxlan over Ipv4
04:00:00:00:11:05
0.0.0.0
Vxlan over Ipv4
06:00:00:00:11:01
0.0.0.0
Vxlan over Ipv4
06:00:00:00:11:02
0.0.0.0
Vxlan over Ipv4
Vtep
Address
10.1.1.29
10.1.1.29
10.1.1.29
10.1.1.29
10.1.1.29
10.1.1.29
10.1.1.29
10.1.1.29
Copyright © 2014, Juniper Networks, Inc.
Chapter 7: OVSDB Monitoring Commands
06:00:00:00:11:03
06:00:00:00:11:04
06:00:00:00:11:05
40:b4:f0:06:6f:f0
00:23:9c:5e:a7:f0
08:00:00:00:11:01
08:00:00:00:11:02
08:00:00:00:11:03
08:00:00:00:11:04
08:00:00:00:11:05
ff:ff:ff:ff:ff:ff
...
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
Vxlan
Vxlan
Vxlan
Vxlan
Vxlan
Vxlan
Vxlan
Vxlan
Vxlan
Vxlan
Vxlan
over
over
over
over
over
over
over
over
over
over
over
Ipv4
Ipv4
Ipv4
Ipv4
Ipv4
Ipv4
Ipv4
Ipv4
Ipv4
Ipv4
Ipv4
10.1.1.29
10.1.1.29
10.1.1.29
10.1.1.29
10.255.18.22
10.255.18.22
10.255.18.22
10.255.18.22
10.255.18.22
10.255.18.22
10.110.110.1
show ovsdb mac address
user@host> show ovsdb mac address 02:00:00:00:03:01
Mac
Address
02:00:00:00:03:01
IP
Address
0.0.0.0
Encapsulation
Vxlan over Ipv4
Vtep
Address
10.255.18.22
show ovsdb mac logical-switch
user@host> show ovsdb mac logical-switch bf6d4fd4-f5f6-430c-8c37-4033ef1c55ab
Logical Switch Name: bf6d4fd4-f5f6-430c-8c37-4033ef1c55ab
Mac
IP
Encapsulation
Vtep
Address
Address
Address
02:00:00:00:11:01
0.0.0.0
Vxlan over Ipv4
10.1.1.29
02:00:00:00:11:02
0.0.0.0
Vxlan over Ipv4
10.1.1.29
02:00:00:00:11:03
0.0.0.0
Vxlan over Ipv4
10.1.1.29
02:00:00:00:11:04
0.0.0.0
Vxlan over Ipv4
10.1.1.29
02:00:00:00:11:05
0.0.0.0
Vxlan over Ipv4
10.1.1.29
04:00:00:00:11:05
0.0.0.0
Vxlan over Ipv4
10.1.1.29
06:00:00:00:11:01
0.0.0.0
Vxlan over Ipv4
10.1.1.29
06:00:00:00:11:02
0.0.0.0
Vxlan over Ipv4
10.1.1.29
06:00:00:00:11:03
0.0.0.0
Vxlan over Ipv4
10.1.1.29
06:00:00:00:11:04
0.0.0.0
Vxlan over Ipv4
10.1.1.29
06:00:00:00:11:05
0.0.0.0
Vxlan over Ipv4
10.1.1.29
40:b4:f0:06:6f:f0
0.0.0.0
Vxlan over Ipv4
10.1.1.29
00:23:9c:5e:a7:f0
0.0.0.0
Vxlan over Ipv4
10.255.18.22
08:00:00:00:11:01
0.0.0.0
Vxlan over Ipv4
10.255.18.22
08:00:00:00:11:02
0.0.0.0
Vxlan over Ipv4
10.255.18.22
08:00:00:00:11:03
0.0.0.0
Vxlan over Ipv4
10.255.18.22
08:00:00:00:11:04
0.0.0.0
Vxlan over Ipv4
10.255.18.22
08:00:00:00:11:05
0.0.0.0
Vxlan over Ipv4
10.255.18.22
ff:ff:ff:ff:ff:ff
0.0.0.0
Vxlan over Ipv4
10.110.110.1
show ovsdb mac local unicast
user@host> show ovsdb mac local unicast
Logical Switch Name: 24a76aff-7e61-4520-a78d-3eca26ad7510
Mac
IP
Encapsulation
Address
Address
02:00:00:00:03:01
0.0.0.0
Vxlan over Ipv4
02:00:00:00:03:02
0.0.0.0
Vxlan over Ipv4
02:00:00:00:03:03
0.0.0.0
Vxlan over Ipv4
02:00:00:00:03:04
0.0.0.0
Vxlan over Ipv4
02:00:00:00:03:05
0.0.0.0
Vxlan over Ipv4
04:00:00:00:03:05
0.0.0.0
Vxlan over Ipv4
06:00:00:00:03:01
0.0.0.0
Vxlan over Ipv4
06:00:00:00:03:02
0.0.0.0
Vxlan over Ipv4
06:00:00:00:03:03
0.0.0.0
Vxlan over Ipv4
Copyright © 2014, Juniper Networks, Inc.
Vtep
Address
10.255.181.72
10.255.181.72
10.255.181.72
10.255.181.72
10.255.181.72
10.255.181.72
10.255.181.72
10.255.181.72
10.255.181.72
105
OVSDB and VXLAN Feature Guide
06:00:00:00:03:04
06:00:00:00:03:05
40:b4:f0:06:6f:f0
...
106
0.0.0.0
0.0.0.0
0.0.0.0
Vxlan over Ipv4
Vxlan over Ipv4
Vxlan over Ipv4
10.255.181.72
10.255.181.72
10.255.181.72
Copyright © 2014, Juniper Networks, Inc.
Chapter 7: OVSDB Monitoring Commands
show ovsdb statistics interface
Supported Platforms
Syntax
Release Information
Description
MX Series, QFX Series standalone switches
show ovsdb statistics interface
<interface-name>
Command introduced in Junos OS Release 14.1R2.
Command introduced in Junos OS Release 14.1X53-D10 for QFX Series switches.
Display statistics for Open vSwitch Database (OVSDB)-managed interfaces configured
by using the interfaces interface-name statement in the [edit protocols ovsdb] hierarchy.
When an interface is configured as OVSDB-managed, the collection of statistics for that
interface begins, and the statistics displayed at any given time reflects the data collected
up to that point.
Options
none—Display statistics for all configured OVSDB-managed interfaces.
interface-name—Display statistics for the specified interface.
Required Privilege
Level
Related
Documentation
List of Sample Output
Output Fields
admin
•
interfaces on page 75
show ovsdb statistics interface on page 107
show ovsdb statistics interface (Specific Interface) on page 108
Table 18 on page 107 lists the output fields for the show ovsdb statistics interface command.
Output fields are listed in the approximate order in which they appear.
Table 18: show ovsdb statistics interface Output Fields
Field Name
Field Descriptions
Num of rx pkts
Number of packets received by the interface.
Num of tx pkts
Number of packets sent by the interface.
Num of rx bytes
Number of bytes received by the interface.
Num of tx bytes
Number of bytes sent by the interface.
Sample Output
show ovsdb statistics interface
user@host> show ovsdb statistics interface
Interface Name: ge-7/0/9.0
Num of rx pkts: 945
Num of tx pkts: 113280890
Copyright © 2014, Juniper Networks, Inc.
107
OVSDB and VXLAN Feature Guide
Num of rx
Interface
Num of rx
Num of rx
Interface
Num of rx
Num of rx
bytes: 56700
Name: ge-7/0/10.0
pkts: 459
bytes: 84747
Name: ge-7/0/11.0
pkts: 305
bytes: 98974
Num of tx bytes: 57531319540
Num of tx pkts: 473840856
Num of tx bytes: 45830738532
Num of tx pkts: 367483456
Num of tx bytes: 33495468092
show ovsdb statistics interface (Specific Interface)
user@host> show ovsdb statistics interface ge-7/0/9.0
Interface Name: ge-7/0/9.0
Num of rx pkts: 945
Num of tx pkts: 113280890
Num of rx bytes: 56700
Num of tx bytes: 57531319540
108
Copyright © 2014, Juniper Networks, Inc.
Chapter 7: OVSDB Monitoring Commands
show ovsdb virtual-tunnel-end-point
Supported Platforms
Syntax
Release Information
Description
Options
MX Series, QFX Series standalone switches
show ovsdb virtual-tunnel-end-point
address <ip-address>
encapsulation <encapsulation-type>
Command introduced in Junos OS Release 14.1R2.
Command introduced in Junos OS Release 14.1X53-D10 for QFX Series switches.
Display information about the following entities that the Juniper Networks device has
learned:
•
Other Juniper Networks devices that function as hardware virtual tunnel endpoints
(VTEPs)
•
Software VTEPs
•
Service nodes
none—Display information about all VTEPs and service nodes that the Juniper Networks
device has learned.
address ip-address—Display information about the entity with specified IP address.
encapsulation encapsulation-type—Display information about all entities with the specified
encapsulation type.
Required Privilege
Level
List of Sample Output
Output Fields
admin
show ovsdb virtual-tunnel-end-point on page 110
show ovsdb virtual-tunnel-end-point address (Specific Address) on page 110
show ovsdb virtual-tunnel-end-point encapsulation (Specific
Encapsulation) on page 110
show ovsdb virtual-tunnel-end-point address (Specific Address) encapsulation
(Specific Encapsulation) on page 110
Table 19 on page 109 lists the output fields for the show ovsdb virtual-tunnel-end-point
command. Output fields are listed in the approximate order in which they appear.
Table 19: show ovsdb virtual-tunnel-end-point Output Fields
Field Name
Field Description
Encapsulation
Encapsulation type of entity.
IP Address
IP address of entity.
Num of MACs
Number of MAC addresses learned by the entity.
Copyright © 2014, Juniper Networks, Inc.
109
OVSDB and VXLAN Feature Guide
Sample Output
show ovsdb virtual-tunnel-end-point
user@host> show ovsdb virtual-tunnel-end-point
Encapsulation
Ip Address
VXLAN over IPv4
10.255.181.43
VXLAN over IPv4
10.255.181.50
VXLAN over IPv4
10.255.181.72
Num of MAC's
24
12
24
show ovsdb virtual-tunnel-end-point address (Specific Address)
user@host> show ovsdb virtual-tunnel-end-point address 10.255.181.43
Encapsulation
Ip Address
VXLAN over IPv4
10.255.181.43
Num of MAC's
24
show ovsdb virtual-tunnel-end-point encapsulation (Specific Encapsulation)
user@host> show ovsdb virtual-tunnel-end-point encapsulation vxlan-over-ipv4
Encapsulation
Ip Address
Num of MAC's
VXLAN over IPv4
10.255.181.43
24
VXLAN over IPv4
10.255.181.50
12
VXLAN over IPv4
10.255.181.72
24
show ovsdb virtual-tunnel-end-point address (Specific Address) encapsulation (Specific Encapsulation)
user@host> show ovsdb virtual-tunnel-end-point address 10.255.181.43 encapsulation
vxlan-over-ipv4
Encapsulation
Ip Address
Num of MAC's
VXLAN over IPv4
10.255.181.43
24
110
Copyright © 2014, Juniper Networks, Inc.
Chapter 7: OVSDB Monitoring Commands
show vpls mac-table
Supported Platforms
Syntax
Release Information
Description
Options
MX960
show vpls mac-table
<brief | detail | extensive | summary>
<bridge-domain bridge-domain-name>
<instance instance-name>
<interface interface-name>
<logical-system (all | logical-system-name)>
<mac-address>
<vlan-id vlan-id-number>
Command introduced in Junos OS Release 8.5.
(MX960 routers only) Display learned VPLS MAC address information.
none—Display all learned VPLS MAC address information.
brief | detail | extensive | summary—(Optional) Display the specified level of output.
bridge-domain bridge-domain-name—(Optional) Display learned VPLS MAC addresses
for the specified bridge domain.
instance instance-name—(Optional) Display learned VPLS MAC addresses for the specified
instance.
interface interface-name—(Optional) Display learned VPLS MAC addresses for the
specified instance.
logical-system (all | logical-system-name)—(Optional) Display learned VPLS MAC
addresses for all logical systems or for the specified logical system.
mac-address—(Optional) Display the specified learned VPLS MAC address information..
vlan-id vlan-id-number—(Optional) Display learned VPLS MAC addresses for the specified
VLAN.
Required Privilege
Level
List of Sample Output
Output Fields
view
show vpls mac-table on page 112
show vpls mac-table (with VXLAN enabled) on page 113
show vpls mac-table count on page 113
show vpls mac-table detail on page 114
show vpls mac-table extensive on page 114
Table 20 on page 112 describes the output fields for the show bridge mac-table command.
Output fields are listed in the approximate order in which they appear.
Copyright © 2014, Juniper Networks, Inc.
111
OVSDB and VXLAN Feature Guide
Table 20: show vpls mac-table Output fields
Field Name
Field Description
Routing instance
Name of the routing instance.
Bridging domain
Name of the bridging domain.
MAC address
MAC address or addresses learned on a logical interface.
MAC flags
Status of MAC address learning properties for each interface:
•
S—Static MAC address configured.
•
D—Dynamic MAC address learned.
•
SE—MAC accounting is enabled.
•
NM—Nonconfigured MAC.
Logical interface
Name of the logical interface.
MAC count
Number of MAC addresses learned on a specific routing instance or interface.
Learning interface
Logical interface or logical Label Switched Interface (LSI) the address is learned on.
Learn VLAN ID/VLAN
VLAN ID of the routing instance or bridge domain in which the MAC address was learned.
VXLAN ID/VXLAN
VXLAN Network Identifier (VNI)
Layer 2 flags
Debugging flags signifying that the MAC address is present in various lists.
Epoch
Spanning Tree Protocol epoch number identifying when the MAC address was learned. Used for
debugging.
Sequence number
Sequence number assigned to this MAC address. Used for debugging.
Learning mask
Mask of Packet Forwarding Engines where this MAC address was learned. Used for debugging.
IPC generation
Creation time of the logical interface when this MAC address was learned. Used for debugging.
Sample Output
show vpls mac-table
user@host> show vpls mac-table
MAC flags (S -static MAC, D -dynamic MAC,
SE -Statistics enabled, NM -Non configured MAC)
Routing instance : vpls_ldp1
VLAN : 223
MAC
MAC
address
flags
00:90:69:9c:1c:5d
D
Logical
interface
ge-0/2/5.400
MAC flags (S -static MAC, D -dynamic MAC,
112
Copyright © 2014, Juniper Networks, Inc.
Chapter 7: OVSDB Monitoring Commands
SE -Statistics enabled, NM -Non configured MAC)
Routing instance : vpls_red
VLAN : 401
MAC
MAC
address
flags
00:00:aa:12:12:12
D
00:05:85:74:9f:f0
D
Logical
interface
lsi.1051138
lsi.1051138
show vpls mac-table (with VXLAN enabled)
user@host> show vpls mac-table
MAC flags (S -static MAC, D -dynamic MAC, L -locally learned
SE -Statistics enabled, NM -Non configured MAC, R -Remote PE MAC)
Routing instance : vpls_4site:1000
Bridging domain : __vpls_4site:1000__, VLAN : 4094,4093
VXLAN: Id : 300, Multicast group: 226.1.1.3
MAC
MAC
Logical
address
flags
interface
00:01:01:00:01:f4
D,SE
ge-4/2/0.1000
00:02:01:33:01:f4
D,SE
lsi.1052004
00:03:00:32:01:f4
D,SE
lsi.1048840
00:04:00:14:01:f4
D,SE
lsi.1052005
00:02:01:33:02:f7
D,SE
vtep.1052010
00:04:00:14:02:f7
D,SE
vtep.1052011
show vpls mac-table count
user@host> show vpls mac-table count
0 MAC address learned in routing instance __juniper_private1__
MAC address count per interface within routing instance:
Logical interface
MAC count
lc-0/0/0.32769
0
lc-0/1/0.32769
0
lc-0/2/0.32769
0
lc-2/0/0.32769
0
lc-0/3/0.32769
0
lc-2/1/0.32769
0
lc-9/0/0.32769
0
lc-11/0/0.32769
0
lc-2/2/0.32769
0
lc-9/1/0.32769
0
lc-11/1/0.32769
0
lc-2/3/0.32769
0
lc-9/2/0.32769
0
lc-11/2/0.32769
0
lc-11/3/0.32769
0
lc-9/3/0.32769
0
MAC address count per learn VLAN within routing instance:
Learn VLAN ID
MAC count
0
0
1 MAC address learned in routing instance vpls_ldp1
MAC address count per interface within routing instance:
Logical interface
MAC count
lsi.1051137
0
ge-0/2/5.400
1
Copyright © 2014, Juniper Networks, Inc.
113
OVSDB and VXLAN Feature Guide
MAC address count per learn VLAN within routing instance:
Learn VLAN ID
MAC count
0
1
1 MAC address learned in routing instance vpls_red
MAC address count per interface within routing instance:
Logical interface
MAC count
ge-0/2/5.300
1
MAC address count per learn VLAN within routing instance:
Learn VLAN ID
MAC count
0
1
show vpls mac-table detail
user@host> show vpls mac-table detail
MAC address: 00:90:69:9c:1c:5d
Routing instance: vpls_ldp1
Learning interface: ge-0/2/5.400
Layer 2 flags: in_ifd, in_ifl, in_vlan, kernel
Epoch: 0
Sequence number: 1
Learning mask: 0x1
IPC generation: 0
MAC address: 00:90:69:9c:1c:5d
Routing instance: vpls_red
Learning interface: ge-0/2/5.300
Layer 2 flags: in_ifd, in_ifl, in_vlan, kernel
Epoch: 0
Sequence number: 1
Learning mask: 0x1
IPC generation: 0
show vpls mac-table extensive
user@host> show vpls mac-table extensive
MAC address: 00:00:aa:12:12:12
Routing instance: vpls_ldp1
Learning interface: lsi.1051137
Layer 2 flags: in_ifd, in_ifl, in_vlan, kernel
Epoch: 0
Sequence number: 1
Learning mask: 0x1
IPC generation: 0
MAC address: 00:05:85:74:9f:f0
Routing instance: vpls_ldp1
Learning interface: lsi.1051137
Layer 2 flags: in_ifd, in_ifl, in_vlan, kernel
Epoch: 0
Sequence number: 1
Learning mask: 0x1
IPC generation: 0
MAC address: 00:90:69:9c:1c:5d
Routing instance: vpls_ldp1
Learning interface: ge-0/2/5.400
Layer 2 flags: in_ifd, in_ifl, in_vlan, kernel
Epoch: 0
Sequence number: 1
Learning mask: 0x1
IPC generation: 0
MAC address: 00:00:aa:12:12:12
Routing instance: vpls_red
Learning interface: lsi.1051138
Layer 2 flags: in_ifd, in_ifl, in_vlan, kernel
Epoch: 0
Sequence number: 0
114
Copyright © 2014, Juniper Networks, Inc.
Chapter 7: OVSDB Monitoring Commands
Learning mask: 0x1
IPC generation: 0
MAC address: 00:05:85:74:9f:f0
Routing instance: vpls_red
Learning interface: lsi.1051138
Layer 2 flags: in_ifd, in_ifl, in_vlan, kernel
Epoch: 0
Sequence number: 0
Learning mask: 0x1
IPC generation: 0
Copyright © 2014, Juniper Networks, Inc.
115
OVSDB and VXLAN Feature Guide
116
Copyright © 2014, Juniper Networks, Inc.
CHAPTER 8
VXLAN Monitoring Commands
•
show bridge mac-table
•
show vpls mac-table
•
Verifying VXLAN Reachability on page 126
•
Verifying That a Local VXLAN VTEP is Configured Correctly on page 126
•
Verifying MAC Learning from a Remote VTEP on page 127
•
Monitor a Remote VTEP Interface on page 127
Copyright © 2014, Juniper Networks, Inc.
117
OVSDB and VXLAN Feature Guide
show bridge mac-table
Supported Platforms
Syntax
Release Information
Description
Options
MX Series
show bridge mac-table
<brief | count | detail | extensive>
<bridge-domain (all | bridge-domain-name)>
<global-count>
<interface interface-name>
<mac-address>
<vlan-id (all-vlan | vlan-id)>
Command introduced in Junos OS Release 8.4.
(MX Series routers only) Display Layer 2 MAC address information.
none—Display all learned Layer 2 MAC address information.
brief | count | detail | extensive—(Optional) Display the specified level of output.
bridge-domain (all | bridge-domain-name)—(Optional) Display learned Layer 2 MAC
addresses for all bridging domains or for the specified bridging domain.
global-count—(Optional) Display the total number of learned Layer 2 MAC addresses
on the system.
instance instance-name—(Optional) Display learned Layer 2 MAC addresses for the
specified routing instance.
interface interface-name—(Optional) Display learned Layer 2 MAC addresses for the
specified interface.
mac-address—(Optional) Display the specified learned Layer 2 MAC address information.
vlan-id (all-vlan | vlan-id)—(Optional) Display learned Layer 2 MAC addresses for all
VLANs or for the specified VLAN.
Additional Information
Required Privilege
Level
List of Sample Output
Output Fields
118
When Layer 2 protocol tunneling is enabled, the tunneling MAC address 01:00:0c:cd:cd:d0
is installed in the MAC table. When the Cisco Discovery Protocol (CDP), Spanning Tree
Protocol (STP), or VLAN Trunk Protocol (VTP) is configured for Layer 2 protocol tunneling
on an interface, the corresponding protocol MAC address is installed in the MAC table.
view
show bridge mac-table on page 119
show bridge mac-table (with VXLAN enabled) on page 120
show bridge mac-table count on page 120
show bridge mac-table detail on page 121
Table 13 on page 93 describes the output fields for the show bridge mac-table command.
Output fields are listed in the approximate order in which they appear.
Copyright © 2014, Juniper Networks, Inc.
Chapter 8: VXLAN Monitoring Commands
Table 21: show bridge mac-table Output fields
Field Name
Field Description
Routing instance
Name of the routing instance.
Bridging domain
Name of the bridging domain.
MAC address
MAC address or addresses learned on a logical interface.
MAC flags
Status of MAC address learning properties for each interface:
•
S—Static MAC address is configured.
•
D—Dynamic MAC address is configured.
•
L—Locally learned MAC address is configured.
•
C—Control MAC address is configured.
•
SE—MAC accounting is enabled.
•
NM—Non-configured MAC.
•
R—Remote PE MAC address is configured.
Logical interface
Name of the logical interface.
MAC count
Number of MAC addresses learned on the specific routing instance or
interface.
Learning interface
Name of the logical interface on which the MAC address was learned.
Learning VLAN
VLAN ID of the routing instance or bridge domain in which the MAC address
was learned.
VXLAN ID/VXLAN
VXLAN Network Identifier (VNI)
Layer 2 flags
Debugging flags signifying that the MAC address is present in various lists.
Epoch
Spanning Tree Protocol epoch number identifying when the MAC address
was learned. Used for debugging.
Sequence number
Sequence number assigned to this MAC address. Used for debugging.
Learning mask
Mask of the Packet Forwarding Engines where this MAC address was learned.
Used for debugging.
IPC generation
Creation time of the logical interface when this MAC address was learned.
Used for debugging.
Sample Output
show bridge mac-table
user@host> show bridge mac-table
MAC flags (S -static MAC, D -dynamic MAC, L -locally learned, C -Control MAC
SE -Statistics enabled, NM -Non configured MAC, R -Remote PE MAC)
Copyright © 2014, Juniper Networks, Inc.
119
OVSDB and VXLAN Feature Guide
Routing instance : default-switch
Bridging domain : test1, VLAN : 1
MAC
MAC
Logical
address
flags
interface
01:00:0c:cc:cc:cc
S,NM
NULL
01:00:0c:cc:cc:cd
S,NM
NULL
01:00:0c:cd:cd:d0
S,NM
NULL
64:87:88:6a:17:d0
D
ae0.1
64:87:88:6a:17:f0
D
ae0.1
NH
Index
RTR
ID
show bridge mac-table (with VXLAN enabled)
user@host> show bridge mac-table
MAC flags (S -static MAC, D -dynamic MAC, L -locally learned
SE -Statistics enabled, NM -Non configured MAC, R -Remote PE MAC)
Routing instance : default-switch
Bridging domain : vlan-1, VLAN : 1
VXLAN: Id : 100, Multicast group: 226.1.1.1
MAC
MAC
Logical
address
flags
interface
00:01:01:00:01:f7
D,SE
vtep.1052010
00:03:00:32:01:f7
D,SE
vtep.1052011
00:00:21:11:11:10
DL
ge-1/0/0.0
00:00:21:11:11:11
DL
ge-1/1/0.0
Routing instance : default-switch
Bridging domain : vlan-2, VLAN : 2, VXLAN : 200
VXLAN: Id : 200, Multicast group: 226.1.1.2
MAC
MAC
Logical
address
flags
interface
00:02:01:33:01:f7
D,SE
vtep.1052010
00:04:00:14:01:f7
D,SE
vtep.1052011
00:00:21:11:21:10
DL
ge-1/0/0.1
00:00:21:11:21:11
DL
ge-1/1/0.1
show bridge mac-table count
user@host> show bridge mac-table count
2 MAC address learned in routing instance vs1 bridge domain vlan100
MAC address count per interface within routing instance:
Logical interface
MAC count
ge-11/0/3.0
1
ge-11/1/4.100
0
ge-11/1/1.100
0
ge-11/1/0.100
0
xe-10/2/0.100
1
xe-10/0/0.100
0
MAC address count per learn VLAN within routing instance:
Learn VLAN ID
MAC count
0
2
0 MAC address learned in routing instance vs1 bridge domain vlan200
MAC address count per interface within routing instance:
Logical interface
MAC count
120
Copyright © 2014, Juniper Networks, Inc.
Chapter 8: VXLAN Monitoring Commands
ge-11/1/0.200
ge-11/1/1.200
ge-11/1/4.200
xe-10/0/0.200
xe-10/2/0.200
0
0
0
0
0
MAC address count per learn VLAN within routing instance:
Learn VLAN ID
MAC count
0
0
show bridge mac-table detail
user@host> show bridge mac-table detail
MAC address: 00:00:00:19:1c:db
Routing instance: vs1
Bridging domain: vlan100
Learning interface: ge-11/0/3.0
Learning VLAN: 0
Layer 2 flags: in_ifd, in_ifl, in_vlan, kernel
Epoch: 4
Sequence number: 0
Learning mask: 0x800
IPC generation: 0
MAC address: 00:00:00:59:3a:2f
Routing instance: vs1
Bridging domain: vlan100
Learning interface: xe-10/2/0.100
Learning VLAN: 0
Layer 2 flags: in_ifd, in_ifl, in_vlan, kernel
Epoch: 7
Sequence number: 0
Learning mask: 0x400
IPC generation: 0
Copyright © 2014, Juniper Networks, Inc.
121
OVSDB and VXLAN Feature Guide
show vpls mac-table
Supported Platforms
Syntax
Release Information
Description
Options
show vpls mac-table
<brief | detail | extensive | summary>
<bridge-domain bridge-domain-name>
<instance instance-name>
<interface interface-name>
<logical-system (all | logical-system-name)>
<mac-address>
<vlan-id vlan-id-number>
Command introduced in Junos OS Release 8.5.
(MX960 routers only) Display learned VPLS MAC address information.
none—Display all learned VPLS MAC address information.
brief | detail | extensive | summary—(Optional) Display the specified level of output.
bridge-domain bridge-domain-name—(Optional) Display learned VPLS MAC addresses
for the specified bridge domain.
instance instance-name—(Optional) Display learned VPLS MAC addresses for the specified
instance.
interface interface-name—(Optional) Display learned VPLS MAC addresses for the
specified instance.
logical-system (all | logical-system-name)—(Optional) Display learned VPLS MAC
addresses for all logical systems or for the specified logical system.
mac-address—(Optional) Display the specified learned VPLS MAC address information..
vlan-id vlan-id-number—(Optional) Display learned VPLS MAC addresses for the specified
VLAN.
Required Privilege
Level
List of Sample Output
Output Fields
122
view
show vpls mac-table on page 123
show vpls mac-table (with VXLAN enabled) on page 124
show vpls mac-table count on page 124
show vpls mac-table detail on page 125
show vpls mac-table extensive on page 125
Table 20 on page 112 describes the output fields for the show bridge mac-table command.
Output fields are listed in the approximate order in which they appear.
Copyright © 2014, Juniper Networks, Inc.
Chapter 8: VXLAN Monitoring Commands
Table 22: show vpls mac-table Output fields
Field Name
Field Description
Routing instance
Name of the routing instance.
Bridging domain
Name of the bridging domain.
MAC address
MAC address or addresses learned on a logical interface.
MAC flags
Status of MAC address learning properties for each interface:
•
S—Static MAC address configured.
•
D—Dynamic MAC address learned.
•
SE—MAC accounting is enabled.
•
NM—Nonconfigured MAC.
Logical interface
Name of the logical interface.
MAC count
Number of MAC addresses learned on a specific routing instance or interface.
Learning interface
Logical interface or logical Label Switched Interface (LSI) the address is learned on.
Learn VLAN ID/VLAN
VLAN ID of the routing instance or bridge domain in which the MAC address was learned.
VXLAN ID/VXLAN
VXLAN Network Identifier (VNI)
Layer 2 flags
Debugging flags signifying that the MAC address is present in various lists.
Epoch
Spanning Tree Protocol epoch number identifying when the MAC address was learned. Used for
debugging.
Sequence number
Sequence number assigned to this MAC address. Used for debugging.
Learning mask
Mask of Packet Forwarding Engines where this MAC address was learned. Used for debugging.
IPC generation
Creation time of the logical interface when this MAC address was learned. Used for debugging.
Sample Output
show vpls mac-table
user@host> show vpls mac-table
MAC flags (S -static MAC, D -dynamic MAC,
SE -Statistics enabled, NM -Non configured MAC)
Routing instance : vpls_ldp1
VLAN : 223
MAC
MAC
address
flags
00:90:69:9c:1c:5d
D
Logical
interface
ge-0/2/5.400
MAC flags (S -static MAC, D -dynamic MAC,
Copyright © 2014, Juniper Networks, Inc.
123
OVSDB and VXLAN Feature Guide
SE -Statistics enabled, NM -Non configured MAC)
Routing instance : vpls_red
VLAN : 401
MAC
MAC
address
flags
00:00:aa:12:12:12
D
00:05:85:74:9f:f0
D
Logical
interface
lsi.1051138
lsi.1051138
show vpls mac-table (with VXLAN enabled)
user@host> show vpls mac-table
MAC flags (S -static MAC, D -dynamic MAC, L -locally learned
SE -Statistics enabled, NM -Non configured MAC, R -Remote PE MAC)
Routing instance : vpls_4site:1000
Bridging domain : __vpls_4site:1000__, VLAN : 4094,4093
VXLAN: Id : 300, Multicast group: 226.1.1.3
MAC
MAC
Logical
address
flags
interface
00:01:01:00:01:f4
D,SE
ge-4/2/0.1000
00:02:01:33:01:f4
D,SE
lsi.1052004
00:03:00:32:01:f4
D,SE
lsi.1048840
00:04:00:14:01:f4
D,SE
lsi.1052005
00:02:01:33:02:f7
D,SE
vtep.1052010
00:04:00:14:02:f7
D,SE
vtep.1052011
show vpls mac-table count
user@host> show vpls mac-table count
0 MAC address learned in routing instance __juniper_private1__
MAC address count per interface within routing instance:
Logical interface
MAC count
lc-0/0/0.32769
0
lc-0/1/0.32769
0
lc-0/2/0.32769
0
lc-2/0/0.32769
0
lc-0/3/0.32769
0
lc-2/1/0.32769
0
lc-9/0/0.32769
0
lc-11/0/0.32769
0
lc-2/2/0.32769
0
lc-9/1/0.32769
0
lc-11/1/0.32769
0
lc-2/3/0.32769
0
lc-9/2/0.32769
0
lc-11/2/0.32769
0
lc-11/3/0.32769
0
lc-9/3/0.32769
0
MAC address count per learn VLAN within routing instance:
Learn VLAN ID
MAC count
0
0
1 MAC address learned in routing instance vpls_ldp1
MAC address count per interface within routing instance:
Logical interface
MAC count
lsi.1051137
0
ge-0/2/5.400
1
124
Copyright © 2014, Juniper Networks, Inc.
Chapter 8: VXLAN Monitoring Commands
MAC address count per learn VLAN within routing instance:
Learn VLAN ID
MAC count
0
1
1 MAC address learned in routing instance vpls_red
MAC address count per interface within routing instance:
Logical interface
MAC count
ge-0/2/5.300
1
MAC address count per learn VLAN within routing instance:
Learn VLAN ID
MAC count
0
1
show vpls mac-table detail
user@host> show vpls mac-table detail
MAC address: 00:90:69:9c:1c:5d
Routing instance: vpls_ldp1
Learning interface: ge-0/2/5.400
Layer 2 flags: in_ifd, in_ifl, in_vlan, kernel
Epoch: 0
Sequence number: 1
Learning mask: 0x1
IPC generation: 0
MAC address: 00:90:69:9c:1c:5d
Routing instance: vpls_red
Learning interface: ge-0/2/5.300
Layer 2 flags: in_ifd, in_ifl, in_vlan, kernel
Epoch: 0
Sequence number: 1
Learning mask: 0x1
IPC generation: 0
show vpls mac-table extensive
user@host> show vpls mac-table extensive
MAC address: 00:00:aa:12:12:12
Routing instance: vpls_ldp1
Learning interface: lsi.1051137
Layer 2 flags: in_ifd, in_ifl, in_vlan, kernel
Epoch: 0
Sequence number: 1
Learning mask: 0x1
IPC generation: 0
MAC address: 00:05:85:74:9f:f0
Routing instance: vpls_ldp1
Learning interface: lsi.1051137
Layer 2 flags: in_ifd, in_ifl, in_vlan, kernel
Epoch: 0
Sequence number: 1
Learning mask: 0x1
IPC generation: 0
MAC address: 00:90:69:9c:1c:5d
Routing instance: vpls_ldp1
Learning interface: ge-0/2/5.400
Layer 2 flags: in_ifd, in_ifl, in_vlan, kernel
Epoch: 0
Sequence number: 1
Learning mask: 0x1
IPC generation: 0
MAC address: 00:00:aa:12:12:12
Routing instance: vpls_red
Learning interface: lsi.1051138
Layer 2 flags: in_ifd, in_ifl, in_vlan, kernel
Epoch: 0
Sequence number: 0
Copyright © 2014, Juniper Networks, Inc.
125
OVSDB and VXLAN Feature Guide
Learning mask: 0x1
IPC generation: 0
MAC address: 00:05:85:74:9f:f0
Routing instance: vpls_red
Learning interface: lsi.1051138
Layer 2 flags: in_ifd, in_ifl, in_vlan, kernel
Epoch: 0
Sequence number: 0
Learning mask: 0x1
IPC generation: 0
Verifying VXLAN Reachability
Supported Platforms
Purpose
Action
Meaning
Related
Documentation
QFX Series standalone switches
On the local VTEP, verify that there is connectivity with the remote VTEP.
user@switch> show ethernet-switching vxlan-tunnel-end-point remote
Logical System Name
Id SVTEP-IP
IFL
L3-Idx
<default>
0
10.1.1.2
lo0.0
0
RVTEP-IP
IFL-Idx
NH-Id
10.1.1.2
559
1728
VNID
MC-Group-IP
100
232.1.1.1
The remote VTEP is reachable because its IP address appears in the output. The output
also shows that the VXLAN (VNI 100) and corresponding multicast group are configured
correctly on the remote VTEP.
•
Understanding VXLANs on page 17
•
Configuring VXLANs on a QFX5100 Switch on page 69
•
Examples: Configuring VXLANs on QFX Series Switches on page 51
Verifying That a Local VXLAN VTEP is Configured Correctly
Supported Platforms
Purpose
Action
QFX Series standalone switches
Verify that a local VTEP is correct..
user@switch> show ethernet-switching vxlan-tunnel-end-point source
Logical System Name
<default>
L2-RTT
default-switch
Meaning
Related
Documentation
126
Id SVTEP-IP
0
10.1.1.1
Bridge Domain
VLAN1+100
IFL
lo0.0
L3-Idx
0
VNID
100
MC-Group-IP
232.1.1.1
The output should show the correct tunnel source IP address (loopback address), VLAN,
and multicast group for the VXLAN.
•
Understanding VXLANs on page 17
•
Configuring VXLANs on a QFX5100 Switch on page 69
Copyright © 2014, Juniper Networks, Inc.
Chapter 8: VXLAN Monitoring Commands
•
Examples: Configuring VXLANs on QFX Series Switches on page 51
Verifying MAC Learning from a Remote VTEP
Supported Platforms
Purpose
Action
QFX Series standalone switches
Verify that a local VTEP is learning MAC addresses from a remote VTEP.
user@switch> show ethernet-switching table
MAC flags (S - static MAC, D - dynamic MAC, L - locally learned, P - Persistent
static
SE - statistics enabled, NM - non configured MAC, R - remote PE MAC)
Ethernet switching table : 2 entries, 2 learned
Routing instance : default-switch
Vlan
MAC
MAC
Age
Logical
name
address
flags
interface
VLAN1
00:00:00:ff:ff:ff
D
vtep.12345
VLAN1
00:10:94:00:00:02
D
xe-0/0/0.0
Meaning
Related
Documentation
This shows the MAC addresses learned from the remote VTEP (in addition to those
learned on the normal Layer 2 interfaces). It also shows the logical name of the remote
VTEP interface (vtep.12345 in the above output).
•
Understanding VXLANs on page 17
•
Configuring VXLANs on a QFX5100 Switch on page 69
•
Examples: Configuring VXLANs on QFX Series Switches on page 51
Monitor a Remote VTEP Interface
Supported Platforms
Purpose
QFX Series standalone switches
Monitor traffic details for a remote VTEP interface.
Copyright © 2014, Juniper Networks, Inc.
127
OVSDB and VXLAN Feature Guide
Action
user@switch> show interface logical-name detail
M
Flags: Up SNMP-Traps Encapsulation: ENET2
VXLAN Endpoint Type: Remote, VXLAN Endpoint Address: 10.1.1.2, L2 Routing
Instance: default-switch, L3 Routing Instance: default
Traffic statistics:
Input bytes :
228851738624
Output bytes :
0
Input packets:
714162415
Output packets:
0
Local statistics:
Input bytes :
0
Output bytes :
0
Input packets:
0
Output packets:
0
Transit statistics:
Input bytes :
228851738624
0 bps
Output bytes :
0
0 bps
Input packets:
714162415
0 pps
Output packets:
0
0 pps
Protocol eth-switch, MTU: 1600, Generation: 277, Route table: 5
Meaning
Related
Documentation
128
This shows traffic details for the remote VTEP interface. To get this information, you
must supply the logical name of the remote VTEP interface (vtep.12345 in the above
output), which you can learn by using the show ethernet-switching table command.
•
Understanding VXLANs on page 17
•
Configuring VXLANs on a QFX5100 Switch on page 69
•
Examples: Configuring VXLANs on QFX Series Switches on page 51
Copyright © 2014, Juniper Networks, Inc.
PART 4
Troubleshooting
•
Troubleshooting Procedures on page 131
Copyright © 2014, Juniper Networks, Inc.
129
OVSDB and VXLAN Feature Guide
130
Copyright © 2014, Juniper Networks, Inc.
CHAPTER 9
Troubleshooting Procedures
•
Troubleshooting a Nonoperational VMware NSX Logical Switch and Corresponding
Junos OS OVSDB-Managed VXLAN on page 131
Troubleshooting a Nonoperational VMware NSX Logical Switch and Corresponding
Junos OS OVSDB-Managed VXLAN
Supported Platforms
Problem
Cause
Solution
MX Series, QFX Series standalone switches
Description: A logical switch configured by using VMware NSX Manager or the NSX API,
and the corresponding Open vSwitch Database (OVSDB)-Managed Virtual Extensible
LAN (VXLAN), which is configured on a Juniper Networks device, are not exchanging MAC
addresses learned in the NSX and Junos OS environments, respectively. Also, the Flags
field in the show ovsdb logical-switch operational mode command output is one of the
following:
•
Created by Controller
•
Created by L2ALD
•
Tunnel key mismatch
•
If the Flags field displays Created by Controller, a logical switch is configured in NSX
Manager or in the NSX API, but a corresponding VXLAN is not configured or is improperly
configured on the Juniper Networks device.
•
If the Flags field displays Created by L2ALD, a VXLAN is configured on the Juniper
Networks device, but a corresponding logical switch is not configured in NSX Manager
or in the NSX API.
•
If the Flags field displays Tunnel key mismatch, the VXLAN network identifiers (VNIs)
in the logical switch and corresponding VXLAN configurations do not match.
If the Flags field displays Created by Controller, take the following action:
•
On a QFX5100 switch, verify that the set switch-options ovsdb-managed configuration
command was issued in the Junos OS CLI. Issuing this command and committing the
configuration enable the switch to automatically create OVSDB-managed VXLANs.
If this command was already issued, another possible cause is that the L2ALD daemon
has become non-functional. If this is the case, wait for a few seconds, reissue the show
Copyright © 2014, Juniper Networks, Inc.
131
OVSDB and VXLAN Feature Guide
ovsdb logical-switch operational mode command, and recheck the setting of the Flags
field.
•
On all other Juniper Networks devices that support VXLAN and OVSDB, determine
whether a corresponding VXLAN is configured on the device. If the VXLAN is not
configured, configure it using the procedure in “Configuring OVSDB-Managed VXLANs”
on page 66. If a VXLAN is configured, check the VXLAN name to make sure that it is
the same as the universally unique identifier (UUID) of the logical switch. Also, check
the VNI to make sure that the value is the same as the value in the logical switch
configuration.
If the Flags field displays Created by L2ALD, take the following action:
•
On a QFX5100 switch, two issues exist. First, despite the fact that the switch
automatically creates OVSDB-managed VXLANs, this VXLAN was manually configured
by using the Junos OS CLI. Second, a corresponding logical switch was not configured.
To resolve both issues, configure a logical switch in NSX Manager or in the NSX API.
After the NSX controller pushes relevant logical switch information to the switch, the
switch automatically creates a corresponding VXLAN and deletes the manually
configured VXLAN.
•
On all other Juniper Networks devices that support VXLAN and OVSDB, determine
whether a corresponding logical switch is configured in NSX Manager or in the NSX
API. If a logical switch is not configured, configure one, keeping in mind that NSX
automatically generates a UUID for the logical switch and that this UUID must be used
as the name of the VXLAN. That is, the VXLAN name must be reconfigured with the
logical switch UUID. Another possibility is that the logical switch might exist, but the
logical switch UUID might not be the VXLAN name. In NSX Manager or in the NSX API,
check for a logical switch that has the same configuration as the VXLAN but has a
different UUID.
If the Flags field displays Tunnel key mismatch, take the following action:
Related
Documentation
132
•
For a QFX5100 switch, check the configuration of the VNI in NSX Manager or in the
NSX API to see whether it was changed after the switch created the corresponding
VXLAN. If it was changed, update the VNI on the QFX5100 switch, using the Junos OS
CLI.
•
On all other Juniper Networks devices that support VXLAN and OVSDB, check the
values of the VNI in NSX Manager or in the NSX API and the Junos OS CLI, and change
the incorrect value.
•
Understanding How to Set Up Virtual Extensible LANs in an Open vSwitch Database
Environment on page 10
•
show ovsdb logical-switch on page 101
Copyright © 2014, Juniper Networks, Inc.