dcbtool

package: lldpad

title: dcbtool(8)

text:
# dcbtool(8)

## NAME
dcbtool - manage the Data Center Bridging (DCB) settings of a CEE DCB interface

## SYNOPSIS
dcbtool -h

dcbtool -v

dcbtool [-rR]

dcbtool [-rR] [command] [command arguments]

## DESCRIPTION
dcbtool is used to query and set the DCB settings of a Converged Enhanced Ethernet (CEE) DCB capable Ethernet interface. It connects to the client interface of lldpad to perform these operations. dcbtool will operate in interactive mode if it is executed without a command. In interactive mode, dcbtool also functions as an event listener and will print out events received from lldpad as they arrive. It will use libreadline for interactive input when available. 802.1Qaz DCBX is not controllable from dcbtool instead lldptool can be used in this case.

## OPTIONS
-h

show the dcbtool usage message

-v

shows dcbtool version information

-r

display the raw lldpad client interface messages as well as the readable output.

-R

display only the raw lldpad client interface messages

## COMMANDS
help

shows the dcbtool usage message

ping

test command. lldpad responds with "PPONG" if the client interface is operational.

license

displays dcbtool license information

quit

exit from interactive mode

The following commands interact with lldpad to manage the daemon and DCB features on DCB capable interfaces.

dcbtool general configuration commands:

<gc|go> dcbx

Get the configured or operational legacy version of the DCBX protocol which will be supported by lldpad. The configured version, if different from the operational version, will take effect after lldpad is restarted.

sc dcbx v:[cin|cee|force-cin|force-cee]

Set the legacy version of DCBX which will be supported by lldpad the next time it is started.

Information about the CIN version can be found at:

<http://download.intel.com/technology/eedc/dcb_cep_spec.pdf>

Information about the CEE version can be found at:

<http://www.ieee802.org/1/files/public/docs2008/az-wadekar-dcbx-capability-exchange-discovery-protocol-1108-v1.01.pdf>

The dcbx setting is a global setting and changes only take effect when lldpad is restarted. The default DCBX version used is the IEEE standard version. If a pre-IEEE DCBX version is received (per port) which matches the dcbx setting, then lldpad will fall back to the configured global dcbx setting. If the dcbx setting is set to either 'force-cin' or 'force-cee' then any port doing DCBX will start out in the corresponding legacy DCBX mode.

DCB per-interface commands:

gc <ifname> <feature>

get configuration of feature on interface ifname.

go <ifname> <feature>

get operational status of feature on interface ifname.

gp <ifname> <feature>

get peer configuration of feature on interface ifname.

sc <ifname> <feature> <args>

set the configuration of feature on interface ifname.

feature may be one of the following:

dcb

DCB state of the port

pg

priority groups

pfc

priority flow control

app:<subtype>

application specific data

ll:<subtype>

logical link status

subtype can be:

0|fcoe

Fiber Channel over Ethernet (FCoE)

1|iscsi

Internet Small Computer System Interface (iSCSI)

2|fip

FCoE Initialization Protocol (FIP)

args can include:

e:<0|1>

controls feature enable

a:<0|1>

controls whether the feature is advertised via DCBX to the peer

w:<0|1>

controls whether the feature is willing to change its operational configuration based on what is received from the peer

[feature specific args]

arguments specific to a DCB feature

Feature specific arguments for dcb:

on|off

enable or disable DCB for the interface. The go and gp commands are not needed for the dcb feature. Also, the enable(e), advertise(a) and willing(w) arguments are not required.

Feature specific arguments for pg:

pgid:xxxxxxxx

Priority group ID for the 8 priorities. From left to right (priorities 0-7), x is the corresponding priority group ID value, which can be 0-7 for priority groups with bandwidth allocations or f (priority group ID 15) for the unrestricted priority group.

pgpct:x,x,x,x,x,x,x,x

Priority group percentage of link bandwidth. From left to right (priority groups 0-7), x is the percentage of link bandwidth allocated to the corresponding priority group. The total bandwidth must equal 100%.

uppct:x,x,x,x,x,x,x,x

Priority percentage of priority group bandwidth. From left to right (priorities 0-7), x is the percentage of priority group bandwidth allocated to the corresponding priority. The sum of percentages for priorities which belong to the same priority group must total 100% (except for priority group 15).

strict:xxxxxxxx

Strict priority setting. From left to right (priorities 0-7), x is 0 or 1. 1 indicates that the priority may utilize all of the bandwidth allocated to its priority group.

up2tc:xxxxxxxx

Priority to traffic class mapping. From left to right (priorities 0-7), x is the traffic class (0-7) to which the priority is mapped.

Feature specific arguments for pfc:

pfcup:xxxxxxxx

Enable/disable priority flow control. From left to right (priorities 0-7), x is 0 or 1. 1 indicates that the corresponding priority is configured to transmit priority pause.

Feature specific arguments for app:<subtype>:

The app features uses global enable and willing bits for all subtypes. To remove or add subtypes to the TLV set the advertise bit.

appcfg:xx

xx is a hexadecimal value representing an 8 bit bitmap where 1 bits indicate the priorities which frames for the applications specified by subtype should use. The lowest order bit maps to priority 0.

Feature specific arguments for ll:<subtype>:

status:[0|1]

For testing purposes, the logical link status may be set to 0 or 1. Changes to the logical link status are not saved in the configuration file.

## EXAMPLES
Enable DCB on interface eth2

dcbtool sc eth2 dcb on

Assign priorities 0-3 to priority group 0, priorities 4-6 to priority group 1 and priority 7 to the unrestricted priority. Also, allocate 25% of link bandwidth to priority group 0 and 75% to group 1.

dcbtool sc eth2 pg pgid:0000111f pgpct:25,75,0,0,0,0,0,0

Enable transmit of Priority Flow Control for priority 3 and assign FCoE to priority 3.

dcbtool sc eth2 pfc pfcup:00010000

dcbtool sc eth2 app:0 appcfg:08

## SEE ALSO
lldpad(8), lldptool(8), lldptool-dcbx(8), lldptool-ets(8), lldptool-pfc(8), lldptool-app(8)

## COPYRIGHT
dcbtool - DCB configuration utility

Copyright(c) 2007-2012 Intel Corporation. Portions of dcbtool are based on:

hostapd-0.5.7

Copyright

(c) 2004-2008, Jouni Malinen <j@w1.fi>

## LICENSE
This program is free software; you can redistribute it and/or modify it under the terms and conditions of the GNU General Public License, version 2, as published by the Free Software Foundation.

This program is distributed in the hope it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA.

The full GNU General Public License is included in this distribution in the file called "COPYING".

## SUPPORT
Contact Information: open-lldp Mailing List <lldp-devel@open-lldp.org>


lldpad

title: lldpad(8)

text:
# lldpad(8)

## NAME
lldpad - Link Layer Discovery Protocol (LLDP) agent daemon

## SYNOPSIS
lldpad [-h] [-v] [-V level] [-d] [-k] [-p] [-s] [-t] [-f filename]

## DESCRIPTION
Executes the LLDP protocol for supported network interfaces. The list of TLVs currently supported are:

-

IEEE 802.1AB Mandatory TLVs

-

IEEE 802.1AB Basic Management TLVs

-

IEEE 802.3 Organizationally Specific TLVs

-

LLDP-MED Organizationally Specific TLVs

-

Data Center Bridging capabilities exchange protocol (DCBX) TLVs

-

Edge Virtual Bridging (EVB) TLVs

Capabilities of lldpad include:

-

Transmission of LLDP PDUs containing enabled TLVs from enabled ports.

-

Reception of LLDP PDUs from enabled ports.

-

Operation of the DCBX protocol for interfaces which support the DCB rtnetlink interface. This includes operation of the DCBX state machines above LLDP and corresponding configuration of the DCB parameters of the network interface. Supported DCB features are: Extended Transmission Selection, Priority Flow Control and the FCoE application.

-

Configuring the DCB settings of the network driver based on the operation of DCBX.

-

Provides a multi-channel interface for client applications to query and configure features. Events are also generated on the client interface to inform clients of changes. The lldpad package includes two clients: lldptool for general LLDP agent management and dcbtool for DCB management.

lldpad supports the versions of the DCB capabilities exchange (DCBX) protocol listed as follows:

version 1 - also known as CIN DCBX

<http://download.intel.com/technology/eedc/dcb_cep_spec.pdf>

version 2 - also known as CEE DCBX

<http://www.ieee802.org/1/files/public/docs2008/az-wadekar-dcbx-capability-exchange-discovery-protocol-1108-v1.01.pdf>

IEEE DCBX

See the IEEE 802.1Qaz-2011 specification for details.

IEEE DCBX is the default DCBX mode for a DCB capable interface so the default and configured IEEE DCBX TLVs will be transmitted when the interface comes up. lldpad can be globally configured to support one of the legacy DCBX versions (CIN or CEE). If the remote LLDP agent does not transmit any IEEE DCBX TLVs and does transmit a legacy DCBX TLV which matches the configured legacy DCBX version, then the DCBX mode will drop back to legacy DCBX mode. It will not transition back to IEEE DCBX mode until the next link reset. If lldpad has dropped back to legacy DCBX mode for a given interface and the daemon is stopped and restarted, the legacy DCBX mode for that interface will be used instead of starting out in IEEE DCBX mode. This behavior only applies to the case where lldpad is restarted and is not persistent across a system reboot.

See dcbtool for information on how to globally configure which legacy version of DCBX lldpad executes.

See lldptool for information on how to reset the DCBX mode of an interface back to default (starts out in IEEE DCBX mode).

lldpad also supports edge virtual bridging as currently under specification in the IEEE 802.1Qb working group. <http://www.ieee802.org/1/pages/802.1bg.html>

## OPTIONS
lldpad has the following command line options:

-h

show usage information

-f filename

use the specified file as the configuration file instead of the default file: /var/lib/lldpad/lldpad.conf lldpad expects the directory of the configuration file to exist, but if the configuration file does not exist, then a default configuration file will be created. lldpad creates and maintains the contents of the configuration file. Configuration should be performed by using lldptool or dcbtool.

-d

run lldpad as a daemon

-v

show lldpad version

-V level

set lldpad debugging level. Uses syslog debug levels see syslog.2 for details.

-k

used to terminate the first instance of lldpad that was started (e.g. from initrd). Once lldpad -k has been invoked and lldpad has been restarted, subsequent invocations of lldpad -k will not terminate lldpad.

-s

remove lldpad state records from shared memory

-p

do not create PID file /var/run/lldpad.pid on startup

-t

omit timestamps from logging messages

## NOTE
On termination, lldpad does not undo any of the configurations that it has set. This approach minimizes the risk of restarting the daemon to perform a software update, or of having storage issues during shutdown. Ongoing operation of network interfaces that had been controlled by lldpad may result in unexpected behavior.

## SEE ALSO
dcbtool(8), lldptool(8), lldptool-dcbx(8), lldptool-ets(8), lldptool-pfc(8), lldptool-app(8), lldptool-med(8), lldptool-vdp(8), lldptool-evb(8)

## COPYRIGHT
lldpad - LLDP agent daemon with DCBX support

Copyright(c) 2007-2012 Intel Corporation. Portions of lldpad are based on:

hostapd-0.5.7

Copyright

(c) 2004-2008, Jouni Malinen <j@w1.fi>

## LICENSE
This program is free software; you can redistribute it and/or modify it under the terms and conditions of the GNU General Public License, version 2, as published by the Free Software Foundation.

This program is distributed in the hope it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA.

