VPP/Command-line Interface (CLI) Guide

From fd.io
< VPP
Revision as of 21:23, 17 November 2017 by Jdenisco (Talk | contribs)

Jump to: navigation, search

Introduction

The vpp network stack comes equipped with a set of commands that are useful for debugging.

The easiest way to access the CLI (with proper permissions) is to use the vppctl command:

sudo vppctl <cli command>

The CLI parser matches static keyword strings, eventually invoking an action function. Unambiguous partial keyword matching always occurs. The action functions consume input until satisfied or until they fail. This model makes for easy coding, but does not guarantee useful "help" output. It's up to the CLI command writer to add useful help strings.

You can find the source code of CLI commands by searching for instances of the VLIB_CLI_COMMAND macro in the code source files.

Please help maintain and improve this document to make and keep these commands clear and useful!


Debug and Telnet CLI

The debug CLI is enabled with the unix interactive parameter or startup configuration option. This causes VPP to start without daemonizing and presents a command line interface on the terminal where it is run.

The Telnet CLI is enabled with the cli-listen localhost:5002 option which will cause VPP to listen for TCP connections on the localhost address port 5002. A Telnet client can then connect to this port (for example, telnet localhost 5002) and will receive a command line prompt.

This configuration will enable both mechanisms:

unix {
  interactive
  cli-listen localhost:5002
}

The debug CLI can operate in line mode, which may be useful when running inside an IDE like Emacs. This is enabled with the option unix cli-line-mode. Several other options exist that alter how this CLI works, see VPP/Command-line_Arguments for details.

The CLI starts with a banner graphic (which can be disabled) and a prompt. The prompt will typically read "vpp" for a release version of VPP and "DBGvpp# for a development version with debugging enabled, for example:

    _______    _        _   _____  ___ 
 __/ __/ _ \  (_)__    | | / / _ \/ _ \
 _/ _// // / / / _ \   | |/ / ___/ ___/
 /_/ /____(_)_/\___/   |___/_/  /_/    

vpp# 

versus:

    _______    _        _   _____  ___ 
 __/ __/ _ \  (_)__    | | / / _ \/ _ \
 _/ _// // / / / _ \   | |/ / ___/ ___/
 /_/ /____(_)_/\___/   |___/_/  /_/    

DBGvpp# 

This prompt can be configured with the unix cli-prompt setting and the banner disabled with unix cli-no-banner.

CLI features

The CLI has several editing features that make it easy to use.

  • Cursor keys left/right will move the cursor within a command line; typing will insert at the cursor; erase will erase at the cursor.
  • Ctrl-left/right will search for the start of the next word to the left or right.
  • Home/end will jump the cursor to the start and end of the line.
  • Cursor keys up/down and ^P/^N iterate through the command history buffer. Lines from the history buffer may be edited. New commands are added to the end of the buffer when executed; though duplicates of the previous command are not added.
  • ^U erases the line contents from the left of the cursor to the start. ^K erases the contents from the cursor to the end.
  • ^R will search the command history forwards or in reverse for a command; start typing for matches to auto complete.
  • ^L will clear the screen and repaint the prompt and any current line. The cursor position is also retained.
  • The CLI can be closed with the exit command. Alternatively, ^D on an empty input line will also close the session.
  • Closing the debug session will also shutdown VPP.

Output that exceeds the length of a terminal page will be buffered, up to a limit.

  • Space or page-down displays the next page.
  • Enter or down-arrow displays the next line.
  • Page-up goes back a page.
  • Up-arrow goes up a line.
  • Home/end jump to the start/end of the buffered output.
  • The key q quits the pager. Space and enter will also quit the pager if the end of the buffer has been reached.

Interface Commands

show interface

To display interface names and rx/tx packet/byte and drop counters, use "show interface":

vpp# show interface
             Name                    State          Counter          Count     
GigabitEthernet2/0/0                   up       rx packets                  1801
                                                rx bytes                  179560
                                                tx packets                   343
                                                tx bytes                   88050
                                                drops                       1459
