tc-taprio

title: tc-taprio(8)

summary: Time Aware Priority Shaper

text:
# tc-taprio(8)

## NAME
TAPRIO - Time Aware Priority Shaper

## SYNOPSIS
tc qdisc ... dev dev parent classid [ handle major: ] taprio num_tc tcs map P0 P1 P2 ... queues count1@offset1 count2@offset2 ... base-time base-time clockid clockid sched-entry <command 1> <gate mask 1> <interval 1> sched-entry <command 2> <gate mask 2> <interval 2> sched-entry <command 3> <gate mask 3> <interval 3> sched-entry <command N> <gate mask N> <interval N>

## DESCRIPTION
The TAPRIO qdisc implements a simplified version of the scheduling state machine defined by IEEE 802.1Q-2018 Section 8.6.9, which allows configuration of a sequence of gate states, where each gate state allows outgoing traffic for a subset (potentially empty) of traffic classes.

How traffic is mapped to different hardware queues is similar to mqprio(8) and so the map and queues parameters have the same meaning.

The other parameters specify the schedule, and at what point in time it should start (it can behave as the schedule started in the past).

## PARAMETERS
num_tc

Number of traffic classes to use. Up to 16 classes supported.

map

The priority to traffic class map. Maps priorities 0..15 to a specified traffic class. See mqprio(8) for more details.

queues

Provide count and offset of queue range for each traffic class. In the format, count@offset. Queue ranges for each traffic classes cannot overlap and must be a contiguous range of queues.

base-time

Specifies the instant in nanoseconds, using the reference of clockid, defining the time when the schedule starts. If 'base-time' is a time in the past, the schedule will start at base-time + (N * cycle-time)

where N is the smallest integer so the resulting time is greater than "now", and "cycle-time" is the sum of all the intervals of the entries in the schedule;

clockid

Specifies the clock to be used by qdisc's internal timer for measuring time and scheduling events. This argument must be omitted when using the full-offload feature (flags 0x2), since in that case, the clockid is implicitly /dev/ptpN (where N is given by ethtool -T eth0 | grep 'PTP Hardware Clock' ), and therefore not necessarily synchronized with the system's CLOCK_TAI.

sched-entry

There may multiple sched-entry parameters in a single schedule. Each one has the sched-entry <command> <gatemask> <interval>

format. The only supported <command> is "S", which means "SetGateStates", following the IEEE 802.1Q-2018 definition (Table 8-7). <gate mask> is a bitmask where each bit is a associated with a traffic class, so bit 0 (the least significant bit) being "on" means that traffic class 0 is "active" for that schedule entry. <interval> is a time duration, in nanoseconds, that specifies for how long that state defined by <command> and <gate mask> should be held before moving to the next entry.

flags

This is a bit mask which specifies different modes for taprio.

0x1

Enables the txtime-assist feature. In this mode, taprio will set the transmit timestamp depending on the interval in which the packet needs to be transmitted. It will then utililize the etf(8) qdisc to sort and transmit the packets at the right time. The second example can be used as a reference to configure this mode.

0x2

Enables the full-offload feature. In this mode, taprio will pass the gate control list to the NIC which will execute it cyclically in hardware. When using full-offload, there is no need to specify the clockid argument. The txtime-assist and full-offload features are mutually exclusive, i.e. setting flags to 0x3 is invalid.

txtime-delay

This parameter is specific to the txtime offload mode. It specifies the maximum time a packet might take to reach the network card from the taprio qdisc. The value should always be greater than the delta specified in the etf(8) qdisc.

## EXAMPLES
The following example shows how an traffic schedule with three traffic classes ("num_tc 3"), which are separated different traffic classes, we are going to call these TC 0, TC 1 and TC 2. We could read the "map" parameter below as: traffic with priority 3 is classified as TC 0, priority 2 is classified as TC 1 and the rest is classified as TC 2.

The schedule will start at instant 1528743495910289987 using the reference CLOCK_TAI. The schedule is composed of three entries each of 300us duration.

```
# tc qdisc replace dev eth0 parent root handle 100 taprio \

              num_tc 3 \

              map 2 2 1 0 2 2 2 2 2 2 2 2 2 2 2 2 \

              queues 1@0 1@1 2@2 \

              base-time 1528743495910289987 \

              sched-entry S 01 300000 \

              sched-entry S 02 300000 \

              sched-entry S 04 300000 \

              clockid CLOCK_TAI
```

Following is an example to enable the txtime offload mode in taprio. See etf(8) for more information about configuring the ETF qdisc.

```
# tc qdisc replace dev eth0 parent root handle 100 taprio \

              num_tc 3 \

              map 2 2 1 0 2 2 2 2 2 2 2 2 2 2 2 2 \

              queues 1@0 1@0 1@0 \

              base-time 1528743495910289987 \

              sched-entry S 01 300000 \

              sched-entry S 02 300000 \

              sched-entry S 04 400000 \

              flags 0x1 \

              txtime-delay 200000 \

              clockid CLOCK_TAI
# tc qdisc replace dev $IFACE parent 100:1 etf skip_skb_check \

              offload delta 200000 clockid CLOCK_TAI
```

The following is a schedule in full offload mode. The base-time is 200 ns and the cycle-time is implicitly calculated as the sum of all sched-entry durations (i.e. 20 us + 20 us + 60 us = 100 us). Although the base-time is in the past, the hardware will start executing the schedule at a PTP time equal to the smallest integer multiple of 100 us, plus 200 ns, that is larger than the NIC's current PTP time.

```
# tc qdisc add dev eth0 parent root taprio \

              num_tc 8 \

              map 0 1 2 3 4 5 6 7 \

              queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 \

              base-time 200 \

              sched-entry S 80 20000 \

              sched-entry S a0 20000 \

              sched-entry S df 60000 \

              flags 0x2
```

## AUTHORS
Vinicius Costa Gomes <vinicius.gomes@intel.com>


tc-tbf

title: tc-tbf(8)

summary: Token Bucket Filter

text:
# tc-tbf(8)

## NAME
tbf - Token Bucket Filter

## SYNOPSIS
tc qdisc ... tbf rate rate burst bytes/cell ( latency ms | limit bytes ) [ mpu bytes [ peakrate rate mtu bytes/cell ] ]

burst is also known as buffer and maxburst. mtu is also known as minburst.

## DESCRIPTION
The Token Bucket Filter is a classful queueing discipline available for traffic control with the tc(8) command.

TBF is a pure shaper and never schedules traffic. It is non-work-conserving and may throttle itself, although packets are available, to ensure that the configured rate is not exceeded. It is able to shape up to 1mbit/s of normal traffic with ideal minimal burstiness, sending out data exactly at the configured rates.

Much higher rates are possible but at the cost of losing the minimal burstiness. In that case, data is on average dequeued at the configured rate but may be sent much faster at millisecond timescales. Because of further queues living in network adaptors, this is often not a problem.

