vtysh

vtysh [OPTIONS] [COMMAND]

-b, --boot
    Execute commands in boot mode. This typically processes commands that set up the initial configuration from a boot-time script.

-c, --command <command>
    Executes a single command string and then exits. Useful for scripting automated configuration or status checks.

-d, --daemon <daemon_name>
    Connects to a specific routing daemon (e.g., zebra, bgpd, ospfd) instead of the default zebra.

-e, --enable
    Enters privileged EXEC mode directly upon startup, bypassing the need to type `enable`.

-f, --file <file>
    Executes commands from the specified file. This is commonly used for loading configuration files or running batches of commands.

-M, --no-pager
    Disables the pager for output. By default, long outputs are paginated (like `more` or `less`).

-u, --user <username>
    Authenticates as the specified username. This is relevant when vtysh is configured to use system user accounts for authentication.

--show-vtysh-config
    Displays the path to the vtysh configuration file.

-?, --help
    Displays a brief help message and exits.

--version
    Shows the vtysh version information and exits.

vtysh (pronounced "vee-tish") is a command-line interface (CLI) shell designed to provide a unified configuration and operational interface for the FRRouting (FRR) suite of routing protocols. It originated with the Quagga routing software and was later adopted and further developed by the FRR project.

Rather than configuring each routing daemon (like Zebra, OSPF, BGP, RIP, ISIS) separately, vtysh allows administrators to manage all aspects of the router's configuration from a single, consistent interface. Its command structure is heavily inspired by Cisco IOS and Juniper JUNOS, making it familiar to network engineers.

It supports various modes, including user EXEC mode for basic commands, privileged EXEC mode for show commands and configuration entry, and various configuration modes for specific features (e.g., global configuration, interface configuration, router configuration for protocols). vtysh simplifies the management of complex routing setups by abstracting the underlying daemon interactions into a single, intuitive CLI.

• vtysh relies on the FRR routing daemons (e.g., zebra, ospfd, bgpd) being actively running in the background. Without them, vtysh cannot communicate or apply configurations.
• Configuration changes made through vtysh are often kept in running memory by the daemons. To make them persistent across reboots, an explicit save command (e.g., `write memory` or `copy running-config startup-config`) must be executed.
• Proper permissions are required. vtysh usually needs to be run as root or by a user belonging to a specific group (e.g., frr or quagga) to interact with the daemons' control sockets.

vtysh operates in several hierarchical modes similar to commercial router CLIs:

• User EXEC Mode (e.g., `>` prompt): For basic commands like `show version`.
• Privileged EXEC Mode (e.g., `#` prompt): Accessed via `enable`, for more powerful `show` commands and entry into configuration mode.
• Global Configuration Mode (e.g., `(config)#` prompt): Entered via `configure terminal`, for global settings.
• Specific Configuration Modes (e.g., `(config-if)#`, `(config-router)#`): For configuring interfaces, routing protocols, etc.

Unlike some systems where changes are automatically saved, vtysh and FRR daemons typically require an explicit command to save the running configuration to a startup configuration file. Common commands include `write memory` or `copy running-config startup-config` within the privileged EXEC mode to ensure configurations persist after a system reboot.

vtysh originated as part of the Quagga routing suite, providing a Cisco-like CLI experience for open-source routing daemons. When the development of Quagga slowed, the project was forked and continued as FRRouting (FRR). vtysh was consequently inherited by FRR and remains its primary command-line interface, undergoing continuous development and enhancements to support new features and protocols within the FRR ecosystem. Its design was driven by the need for a unified, user-friendly interface that could manage complex routing configurations across multiple daemons from a single point.

zebra(8), bgpd(8), ospfd(8), ripd(8), frr(8)