GigabitEthernet2/2/0                   up       rx packets                  7875
                                                rx bytes                  740694
                                                tx packets                   228
                                                tx bytes                   78888
                                                drops                       7647
GigabitEthernet2/3/0                  down      
GigabitEthernet2/4/0                  down      
local0                                down      
pg/stream-0                           down      
pg/stream-1                           down      
pg/stream-2                           down      
pg/stream-3                           down      
tuntap-0                               up

On x86_64 hardware, interface names derive directly from PCI bus, id, and function. Local0 and the packet generator streams are "special" and should not be configured directly. When running in "punt/inject mode" tuntap-0 is "special" and should not be configured directly.

show interface address

To display interface addresses and up/down state:

vpp# show int address
GigabitEthernet0/8/0 (up):
  172.28.128.5/24
local0 (dn):
pg/stream-0 (dn):
pg/stream-1 (dn):
pg/stream-2 (dn):
pg/stream-3 (dn):

show hardware

show hardware-interfaces

clear interface

clear interface

set interface

set interface

show interface

show interface

create vlan subinterface

moved to doxygen

set interface ip

set interface ip moved to doxygen

set interface ip addr

set interface ip addr

set interface ip table

set interface ip table

Routing table commands

ip route add/del

ip route add/del

ip route add/del (multiple)

moved to doxygen

ip route add/del (multipath)

moved to doxygen


show ip fib / show ip6 fib

moved to doxygen

Manipulating the ARP cache

moved to doxygen

Proxy ARP

moxed to doxygen

dhcp proxy

To configure dhcp proxy, configure as follows:

vpp# set dhcp proxy server 6.0.0.1

As of this writing, we support one DHCP server.

dhcp proxy option 82 (circuit-ID)

If configured as follows, the vpp dhcp proxy implementation will add the client-facing interface FIB number as a DHCP option 82 circuit-ID. Furthermore, the code sets suboption 5 to the first ip4 address provisioned on the client-facing interface.

 vpp# set dhcp proxy server 6.0.0.1 add-option-82

If necessary, one can configure the suboption-5-provided ip4 addresses manually; on a per-interface basis:

 vpp# set dhcp option-82 address [delete] <interface> <ip4-address>

To inspect the suboption-5 interface→ip4 address table, use:

 vpp# show dhcp option-82 addresses

provisioning martian addresses

If you intend to use the dhcp relay feature, you'll need to explicitly provision the ip4 L3 martian addresses 255.255.255.255 and 0.0.0.0:

vpp# ip route add 255.255.255.255/32 via local
vpp# ip route add 0.0.0.0/32 via local

set ip6 neighbor

To statically configure an ip6 neighbor adjacency, use the "set ip6 neighbor" command:

vpp# set ip6 neighbor [del] <intfc> <ip6-address> <mac-address>

This command is especially useful for example when adding an ip6 default route, since neither the ip4 nor ip6 FIB has the concept of a glean adjacency.

show ip6 neighbors

To display the vpp platform's idea of adjacent ipv6 hosts found via neighbor discovery:

vpp# show ip6 neighbors

enable/disable source RPF checking on an interface

vpp# set interface ip source-check GigabitEthernet2/0/0
vpp# set interface ip source-check GigabitEthernet2/0/0 del

Source RPF checking is on by default.

ip probe

The ip probe command ARPs for ip4 addresses or attempts ip6 neighbor discovery depending on the supplied ip address format.

 vpp# ip probe <interface> <ip-address>

Note that this command will not immediately affect the indicated FIB; it is not suitable for use in establishing a FIB entry prior to adding recursive FIB entries. As in: don't use it in a script to probe a gateway prior to adding a default route. It won't work. Instead, configure a static ARP cache entry [see set ip arp], or a static ip6 neighbor [see set ip6 neighbor].

Layer 2 commands