## ALGORITHM
As the name implies, traffic is filtered based on the expenditure of tokens. Tokens roughly correspond to bytes, with the additional constraint that each packet consumes some tokens, no matter how small it is. This reflects the fact that even a zero-sized packet occupies the link for some time.

On creation, the TBF is stocked with tokens which correspond to the amount of traffic that can be burst in one go. Tokens arrive at a steady rate, until the bucket is full.

If no tokens are available, packets are queued, up to a configured limit. The TBF now calculates the token deficit, and throttles until the first packet in the queue can be sent.

If it is not acceptable to burst out packets at maximum speed, a peakrate can be configured to limit the speed at which the bucket empties. This peakrate is implemented as a second TBF with a very small bucket, so that it doesn't burst.

To achieve perfection, the second bucket may contain only a single packet, which leads to the earlier mentioned 1mbit/s limit.

This limit is caused by the fact that the kernel can only throttle for at minimum 1 'jiffy', which depends on HZ as 1/HZ. For perfect shaping, only a single packet can get sent per jiffy - for HZ=100, this means 100 packets of on average 1000 bytes each, which roughly corresponds to 1mbit/s.

## PARAMETERS
See tc(8) for how to specify the units of these values.

limit or latency

Limit is the number of bytes that can be queued waiting for tokens to become available. You can also specify this the other way around by setting the latency parameter, which specifies the maximum amount of time a packet can sit in the TBF. The latter calculation takes into account the size of the bucket, the rate and possibly the peakrate (if set). These two parameters are mutually exclusive.

burst

Also known as buffer or maxburst. Size of the bucket, in bytes. This is the maximum amount of bytes that tokens can be available for instantaneously. In general, larger shaping rates require a larger buffer. For 10mbit/s on Intel, you need at least 10kbyte buffer if you want to reach your configured rate! If your buffer is too small, packets may be dropped because more tokens arrive per timer tick than fit in your bucket. The minimum buffer size can be calculated by dividing the rate by HZ.

Token usage calculations are performed using a table which by default has a resolution of 8 packets. This resolution can be changed by specifying the cell size with the burst. For example, to specify a 6000 byte buffer with a 16 byte cell size, set a burst of 6000/16. You will probably never have to set this. Must be an integral power of 2.

mpu

A zero-sized packet does not use zero bandwidth. For ethernet, no packet uses less than 64 bytes. The Minimum Packet Unit determines the minimal token usage (specified in bytes) for a packet. Defaults to zero.

rate

The speed knob. See remarks above about limits! See tc(8) for units.

Furthermore, if a peakrate is desired, the following parameters are available:

peakrate

Maximum depletion rate of the bucket. The peakrate does not need to be set, it is only necessary if perfect millisecond timescale shaping is required.

mtu/minburst

Specifies the size of the peakrate bucket. For perfect accuracy, should be set to the MTU of the interface. If a peakrate is needed, but some burstiness is acceptable, this size can be raised. A 3000 byte minburst allows around 3mbit/s of peakrate, given 1000 byte packets. Like the regular burstsize you can also specify a cell size.

## EXAMPLE & USAGE
To attach a TBF with a sustained maximum rate of 0.5mbit/s, a peakrate of 1.0mbit/s, a 5kilobyte buffer, with a pre-bucket queue size limit calculated so the TBF causes at most 70ms of latency, with perfect peakrate behaviour, issue:

\# tc qdisc add dev eth0 handle 10: root tbf rate 0.5mbit \

burst 5kb latency 70ms peakrate 1mbit \

minburst 1540

To attach an inner qdisc, for example sfq, issue:

\# tc qdisc add dev eth0 parent 10:1 handle 100: sfq

Without inner qdisc TBF queue acts as bfifo. If the inner qdisc is changed the limit/latency is not effective anymore.

## SEE ALSO
tc(8)

## AUTHOR
Alexey N. Kuznetsov, <kuznet@ms2.inr.ac.ru>. This manpage maintained by bert hubert <ahu@ds9a.nl>


tc-tcindex

title: tc-tcindex(8)

summary: traffic control index filter

text:
# tc-tcindex(8)

## NAME
tcindex - traffic control index filter

## SYNOPSIS

tc filter ... tcindex [ hash SIZE ] [ mask MASK ] [ shift SHIFT ] [ pass_on | fall_through ] [ classid CLASSID ] [ action ACTION_SPEC ]

## DESCRIPTION
This filter allows to match packets based on their tcindex field value, i.e. the combination of the DSCP and ECN fields as present in IPv4 and IPv6 headers.

## OPTIONS
action ACTION_SPEC

Apply an action from the generic actions framework on matching packets.

classid CLASSID

Push matching packets into the class identified by CLASSID.

hash SIZE

Hash table size in entries to use. Defaults to 64.

mask MASK

An optional bitmask to binary AND to the packet's tcindex field before use.

shift SHIFT

The number of bits to right-shift a packet's tcindex value before use. If a mask has been set, masking is done before shifting.

pass_on

If this flag is set, failure to find a class for the resulting ID will make the filter fail and lead to the next filter being consulted.

fall_through

This is the opposite of pass_on and the default. The filter will classify the packet even if there is no class present for the resulting class ID.

## SEE ALSO
tc(8)


title: tc-tunnel_key(8)

text:
# tc-tunnel_key(8)

## NAME
tunnel_key - Tunnel metadata manipulation

## SYNOPSIS

tc ... action tunnel_key { unset | SET }

SET := set src_ip ADDRESS dst_ip ADDRESS id KEY_ID dst_port UDP_PORT tos TOS ttl TTL [ csum | nocsum ]

## DESCRIPTION
The tunnel_key action combined with a shared IP tunnel device, allows to perform IP tunnel en- or decapsulation on a packet, reflected by the operation modes UNSET and SET. The UNSET mode is optional - even without using it, the metadata information will be released automatically when packet processing will be finished. UNSET function could be used in cases when traffic is forwarded between two tunnels, where the metadata from the first tunnel will be used for encapsulation done by the second tunnel. SET mode requires the source and destination ip ADDRESS and the tunnel key id KEY_ID which will be used by the ip tunnel shared device to create the tunnel header. The tunnel_key action is useful only in combination with a mirred redirect action to a shared IP tunnel device which will use the metadata (for SET ) and unset the metadata created by it (for UNSET ).

## OPTIONS
unset

Unset the tunnel metadata created by the IP tunnel device. This function is not mandatory and might be used only in some specific use cases (as explained above).

set

Set tunnel metadata to be used by the IP tunnel device. Requires src_ip and dst_ip options. id , dst_port , geneve_opts , vxlan_opts and erspan_opts are optional.

id

Tunnel ID (for example VNI in VXLAN tunnel)

src_ip

Outer header source IP address (IPv4 or IPv6)

dst_ip

Outer header destination IP address (IPv4 or IPv6)

dst_port

Outer header destination UDP port

geneve_opts

Geneve variable length options. geneve_opts is specified in the form CLASS:TYPE:DATA, where CLASS is represented as a 16bit hexadecimal value, TYPE as an 8bit hexadecimal value and DATA as a variable length hexadecimal value. Additionally multiple options may be listed using a comma delimiter.

