From add17b6945ab6d484becd19616d353e09a328b9a Mon Sep 17 00:00:00 2001 From: Bruce Davie Date: Tue, 8 Oct 2013 14:37:51 -0700 Subject: [PATCH] vtep: Initial checkin of vtep schema. The hardware VTEP OVSDB schema specifies relations that a VTEP can use to integrate physical ports into logical switches maintained by a network virtualization controller such as NVP. Co-authored-by: Ben Pfaff Co-authored-by: Kenneth Duda Co-authored-by: Justin Pettit Signed-off-by: Bruce Davie Signed-off-by: Ben Pfaff Signed-off-by: Kenneth Duda Signed-off-by: Justin Pettit Acked-by: Ben Pfaff --- Makefile.am | 1 + lib/.gitignore | 3 + lib/automake.mk | 17 +- lib/vtep-idl.ann | 9 + vtep/.gitignore | 6 + vtep/automake.mk | 46 +++ vtep/vtep.ovsschema | 157 ++++++++++ vtep/vtep.xml | 717 ++++++++++++++++++++++++++++++++++++++++++++ 8 files changed, 954 insertions(+), 2 deletions(-) create mode 100644 lib/vtep-idl.ann create mode 100644 vtep/.gitignore create mode 100644 vtep/automake.mk create mode 100644 vtep/vtep.ovsschema create mode 100644 vtep/vtep.xml diff --git a/Makefile.am b/Makefile.am index 5b9e0ac18..45eb3c581 100644 --- a/Makefile.am +++ b/Makefile.am @@ -274,3 +274,4 @@ include xenserver/automake.mk include python/automake.mk include python/compat/automake.mk include tutorial/automake.mk +include vtep/automake.mk diff --git a/lib/.gitignore b/lib/.gitignore index f4c59add9..31346e4b7 100644 --- a/lib/.gitignore +++ b/lib/.gitignore @@ -8,3 +8,6 @@ /vswitch-idl.c /vswitch-idl.h /vswitch-idl.ovsidl +/vtep-idl.c +/vtep-idl.h +/vtep-idl.ovsidl diff --git a/lib/automake.mk b/lib/automake.mk index da390aba1..8fdc1628a 100644 --- a/lib/automake.mk +++ b/lib/automake.mk @@ -229,7 +229,9 @@ lib_libopenvswitch_a_SOURCES = \ lib/vlog.c \ lib/vlog.h \ lib/vswitch-idl.c \ - lib/vswitch-idl.h + lib/vswitch-idl.h \ + lib/vtep-idl.c \ + lib/vtep-idl.h nodist_lib_libopenvswitch_a_SOURCES = \ lib/dirs.c @@ -334,7 +336,10 @@ MAN_FRAGMENTS += \ OVSIDL_BUILT += \ $(srcdir)/lib/vswitch-idl.c \ $(srcdir)/lib/vswitch-idl.h \ - $(srcdir)/lib/vswitch-idl.ovsidl + $(srcdir)/lib/vswitch-idl.ovsidl \ + $(srcdir)/lib/vtep-idl.c \ + $(srcdir)/lib/vtep-idl.h \ + $(srcdir)/lib/vtep-idl.ovsidl EXTRA_DIST += $(srcdir)/lib/vswitch-idl.ann VSWITCH_IDL_FILES = \ @@ -344,6 +349,14 @@ $(srcdir)/lib/vswitch-idl.ovsidl: $(VSWITCH_IDL_FILES) $(OVSDB_IDLC) annotate $(VSWITCH_IDL_FILES) > $@.tmp mv $@.tmp $@ +EXTRA_DIST += $(srcdir)/lib/vtep-idl.ann +VTEP_IDL_FILES = \ + $(srcdir)/vtep/vtep.ovsschema \ + $(srcdir)/lib/vtep-idl.ann +$(srcdir)/lib/vtep-idl.ovsidl: $(VTEP_IDL_FILES) + $(OVSDB_IDLC) annotate $(VTEP_IDL_FILES) > $@.tmp + mv $@.tmp $@ + lib/dirs.c: lib/dirs.c.in Makefile ($(ro_c) && sed < $(srcdir)/lib/dirs.c.in \ -e 's,[@]srcdir[@],$(srcdir),g' \ diff --git a/lib/vtep-idl.ann b/lib/vtep-idl.ann new file mode 100644 index 000000000..5ffe58545 --- /dev/null +++ b/lib/vtep-idl.ann @@ -0,0 +1,9 @@ +# -*- python -*- + +# This code, when invoked by "ovsdb-idlc annotate" (by the build +# process), annotates vswitch.ovsschema with additional data that give +# the ovsdb-idl engine information about the types involved, so that +# it can generate more programmer-friendly data structures. + +s["idlPrefix"] = "vteprec_" +s["idlHeader"] = "\"lib/vtep-idl.h\"" diff --git a/vtep/.gitignore b/vtep/.gitignore new file mode 100644 index 000000000..1549759c1 --- /dev/null +++ b/vtep/.gitignore @@ -0,0 +1,6 @@ +/Makefile +/Makefile.in +/vtep.5 +/vtep.gv +/vtep.ovsschema.stamp +/vtep.pic diff --git a/vtep/automake.mk b/vtep/automake.mk new file mode 100644 index 000000000..2db12c29e --- /dev/null +++ b/vtep/automake.mk @@ -0,0 +1,46 @@ +# VTEP schema and IDL +EXTRA_DIST += vtep/vtep.ovsschema +pkgdata_DATA += vtep/vtep.ovsschema + +# VTEP E-R diagram +# +# If "python" or "dot" is not available, then we do not add graphical diagram +# to the documentation. +if HAVE_PYTHON +if HAVE_DOT +vtep/vtep.gv: ovsdb/ovsdb-dot.in vtep/vtep.ovsschema + $(OVSDB_DOT) --no-arrows $(srcdir)/vtep/vtep.ovsschema > $@ +vtep/vtep.pic: vtep/vtep.gv ovsdb/dot2pic + (dot -T plain < vtep/vtep.gv | $(srcdir)/ovsdb/dot2pic -f 3) > $@; +VTEP_PIC = vtep/vtep.pic +VTEP_DOT_DIAGRAM_ARG = --er-diagram=$(VTEP_PIC) +DISTCLEANFILES += vtep/vtep.gv vtep/vtep.pic +endif +endif + +# VTEP schema documentation +EXTRA_DIST += vtep/vtep.xml +DISTCLEANFILES += vtep/vtep.5 +dist_man_MANS += vtep/vtep.5 +$(srcdir)/vtep/vtep.5: \ + ovsdb/ovsdb-doc vtep/vtep.xml vtep/vtep.ovsschema $(VTEP_PIC) + $(OVSDB_DOC) \ + --title="vtep" \ + $(VTEP_DOT_DIAGRAM_ARG) \ + $(srcdir)/vtep/vtep.ovsschema \ + $(srcdir)/vtep/vtep.xml > $@.tmp + mv $@.tmp $@ + +# Version checking for vtep.ovsschema. +ALL_LOCAL += vtep/vtep.ovsschema.stamp +vtep/vtep.ovsschema.stamp: vtep/vtep.ovsschema + @sum=`sed '/cksum/d' $? | cksum`; \ + expected=`sed -n 's/.*"cksum": "\(.*\)".*/\1/p' $?`; \ + if test "X$$sum" = "X$$expected"; then \ + touch $@; \ + else \ + ln=`sed -n '/"cksum":/=' $?`; \ + echo >&2 "$?:$$ln: checksum \"$$sum\" does not match (you should probably update the version number and fix the checksum)"; \ + exit 1; \ + fi +CLEANFILES += vtep/vtep.ovsschema.stamp diff --git a/vtep/vtep.ovsschema b/vtep/vtep.ovsschema new file mode 100644 index 000000000..d03d96d51 --- /dev/null +++ b/vtep/vtep.ovsschema @@ -0,0 +1,157 @@ +{ + "name": "hardware_vtep", + "cksum": "825115144 5318", + "tables": { + "Global": { + "columns": { + "managers": { + "type": {"key": {"type": "uuid", + "refTable": "Manager"}, + "min": 0, "max": "unlimited"}}, + "switches": { + "type": {"key": {"type": "uuid", "refTable": "Physical_Switch"}, + "min": 0, "max": "unlimited"}} + }, + "maxRows": 1, + "isRoot": true}, + "Physical_Switch": { + "columns": { + "ports": { + "type": {"key": {"type": "uuid", "refTable": "Physical_Port"}, + "min": 0, "max": "unlimited"}}, + "name": {"type": "string"}, + "description": {"type": "string"}, + "management_ips": { + "type": {"key": {"type": "string"}, "min": 0, "max": "unlimited"}}, + "tunnel_ips": { + "type": {"key": {"type": "string"}, "min": 0, "max": "unlimited"}}}, + "indexes": [["name"]]}, + "Physical_Port": { + "columns": { + "name": {"type": "string"}, + "description": {"type": "string"}, + "vlan_bindings": { + "type": {"key": {"type": "integer", + "minInteger": 0, "maxInteger": 4095}, + "value": {"type": "uuid", "refTable": "Logical_Switch"}, + "min": 0, "max": "unlimited"}}, + "vlan_stats": { + "type": {"key": {"type": "integer", + "minInteger": 0, "maxInteger": 4095}, + "value": {"type": "uuid", + "refTable": "Logical_Binding_Stats"}, + "min": 0, "max": "unlimited"}}}}, + "Logical_Binding_Stats": { + "columns": { + "bytes_from_local": {"type": "integer"}, + "packets_from_local": {"type": "integer"}, + "bytes_to_local": {"type": "integer"}, + "packets_to_local": {"type": "integer"}}}, + "Logical_Switch": { + "columns": { + "name": {"type": "string"}, + "description": {"type": "string"}, + "tunnel_key": {"type": {"key": "integer", "min": 0, "max": 1}}}, + "isRoot": true, + "indexes": [["name"]]}, + "Ucast_Macs_Local": { + "columns": { + "MAC": {"type": "string"}, + "logical_switch": { + "type": {"key": {"type": "uuid", + "refTable": "Logical_Switch"}}}, + "locator": { + "type": {"key": {"type": "uuid", + "refTable": "Physical_Locator"}}}, + "ipaddr": {"type": "string"}}, + "isRoot": true}, + "Ucast_Macs_Remote": { + "columns": { + "MAC": {"type": "string"}, + "logical_switch": { + "type": {"key": {"type": "uuid", + "refTable": "Logical_Switch"}}}, + "locator": { + "type": {"key": {"type": "uuid", + "refTable": "Physical_Locator"}}}, + "ipaddr": {"type": "string"}}, + "isRoot": true}, + "Mcast_Macs_Local": { + "columns": { + "MAC": {"type": "string"}, + "logical_switch": { + "type": {"key": {"type": "uuid", + "refTable": "Logical_Switch"}}}, + "locator_set": { + "type": {"key": {"type": "uuid", + "refTable": "Physical_Locator_Set"}}}, + "ipaddr": {"type": "string"}}, + "isRoot": true}, + "Mcast_Macs_Remote": { + "columns": { + "MAC": {"type": "string"}, + "logical_switch": { + "type": {"key": {"type": "uuid", + "refTable": "Logical_Switch"}}}, + "locator_set": { + "type": {"key": {"type": "uuid", + "refTable": "Physical_Locator_Set"}}}, + "ipaddr": {"type": "string"}}, + "isRoot": true}, + "Logical_Router": { + "columns": { + "name": {"type": "string"}, + "description": {"type": "string"}, + "switch_binding": { + "type": {"key": {"type": "string"}, + "value": {"type": "uuid", + "refTable": "Logical_Switch"}, + "min": 0, "max": "unlimited"}}, + "static_routes": { + "type": {"key": {"type": "string"}, + "value": {"type" : "string"}, + "min": 0, "max": "unlimited"}}}, + "isRoot": true, + "indexes": [["name"]]}, + "Physical_Locator_Set": { + "columns": { + "locators": { + "type": {"key": {"type": "uuid", "refTable": "Physical_Locator"}, + "min": 1, "max": "unlimited"}, + "mutable": false}}}, + "Physical_Locator": { + "columns": { + "encapsulation_type": { + "type": { + "key": { + "enum": ["set", ["vxlan_over_ipv4"]], + "type": "string"}}, + "mutable": false}, + "dst_ip": {"type": "string", "mutable": false}, + "bfd": { + "type": {"key": "string", "value": "string", + "min": 0, "max": "unlimited"}}, + "bfd_status": { + "type": {"key": "string", "value": "string", + "min": 0, "max": "unlimited"}}}, + "indexes": [["encapsulation_type", "dst_ip"]]}, + "Manager": { + "columns": { + "target": {"type": "string"}, + "max_backoff": { + "type": {"key": {"type": "integer", + "minInteger": 1000}, + "min": 0, "max": 1}}, + "inactivity_probe": { + "type": {"key": "integer", "min": 0, "max": 1}}, + "other_config": { + "type": {"key": "string", "value": "string", "min": 0, "max": "unlimited"}}, + "is_connected": { + "type": "boolean", + "ephemeral": true}, + "status": { + "type": {"key": "string", "value": "string", "min": 0, "max": "unlimited"}, + "ephemeral": true}}, + "indexes": [["target"]], + "isRoot": false}}, + "version": "1.0.0"} diff --git a/vtep/vtep.xml b/vtep/vtep.xml new file mode 100644 index 000000000..9fd7495fc --- /dev/null +++ b/vtep/vtep.xml @@ -0,0 +1,717 @@ + + +

+ This schema specifies relations that a VTEP can use to integrate + physical ports into logical switches maintained by a network + virtualization controller such as NSX. +

+ +

Glossary:

+ +
+
VTEP
+
+ VXLAN Tunnel End Point, an entity which originates and/or terminates + VXLAN tunnels. +
+ +
HSC
+
+ Hardware Switch Controller. +
+ +
NVC
+
+ Network Virtualization Controller, e.g. NSX. +
+ +
VRF
+
+ Virtual Routing and Forwarding instance. +
+
+ + + Top-level configuration for a hardware VTEP. There must be + exactly one record in the table. + + + The physical switches managed by the VTEP. + + + +

+ These columns primarily configure the database server + (ovsdb-server), not the hardware VTEP itself. +

+ + + Database clients to which the database server should connect or + to which it should listen, along with options for how these + connection should be configured. See the + table for more information. + + +
+ + +

+ Configuration for a database connection to an Open vSwitch Database + (OVSDB) client. +

+ +

+ The database server can initiate and maintain active connections + to remote clients. It can also listen for database connections. +

+ + + +

Connection method for managers.

+

+ The following connection methods are currently supported: +

+
+
ssl:ip[:port]
+
+

+ The specified SSL port (default: 6632) on the host at + the given ip, which must be expressed as an IP address + (not a DNS name). +

+

+ SSL key and certificate configuration happens outside the + database. +

+
+ +
tcp:ip[:port]
+
+ The specified TCP port (default: 6632) on the host at + the given ip, which must be expressed as an IP address + (not a DNS name). +
+
pssl:[port][:ip]
+
+

+ Listens for SSL connections on the specified TCP port + (default: 6632). If ip, which must be expressed as an + IP address (not a DNS name), is specified, then connections are + restricted to the specified local IP address. +

+
+
ptcp:[port][:ip]
+
+ Listens for connections on the specified TCP port + (default: 6632). If ip, which must be expressed as an + IP address (not a DNS name), is specified, then connections are + restricted to the specified local IP address. +
+
+ + + + + + Maximum number of milliseconds to wait between connection attempts. + Default is implementation-specific. + + + + Maximum number of milliseconds of idle time on connection to the + client before sending an inactivity probe message. If the Open + vSwitch database does not communicate with the client for the + specified number of seconds, it will send a probe. If a + response is not received for the same additional amount of time, + the database server assumes the connection has been broken + and attempts to reconnect. Default is implementation-specific. + A value of 0 disables inactivity probes. + + + + + + true if currently connected to this manager, + false otherwise. + + + + A human-readable description of the last error on the connection + to the manager; i.e. strerror(errno). This key + will exist only if an error has occurred. + + + +

+ The state of the connection to the manager: +

+
+
VOID
+
Connection is disabled.
+ +
BACKOFF
+
Attempting to reconnect at an increasing period.
+ +
CONNECTING
+
Attempting to connect.
+ +
ACTIVE
+
Connected, remote host responsive.
+ +
IDLE
+
Connection is idle. Waiting for response to keep-alive.
+
+

+ These values may change in the future. They are provided only for + human consumption. +

+ + + + The amount of time since this manager last successfully connected + to the database (in seconds). Value is empty if manager has never + successfully connected. + + + + The amount of time since this manager last disconnected from the + database (in seconds). Value is empty if manager has never + disconnected. + + + + Space-separated list of the names of OVSDB locks that the connection + holds. Omitted if the connection does not hold any locks. + + + + Space-separated list of the names of OVSDB locks that the connection is + currently waiting to acquire. Omitted if the connection is not waiting + for any locks. + + + + Space-separated list of the names of OVSDB locks that the connection + has had stolen by another OVSDB client. Omitted if no locks have been + stolen from this connection. + + + +

+ When specifies a connection method that + listens for inbound connections (e.g. ptcp: or + pssl:) and more than one connection is actually active, + the value is the number of active connections. Otherwise, this + key-value pair is omitted. +

+

+ When multiple connections are active, status columns and key-value + pairs (other than this one) report the status of one arbitrarily + chosen connection. +

+ + + + +

+ Additional configuration for a connection between the manager + and the database server. +

+ + + The Differentiated Service Code Point (DSCP) is specified using 6 bits + in the Type of Service (TOS) field in the IP header. DSCP provides a + mechanism to classify the network traffic and provide Quality of + Service (QoS) on IP networks. + + The DSCP value specified here is used when establishing the + connection between the manager and the database server. If no + value is specified, a default value of 48 is chosen. Valid DSCP + values must be in the range 0 to 63. + + +
+ + + A physical switch that implements a VTEP. + + + The physical ports within the switch. + + + + + IPv4 or IPv6 addresses at which the switch may be contacted + for management purposes. + + + +

+ IPv4 or IPv6 addresses on which the switch may originate or + terminate tunnels. +

+ +

+ This column is intended to allow a to + determine the that terminates + the tunnel represented by a . +

+ + + + + + Symbolic name for the switch, such as its hostname. + + + + An extended description for the switch, such as its switch login + banner. + + +
+ + + A port within a . + + + Identifies how VLANs on the physical port are bound to logical switches. + If, for example, the map contains a (VLAN, logical switch) pair, a packet + that arrives on the port in the VLAN is considered to belong to the + paired logical switch. + + + + Statistics for VLANs bound to logical switches on the physical port. An + implementation that fully supports such statistics would populate this + column with a mapping for every VLAN that is bound in . An implementation that does not support such + statistics or only partially supports them would not populate this column + or partially populate it, respectively. + + + + + Symbolic name for the port. The name ought to be unique within a given + , but the database is not capable of + enforcing this. + + + + An extended description for the port. + + +
+ + + Reports statistics for the with which a VLAN + on a is associated. + + + These statistics count only packets to which the binding applies. + + + Number of packets sent by the . + + + + Number of bytes in packets sent by the . + + + + Number of packets received by the . + + + + Number of bytes in packets received by the . + + +
+ + + A logical Ethernet switch, whose implementation may span physical and + virtual media, possibly crossing L3 domains via tunnels; a logical layer-2 + domain; an Ethernet broadcast domain. + + + + +

+ Tunnel protocols tend to have a field that allows the tunnel + to be partitioned into sub-tunnels: VXLAN has a VNI, GRE and + STT have a key, CAPWAP has a WSI, and so on. We call these + generically ``tunnel keys.'' Given that one needs to use a + tunnel key at all, there are at least two reasonable ways to + assign their values: +

+ +
    +
  • +

    + Per + + pair. That is, each logical switch may be assigned a different + tunnel key on every . This model is + especially flexible. +

    + +

    + In this model, carries the tunnel + key. Therefore, one record will + exist for each logical switch carried at a given IP destination. +

    +
    • + +
  • +

    + Per . That is, every tunnel + associated with a particular logical switch carries the same tunnel + key, regardless of the to which the + tunnel is addressed. This model may ease switch implementation + because it imposes fewer requirements on the hardware datapath. +

    + +

    + In this model, carries the tunnel + key. Therefore, one record will + exist for each IP destination. +

    +
    • +
+ + +

+ This column is used only in the tunnel key per model (see above), because only in that + model is there a tunnel key associated with a logical switch. +

+ +

+ For vxlan_over_ipv4 encapsulation, this column + is the VXLAN VNI that identifies a logical switch. It must + be in the range 0 to 16,777,215. +

+ + + + + + Symbolic name for the logical switch. + + + + An extended description for the logical switch, such as its switch + login banner. + + +
+ + +

+ Mapping of unicast MAC addresses to tunnels (physical + locators). This table is written by the HSC, so it contains the + MAC addresses that have been learned on physical ports by a + VTEP. +

+ + + A MAC address that has been learned by the VTEP. + + + + The Logical switch to which this mapping applies. + + + + The physical locator to be used to reach this MAC address. In + this table, the physical locator will be one of the tunnel IP + addresses of the appropriate VTEP. + + + + The IP address to which this MAC corresponds. Optional field for + the purpose of ARP supression. + + +
+ + +

+ Mapping of unicast MAC addresses to tunnels (physical + locators). This table is written by the NVC, so it contains the + MAC addresses that the NVC has learned. These include VM MAC + addresses, in which case the physical locators will be + hypervisor IP addresses. The NVC will also report MACs that it + has learned from other HSCs in the network, in which case the + physical locators will be tunnel IP addresses of the + corresponding VTEPs. +

+ + + A MAC address that has been learned by the NSC. + + + + The Logical switch to which this mapping applies. + + + + The physical locator to be used to reach this MAC address. In + this table, the physical locator will be either a hypervisor IP + address or a tunnel IP addresses of another VTEP. + + + + The IP address to which this MAC corresponds. Optional field for + the purpose of ARP supression. + + +
+ + +

+ Mapping of multicast MAC addresses to tunnels (physical + locators). This table is written by the HSC, so it contains the + MAC addresses that have been learned on physical ports by a + VTEP. These may be learned by IGMP snooping, for example. This + table also specifies how to handle unknown unicast and broadcast packets. +

+ + +

+ A MAC address that has been learned by the VTEP. +

+

+ The keyword unknown-dst is used as a special + ``Ethernet address'' that indicates the locations to which + packets in a logical switch whose destination addresses do not + otherwise appear in (for + unicast addresses) or (for + multicast addresses) should be sent. +

+ + + + The Logical switch to which this mapping applies. + + + + The physical locator set to be used to reach this MAC address. In + this table, the physical locator set will be contain one or more tunnel IP + addresses of the appropriate VTEP(s). + + +
+ + +

+ Mapping of multicast MAC addresses to tunnels (physical + locators). This table is written by the NVC, so it contains the + MAC addresses that the NVC has learned. This + table also specifies how to handle unknown unicast and broadcast + packets. +

+

+ Multicast packet replication may be handled by a service node, + in which case the physical locators will be IP addresses of + service nodes. If the VTEP supports replication onto multiple + tunnels, then this may be used to replicate directly onto + VTEP-hyperisor tunnels. +

+ + +

+ A MAC address that has been learned by the NSC. +

+

+ The keyword unknown-dst is used as a special + ``Ethernet address'' that indicates the locations to which + packets in a logical switch whose destination addresses do not + otherwise appear in (for + unicast addresses) or (for + multicast addresses) should be sent. +

+ + + + The Logical switch to which this mapping applies. + + + + The physical locator set to be used to reach this MAC address. In + this table, the physical locator set will be either a service node IP + address or a set of tunnel IP addresses of hypervisors (and + potentially other VTEPs). + + + + The IP address to which this MAC corresponds. Optional field for + the purpose of ARP supression. + + +
+ + +

+ A logical router, or VRF. A logical router may be connected to one or more + logical switches. Subnet addresses and interface addresses may be configured on the + interfaces. +

+ + + Maps from an IPv4 or IPv6 address prefix in CIDR notation to a + logical switch. Multiple prefixes may map to the same switch. By + writing a 32-bit (or 128-bit for v6) address with a /N prefix + length, both the router's interface address and the subnet + prefix can be configured. For example, 192.68.1.1/24 creates a + /24 subnet for the logical switch attached to the interface and + assigns the address 192.68.1.1 to the router interface. + + + + One or more static routes, mapping IP prefixes to next hop IP addresses. + + + + + Symbolic name for the logical router. + + + + An extended description for the logical router. + + +
+ + +

+ A set of one or more s. +

+ +

+ This table exists only because OVSDB does not have a way to + express the type ``map from string to one or more records.'' +

+ + +
+ + +

+ Identifies an endpoint to which logical switch traffic may be + encapsulated and forwarded. +

+ +

+ For the vxlan_over_ipv4 encapsulation, the only + encapsulation defined so far, all endpoints associated with a given must use a common tunnel key, which is carried + in the column of . +

+ +

+ For some encapsulations yet to be defined, we expect to identify both an endpoint and a tunnel key. + When the first such encapsulation is defined, we expect to add a + ``tunnel_key'' column to to allow the + tunnel key to be defined. +

+ +

+ See the ``Per Logical-Switch Tunnel Key'' section in the table for further discussion of the model. +

+ + + The type of tunneling encapsulation. + + + +

+ For vxlan_over_ipv4 encapsulation, the IPv4 address of the + VXLAN tunnel endpoint. +

+ +

+ We expect that this column could be used for IPv4 or IPv6 addresses in + encapsulations to be introduced later. +

+ + +

+ BFD, defined in RFC 5880, allows point to point detection of + connectivity failures by occasional transmission of BFD control + messages. +

+ +

+ BFD operates by regularly transmitting BFD control messages at a + rate negotiated independently in each direction. Each endpoint + specifies the rate at which it expects to receive control messages, + and the rate at which it's willing to transmit them. An endpoint + which fails to receive BFD control messages for a period of three + times the expected reception rate, will signal a connectivity + fault. In the case of a unidirectional connectivity issue, the + system not receiving BFD control messages will signal the problem + to its peer in the messages is transmists. +

+ + + The minimum rate, in milliseconds, at which this BFD session is + willing to receive BFD control messages. The actual rate may slower + if the remote endpoint isn't willing to transmit as quickly as + specified. Defaults to 1000. + + + + The minimum rate, in milliseconds, at which this BFD session is + willing to transmit BFD control messages. The actual rate may be + slower if the remote endpoint isn't willing to receive as quickly as + specified. Defaults to 100. + + + + Concatenated path down may be used when the local system should not + have traffic forwarded to it for some reason other than a connectivty + failure on the interface being monitored. The local BFD session will + notify the remote session of the connectivity problem, at which time + the remote session may choose not to forward traffic. Defaults to + false. + + + + State of the BFD session. One of ADMIN_DOWN, + DOWN, INIT, or UP. + + + + True if the BFD session believes this may be + used to forward traffic. Typically this means the local session is + up, and the remote system isn't signalling a problem such as + concatenated path down. + + + + A short message indicating what the BFD session thinks is wrong in + case of a problem. + + + + State of the remote endpoint's BFD session. + + + + A short message indicating what the remote endpoint's BFD session + thinks is wrong in case of a problem. + + +
+ + -- 2.43.0