The Vector Packet Engine (VPE) natively includes a small set of layer2 features.

Interface mode commands

moved to doxygen

l2fib commands

The mac forwarding table for bridge-domains is called the l2fib. Entries are added automatically as part of mac learning, but you can also add entries manually.

The following command associates the mac address in bridge domain 0 with GigabitEthernet2/0/0. (Note that the interface should be configured to be the specified bridge-domain but this is not enforced):

vpp# l2fib add 00:11:22:33:44:55 0 GigabitEthernet2/0/0

You can also create static mac entries. These cannot be overridden by mac learning.

vpp# l2fib add 00:11:22:33:44:55 0 GigabitEthernet2/0/0 static

You can drop packets with "bad" mac addresses by creating filter entries. If a packet's source mac or destination mac matches a filtered entry, the packet is dropped:

vpp# l2fib add 00:11:22:33:44:55 0 filter

You can also create entries that point to BVI interfaces. See the BVI section for more information.

vpp# l2fib add 00:11:22:33:44:55 0 loop0 bvi

You can delete specific l2fib entries using:

vpp# l2fib del 00:11:22:33:44:55 0 

You can delete all l2fib entries using:

vpp# clear l2fib

You can display the contents of the l2fib using:

vpp# show l2fib
   Mac Address     BD ID            Interface           Index  static  filter  bvi  refresh  timestamp 
00:02:04:06:08:0a    0        GigabitEthernet2/1/0        6       0       0     0      0         0     
00:22:44:06:08:0a    0       GigabitEthernet2/2/0.1       9       0       0     0      0         0

bridge-domain commands

You can display the list of all bridge-domains that are in use:

vpp# show bridge-domain
 ID     Learning      Forwarding      Flooding             BVI Interface        
 0       enabled        enabled        enabled                  N/A             
 2       enabled        enabled        enabled                  N/A             

You can display information on a single bridge-domain:

vpp# show bridge-domain 0
 ID     Learning      Forwarding      Flooding             BVI Interface        
 0       enabled        enabled        enabled                  N/A             

You can also display detailed information (basically the member list) on a single bridge-domain:

vpp# show bridge-domain 0 detail
 ID     Learning      Forwarding      Flooding             BVI Interface        
 0       enabled        enabled        enabled                  N/A             

          Interface             Id   BVI 
    GigabitEthernet2/1/0        6    no  
   GigabitEthernet2/2/0.1       9    no  

enable/disable learning, forwarding, and flooding

MAC learning, unicast forwarding, and flooding can be enabled and disabled independently on each interface and on each bridge-domain. By default these are enabled.

To disable learning on an interface use:

vpp# set interface l2 learn GigabitEthernet2/0/0 disable

To re-enable it use:

vpp# set interface l2 learn GigabitEthernet2/0/0

Similarly, unicast forwarding and flooding can be disabled:

vpp# set interface l2 forward GigabitEthernet2/0/0 disable
vpp# set interface l2 flood GigabitEthernet2/0/0 disable

These three features can also be disabled at the bridge-domain level. To disable learning on all interfaces in bridge-domain 2, use:

vpp# set bridge-domain learn 2 disable

VLAN Tag Rewrite

VLAN tag rewrite provides the ability to change the VLAN tags on a packet. Existing tags can be popped, new tags can be pushed, and existing tags can be swapped with new tags. The rewrite feature is attached to a subinterface as input and output operations. The input operation is explicitly configured. The output operation the symmetric opposite and is automatically derived from the input operation.

By default a subinterface has no tag-rewrite. To return a subinterface to this state use:

vpp# set interface tag-rewrite GigabitEthernet2/0/0.1 disable

To pop vlan tags off packets received from a subinterface, use:

vpp# set interface tag-rewrite GigabitEthernet2/0/0.1 pop 1
vpp# set interface tag-rewrite GigabitEthernet2/0/0.1 pop 2