vxlan_opts

Vxlan metadata options. vxlan_opts is specified in the form GBP, as a 32bit number. Multiple options is not supported.

erspan_opts

Erspan metadata options. erspan_opts is specified in the form VERSION:INDEX:DIR:HWID, where VERSION is represented as a 8bit number, INDEX as an 32bit number, DIR and HWID as a 8bit number. Multiple options is not supported. Note INDEX is used when VERSION is 1, and DIR and HWID are used when VERSION is 2.

tos

Outer header TOS

ttl

Outer header TTL

[no]csum

Controls outer UDP checksum. When set to csum (which is default), the outer UDP checksum is calculated and included in the packets. When set to nocsum, outer UDP checksum is zero. Note that when using zero UDP checksums with IPv6, the other tunnel endpoint must be configured to accept such packets. In Linux, this would be the udp6zerocsumrx option for the VXLAN tunnel interface.

If using nocsum with IPv6, be sure you know what you are doing. Zero UDP checksums provide weaker protection against corrupted packets. See RFC6935 for details.

## EXAMPLES
The following example encapsulates incoming ICMP packets on eth0 into a vxlan tunnel, by setting metadata to VNI 11, source IP 11.11.0.1 and destination IP 11.11.0.2, and by redirecting the packet with the metadata to device vxlan0, which will do the actual encapsulation using the metadata:

```
#tc qdisc add dev eth0 handle ffff: ingress
#tc filter add dev eth0 protocol ip parent ffff: \

  flower \

    ip_proto icmp \

  action tunnel_key set \

    src_ip 11.11.0.1 \

    dst_ip 11.11.0.2 \

    id 11 \

  action mirred egress redirect dev vxlan0
```

Here is an example of the unset function: Incoming VXLAN traffic with outer IP's and VNI 11 is decapsulated by vxlan0 and metadata is unset before redirecting to tunl1 device:

```
#tc qdisc add dev eth0 handle ffff: ingress
#tc filter add dev vxlan0 protocol ip parent ffff:   flower \
	  enc_src_ip 11.11.0.2 enc_dst_ip 11.11.0.1 enc_key_id 11 	action tunnel_key unset 	action mirred egress redirect dev tunl1
```

## SEE ALSO
tc(8)


title: tc-u32(8)

summary: universal 32bit traffic control filter

text:
# tc-u32(8)

## NAME
u32 - universal 32bit traffic control filter

## SYNOPSIS

tc filter ... [ handle HANDLE ] u32 OPTION_LIST [ offset OFFSET ] [ hashkey HASHKEY ] [ classid CLASSID ] [ divisor uint_value ] [ order u32_value ] [ ht HANDLE ] [ sample SELECTOR [ divisor uint_value ] ] [ link HANDLE ] [ indev ifname ] [ skip_hw | skip_sw ] [ help ]

