iwdt

title: iwdt(8)

text:
# iwdt(8)

## NAME
ipmiutil_wdt- display and set WatchDog Timer parameters

## SYNOPSIS
ipmiutil wdt [-acdelrtx -N node -P/-R pswd -U user -EFJTVY]

## DESCRIPTION
ipmiutil wdt is a program that uses IPMI commands to display and set WatchDog Timer parameters.

This utility can use either any available IPMI driver, or direct user-space IOs, or the IPMI LAN interface if -N.

This utility is an example of how to access the IPMI watchdog parameters directly, which allows changing the timer configuration.

There is an init script provided with ipmiutil to automate the task of managing the watchdog timer in user-space.

\# chkconfig --add ipmiutil_wdt (skip this if no chkconfig)

\# /etc/init.d/ipmiutil_wdt start

This sets the watchdog timer to reset the system if the wdt is not restarted within 90 seconds. It creates an /etc/cron.d/wdt file to restart wdt every 60 seconds. See also ipmiutil UserGuide section 4.4 for more information.

## OPTIONS
Command line options are described below.

-a N

Set watchdog event Action to N. Values: 0 = No action, 1 = Hard Reset(default), 2 = Power down, 3 = Power cycle.

-c

Show watchdog output in a canonical format, with a default delimiter of '|'.

-d

Disables the watchdog timer.

-e

Enables the watchdog timer. The timer is not actually started, however, until the timer is reset. The pre-timeout action is not enabled.

-l

Set the watchdog dontLog bit to not log watchdog events in the SEL.

-p N

Set watchdog Pretimeout event action to N. Values: 0 = No action(default), 1 = SMI, 2 = NMI, 3 = Messaging Interrupt. If this is set to an action other than 0, the pretimeout will also be set to 90% of the timeout. However, if the timeout is less than 20 seconds, the pretimeout will not be enabled.

-q S

Set watchdog pretimeout value to S seconds, rather than 90% of the timeout as in -p. The pretimeout value must be >= 5 and at least 5 seconds less than the timeout value.

-r

Resets the watchdog timer. This should be done every N seconds if the timer is running to prevent the watchdog action (usually a system reset) from occurring.

-tN

Set the watchdog Timeout to N seconds. The default is 120 seconds (2 minutes).

-x

Causes extra debug messages to be displayed.

-N nodename

Nodename or IP address of the remote target system. If a nodename is specified, IPMI LAN interface is used. Otherwise the local system management interface is used.

-P/-R rmt_pswd

Remote password for the nodename given. The default is a null password.

-U rmt_user

Remote username for the nodename given. The default is a null username.

-E

Use the remote password from Environment variable IPMI_PASSWORD.

-F drv_t

Force the driver type to one of the followng: imb, va, open, gnu, landesk, lan, lan2, lan2i, kcs, smb. Note that lan2i means lan2 with intelplus. The default is to detect any available driver type and use it.

-J

Use the specified LanPlus cipher suite (0 thru 17): 0=none/none/none, 1=sha1/none/none, 2=sha1/sha1/none, 3=sha1/sha1/cbc128, 4=sha1/sha1/xrc4_128, 5=sha1/sha1/xrc4_40, 6=md5/none/none, ... 14=md5/md5/xrc4_40. Default is 3.

-T

Use a specified IPMI LAN Authentication Type: 0=None, 1=MD2, 2=MD5, 4=Straight Password, 5=OEM.

-V

Use a specified IPMI LAN privilege level. 1=Callback level, 2=User level, 3=Operator level, 4=Administrator level (default), 5=OEM level.

-Y

Yes, do prompt the user for the IPMI LAN remote password. Alternatives for the password are -E or -P.

## SEE ALSO
ialarms(8) iconfig(8) icmd(8) idiscover(8) ievents(8) ifirewall(8) ifru(8) ifruset(8) ifwum(8) igetevent(8) ihealth(8) ihpm(8) ilan(8) ipicmg(8) ireset(8) isel(8) isensor(8) iserial(8) isol(8) isunoem(8) iwdt(8) ipmiutil(8) ipmi_port(8)

## WARNINGS
See http://ipmiutil.sourceforge.net/ for the latest version of ipmiutil and any bug fix list.

## COPYRIGHT
Copyright (C) 2009 Kontron America, Inc.

See the file COPYING in the distribution for more details regarding redistribution.

This utility is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY.

## AUTHOR
Andy Cress <arcress at users.sourceforge.net>


ipp-usb

package: ipp-usb

title: ipp-usb(8)

summary: Daemon for IPP over USB printer support

text:
# ipp-usb(8)

## NAME
ipp-usb - Daemon for IPP over USB printer support

## DESCRIPTION
ipp-usb daemon enables driver-less printing and scanning on USB-only AirPrint-compatible printers and MFPs.

It works by connecting to the device by USB using IPP-over-USB protocol, and exposing the device to the network, including DNS-SD (ZeroConf) advertising.

IPP printing, eSCL scanning and web console are fully supported.

## SYNOPSIS

### Usage:
ipp-usb mode [options]

### Modes are:
standalone

run forever, automatically discover IPP-over-USB devices and serve them all

udev

like standalone, but exit when last IPP-over-USB device is disconnected

debug

logs duplicated on console, -bg option is ignored

check

check configuration and exit. It also prints a list of all connected devices

status

print status of the running ipp-usb daemon, including information of all connected devices

### Options are

- -bg

run in background (ignored in debug mode)

- -path-conf-files-srch dir1[:dir2...]

List of directories where configuration files (ipp-usb.conf) are searched (/etc/ipp-usb)

- -path-log-dir dir

Path to the directory where log files (main.log and per-device DEVICE.log) are written (/var/log/ipp-usb)

- -path-lock-file file

Path to the program's lock file (/var/ipp-usb/lock/ipp-usb.lock)

- -path-dev-state-dir dir

Path to the directory where per-device state files are written (/var/ipp-usb/dev)

- -path-ctrl-sock file

Path to the program's control socket (/var/ipp-usb/ctrl)

- -path-quirks-files-srch dir1[:dir2...]

List of directories where quirks files (*.conf) is searched (/etc/ipp-usb/quirks:/usr/share/ipp-usb/quirks)

## NETWORKING
Essentially, ipp-usb makes printer or scanner accessible from the network, converting network-side HTTP operations to the USB operations.

By default, ipp-usb exposes device only to the loopback interface, using the localhost address (both 127.0.0.1 and ::1, for IPv4 and IPv6, respectively). TCP ports are allocated automatically, and allocation is persisted in the association with the particular device, so the next time the device is plugged on, it will get the same port. The default port range for TCP ports allocation is 60000-65535.

This default behavior can be changed, using configuration file. See CONFIGURATION section below for details.

If you decide to publish your device to the real network, the following things should be taken into consideration:

1.

Your private device will become public and it will become accessible by other computers from the network

2.

Firewall rules needs to be updated appropriately. The ipp-usb daemon will not do it automatically by itself

3.

IPP over USB specification explicitly require that the Host field in the HTTP request is set to localhost or localhost:port. If device is accessed from the real network, Host header will reflect the real network address. Most of devices allow it, but some are more restrictive and will not work in this configuration.

## DNS-SD (AVAHI INTEGRATION)
IPP over USB is intended to be used with the automatic device discovery, and for this purpose ipp-usb advertises all devices it handles, using DNS-SD protocol. On Linux, DNS-SD is handled with a help of Avahi daemon.

DNS-SD advertising can be disabled via configuration file. Also, if Avahi is not installed or not running, ipp-usb will still work correctly, although DNS-SD advertising will not work.

For every device the following services will be advertised:

Instance

Type

Subtypes

Device name

_ipp._tcp

_universal._sub._ipp._tcp

Device name

_printer._tcp

Device name

_uscan._tcp

Device name

_http._tcp

BBPP

_ipp-usb._tcp

Notes:

- Device name is the name under which device appears in the list of available devices, for example, in the printing dialog (it is DNS-SD device name, in another words), and for most of devices will match the device's model name. It is appended with the " (USB)" suffix, so if device is connected via network and via USB simultaneously, these two connections can be easily distinguished. If there are two devices with the same name connected simultaneously, the suffix becomes " (USB NNN)", with NNN number unique for each device, for disambiguation. In another words, the single "Kyocera ECOSYS M2040dn" device will be listed as "Kyocera ECOSYS M2040dn (USB)", and two such a devices will be listed as "Kyocera ECOSYS M2040dn (USB 1)" and "Kyocera ECOSYS M2040dn (USB 2)"

- _ipp._tcp and _printer._tcp are only advertises for printer devices and MFPs

- _uscan._tcp is only advertised for scanner devices and MFPs

- for the _ipp._tcp service, the _universal._sub._ipp._tcp subtype is also advertised for iOS compatibility

- _printer._tcp is advertised with TCP port set to 0. Other services are advertised with the actual port number

- _http._tcp is device web-console. It is always advertises in assumption it is always exist

- BBPP, used for the _ipp-usb._tcp service, is the USB bus (BB) and port (PP) numbers in hex. The purpose of this advertising is to help CUPS and other possible "clients" to guess which devices are handled by the ipp-usb service, to avoid possible conflicts with the legacy USB drivers.

## Matching DNS-SD announcements against local USB bus
Client software may need to match local devices exposed by ipp-usb with those found on the local USB bus. This can be useful, for example, to avoid offering USB devices in the print or scan dialog that cannot be used because they are already in use by ipp-usb.

As a rough guideline, clients might consider USB devices that offer interfaces with Class=7, SubClass=1, and Protocol=4 as belonging to ipp-usb. However, this is not a precise method. Some devices may not properly implement the IPP over USB protocol and could be blacklisted in the ipp-usb configuration for this reason. Additionally, some devices may be automatically recognized by ipp-usb as incompatible and thus skipped. It's also possible that ipp-usb is disabled on the system entirely.

A more reliable approach is to directly query the running ipp-usb instance to determine which devices it actually handles.

To facilitate the matching of devices that ipp-usb manages and announces via DNS-SD against local devices found on the USB bus, ipp-usb adds two TXT records to each _ipp._tcp, _printer._tcp, and _uscan._tcp services it announces:

- usb_SER=VCF9192281 - USB serial number for the device

- usb_HWID=0482&069d - USB vendor and hardware ID for the device in hex

Please note that when matching devices discovered via DNS-SD with USB devices, it is important to only consider DNS-SD advertisements from IP addresses that are either loopback addresses (127.0.0.1 or ::1) or belong to a local interface.

## CONFIGURATION
ipp-usb searched for its configuration file in two places:

1.

/etc/ipp-usb/ipp-usb.conf

2.

ipp-usb.conf in the directory where executable file is located

Configuration file syntax is very similar to .INI files syntax. It consist of named sections, and each section contains a set of named variables. Comments are started from # or ; characters and continues until end of line:

```
# This is a comment
[section 1]
variable 1 = value 1  ; and another comment
variable 2 = value 2
```

### Network parameters
Network parameters are all in the [network] section:

```
[network]

  # TCP ports for HTTP will be automatically allocated in the

  # following range

  http-min-port = 60000

  http-max-port = 65535

  # Enable or disable DNS-SD advertisement

  dns-sd = enable      # enable | disable

  # Network interface to use. Set to `all` if you want to expose you

  # printer to the local network. This way you can share your printer

  # with other computers in the network, as well as with iOS and

  # Android devices.

  interface = loopback # all | loopback

  # Enable or disable IPv6

  ipv6 = enable        # enable | disable
```