The subinterface encapsulation (the vlan tags specified when it was created) must have at least the number of popped tags. e.g. the "pop 2" operation would be rejected on a single-vlan interface. The output tag-rewrite operation for pops is to push the specified number of vlan tags onto the packet. The pushed tag values are the ones in the subinterface encapsulation.

To push one or two vlan tags onto packets received from an interface, use:

vpp# set interface tag-rewrite GigabitEthernet2/0/0.1 push dot1q 100
vpp# set interface tag-rewrite GigabitEthernet2/0/0.1 push dot1ad 100 200

The push operation also specifies the ethertype. The output tag-rewrite operation for pushes is to pop the same number of tags off the packet. If the packet doesn't have enough tags it is dropped.

Tags can also be translated, which is basically a combination of a pop and push.

vpp# set interface tag-rewrite GigabitEthernet2/0/0.1 translate 1-1 dot1ad 100
vpp# set interface tag-rewrite GigabitEthernet2/0/0.1 translate 2-2 dot1ad 100 200
vpp# set interface tag-rewrite GigabitEthernet2/0/0.1 translate 1-2 dot1q 100 200
vpp# set interface tag-rewrite GigabitEthernet2/0/0.1 translate 2-1 dot1q 100

EFP Filter Check

It is possible to transmit a packet out a subinterface with vlan tags that are not compatible with that subinterface. In other words, if that packet arrived on the output port, it would not be classified as coming from the output subinterface. This can happen in various ways: through misconfiguration, by putting subinterfaces with different vlan encaps in the same bridge-domain, etc. The EFP Filter Check detects such packets and drops them. It consists of two checks, one that verifies the packet prior to output vlan tag rewrite and one that verifies the packet after vlan tag rewrite.

You can enable the EFP filter check using:

vpp# set interface efp-filter GigabitEthernet2/0/0.1

The EFP Filter check is disabled by default. You can disable it again by using:

vpp# set interface efp-filter GigabitEthernet2/0/0.1 disable

IRB/BVI

Integrated Routing and Bridging (IRB) emulates a switch connected to a router port using an internal virtual interface called a Bridged Virtual Interface (BVI). The BVI connects an L3 vrf to an L2 bridge-domain. When an L3 packet is routed to the BVI, an L2 encapsulation is added to the packet as is done normally. But instead of being transmitted out a physical interface, the packet is forwarded in the bridge-domain associated with the BVI. The packet could be unicast or flooded to all interfaces in the bridge-domain. In the other direction, an L2 packet could be forwarded to a BVI interface. This could happen via a BVI entry in the l2fib or via flooding in a bridge-domain that includes a BVI interface. The packet is then routed in the vrf associated with the BVI.

A bridge-domain can be associated with only one BVI. However a vrf can contain routes to multiple BVIs.

To configure a BVI interface, create it using a loopback interface, assign a mac address, and set its vrf and bridge-domain. This example uses vrf 0 and bridge-domain 5. Learning should be disabled on the BVI interface. It is harmless but useless to enable it because the BVI l2fib entry is static:

vpp# loop create 0000.0B51.0001
vpp# set int l2 bridge loop0 5 bvi
vpp# set int ip table loop0 0
vpp# set int l2 learn loop0 disable
vpp# set int state loop0 up

Add L3 connectivity by creating a route and adjacency for the BVI interface. The static ARP is not strictly necessary -- routing to an IP with an unknown mac will cause an ARP request to be generated.

vpp# ip route table 0 8.0.1.0/24 via loop0
vpp# set ip arp loop0 8.0.1.1 00:02:04:06:08:0a

Verify the BVI configuration:

vpp# show l2fib
    Mac Address     BD ID            Interface           Index  static  filter  bvi  refresh  timestamp 
 00:00:0b:51:00:01    5                loop0               9       1       0     1      0         0     
vpp# show bridge-domain
  ID     Learning      Forwarding      Flooding             BVI Interface        
  5       enabled        enabled        enabled                 loop0            