The full GNU General Public License is included in this distribution in the file called "COPYING".

## SUPPORT
Contact Information: open-lldp Mailing List <lldp-devel@open-lldp.org>


lldptool

title: lldptool(8)

text:
# lldptool(8)

## NAME
lldptool - manage the LLDP settings and status of lldpad

## SYNOPSIS
lldptool <command> [options] [argument]

## DESCRIPTION
lldptool is used to query and configure lldpad. It connects to the client interface of lldpad to perform these operations. lldptool will operate in interactive mode if it is executed without a command. In interactive mode, lldptool will also function as an event listener to print out events as they are received asynchronously from lldpad. It will use libreadline for interactive input when available.

## OPTIONS
-i [ifname]

specifies the network interface to which the command applies. Most lldptool commands require specifying a network interface.

-V [tlvid]

specifies the TLV identifier

The tlvid is an integer value used to identify specific LLDP TLVs. The tlvid value is the Type value for types not equal to 127 (the organizationally specific type). For organizationally specific TLVs, the tlvid is the value represented by the 3 byte OUI and 1 byte subtype - where the subtype is the lowest order byte of the tlvid.

The tlvid can be entered as a numerical value (e.g. 10 or 0xa), or for supported TLVs, as a keyword. Review the lldptool help output to see the list of supported TLV keywords.

-n

"neighbor" option for commands which can use it (e.g. get-tlv)

-g [bridge scope]

specify the bridge scope this command operates on. Allows to set and query all LLDP TLV modules for "nearest_bridge" (short: "nb"), "nearest_customer_bridge" ("ncb") and "nearest_nontpmr_bridge" ("nntpmrb") group mac addresses. Configurations are saved into independent sections in lldpad.conf. If no bridge scope is supplied this defaults to "nearest bridge" to preserve the previous behaviour.

-c <argument list>

"config" option for TLV queries. Indicates that the query is for the configuration elements for the specified TLV. The argument list specifies the specific elements to query. If no arguments are listed, then all configuration elements for the TLV are returned.

-r

show raw client interface messages

-R

show only raw Client interface messages

## COMMANDS
license

show license information

-h, help

show usage information

-v, version

show version information

-S, stats

get LLDP statistics for the specified interface

-t, get-tlv

get TLV information for the specified interface

-T, set-tlv

set TLV information for the specified interface

-l, get-lldp

get LLDP parameters for the specified interface

-L, set-lldp

set LLDP parameters for the specified interface

-p, ping

display the process identifier of the running lldpad process

-q, quit

exit from interactive mode

## ARGUMENTS
This section lists arguments which are available for administration of LLDP parameters. Arguments for basic TLV's (non-organizationally specific TLVs) are also described. See the SEE ALSO section for references to other lldptool man pages which contain usage details and arguments for various organizationally specific TLVs.

adminStatus

Argument for the get-lldp/set-lldp commands. Configures the LLDP adminStatus parameter for the specified interface. Valid values are: disabled, rx, tx, rxtx

enableTx

Argument for the get-tlv/set-tlv commands. May be applied per interface for a specified TLV. Valid values are: yes, no. If the DCBX TLV enableTx is set to no, then all of the DCB feature TLVs DCBX advertise settings will be turned off as well. Setting enableTx to yes will enable the DCBX advertise settings.

ipv4

Argument for the get-tlv/set-tlv commands with respect to the Management Address TLV. The get command will retrieve the configured value. Set values take the form of an IPv4 address: A.B.C.D

ipv6

Argument for the get-tlv/set-tlv commands with respect to the Management Address TLV. The get command will retrieve the configured value. Set values take the form of an IPv6 address: 1111:2222:3333:4444:5555:6666:7777:8888 and various shorthand variations.

## EXAMPLES
Configure LLDP adminStatus to Receive and Transmit for interface eth2

lldptool -L -i eth2 adminStatus=rxtx

lldptool set-lldp -i eth2 adminStatus=rxtx

Query the LLDP adminStatus for interface eth3

lldptool -l -i eth3 adminStatus

lldptool get-lldp -i eth3 adminStatus

Query the LLDP statistics for interface eth3

lldptool -S -i eth3

lldptool stats -i eth3

Query the local TLVs which are being transmitted for a given interface:

lldptool -t -i eth3

lldptool get-tlv -i eth3

Query the received neighbor TLVs received on a given interface:

lldptool -t -n -i eth3

lldptool get-tlv -n -i eth3

Query the value of the System Description TLV as received from the neighbor on a given interface:

lldptool -t -n -i eth3 -V sysDesc

lldptool get-tlv -n -i eth3 -V 6

Disable transmit of the IEEE 802.3 MAC/PHY Configuration Status TLV for a given interface:

lldptool -T -i eth3 -V macPhyCfg enableTx=no

lldptool set-tlv -i eth3 -V 0x120f01 enableTx=no

Query value of the transmit setting for the Port Description TLV for a given interface:

lldptool -t -i eth3 -V portDesc -c enableTx

lldptool get-tlv -i eth3 -V 4 -c enableTx

Set a Management Address TLV on eth3 to carry IPv4 address 192.168.10.10

lldptool -T -i eth3 -V mngAddr ipv4=192.168.10.10

Set a Management Address TLV on eth3 to carry IPv6 address ::192.168.10.10

lldptool -T -i eth3 -V mngAddr ipv6=::192.168.10.10

Get the configured IPv4 address for the Management Address TLV on eth3

lldptool -t -i eth3 -V mngAddr -c ipv4

Get all configured attributes for the Management Address TLV on eth3

lldptool -t -i eth3 -V mngAddr -c

Enable transmit of the Edge Virtual Bridging TLV for interface eth4

lldptool -i eth4 -T -g ncb -V evbCfg enableTx=yes

Enable transmit of VDP for interface eth4

lldptool -i eth4 -T -V vdp enableTx=yes

Display process identifier of lldpad

lldptool -p

## SEE ALSO
lldptool-dcbx(8), lldptool-ets(8), lldptool-pfc(8), lldptool-app(8), lldptool-med(8), lldptool-vdp(8), lldptool-evb(8), lldptool-evb22(8), dcbtool(8), lldpad(8)

## COPYRIGHT
lldptool - LLDP agent configuration utility

Copyright(c) 2007-2012 Intel Corporation. Portions of lldptool are based on:

hostapd-0.5.7

Copyright

(c) 2004-2008, Jouni Malinen <j@w1.fi>

## LICENSE
This program is free software; you can redistribute it and/or modify it under the terms and conditions of the GNU General Public License, version 2, as published by the Free Software Foundation.

This program is distributed in the hope it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA.

The full GNU General Public License is included in this distribution in the file called "COPYING".

## SUPPORT
Contact Information: open-lldp Mailing List <lldp-devel@open-lldp.org>


lldptool-app

title: lldptool-app(8)

summary: Show / manipulate APP TLV configuration

text:
# lldptool-app(8)

## NAME
APP - Show / manipulate APP TLV configuration

## SYNOPSIS
lldptool -t -i ethx -V APP [-c app]

lldptool -T -i ethx -V APP [-d] app=prio,sel,pid

## DESCRIPTION
The APP TLV is an informational TLV and will advertise the current configured application table. If the peer APP TLV and a local APP TLV match the same selector and protocol field the local parameter is used.

## ARGUMENTS
app

Configures a local application data field using the three parameters: priority (prio), selector (sel), and protocol (pid). The -d option can be provided to remove an entry which matches the three parameters.

## Theory of Operations
The APP TLV is an informational TLV for most end stations. It is not expected that setting APP data should be required. Peer data will be processed and added to the application data table by default assuming there does not already exist a local entry with matching selector and priority fields.

By adding APP data to the application table it is available for applications, eg iscsid, to query. Applications query for a specific protocol and selector and may use this data to map traffic to the corresponding traffic class.

## EXAMPLE & USAGE
Configure ISCSI application for priority 4 on eth2

lldptool -T -i eth2 -V APP app=4,2,3260

Configure FCoE application for priority 3 on eth2

lldptool -T -i eth2 -V APP app=3,1,35078

Remove FCoE application for priority 3 on eth2

lldptool -T -i eth2 -V APP -d app=3,1,35078

Display locally configured application table on eth2

lldptool -t -i eth2 -V APP -c app

Display last transmitted APP TLV on eth2

lldptool -t -i eth2 -V APP

## SOURCE
o