### Authentication
By default, ipp-usb exposes locally connected USB printer to all users of the system.

Though this is reasonable behavior in most cases, when computer and printer are both in personal use, for bigger installation this approach can be too simple and primitive.

ipp-usb provides a mechanism, which allows to control local clients access based on UID the client program runs under.

Please note, this mechanism will not work for remote connections (disabled by default but supported). Authentication of remote users requires some different mechanism, which is under consideration but is not yet implemented.

Note also, this mechanism may or may not work in containerized installation (i.e., snap, flatpak and similar). The container namespace may be isolated from the system and/or user's namespaces, so even for local clients the UID as seen by the ipp-usb may be different from the system-wide UID.

Authentication parameters are all in the [auth uid] section:

```
# Local user authentication by UID/GID
[auth uid]

  # Syntax:

  #     operations = users

  #

  # Operations are comma-separated list of following operations:

  #     all    - all operations

  #     config - configuration web-console

  #     fax    - faxing

  #     print  - printing

  #     scan   - scanning

  #

  # Users have the following suntax:

  #     user   - user name

  #     @group - all users that belongs to the group

  #

  # Users and groups may be specified either by names or by

  # numbers. "*" means any

  #

  # Note, if user/group is not known in the context of request

  # (for example, in the case of non-local network connection),

  # "*" used for matching, which will only match wildcard

  # rules.

  #

  # User/group names are resolved at the moment of request

  # processing (and cached for a couple of seconds), so running

  # daemon will see changes to the /etc/passwd and /etc/group

  #

  # Examples:

  #     fax, print = lp, @lp   # Allow CUPS to do its work

  #     scan       = *         # Allow any user to scan

  #     config     = @wheel    # Only wheel group members can do that

  all = *
```

### Logging configuration
Logging parameters are all in the [logging] section:

```
[logging]

  # device-log  - what logs are generated per device

  # main-log    - what common logs are generated

  # console-log - what of generated logs goes to console

  #

  # parameter contains a comma-separated list of

  # the following keywords:

  #   error     - error messages

  #   info      - informative messages

  #   debug     - debug messages

  #   trace-ipp, trace-escl, trace-http - very detailed

  #               per-protocol traces

  #   trace-usb - hex dump of all USB traffic

  #   all       - all logs

  #   trace-all - alias to all

  #

  # Note, trace-* implies debug, debug implies info, info implies

  # error

  device-log    = all

  main-log      = debug

  console-log   = debug

  # Log rotation parameters:

  #   log-file-size    - max log file before rotation. Use suffix

  #                      M for megabytes or K for kilobytes

  #   log-backup-files - how many backup files to preserve during

  #                      rotation

  #

  max-file-size    = 256K

  max-backup-files = 5

  # Enable or disable ANSI colors on console

  console-color = enable # enable | disable

  # ipp-usb queries IPP printer attributes at the initialization time

  # for its own purposes and writes received attributes to the log.

  # By default, only necessary attributes are requested from device.

  #

  # If this parameter is set to true, all printer attributes will

  # be requested. Normally, it only affects the logging. However,

  # some enterprise-level HP printers returns such huge amount of

  # data and do it so slowly, so it can cause initialization timeout.

  # This is why this feature is not enabled by default

  get-all-printer-attrs = false # false | true
```