vpp# show ip fib
Table 0, flow hash: src dst sport dport proto 
     Destination         Packets          Bytes         Adjacency   
8.0.1.0/24                         0               0 weight 1, index 3
                                                     loop0
8.0.1.1/32                         0               0 weight 1, index 4
                                                     loop0
                                                     00020406080a00000b5100010800

Tunnel encapsulations

GRE tunnels

To create a GRE tunnel:

vpp# create gre tunnel src <addr> dst <addr> [outer-fib-id <fib-id>]

This creates a GRE tunnel whose outer IP header will have the indicated source and destination IP addresses. The tunnel manifests itself as a greX interface. Interface address can be set with "set interface address" command. GRE Encapsulated packets can be sent/received in non-zero FIB by specifying optional keyword outer-fib-id.

MPLS-in-GRE tunnels

To create an MPLS-in-GRE tunnel, first create the required encap and decap label mappings:

vpp# mpls decap [add|delete] label <label> fib <id>
vpp# mpls encap [add|delete] label <label> fib <id> dest <ip4-address>

Next, create the tunnel itself.

vpp# create mpls gre tunnel src <addr> dst <addr> intfc <addr>

Tunnel creation will fail if no encap label exists for the "intfc <addr>"

The dataplane expects to find a single MPLS label after the outer-IP header. The label value is translated through the MPLS decap table; the indicated FIB tables are used to route the decapsulated inner IP header.

To display the encap and decap label tables, use:

vpp# show mpls fib

To display the set of MPLS tunnels, use:

vpp# show mpls tunnel

L2tpv3-in-ip6 tunnels

To create an l2tpv3-in-ip6←→L2 VLAN tunnel, use the "create l2tpv3 tunnel" command. All parameters are specified on a single input line (of arbitrary length):

vpp# create l2tpv3 tunnel client <ip6-addr> our <ip6-addr>
      [local-cookie <%llx>] [remote-cookie <%llx>] 
      [local-session-id <dec-num>] [remote-session-id <dec-num>]
      [l2-sublayer-present]

The created tunnel appears as a virtual interface which needs to be associated with a bridge-domain and then set up.

vpp# set interface l2 bridge l2tpv3_tunnel0 <bridge-domain-id>
vpp# set interface state l2tpv3_tunnel0 up

Local-cookie and remote-cookie default to FFFFFFFFFFFFFFFF. Local-session-id and remote-session-id default to 1.

When interoperating with the current Linux l2tpv3-in-v6 implementation, you'll need to specify the l2-sublayer-present property. Conversely, when interoperating with IOS-XR, do not specify l2-sublayer-present. Since the l2 sublayer is used to transport sequence information -- not present in static l2tpv3 softwires -- it seems that the Linux implementation is incorrect.

In the tunnel-to-l2-interface direction, decapsulation must be explicitly enabled on the input interface:

vpp# set interface ip6 l2tpv3 GigabitEthernet2/1/0 

This can be deconfigured as well:

vpp# set interface ip6 l2tpv3 GigabitEthernet2/1/0 del

The vpp stack strips the ip6 and tunnel encaps and tracks down the inner l2 header. Vlan tags can be inserted using subinterface VLAN tag-rewrite commands (see above).

The session lookup key is configurable on the vpp command line. For example:

 # <vpp-app-full-path> unix interactive l2tp [lookup-v6-src | lookup-v6-dst | lookup-session-id]

The vpp stack defaults to "lookup-v6-dst."

In the l2-interface-to-tunnel direction, the vpp stack uses the l2 subinterface as the session lookup key.

Interoperation with the latest Linux kernel / network stack l2tpv3-in-ip6 implementation has been demonstrated.

L2TP Cookie Rollover Commands

Configure L2TPv3 Rollover cookie"

vpp# set l2tpv3 tunnel cookie <interface> [local <64bit hex value>] [remote <64bit hex value>]
  • if the local cookie value is specified, both the existing cookie value and the specified rollover value will be accepted.
  • if the remote cookie value is specified, it will immediately replace the existing remote cookie value.