IEEE 802.1Qaz (http://www.ieee802.org/1/pages/dcbridges.html)

## SEE ALSO
lldptool(8), lldpad(8)

## AUTHOR
John Fastabend


lldptool-dcbx

title: lldptool-dcbx(8)

summary: Show / manipulate DCBX configuration

text:
# lldptool-dcbx(8)

## NAME
DCBX - Show / manipulate DCBX configuration

## SYNOPSIS
lldptool -t -i ethx -V IEEE-DCBX -c [mode]

lldptool -T -i ethx -V IEEE-DCBX mode=reset

lldptool -t -i ethx -V <CIN-DCBX|CEE-DCBX> -c [enableTx]

lldptool -T -i ethx -V <CIN-DCBX|CEE-DCBX> enableTx=<yes|no>

## DESCRIPTION - DCBX MODE
lldpad supports the following versions of the DCB capabilities exchange (DCBX) protocol:

CIN DCBX

<http://download.intel.com/technology/eedc/dcb_cep_spec.pdf>

CEE DCBX

<http://www.ieee802.org/1/files/public/docs2008/az-wadekar-dcbx-capability-exchange-discovery-protocol-1108-v1.01.pdf>

IEEE DCBX

See the IEEE 802.1Qaz-2011 specification for details."

IEEE DCBX is the default DCBX mode for a DCB capable interface. Therefore the default and configured IEEE DCBX TLVs will be transmitted when the interface comes up. lldpad can be globally configured to support one of the legacy DCBX versions (CIN or CEE). If the remote LLDP agent does not transmit any IEEE DCBX TLVs and does transmit a legacy DCBX TLV which matches the configured legacy DCBX version, then the DCBX mode will drop back to legacy DCBX mode. It will not transition back to IEEE DCBX mode until the next link reset. If lldpad has dropped back to legacy DCBX mode for a given interface and the daemon is stopped and restarted, the legacy DCBX mode for that interface will be used instead of starting out in IEEE DCBX mode. This behavior only applies to the case where lldpad is restarted and is not persistent across a system reboot.

The DCBX mode can be queried and configured by using the special tlvid IEEE-DCBX. There is not an actual TLV which corresponds to this tlvid. Its use is to query and reset the IEEE DCBX mode. When queried, IEEE DCBX mode can take the following values:

auto - IEEE DCBX will be used (initially) if lldpad is restarted. An exception is if the DCBX mode has been forced to a legacy DCBX mode, then the specified legacy mode will be used. See information about the 'dcbx' parameter in dcbtool(8) for more information about this exception."

CEE - CEE DCBX will be used if lldpad is restarted

CIN - CIN DCBX will be used if lldpad is restarted

The IEEE DCBX mode can be reset to auto by setting the mode argument to the value reset

## DESCRIPTION - DCBX CONFIGURATION
The detailed configuration of the IEEE DCBX TLVs can be found in related lldptool man pages for each IEEE DCBX TLV (see lldptool-pfc(8), lldptool-ets(8) and lldptool-app(8)).

The detailed configuration of the CIN and CEE DCBX TLVs is performed using dcbtool (see dcbtool(8)). However, lldptool can configure the enableTx parameter of the CIN and CEE DCBX TLVs (as it can with most other TLVs). Since lldpad only transmits TLVs for one version of DCBX on any given interface, the enableTx parameter for the CIN and CEE DCBX TLVs (and for the IEEE DCBX feature TLVs) takes effect only when the corresponding DCBX version is active.

## ARGUMENTS
mode=reset

Reset the DCBX mode that will be used if lldpad is restarted by setting the mode argument to reset using the special tlvid IEEE-DCBX.

enableTx

Enable the specified DCBX TLV (CIN-DCBX or CEE-DCBX) to be transmitted in the LLDPDU if that DCBX mode for the specified interface has been selected.

## EXAMPLE & USAGE
Query the current DCBX mode that will be used if lldpad is restarted. (this is not a persistent setting)

lldptool -t -i eth3 -V IEEE-DCBX -c mode

Reset the DCBX mode to be 'auto' (start in IEEE DCBX mode) after the next lldpad restart

lldptool -T -i eth3 -V IEEE-DCBX mode=reset

Enable transmission of the CEE DCBX TLV

lldptool -T -i eth3 -V CEE-DCBX enableTx=yes

Disable transmission of the CIN DCBX TLV

lldptool -T -i eth3 -V CIN-DCBX enableTx=no

Query the configuration of enableTx for the CEE DCBX TLV

lldptool -t -i eth3 -V CEE-DCBX -c enableTx

## SEE ALSO
dcbtool(8), lldptool(8), lldptool-ets(8), lldptool-pfc(8), lldptool-app(8), lldpad(8)

## AUTHOR
Eric Multanen


lldptool-ets

title: lldptool-ets(8)

summary: Show / manipulate ETS TLV configuration

text:
# lldptool-ets(8)

## NAME
ETS-{CFG|REC} - Show / manipulate ETS TLV configuration

## SYNOPSIS
lldptool -t -i ethx -V ETS-CFG <-c CONFIG_ARG ...>

CONFIG_ARG := { enableTx | willing | tsa | up2tc | numtcs | tcbw }

lldptool -T -i ethx -V ETS-CFG CONFIG_ARG=value ...

CONFIG_ARG :=

enableTx = {yes|no} |

willing = {yes|no} |

tsa = tc:{ets|strict|vendor},... |

up2tc = priority:tc,... |

tcbw = bw1,bw2,...

lldptool -t -i ethx -V ETS-REC <-c CONFIG_ARG ...>

lldptool -T -i ethx -V ETS-REC CONFIG_ARG=value ...

CONFIG_ARG :=

enableTx = {yes|no} |

tsa = tc:{ets|strict|vendor},... |

up2tc = priority:tc,... |

tcbw = bw1,bw2,...

## DESCRIPTION
The Enhanced Transmission Selection (ETS) feature has a recommendation TLV and a configuration TLV configured with ETS-REC and ETS-CFG respectively.

## ARGUMENTS
enableTx

Enables the ETS TLV to be transmitted

willing

Sets the ETS-CFG willing bit

tsa

Transmission selection algorithm, sets a comma separated list of traffic classes to the corresponding selection algorithm. Valid algorithms include "ets", "strict" and "vendor".

up2tc

Comma separated list mapping user priorities to traffic classes.

tcbw

Comma separated list of bandwidths for each traffic class the first value being assigned to traffic class 0 and the second to traffic class 1 and so on. Undefined bandwidths are presumed to be 0.

numtcs

Displays the number of ETS supported traffic classes.

## Theory of Operations
IEEE 802.1Qaz is enabled by default on hardware that supports this mode indicated by support for the DCBNL interface. Kernel config option CONFIG_DCB. The ETS-CFG TLV is advertised by default with the attributes indicated by querying the hardware for its current configuration. A valid configuration is to map all priorities to a single traffic class and use the link strict selection algorithm. This is equivalent to being in a non-DCB enabled mode.

To support legacy DCBX (CIN or CEE) the ETS-CFG and ETS-REC TLVs are disabled if a legacy DCBX TLV is received and no valid IEEE DCBX TLVs are received. The hardware DCBX mode will also be set to the legacy mode and IEEE mode is disabled. This allows switches to be configured and end nodes will then be configured accordingly without any configuration required on the end node. See lldpad(8) for more information about the operation of the DCBX selection mechanism.

Mapping applications and protocols to traffic classes is required for ETS to be useful. User space programs can encode the priority of an application with the SO_PRIORITY option. The net_prio cgroup can be used to assign application traffic to specific priorities. See the kernel documentation and cgdcbxd(8) for net_prio cgroup information.

## EXAMPLE & USAGE
Configure willing bit for interface eth2

lldptool -T -i eth2 -V ETS-CFG willing=yes

Configure traffic classes for ETS and strict priority on eth2

lldptool -T -i eth2 -V ETS-CFG tsa=0:ets,1:ets,2:ets,3:ets,4:strict,5:strict

Configure 1:1 mapping from priority to traffic classes on eth2

lldptool -T -i eth2 -V ETS-CFG up2tc=0:0,1:1,2:2,3:3,4:4,5:5,6:6,7:7

Display local configured ETS-CFG parameters for tcbw

lldptool -t -i eth2 -V ETS-CFG -c tcbw

Display last transmitted ETS-CFG TLV

lldptool -t -i eth2 -V ETS-CFG

Configure ETS-CFG and ETS-REC for default DCB on eth2

lldptool -T -i eth2 -V ETS-CFG tsa=0:ets,1:ets,2:ets,3:ets,4:ets,5:ets,6:ets,7:ets up2tc=0:0,1:1,2:2,3:3,4:4,5:5,6:6,7:7 tcbw=12,12,12,12,13,13,13,13 lldptool -T -i eth2 -V ETS-REC tsa=0:ets,1:ets,2:ets,3:ets,4:ets,5:ets,6:ets,7:ets up2tc=0:0,1:1,2:2,3:3,4:4,5:5,6:6,7:7 tcbw=12,12,12,12,13,13,13,13

## SOURCE
o

IEEE 802.1Qaz (http://www.ieee802.org/1/pages/dcbridges.html)

## NOTES
Support for tc-mqprio was added in 2.6.38 on older kernels other mechanisms may need to be used to map applications to traffic classes.

## SEE ALSO
lldptool(8), lldptool-app(8), lldpad(8), tc-mqprio(8),

## AUTHOR
John Fastabend


lldptool-evb

title: lldptool-evb(8)

summary: Show / manipulate EVB TLV configuration

text:
# lldptool-evb(8)

## NAME
evb - Show / manipulate EVB TLV configuration

## SYNOPSIS
lldptool -t -g ncb -i ethx -V evbCfg -c enableTx

lldptool -T -g ncb -i ethx -V evbCfg -c enableTx=[yes|no]

lldptool -t -g ncb -i ethx -V evbCfg -c fmode

lldptool -T -g ncb -i ethx -V evbCfg -c fmode=[bridge|reflectiverelay]

lldptool -t -g ncb -i ethx -V evbCfg -c capabilities

lldptool -T -g ncb -i ethx -V evbCfg -c capabilities=[rte|ecp|vdp|none]

lldptool -t -g ncb -i ethx -V evbCfg -c rte

lldptool -T -g ncb -i ethx -V evbCfg -c rte=[<rte>]

lldptool -t -g ncb -i ethx -V evbCfg -c vsis

lldptool -T -g ncb -i ethx -V evbCfg -c vsis=[<number of vsis>]

## DESCRIPTION
The EVB TLV is a TLV to announce the station and bridge's edge virtual bridging (evb) capabilities and request the bridge forwarding mode. If both sides have agree on edge control protocol (ECP), VSI discovery protocol (VDP) capabilities, both sides can exchange VDP TLV using ECP frames. The vsis parameter will set the maximum number of VSIs and show the number of currently configured VSIs.

## ARGUMENTS
enableTx

Enables the EVB TLV to be transmitted

fmode

shows or sets the forwarding mode between bridge (default) or reflectiverelay (RR).

capabilities

shows or sets the local capabilities that are announced to the adjacent switch in the TLV. This parameter will accept any combination of rte, vdp or ecp, separated by ",". Use the keyword "none" if you do not want to set any capabilities.

rte

shows or set the local run time exponent (RTE). The RTE will be used as the base for the timing of the ECP and VDP protocols.

vsis

shows or sets the number of virtual station interfaces (VSIs) that are announced to the adjacent switch in the TLV. This parameter expects a number between 0 and 65535.

## Theory of Operation
The EVB TLV is used to announce and exchange supported parameters between the station and an adjacent switch. The TLV uses the nearest customer bridge agent.

If "reflectiverelay" is set as forwarding mode, the switch will allow "reflection" of frames coming from different sources at the same port back to the port. This will allow communication between virtual machines on the same host via the switch.

The capabilities parameter is used to set RTE, ECP and VDP support. VDP TLVs in ECP frames can only be exchanged if both sides agree on ECP and VDP as capabilities. RTE will be used as the base timing parameter for ECP and VDP.

## EXAMPLE & USAGE
Display locally configured values for eth8

lldptool -t -g ncb -i eth8 -V evbCfg

Display remotely configured values for eth8

lldptool -n -g ncb -t -i eth8 -V evbCfg

Display wether evb tlv is configured for tx on eth8

lldptool -t -g ncb -i eth8 -V evbCfg -c enableTx

Display the currently requested forwarding mode for eth8

lldptool -t -g ncb -i eth8 -V evbCfg -c fmode

Set the forwarding mode to reflective relay

lldptool -T -g ncb -i eth8 -V evbCfg -c fmode=reflectiverelay

Display the currently configured capabilities

lldptool -t -g ncb -i ethx -V evbCfg -c capabilities

Set the locally possible capabilities to RTE, ECP and VDP

lldptool -T -g ncb -i ethx -V evbCfg -c capabilities=rte,ecp,vdp

Resets the locally possible capabilities to "none"

lldptool -T -g ncb -i ethx -V evbCfg -c capabilities=none

Display the locally configured value for RTE

lldptool -t -g ncb -i ethx -V evbCfg -c rte

Set the value for RTE

lldptool -T -g ncb -i ethx -V evbCfg -c rte=[<rte>]

Display the configured maximum number of VSIs

lldptool -t -g ncb -i ethx -V evbCfg -c vsis

Set the maximum number of VSIs

lldptool -T -g ncb -i ethx -V evbCfg -c vsis=[<number of vsis>]

## SOURCE
o

IEEE 802.1Qbg (http://www.ieee802.org/1/pages/802.1bg.html)

## NOTES
Currently the code in lldpad reflects draft 0 of the upcoming standard. EVB TLVs on the wire can be decoded with wireshark > v1.6.

## SEE ALSO
lldptool-vdp(8), lldptool(8), lldpad(8)

## AUTHOR
Jens Osterkamp


title: lldptool-evb22(8)

text:
# lldptool-evb22(8)

## NAME
evb22 - Show / manipulate EVB IEEE 802.1 Ratified Standard TLV configuration

## SYNOPSIS
lldptool -t -i ethx -g ncb -V evb

lldptool -t -i ethx -g ncb -V evb -c

lldptool -t -i ethx -g ncb -V evb -c enabletx

lldptool -T -i ethx -g ncb -V evb -c enabletx=[yes|no]

lldptool -t -i ethx -g ncb -V evb -c evbmode

lldptool -T -i ethx -g ncb -V evb -c evbmode=[bridge|station]

lldptool -t -i ethx -g ncb -V evb -c evbrrreq

lldptool -T -i ethx -g ncb -V evb -c evbrrreq=[yes|no]

lldptool -t -i ethx -g ncb -V evb -c evbrrcap

lldptool -T -i ethx -g ncb -V evb -c evbrrcap=[yes|no]

lldptool -t -i ethx -g ncb -V evb -c evbgpid

lldptool -T -i ethx -g ncb -V evb -c evbgpid=[yes|no]

lldptool -t -i ethx -g ncb -V evb -c ecpretries

lldptool -T -i ethx -g ncb -V evb -c ecpretries=[0..7]

lldptool -t -i ethx -g ncb -V evb -c ecprte

lldptool -T -i ethx -g ncb -V evb -c ecprte=[0..31]

lldptool -t -i ethx -g ncb -V evb -c vdprwd

lldptool -T -i ethx -g ncb -V evb -c vdprwd=[0..31]

lldptool -t -i ethx -g ncb -V evb -c vdprka

lldptool -T -i ethx -g ncb -V evb -c vdprka=[0..31]

## DESCRIPTION
The Edge Virtual Bridge (EVB) TLV is a TLV to announce the station and bridge's edge virtual bridging (EVB) capabilities and may request the bridge port to be set into reflective relay (hairpin) mode. If both sides agree on the modes and time out values, the edge control protocol (ECP) will be used to exchange VSI discovery protocol (VDP) data using ECP frames between the host interface and the adjacent switch port facing the host interface.

This man pages describes the IEEE 802.1 Qbg ratified standard dated from July 5th, 2012. The arguments and parameters differ from the IEEE 802.1 Qbg draft 0.2, which is also implemented. The EVB protocol version to be used depends on the organizational unique identifier (OUI) of the EVB TLV in the LLDP data stream. A OUI value of 0x001b3f stands for the IEEE 802.1 Qbg draft 0.2, a OUI value of 0x0080c2 stands for the IEEE 802.1 Qbg ratified standard. The version of the ECP and VDP protocols are determined by the ethernet type field in the ethernet header. The ethernet type value for IEEE 802.1 Qbg draft 0.2 is 0x88b7, the value for IEEE 802.1 Qbg ratified standard is 0x8890. Note that the EVB protocol is exchanged between nearest customer bridges only, employing the reserved multicast MAC address 01:80:c2:00:00:00 as destination MAC address. lldpad(8) supports both versions, the switch port configuration determines which version will be used. The switch port configuration should select only one protocol version, never both.

The command line options and arguments are explained in the lldptool(8) man pages. Only the EVB, ECP and VDP protocol specific parameters are detailed in this manual page.

## ARGUMENTS
The invocation without command line option '-c' and argument displays the complete EVB, ECP and VDP protocol settings in a pretty print out. See below for a detailed description on how to interpret the output.

-c text

Use of the command line option '-c' without any argument displays all known parameters in the format of key=value, which is suitable for post processing. Use command line option '-c' and one of the following arguments to display and set individual parameters. Text can be one of the following values:

enabletx

Enables or disables the EVB TLV to be transmitted. When set to disabled no EVB TLV will be included in the LLDP data stream. Furthermore the output of the complete EVB settings without option '-c' will be empty.

evbmode

Display the current role or sets the role the to given value. Supported values are either "station" or "bridge".

evbrrreq

Shows the current reflective relay (hairpin) request mode or sets the reflective relay (hairpin) request mode. If the value is "yes", the station requests the interface facing switch port to be set in reflective relay (hairpin) mode. This field is only valid for stations, the output of evbmode equals "station".

evbrrcap

Shows the current reflective relay (hairpin) capabilities or sets the reflective relay (hairpin) capabilities. If the value is "yes", the switch port will be set in reflective relay (hairpin) mode. This field is only valid for switches, the output of evbmode equals "bridge".

gpid

Shows the current station or switch support for grouping or turns on/off the station or switch support for grouping. If set to true, the station or switch wants to use group identifiers in VDP protocols.

ecpretries

Shows or sets the maximum number of retries for ECP frames to be retransmitted. A retransmit occurs when no ECP acknowledgement message has been received during a given time period.

ecprte

Shows or sets the local run time exponent (RTE). The RTE will be used as the base for the timing of the ECP protocol time outs and retransmits. The wait time is calculated as 10*2ecprte micro seconds.

vdprwd

Shows or sets the number of resource wait delay value. This value is calculated as 10*2vdprwd micro seconds and determines the maximum wait time for VDP protocol acknowledgements.

vdprka

Shows or sets the number of re-init keep alive value. This value is calculated as 10*2vdprka micro seconds and determines the wait time for VDP protocol to send a keep alive message.

## Theory of Operation
The EVB TLV is used to announce and exchange supported parameters between the station and an adjacent switch. If reflectiverelay is active, the switch sends back ethernet frames on the very same port it received the frame on. This is an extension to the current bridging standard and allows communication between virtual machines on the same host through the switch port.

## EXAMPLE & USAGE
Display locally configured values for eth0

lldptool -t -g ncb -i eth0 -V evb

```
EVB Configuration TLV
	bridge:(00)
	station:rrreq,rrstat(0x5)
	retries:7 rte:31
	mode:station r/l:0 rwd:31
	r/l:0 rka:8
```

This output is displayed when enabletx has been enabled. The first line shows the currently known status of the bridge. The second line shows the currently known status of the station. The status is displayed verbose appended by the hexadecimal value in parenthesis. The verbose output uses the bit naming convention used in the standard document. The third line displays the values for the ECP protocol number of retransmits (retries) and the retransmit timeout exponent. The forth line shows the current mode of operation, either bridge or station, the resource wait delay value (rwd) and an indication if the local (0) or remote (1) rwd value is used. The fifth line displays the value of the re-init keep alive counter (rka) and an indication if the local (0) or remote (1) rka value is used.

Display the currently requested forwarding mode for eth0

lldptool -t -g ncb -i eth0 -V evb -c evbrrreq

Display the locally configured value for RTE

lldptool -t -g ncb -i eth0 -V evb -c evbrte

Set the value for RTE to its maximum value

lldptool -T -g ncb -i eth0 -V evb -c rte=7

Set the value for enabletx to yes

lldptool -T -g ncb -i eth0 -V evb -c enabletx=yes

## NOTES
Currently the code in lldpad reflects IEEE 802.1 Qbg draft 0.2 of the upcoming standard. Wireshark support for IEEE 802.1 Qbg ratified standard TLVs is currently missing. Support for the IEEE 802.1 Qbg ratified standard protocols ECP and VDP is currently under development and not fully functional.

## SEE ALSO
lldptool-vdp(8), lldptool(8), lldpad(8)

IEEE 802.1Qbg (http://www.ieee802.org/1/pages/802.1bg.html)

## AUTHOR
Thomas Richter


lldptool-med

title: lldptool-med(8)

text:
# lldptool-med(8)

## NAME
LLDP-MED - Show / manipulate MED TLV configurations

## SYNOPSIS
lldptool -t -i ethx -V [ TLV_TYPE ] enableTx

lldptool -T -i ethx -V [ TLV_TYPE ] enableTx = { yes | no }

lldptool -T -i ethx -V LLDP-MED devtype = { class1 | class2 | class3 | none }

lldptool -t -i ethx -V LLDP-MED devtype

TLV_TYPE : = {LLDP-MED | medCap | medPolicy | medLoc | medPower | medHwRev | medFwRev | medSwRev | medSerNum | medManuf | medModel | medAssetID }

## DESCRIPTION
The LLDP-MED extensions support the Link Layer Discovery Protocol for Media Endpoint Devices defined in the ANSI/TIA-1057-2006 document. Each TLV can be configured as a class1 , class2 or class3 device. Class I devices are the most basic class of Endpoint Device, Class II devices support media stream capabilities and Class III devices directly support end users of the IP communication system. See ANS-TIA-1057 for clarification of class types.

## ARGUMENTS
enableTx

Enables the TLV to be transmitted

devtype

Set or query the class type of the device.

## TLV_TYPE
List of supported TLV specifiers applicable to Media Endpoint Devices.

LLDP-MED

apply arguments to all supported MED TLVs.

medCAP

LLDP-MED Capabilities TLV

medPolicy

LLDP-MED Network Policy TLV

medLoc

LLDP-MED Location TLV

medPower

LLDP-MED Extended Power-via-MDI TLV

medHwRev

LLDP-MED Hardware Revision TLV

medFwRev

LLDP-MED Firmware Revision TLV

medSwRev

LLDP-MED Software Revision TLV

medSerNum

LLDP-MED Serial Number TLV

medManuf

LLDP-MED Manufacturer Name TL

medModel

LLDP-MED Model Name TLV

medAssetID

LLDP-MED Asset ID TLV

## EXAMPLE & USAGE
Enable class1 MED device on eth2

lldptool -T -i eth2 -V LLDP-MED enableTx=yes devtype=class1

Query class type of MED on eth2

lldptool -t -i eth2 -V LLDP-MED -c devtype

Query transmit state of medPolicy on device eth2

lldptool -t -i eth2 -V medPolicy -c enableTx

## SOURCE
o

Link Layer Discovery Protocol for Media Endpoint Devices (http://www.tiaonline.org/standards/technology/voip/documents/ANSI-TIA-1057_final_for_publication.pdf)

## SEE ALSO
lldptool(8), lldpad(8)

## AUTHOR
John Fastabend


lldptool-pfc

title: lldptool-pfc(8)

summary: Show / manipulate PFC TLV configuration

text:
# lldptool-pfc(8)

## NAME
PFC - Show / manipulate PFC TLV configuration

## SYNOPSIS
lldptool -t -i ethx -V PFC [ -c [ enableTx | willing | enabled | delay ] ]

lldptool -T -i ethx -V PFC <CONFIG_ARG=value ...>

CONFIG_ARG:=

enableTx=<yes|no>

willing=<yes|no|0|1>

enabled=<none|[0..7],[0..7],...>

delay=<integer value>

## DESCRIPTION
The PFC TLV is used to display and set current PFC TLV attributes.

## ARGUMENTS
enableTx

Enable the PFC TLV to be transmitted in the LLDP PDU for the specified interface.

willing

Display or set the willing attribute. If set to yes and a peer TLV is received then the peer PFC attributes will be used. If set to no then locally configured attributes are used.

enabled

Display or set the priorities with PFC enabled. The set attribute takes a comma separated list of priorities to enable, or the string none to disable all priorities.

delay

Display or set the delay attribute used to configure PFC thresholds in hardware buffers. If PFC is enabled and frames continue to be dropped due to full hardware buffers then increasing this value may help.

## Theory of Operations
The PFC TLV uses the Symmetric attribute passing state machine defined in IEEE 802.1Qaz. This means the attributes used will depend on the willing bit. If the willing bit is set to 1 and a peer TLV is received then the peers attributes will be used. If the willing bit is set to 0 the local attributes will be used. When both the peer and local configuration are willing a tie breaking scheme is used. For more detailed coverage see the specification.

## EXAMPLE & USAGE
Enable PFC for priorities 1, 2, and 4 on eth2

lldptool -T -i eth2 -V PFC enabled=1,2,4

Disable PFC for all priorities on eth2

lldptool -T -i eth2 -V PFC enabled=none

Display configuration of PFC enabled priorities for eth2

lldptool -t -i eth2 -V PFC -c enabled

Display last transmitted PFC TLV on eth2

lldptool -t -i eth2 -V PFC

## SOURCE
o

IEEE 802.1Qaz (http://www.ieee802.org/1/pages/dcbridges.html)

## SEE ALSO
lldptool(8), lldpad(8)

## AUTHOR
John Fastabend


lldptool-vdp

title: lldptool-vdp(8)

summary: Show / manipulate VDP TLV configuration

text:
# lldptool-vdp(8)

## NAME
vdp - Show / manipulate VDP TLV configuration

## SYNOPSIS
lldptool -t -i ethx -V vdp -c enableTx

lldptool -T -i ethx -V vdp -c enableTx=[yes|no]

lldptool -t -i ethx -V vdp -c mode

lldptool -T -i ethx -V vdp -c mode=<mode>,<mgrid>,<typeid>,<typeidversion>,<instanceid>,<mac>,<vlan>

lldptool -t -i ethx -V vdp -c role

lldptool -T -i ethx -V vdp -c role=[station|bridge]

## DESCRIPTION
The VSI discovery protocol (VDP) is NOT a TLV in the LLDP sense but rather a protocol to manage the association and deassociation of virtual station interfaces (VSIs) between the station and an adjacent switch. VDP uses ECP as transport for VDP TLVs. An ECP frame may contain multiple VDP TLVs. Each VDP TLVs contains a mode, typeid, version, instanceid, mac and vlan for a VSI.

## ARGUMENTS
enableTx

Enables or disables VDP

mode

shows or sets modes for VSIs with the following parameters:

<mode>

mode (0=preassociate, 1=preassociate with RR, 2=associate, 3=deassociate)

<mgrid>

manager (database) id

<typeid>

VSI type id

<version>

VSI type id version

<instanceid>

VSI instance id

<format>

VDP filter info format

<mac>

VSI mac address

<vlan>

VSI vlan id

role

shows or sets the role of the local machine to act as either station (default) or bridge.

## Theory of Operation
The VDP protocol is used to pre-associate, associate or deassociate VSIs to and adjacent switch. Information about the VSIs is formatted into VDP TLVs which are then handed to ECP for lower-level transport. Each ECP frame may contain multiple VDP TLVs.

Two ways to receive VSI information exist in llpdad: via netlink or with lldptool. netlink is used by libvirt to communicate VSIs to lldpad. lldptool can be used to associate/deassociate VSIs from the command line. This is especially helpful for testing purposes.

## EXAMPLE & USAGE
Display if vdp is enabled on eth8

lldptool -t -i eth8 -V vdp -c enableTx

Enable vdp on eth8

lldptool -T -i eth8 -V vdp -c enableTx=yes

Display the currently configured VSIs for eth8

lldptool -t -i eth8 -V vdp -c mode

Associate a VSI on eth8

lldptool -T -i eth8 -V vdp -c mode=2,12,1193046,1,fa9b7fff-b0a0-4893-8e0e-beef4ff18f8f,2,52:54:00:C7:3E:CE,3

Display the locally configured role for VDP on eth8

lldptool -t -i eth8 -V vdp -c role

Set the local role for VDP on eth8

lldptool -T -i eth8 -V vdp -c role=bridge

## SOURCE
o

IEEE 802.1Qbg (http://www.ieee802.org/1/pages/802.1bg.html)

## NOTES
Currently the code in lldpad reflects draft 0 of the upcoming standard. ECP/VDP TLVs on the wire can be decoded with wireshark > v1.8.

## SEE ALSO
lldptool-evb(8), lldptool(8), lldpad(8)

## AUTHOR
Jens Osterkamp


vdptool

title: vdptool(8)

text:
# vdptool(8)

## NAME
vdptool - manage the VSI associations and status of lldpad

## SYNOPSIS
vdptool <command> [options] [argument]

## DESCRIPTION
vdptool is used to query and configure the VSI associations in lldpad. Only the ratified stardard version of the VDP protocol (also refered to as vdp22) is supported. It connects to the client interface of lldpad to perform these operations. vdptool will operate in interactive mode if it is executed without a command. In interactive mode, vdptool will also function as an event listener to print out events as they are received asynchronously from lldpad(still to be done). It will use libreadline for interactive input when available (still to be done).

## OPTIONS
-i [ifname]

specifies the network interface to which the command applies. Most vdptool commands require specifying a network interface.

-V [tlvid]

specifies the VDP tlv identifier to be set or queried.

The tlvid is an integer value used to identify specific VDP TLVs. The tlvid value is the type value for types not equal to 127 (the organizationally specific type). For organizationally specific TLVs, the tlvid is the value represented by the 3 byte OUI and 1 byte subtype - where the subtype is the lowest order byte of the tlvid.

The tlvid can be entered as a numerical value (e.g. 10 or 0xa), or for supported TLVs, as a keyword (such as assoc, deassoc, preassoc, preassoc-rr, etc). Review the vdptool help output to see the list of supported TLV keywords. Use option -c to specify the parameters and its values to be set or queried.

-n

"neighbor" option for commands which can use it (e.g. get-tlv). Use this flag to retrieve the last VDP22 data returned from the bridge. (not yet supported).

-c <argument list>

Specifies additional parameters for TLV queries and associations commands. The argument list varies, depending on the command option (-T) or (-t). To establish a VSI association use the command option (-T) and specify additional information as arguments in the form of key=value. See the VSI Parameter subsection and Example section below. To query a VSI specific association use the command option (-t) and specify the value of the VSI Instance Identifier (keywork uuid followed be the VSI UUID value) of the VSI association as configuration parameter.

-r

show raw client interface messages

-R

show only raw Client interface messages

-W

Wait for the bridge response message

### VSI Parameter
Each VDP22 TLVs contains a command mode, manager identifier, type identifier, type identifier version, VSI instance identifier, migration hints and filter information. The fields are explained next:

mode (Command Mode):

The command mode determines the type of the VSI association to be established. It is an ascii string can be one of:

assoc:

Create an VSI association.

preassoc:

Create an VSI preassociation. The association is only announced to the switch.

preassoc-rr:

Create an VSI preassociation. The association is only announced to the switch and the switch should reserve the resources.

deassoc:

Delete an VSI association.

Other strings are not recognized and return an error. mgrid2 (Manager identifier):

The manager identifier is a string of up to 16 alphanumeric characters. It can also be an UUID according to RFC 4122 with optional dashes in between.

typeid (Type Identifier):

The type identifier is a number in the range of 0 to 2^24 - 1.

typeidver (Type Identifier Version):

The type identifer version is a number in the range of 0 to 255.

uuid (VSI Instance Identifier):

The VSI instance identifier is an UUID according to RFC 4122 with optional dashes in between.

hints (Migration Hints):

The migration hints is a string aiding in migration of virtual machines:

none:

No hints available.

from:

The virtual machine is migrating away.

to:

The virtual machine is migrating to.

fid (Filter Information Data):

The filter information data can be supplied in four different formats identified by numbers in parathesis. Multiple filter information fields can be supplied, but all have to be of the same format.

vlan (1)

A vlan number only, also known as filter information format 1. The vlan identifier is a number in the range of 1 to 2^16 - 1. The high order 4 bits are used as quality of service bits. The vlan identifier can be zero, a vlan identifier is then selected by the switch. Refer to IEEE 802.1 Qbg ratified standard for details.

vlan-mac (2)

A vlan number and MAC address delimited by a slash ('-'), also known as filter information format 2. The MAC address is specified in the format xx:xx:xx:xx:xx:xx. The colons are mandatory. For vlan details see (1).

vlan-mac-group (4)

A vlan number, MAC address and group identifier, each delimited by a slash ('-'), also known as filter information format 4. The group identifier is a 32 bit number. For vlan and MAC address details see (1) and (2).

vlan--group (3)

A vlan number and group identifier, delimited by two slashes ('--'), also known as filter information format 3. For vlan and group details see (1) and (4).

oui (Organizationally Unique Identifier):

This defines the optional Organizationally defined information field. This contains the specific sets of values for this entry. There can be multiple organizational specific fields, in which case there will be multiple keywords oui= followed by the values. The value is of the following format:

```
oui=OUI,[Organization specific values ]

```

The OUI specifies the name of the Organization that is responsible for defining this content. A comma is mandatory after the OUI field. The fields following this

is specified by the organization and hence will be decoded based on the value of this OUI field. Currently, the following values for OUI are supported.

cisco

Specifies Cisco defined OUI.

## COMMANDS
license

show license information

-h, help

show usage information

-v, version

show version information

-t, get-vsi

get VSI information for the specified interface

-T, set-vsi

set VSI information for the specified interface

-p, ping

display the process identifier of the running lldpad process

-q, quit

exit from interactive mode

## NOTES
This tool is in its early design and development phase. It it buggy, incomplete and most of the ideas have not even been thought of.... It reflects the current state of development when I had been given another work assignment. I append it so some else can continue to work on this.

## EXAMPLES
Display process identifier of lldpad

vdptool -p

Create a VSI association on interface eth2

```
vdptool -i eth2 -T -V assoc -c mode=assoc -c mgrid2=blabla \
	-c typeid=5 -c uuid=1122 -c typeidver=4 -c hints=none \
	-c filter=2-52:00:00:11:22:33-200
```

Create a VSI association on interface eth2 and wait for the

response from the bridge

```
vdptool -i eth2 -T -W -V assoc -c mode=assoc -c mgrid2=blabla \
	-c typeid=5 -c uuid=1122 -c typeidver=4 -c hints=none \
	-c filter=0-52:00:00:11:22:33-200
```

Create a VSI association on interface eth2 wth OUI parameters

and wait for the response from the bridge

```
vdptool -i eth2 -T -W -V assoc -c mode=assoc -c mgrid2=blabla \
	-c typeid=5 -c uuid=1122 -c typeidver=4 -c hints=none \
	-c filter=0-52:00:00:11:22:33-200 -c oui=CompanyA,data
```

Create a VSI association on interface eth2 wth multiple OUI parameters

and wait for the response from the bridge

```
vdptool -i eth2 -T -W -V assoc -c mode=assoc -c mgrid2=blabla \
	-c typeid=5 -c uuid=1122 -c typeidver=4 -c hints=none \
	-c filter=0-52:00:00:11:22:33-200 -c oui=CompanyA,data \
	-c oui=CompanyB,data
```

Query all VSI association on interface eth2

vdptool -i eth2 -t -V assoc

Query VSI association on interface eth2 that matches specific

VSI parameters. Any of the VSI parameters below can be omitted.

vdptool -i eth2 -t -V assoc -t -V assoc -c mode=assoc \

-c mgrid2=blabla -c typeid=5 -c uuid=1122 \

-c typeidver=4 -c hints=none

## SEE ALSO
lldptool-dcbx(8), lldptool-ets(8), lldptool-pfc(8), lldptool-app(8), lldptool-med(8), lldptool-vdp(8), lldptool-evb(8), lldptool-evb22(8), dcbtool(8), lldpad(8)

## COPYRIGHT
vdptool - VSI configuration utility

Copyright(c)

(c) 2014 IBM Corporation. Portions of vdptool are based on:

open-lldp-0.96

lldptool - LLDP agent configuration utility

Copyright(c)

2007-2012 Intel Corporation. Portions of lldptool are based on:

hostapd-0.5.7

Copyright

(c) 2004-2008, Jouni Malinen <j@w1.fi>

## LICENSE
This program is free software; you can redistribute it and/or modify it under the terms and conditions of the GNU General Public License, version 2, as published by the Free Software Foundation.

This program is distributed in the hope it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA.

The full GNU General Public License is included in this distribution in the file called "COPYING".

## SUPPORT
Contact Information: open-lldp Mailing List <lldp-devel@open-lldp.org>


lldpcli

package: lldpd

title: lldpcli(8)

summary: control LLDP daemon

text:
# lldpcli(8)

## NAME
lldpcli, lldpctl — control LLDP daemon

## SYNOPSIS
lldpcli

[-dv] [-u socket] [-f format] [-c file] [command ...]

lldpctl

[-dv] [-u socket] [-f format] [interfaces ...]

## DESCRIPTION
The lldpcli program controls lldpd(8) daemon.

When no command is specified, lldpcli will start an interactive shell which can be used to input arbitrary commands as if they were specified on the command line. This interactive shell should provide completion and history support.

The options are as follows:

-d

Enable more debugging information. This flag can be repeated.

-u socket

Specify the Unix-domain socket used for communication with lldpd(8).

-v

Show lldpcli version. When repeated, show more build information.

-f format

Choose the output format. Currently plain, xml, json, json0 and keyvalue formats are available. The default is plain. json0 is more verbose than json but the structure of the JSON object is not affected by the number of interfaces or the number of neighbors. It is therefore easier to parse.

-c file

Read the given configuration file. This option may be repeated several times. If a directory is provided, each file contained in it will be read if ending by .conf. Order is alphabetical.

When invoked as lldpctl, lldpcli will display detailed information about each neighbors on the specified interfaces or on all interfaces if none are specified. This command is mostly kept for backward compatibility with older versions.

The following commands are supported by lldpcli. When there is no ambiguity, the keywords can be abbreviated. For example, show neighbors ports eth0 summary and sh neigh p eth0 sum are the same command.

exit Quit lldpcli.

help [...]

Display general help or help about a command. Also, you can get help using the completion or by pressing the ? key. However, completion and inline help may be unavailable if lldpcli was compiled without readline support but help command is always available.

show neighbors [ports ethX [,...]] [details | summary] [hidden]

Display information about each neighbor known by lldpd(8) daemon. With summary, only the name and the port description of each remote host will be displayed. On the other hand, with details, all available information will be displayed, giving a verbose view. When using hidden, also display remote ports hidden by the smart filter. When specifying one or several ports, the information displayed is limited to the given list of ports.

show interfaces [ports ethX [,...]] [details | summary] [hidden]

Display information about each local interface known by lldpd(8) daemon. With summary, only the name and the port description of each local interface will be displayed. On the other hand, with details, all available information will be displayed, giving a verbose view. When using hidden, also display local ports hidden by the smart filter. When specifying one or several ports, the information displayed is limited to the given list of ports.

show chassis [details | summary]

Display information about local chassis. With summary, most details are skipped. On the other hand, with details, all available information will be displayed, giving a verbose view.

watch [ports ethX [,...]] [details | summary] [hidden] [limit X]

Watch for any neighbor changes and report them as soon as they happen. When specifying ports, the changes are only reported when happening on the given ports. hidden, summary and details have the same meaning than previously described. If limit is specified, lldpcli will exit after receiving the specified number of events.

show configuration

Display global configuration of lldpd(8) daemon.

show statistics [ports ethX [,...]] [summary]

Report LLDP-related statistics, like the number of LLDPDU transmitted, received, discarded or unrecognized. When specifying ports, only the statistics from the given port are reported. With summary the statistics of each port is summed.

update

Make lldpd(8) update its information and send new LLDP PDU on all interfaces.

configure system hostname name

Override system hostname with the provided value. By default, the system name is the FQDN found from the resolved value of uname -n. As a special value, use "." (dot) to use the short hostname instead of a FQDN.

unconfigure system hostname

Do not override system hostname and restore the use of the node name.

configure system description description

Override chassis description with the provided value instead of using kernel name, node name, kernel version, build date and architecture.

unconfigure system description

Do not override chassis description and use a value computed from node name, kernel name, kernel version, build date and architecture instead.

configure system chassisid description

Override chassis ID with the provided value instead of using MAC address from one interface or host name.

unconfigure system chassisid

Do not override chassis ID and use a value computed from one of the interface MAC address (or host name if none is found).

configure system platform description

Override platform description with the provided value instead of using kernel name. This value is currently only used for CDP.

unconfigure system platform

Do not override platform description and use the kernel name. This option undoes the previous one.

configure system capabilities enabled capabilities

Override system capabilities with the provided value instead of using kernel information. Several capabilities can be specified separated by commas. Only available capabilities can be enabled. Valid capabilities are: other

repeater

bridge

wlan

router

telephone

docsis

station

Here is an example of use: configure system capabilities enabled bridge,router

unconfigure system capabilities enabled

Do not override capabilities and use the kernel information. This option undoes the previous one.

configure system interface pattern pattern

Specify which interface to listen and send LLDPDU to. Without this option, lldpd will use all available physical interfaces. This option can use wildcards. Several interfaces can be specified separated by commas. It is also possible to remove an interface by prefixing it with an exclamation mark. It is possible to allow an interface by prefixing it with two exclamation marks. An allowed interface beats a forbidden interfaces which beats a simple matched interface. For example, with eth*,!eth1,!eth2 lldpd will only use interfaces starting by eth with the exception of eth1 and eth2. While with *,!eth*,!!eth1 lldpcli will use all interfaces, except interfaces starting by eth with the exception of eth1. When an exact match is found, it will circumvent some tests. For example, if eth0.12 is specified, it will be accepted even if this is a VLAN interface.

unconfigure system interface pattern

Remove any previously configured interface pattern and use all physical interfaces. This option undoes the previous one.

configure system interface permanent pattern

Specify interfaces whose configuration is permanently kept by lldpd. By default, lldpd disregard any data about interfaces when they are removed from the system (statistics, custom configuration). This option allows one to specify a pattern similar to the interface pattern. If an interface disappear but matches the pattern, its data is kept in memory and reused if the interface reappear at some point. For example, on Linux, one could use the pattern eth*,eno*,enp*, which should match fixed interfaces on most systems.

unconfigure system interface permanent

Remove any previously configured permanent interface pattern. Any interface removed from the system will be forgotten. This option undoes the previous one.

configure system interface description

Some OS allows the user to set a description for an interface. Setting this option will enable lldpd to override this description with the name of the peer neighbor if one is found or with the number of neighbors found.

unconfigure system interface description

Do not update interface description with the name of the peer neighbor. This option undoes the previous one.

configure system interface promiscuous

Enable promiscuous mode on managed interfaces. When the interface is not managed any more (or when quitting lldpd), the interface is left in promiscuous mode as it is difficult to know if someone else also put the interface in promiscuous mode.

This option is known to be useful when the remote switch is a Cisco 2960 and the local network card features VLAN hardware acceleration. In this case, you may not receive LLDP frames from the remote switch. The most plausible explanation for this is the frame is tagged with some VLAN (usually VLAN 1) and your network card is filtering VLAN. This is not the only available solution to work-around this problem. If you are concerned about performance issues, you can also tag the VLAN 1 on each interface instead.

Currently, this option has no effect on anything else than Linux. On other OS, either disable VLAN acceleration, tag VLAN 1 or enable promiscuous mode manually on the interface.

unconfigure system interface promiscuous

Do not set promiscuous mode on managed interfaces. This option does not disable promiscuous mode on interfaces already using this mode.

configure system ip management pattern pattern

Specify the management addresses of this system. As for interfaces (described above), this option can use wildcards and inversions. Without this option, the first IPv4 and the first IPv6 are used. If an exact IP address is provided, it is used as a management address without any check. If only negative patterns are provided, only one IPv4 and one IPv6 addresses are chosen. Otherwise, many of them can be selected. If you want to remove IPv6 addresses, you can use !*:*. If an interface name is matched, the first IPv4 address and the first IPv6 address associated to this interface will be chosen.

unconfigure system ip management pattern

Unset any specific pattern for matching management addresses. This option undoes the previous one.

configure system bond-slave-src-mac-type value

Set the type of src mac in lldp frames sent on bond slaves Valid types are:

real

Slave real mac

zero

All zero mac

fixed

An arbitrary fixed value (00:60:08:69:97:ef)

local

Real mac with locally administered bit set. If the real mac already has the locally administered bit set, fallback to the fixed value.

Default value for bond-slave-src-mac-type is local. Some switches may complain when using one of the two other possible values (either because 00:00:00:00:00:00 is not a valid MAC or because the MAC address is flapping from one port to another). Using local might lead to a duplicate MAC address on the network (but this is quite unlikely).

configure system max-neighbors neighbors

Change the maximum number of neighbors accepted (for each protocol) on an interface. This is a global value. The default is 32. This setting only applies to future neighbors.

configure lldp agent-type nearest-bridge | nearest-non-tpmr-bridge | nearest-customer-bridge

The destination MAC address used to send LLDPDU allows an agent to control the propagation of LLDPDUs. By default, the 01:80:c2:00:00:0e MAC address is used and limit the propagation of the LLDPDU to the nearest bridge (nearest-bridge). To instruct lldpd to use the 01:80:c2:00:00:03 MAC address instead, use nearest-nontpmr-bridge instead. To use the 01:80:c2:00:00:00 MAC address instead, use nearest-customer-bridge instead.

configure lldp capabilities-advertisements

unconfigure lldp capabilities-advertisements

Enable or disable advertisements of the chassis capabilities TLV.

configure lldp management-addresses-advertisements

unconfigure lldp management-addresses-advertisements

Enable or disable advertisements of the management address TLV.

configure lldp portidsubtype ifname | macaddress

configure [ports ethX [,...]] lldp portidsubtype local value

Force port ID subtype. By default, lldpd will use the MAC address as port identifier and the interface name as port description, unless the interface has an alias. In this case, the interface name will be used as port identifier and the description will be the interface alias. With this command, you can force the port identifier to be the interface name (with ifname), the MAC address (with macaddress) or a local value (with value). In the latest case, the local value should be provided.

configure [ports ethX [,...]] lldp portdescription description

Force port description to the provided string.

configure lldp tx-interval interval

Change transmit delay to the specified value in seconds. The transmit delay is the delay between two transmissions of LLDP PDU. The default value is 30 seconds. Note: lldpd also starts another system based refresh timer on each port to detect changes such as a hostname. This is the value of the tx-interval multiplied by 20. You can specify an interval value in milliseconds by appending a "ms" suffix to the figure (e.g. "configure lldp tx-interval 1500ms" is 1.5s, not 1500s). In this case the TTL for received and sent LLDP frames is rounded up to the next second. Note: the effective interval can be limited by the operating system capabilities and CPU speed.

configure lldp tx-hold hold

Change transmit hold value to the specified value. This value is used to compute the TTL of transmitted packets which is the product of this value and of the transmit delay. The default value is 4 and therefore the default TTL is 120 seconds.

configure [ports ethX [,...]] lldp status rx-and-tx | rx-only | tx-only | disabled

Configure the administrative status of the given port. By default, all ports are configured to be in rx-and-tx mode. This means they can receive and transmit LLDP frames (as well as other protocols if needed). In rx-only mode, they won't emit any frames and in tx-only mode, they won't receive any frames. In disabled mode, no frame will be sent and any incoming frame will be discarded. This setting does not override the operational mode of the main daemon. If it is configured in receive-only mode (with the -r flag), setting any transmit mode won't have any effect.

configure [ports ethX [,...]] lldp vlan-tx vlan_id [prio priority [dei dei]]

Configure the given port to send LLDP frames over a specified VLAN. With VLAN Identifier (VID) as vlan_id, Priority Code Point (PCP) as priority, and Drop Eligible Indicator (DEI) as dei. lldpd accepts LLDP frames on all VLANs.

configure [ports ethX [,...]] lldp custom-tlv [add | replace] oui oui subtype subtype [oui-info content]

Emit a custom TLV for OUI oui, with subtype subtype and optionally with the bytes specified in content. Both oui and content should be a comma-separated list of bytes in hex format. oui must be exactly 3-byte long. If add is specified then the TLV will be added. This is the default action. If replace is specified then all TLVs with the same oui and subtype will be replaced.

unconfigure [ports ethX [,...]] lldp custom-tlv [oui oui] [subtype subtype]

When no oui is specified, remove all previously configured custom TLV. When OUI oui and subtype subtype is specified, remove specific instances of custom TLV.

configure med fast-start enable | tx-interval interval

Configure LLDP-MED fast start mechanism. When a new LLDP-MED-enabled neighbor is detected, fast start allows lldpd to shorten the interval between two LLDPDU. enable should enable LLDP-MED fast start while tx-interval specifies the interval between two LLDPDU in seconds. The default interval is 1 second. Once 4 LLDPDU have been sent, the fast start mechanism is disabled until a new neighbor is detected.

unconfigure med fast-start

Disable LLDP-MED fast start mechanism.

configure [ports ethX [,...]] med location coordinate latitude latitude longitude longitude altitude altitude unit datum datum

Advertise a coordinate based location on the given ports (or on all ports if no port is specified). The format of latitude is a decimal floating point number followed either by N or S. The format of longitude is a decimal floating point number followed either by E or W. altitude is a decimal floating point number followed either by m when expressed in meters or f when expressed in floors. A space is expected between the floating point number and the unit. datum is one of those values:

- WGS84

- NAD83

- NAD83/MLLW

A valid use of this command is:

configure ports eth0 med location coordinate latitude 48.85667N longitude 2.2014E altitude 117.47 m datum WGS84

configure [ports ethX [,...]] med location address country country [type value [...]]

Advertise a civic address on the given ports (or on all ports if no port is specified). country is the two-letter code representing the country. The remaining arguments should be paired to form the address. The first member of each pair indicates the type of the second member which is a free-form text. Here is the list of valid types:

- language

- country-subdivision

- county

- city

- city-division

- block

- street

- direction

- trailing-street-suffix

- street-suffix

- number

- number-suffix

- landmark

- additional

- name

- zip

- building

- unit

- floor

- room

- place-type

- script

A valid use of this command is:

configure ports eth1 med location address country US street "Commercial Road" city "Roseville"

configure [ports ethX [,...]] med location elin number

Advertise the availability of an ELIN number. This is used for setting up emergency call. If the provided number is too small, it will be padded with 0. Here is an example of use: configure ports eth2 med location elin 911

configure [ports ethX [,...]] med policy application application [unknown] [tagged] [vlan vlan] [priority priority] [dscp dscp]

Advertise a specific network policy for the given ports (or for all ports if no port was provided). Only the application type is mandatory. application should be one of the following values:

- voice

- voice-signaling

- guest-voice

- guest-voice-signaling

- softphone-voice

- video-conferencing

- streaming-video

- video-signaling

The unknown flag tells that the network policy for the specified application type is required by the device but is currently unknown. This is used by Endpoint Devices, not by Network Connectivity Devices. If not specified, the network policy for the given application type is defined.

When a VLAN is specified with vlan tells which 802.1q VLAN ID has to be advertised for the network policy. A valid value is between 1 and 4094. tagged tells the VLAN should be tagged for the specified application type.

priority allows one to specify IEEE 802.1d / IEEE 802.1p Layer 2 Priority, also known as Class of Service (CoS), to be used for the specified application type. This field is usually ignored if no VLAN is specified. The names match 802.1D-2004 standard (table G-2). Some more recent standards may use different labels. Only the numeric values should be relied upon. The accepted labels are:

1

background

0

best-effort

2

excellent-effort

3

critical-applications

4

video

5

voice

6

internetwork-control

7

network-control

dscp represents the DSCP value to be advertised for the given network policy. DiffServ/Differentiated Services Code Point (DSCP) value as defined in IETF RFC 2474 for the specified application type. Value: 0 (default per RFC 2475) through 63. Note: The class selector DSCP values are backwards compatible for devices that only support the old IP precedence Type of Service (ToS) format. (See the RFCs for what these values mean)

A valid use of this command is:

configure med policy application voice vlan 500 priority voice dscp 46

configure inventory hardware-revision value

Override hardware-revision with the provided value. By default, the hardware-revision is fetched from /sys/class/dmi

unconfigure inventory hardware-revision

Do not override hardware-revision and restore the use of the /sys/class/dmi value.

configure inventory software-revision value

Override software-revision with the provided value. By default, the software-revision is fetched from uname

unconfigure inventory software-revision

Do not override software-revision and restore the use of the uname value.

configure inventory firmware-revision value

Override firmware-revision with the provided value. By default, the firmware-revision is fetched from /sys/class/dmi

unconfigure inventory firmware-revision

Do not override firmware-revision and restore the use of the /sys/class/dmi value.

configure inventory serial-number value

Override serial-number with the provided value. By default, the serial-number is fetched from /sys/class/dmi

unconfigure inventory serial-number

Do not override serial-number and restore the use of the /sys/class/dmi value.

configure inventory manufacturer value

Override manufacturer with the provided value. By default, the manufacturer is fetched from /sys/class/dmi

unconfigure inventory manufacturer

Do not override manufacturer and restore the use of the /sys/class/dmi value.

configure inventory model value

Override model with the provided value. By default, the model is fetched from /sys/class/dmi

unconfigure inventory model

Do not override model and restore the use of the /sys/class/dmi value.

configure inventory asset value

Override asset with the provided value. By default, the asset is fetched from /sys/class/dmi

unconfigure inventory asset

Do not override asset and restore the use of the /sys/class/dmi value.

configure [ports ethX [,...]] med power pse | pd source source priority priority value value

Advertise the LLDP-MED POE-MDI TLV for the given ports or for all interfaces if no port is provided. One can act as a PD (power consumer) or a PSE (power provider). No check is done on the validity of the parameters while LLDP-MED requires some restrictions:

- PD shall never request more power than physical 802.3af class.

- PD shall never draw more than the maximum power advertised by PSE.

- PSE shall not reduce power allocated to PD when this power is in use.

- PSE may request reduced power using conservation mode

- Being PSE or PD is a global parameter, not a per-port parameter. lldpcli does not enforce this: a port can be set as PD or PSE. LLDP-MED also requires for a PSE to only have one power source (primary or backup). Again, lldpcli does not enforce this. Each port can have its own power source. The same applies for PD and power priority. LLDP-MED MIB does not allow this kind of representation.

Valid types are:

pse

Power Sourcing Entity (power provider)

pd

Power Device (power consumer)

Valid sources are:

unknown

Unknown

primary

For PSE, the power source is the primary power source.

backup

For PSE, the power source is the backup power source or a power conservation mode is asked (the PSE may be running on UPS for example).

pse

For PD, the power source is the PSE.

local

For PD, the power source is a local source.

both

For PD, the power source is both the PSE and a local source.

Valid priorities are:

unknown

Unknown priority

critical

Critical

high

High

low

Low

value should be the total power in milliwatts required by the PD device or available by the PSE device.

Here is an example of use:

configure med power pd source pse priority high value 5000

configure [ports ethX [,...]] dot3 power pse | pd [supported] [enabled] [paircontrol] powerpairs powerpairs [class class] [type type source source priority priority requested requested allocated allocated]

Advertise Dot3 POE-MDI TLV for the given port or for all ports if none was provided. One can act as a PD (power consumer) or a PSE (power provider). This configuration is distinct of the configuration of the transmission of the LLDP-MED POE-MDI TLV but the user should ensure the coherency of those two configurations if they are used together. supported means that MDI power is supported on the given port while enabled means that MDI power is enabled. paircontrol is used to indicate if pair selection can be controlled. Valid values for powerpairs are:

signal

The signal pairs only are in use.

spare

The spare pairs only are in use.

When specified, class is a number between 0 and 4.

The remaining parameters are in conformance with 802.3at and are optional. type should be either 1 or 2, indicating which if the device conforms to 802.3at type 1 or 802.3at type 2. Values of source and priority are the same as for LLDP-MED POE-MDI TLV. requested and allocated are expressed in milliwats.

Here are two valid uses of this command:

configure ports eth3 dot3 power pse supported enabled paircontrol powerpairs spare class class-3

configure dot3 power pd supported enabled powerpairs spare class class-3 type 1 source pse priority low requested 10000 allocated 15000

pause

Pause lldpd operations. lldpd will not send any more frames or receive ones. This can be undone with resume command. This only works interactively as lldpd asks lldpcli to unpause after reading the configuration file.

resume

Resume lldpd operations. lldpd will start to send and receive frames. This command is issued internally after processing configuration but can be used at any time if a manual pause command is issued.

## FILES
/run/lldpd/lldpd.socket

Unix-domain socket used for communication with lldpd(8).

## SEE ALSO
lldpd(8)

## AUTHORS
The lldpcli program was written by Vincent Bernat ⟨bernat@luffy.cx⟩.


lldpd

title: lldpd(8)

summary: LLDP daemon

text:
# lldpd(8)

## NAME
lldpd — LLDP daemon

## SYNOPSIS
lldpd

[-dxcseiklrv] [-D debug] [-p pidfile] [-S description] [-P platform] [-X socket] [-m management] [-u file] [-I interfaces] [-C interfaces] [-M class] [-H hide] [-L lldpcli] [-O configfile]

## DESCRIPTION
lldpd is a daemon able to receive and send LLDP frames. The Link Layer Discovery Protocol is a vendor-neutral Layer 2 protocol that allows a network device to advertise its identity and capabilities on the local network.

lldpd also implements an SNMP subagent using AgentX protocol to interface to a regular SNMP agent like Net-SNMP. To enable this subagent, you need something like that in your snmpd.conf(5):

```
master agentx
```

This daemon implements both reception and sending. It will collect various information to send LLDP frames to all Ethernet interfaces, including management address, speed and VLAN names.

The options are as follows:

-d

Do not daemonize. If this option is specified, lldpd will run in the foreground. When specified one more time, lldpd will not log to syslog but only to stderr. Then, this option can be specified many times to increase verbosity. When specified four times, debug logs will be enabled. They can be filtered with -D flag.

-D debug

This option allows the user to filter out debugging information by specifying allowed tokens. This option can be repeated several times to allow several tokens. This option must be combined with the -d flag to have some effect. Only debugging logs can be filtered. Here is a list of allowed tokens with their description: main

Main daemon.

interfaces

Discovery of local interfaces.

lldp

LLDP PDU encoding/decoding.

edp

EDP PDU encoding/decoding.

cdp

CDP/FDP PDU encoding/decoding.

sonmp

SONMP PDU encoding/decoding.

event

Events management.

libevent

Events management but for logs generated by libevent.

privsep

Privilege separation.

localchassis

Retrieval of information related to the local chassis.

rpc

Client communication.

control

Management of the Unix control socket.

snmp

SNMP subagent.

libsnmp

SNMP subagent but for logs generated by NetSNMP.

decode

Generic PDU decoding.

marshal

Low-level serialization mechanisms.

alloc

Low-level allocation mechanisms.

send

Sending PDU to some interface.

receive

Receiving PDU from some interface.

loop

Main loop.

smartfilter

Smart filtering of different protocols on the same port.

netlink

Netlink subsystem.

-p pidfile

Use the provided PID file to record lldpd PID instead of /run/lldpd.pid.

-k

Disable advertising of kernel release, version and machine. Kernel name (ie: Linux) will still be shared, and Inventory software version will be set to 'Unknown'.

-S description

Override system description with the provided description. The default description is the kernel name, the node name, the kernel version, the build date and the architecture (except if you use the -k flag described above).

-P platform

Override the CDP platform name with the provided value. The default description is the kernel name (Linux).

-x

Enable SNMP subagent. With this option, lldpd will enable an SNMP subagent using AgentX protocol. This allows you to get information about local system and remote systems through SNMP.

-X socket

Enable SNMP subagent using the specified socket. lldpd will enable an SNMP subagent using AgentX protocol for the given socket. This option implies the previous one. The default socket is usually /var/agentx/master. You can specify a socket like tcp:127.0.0.1:705 for example. Since the process that will open this socket is enclosed in a chroot, you need to specify an IP address (not a hostname) when using a TCP or UDP socket.

-c

Enable the support of CDP protocol to deal with Cisco routers that do not speak LLDP. If repeated, CDPv1 packets will be sent even when there is no CDP peer detected. If repeated once again, CDPv2 packets will be sent even when there is no CDP peer detected. If repeated once again (i.e. -cccc), CDPv1 will be disabled and CDPv2 will be enabled. If repeated once again (i.e. -ccccc), CDPv1 will be disabled and CDPv2 will be forced.

-f

Enable the support of FDP protocol to deal with Foundry routers that do not speak LLDP. If repeated, FDP packets will be sent even when there is no FDP peer detected.

-s

Enable the support of SONMP protocol to deal with Nortel routers and switches that do not speak LLDP. If repeated, SONMP packets will be sent even when there is no SONMP peer detected.

-e

Enable the support of EDP protocol to deal with Extreme routers and switches that do not speak LLDP. If repeated, EDP packets will be sent even when there is no EDP peer detected.

-l

Force to send LLDP packets even when there is no LLDP peer detected but there is a peer speaking another protocol detected. By default, LLDP packets are sent when there is a peer speaking LLDP detected or when there is no peer at all. If repeated, LLDP is disabled.

-r

Receive-only mode. With this switch, lldpd will not send any frame. It will only listen to neighbors.

-m management

Specify the management addresses of this system. As for interfaces (described below), this option can use wildcards and inversions. Without this option, the first IPv4 and the first IPv6 are used. If an exact IP address is provided, it is used as a management address without any check. If only negative patterns are provided, only one IPv4 and one IPv6 addresses are chosen. Otherwise, many of them can be selected. If you want to remove IPv6 addresses, you can use !*:*. If an interface name is matched, the first IPv4 address and the first IPv6 address associated to this interface will be chosen.

-u file

Specify the Unix-domain socket used for communication with lldpctl(8).

-I interfaces

Specify which interface to listen and send LLDPDU to. Without this option, lldpd will use all available physical interfaces. This option can use wildcards. Several interfaces can be specified separated by commas. It is also possible to remove an interface by prefixing it with an exclamation mark. It is possible to allow an interface by prefixing it with two exclamation marks. An allowed interface beats a forbidden interface which beats a simple matched interface. For example, with eth*,!eth1,!eth2 lldpd will only use interfaces starting by eth with the exception of eth1 and eth2. While with *,!eth*,!!eth1 lldpd will use all interfaces, except interfaces starting by eth with the exception of eth1. When an exact match is found, it will circumvent some tests. For example, if eth0.12 is specified, it will be accepted even if this is a VLAN interface.

-C interfaces

Specify which interfaces to use for computing chassis ID. Without this option, all interfaces are considered. lldpd will take the first MAC address from all the considered interfaces to compute the chassis ID. The logic of this option is the same as for -I flag: you can exclude interfaces with an exclamation mark and use globbing to specify several interfaces. If all interfaces are removed (with !*), the system name is used as a chassis ID instead.

-M class

Enable emission of LLDP-MED frame. Depending on the selected class, the standard defines which set of TLV should be transmitted. See section 10.2.1. Some devices may be strict about this aspect. The class should be one of the following value: 1

Generic Endpoint (Class I)

2

Media Endpoint (Class II). In this case, the standard requires to define at least one network policy through lldpcli.

3

Communication Device Endpoints (Class III). In this case, the standard requires to define at least one network policy through lldpcli.

4

Network Connectivity Device

-i

Disable LLDP-MED inventory TLV transmission. lldpd will still receive (and publish using SNMP if enabled) those LLDP-MED TLV but will not send them. Use this option if you don't want to transmit sensible information like serial numbers.

-H hide

Filter neighbors. See section FILTERING NEIGHBORS for details.

-L lldpcli

Provide an alternative path to lldpcli for configuration. If empty, does not use lldpcli for configuration.

-O configfile

Override default configuration locations processed by lldpcli at start. If a directory is provided, each file contained in it will be read if ending by .conf. Order is alphabetical.

-v

Show lldpd version. When repeated, show more build information.

## FILTERING NEIGHBORS
In a heterogeneous network, you may see several different hosts on the same port, even if there is only one physically plugged to this port. For example, if you have a Nortel switch running LLDP which is plugged to a Cisco switch running CDP and your host is plugged to the Cisco switch, you will see the Nortel switch as well because LLDP frames are forwarded by the Cisco switch. This may not be what you want. The -H hide parameter will allow you to tell lldpd to discard some frames that it receives and to avoid to send some other frames.

Incoming filtering and outgoing filtering are unrelated. Incoming filtering will hide some remote ports to get you a chance to know exactly what equipment is on the other side of the network cable. Outgoing filtering will avoid to use some protocols to avoid flooding your network with a protocol that is not handled by the nearest equipment. Keep in mind that even without filtering, lldpd will speak protocols for which at least one frame has been received and LLDP otherwise (there are other options to change this behaviour, for example -cc, -ss, -ee, -ll and -ff ).

When enabling incoming filtering, lldpd will try to select one protocol and filter out neighbors using other protocols. To select this protocol, the rule is to take the less used protocol. If on one port, you get 12 CDP neighbors and 1 LLDP neighbor, this mean that the remote switch speaks LLDP and does not filter CDP. Therefore, we select LLDP. When enabling outgoing filtering, lldpd will also try to select one protocol and only speaks this protocol. The filtering is done per port. Each port may select a different protocol.

There are two additional criteria when enabling filtering: allowing one or several protocols to be selected (in case of a tie) and allowing one or several neighbors to be selected. Even when allowing several protocols, the rule of selecting the protocols with the less neighbors still apply. If lldpd selects LLDP and CDP, this means they have the same number of neighbors. The selection of the neighbor is random. Incoming filtering will select a set of neighbors to be displayed while outgoing filtering will use the selected set of neighbors to decide which protocols to use: if a selected neighbor speaks LLDP and another one CDP, lldpd will speak both CDP and LLDP on this port.

There are some corner cases. A typical example is a switch speaking two protocols (CDP and LLDP for example). You want to get the information from the best protocol but you want to speak both protocols because some tools use the CDP table and some other the LLDP table.

The table below summarize all accepted values for the -H hide parameter. The default value is 15 which corresponds to the corner case described above. The filter column means that filtering is enabled. The 1proto column tells that only one protocol will be kept. The 1neigh column tells that only one neighbor will be kept.

incoming

outgoing

filter

1proto

1neigh

filter

1proto

1neigh

0

1

x

x

x

x

2

x

x

3

x

x

4

x

x

5

x

6

x

7

x

x

x

x

x

8

x

x

x

9

x

x

x

x

10

x

x

11

x

x

12

x

x

x

x

13

x

x

x

14

x

x

x

x

15

x

x

x

16

x

x

x

x

x

17

x

x

x

x

18

x

x

x

19

x

x

x

## FILES
/run/lldpd/lldpd.socket

Unix-domain socket used for communication with lldpctl(8).

/etc/lldpd.conf

Configuration file for lldpd. Commands in this files are executed by lldpcli(8) at start.

/etc/lldpd.d

Directory containing configuration files whose commands are executed by lldpcli(8) at start.

## SEE ALSO
lldpctl(8), lldpcli(8), snmpd(8)

## HISTORY
The lldpd program is inspired from a preliminary work of Reyk Floeter.

## AUTHORS
The lldpd program was written by Pierre-Yves Ritschard ⟨pyr@openbsd.org⟩, and Vincent Bernat ⟨bernat@luffy.cx⟩.


lltdscan

package: lltdscan

title: lltdscan(8)

text:
# lltdscan(8)

## NAME
lltdscan - scan for LLTD-enabled hosts on a network interface.

## SYNOPSIS
lltdscan [-i iface] [-t timeout] [-u] [-v] [-v] [aa:bb:cc:dd:ee:ff]

## DESCRIPTION
The lltdscan utility sends broadcast LLTD request on specified (or default) interface. And then listens for timeout milliseconds for responses.

Add one or two -v options to increase verbosity.

Add -u option to show machine names in UTF-8.

Also you can specify exactly one MAC address as last argument - and lltdscan will exit as soon as it receives first reply from specified host.

## LLTD PROTOCOL
LLTD stands for "Link Layer Topology Discovery".

Protocol specs are available from Microsoft at http://www.microsoft.com/whdc/connect/Rally/LLTD-spec.mspx

## SEE ALSO
ping(8), arp(8), arping(8)

## AVAILABILITY
Check for latest versions at http://github.com/zed-0xff/lltdscan

And feel free to visit my personal technical blog at http://zed.0xff.me/ for more fun & useful tools and patches :)

## AUTHOR
Andrey Zaikin <zed.0xff@gmail.com>.


sensors-detect

title: sensors-detect(8)

summary: detect hardware monitoring chips

text:
# sensors-detect(8)

## NAME
sensors-detect - detect hardware monitoring chips

## SYNOPSIS
sensors-detect [ --auto ]

## DESCRIPTION
sensors-detect is an interactive program that will walk you through the process of scanning your system for various hardware monitoring chips, or sensors, supported by libsensors(3), or more generally by the lm_sensors tool suite.

sensors-detect will look for the following devices, in order:

- Sensors embedded in CPUs, south bridges and memory controllers.

- Sensors embedded in Super I/O chips.

- Hardware monitoring chips accessed through ISA I/O ports.

- Hardware monitoring chips reachable over the SMBus or more generally any I2C bus on your system.

As the last two detection steps can cause trouble on some systems, they are normally not attempted if the second detection step led to the discovery of a Super I/O chip with complete hardware monitoring features. However, the user is always free to ask for all detection steps if so is his/her wish. This can be useful if a given system has more than one hardware monitoring chip. Some vendors are known to do this, most notably Asus and Tyan.

## OPTIONS
--auto

Run in automatic, non-interactive mode. Assume default answers to all questions. Note that this isn't necessarily safe as the internal logic may lead to potentially dangerous probes being attempted. See the WARNING section below.

## WARNING
sensors-detect needs to access the hardware for most of the chip detections. By definition, it doesn't know which chips are there before it manages to identify them. This means that it can access chips in a way these chips do not like, causing problems ranging from SMBus lockup to permanent hardware damage (a rare case, thankfully.)

The authors made their best to make the detection as safe as possible, and it turns out to work just fine in most cases, however it is impossible to guarantee that sensors-detect will not lock or kill a specific system. So, as a rule of thumb, you should not run sensors-detect on production servers, and you should not run sensors-detect if can't afford replacing a random part of your system. Also, it is recommended to not force a detection step which would have been skipped by default, unless you know what you are doing.

## SEE ALSO
sensors(1), libsensors(3)

## AUTHOR
Frodo Looijaard and Jean Delvare