HANDLE := { u12_hex_htid:[u8_hex_hash:[u12_hex_nodeid] | 0xu32_hex_value }

OPTION_LIST := [ OPTION_LIST ] OPTION

HASHKEY := [ mask u32_hex_value ] [ at 4*int_value ]

CLASSID := { root | none | [u16_major]:u16_minor | u32_hex_value }

OFFSET := [ plus int_value ] [ at 2*int_value ] [ mask u16_hex_value ] [ shift int_value ] [ eat ]

OPTION := { match SELECTOR | action ACTION }

SELECTOR := { u32 VAL_MASK_32 | u16 VAL_MASK_16 | u8 VAL_MASK_8 | ip IP | ip6 IP6 | { tcp | udp } TCPUDP | icmp ICMP | mark VAL_MASK_32 | ether ETHER }

IP := { { src | dst } { default | any | all | ip_address [ / { prefixlen | netmask } ] } AT | { dsfield | ihl | protocol | precedence | icmp_type | icmp_code } VAL_MASK_8 | { sport | dport } VAL_MASK_16 | nofrag | firstfrag | df | mf }

IP6 := { { src | dst } { default | any | all | ip6_address [/prefixlen ] } AT | priority VAL_MASK_8 | { protocol | icmp_type | icmp_code } VAL_MASK_8 | flowlabel VAL_MASK_32 | { sport | dport } VAL_MASK_16 }

TCPUDP := { src | dst } VAL_MASK_16

ICMP := { type VAL_MASK_8 | code VAL_MASK_8 }

ETHER := { src | dst } ether_address AT

VAL_MASK_32 := u32_value u32_hex_mask [ AT ]

VAL_MASK_16 := u16_value u16_hex_mask [ AT ]

VAL_MASK_8 := u8_value u8_hex_mask [ AT ]

AT := [ at [ nexthdr+ ] int_value ]

## DESCRIPTION
The Universal/Ugly 32bit filter allows to match arbitrary bitfields in the packet. Due to breaking everything down to values, masks and offsets, It is equally powerful and hard to use. Luckily many abstracting directives are present which allow defining rules on a higher level and therefore free the user from having to fiddle with bits and masks in many cases.

There are two general modes of invocation: The first mode creates a new filter to delegate packets to different destinations. Apart from the obvious ones, namely classifying the packet by specifying a CLASSID or calling an action, one may link one filter to another one (or even a list of them), effectively organizing filters into a tree-like hierarchy.

Typically filter delegation is done by means of a hash table, which leads to the second mode of invocation: it merely serves to set up these hash tables. Filters can select a hash table and provide a key selector from which a hash is to be computed and used as key to lookup the table's bucket which contains filters for further processing. This is useful if a high number of filters is in use, as the overhead of performing the hash operation and table lookup becomes negligible in that case. Using hashtables with u32 basically involves the following pattern:

(1)

Creating a new hash table, specifying it's size using the divisor parameter and ideally a handle by which the table can be identified. If the latter is not given, the kernel chooses one on it's own, which has to be guessed later.

(2)

Creating filters which link to the created table in (1) using the link parameter and defining the packet data which the kernel will use to calculate the hashkey.

(3)

Adding filters to buckets in the hash table from (1). In order to avoid having to know how exactly the kernel creates the hash key, there is the sample parameter, which gives sample data to hash and thereby define the table bucket the filter should be added to.

In fact, even if not explicitly requested u32 creates a hash table for every priority a filter is being added with. The table's size is 1 though, so it is in fact merely a linked list.

## VALUES
Options and selectors require values to be specified in a specific format, which is often non-intuitive. Therefore the terminals in SYNOPSIS have been given descriptive names to indicate the required format and/or maximum allowed numeric value: Prefixes u32, u16 and u8 indicate four, two and single byte unsigned values. E.g. u16 indicates a two byte-sized value in range between 0 and 65535 (0xFFFF) inclusive. A prefix of int indicates a four byte signed value. A middle part of _hex_ indicates that the value is parsed in hexadecimal format. Otherwise, the value's base is automatically detected, i.e. values prefixed with 0x are considered hexadecimal, a leading 0 indicates octal format and decimal format otherwise. There are some values with special formatting as well: ip_address and netmask are in dotted-quad formatting as usual for IPv4 addresses. An ip6_address is specified in common, colon-separated hexadecimal format. Finally, prefixlen is an unsigned, decimal integer value in range from 0 to the address width in bits (32 for IPv4 and 128 for IPv6).

Sometimes values need to be dividable by a certain number. In that case a name of the form N*val was chosen, indicating that val must be dividable by N. Or the other way around: the resulting value must be a multiple of N.

## OPTIONS
U32 recognizes the following options:

handle HANDLE

The handle is used to reference a filter and therefore must be unique. It consists of a hash table identifier htid and optional hash (which identifies the hash table's bucket) and nodeid. All these values are parsed as unsigned, hexadecimal numbers with length 12bits ( htid and nodeid) or 8bits ( hash). Alternatively one may specify a single, 32bit long hex number which contains the three fields bits in concatenated form. Other than the fields themselves, it has to be prefixed by 0x.

offset OFFSET

Set an offset which defines where matches of subsequent filters are applied to. Therefore this option is useful only when combined with link or a combination of ht and sample. The offset may be given explicitly by using the plus keyword, or extracted from the packet data with at. It is possible to mangle the latter using mask and/or shift keywords. By default, this offset is recorded but not implicitly applied. It is used only to substitute the nexthdr+ statement. Using the keyword eat though inverses this behaviour: the offset is applied always, and nexthdr+ will fall back to zero.

hashkey HASHKEY

Spefify what packet data to use to calculate a hash key for bucket lookup. The kernel adjusts the value according to the hash table's size. For this to work, the option link must be given.

classid CLASSID

Classify matching packets into the given CLASSID, which consists of either 16bit major and minor numbers or a single 32bit value combining both.

divisor u32_value

Specify a modulo value. Used when creating hash tables to define their size or for declaring a sample to calculate hash table keys from. Must be a power of two with exponent not exceeding eight.

order u32_value

A value to order filters by, ascending. Conflicts with handle which serves the same purpose.

sample SELECTOR

Used together with ht to specify which bucket to add this filter to. This allows one to avoid having to know how exactly the kernel calculates hashes. The additional divisor defaults to 256, so must be given for hash tables of different size.

link HANDLE

Delegate matching packets to filters in a hash table. HANDLE is used to only specify the hash table, so only htid may be given, hash and nodeid have to be omitted. By default, bucket number 0 will be used and can be overridden by the hashkey option.

indev ifname

Filter on the incoming interface of the packet. Obviously works only for forwarded traffic.

skip_sw

Do not process filter by software. If hardware has no offload support for this filter, or TC offload is not enabled for the interface, operation will fail.

skip_hw

Do not process filter by hardware.

help

Print a brief help text about possible options.

## SELECTORS
Basically the only real selector is u32 . All others merely provide a higher level syntax and are internally translated into u32 .

u32 VAL_MASK_32

u16 VAL_MASK_16

u8 VAL_MASK_8

Match packet data to a given value. The selector name defines the sample length to extract (32bits for u32, 16bits for u16 and 8bits for u8). Before comparing, the sample is binary AND'ed with the given mask. This way uninteresting bits can be cleared before comparison. The position of the sample is defined by the offset specified in AT.

ip IP

ip6 IP6

Assume packet starts with an IPv4 ( ip) or IPv6 ( ip6) header. IP/IP6 then allows to match various header fields:

src ADDR

dst ADDR

Compare Source or Destination Address fields against the value of ADDR. The reserved words default, any and all effectively match any address. Otherwise an IP address of the particular protocol is expected, optionally suffixed by a prefix length to match whole subnets. In case of IPv4 a netmask may also be given.

dsfield VAL_MASK_8

IPv4 only. Match the packet header's DSCP/ECN field. Synonyms to this are tos and precedence.

ihl VAL_MASK_8

IPv4 only. Match the Internet Header Length field. Note that the value's unit is 32bits, so to match a packet with 24byte header length u8_value has to be 6.

protocol VAL_MASK_8

Match the Protocol (IPv4) or Next Header (IPv6) field value, e.g. 6 for TCP.

icmp_type VAL_MASK_8

icmp_code VAL_MASK_8

Assume a next-header protocol of icmp or ipv6-icmp and match Type or Code field values. This is dangerous, as the code assumes minimal header size for IPv4 and lack of extension headers for IPv6.

sport VAL_MASK_16

dport VAL_MASK_16

Match layer four source or destination ports. This is dangerous as well, as it assumes a suitable layer four protocol is present (which has Source and Destination Port fields right at the start of the header and 16bit in size). Also minimal header size for IPv4 and lack of IPv6 extension headers is assumed.

nofrag

firstfrag

df

mf

IPv4 only, check certain flags and fragment offset values. Match if the packet is not a fragment (nofrag), the first fragment (firstfrag), if Don't Fragment (df) or More Fragments (mf) bits are set.

priority VAL_MASK_8

IPv6 only. Match the header's Traffic Class field, which has the same purpose and semantics of IPv4's ToS field since RFC 3168: upper six bits are DSCP, the lower two ECN.

flowlabel VAL_MASK_32

IPv6 only. Match the Flow Label field's value. Note that Flow Label itself is only 20bytes long, which are the least significant ones here. The remaining upper 12bytes match Version and Traffic Class fields.

tcp TCPUDP

udp TCPUDP

Match fields of next header of protocol TCP or UDP. The possible values for TCPDUP are:

src VAL_MASK_16

Match on Source Port field value.

dst VALMASK_16

Match on Destination Port field value.

icmp ICMP

Match fields of next header of protocol ICMP. The possible values for ICMP are:

type VAL_MASK_8

Match on ICMP Type field.

code VAL_MASK_8

Match on ICMP Code field.

mark VAL_MASK_32

Match on netfilter fwmark value.

ether ETHER

Match on ethernet header fields. Possible values for ETHER are:

src ether_address AT

dst ether_address AT

Match on source or destination ethernet address. This is dangerous: It assumes an ethernet header is present at the start of the packet. This will probably lead to unexpected things if used with layer three interfaces like e.g. tun or ppp.

## EXAMPLES

```
tc filter add dev eth0 parent 999:0 prio 99 protocol ip u32 \

        match ip src 192.168.8.0/24 classid 1:1
```

This attaches a filter to the qdisc identified by 999:0. It's priority is 99, which affects in which order multiple filters attached to the same parent are consulted (the lower the earlier). The filter handles packets of protocol type ip, and matches if the IP header's source address is within the 192.168.8.0/24 subnet. Matching packets are classified into class 1.1. The effect of this command might be surprising at first glance:

```
filter parent 1: protocol ip pref 99 u32
filter parent 1: protocol ip pref 99 u32 \

        fh 800: ht divisor 1
filter parent 1: protocol ip pref 99 u32 \

        fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:1 \

        match c0a80800/ffffff00 at 12
```

So parent 1: is assigned a new u32 filter, which contains a hash table of size 1 (as the divisor indicates). The table ID is 800. The third line then shows the actual filter which was added above: it sits in table 800 and bucket 0, classifies packets into class ID 1:1 and matches the upper three bytes of the four byte value at offset 12 to be 0xc0a808, which is 192, 168 and 8.

Now for something more complicated, namely creating a custom hash table:

```
tc filter add dev eth0 prio 99 handle 1: u32 divisor 256
```

This creates a table of size 256 with handle 1: in priority 99. The effect is as follows:

```
filter parent 1: protocol all pref 99 u32
filter parent 1: protocol all pref 99 u32 fh 1: ht divisor 256
filter parent 1: protocol all pref 99 u32 fh 800: ht divisor 1
```

So along with the requested hash table (handle 1:), the kernel has created his own table of size 1 to hold other filters of the same priority.

The next step is to create a filter which links to the created hash table:

```
tc filter add dev eth0 parent 1: prio 1 u32 \

        link 1: hashkey mask 0x0000ff00 at 12 \

        match ip src 192.168.0.0/16
```

The filter is given a lower priority than the hash table itself so u32 consults it before manually traversing the hash table. The options link and hashkey determine which table and bucket to redirect to. In this case the hash key should be constructed out of the second byte at offset 12, which corresponds to an IP packet's third byte of the source address field. Along with the match statement, this effectively maps all class C networks below 192.168.0.0/16 to different buckets of the hash table.

Filters for certain subnets can be created like so:

```
tc filter add dev eth0 parent 1: prio 99 u32 \

        ht 1: sample u32 0x00000800 0x0000ff00 at 12 \

        match ip src 192.168.8.0/24 classid 1:1
```

The bucket is defined using the sample option: In this case, the second byte at offset 12 must be 0x08, exactly. In this case, the resulting bucket ID is obviously 8, but as soon as sample selects an amount of data which could exceed the divisor, one would have to know the kernel-internal algorithm to deduce the destination bucket. This filter's match statement is redundant in this case, as the entropy for the hash key does not exceed the table size and therefore no collisions can occur. Otherwise it's necessary to prevent matching unwanted packets.

Matching upper layer fields is problematic since IPv4 header length is variable and IPv6 supports extension headers which affect upper layer header offset. To overcome this, there is the possibility to specify nexthdr+ when giving an offset, and to make things easier there are the tcp and udp matches which use nexthdr+ implicitly. This offset has to be calculated in beforehand though, and the only way to achieve that is by doing it in a separate filter which then links to the filter which wants to use it. Here is an example of doing so:

```
tc filter add dev eth0 parent 1:0 protocol ip handle 1: \

        u32 divisor 1
tc filter add dev eth0 parent 1:0 protocol ip \

        u32 ht 1: \

        match tcp src 22 FFFF \

        classid 1:2
tc filter add dev eth0 parent 1:0 protocol ip \

        u32 ht 800: \

        match ip protocol 6 FF \

        match ip firstfrag \

        offset at 0 mask 0f00 shift 6 \

        link 1:
```

This is what is being done: In the first call, a single element sized hash table is created so there is a place to hold the linked to filter and a known handle (1:) to reference to it. The second call then adds the actual filter, which pushes packets with TCP source port 22 into class 1:2. Using ht, it is moved into the hash table created by the first call. The third call then does the actual magic: It matches IPv4 packets with next layer protocol 6 (TCP), only if it's the first fragment (usually TCP sets DF bit, but if it doesn't and the packet is fragmented, only the first one contains the TCP header), and then sets the offset based on the IP header's IHL field (right-shifting by 6 eliminates the offset of the field and at the same time converts the value into byte unit). Finally, using link, the hash table from first call is referenced which holds the filter from second call.

## SEE ALSO
tc(8),

cls_u32.txt at http://linux-tc-notes.sourceforge.net/


tc-vlan

title: tc-vlan(8)

text:
# tc-vlan(8)

## NAME
vlan - vlan manipulation module

## SYNOPSIS

tc ... action vlan { pop | pop_eth | PUSH | MODIFY | PUSH_ETH } [ CONTROL ]

PUSH := push [ protocol VLANPROTO ] [ priority VLANPRIO ] id VLANID

MODIFY := modify [ protocol VLANPROTO ] [ priority VLANPRIO ] id VLANID

PUSH_ETH := push_eth dst_mac LLADDR src_mac LLADDR

CONTROL := { reclassify | pipe | drop | continue | pass | goto chain CHAIN_INDEX }

## DESCRIPTION
The vlan action allows to perform 802.1Q en- or decapsulation on a packet, reflected by the operation modes POP, PUSH and MODIFY. The POP mode is simple, as no further information is required to just drop the outer-most VLAN encapsulation. The PUSH and MODIFY modes require at least a VLANID and allow to optionally choose the VLANPROTO to use.

The vlan action can also be used to add or remove the base Ethernet header. The pop_eth mode, which takes no argument, is used to remove the base Ethernet header. All existing VLANs must have been previously dropped. The opposite operation, adding a base Ethernet header, is done with the push_eth mode. In that case, the packet must have no MAC header (stacking MAC headers is not permitted). This mode is mostly useful when a previous action has encapsulated the whole original frame behind a network header and one needs to prepend an Ethernet header before forwarding the resulting packet.

## OPTIONS
pop

Decapsulation mode, no further arguments allowed.

push

Encapsulation mode. Requires at least id option.

modify

Replace mode. Existing 802.1Q tag is replaced. Requires at least id option.

pop_eth

Ethernet header decapsulation mode. Only works on a plain Ethernet header: VLANs, if any, must be removed first.

push_eth

Ethernet header encapsulation mode. The Ethertype is automatically set using the network header type. Chaining Ethernet headers is not allowed: the packet must have no MAC header when using this mode. Requires the dst_mac and src_mac options.

id VLANID

Specify the VLAN ID to encapsulate into. VLANID is an unsigned 16bit integer, the format is detected automatically (e.g. prefix with '0x' for hexadecimal interpretation, etc.).

protocol VLANPROTO

Choose the VLAN protocol to use. At the time of writing, the kernel accepts only 802.1Q or 802.1ad.

priority VLANPRIO

Choose the VLAN priority to use. Decimal number in range of 0-7.

dst_mac LLADDR

Choose the destination MAC address to use.

src_mac LLADDR

Choose the source MAC address to use.

CONTROL

How to continue after executing this action.

reclassify

Restarts classification by jumping back to the first filter attached to this action's parent.

pipe

Continue with the next action, this is the default.

drop

Packet will be dropped without running further actions.

continue

Continue classification with next filter in line.

pass

Return to calling qdisc for packet processing. This ends the classification process.

## EXAMPLES
The following example encapsulates incoming ICMP packets on eth0 from 10.0.0.2 into VLAN ID 123:

```
#tc qdisc add dev eth0 handle ffff: ingress
#tc filter add dev eth0 parent ffff: pref 11 protocol ip \
	u32 match ip protocol 1 0xff flowid 1:1 \
	    match ip src 10.0.0.2 flowid 1:1 \
	action vlan push id 123
```

Here is an example of the pop function: Incoming VLAN packets on eth0 are decapsulated and the classification process then restarted for the plain packet:

```
#tc qdisc add dev eth0 handle ffff: ingress
#tc filter add dev $ETH parent ffff: pref 1 protocol 802.1Q \
	u32 match u32 0 0 flowid 1:1 \
	action vlan pop reclassify
```

For an example of the pop_eth and push_eth modes, see tc-mpls(8).

## SEE ALSO
tc(8), tc-mpls(8)


tc-xt

title: tc-xt(8)

text:
# tc-xt(8)

## NAME
xt - tc iptables action

## SYNOPSIS

tc ... action xt -j TARGET [ TARGET_OPTS ]

## DESCRIPTION
The xt action allows to call arbitrary iptables targets for packets matching the filter this action is attached to.

## OPTIONS
-j TARGET [ TARGET_OPTS ]

Perform a jump to the given iptables target, optionally passing any target specific options in TARGET_OPTS.

## EXAMPLES
The following will attach a u32 filter to the ingress qdisc matching ICMP replies and using the xt action to make the kernel yell 'PONG' each time:

```
tc qdisc add dev eth0 ingress
tc filter add dev eth0 parent ffff: proto ip u32 \
	match ip protocol 1 0xff \
	match ip icmp_type 0 0xff \
	action xt -j LOG --log-prefix PONG
```

## SEE ALSO
tc(8), tc-u32(8), iptables-extensions(8)


tipc

title: tipc(8)

text:
# tipc(8)

## NAME
tipc - a TIPC configuration and management tool

## SYNOPSIS

tipc [ OPTIONS ] COMMAND ARGUMENTS

COMMAND := { bearer | link | media | nametable | node | socket }

OPTIONS := { -h[help] }

## DESCRIPTION
The Transparent Inter-Process Communication (TIPC) protocol offers total address transparency between processes which allows applications in a clustered computer environment to communicate quickly and reliably with each other, regardless of their location within the cluster.

TIPC originated at the telecommunications manufacturer Ericsson. The first open source version of TIPC was created in 2000 when Ericsson released its first Linux version of TIPC. TIPC was introduced in the mainline Linux kernel in 2006 and is now widely used both within and outside of Ericsson.

## OPTIONS
-h, --help

Show help about last given command. For example tipc bearer --help will show bearer help and tipc --help will show general help. The position of the option in the string is irrelevant.

-j, -json

Output results in JavaScript Object Notation (JSON).

-p, -pretty

The default JSON format is compact and more efficient to parse but hard for most users to read. This flag adds indentation for readability.

## COMMANDS
BEARER

- Show or modify TIPC bearers

LINK

- Show or modify TIPC links

MEDIA

- Show or modify TIPC media

NAMETABLE

- Show TIPC nametable

NODE

- Show or modify TIPC node parameters

SOCKET

- Show TIPC sockets

## ARGUMENTS
Command arguments are described in a command specific man page and typically consists of nested commands along with key value pairs. If no arguments are given a command typically shows its help text. The explicit help option -h or --help can occur anywhere among the arguments and will show help for the last valid command given.

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

## SEE ALSO
tipc-bearer(8), tipc-link(8), tipc-media(8), tipc-nametable(8), tipc-node(8), tipc-peer(8), tipc-socket(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
Richard Alpe <richard.alpe@ericsson.com>


tipc-bearer

title: tipc-bearer(8)

summary: show or modify TIPC bearers

text:
# tipc-bearer(8)

## NAME
tipc-bearer - show or modify TIPC bearers

## SYNOPSIS

tipc bearer add media udp name NAME remoteip REMOTEIP

tipc bearer enable [ domain DOMAIN ] [ priority PRIORITY ] media

{ { eth | ib } device DEVICE } |

{ udp name NAME localip LOCALIP [ localport LOCALPORT ] [ remoteip REMOTEIP ] [ remoteport REMOTEPORT ] }

tipc bearer disable media

{ { eth | ib } device DEVICE } |

{ udp name NAME }

tipc bearer set { priority PRIORITY | tolerance TOLERANCE | window WINDOW } media

{ { eth | ib } device DEVICE } |

{ udp name NAME }

tipc bearer get [ priority | tolerance | window ] media

{ { eth | ib } device DEVICE } |

{ udp name NAME [ localip | localport | remoteip | remoteport ] }

tipc bearer list

## OPTIONS
Options (flags) that can be passed anywhere in the command chain.

-h, --help

Show help about last valid command. For example tipc bearer --help will show bearer help and tipc --help will show general help. The position of the option in the string is irrelevant.

## DESCRIPTION

### Bearer identification
media MEDIA

Specifies the TIPC media type for a particular bearer to operate on. Different media types have different ways of identifying a unique bearer. For example, ib and eth identify a bearer with a DEVICE while udp identify a bearer with a LOCALIP and a NAME ib - Infiniband

eth - Ethernet

udp - User Datagram Protocol (UDP)

name NAME

Logical bearer identifier valid for bearers on udp media.

device DEVICE

Physical bearer device valid for bearers on eth and ib media.

### Bearer properties
domain

The addressing domain (region) in which a bearer will establish links and accept link establish requests.

priority

Default link priority inherited by all links subsequently established over a bearer. A single bearer can only host one link to a particular node. This means the default link priority for a bearer typically affects which bearer to use when communicating with a particular node in an multi bearer setup. For more info about link priority see tipc-link(8)

tolerance

Default link tolerance inherited by all links subsequently established over a bearer. For more info about link tolerance see tipc-link(8)

window

Default link window inherited by all links subsequently established over a bearer. For more info about the link window size see tipc-link(8)

### UDP bearer options
localip LOCALIP

Specify a local IP v4/v6 address for a udp bearer.

localport LOCALPORT

Specify the local port for a udp bearer. The default port 6118 is used if no port is specified.

remoteip REMOTEIP

Specify a remote IP for a udp bearer. If no remote IP is specified a udp bearer runs in multicast mode and tries to auto-discover its neighbours. The multicast IP address is generated based on the TIPC network ID. If a remote IP is specified the udp bearer runs in point-to-point mode. Multiple remoteip addresses can be added via the bearer add command. Adding one or more unicast remoteip addresses to an existing udp bearer puts the bearer in replicast mode where IP multicast is emulated by sending multiple unicast messages to each configured remoteip. When a peer sees a TIPC discovery message from an unknown peer the peer address is automatically added to the remoteip (replicast) list, thus only one side of a link needs to be manually configured. A remoteip address cannot be added to a multicast bearer.

remoteport REMOTEPORT

Specify the remote port for a udp bearer. The default port 6118 is used if no port is specified.

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

## SEE ALSO
tipc(8), tipc-link(8), tipc-media(8), tipc-nametable(8), tipc-node(8), tipc-peer(8), tipc-socket(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
Richard Alpe <richard.alpe@ericsson.com>


tipc-link

title: tipc-link(8)

summary: show links or modify link properties

text:
# tipc-link(8)

## NAME
tipc-link - show links or modify link properties

## SYNOPSIS

tipc link set

[ { priority PRIORITY | tolerance TOLERANCE | window WINDOW } link LINK ] |

[ { broadcast [ BROADCAST | REPLICAST | AUTOSELECT [ ratio SIZE ] ] } ]

tipc link get

[ { priority | tolerance | window } link LINK ] |

[ { broadcast } ]

tipc link statistics { show [ link LINK ] | reset link LINK }

tipc link list

tipc link monitor set { threshold }

tipc link monitor get { threshold }

tipc link monitor summary

tipc link monitor list

[ media { eth | ib } device DEVICE ] |

[ media udp name NAME ]

## OPTIONS
Options (flags) that can be passed anywhere in the command chain.

-h, --help

Show help about last valid command. For example tipc link --help will show link help and tipc --help will show general help. The position of the option in the string is irrelevant.

-j, -json

Output results in JavaScript Object Notation (JSON).

-p, -pretty

The default JSON format is compact and more efficient to parse but hard for most users to read. This flag adds indentation for readability.

## DESCRIPTION

### Link statistics
ACTIVE link state

An ACTIVE link is serving traffic. Two links to the same node can become ACTIVE if they have the same link priority. If there is more than two links with the same priority the additional links will be put in STANDBY state.

STANDBY link state

A STANDBY link has lower link priority than an ACTIVE link. A STANDBY link has control traffic flowing and is ready to take over should the ACTIVE link(s) go down.

MTU

The Maximum Transmission Unit. The two endpoints advertise their default or configured MTU at initial link setup and will agree to use the lower of the two values should they differ.

Packets

The total amount of transmitted or received TIPC packets on a link. Including fragmented and bundled packets.

Fragments

Represented in the form fragments/fragmented. Where fragmented is the amount of data messages which have been broken into fragments. Subsequently the fragments are the total amount of packets that the fragmented messages has been broken into.

Bundles

Represented in the form bundles/bundled. If a link becomes congested the link will attempt to bundle data from small bundled packets into bundles of full MTU size packets before they are transmitted.

Profile

Shows the average packet size in octets/bytes for a sample of packets. It also shows the packet size distribution of the sampled packets in the intervals 0-64 bytes

64-256 bytes

256-1024 bytes

1024-4096 bytes

4096-16384 bytes

16384-32768 bytes

32768-66000 bytes

Message counters

states - Number of link state messages

probes - Link state messages with probe flag set. Typically sent when a link is idle

nacks - Number of negative acknowledgement (NACK) packets sent and received by the link

defs - Number of packets received out of order

dups - Number of duplicate packets received

Congestion link

The number of times an application has tried to send data when the TIPC link was congested

Send queue

Max is the maximum amount of messages that has resided in the out queue during the statistics collection period of a link. Avg is the average outqueue size during the lifetime of a link.

### Link properties
priority

The priority between logical TIPC links to a particular node. Link priority can range from 0 (lowest) to 31 (highest).

tolerance

Link tolerance specifies the maximum time in milliseconds that TIPC will allow a communication problem to exist before taking the link down. The default value is 1500 milliseconds.

window

The link window controls how many unacknowledged messages a link endpoint can have in its transmit queue before TIPC's congestion control mechanism is activated.

### Monitor properties
threshold

The threshold specifies the cluster size exceeding which the link monitoring algorithm will switch from "full-mesh" to "overlapping-ring". If set of 0 the overlapping-ring monitoring is always on and if set to a value larger than anticipated cluster size the overlapping-ring is disabled. The default value is 32.

### Monitor information
table_generation

Represents the event count in a node's local monitoring list. It steps every time something changes in the local monitor list, including changes in the local domain.

cluster_size

Represents the current count of cluster members.

algorithm

The current supervision algorithm used for neighbour monitoring for the bearer. Possible values are full-mesh or overlapping-ring.

status

The node status derived by the local node. Possible status are up or down.

monitored

Represent the type of monitoring chosen by the local node. Possible values are direct or indirect.

generation

Represents the domain generation which is the event count in a node's local domain. Every time something changes (peer add/remove/up/down) the domain generation is stepped and a new version of node record is sent to inform the neighbors about this change. The domain generation helps the receiver of a domain record to know if it should ignore or process the record.

applied_node_status

The node status reported by the peer node for the succeeding peers in the node list. The Node list is a circular list of ascending addresses starting with the local node. Possible status are: U or D. The status U implies up and D down.

[non_applied_node:status]

Represents the nodes and their status as reported by the peer node. These nodes were not applied to the monitoring list for this peer node. They are usually transient and occur during the cluster startup phase or network reconfiguration. Possible status are: U or D. The status U implies up and D down.

### Broadcast properties
BROADCAST

Forces all multicast traffic to be transmitted via broadcast only, irrespective of cluster size and number of destinations.

REPLICAST

Forces all multicast traffic to be transmitted via replicast only, irrespective of cluster size and number of destinations.

AUTOSELECT

Auto switching to broadcast or replicast depending on cluster size and destination node number.

ratio SIZE

Set the AUTOSELECT criteria, percentage of destination nodes vs cluster size.

## EXAMPLES
tipc link monitor list

Shows the link monitoring information for cluster members on device data0.

tipc link monitor summary

The monitor summary command prints the basic attributes.

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

## SEE ALSO
tipc(8), tipc-media(8), tipc-bearer(8), tipc-nametable(8), tipc-node(8), tipc-peer(8), tipc-socket(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
Richard Alpe <richard.alpe@ericsson.com>


tipc-media

title: tipc-media(8)

summary: list or modify media properties

text:
# tipc-media(8)

## NAME
tipc-media - list or modify media properties

## SYNOPSIS

tipc media set { priority PRIORITY | tolerance TOLERANCE | window WINDOW } media MEDIA

tipc media get { priority | tolerance | window } media MEDIA

tipc media list

## OPTIONS
Options (flags) that can be passed anywhere in the command chain.

-h, --help

Show help about last valid command. For example tipc media --help will show media help and tipc --help will show general help. The position of the option in the string is irrelevant.

## DESCRIPTION

### Media properties
priority

Default link priority inherited by all bearers subsequently enabled on a media. For more info about link priority see tipc-link(8)

tolerance

Default link tolerance inherited by all bearers subsequently enabled on a media. For more info about link tolerance see tipc-link(8)

window

Default link window inherited by all bearers subsequently enabled on a media. For more info about link window see tipc-link(8)

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

## SEE ALSO
tipc(8), tipc-bearer(8), tipc-link(8), tipc-nametable(8), tipc-node(8), tipc-peer(8), tipc-socket(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
Richard Alpe <richard.alpe@ericsson.com>


tipc-nametable

title: tipc-nametable(8)

summary: show TIPC nametable

text:
# tipc-nametable(8)

## NAME
tipc-nametable - show TIPC nametable

## SYNOPSIS

tipc nametable show

## OPTIONS
Options (flags) that can be passed anywhere in the command chain.

-h, --help

-j, -json

Output results in JavaScript Object Notation (JSON).

-p, -pretty

The default JSON format is compact and more efficient to parse but hard for most users to read. This flag adds indentation for readability. Show help about last valid command. For example tipc nametable --help will show nametable help and tipc --help will show general help. The position of the option in the string is irrelevant.

## DESCRIPTION
The nametable shows TIPC publication information.

### Nametable format
Type

The 32-bit type field of the port name. The type field often indicates the class of service provided by a port.

Lower

The lower bound of the 32-bit instance field of the port name. The instance field is often used as as a sub-class indicator.

Upper

The upper bound of the 32-bit instance field of the port name. The instance field is often used as as a sub-class indicator. A difference in lower and upper means the socket is bound to the port name range [lower,upper]

Port Identity

The unique socket (port) identifier within the TIPC cluster. The port identity consists of a node identity followed by a socket reference number.

Publication

The publication ID is a random number used internally to represent a publication.

Scope

The publication scope specifies the visibility of a bound port name. The scope can be specified to comprise three different domains: node, cluster and zone. Applications residing within the specified scope can see and access the port using the displayed port name.

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

## SEE ALSO
tipc(8), tipc-bearer(8), tipc-link(8), tipc-media(8), tipc-node(8), tipc-peer(8), tipc-socket(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
Richard Alpe <richard.alpe@ericsson.com>


tipc-node

title: tipc-node(8)

text:
# tipc-node(8)

## NAME
tipc-node - modify and show local node parameters or list peer nodes

## SYNOPSIS

tipc node set { address ADDRESS | netid NETID }

tipc node get { address | netid }

tipc node list

## OPTIONS
Options (flags) that can be passed anywhere in the command chain.

-h, --help

Show help about last valid command. For example tipc node --help will show node help and tipc --help will show general help. The position of the option in the string is irrelevant.

## DESCRIPTION

### Node parameters
address

The TIPC logical address. On the form x.y.z where x, y and z are unsigned integers.

netid

Network identity. Can by used to create individual TIPC clusters on the same media.

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

## SEE ALSO
tipc(8), tipc-bearer(8), tipc-link(8), tipc-media(8), tipc-nametable(8), tipc-peer(8), tipc-socket(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
Richard Alpe <richard.alpe@ericsson.com>


tipc-peer

title: tipc-peer(8)

summary: modify peer information

text:
# tipc-peer(8)

## NAME
tipc-peer - modify peer information

## SYNOPSIS

tipc peer remove address ADDRESS

## OPTIONS
Options (flags) that can be passed anywhere in the command chain.

-h, --help

Show help about last valid command. For example tipc peer --help will show peer help and tipc --help will show general help. The position of the option in the string is irrelevant.

## DESCRIPTION

### Peer remove
Remove an offline peer node from the local data structures. The peer is identified by its address

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

## SEE ALSO
tipc(8), tipc-bearer(8), tipc-link(8), tipc-media(8), tipc-nametable(8), tipc-node(8), tipc-socket(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
Richard Alpe <richard.alpe@ericsson.com>


tipc-socket

title: tipc-socket(8)

summary: show TIPC socket (port) information

text:
# tipc-socket(8)

## NAME
tipc-socket - show TIPC socket (port) information

## SYNOPSIS

tipc socket list

## OPTIONS
Options (flags) that can be passed anywhere in the command chain.

-h, --help

Show help about last valid command. For example tipc socket --help will show socket help and tipc --help will show general help. The position of the option in the string is irrelevant.

## DESCRIPTION
A TIPC socket is represented by an unsigned integer.

### Bound state
A bound socket has a logical TIPC port name associated with it.

### Connected state
A connected socket is directly connected to another socket creating a point to point connection between TIPC sockets. If the connection to X was made using a logical port name Y that name will show up as connected to X via Y

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

## SEE ALSO
tipc(8), tipc-bearer(8) tipc-link(8), tipc-media(8), tipc-nametable(8), tipc-node(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
Richard Alpe <richard.alpe@ericsson.com>


vdpa

title: vdpa(8)

summary: vdpa management tool

text:
# vdpa(8)

## NAME
vdpa - vdpa management tool

## SYNOPSIS

vdpa [ OPTIONS ] { dev|mgmtdev } { COMMAND | help }

## OPTIONS
-V, --Version

Print the version of the vdpa utility and exit.

-j, --json

Generate JSON output.

-p, --pretty

When combined with -j generate a pretty JSON output.

### OBJECT
dev

- vdpa device.

mgmtdev

- vdpa management device.

### COMMAND
Specifies the action to perform on the object. The set of possible actions depends on the object type. It is possible to show (or list ) objects. 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 show or, if the objects of this class cannot be listed, help.

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

## SEE ALSO
vdpa-dev(8), vdpa-mgmtdev(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
Parav Pandit <parav@nvidia.com>


vdpa-dev

title: vdpa-dev(8)

summary: vdpa device configuration

text:
# vdpa-dev(8)

## NAME
vdpa-dev - vdpa device configuration

## SYNOPSIS

vdpa dev [ OPTIONS ] { COMMAND| help }

OPTIONS := { -V[ersion] }

vdpa dev show [ DEV ]

vdpa dev help

vdpa dev add name NAME mgmtdev MGMTDEV

vdpa dev del DEV

## DESCRIPTION

### vdpa dev show - display vdpa device attributes
DEV - specifies the vdpa device to show. If this argument is omitted all devices are listed.

Format is:

VDPA_DEVICE_NAME

### vdpa dev add - add a new vdpa device.
name NAME

Name of the new vdpa device to add.

mgmtdev MGMTDEV

Name of the management device to use for device addition.

### vdpa dev del - Delete the vdpa device.
DEV - specifies the vdpa device to delete.

## EXAMPLES
vdpa dev show

Shows the all vdpa devices on the system.

vdpa dev show foo

Shows the specified vdpa device.

vdpa dev add name foo mgmtdev vdpa_sim_net

Add the vdpa device named foo on the management device vdpa_sim_net.

vdpa dev del foo

Delete the vdpa device named foo which was previously created.

## SEE ALSO
vdpa(8), vdpa-mgmtdev(8),

## AUTHOR
Parav Pandit <parav@nvidia.com>


vdpa-mgmtdev

title: vdpa-mgmtdev(8)

summary: vdpa management device view

text:
# vdpa-mgmtdev(8)

## NAME
vdpa-dev - vdpa management device view

## SYNOPSIS

vdpa mgmtdev { COMMAND| help }

OPTIONS := { -V[ersion] }

vdpa mgmtdev show [ MGMTDEV ]

vdpa mgmtdev help

## DESCRIPTION

### vdpa mgmtdev show - display vdpa management device attributes
MGMTDEV - specifies the vdpa management device to show. If this argument is omitted all management devices are listed.

## EXAMPLES
vdpa mgmtdev show

Shows all the vdpa management devices on the system.

vdpa mgmtdev show bar

Shows the specified vdpa management device.

## SEE ALSO
vdpa(8), vdpa-dev(8),

## AUTHOR
Parav Pandit <parav@nvidia.com>