### Quirks
Some devices, due to their firmware bugs, require special handling, called device-specific quirks. ipp-usb loads quirks from the /usr/share/ipp-usb/quirks/*.conf files and from the /etc/ipp-usb/quirks/*.conf files. The /etc/ipp-usb/quirks directory is for system quirks overrides or admin changes. These files have .INI-file syntax with the content that looks like this:

```
# Various HP printers - match by bame
[HP LaserJet MFP M28-M31]

  http-connection = keep-alive
[HP OfficeJet Pro 8730]

  http-connection = close
[HP Inc. HP Laser MFP 135a]

  blacklist = true
# Xerox B210. Match by HWID, as model name is not reliable
# before reset.
[0924:42ea]

  mfg        = Xerox

  model      = B210

  init-reset = hard
# Default configuration
[*]

  http-connection = ""
```

Section name defines the device (or group of devices) quirks are applied to, and section body contains the applied quirks.

For each discovered device, quirks are searched by the USB HWID (Vendor:Product, in hex) and by the model name.

Section names may contain wildcards:

```
`[HP OfficeJet Pro 8730]` - match the "HP OfficeJet Pro 8730" device
`[HP OfficeJet *]`        - match all models with name started with

                            the "HP OfficeJet" prefix.
`[0924:42ea]`             - match the device with the USB HWID 0924:42ea
`[0924:*]`                - match all devices with the Vendor ID equal

                            to 0924 (this ID owned by Xerox).
```

Model names may contain glob-style wildcards: * that matches any sequence of characters and ? , that matches any single character. To match one of these characters (* and ?) literally, use backslash as escape.

HWID sections may only contain a * wildcard in a place of the Product ID.

Note, the simplest way to guess the exact model name for the particular device is to use ipp-usb check command, which prints a list of all connected devices. To obtain list if USB HWIDs, use the lsusb command.

If some parameter found in multiple matching sections, ipp-usb follows the principle: most specific match wins.

To be more precise, the following prioritization algorithm is used:

- The exact HWID (non-wildcard, i.e., [0924:42ea]) considered the most specific.

- The next candidates are model name match with at least one matched non-wildcard character. If there are multiple model name matches, amount of non-wildcard matched characters is counted, and the longer match wins.

- The next candidate is the wildcard HWID match (i.e., [0924:*]).

- And the least specific is the all-wildcard model name match (i.e., [*]).

In a case of multiple matches even after applying this algorithm, the first definition wins. Files are loaded in alphabetical order, sections read sequentially

In another words, non-wildcard HWID match considered most specific, model name matches are ranked by the amount of non-wildcard matched characters, and wildcard HWID match considered less specific as any of above, because it can only be applied to all devices of the particular vendor, and the least specific is the all-wildcard model name match, used to specify defaults.

Please notice that HWID-matched quirks are loaded early and may cause some actions to be performed before the model-name matched quirks are loaded and applied, and the model-name matched quirks cannot withdraw these early performed actions. It happens because some printers cannot reliably report their model name before appropriate actions is applied. It is related to the following quirks:

- blacklist = true. Model-name quirks will not be loaded if device is blacklisted by HWID.

- init-reset = hard. Reset will be issued, even if model-name matched quirk has a different setting.

- mfg = name and model = name. These parameters are only available for the HWID quirks and override identification information, provided by the device, when searching quirks by the model name.

The following parameters are defined:

- blacklist = true | false

If true, the matching device is ignored by the ipp-usb

- buggy-ipp-responses = reject | allow | sanitize

Some devices send buggy (malformed) IPP responses that violate IPP specification. ipp-usb may reject these responses (so ipp-usb initialization will fail), allow them (ipp-usb initialization will succeed, but CUPS needs to accept them as well) or sanitize them (fix IPP specs violations).

- disable-fax = true | false

If true, the matching device's fax capability is ignored.

- disable-scan = true | false

If true, the matching device's scan capability is ignored.

- http-XXX = YYY

Set XXX header of the HTTP requests forwarded to device to YYY. If YYY is empty string, XXX header is removed.

- ignore-ipp-status = true | false

If true, IPP status of IPP requests sent by the ipp-usb by itself will be ignored. This quirk is useful, when device correctly handles IPP request but returned status is not reliable. Affects only ipp-usb initialization.

- init-delay = DELAY

Delay, between device is opened and, optionally, reset, and the first request is sent to device.

- init-retry-partial = true | false

Retry the initialization in case only part of the device's functions have been initialized, instead of continuing to operate with incomplete functionality.

It can be useful if the device takes a long time to fully initialize. During this period, some components may respond normally while others are still initializing. For example, the device may quickly report its scanning capabilities shortly after startup, while its printing functionality may take several minutes to become operational.

Some enterprise-level HP printers are known to have this problem.

- init-reset = none | soft | hard

How to reset device during initialization. Default is none

- init-timeout = DELAY

Timeout for HTTP requests send by the ipp-usb during initialization.

- mfg = name

Overrides the USB manufacturer (vendor) name. This quirk can only be used in the HWID section and affects searching quirks by model name.

- model = name

Overrides the USB model (product) name. This quirk can only be used in the HWID section and affects searching quirks by model name.

- request-delay = DELAY

Delay between subsequent HTTP requests, sent to device (this is not the same as usb-send-delay, which inserts delays between each subsequent USB send-to-device requests).

- usb-max-interfaces = N

Don't use more that N USB interfaces, even if more is available.

- usb-send-delay = DELAY

Delay between low-level USB send-to-device requests (this is not the same as request-delay, which inserts delays between the whole HTTP-level requests).

- usb-send-delay-threshold = N

usb-send-delay only applied if USB send-to-device request size exceeds this threshold.

- zlp-recv-hack = true | false

Some enterprise-level HP devices, during the initialization phase (which can last several minutes), may respond with an HTTP 503 status or similar, which is expected. However, the response body may be truncated (typically, the terminating '\n' is lost). In such cases, ipp-usb will wait indefinitely for a response to maintain synchronization with the device.

At the same time, these devices send a zero-length UDP packet at the end of the truncated output. If the zlp-recv-hack quirk is enabled, when ipp-usb receives a zero-length packet from the USB followed by a receive timeout, it interprets this combination of events as a valid termination of the response body. It works only at the initialization time and doesn't affect futher operations.

•

zlp-send = true | false

Terminate outgoing transfers that a multiple of the endpoint's packet size win an extra zero length packet.

The DELAY parameter can be specified either as an unsigned integer (in milliseconds) or as a sequence of decimal numbers with an optional fraction and a unit suffix, such as "300ms," "0.5s," or "2m30s." Valid time units are "ns," "us" (or "µs"), "ms" "s" "m" and "h"

If you found out about your device that it needs a quirk to work properly or it does not work with ipp-usb at all, although it provides IPP-over-USB interface, please report the issue at https://github.com/OpenPrinting/ipp-usb. It will let us to update our collection of quirks, so helping other owners of such a device.

## FILES

- /etc/ipp-usb/ipp-usb.conf: the daemon configuration file

- /var/log/ipp-usb/main.log: the main log file

- /var/log/ipp-usb/<DEVICE>.log: per-device log files

- /var/ipp-usb/dev/<DEVICE>.state: device state (HTTP port allocation, DNS-SD name)

- /var/ipp-usb/lock/ipp-usb.lock: lock file, that helps to prevent multiple copies of daemon to run simultaneously

- /var/ipp-usb/ctrl: ipp-usb control socket. Currently only used to obtain the per-device status (printed by ipp-usb status), but its functionality may be extended in a future

- /usr/share/ipp-usb/quirks/*.conf: device-specific quirks (see above)

- /etc/ipp-usb/quirks/*.conf: device-specific quirks defined by sysadmin (see above)

## COPYRIGHT
Copyright (c) by Alexander Pevzner (pzz@apevzner.com, pzz@pzz.msk.ru)

All rights reserved.

This program is licensed under 2-Clause BSD license. See LICENSE file for details.

## SEE ALSO
cups(1)

branch: sisyphus


arpd

title: arpd(8)

summary: userspace arp daemon.

text:
# arpd(8)

## NAME
arpd - userspace arp daemon.

## SYNOPSIS
Usage: arpd [ -lkh? ] [ -a N ] [ -b dbase ] [ -B number ] [ -f file ] [-p interval ] [ -n time ] [ -R rate ] [ <INTERFACES> ]

## DESCRIPTION
The arpd daemon collects gratuitous ARP information, saving it on local disk and feeding it to the kernel on demand to avoid redundant broadcasting due to limited size of the kernel ARP cache.

## OPTIONS
-h -?

Print help

-l

Dump the arpd database to stdout and exit. The output consists of three columns: the interface index, the IP address of the interface, and the MAC address of the interface. Negative entries for dead hosts are also shown, in this case the MAC address is replaced by the word FAILED followed by a colon and the most recent time when the fact that the host is dead was proven.

-f <FILE>

Read and load an arpd database from FILE in a text format similar to that dumped by option -l. Exit after load, possibly listing resulting database, if option -l is also given. If FILE is -, stdin is read to get the ARP table.

-b <DATABASE>

the location of the database file. The default location is /var/lib/arpd/arpd.db

-a <NUMBER>

With this option, arpd not only passively listens for ARP packets on the interface, but also sends broadcast queries itself. NUMBER is the number of such queries to make before a destination is considered dead. When arpd is started as kernel helper (i.e. with app_solicit enabled in sysctl or even with option -k) without this option and still did not learn enough information, you can observe 1 second gaps in service. Not fatal, but not good.

-k

Suppress sending broadcast queries by the kernel. This option only makes sense together with option -a.

-n <TIME>

Specifies the timeout of the negative cache. When resolution fails, arpd suppresses further attempts to resolve for this period. This option only makes sense together with option '-k'. This timeout should not be too much longer than the boot time of a typical host not supporting gratuitous ARP. Default value is 60 seconds.

-p <TIME>

The time to wait in seconds between polling attempts to the kernel ARP table. TIME may be a floating point number. The default value is 30.

-R <RATE>

Maximal steady rate of broadcasts sent by arpd in packets per second. Default value is 1.

-B <NUMBER>

The number of broadcasts sent by arpd back to back. Default value is 3. Together with the -R option, this option ensures that the number of ARP queries that are broadcast does not exceed B+R*T over any interval of time T.

<INTERFACES> is a list of names of networking interfaces to watch. If no interfaces are given, arpd monitors all the interfaces. In this case arpd does not adjust sysctl parameters, it is assumed that the user does this himself after arpd is started.

## SIGNALS
When arpd receives a SIGINT or SIGTERM signal, it exits gracefully, syncing the database and restoring adjusted sysctl parameters. On a SIGHUP it syncs the database to disk. With SIGUSR1 it sends some statistics to syslog. The effect of any other signals is undefined. In particular, they may corrupt the database and leave the sysctl parameters in an unpredictable state.

## NOTE
In order for arpd to be able to serve as ARP resolver, the kernel must be compiled with the option CONFIG_ARPD and, in the case when interface list in not given on command line, variable app_solicit on interfaces of interest should be in /proc/sys/net/ipv4/neigh/*. If this is not made arpd still collects gratuitous ARP information in its database.

## EXAMPLES
arpd -b /var/tmp/arpd.db

Start arpd to collect gratuitous ARP, but not messing with kernel functionality.

killall arpd ; arpd -l -b /var/tmp/arpd.db

Look at result after some time.

arpd -b /var/tmp/arpd.db -a 1 eth0 eth1

Enable kernel helper, leaving leading role to kernel.

arpd -b /var/tmp/arpd.db -a 3 -k eth0 eth1

Completely replace kernel resolution on interfaces eth0 and eth1. In this case the kernel still does unicast probing to validate entries, but all the broadcast activity is suppressed and made under authority of arpd.

This is the mode in which arpd normally is supposed to work. It is not the default to prevent occasional enabling of too aggressive a mode.


bridge

title: bridge(8)

text:
# bridge(8)

## NAME
bridge - show / manipulate bridge addresses and devices

## SYNOPSIS

bridge [ OPTIONS ] OBJECT { COMMAND | help }

OBJECT := { link | fdb | mdb | vlan | vni | monitor }

OPTIONS := { -V[ersion] | -s[tatistics] | -n[etns] name | -b[atch] filename | -com[pressvlans] | -c[olor] | -p[retty] | -j[son] | -o[neline] }

bridge link set dev DEV [ cost COST ] [ priority PRIO ] [ state STATE ] [ guard { on | off } ] [ hairpin { on | off } ] [ fastleave { on | off } ] [ root_block { on | off } ] [ learning { on | off } ] [ learning_sync { on | off } ] [ flood { on | off } ] [ hwmode { vepa | veb } ] [ bcast_flood { on | off } ] [ mcast_flood { on | off } ] [ mcast_max_groups MAX_GROUPS ] [ mcast_router MULTICAST_ROUTER ] [ mcast_to_unicast { on | off } ] [ neigh_suppress { on | off } ] [ neigh_vlan_suppress { on | off } ] [ vlan_tunnel { on | off } ] [ isolated { on | off } ] [ locked { on | off } ] [ mab { on | off } ] [ backup_port DEVICE ] [ nobackup_port ] [ backup_nhid NHID ] [ self ] [ master ]

bridge link [ show ] [ dev DEV ] [ master DEVICE ]

bridge fdb { add | append | del | replace } LLADDR dev DEV { local | static | dynamic } [ self ] [ master ] [ router ] [ use ] [ extern_learn ] [ sticky ] [ src_vni VNI ] { [ dst IPADDR ] [ vni VNI ] [ port PORT ] [ via DEVICE ] | nhid NHID } [ activity_notify ] [ inactive ] [ norefresh ]

bridge fdb [ [ show ] [ br BRDEV ] [ brport DEV ] [ vlan VID ] [ state STATE ] [ dynamic ] ]

bridge fdb get [ to ] LLADDR [ br BRDEV ] { brport | dev } DEV [ vlan VID ] [ vni VNI ] [ self ] [ master ] [ dynamic ]

bridge fdb flush dev DEV [ brport DEV ] [ vlan VID ] [ src_vni VNI ] [ nhid NHID ] [ vni VNI ] [ port PORT ] [ dst IPADDR ] [ self ] [ master ] [ [no]permanent | [no]static | [no]dynamic ] [ [no]added_by_user ] [ [no]extern_learn ] [ [no]sticky ] [ [no]offloaded ] [ [no]router ]

bridge mdb { add | del | replace } dev DEV port PORT grp GROUP [ src SOURCE ] [ permanent | temp ] [ vid VID ] [ filter_mode { include | exclude } ] [ source_list SOURCE_LIST ] [ proto PROTO ] [ dst IPADDR ] [ dst_port DST_PORT ] [ vni VNI ] [ src_vni SRC_VNI ] [ via DEV ]

bridge mdb show [ dev DEV ]

bridge mdb get dev DEV grp GROUP [ src SOURCE ] [ vid VID ] [ src_vni SRC_VNI ]

bridge mdb flush dev DEV [ port PORT ] [ vid VID ] [ src_vni SRC_VNI ] [ proto PROTO ] [ [no]permanent ] [ dst IPADDR ] [ dst_port DST_PORT ] [ vni VNI ]

bridge mst set dev DEV msti MSTI state STP_STATE

bridge mst [ [ show ] [ dev DEV ] ]

bridge vlan { add | del } dev DEV vid VID [ tunnel_info TUNNEL_ID ] [ pvid ] [ untagged ] [ self ] [ master ]

bridge vlan set dev DEV vid VID [ state STP_STATE ] [ mcast_max_groups MAX_GROUPS ] [ mcast_router MULTICAST_ROUTER ] [ neigh_suppress { on | off } ]

bridge vlan [ show | tunnelshow ] [ dev DEV ]

bridge vlan global set dev DEV vid VID [ mcast_snooping MULTICAST_SNOOPING ] [ mcast_querier MULTICAST_QUERIER ] [ mcast_igmp_version IGMP_VERSION ] [ mcast_mld_version MLD_VERSION ] [ mcast_last_member_count LAST_MEMBER_COUNT ] [ mcast_last_member_interval LAST_MEMBER_INTERVAL ] [ mcast_startup_query_count STARTUP_QUERY_COUNT ] [ mcast_startup_query_interval STARTUP_QUERY_INTERVAL ] [ mcast_membership_interval MEMBERSHIP_INTERVAL ] [ mcast_querier_interval QUERIER_INTERVAL ] [ mcast_query_interval QUERY_INTERVAL ] [ mcast_query_response_interval QUERY_RESPONSE_INTERVAL ] [ msti MSTI ]

bridge vlan global [ show ] [ dev DEV ] [ vid VID ]

bridge vlan show [ dev DEV ]

bridge vni { add | del } dev DEV vni VNI [ { group | remote } IPADDR ]

bridge vni show [ dev DEV ]

bridge monitor [ all | neigh | link | mdb | vlan ]

## OPTIONS
-V, -Version

print the version of the bridge utility and exit.

-s, -stats, -statistics

output more information. If this option is given multiple times, the amount of information increases. As a rule, the information is statistics or some time values.

-d, -details

print detailed information about bridge vlan filter entries or MDB router ports.

-n, -net, -netns <NETNS>

switches bridge to the specified network namespace NETNS. Actually it just simplifies executing of: ip netns exec NETNS bridge [ OPTIONS ] OBJECT { COMMAND | help }

to

bridge -n[etns] NETNS [ OPTIONS ] OBJECT { COMMAND | help }

-b, -batch <FILENAME>

Read commands from provided file or standard input and invoke them. First failure will cause termination of bridge command.

-force

Don't terminate bridge command on errors in batch mode. If there were any errors during execution of the commands, the application return code will be non zero.

-com, -compressvlans

Show compressed VLAN list. It will show continuous VLANs with the range instead of separated VLANs. Default is off.

-c[color][={always|auto|never}

Configure color output. If parameter is omitted or always, color output is enabled regardless of stdout state. If parameter is auto, stdout is checked to be a terminal before enabling color output. If parameter is never, color output is disabled. If specified multiple times, the last one takes precedence. This flag is ignored if -json is also given.

-j, -json

Output results in JavaScript Object Notation (JSON).

-p, -pretty

When combined with -j generate a pretty JSON output.

-o, -oneline

output each record on a single line, replacing line feeds with the '\' character. This is convenient when you want to count records with wc(1) or to grep(1) the output.

## BRIDGE - COMMAND SYNTAX

### OBJECT
link

- Bridge port.

fdb

- Forwarding Database entry.

mdb

- Multicast group database entry.

vlan

- VLAN filter list.

vni

- VNI filter list.

### COMMAND
Specifies the action to perform on the object. The set of possible actions depends on the object type. As a rule, it is possible to add, delete and show (or list ) objects, but some objects do not allow all of these operations or have some additional commands. The help command is available for all objects. It prints out a list of available commands and argument syntax conventions.

If no command is given, some default command is assumed. Usually it is list or, if the objects of this class cannot be listed, help.

## bridge link - bridge port
link objects correspond to the port devices of the bridge.

The corresponding commands set and display port status and bridge specific attributes.

### bridge link set - set bridge specific attributes on a port
dev NAME

interface name of the bridge port

cost COST

the STP path cost of the specified port.

priority PRIO

the STP port priority. The priority value is an unsigned 8-bit quantity (number between 0 and 255). This metric is used in the designated port an droot port selection algorithms.

state STATE

the operation state of the port. Except state 0 (disable STP or BPDU filter feature), this is primarily used by user space STP/RSTP implementation. One may enter port state name (case insensitive), or one of the numbers below. Negative inputs are ignored, and unrecognized names return an error. 0 - port is in STP DISABLED state. Make this port completely inactive for STP. This is also called BPDU filter and could be used to disable STP on an untrusted port, like a leaf virtual devices.

1 - port is in STP LISTENING state. Only valid if STP is enabled on the bridge. In this state the port listens for STP BPDUs and drops all other traffic frames.

2 - port is in STP LEARNING state. Only valid if STP is enabled on the bridge. In this state the port will accept traffic only for the purpose of updating MAC address tables.

3 - port is in STP FORWARDING state. Port is fully active.

4 - port is in STP BLOCKING state. Only valid if STP is enabled on the bridge. This state is used during the STP election process. In this state, port will only process STP BPDUs.

guard on or guard off

Controls whether STP BPDUs will be processed by the bridge port. By default, the flag is turned off allowed BPDU processing. Turning this flag on will disables the bridge port if a STP BPDU packet is received. If running Spanning Tree on bridge, hostile devices on the network may send BPDU on a port and cause network failure. Setting guard on will detect and stop this by disabling the port. The port will be restarted if link is brought down, or removed and reattached. For example if guard is enable on eth0:

ip link set dev eth0 down; ip link set dev eth0 up

hairpin on or hairpin off

Controls whether traffic may be send back out of the port on which it was received. This option is also called reflective relay mode, and is used to support basic VEPA (Virtual Ethernet Port Aggregator) capabilities. By default, this flag is turned off and the bridge will not forward traffic back out of the receiving port.

fastleave on or fastleave off

This flag allows the bridge to immediately stop multicast traffic on a port that receives IGMP Leave message. It is only used with IGMP snooping is enabled on the bridge. By default the flag is off.

root_block on or root_block off

Controls whether a given port is allowed to become root port or not. Only used when STP is enabled on the bridge. By default the flag is off. This feature is also called root port guard. If BPDU is received from a leaf (edge) port, it should not be elected as root port. This could be used if using STP on a bridge and the downstream bridges are not fully trusted; this prevents a hostile guest from rerouting traffic.

learning on or learning off

Controls whether a given port will learn MAC addresses from received traffic or not. If learning if off, the bridge will end up flooding any traffic for which it has no FDB entry. By default this flag is on.

learning_sync on or learning_sync off

Controls whether a given port will sync MAC addresses learned on device port to bridge FDB.

flood on or flood off

Controls whether unicast traffic for which there is no FDB entry will be flooded towards this given port. By default this flag is on.

hwmode

Some network interface cards support HW bridge functionality and they may be configured in different modes. Currently support modes are: vepa - Data sent between HW ports is sent on the wire to the external switch.

veb - bridging happens in hardware.

bcast_flood on or bcast_flood off

Controls flooding of broadcast traffic on the given port. By default this flag is on.

mcast_flood on or mcast_flood off

Controls whether multicast traffic for which there is no MDB entry will be flooded towards this given port. By default this flag is on.

mcast_max_groups MAX_GROUPS

Sets the maximum number of MDB entries that can be registered for a given port. Attempts to register more MDB entries at the port than this limit allows will be rejected, whether they are done through netlink (e.g. the bridge tool), or IGMP or MLD membership reports. Setting a limit to 0 has the effect of disabling the limit. The default value is 0. See also the ip link option mcast_hash_max.

mcast_router MULTICAST_ROUTER

This flag is almost the same as the per-VLAN flag, see below, except its value can only be set in the range 0-2. The default is 1 where the bridge figures out automatically where an IGMP/MLD querier, MRDISC capable device, or PIM router, is located. Setting this flag to 2 is useful in cases where the multicast router does not indicate its presence in any meaningful way (e.g. older versions of SMCRoute, or mrouted), or when there is a need for forwarding both known and unknown IP multicast to a secondary/backup router.

mcast_to_unicast on or mcast_to_unicast off

Controls whether a given port will replicate packets using unicast instead of multicast. By default this flag is off. This is done by copying the packet per host and changing the multicast destination MAC to a unicast one accordingly.

mcast_to_unicast works on top of the multicast snooping feature of the bridge. Which means unicast copies are only delivered to hosts which are interested in it and signalized this via IGMP/MLD reports previously.

This feature is intended for interface types which have a more reliable and/or efficient way to deliver unicast packets than broadcast ones (e.g. WiFi).

However, it should only be enabled on interfaces where no IGMPv2/MLDv1 report suppression takes place. IGMP/MLD report suppression issue is usually overcome by the network daemon (supplicant) enabling AP isolation and by that separating all STAs.

Delivery of STA-to-STA IP multicast is made possible again by enabling and utilizing the bridge hairpin mode, which considers the incoming port as a potential outgoing port, too (see hairpin option). Hairpin mode is performed after multicast snooping, therefore leading to only deliver reports to STAs running a multicast router.

neigh_suppress on or neigh_suppress off

Controls whether neigh discovery (arp and nd) proxy and suppression is enabled on the port. By default this flag is off.

neigh_vlan_suppress on or neigh_vlan_suppress off

Controls whether per-VLAN neigh discovery (arp and nd) proxy and suppression is enabled on the port. When on, the bridge link option neigh_suppress has no effect and the per-VLAN state is set using the bridge vlan option neigh_suppress. By default this flag is off.

vlan_tunnel on or vlan_tunnel off

Controls whether vlan to tunnel mapping is enabled on the port. By default this flag is off.

isolated on or isolated off

Controls whether a given port will be isolated, which means it will be able to communicate with non-isolated ports only. By default this flag is off.

locked on or locked off

Controls whether a port is locked or not. When locked, non-link-local frames received through the port are dropped unless an FDB entry with the MAC source address points to the port. The common use case is IEEE 802.1X where hosts can authenticate themselves by exchanging EAPOL frames with an authenticator. After authentication is complete, the user space control plane can install a matching FDB entry to allow traffic from the host to be forwarded by the bridge. When learning is enabled on a locked port, the no_linklocal_learn bridge option needs to be on to prevent the bridge from learning from received EAPOL frames. By default this flag is off.

mab on or mab off

Controls whether MAC Authentication Bypass (MAB) is enabled on the port or not. MAB can only be enabled on a locked port that has learning enabled. When enabled, FDB entries are learned from received traffic and have the "locked" FDB flag set. The flag can only be set by the kernel and it indicates that the FDB entry cannot be used to authenticate the corresponding host. User space can decide to authenticate the host by replacing the FDB entry and clearing the "locked" FDB flag. Locked FDB entries can roam to unlocked (authorized) ports in which case the "locked" flag is cleared. FDB entries cannot roam to locked ports regardless of MAB being enabled or not. Therefore, locked FDB entries are only created if an FDB entry with the given {MAC, VID} does not already exist. This behavior prevents unauthenticated hosts from disrupting traffic destined to already authenticated hosts. Locked FDB entries act like regular dynamic entries with respect to forwarding and aging. By default this flag is off.

backup_port DEVICE

If the port loses carrier all traffic will be redirected to the configured backup port

nobackup_port

Removes the currently configured backup port

backup_nhid NHID

The FDB nexthop object ID (see ip-nexthop(8)) to attach to packets being redirected to a backup port that has VLAN tunnel mapping enabled (via the vlan_tunnel option). Setting a value of 0 (default) has the effect of not attaching any ID.

self

link setting is configured on specified physical device

master

link setting is configured on the software bridge (default)

-t, -timestamp

display current time when using monitor option.

### bridge link show - list ports configuration for all bridges.
This command displays ports configuration and flags for all bridges by default.

dev DEV

only display the specific bridge port named DEV.

master DEVICE

only display ports of the bridge named DEVICE. This is similar to "ip link show master <bridge_device>" command.

## bridge fdb - forwarding database management
fdb objects contain known Ethernet addresses on a link.

The corresponding commands display fdb entries, add new entries, append entries, and delete old ones.

### bridge fdb add - add a new fdb entry
This command creates a new fdb entry.

LLADDR

the Ethernet MAC address.

dev DEV

the interface to which this address is associated. local - is a local permanent fdb entry, which means that the bridge will not forward frames with this destination MAC address and VLAN ID, but terminate them locally. This flag is default unless "static" or "dynamic" are explicitly specified.

permanent - this is a synonym for "local"

static - is a static (no arp) fdb entry

dynamic - is a dynamic reachable age-able fdb entry

self - the operation is fulfilled directly by the driver for the specified network device. If the network device belongs to a master like a bridge, then the bridge is bypassed and not notified of this operation (and if the device does notify the bridge, it is driver-specific behavior and not mandated by this flag, check the driver for more details). The "bridge fdb add" command can also be used on the bridge device itself, and in this case, the added fdb entries will be locally terminated (not forwarded). In the latter case, the "self" flag is mandatory. The flag is set by default if "master" is not specified.

master - if the specified network device is a port that belongs to a master device such as a bridge, the operation is fulfilled by the master device's driver, which may in turn notify the port driver too of the address. If the specified device is a master itself, such as a bridge, this flag is invalid.

router - the destination address is associated with a router. Valid if the referenced device is a VXLAN type device and has route short circuit enabled.

use - the address is in use. User space can use this option to indicate to the kernel that the fdb entry is in use.

extern_learn - this entry was learned externally. This option can be used to indicate to the kernel that an entry was hardware or user-space controller learnt dynamic entry. Kernel will not age such an entry.

sticky - this entry will not change its port due to learning.

The next command line parameters apply only when the specified device DEV is of type VXLAN.

dst IPADDR

the IP address of the destination VXLAN tunnel endpoint where the Ethernet MAC ADDRESS resides.

src_vni VNI

the src VNI Network Identifier (or VXLAN Segment ID) this entry belongs to. Used only when the vxlan device is in external or collect metadata mode. If omitted the value specified at vxlan device creation will be used.

vni VNI

the VXLAN VNI Network Identifier (or VXLAN Segment ID) to use to connect to the remote VXLAN tunnel endpoint. If omitted the value specified at vxlan device creation will be used.

port PORT

the UDP destination PORT number to use to connect to the remote VXLAN tunnel endpoint. If omitted the default value is used.

via DEVICE

device name of the outgoing interface for the VXLAN device driver to reach the remote VXLAN tunnel endpoint.

nhid NHID

ecmp nexthop group for the VXLAN device driver to reach remote VXLAN tunnel endpoints.

activity_notify

enable activity notifications on an existing or a new FDB entry. This keyword only makes sense for non-dynamic entries as dynamic entries are deleted upon inactivity. An entry is assumed to be active unless the inactive keyword is specified.

inactive

mark an FDB entry as inactive. This keyword only makes sense in conjunction with the activity_notify keyword and usually only when adding a new FDB entry as opposed to replacing an existing one.

norefresh

avoid resetting an FDB entry's activity (i.e., its last updated time). This can be useful, for example, when one wants to enable activity notifications on an existing entry without modifying its last updated time.

### bridge fdb append - append a forwarding database entry
This command adds a new fdb entry with an already known LLADDR. Valid only for multicast link layer addresses. The command adds support for broadcast and multicast Ethernet MAC addresses. The Ethernet MAC address is added multiple times into the forwarding database and the vxlan device driver sends a copy of the data packet to each entry found.

The arguments are the same as with bridge fdb add.

### bridge fdb delete - delete a forwarding database entry
This command removes an existing fdb entry.

The arguments are the same as with bridge fdb add.

### bridge fdb replace - replace a forwarding database entry
If no matching entry is found, a new one will be created instead.

The arguments are the same as with bridge fdb add.

### bridge fdb show - list forwarding entries.
This command displays the current forwarding table.

With the -statistics option, the command becomes verbose. It prints out the last updated and last used time for each entry.

### bridge fdb get - get bridge forwarding entry.
lookup a bridge forwarding table entry.

LLADDR

the Ethernet MAC address.

dev DEV

the interface to which this address is associated.

brport DEV

the bridge port to which this address is associated. same as dev above.

br DEV

the bridge to which this address is associated.

self

- the address is associated with the port drivers fdb. Usually hardware.

master

- the address is associated with master devices fdb. Usually software (default).

### bridge fdb flush - flush bridge forwarding table entries.
flush the matching bridge forwarding table entries. Some options below have a negated form when "no" is prepended to them (e.g. permanent and nopermanent).

dev DEV

the target device for the operation. If the device is a bridge port and "master" is set then the operation will be fulfilled by its master device's driver and all entries pointing to that port will be deleted.

brport DEV

the target bridge port for the operation. If the bridge device is specified then only entries pointing to the bridge itself will be deleted. Note that the target device specified by this option will override the one specified by dev above.

vlan VID

the target VLAN ID for the operation. Match forwarding table entries only with the specified VLAN ID.

src_vni VNI

the src VNI Network Identifier (or VXLAN Segment ID) for the operation. Match forwarding table entries only with the specified VNI. Valid if the referenced device is a VXLAN type device.

nhid NHID

the ECMP nexthop group for the operation. Match forwarding table entries only with the specified NHID. Valid if the referenced device is a VXLAN type device.

vni VNI

the VXLAN VNI Network Identifier (or VXLAN Segment ID) for the operation. Match forwarding table entries only with the specified VNI. Valid if the referenced device is a VXLAN type device.

port PORT

the UDP destination PORT number for the operation. Match forwarding table entries only with the specified PORT. Valid if the referenced device is a VXLAN type device.

dst IPADDR

the IP address of the destination VXLAN tunnel endpoint for the operation. Match forwarding table entries only with the specified IPADDR. Valid if the referenced device is a VXLAN type device.

self

the operation is fulfilled directly by the driver for the specified network device. If the network device belongs to a master like a bridge, then the bridge is bypassed and not notified of this operation. The "bridge fdb flush" command can also be used on the bridge device itself. The flag is set by default if "master" is not specified.

master

if the specified network device is a port that belongs to a master device such as a bridge, the operation is fulfilled by the master device's driver. Flush with both 'master' and 'self' is not recommended with attributes that are not supported by all devices (e.g., vlan, vni). Such command will be handled by bridge or VXLAN driver, but will return an error from the driver that does not support the attribute. Instead, run flush twice - once with 'self' and once with 'master', and each one with the supported attributes.

[no]permanent

if specified then only permanent entries will be deleted or respectively if "no" is prepended then only non-permanent entries will be deleted.

[no]static

if specified then only static entries will be deleted or respectively if "no" is prepended then only non-static entries will be deleted.

[no]dynamic

if specified then only dynamic entries will be deleted or respectively if "no" is prepended then only non-dynamic (static or permanent) entries will be deleted.

[no]added_by_user

if specified then only entries with added_by_user flag will be deleted or respectively if "no" is prepended then only entries without added_by_user flag will be deleted.

[no]extern_learn

if specified then only entries with extern_learn flag will be deleted or respectively if "no" is prepended then only entries without extern_learn flag will be deleted.

[no]sticky

if specified then only entries with sticky flag will be deleted or respectively if "no" is prepended then only entries without sticky flag will be deleted.

[no]offloaded

if specified then only entries with offloaded flag will be deleted or respectively if "no" is prepended then only entries without offloaded flag will be deleted.

[no]router

if specified then only entries with router flag will be deleted or respectively if "no" is prepended then only entries without router flag will be deleted. Valid if the referenced device is a VXLAN type device.

## bridge mdb - multicast group database management
mdb objects contain known IP or L2 multicast group addresses on a link.

The corresponding commands display mdb entries, add new entries, replace entries and delete old ones.

### bridge mdb add - add a new multicast group database entry
This command creates a new mdb entry.

dev DEV

the interface where this group address is associated.

port PORT

the port whose link is known to have members of this multicast group.

grp GROUP

the multicast group address (IPv4, IPv6 or L2 multicast) whose members reside on the link connected to the port. permanent - the mdb entry is permanent. Optional for IPv4 and IPv6, mandatory for L2.

temp - the mdb entry is temporary (default)

src SOURCE

optional source IP address of a sender for this multicast group. If IGMPv3 for IPv4, or MLDv2 for IPv6 respectively, are enabled it will be included in the lookup when forwarding multicast traffic.

vid VID

the VLAN ID which is known to have members of this multicast group.

filter_mode include or filter_mode exclude

controls whether the sources in the entry's source list are in INCLUDE or EXCLUDE mode. Can only be set for (*, G) entries.

source_list SOURCE_LIST

optional list of source IP addresses of senders for this multicast group, separated by a ','. Whether the entry forwards packets from these senders or not is determined by the entry's filter mode, which becomes a mandatory argument. Can only be set for (*, G) entries.

proto PROTO

the routing protocol identifier of this mdb entry. Can be a number or a string from the file /etc/iproute2/rt_protos. If the routing protocol is not given, then static is assumed.

The next command line parameters apply only when the specified device DEV is of type VXLAN.

dst IPADDR

the IP address of the destination VXLAN tunnel endpoint where the multicast receivers reside.

dst_port DST_PORT

the UDP destination port number to use to connect to the remote VXLAN tunnel endpoint. If omitted, the value specified at VXLAN device creation will be used.

vni VNI

the VXLAN VNI Network Identifier to use to connect to the remote VXLAN tunnel endpoint. If omitted, the value specified at VXLAN device creation will be used or the source VNI when the VXLAN device is in external mode.

src_vni SRC_VNI

the source VNI Network Identifier this entry belongs to. Used only when the VXLAN device is in external mode. If omitted, the value specified at VXLAN device creation will be used.

via DEV

device name of the outgoing interface for the VXLAN device to reach the remote VXLAN tunnel endpoint.

The 0.0.0.0 and :: MDB entries are special catchall entries used to flood IPv4 and IPv6 unregistered multicast packets, respectively. Therefore, when these entries are programmed, the catchall 00:00:00:00:00:00 FDB entry will only flood broadcast, unknown unicast and link-local multicast.

### bridge mdb delete - delete a multicast group database entry
This command removes an existing mdb entry.

The arguments are the same as with bridge mdb add.

### bridge mdb replace - replace a multicast group database entry
If no matching entry is found, a new one will be created instead.

The arguments are the same as with bridge mdb add.

### bridge mdb show - list multicast group database entries
This command displays the current multicast group membership table. The table is populated by IGMP and MLD snooping in the bridge driver automatically. It can be altered by bridge mdb add and bridge mdb del commands manually too.

dev DEV

the interface only whose entries should be listed. Default is to list all bridge interfaces.

With the -details option, the command becomes verbose. It prints out the ports known to have a connected router.

With the -statistics option, the command displays timer values for mdb and router port entries.

### bridge mdb get - get multicast group database entry.
This command retrieves a multicast group database entry based on its key.

dev DEV

the interface where this group address is associated.

grp GROUP

the multicast group address (IPv4, IPv6 or L2 multicast).

src SOURCE

the source IP address. Only relevant when retrieving an (S, G) entry.

vid VID

the VLAN ID. Only relevant when the bridge is VLAN-aware.

src_vni SRC_VNI

the source VNI Network Identifier. Only relevant when the VXLAN device is in external mode.

### bridge mdb flush - flush multicast group database entries.
This command flushes the matching multicast group database entries.

dev DEV

the interface where this group address is associated.

port PORT

the target port for the operation. If the bridge device is specified then only entries pointing to the bridge itself will be deleted.

vid VID

the VLAN ID for the operation. Match entries only with the specified VLAN ID.

src_vni SRC_VNI

the source VNI Network Identifier for the operation. Match entries only with the specified source VNI.

proto PROTO

the routing protocol identifier for the operation. Match entries only with the specified routing protocol. Can be a number or a string from the file /etc/iproute2/rt_protos.

[no]permanent

if specified then only permanent entries will be deleted or respectively if "no" is prepended then only non-permanent (temp) entries will be deleted.

dst IPADDR

the IP address of the destination VXLAN tunnel endpoint where the multicast receivers reside. Match entries only with the specified destination IP.

dst_port DST_PORT

the UDP destination port number to use to connect to the remote VXLAN tunnel endpoint. Match entries only with the specified destination port number.

vni VNI

the VXLAN VNI Network Identifier to use to connect to the remote VXLAN tunnel endpoint. Match entries only with the specified destination VNI.

## bridge mst - multiple spanning tree port states
In the multiple spanning tree (MST) model, the active paths through a network can be different for different VLANs. In other words, a bridge port can simultaneously forward one subset of VLANs, while blocking another.

Provided that the mst_enable bridge option is enabled, a group of VLANs can be forwarded along the same spanning tree by associating them with the same instance (MSTI) using bridge vlan global set.

### bridge mst set - set multiple spanning tree state
Set the spanning tree state for DEV, in the multiple spanning tree instance MSTI, to STP_STATE.

dev DEV

Interface name of the bridge port.

msti MSTI

The multiple spanning tree instance.

state STP_STATE

The spanning tree state, see the state option of bridge link set for supported states.

### bridge mst show - list MST states
List current MST port states in every MSTI.

dev DEV

If specified, only display states of the bridge port with this interface name.

## bridge vlan - VLAN filter list
vlan objects contain known VLAN IDs for a link.

The corresponding commands display vlan filter entries, add new entries, and delete old ones.

### bridge vlan add - add a new vlan filter entry
This command creates a new vlan filter entry.

dev NAME

the interface with which this vlan is associated.

vid VID

the VLAN ID that identifies the vlan.

tunnel_info TUNNEL_ID

the TUNNEL ID that maps to this vlan. The tunnel id is set in dst_metadata for every packet that belongs to this vlan (applicable to bridge ports with vlan_tunnel flag set).

pvid

the vlan specified is to be considered a PVID at ingress. Any untagged frames will be assigned to this VLAN.

untagged

the vlan specified is to be treated as untagged on egress.

self

the vlan is configured on the specified physical device. Required if the device is the bridge device.

master

the vlan is configured on the software bridge (default).

### bridge vlan delete - delete a vlan filter entry
This command removes an existing vlan filter entry.

The arguments are the same as with bridge vlan add. The pvid and untagged flags are ignored.

### bridge vlan set - change vlan filter entry's options
This command changes vlan filter entry's options.

dev NAME

the interface with which this vlan is associated.

vid VID

the VLAN ID that identifies the vlan.

state STP_STATE

the operation state of the vlan. One may enter STP state name (case insensitive), or one of the numbers below. Negative inputs are ignored, and unrecognized names return an error. Note that the state is set only for the vlan of the specified device, e.g. if it is a bridge port then the state will be set only for the vlan of the port. 0 - vlan is in STP DISABLED state. Make this vlan completely inactive for STP. This is also called BPDU filter and could be used to disable STP on an untrusted vlan.

1 - vlan is in STP LISTENING state. Only valid if STP is enabled on the bridge. In this state the vlan listens for STP BPDUs and drops all other traffic frames.

2 - vlan is in STP LEARNING state. Only valid if STP is enabled on the bridge. In this state the vlan will accept traffic only for the purpose of updating MAC address tables.

3 - vlan is in STP FORWARDING state. This is the default vlan state.

4 - vlan is in STP BLOCKING state. Only valid if STP is enabled on the bridge. This state is used during the STP election process. In this state, the vlan will only process STP BPDUs.

mcast_max_groups MAX_GROUPS

Sets the maximum number of MDB entries that can be registered for a given VLAN on a given port. A VLAN-specific equivalent of the per-port option of the same name, see above for details. Note that this option is only available when ip link option mcast_vlan_snooping is enabled.

mcast_router MULTICAST_ROUTER

configure this vlan and interface's multicast router mode, note that only modes 0 - 2 are available for bridge devices. A vlan and interface with a multicast router will receive all multicast traffic. MULTICAST_ROUTER may be either 0 - to disable multicast router.

1 - to let the system detect the presence of routers (default).

2 - to permanently enable multicast traffic forwarding on this vlan and interface.

3 - to temporarily mark this vlan and port as having a multicast router, i.e. enable multicast traffic forwarding. This mode is available only for ports.

neigh_suppress on or neigh_suppress off

Controls whether neigh discovery (arp and nd) proxy and suppression is enabled for a given VLAN on a given port. By default this flag is off. Note that this option only takes effect when bridge link option neigh_vlan_suppress is enabled for a given port.

### bridge vlan show - list vlan configuration.
This command displays the current VLAN filter table.

With the -details option, the command becomes verbose. It displays the per-vlan options.

With the -statistics option, the command displays per-vlan traffic statistics.

### bridge vlan tunnelshow - list vlan tunnel mapping.
This command displays the current vlan tunnel info mapping.

### bridge vlan global set - change vlan filter entry's global options
This command changes vlan filter entry's global options.

dev NAME

the interface with which this vlan is associated. Only bridge devices are supported for global options.

vid VID

the VLAN ID that identifies the vlan.

mcast_snooping MULTICAST_SNOOPING

turn multicast snooping for VLAN entry with VLAN ID on (MULTICAST_SNOOPING > 0) or off (MULTICAST_SNOOPING == 0). Default is on.

mcast_querier MULTICAST_QUERIER

enable (MULTICAST_QUERIER > 0) or disable (MULTICAST_QUERIER == 0) IGMP/MLD querier, ie sending of multicast queries by the bridge. Default is disabled.

mcast_igmp_version IGMP_VERSION

set the IGMP version. Default is 2.

mcast_mld_version MLD_VERSION

set the MLD version. Default is 1.

mcast_last_member_count LAST_MEMBER_COUNT

set multicast last member count, ie the number of queries the bridge will send before stopping forwarding a multicast group after a "leave" message has been received. Default is 2.

mcast_last_member_interval LAST_MEMBER_INTERVAL

interval between queries to find remaining members of a group, after a "leave" message is received.

mcast_startup_query_count STARTUP_QUERY_COUNT

set the number of queries to send during startup phase. Default is 2.

mcast_startup_query_interval STARTUP_QUERY_INTERVAL

interval between queries in the startup phase.

mcast_membership_interval MEMBERSHIP_INTERVAL

delay after which the bridge will leave a group, if no membership reports for this group are received.

mcast_querier_interval QUERIER_INTERVAL

interval between queries sent by other routers. If no queries are seen after this delay has passed, the bridge will start to send its own queries (as if mcast_querier was enabled).

mcast_query_interval QUERY_INTERVAL

interval between queries sent by the bridge after the end of the startup phase.

mcast_query_response_interval QUERY_RESPONSE_INTERVAL

set the Max Response Time/Maximum Response Delay for IGMP/MLD queries sent by the bridge.

msti MSTI

associate the VLAN with the specified multiple spanning tree instance (MSTI).

### bridge vlan global show - list global vlan options.
This command displays the global VLAN options for each VLAN entry.

dev DEV

the interface only whose VLAN global options should be listed. Default is to list all bridge interfaces.

vid VID

the VLAN ID only whose global options should be listed. Default is to list all vlans.

## bridge vni - VNI filter list
vni objects contain known VNI IDs for a dst metadata vxlan link.

The corresponding commands display vni filter entries, add new entries, and delete old ones.

### bridge vni add - add a new vni filter entry
This command creates a new vni filter entry.

dev NAME

the interface with which this vni is associated.

vni VNI

the VNI ID that identifies the vni.

remote IPADDR

specifies the unicast destination IP address to use in outgoing packets when the destination link layer address is not known in the VXLAN device forwarding database. This parameter cannot be specified with the group.

group IPADDR

specifies the multicast IP address to join for this VNI

### bridge vni del - delete a new vni filter entry
This command removes an existing vni filter entry.

The arguments are the same as with bridge vni add.

### bridge vni show - list vni filtering configuration.
This command displays the current vni filter table.

With the -statistics option, the command displays per-vni traffic statistics.

dev NAME

shows vni filtering table associated with the vxlan device

## bridge monitor - state monitoring
The bridge utility can monitor the state of devices and addresses continuously. This option has a slightly different format. Namely, the monitor command is the first in the command line and then the object list follows:

bridge monitor [ all | OBJECT-LIST ]

OBJECT-LIST is the list of object types that we want to monitor. It may contain link, fdb, vlan and mdb. If no file argument is given, bridge opens RTNETLINK, listens on it and dumps state changes in the format described in previous sections.

If a file name is given, it does not listen on RTNETLINK, but opens the file containing RTNETLINK messages saved in binary format and dumps them.

## NOTES
This command uses facilities added in Linux 3.0.

Although the forwarding table is maintained on a per-bridge device basis the bridge device is not part of the syntax. This is a limitation of the underlying netlink neighbour message protocol. When displaying the forwarding table, entries for all bridges are displayed. Add/delete/modify commands determine the underlying bridge device based on the bridge to which the corresponding ethernet device is attached.

## SEE ALSO
ip(8)

## BUGS
Please direct bugreports and patches to: <netdev@vger.kernel.org>

## AUTHOR
Original Manpage by Stephen Hemminger


dcb

title: dcb(8)

text:
# dcb(8)

## NAME
dcb - show / manipulate DCB (Data Center Bridging) settings

## SYNOPSIS

dcb [ OPTIONS ] { app | buffer | ets | maxrate | pfc } { COMMAND | help }

dcb [ -force ] -batch filename

dcb [ OPTIONS ] help

## OPTIONS
-n, --netns <NETNS>

switches dcb to the specified network namespace NETNS.

-V, --Version

Print the version of the dcb utility and exit.

-b, --batch <FILENAME>

Read commands from provided file or standard input and invoke them. First failure will cause termination of dcb.

-f, --force

Don't terminate dcb on errors in batch mode. If there were any errors during execution of the commands, the application return code will be non zero.

-i, --iec

When showing rates, use ISO/IEC 1024-based prefixes (Ki, Mi, Bi) instead of the 1000-based ones (K, M, B).

-j, --json

Generate JSON output.

-N, --Numeric

If the subtool in question translates numbers to symbolic names in some way, suppress this translation.

-p, --pretty

When combined with -j generate a pretty JSON output.

-s, --statistics

If the object in question contains any statistical counters, shown them as part of the "show" output.

## OBJECTS
app

- Configuration of application priority table

buffer

- Configuration of port buffers

ets

- Configuration of ETS (Enhanced Transmission Selection)

maxrate

- Configuration of per-TC maximum transmit rate

pfc

- Configuration of PFC (Priority-based Flow Control)

## COMMANDS
A COMMAND specifies the action to perform on the object. The set of possible actions depends on the object type. As a rule, it is possible to show objects and to invoke topical help, which prints a list of available commands and argument syntax conventions.

## ARRAY PARAMETERS
Like commands, specification of parameters is in the domain of individual objects (and their commands) as well. However, much of the DCB interface revolves around arrays of fixed size that specify one value per some key, such as per traffic class or per priority. There is therefore a single syntax for adjusting elements of these arrays. It consists of a series of KEY:VALUE pairs, where the meaning of the individual keys and values depends on the parameter.

The elements are evaluated in order from left to right, and the latter ones override the earlier ones. The elements that are not specified on the command line are queried from the kernel and their current value is retained.

As an example, take a made-up parameter tc-juju, which can be set to charm traffic in a given TC with either good luck or bad luck. KEY can therefore be 0..7 (as is usual for TC numbers in DCB), and VALUE either of none, good, and bad. An example of changing a juju value of TCs 0 and 7, while leaving all other intact, would then be:

\# dcb foo set dev eth0 tc-juju 0:good 7:bad

A special key, all, is recognized which sets the same value to all array elements. This can be combined with the usual single-element syntax. E.g. in the following, the juju of all keys is set to none, except 0 and 7, which have other values:

\# dcb foo set dev eth0 tc-juju all:none 0:good 7:bad

## EXIT STATUS
Exit status is 0 if command was successful or a positive integer upon failure.

## SEE ALSO
dcb-app(8), dcb-apptrust(8), dcb-buffer(8), dcb-ets(8), dcb-maxrate(8), dcb-pfc(8), dcb-rewr(8)

## REPORTING BUGS
Report any bugs to the Network Developers mailing list <netdev@vger.kernel.org> where the development and maintenance is primarily done. You do not have to be subscribed to the list to send a message there.

## AUTHOR
Petr Machata <me@pmachata.org>


dcb-app

title: dcb-app(8)

text:
# dcb-app(8)

## NAME
dcb-app - show / manipulate application priority table of the DCB (Data Center Bridging) subsystem

## SYNOPSIS

dcb [ OPTIONS ] app { COMMAND | help }

dcb app { show | flush } dev DEV [ default-prio ] [ ethtype-prio ] [ stream-port-prio ] [ dgram-port-prio ] [ port-prio ] [ dscp-prio ] [ pcp-prio ]

dcb app { add | del | replace } dev DEV [ default-prio PRIO-LIST ] [ ethtype-prio ET-MAP ] [ stream-port-prio PORT-MAP ] [ dgram-port-prio PORT-MAP ] [ port-prio PORT-MAP ] [ dscp-prio DSCP-MAP ] [ pcp-prio PCP-MAP ]

PRIO-LIST := [ PRIO-LIST ] PRIO

ET-MAP := [ ET-MAP ] ET-MAPPING

ET-MAPPING := ET:PRIO

PORT-MAP := [ PORT-MAP ] PORT-MAPPING

PORT-MAPPING := PORT:PRIO

DSCP-MAP := [ DSCP-MAP ] DSCP-MAPPING

DSCP-MAPPING := { DSCP | all }:PRIO

PCP-MAP := [ PCP-MAP ] PCP-MAPPING

PCP-MAPPING := PCP:PRIO

ET := { 0x600 .. 0xffff }

PORT := { 1 .. 65535 }

DSCP := { 0 .. 63 }

PCP := { 0(nd/de) .. 7(nd/de) }

PRIO := { 0 .. 7 }

## DESCRIPTION
dcb app is used to configure APP table, or application priority table in the DCB (Data Center Bridging) subsystem. The APP table is used to assign priority to traffic based on value in one of several headers: EtherType, L4 destination port, or DSCP. It also allows configuration of port-default priority that is chosen if no other prioritization rule applies.

DCB APP entries are 3-tuples of selector, protocol ID, and priority. Selector is an enumeration that picks one of the prioritization namespaces. Currently it mostly corresponds to configurable parameters described below. Protocol ID is a value in the selector namespace. E.g. for EtherType selector, protocol IDs are the individual EtherTypes, for DSCP they are individual code points. The priority is the priority that should be assigned to traffic that matches the selector and protocol ID.

The APP table is a set of DCB APP entries. The only requirement is that duplicate entries are not added. Notably, it is valid to have conflicting priority assignment for the same selector and protocol ID. For example, the set of two APP entries (DSCP, 10, 1) and (DSCP, 10, 2), where packets with DSCP of 10 should get priority of both 1 and 2, form a well-defined APP table. The dcb app tool allows low-level management of the app table by adding and deleting individual APP 3-tuples through add and del commands. On the other hand, the command replace does what one would typically want in this situation--first adds the new configuration, and then removes the obsolete one, so that only one prioritization is in effect for a given selector and protocol ID.

## COMMANDS
show

Display all entries with a given selector. When no selector is given, shows all APP table entries categorized per selector.

flush

Remove all entries with a given selector. When no selector is given, removes all APP table entries.

add

del

Add and, respectively, remove individual APP 3-tuples to and from the DCB APP table.

replace

Take the list of entries mentioned as parameter, and add those that are not present in the APP table yet. Then remove those entries, whose selector and protocol ID have been mentioned as parameter, but not with the exact same priority. This has the effect of, for the given selector and protocol ID, causing that the table only contains the priority (or priorities) given as parameter.

## PARAMETERS
The following table shows parameters in a way that they would be used with add, del and replace commands. For show and flush, the parameter name is to be used as a simple keyword without further arguments.

default-prio PRIO-LIST

The priority to be used for traffic the priority of which is otherwise unspecified. The argument is a list of individual priorities. Note that default-prio rules are configured as triplets (EtherType, 0, PRIO). dcb app translates these rules to the symbolic name default-prio and back.

ethtype-prio ET-MAP

ET-MAP uses the array parameter syntax, see dcb(8) for details. Keys are EtherType values. Values are priorities to be assigned to traffic with the matching EtherType.

stream-port-prio PORT-MAP

dgram-port-prio PORT-MAP

port-prio PORT-MAP

PORT-MAP uses the array parameter syntax, see dcb(8) for details. Keys are L4 destination port numbers that match on, respectively, TCP and SCTP traffic, UDP and DCCP traffic, and either of those. Values are priorities that should be assigned to matching traffic.

dscp-prio DSCP-MAP

DSCP-MAP uses the array parameter syntax, see dcb(8) for details. Keys are DSCP points, values are priorities assigned to traffic with matching DSCP. DSCP points can be written either directly as numeric values, or using symbolic names specified in /etc/iproute2/rt_dsfield (however note that the file specifies full 8-bit dsfield values, whereas dcb app will only use the higher six bits). dcb app show will similarly format DSCP values as symbolic names if possible. The command line option -N turns the show translation off.

pcp-prio PCP-MAP

PCP-MAP uses the array parameter syntax, see dcb(8) for details. Keys are PCP/DEI. Values are priorities assigned to traffic with matching PCP/DEI. PCP/DEI values are written as a combination of numeric- and symbolic values, to accommodate for both. PCP always in numerical form e.g 0 .. 7 and DEI in symbolic form e.g 'de' (drop-eligible), indicating that the DEI bit is 1 or 'nd' (not-drop-eligible), indicating that the DEI bit is 0. In combination 2de:1 translates to a mapping of PCP=2 and DEI=1 to priority 1.

## EXAMPLE & USAGE
Prioritize traffic with DSCP 0 to priority 0, 24 to 3 and 48 to 6:

\# dcb app add dev eth0 dscp-prio 0:0 24:3 48:6

Add another rule to configure DSCP 24 to priority 2 and show the result:

\# dcb app add dev eth0 dscp-prio 24:2

\# dcb app show dev eth0 dscp-prio

dscp-prio 0:0 CS3:2 CS3:3 CS6:6

\# dcb -N app show dev eth0 dscp-prio

dscp-prio 0:0 24:2 24:3 48:6

Reconfigure the table so that the only rule for DSCP 24 is for assignment of priority 4:

\# dcb app replace dev eth0 dscp-prio 24:4

\# dcb app -N show dev eth0 dscp-prio

dscp-prio 0:0 24:4 48:6

Flush all DSCP rules:

\# dcb app flush dev eth0 dscp-prio

\# dcb app show dev eth0 dscp-prio

(nothing)

Add a rule to map traffic with PCP 1 and DEI 0 to priority 1 and PCP 2 and DEI 1 to priority 2:

\# dcb app add dev eth0 pcp-prio 1nd:1 2de:2

\# dcb app show dev eth0 pcp-prio

pcp-prio 1nd:1 2de:2

## EXIT STATUS
Exit status is 0 if command was successful or a positive integer upon failure.

## SEE ALSO
dcb(8)

## REPORTING BUGS
Report any bugs to the Network Developers mailing list <netdev@vger.kernel.org> where the development and maintenance is primarily done. You do not have to be subscribed to the list to send a message there.

## AUTHOR
Petr Machata <me@pmachata.org>


dcb-apptrust

title: dcb-apptrust(8)

text:
# dcb-apptrust(8)

## NAME
dcb-apptrust - show / configure per-selector trust and trust order of the application priority table of the DCB (Data Center Bridging) subsystem.

## SYNOPSIS

dcb [ OPTIONS ] apptrust { COMMAND | help }

dcb apptrust show dev DEV [ order ]

dcb apptrust set dev DEV [ order SEL-LIST ]

SEL-LIST := [ SEL-LIST ] SEL

SEL := { ethtype | stream-port | dgram-port | port | dscp | pcp }

## DESCRIPTION
dcb apptrust is used to configure per-selector trust and trust order of the Application Priority Table, see dcb-app(8) for details on how to configure app table entries.

Selector trust can be used by the software stack, or drivers (most likely the latter), when querying the APP table, to determine if an APP entry should take effect, or not. Additionally, the order of the trusted selectors will dictate which selector should take precedence, in the case of multiple different APP table selectors being present.

## COMMANDS
show

Display all trusted selectors.

set

Set new list of trusted selectors. Empty list is effectively the same as removing trust entirely.

## PARAMETERS
The following describes only the write direction, i.e. as used with the set command. For the show command, the parameter name is to be used as a simple keyword without further arguments. This instructs the tool to show the values of a given parameter.

order SEL-LIST

SEL-LIST is a space-separated list of selector names. Possible selector values are: ethtype, stream-port, dgram-port, port, dscp, and pcp

## EXAMPLE & USAGE
Set trust order to: dscp, pcp for eth0:

\# dcb apptrust set dev eth0 order dscp pcp

Set trust order to: port (stream or dgram), pcp, ethtype for eth1:

\# dcb apptrust set dev eth1 order port pcp ethtype

Show what was set:

\# dcb apptrust show dev eth0

order: port pcp ethtype

## EXIT STATUS
Exit status is 0 if command was successful or a positive integer upon failure.

## SEE ALSO
dcb(8), dcb-app(8)

## REPORTING BUGS
Report any bugs to the Network Developers mailing list <netdev@vger.kernel.org> where the development and maintenance is primarily done. You do not have to be subscribed to the list to send a message there.

## AUTHOR
Daniel Machon <daniel.machon@microchip.com>


dcb-buffer

title: dcb-buffer(8)

text:
# dcb-buffer(8)

## NAME
dcb-buffer - show / manipulate port buffer settings of the DCB (Data Center Bridging) subsystem

## SYNOPSIS

dcb [ OPTIONS ] buffer { COMMAND | help }

dcb buffer show dev DEV [ prio-buffer ] [ buffer-size ] [ total-size ]

dcb buffer set dev DEV [ prio-buffer PRIO-MAP ] [ buffer-size SIZE-MAP ]

PRIO-MAP := [ PRIO-MAP ] PRIO-MAPPING

PRIO-MAPPING := { PRIO | all }:BUFFER

SIZE-MAP := [ SIZE-MAP ] SIZE-MAPPING

SIZE-MAPPING := { BUFFER | all }:SIZE

PRIO := { 0 .. 7 }

BUFFER := { 0 .. 7 }

SIZE := { INTEGER | INTEGERK | INTEGERM | ... }

## DESCRIPTION
dcb buffer is used to configure assignment of traffic to port buffers based on traffic priority, and sizes of those buffers. It can be also used to inspect the current configuration, as well as total device memory that the port buffers take.

## PARAMETERS
For read-write parameters, the following describes only the write direction, i.e. as used with the set command. For the show command, the parameter name is to be used as a simple keyword without further arguments. This instructs the tool to show the value of a given parameter. When no parameters are given, the tool shows the complete buffer configuration.

total-size

A read-only property that shows the total device memory taken up by port buffers. This might be more than a simple sum of individual buffer sizes if there are any hidden or internal buffers.

prio-buffer PRIO-MAP

PRIO-MAP uses the array parameter syntax, see dcb(8) for details. Keys are priorities, values are buffer indices. For each priority sets a buffer where traffic with that priority is directed to.

buffer-size SIZE-MAP

SIZE-MAP uses the array parameter syntax, see dcb(8) for details. Keys are buffer indices, values are sizes of that buffer in bytes. The sizes can use the notation documented in section PARAMETERS at tc(8). Note that the size requested by the tool can be rounded or capped by the driver to satisfy the requirements of the device.

## EXAMPLE & USAGE
Configure the priomap in a one-to-one fashion:

\# dcb buffer set dev eth0 prio-buffer 0:0 1:1 2:2 3:3 4:4 5:5 6:6 7:7

Set sizes of all buffers to 10KB, except for buffer 6, which will have the size 1MB:

\# dcb buffer set dev eth0 buffer-size all:10K 6:1M

Show what was set:

\# dcb buffer show dev eth0

prio-buffer 0:0 1:1 2:2 3:3 4:4 5:5 6:6 7:7

buffer-size 0:10Kb 1:10Kb 2:10Kb 3:10Kb 4:10Kb 5:10Kb 6:1Mb 7:10Kb

total-size 1222Kb

## EXIT STATUS
Exit status is 0 if command was successful or a positive integer upon failure.

## SEE ALSO
dcb(8)

## REPORTING BUGS
Report any bugs to the Network Developers mailing list <netdev@vger.kernel.org> where the development and maintenance is primarily done. You do not have to be subscribed to the list to send a message there.

## AUTHOR
Petr Machata <me@pmachata.org>


dcb-dcbx

title: dcb-dcbx(8)

text:
# dcb-dcbx(8)

## NAME
dcb-dcbx - show / manipulate port DCBX (Data Center Bridging eXchange)

## SYNOPSIS

dcb [ OPTIONS ] dcbx { COMMAND | help }

dcb dcbx show dev DEV

dcb dcbx set dev DEV [ host ] [ lld-managed ] [ cee ] [ ieee ] [ static ]

## DESCRIPTION
Data Center Bridging eXchange (DCBX) is a protocol used by DCB devices to exchange configuration information with directly connected peers. The Linux DCBX object is a 1-byte bitfield of flags that configure whether DCBX is implemented in the device or in the host, and which version of the protocol should be used. dcb dcbx is used to access the per-port Linux DCBX object.

There are two principal modes of operation: in host mode, DCBX protocol is implemented by the host LLDP agent, and the DCB interfaces are used to propagate the negotiate parameters to capable devices. In lld-managed mode, the configuration is handled by the device, and DCB interfaces are used for inspection of negotiated parameters, and can also be used to set initial parameters.

## PARAMETERS
When used with dcb dcbx set, the following keywords enable the corresponding configuration. The keywords that are not mentioned on the command line are considered disabled. When used with show, each enabled feature is shown by its corresponding keyword.

host

lld-managed

The device is in the host mode of operation and, respectively, the lld-managed mode of operation, as described above. In principle these two keywords are mutually exclusive, but dcb dcbx allows setting both and lets the driver handle it as appropriate.

cee

ieee

The device supports CEE (Converged Enhanced Ethernet) and, respectively, IEEE version of the DCB specification. Typically only one of these will be set, but dcb dcbx does not mandate this.

static

indicates the engine supports static configuration. No actual negotiation is performed, negotiated parameters are always the initial configuration.

## EXAMPLE & USAGE
Put the DCB engine into the "host" mode of operation, and use IEEE-standardized DCB interfaces:

\# dcb dcbx set dev eth0 host ieee

Show what was set:

\# dcb dcbx show dev eth0

host ieee

## EXIT STATUS
Exit status is 0 if command was successful or a positive integer upon failure.

## SEE ALSO
dcb(8)

## REPORTING BUGS
Report any bugs to the Network Developers mailing list <netdev@vger.kernel.org> where the development and maintenance is primarily done. You do not have to be subscribed to the list to send a message there.

## AUTHOR
Petr Machata <me@pmachata.org>


dcb-ets

title: dcb-ets(8)

text:
# dcb-ets(8)

## NAME
dcb-ets - show / manipulate ETS (Enhanced Transmission Selection) settings of the DCB (Data Center Bridging) subsystem

## SYNOPSIS

dcb [ OPTIONS ] ets { COMMAND | help }

dcb ets show dev DEV [ willing ] [ ets-cap ] [ cbs ] [ tc-tsa ] [ reco-tc-tsa ] [ pg-bw ] [ tc-bw ] [ reco-tc-bw ] [ prio-tc ] [ reco-prio-tc ]

dcb ets set dev DEV [ willing { on | off } ] [ { tc-tsa | reco-tc-tsa } TSA-MAP ] [ { pg-bw | tc-bw | reco-tc-bw } BW-MAP ] [ { prio-tc | reco-prio-tc } PRIO-MAP ]

TSA-MAP := [ TSA-MAP ] TSA-MAPPING

TSA-MAPPING := { TC | all }:{ strict | cbs | ets | vendor }

BW-MAP := [ BW-MAP ] BW-MAPPING

BW-MAPPING := { TC | all }:INTEGER

PRIO-MAP := [ PRIO-MAP ] PRIO-MAPPING

PRIO-MAPPING := { PRIO | all }:TC

TC := { 0 .. 7 }

PRIO := { 0 .. 7 }

## DESCRIPTION
dcb ets is used to configure Enhanced Transmission Selection attributes through Linux DCB (Data Center Bridging) interface. ETS permits configuration of mapping of priorities to traffic classes, traffic selection algorithm to use per traffic class, bandwidth allocation, etc.

Two DCB TLVs are related to the ETS feature: a configuration and recommendation values. Recommendation values are named with a prefix reco-, while the configuration ones have plain names.

## PARAMETERS
For read-write parameters, the following describes only the write direction, i.e. as used with the set command. For the show command, the parameter name is to be used as a simple keyword without further arguments. This instructs the tool to show the value of a given parameter. When no parameters are given, the tool shows the complete ETS configuration.

ets-cap

A read-only property that shows the number of supported ETS traffic classes.

cbs

A read-only property that is enabled if the driver and the hardware support the CBS Transmission Selection Algorithm.

willing { on | off }

Whether local host should accept configuration from peer TLVs.

prio-tc PRIO-MAP

reco-prio-tc PRIO-MAP

PRIO-MAP uses the array parameter syntax, see dcb(8) for details. Keys are priorities, values are traffic classes. For each priority sets a TC where traffic with that priority is directed to.

tc-tsa TSA-MAP

reco-tc-tsa TSA-MAP

TSA-MAP uses the array parameter syntax, see dcb(8) for details. Keys are TCs, values are Transmission Selection Algorithm (TSA) keywords described below. For each TC sets an algorithm used for deciding how traffic queued up at this TC is scheduled for transmission. Supported TSAs are: strict - for strict priority, where traffic in higher-numbered TCs always takes precedence over traffic in lower-numbered TCs.

ets - for Enhanced Traffic Selection, where available bandwidth is distributed among the ETS-enabled TCs according to the weights set by tc-bw and reco-tc-bw, respectively.

cbs - for Credit Based Shaper, where traffic is scheduled in a strict manner up to the limit set by a shaper.

vendor - for vendor-specific traffic selection algorithm.

tc-bw BW-MAP

reco-tc-bw BW-MAP

BW-MAP uses the array parameter syntax, see dcb(8) for details. Keys are TCs, values are integers representing percent of available bandwidth given to the traffic class in question. The value should be 0 for TCs whose TSA is not ets, and the sum of all values shall be 100. As an exception to the standard wording, a configuration with no ets TCs is permitted to sum up to 0 instead.

pg-bw BW-MAP

The precise meaning of pg-bw is not standardized, but the assumption seems to be that the same scheduling process as on the transmit side is applicable on receive side as well, and configures receive bandwidth allocation for ets ingress traffic classes (priority groups).

## EXAMPLE & USAGE
Configure ETS priomap in a one-to-one fashion:

\# dcb ets set dev eth0 prio-tc 0:0 1:1 2:2 3:3 4:4 5:5 6:6 7:7

Set TSA and transmit bandwidth configuration:

\# dcb ets set dev eth0 tc-tsa all:strict 0:ets 1:ets 2:ets \

tc-bw all:0 0:33 1:33 2:34

Show what was set:

\# dcb ets show dev eth0 prio-tc tc-tsa tc-bw

prio-tc 0:0 1:1 2:2 3:3 4:4 5:5 6:6 7:7

tc-tsa 0:ets 1:ets 2:ets 3:strict 4:strict 5:strict 6:strict 7:strict

tc-bw 0:33 1:33 2:34 3:0 4:0 5:0 6:0 7:0

## EXIT STATUS
Exit status is 0 if command was successful or a positive integer upon failure.

## SEE ALSO
dcb(8)

## REPORTING BUGS
Report any bugs to the Network Developers mailing list <netdev@vger.kernel.org> where the development and maintenance is primarily done. You do not have to be subscribed to the list to send a message there.

## AUTHOR
Petr Machata <me@pmachata.org>


dcb-maxrate

title: dcb-maxrate(8)

text:
# dcb-maxrate(8)

## NAME
dcb-maxrate - show / manipulate port maxrate settings of the DCB (Data Center Bridging) subsystem

## SYNOPSIS

dcb [ OPTIONS ] maxrate { COMMAND | help }

dcb maxrate show dev DEV [ tc-maxrate ]

dcb maxrate set dev DEV [ tc-maxrate RATE-MAP ]

RATE-MAP := [ RATE-MAP ] RATE-MAPPING

RATE-MAPPING := { TC | all }:RATE

TC := { 0 .. 7 }

RATE := { INTEGER[bit] | INTEGERKbit | INTEGERMib | ... }

## DESCRIPTION
dcb maxrate is used to configure and inspect maximum rate at which traffic is allowed to egress from a given traffic class.

## PARAMETERS
The following describes only the write direction, i.e. as used with the set command. For the show command, the parameter name is to be used as a simple keyword without further arguments. This instructs the tool to show the value of a given parameter. When no parameters are given, the tool shows the complete maxrate configuration.

tc-maxrate RATE-MAP

RATE-MAP uses the array parameter syntax, see dcb(8) for details. Keys are TC indices, values are traffic rates in bits per second. The rates can use the notation documented in section PARAMETERS at tc(8). Note that under that notation, "bit" stands for bits per second whereas "b" stands for bytes per second. When showing, the command line option -i toggles between using decadic and ISO/IEC prefixes.

## EXAMPLE & USAGE
Set rates of all traffic classes to 25Gbps, except for TC 6, which will have the rate of 100Gbps:

\# dcb maxrate set dev eth0 tc-maxrate all:25Gbit 6:100Gbit

Show what was set:

\# dcb maxrate show dev eth0

tc-maxrate 0:25Gbit 1:25Gbit 2:25Gbit 3:25Gbit 4:25Gbit 5:25Gbit 6:100Gbit 7:25Gbit

## EXIT STATUS
Exit status is 0 if command was successful or a positive integer upon failure.

## SEE ALSO
dcb(8)

## REPORTING BUGS
Report any bugs to the Network Developers mailing list <netdev@vger.kernel.org> where the development and maintenance is primarily done. You do not have to be subscribed to the list to send a message there.

## AUTHOR
Petr Machata <me@pmachata.org>


dcb-pfc

title: dcb-pfc(8)

text:
# dcb-pfc(8)

## NAME
dcb-pfc - show / manipulate PFC (Priority-based Flow Control) settings of the DCB (Data Center Bridging) subsystem

## SYNOPSIS

dcb [ OPTIONS ] pfc { COMMAND | help }

dcb pfc show dev DEV [ pfc-cap ] [ prio-pfc ] [ macsec-bypass ] [ delay ] [ requests ] [ indications ]

dcb pfc set dev DEV [ prio-pfc PFC-MAP ] [ macsec-bypass { on | off } ] [ delay INTEGER ]

PFC-MAP := [ PFC-MAP ] PFC-MAPPING

PFC-MAPPING := { PRIO | all }:{ on | off }

PRIO := { 0 .. 7 }

## DESCRIPTION
dcb pfc is used to configure Priority-based Flow Control attributes through Linux DCB (Data Center Bridging) interface. PFC permits marking flows with a certain priority as lossless, and holds related configuration, as well as PFC counters.

## PARAMETERS
For read-write parameters, the following describes only the write direction, i.e. as used with the set command. For the show command, the parameter name is to be used as a simple keyword without further arguments. This instructs the tool to show the value of a given parameter. When no parameters are given, the tool shows the complete PFC configuration.

pfc-cap

A read-only property that shows the number of traffic classes that may simultaneously support PFC.

requests

A read-only count of the sent PFC frames per traffic class. Only shown when -s is given, or when requested explicitly.

indications

A read-only count of the received PFC frames per traffic class. Only shown when -s is given, or when requested explicitly.

macsec-bypass { on | off }

Whether the sending station is capable of bypassing MACsec processing when MACsec is disabled.

prio-pfc PFC-MAP

PFC-MAP uses the array parameter syntax, see dcb(8) for details. Keys are priorities, values are on / off indicators of whether PFC is enabled for a given priority.

delay INTEGER

The allowance made for round-trip propagation delay of the link in bits. The value shall be 0..65535.

## EXAMPLE & USAGE
Enable PFC on priorities 6 and 7, leaving the rest intact:

\# dcb pfc set dev eth0 prio-pfc 6:on 7:on

Disable PFC of all priorities except 6 and 7, and configure delay to 4096 bits:

\# dcb pfc set dev eth0 prio-pfc all:off 6:on 7:on delay 0x1000

Show what was set:

\# dcb pfc show dev eth0

pfc-cap 8 macsec-bypass off delay 4096

prio-pfc 0:off 1:off 2:off 3:off 4:off 5:off 6:on 7:on

## EXIT STATUS
Exit status is 0 if command was successful or a positive integer upon failure.

## SEE ALSO
dcb(8)

## REPORTING BUGS
Report any bugs to the Network Developers mailing list <netdev@vger.kernel.org> where the development and maintenance is primarily done. You do not have to be subscribed to the list to send a message there.

## AUTHOR
Petr Machata <me@pmachata.org>