P2# sh l2tpv3 verbose
1 l2tp sessions...
L2tp session lookup on dst address
[0] 2003:123a:40:11::11 (our) 2003:132a:40:11::1 (client) l2tpv3_tunnel0 (sw_if_index 9)
   local cookies 1111111111111111 0000000000000000 remote cookie 1111111111111111
   local session-id -1 remote session-id -1
   l2 specific sublayer absent
   user-to-net: 20472964 pkts 1944931580 bytes

Infrastructure Commands

statistic and error counters

The vpp stack maintains many useful statistic and error counters. To display them:

 vpp# show error
     Count                       Node                          Error       
           8077                arp-input               IP4 destination address not local to subnet
              1                arp-input               ARP replies received
            126                arp-input               Proxy ARP replies sent
              1                 ip4-arp                ARP requests sent
           1230                ip4-input               ip4 ttl <= 1
            667                ip4-input               ip4 source lookup miss
              3                ip6-input               ip6 destination lookup miss
            253          dhcp-proxy-to-server          DHCP packets relayed to the server
            252          dhcp-proxy-to-server          DHCP packets relayed to clients
              1             ip6-icmp-input             neighbor solicitations for unknown targets

To understand the precise meaning of a statistic, start with the vlib graph node name (the "Node" column above), find the graph node definition, and finally "Use the Force and Read the Source."

To clear the statistic and error counters:

vpp# clear error

graph runtime statistics

vpp# sh run
Time 75110.5, average vectors/node 1.00, last 128 main loops 0.00 per node 0.00
  vector rates in 1.4224e-1, out 8.4009e-3, drop 1.3386e-1, punt 0.0000e0
            Name                State     Vectors        Suspends         Clocks      
GigabitEthernet2/0/0-outpu      active             379               0          1.71e4 
GigabitEthernet2/0/0-tx         active             379               0          7.65e4 
GigabitEthernet2/2/0-outpu      active             252               0          1.65e4 
GigabitEthernet2/2/0-tx         active             252               0          6.48e4 
arp-input                       active            8262               0          6.97e4 
dhcp-proxy-to-client            active             252               0          4.18e4 
dhcp-proxy-to-server            active             505               0          2.49e4 
error-drop                      active           10054               0          3.08e4 
ethernet-input                  active            8262               0          5.29e4 
icmp6-neighbor-solicitatio      active               2               0          5.69e4 
ige-input                    interrupt w         10684               0          1.41e5 
ige-process                    any wait              0            2505          0.00e0 
ip4-arp                         active               1               0          4.98e5 
ip4-input-no-checksum           active            2414               0          8.51e4 
ip4-local                       active            1177               0          5.66e4 
ip4-lookup                      active            1430               0          2.96e4 
ip4-rewrite-transit             active             252               0          3.32e4 
ip6-icmp-input                  active               2               0          1.92e4 
ip6-input                       active               8               0          3.64e4 
ip6-local                       active               2               0          1.64e4 
ip6-lookup                      active               8               0          3.54e4 
ip6-miss                        active               6               0          4.69e4 
udp-input                       active             505               0          2.43e4 
unix-cli-stdin                  active               0              15          0.00e0 
unix-epoll-input                polling              0               0          2.95e7 

[note: output from a debug image processing 0.1 PPS, the per-node runtime statistics are not worth the paper they're not printed on...]

packet tracer

The packet tracer is your friend. If the vpp stack is dropping traffic, turn on the packet tracer to see why.

First, identify the input node from which the traffic originates. (See also the command show run.)

For most cases, we see that traffic originates from "dpdk-input" which is the dpdk driver rx graph node. Another choice is "pg-input" for packets from the built-in packet generator.

vpp# trace add dpdk-input 1

To display the traced packets:

vpp# show trace
Packet 1
00:00:56:143358: dpdk-input
 GigabitEthernet2/0/0 rx queue 0
 before: sw-owned, length this descriptor 102, end-of-packet
         ip4 checksum ok, tcp checksum ok
 buffer 0x3180: current data 14, length 88, free-list 14, trace 0x4
 IP4: 00:50:56:b7:7c:8f -> 00:50:56:b7:7c:83
 ICMP: 6.0.0.1 -> 6.0.0.2
   tos 0x00, ttl 64, length 84, checksum 0x2ea7
   fragment id 0x0000, flags DONT_FRAGMENT
 ICMP echo_request checksum 0x66d6
00:00:56:143400: ip4-input-no-checksum
 ICMP: 6.0.0.1 -> 6.0.0.2
   tos 0x00, ttl 64, length 84, checksum 0x2ea7
   fragment id 0x0000, flags DONT_FRAGMENT
 ICMP echo_request checksum 0x66d6
00:00:56:143427: ip4-local
 adjacency: local 6.0.0.2/24
00:00:56:143434: ip4-icmp-input
 ICMP: 6.0.0.1 -> 6.0.0.2
   tos 0x00, ttl 64, length 84, checksum 0x2ea7
   fragment id 0x0000, flags DONT_FRAGMENT
 ICMP echo_request checksum 0x66d6
00:00:56:143437: ip4-icmp-echo-request
 ICMP: 6.0.0.1 -> 6.0.0.2
   tos 0x00, ttl 64, length 84, checksum 0x2ea7
   fragment id 0x0000, flags DONT_FRAGMENT
 ICMP echo_request checksum 0x66d6
00:00:56:143444: ip4-rewrite-local
 adjacency: GigabitEthernet2/0/0
            IP4: 00:50:56:b7:7c:83 -> 00:50:56:b7:7c:8f
 IP4: 00:50:56:b7:7c:83 -> 00:50:56:b7:7c:8f
 ICMP: 6.0.0.2 -> 6.0.0.1
   tos 0x00, ttl 64, length 84, checksum 0xa226
   fragment id 0x8c80, flags DONT_FRAGMENT
 ICMP echo_reply checksum 0x6ed6
00:00:56:143447: GigabitEthernet2/0/0-output
 GigabitEthernet2/0/0
 IP4: 00:50:56:b7:7c:83 -> 00:50:56:b7:7c:8f
 ICMP: 6.0.0.2 -> 6.0.0.1
   tos 0x00, ttl 64, length 84, checksum 0xa226
   fragment id 0x8c80, flags DONT_FRAGMENT
 ICMP echo_reply checksum 0x6ed6
00:00:56:143450: GigabitEthernet2/0/0-tx
 GigabitEthernet2/0/0 tx queue 0
 descriptor: buffer 0x100c03200, 102 bytes this buffer
             eop, insert-fcs, 
 buffer 0x3180: current data 0, length 102, free-list 14, trace 0x4
 IP4: 00:50:56:b7:7c:83 -> 00:50:56:b7:7c:8f
 ICMP: 6.0.0.2 -> 6.0.0.1
   tos 0x00, ttl 64, length 84, checksum 0xa226
   fragment id 0x8c80, flags DONT_FRAGMENT
 ICMP echo_reply checksum 0x6ed6

Each graph node can contribute to the per-packet trace.

To clear the packet trace buffer, use "clear trace"

vpp# clear trace

command scripts

The "exec" command feeds the contents of a file to the parser:

vpp# exec /tmp/commands

Erroneous commands will result in complaints on stderr. Processing will continue.

API trace and client commands

If you've enabled API message tracing, you can save the current trace buffer to /tmp/<filename>, as follows:

vpp# api trace save <filename>

In more detail, the API trace command has the following syntax:

api trace [on|off][dump|save|replay <file>][status][free][post-mortem-on][post-mortem-off]

If API tracing is enabled and the vpp engine crashes, it makes every effort to save the current API trace to /tmp/api_post_mortem.<pid>. Enable API tracing from the beginning of time via this command line argument.

If misbehavior of the vpp engine control-plane APIs is suspected, please include a full API trace with the report. Given a reasonably similar image, we can reproduce complex multi-step issues in a few seconds.

To display the current set of connected API clients, use:

vpp# show api clients

To display statistics for the fast API message ring allocator, use:

vpp# show api ring-stats

NB the "ring miss fallback allocation" counter. If it's going through the roof, something is wrong.

connect to a tap device

To connect to a Linux "tap" device, use the "tap connect" CLI command:

vpp# tap connect <linux-tap-intfc-name> [hwaddr [<eth-addr> | random]]

Specify <eth-addr> in "xx:xx:xx:xx:xx:xx" or "xxyy.xxyy.xxyy" format. "Random" MAC addresses use the current time to seed a known-good 32-bit LCRN. Caveat emptor.

By default, the hwaddr matches the Linux device. This can easily cause confusion when placing the tap device into a Linux virtual bridge.

Display software version stamps

VPP software version stamps can be displayed using the show version CLI:

vpp# show version
vpp v1.0.0-63~g1bc56f7 built by loj on jl-cluster-1 at Sat Jan  9 15:42:51 EST 2016
vpp# show version verbose
vpp v1.0.0-63~g1bc56f7 built by loj on jl-cluster-1 at Sat Jan  9 15:42:51 EST 2016
Built in /scratch/loj/test/vpp
Compiled with GCC 4.8.4
DPDK version is RTE 2.1.0

Inline IPv6 OAM Commands

Configure ioam trace fields

vpp # set ioam rewrite trace-type <0x1f|0x3|0x9|0x11|0x19> trace-elts <nn> trace-tsp <0|1|2|3> node-id <node id in hex> app-data <app_data in hex> 

Valid values for trace-type are 0x1f, 0x03, 0x09, 0x11 and 0x19. Following list provides corresponding trace elements included in hop-by-hop header:

0x1f : Hoplimit, node_id, ingress_if_id, egress_if_id, timestamp and app_data
0x03 : Hoplimit, node_id, ingress_if_id and egress_if_id
0x09 : Hoplimit, node_id  and timestamp
0x11 : Hoplimit, node_id  and app_data
0x19 : Hoplimit, node_id, timestamp and app_data

Valid values for trace-tsp are 0, 1, 2 and 3 defines the precision of 32-bit timestamp. This encodes the number of microseconds elapsed since 1970 Jan 1 in 64-bit. Optimization is done to keep only significant 32-bits that is enough to decode relative time across Value 0 means the precision is in seconds, 1 is for milliseconds, 2 is for micro seconds and 3 is for nano seconds.

Show ioam configuration summary

vpp# sh ioam summary  
              REWRITE FLOW CONFIGS - Not configured
 HOP BY HOP OPTIONS - TRACE CONFIG - 
                        Trace Type : 0x1f (31)
         Trace timestamp precision : 1 (Milliseconds)
                Num of trace nodes : 3
                           Node-id : 0x1 (1)
                          App Data : 0x2424 (9252)
                        POW OPTION - 1 (Enabled)
Try 'show ioam sc-profile' for more information
         EDGE TO EDGE - PPC OPTION - 1 (Encap)
Try 'show ioam ppc' for more information

Terminal Commands

Display command history

vpp# history
1  show terminal
2  set terminal ?
3  history

Show terminal state

vpp# show terminal
Terminal name:   unix-cli-stdin
Terminal mode:   char-by-char
Terminal width:  123
Terminal height: 48
ANSI capable:    yes
History enabled: yes
History limit:   50
Pager enabled:   yes
Pager limit:     100000
CRLF mode:       LF

Terminal settings

# set terminal ?
  set terminal ansi                        set terminal ansi [on|off]
  set terminal history                     set terminal history [on|off] [limit <lines>]
  set terminal pager                       set terminal pager [on|off] [limit <lines>]