--- /dev/null
+This is quagga.info, produced by makeinfo version 4.7 from quagga.texi.
+
+ Permission is granted to make and distribute verbatim copies of
+ this manual provided the copyright notice and this permission
+ notice are preserved on all copies.
+
+ Permission is granted to copy and distribute modified versions of
+ this manual under the conditions for verbatim copying, provided
+ that the entire resulting derived work is distributed under the
+ terms of a permission notice identical to this one.
+
+ Permission is granted to copy and distribute translations of this
+ manual into another language, under the above conditions for
+ modified versions, except that this permission notice may be
+ stated in a translation approved by Kunihiro Ishiguro.
+
+INFO-DIR-SECTION Routing Software:
+START-INFO-DIR-ENTRY
+* Quagga: (quagga). The Quagga Software Routing Suite
+END-INFO-DIR-ENTRY
+
+ This file documents the Quagga Software Routing Suite which manages
+common TCP/IP routing protocols.
+
+ This is Edition 0.97.3, last updated 7 November 2004 of `The Quagga
+Manual', for Quagga Version 0.97.3.
+
+ Copyright (C) 1999-2004 Kunihiro Ishiguro, et al.
+
+ Permission is granted to make and distribute verbatim copies of
+ this manual provided the copyright notice and this permission
+ notice are preserved on all copies.
+
+ Permission is granted to copy and distribute modified versions of
+ this manual under the conditions for verbatim copying, provided
+ that the entire resulting derived work is distributed under the
+ terms of a permission notice identical to this one.
+
+ Permission is granted to copy and distribute translations of this
+ manual into another language, under the above conditions for
+ modified versions, except that this permission notice may be
+ stated in a translation approved by Kunihiro Ishiguro.
+
+\1f
+File: quagga.info, Node: Top, Next: Overview, Up: (dir)
+
+Quagga
+******
+
+Quagga is an advanced routing software package that provides a suite of
+TCP/IP based routing protocols. This is the Manual for quagga-0.97.3.
+Quagga is a fork of GNU Zebra.
+
+* Menu:
+
+* Overview::
+* Installation::
+* Basic commands::
+* Zebra::
+* RIP::
+* RIPng::
+* OSPFv2::
+* OSPFv3::
+* BGP::
+* Configuring Quagga as a Route Server::
+* VTY shell::
+* Filtering::
+* Route Map::
+* IPv6 Support::
+* Kernel Interface::
+* SNMP Support::
+* Zebra Protocol::
+* Packet Binary Dump Format::
+* Command Index::
+* VTY Key Index::
+
+\1f
+File: quagga.info, Node: Overview, Next: Installation, Prev: Top, Up: Top
+
+1 Overview
+**********
+
+Quagga is a routing software package that provides TCP/IP based routing
+services with routing protocols support such as RIPv1, RIPv2, RIPng,
+OSPFv2, OSPFv3, BGP-4, and BGP-4+ (*note Supported RFC::). Quagga also
+supports special BGP Route Reflector and Route Server behavior. In
+addition to traditional IPv4 routing protocols, Quagga also supports
+IPv6 routing protocols. With SNMP daemon which supports SMUX protocol,
+Quagga provides routing protocol MIBs (*note SNMP Support::).
+
+ Quagga uses an advanced software architecture to provide you with a
+high quality, multi server routing engine. Quagga has an interactive
+user interface for each routing protocol and supports common client
+commands. Due to this design, you can add new protocol daemons to
+Quagga easily. You can use Quagga library as your program's client
+user interface.
+
+ Quagga is distributed under the GNU General Public License.
+
+* Menu:
+
+* About Quagga:: Basic information about Quagga
+* System Architecture:: The Quagga system architecture
+* Supported Platforms:: Supported platforms and future plans
+* Supported RFC:: Supported RFCs
+* How to get Quagga::
+* Mailing List:: Mailing list information
+* Bug Reports:: Mail address for bug data
+
+\1f
+File: quagga.info, Node: About Quagga, Next: System Architecture, Up: Overview
+
+1.1 About Quagga
+================
+
+Today, TCP/IP networks are covering all of the world. The Internet has
+been deployed in many countries, companies, and to the home. When you
+connect to the Internet your packet will pass many routers which have
+TCP/IP routing functionality.
+
+ A system with Quagga installed acts as a dedicated router. With
+Quagga, your machine exchanges routing information with other routers
+using routing protocols. Quagga uses this information to update the
+kernel routing table so that the right data goes to the right place.
+You can dynamically change the configuration and you may view routing
+table information from the Quagga terminal interface.
+
+ Adding to routing protocol support, Quagga can setup interface's
+flags, interface's address, static routes and so on. If you have a
+small network, or a stub network, or xDSL connection, configuring the
+Quagga routing software is very easy. The only thing you have to do is
+to set up the interfaces and put a few commands about static routes
+and/or default routes. If the network is rather large, or if the
+network structure changes frequently, you will want to take advantage
+of Quagga's dynamic routing protocol support for protocols such as RIP,
+OSPF or BGP.
+
+ Traditionally, UNIX based router configuration is done by `ifconfig'
+and `route' commands. Status of routing table is displayed by
+`netstat' utility. Almost of these commands work only if the user has
+root privileges. Quagga has a different system administration method.
+There are two user modes in Quagga. One is normal mode, the other is
+enable mode. Normal mode user can only view system status, enable mode
+user can change system configuration. This UNIX account independent
+feature will be great help to the router administrator.
+
+ Currently, Quagga supports common unicast routing protocols.
+Multicast routing protocols such as BGMP, PIM-SM, PIM-DM may be
+supported in Quagga 2.0. MPLS support is going on. In the future,
+TCP/IP filtering control, QoS control, diffserv configuration will be
+added to Quagga. Quagga project's final goal is making a productive,
+quality, free TCP/IP routing software.
+
+\1f
+File: quagga.info, Node: System Architecture, Next: Supported Platforms, Prev: About Quagga, Up: Overview
+
+1.2 System Architecture
+=======================
+
+Traditional routing software is made as a one process program which
+provides all of the routing protocol functionalities. Quagga takes a
+different approach. It is made from a collection of several daemons
+that work together to build the routing table. There may be several
+protocol-specific routing daemons and zebra the kernel routing manager.
+
+ The `ripd' daemon handles the RIP protocol, while `ospfd' is a
+daemon which supports OSPF version 2. `bgpd' supports the BGP-4
+protocol. For changing the kernel routing table and for redistribution
+of routes between different routing protocols, there is a kernel
+routing table manager `zebra' daemon. It is easy to add a new routing
+protocol daemons to the entire routing system without affecting any
+other software. You need to run only the protocol daemon associated
+with routing protocols in use. Thus, user may run a specific daemon
+and send routing reports to a central routing console.
+
+ There is no need for these daemons to be running on the same
+machine. You can even run several same protocol daemons on the same
+machine. This architecture creates new possibilities for the routing
+system.
+
+ +----+ +----+ +-----+ +-----+
+ |bgpd| |ripd| |ospfd| |zebra|
+ +----+ +----+ +-----+ +-----+
+ |
+ +---------------------------|--+
+ | v |
+ | UNIX Kernel routing table |
+ | |
+ +------------------------------+
+
+ Quagga System Architecture
+
+ Multi-process architecture brings extensibility, modularity and
+maintainability. At the same time it also brings many configuration
+files and terminal interfaces. Each daemon has it's own configuration
+file and terminal interface. When you configure a static route, it
+must be done in `zebra' configuration file. When you configure BGP
+network it must be done in `bgpd' configuration file. This can be a
+very annoying thing. To resolve the problem, Quagga provides
+integrated user interface shell called `vtysh'. `vtysh' connects to
+each daemon with UNIX domain socket and then works as a proxy for user
+input.
+
+ Quagga was planned to use multi-threaded mechanism when it runs with
+a kernel that supports multi-threads. But at the moment, the thread
+library which comes with GNU/Linux or FreeBSD has some problems with
+running reliable services such as routing software, so we don't use
+threads at all. Instead we use the `select(2)' system call for
+multiplexing the events.
+
+\1f
+File: quagga.info, Node: Supported Platforms, Next: Supported RFC, Prev: System Architecture, Up: Overview
+
+1.3 Supported Platforms
+=======================
+
+Currently Quagga supports GNU/Linux, BSD and Solaris. Porting Quagga to
+other platforms is not too difficult as platform dependent code should
+most be limited to the `zebra' daemon. Protocol daemons are mostly
+platform independent. Please let us know when you find out Quagga runs
+on a platform which is not listed below.
+
+ The list of officially supported platforms are listed below. Note
+that Quagga may run correctly on other platforms, and may run with
+partial functionality on further platforms.
+
+
+ * GNU/Linux 2.2.x and higher
+
+ * FreeBSD 4.x and higher
+
+ * NetBSD 1.6 and higher
+
+ * OpenBSD 2.5 and higher
+
+ * Solaris 2.6 and higher (IPv6 support requires a patch at moment)
+
+
+ Some IPv6 stacks are in development. Quagga supports following IPv6
+stacks. For BSD, we recommend KAME IPv6 stack. Solaris IPv6 stack is
+not yet supported.
+
+ * Linux IPv6 stack for GNU/Linux 2.2.x and higher.
+
+ * KAME IPv6 stack for BSD.
+
+ * INRIA IPv6 stack for BSD.
+
+\1f
+File: quagga.info, Node: Supported RFC, Next: How to get Quagga, Prev: Supported Platforms, Up: Overview
+
+1.4 Supported RFC
+=================
+
+Below is the list of currently supported RFC's.
+
+RFC1058
+ `Routing Information Protocol. C.L. Hedrick. Jun-01-1988.'
+
+RF2082
+ `RIP-2 MD5 Authentication. F. Baker, R. Atkinson. January 1997.'
+
+RFC2453
+ `RIP Version 2. G. Malkin. November 1998.'
+
+RFC2080
+ `RIPng for IPv6. G. Malkin, R. Minnear. January 1997.'
+
+RFC2328
+ `OSPF Version 2. J. Moy. April 1998.'
+
+RFC2370
+ `The OSPF Opaque LSA Option R. Coltun. July 1998.'
+
+RFC3101
+ `The OSPF Not-So-Stubby Area (NSSA) Option P. Murphy. January
+ 2003.'
+
+RFC2740
+ `OSPF for IPv6. R. Coltun, D. Ferguson, J. Moy. December 1999.'
+
+RFC1771
+ `A Border Gateway Protocol 4 (BGP-4). Y. Rekhter & T. Li. March
+ 1995.'
+
+RFC1965
+ `Autonomous System Confederations for BGP. P. Traina. June 1996.'
+
+RFC1997
+ `BGP Communities Attribute. R. Chandra, P. Traina & T. Li. August
+ 1996.'
+
+RFC2545
+ `Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain
+ Routing. P. Marques, F. Dupont. March 1999.'
+
+RFC2796
+ `BGP Route Reflection An alternative to full mesh IBGP. T. Bates &
+ R. Chandrasekeran. June 1996.'
+
+RFC2858
+ `Multiprotocol Extensions for BGP-4. T. Bates, Y. Rekhter, R.
+ Chandra, D. Katz. June 2000.'
+
+RFC2842
+ `Capabilities Advertisement with BGP-4. R. Chandra, J. Scudder.
+ May 2000.'
+
+
+ When SNMP support is enabled, below RFC is also supported.
+
+RFC1227
+ `SNMP MUX protocol and MIB. M.T. Rose. May-01-1991.'
+
+RFC1657
+ `Definitions of Managed Objects for the Fourth Version of the
+ Border Gateway Protocol (BGP-4) using SMIv2. S. Willis, J. Burruss,
+ J. Chu, Editor. July 1994.'
+
+RFC1724
+ `RIP Version 2 MIB Extension. G. Malkin & F. Baker. November 1994.'
+
+RFC1850
+ `OSPF Version 2 Management Information Base. F. Baker, R. Coltun.
+ November 1995.'
+
+
+\1f
+File: quagga.info, Node: How to get Quagga, Next: Mailing List, Prev: Supported RFC, Up: Overview
+
+1.5 How to get Quagga
+=====================
+
+Quagga is still beta software and there is no officially released
+version.
+
+ Zebra's official web page is located at:
+
+ `http://www.gnu.org/software/zebra/zebra.html'.
+
+ The original Zebra web site is located at:
+
+ `http://www.zebra.org/'.
+
+ As of this writing, development by zebra.org on Zebra has slowed
+down. Some work is being done by third-parties to try maintain
+bug-fixes and enhancements to the current Zebra code-base, which has
+resulted in a fork of Zebra called Quagga, see:
+
+ `http://www.quagga.net/'
+
+ for further information, as well as links to additional zebra
+resources.
+
+\1f
+File: quagga.info, Node: Mailing List, Next: Bug Reports, Prev: How to get Quagga, Up: Overview
+
+1.6 Mailing List
+================
+
+There is a mailing list for discussions about Quagga. If you have any
+comments or suggestions to Quagga, please subscribe to:
+
+ `http://lists.quagga.net/mailman/listinfo/quagga-users'.
+
+ The Quagga site has further information on the available mailing
+lists, see:
+
+ `http://www.quagga.net/lists.php'
+
+\1f
+File: quagga.info, Node: Bug Reports, Prev: Mailing List, Up: Overview
+
+1.7 Bug Reports
+===============
+
+If you think you have found a bug, please send a bug report to:
+
+ `http://bugzilla.quagga.net'
+
+ When you send a bug report, please be careful about the points below.
+
+ * Please note what kind of OS you are using. If you use the IPv6
+ stack please note that as well.
+
+ * Please show us the results of `netstat -rn' and `ifconfig -a'.
+ Information from zebra's VTY command `show ip route' will also be
+ helpful.
+
+ * Please send your configuration file with the report. If you
+ specify arguments to the configure script please note that too.
+
+ Bug reports are very important for us to improve the quality of
+Quagga. Quagga is still in the development stage, but please don't
+hesitate to send a bug report to `http://bugzilla.quagga.net'.
+
+\1f
+File: quagga.info, Node: Installation, Next: Basic commands, Prev: Overview, Up: Top
+
+2 Installation
+**************
+
+There are three steps for installing the software: configuration,
+compilation, and installation.
+
+* Menu:
+
+* Configure the Software::
+* Build the Software::
+* Install the Software::
+
+ The easiest way to get Quagga running is to issue the following
+commands:
+
+ % configure
+ % make
+ % make install
+
+\1f
+File: quagga.info, Node: Configure the Software, Next: Build the Software, Up: Installation
+
+2.1 Configure the Software
+==========================
+
+* Menu:
+
+* The Configure script and its options::
+* Least-Privilege support::
+* Linux notes::
+
+\1f
+File: quagga.info, Node: The Configure script and its options, Next: Least-Privilege support, Up: Configure the Software
+
+2.1.1 The Configure script and its options
+------------------------------------------
+
+Quagga has an excellent configure script which automatically detects
+most host configurations. There are several additional configure
+options you can use to turn off IPv6 support, to disable the
+compilation of specific daemons, and to enable SNMP support.
+
+`--enable-guile'
+ Turn on compilation of the zebra-guile interpreter. You will need
+ the guile library to make this. zebra-guile implementation is not
+ yet finished. So this option is only useful for zebra-guile
+ developers.
+
+`--disable-ipv6'
+ Turn off IPv6 related features and daemons. Quagga configure
+ script automatically detects IPv6 stack. But sometimes you might
+ want to disable IPv6 support of Quagga.
+
+`--disable-zebra'
+ Do not build zebra daemon.
+
+`--disable-ripd'
+ Do not build ripd.
+
+`--disable-ripngd'
+ Do not build ripngd.
+
+`--disable-ospfd'
+ Do not build ospfd.
+
+`--disable-ospf6d'
+ Do not build ospf6d.
+
+`--disable-bgpd'
+ Do not build bgpd.
+
+`--disable-bgp-announce'
+ Make `bgpd' which does not make bgp announcements at all. This
+ feature is good for using `bgpd' as a BGP announcement listener.
+
+`--enable-netlink'
+ Force to enable GNU/Linux netlink interface. Quagga configure
+ script detects netlink interface by checking a header file. When
+ the header file does not match to the current running kernel,
+ configure script will not turn on netlink support.
+
+`--enable-snmp'
+ Enable SNMP support. By default, SNMP support is disabled.
+
+`--enable-opaque-lsa'
+ Enable support for Opaque LSAs (RFC2370) in ospfd.
+
+`--disable-ospfapi'
+ Disable support for OSPF-API, an API to interface directly with
+ ospfd. OSPF-API is enabled if -enable-opaque-lsa is set.
+
+`--disable-ospfclient'
+ Disable building of the example OSPF-API client.
+
+`--enable-ospf-te'
+ Enable support for OSPF Traffic Engineering Extension
+ (internet-draft) this requires support for Opaque LSAs.
+
+`--enable-multipath=ARG'
+ Enable support for Equal Cost Multipath. ARG is the maximum number
+ of ECMP paths to allow, set to 0 to allow unlimited number of
+ paths.
+
+`--enable-rtadv'
+ Enable support IPV6 router advertisement in zebra.
+
+ You may specify any combination of the above options to the configure
+script. By default, the executables are placed in `/usr/local/sbin'
+and the configuration files in `/usr/local/etc'. The `/usr/local/'
+installation prefix and other directories may be changed using the
+following options to the configuration script.
+
+`--prefix=PREFIX'
+ Install architecture-independent files in PREFIX [/usr/local].
+
+`--sysconfdir=DIR'
+ Look for configuration files in DIR [PREFIX/etc]. Note that sample
+ configuration files will be installed here.
+
+`--localstatedir=DIR'
+ Configure zebra to use DIR for local state files, such as pid
+ files and unix sockets.
+
+ % ./configure --disable-ipv6
+
+ This command will configure zebra and the routing daemons.
+
+\1f
+File: quagga.info, Node: Least-Privilege support, Next: Linux notes, Prev: The Configure script and its options, Up: Configure the Software
+
+2.1.2 Least-Privilege support
+-----------------------------
+
+Additionally, you may configure zebra to drop its elevated privileges
+shortly after startup and switch to another user. The configure script
+will automatically try to configure this support. There are three
+configure options to control the behaviour of Quagga daemons.
+
+`--enable-user=USER'
+ Switch to user ARG shortly after startup, and run as user ARG in
+ normal operation.
+
+`--enable-group=GROUP'
+ Switch real and effective group to GROUP shortly after startup.
+
+`--enable-vty-group=GROUP'
+ Create Unix Vty sockets (for use with vtysh) with group owndership
+ set to GROUP. This allows one to create a seperate group which is
+ restricted to accessing only the Vty sockets, hence allowing one to
+ delegate this group to individual users, or to run vtysh setgid to
+ this group.
+
+ The default user and group which will be configured is 'quagga' if
+no user or group is specified. Note that this user or group requires
+write access to the local state directory (see -localstatedir) and
+requires at least read access, and write access if you wish to allow
+daemons to write out their configuration, to the configuration
+directory (see -sysconfdir).
+
+ On systems which have the 'libcap' capabilities manipulation library
+(currently only linux), the quagga system will retain only minimal
+capabilities required, further it will only raise these capabilities for
+brief periods. On systems without libcap, quagga will run as the user
+specified and only raise its uid back to uid 0 for brief periods.
+
+\1f
+File: quagga.info, Node: Linux notes, Prev: Least-Privilege support, Up: Configure the Software
+
+2.1.3 Linux Notes
+-----------------
+
+There are several options available only to GNU/Linux systems: (1). If
+you use GNU/Linux, make sure that the current kernel configuration is
+what you want. Quagga will run with any kernel configuration but some
+recommendations do exist.
+
+CONFIG_NETLINK
+ Kernel/User netlink socket. This is a brand new feature which
+ enables an advanced interface between the Linux kernel and zebra
+ (*note Kernel Interface::).
+
+CONFIG_RTNETLINK
+ Routing messages. This makes it possible to receive netlink
+ routing messages. If you specify this option, `zebra' can detect
+ routing information updates directly from the kernel (*note Kernel
+ Interface::).
+
+CONFIG_IP_MULTICAST
+ IP: multicasting. This option should be specified when you use
+ `ripd' (*note RIP::) or `ospfd' (*note OSPFv2::) because these
+ protocols use multicast.
+
+
+ IPv6 support has been added in GNU/Linux kernel version 2.2. If you
+try to use the Quagga IPv6 feature on a GNU/Linux kernel, please make
+sure the following libraries have been installed. Please note that
+these libraries will not be needed when you uses GNU C library 2.1 or
+upper.
+
+`inet6-apps'
+ The `inet6-apps' package includes basic IPv6 related libraries such
+ as `inet_ntop' and `inet_pton'. Some basic IPv6 programs such as
+ `ping', `ftp', and `inetd' are also included. The `inet-apps' can
+ be found at `ftp://ftp.inner.net/pub/ipv6/'.
+
+`net-tools'
+ The `net-tools' package provides an IPv6 enabled interface and
+ routing utility. It contains `ifconfig', `route', `netstat', and
+ other tools. `net-tools' may be found at
+ `http://www.tazenda.demon.co.uk/phil/net-tools/'.
+
+
+ ---------- Footnotes ----------
+
+ (1) GNU/Linux has very flexible kernel configuration features
+
+\1f
+File: quagga.info, Node: Build the Software, Next: Install the Software, Prev: Configure the Software, Up: Installation
+
+2.2 Build the Software
+======================
+
+After configuring the software, you will need to compile it for your
+system. Simply issue the command `make' in the root of the source
+directory and the software will be compiled. If you have *any* problems
+at this stage, be certain to send a bug report *Note Bug Reports::.
+
+ % ./configure
+ .
+ .
+ .
+ ./configure output
+ .
+ .
+ .
+ % make
+
+\1f
+File: quagga.info, Node: Install the Software, Prev: Build the Software, Up: Installation
+
+2.3 Install the Software
+========================
+
+Installing the software to your system consists of copying the compiled
+programs and supporting files to a standard location. After the
+installation process has completed, these files have been copied from
+your work directory to `/usr/local/bin', and `/usr/local/etc'.
+
+ To install the Quagga suite, issue the following command at your
+shell prompt: `make install'.
+
+ %
+ % make install
+ %
+
+ Quagga daemons have their own terminal interface or VTY. After
+installation, you have to setup each beast's port number to connect to
+them. Please add the following entries to `/etc/services'.
+
+ zebrasrv 2600/tcp # zebra service
+ zebra 2601/tcp # zebra vty
+ ripd 2602/tcp # RIPd vty
+ ripngd 2603/tcp # RIPngd vty
+ ospfd 2604/tcp # OSPFd vty
+ bgpd 2605/tcp # BGPd vty
+ ospf6d 2606/tcp # OSPF6d vty
+ ospfapi 2607/tcp # ospfapi
+ isisd 2608/tcp # ISISd vty
+
+ If you use a FreeBSD newer than 2.2.8, the above entries are already
+added to `/etc/services' so there is no need to add it. If you specify
+a port number when starting the daemon, these entries may not be needed.
+
+ You may need to make changes to the config files in
+`/etc/quagga/*.conf'. *Note Config Commands::.
+
+\1f
+File: quagga.info, Node: Basic commands, Next: Zebra, Prev: Installation, Up: Top
+
+3 Basic commands
+****************
+
+There are five routing daemons in use, and there is one manager daemon.
+These daemons may be located on separate machines from the manager
+daemon. Each of these daemons will listen on a particular port for
+incoming VTY connections. The routing daemons are:
+
+ * `ripd', `ripngd', `ospfd', `ospf6d', `bgpd'
+
+ * `zebra'
+
+ The following sections discuss commands common to all the routing
+daemons.
+
+* Menu:
+
+* Config Commands:: Commands used in config files
+* Common Invocation Options:: Starting the daemons
+* Virtual Terminal Interfaces:: Interacting with the daemons
+
+\1f
+File: quagga.info, Node: Config Commands, Next: Common Invocation Options, Up: Basic commands
+
+3.1 Config Commands
+===================
+
+* Menu:
+
+* Basic Config Commands:: Some of the generic config commands
+* Sample Config File:: An example config file
+
+ In a config file, you can write the debugging options, a vty's
+password, routing daemon configurations, a log file name, and so forth.
+This information forms the initial command set for a routing beast as
+it is starting.
+
+ Config files are generally found in:
+
+ `/etc/quagga/*.conf'
+
+ Each of the daemons has its own config file. For example, zebra's
+default config file name is:
+
+ `/etc/quagga/zebra.conf'
+
+ The daemon name plus `.conf' is the default config file name. You
+can specify a config file using the `-f' or `--config-file' options
+when starting the daemon.
+
+\1f
+File: quagga.info, Node: Basic Config Commands, Next: Sample Config File, Up: Config Commands
+
+3.1.1 Basic Config Commands
+---------------------------
+
+ -- Command: hostname HOSTNAME
+ Set hostname of the router.
+
+ -- Command: password PASSWORD
+ Set password for vty interface. If there is no password, a vty
+ won't accept connections.
+
+ -- Command: enable password PASSWORD
+ Set enable password.
+
+ -- Command: log stdout
+ -- Command: no log stdout
+ Set logging output to stdout.
+
+ -- Command: log file FILENAME
+ If you want to log into a file please specify `filename' as
+ follows.
+ log file /usr/local/etc/bgpd.log
+
+ -- Command: log syslog
+ -- Command: no log syslog
+ Set logging output to syslog.
+
+ -- Command: write terminal
+ Displays the current configuration to the vty interface.
+
+ -- Command: write file
+ Write current configuration to configuration file.
+
+ -- Command: configure terminal
+ Change to configuration mode. This command is the first step to
+ configuration.
+
+ -- Command: terminal length <0-512>
+ Set terminal display length to <0-512>. If length is 0, no
+ display control is performed.
+
+ -- Command: who
+
+ -- Command: list
+ List commands.
+
+ -- Command: service password-encryption
+ Encrypt password.
+
+ -- Command: service advanced-vty
+ Enable advanced mode VTY.
+
+ -- Command: service terminal-length <0-512>
+ Set system wide line configuration. This configuration command
+ applies to all VTY interfaces.
+
+ -- Command: show version
+ Show the current version of Quagga and its build host information.
+
+ -- Command: line vty
+ Enter vty configuration mode.
+
+ -- Command: banner motd default
+ Set default motd string.
+
+ -- Command: no banner motd
+ No motd banner string will be printed.
+
+ -- Line Command: exec-timeout MINUTE
+ -- Line Command: exec-timeout MINUTE SECOND
+ Set VTY connection timeout value. When only one argument is
+ specified it is used for timeout value in minutes. Optional
+ second argument is used for timeout value in seconds. Default
+ timeout value is 10 minutes. When timeout value is zero, it means
+ no timeout.
+
+ -- Line Command: no exec-timeout
+ Do not perform timeout at all. This command is as same as
+ `exec-timeout 0 0'.
+
+ -- Line Command: access-class ACCESS-LIST
+ Restrict vty connections with an access list.
+
+\1f
+File: quagga.info, Node: Sample Config File, Prev: Basic Config Commands, Up: Config Commands
+
+3.1.2 Sample Config File
+------------------------
+
+Below is a sample configuration file for the zebra daemon.
+
+ !
+ ! Zebra configuration file
+ !
+ hostname Router
+ password zebra
+ enable password zebra
+ !
+ log stdout
+ !
+ !
+
+ '!' and '#' are comment characters. If the first character of the
+word is one of the comment characters then from the rest of the line
+forward will be ignored as a comment.
+
+ password zebra!password
+
+ If a comment character is not the first character of the word, it's a
+normal character. So in the above example '!' will not be regarded as a
+comment and the password is set to 'zebra!password'.
+
+\1f
+File: quagga.info, Node: Common Invocation Options, Next: Virtual Terminal Interfaces, Prev: Config Commands, Up: Basic commands
+
+3.2 Common Invocation Options
+=============================
+
+These options apply to all Quagga daemons.
+
+`-d'
+`--daemon'
+ Runs in daemon mode.
+
+`-f FILE'
+`--config_file=FILE'
+ Set configuration file name.
+
+`-h'
+`--help'
+ Display this help and exit.
+
+`-i FILE'
+`--pid_file=FILE'
+ Upon startup the process identifier of the daemon is written to a
+ file, typically in `/var/run'. This file can be used by the init
+ system to implement commands such as `.../init.d/zebra status',
+ `.../init.d/zebra restart' or `.../init.d/zebra stop'.
+
+ The file name is an run-time option rather than a configure-time
+ option so that multiple routing daemons can be run simultaneously.
+ This is useful when using Quagga to implement a routing looking
+ glass. One machine can be used to collect differing routing views
+ from differing points in the network.
+
+`-A ADDRESS'
+`--vty_addr=ADDRESS'
+ Set the VTY local address to bind to. If set, the VTY socket will
+ only be bound to this address.
+
+`-P PORT'
+`--vty_port=PORT'
+ Set the VTY TCP port number. If set to 0 then the TCP VTY sockets
+ will not be opened.
+
+`-u USER'
+`--vty_addr=USER'
+ Set the user and group to run as.
+
+`-v'
+`--version'
+ Print program version.
+
+
+\1f
+File: quagga.info, Node: Virtual Terminal Interfaces, Prev: Common Invocation Options, Up: Basic commands
+
+3.3 Virtual Terminal Interfaces
+===============================
+
+VTY - Virtual Terminal [aka TeletYpe] Interface is a command line
+interface (CLI) for user interaction with the routing daemon.
+
+* Menu:
+
+* VTY Overview:: Basics about VTYs
+* VTY Modes:: View, Enable, and Other VTY modes
+* VTY CLI Commands:: Commands for movement, edition, and management
+
+\1f
+File: quagga.info, Node: VTY Overview, Next: VTY Modes, Up: Virtual Terminal Interfaces
+
+3.3.1 VTY Overview
+------------------
+
+VTY stands for Virtual TeletYpe interface. It means you can connect to
+the daemon via the telnet protocol.
+
+ To enable a VTY interface, you have to setup a VTY password. If
+there is no VTY password, one cannot connect to the VTY interface at
+all.
+
+ % telnet localhost 2601
+ Trying 127.0.0.1...
+ Connected to localhost.
+ Escape character is '^]'.
+
+ Hello, this is Quagga (version 0.97.3)
+ Copyright (C) 1999-2004 Kunihiro Ishiguro, et al.
+
+ User Access Verification
+
+ Password: XXXXX
+ Router> ?
+ enable Turn on privileged commands
+ exit Exit current mode and down to previous mode
+ help Description of the interactive help system
+ list Print command list
+ show Show running system information
+ who Display who is on a vty
+ Router> enable
+ Password: XXXXX
+ Router# configure terminal
+ Router(config)# interface eth0
+ Router(config-if)# ip address 10.0.0.1/8
+ Router(config-if)# ^Z
+ Router#
+
+ '?' is very useful for looking up commands.
+
+\1f
+File: quagga.info, Node: VTY Modes, Next: VTY CLI Commands, Prev: VTY Overview, Up: Virtual Terminal Interfaces
+
+3.3.2 VTY Modes
+---------------
+
+There are three basic VTY modes:
+
+* Menu:
+
+* VTY View Mode:: Mode for read-only interaction
+* VTY Enable Mode:: Mode for read-write interaction
+* VTY Other Modes:: Special modes (tftp, etc)
+
+ There are commands that may be restricted to specific VTY modes.
+
+\1f
+File: quagga.info, Node: VTY View Mode, Next: VTY Enable Mode, Up: VTY Modes
+
+3.3.2.1 VTY View Mode
+.....................
+
+This mode is for read-only access to the CLI. One may exit the mode by
+leaving the system, or by entering `enable' mode.
+
+\1f
+File: quagga.info, Node: VTY Enable Mode, Next: VTY Other Modes, Prev: VTY View Mode, Up: VTY Modes
+
+3.3.2.2 VTY Enable Mode
+.......................
+
+This mode is for read-write access to the CLI. One may exit the mode by
+leaving the system, or by escaping to view mode.
+
+\1f
+File: quagga.info, Node: VTY Other Modes, Prev: VTY Enable Mode, Up: VTY Modes
+
+3.3.2.3 VTY Other Modes
+.......................
+
+This page is for describing other modes.
+
+\1f
+File: quagga.info, Node: VTY CLI Commands, Prev: VTY Modes, Up: Virtual Terminal Interfaces
+
+3.3.3 VTY CLI Commands
+----------------------
+
+Commands that you may use at the command-line are described in the
+following three subsubsections.
+
+* Menu:
+
+* CLI Movement Commands:: Commands for moving the cursor about
+* CLI Editing Commands:: Commands for changing text
+* CLI Advanced Commands:: Other commands, session management and so on
+
+\1f
+File: quagga.info, Node: CLI Movement Commands, Next: CLI Editing Commands, Up: VTY CLI Commands
+
+3.3.3.1 CLI Movement Commands
+.............................
+
+These commands are used for moving the CLI cursor. The <C> character
+means press the Control Key.
+
+`C-f'
+`<RIGHT>'
+ Move forward one character.
+
+`C-b'
+`<LEFT>'
+ Move backward one character.
+
+`M-f'
+ Move forward one word.
+
+`M-b'
+ Move backward one word.
+
+`C-a'
+ Move to the beginning of the line.
+
+`C-e'
+ Move to the end of the line.
+
+
+\1f
+File: quagga.info, Node: CLI Editing Commands, Next: CLI Advanced Commands, Prev: CLI Movement Commands, Up: VTY CLI Commands
+
+3.3.3.2 CLI Editing Commands
+............................
+
+These commands are used for editing text on a line. The <C> character
+means press the Control Key.
+
+`C-h'
+`<DEL>'
+ Delete the character before point.
+
+`C-d'
+ Delete the character after point.
+
+`M-d'
+ Forward kill word.
+
+`C-w'
+ Backward kill word.
+
+`C-k'
+ Kill to the end of the line.
+
+`C-u'
+ Kill line from the beginning, erasing input.
+
+`C-t'
+ Transpose character.
+
+
+\1f
+File: quagga.info, Node: CLI Advanced Commands, Prev: CLI Editing Commands, Up: VTY CLI Commands
+
+3.3.3.3 CLI Advanced Commands
+.............................
+
+There are several additional CLI commands for command line completions,
+insta-help, and VTY session management.
+
+`C-c'
+ Interrupt current input and moves to the next line.
+
+`C-z'
+ End current configuration session and move to top node.
+
+`C-n'
+`<DOWN>'
+ Move down to next line in the history buffer.
+
+`C-p'
+`<UP>'
+ Move up to previous line in the history buffer.
+
+`TAB'
+ Use command line completion by typing <TAB>.
+
+`'
+ You can use command line help by typing `help' at the beginning of
+ the line. Typing `?' at any point in the line will show possible
+ completions.
+
+
+\1f
+File: quagga.info, Node: Zebra, Next: RIP, Prev: Basic commands, Up: Top
+
+4 Zebra
+*******
+
+`zebra' is an IP routing manager. It provides kernel routing table
+updates, interface lookups, and redistribution of routes between
+different routing protocols.
+
+* Menu:
+
+* Invoking zebra:: Running the program
+* Interface Commands:: Commands for zebra interfaces
+* Static Route Commands:: Commands for adding static routes
+* zebra Terminal Mode Commands:: Commands for zebra's VTY
+
+\1f
+File: quagga.info, Node: Invoking zebra, Next: Interface Commands, Up: Zebra
+
+4.1 Invoking zebra
+==================
+
+Besides the common invocation options (*note Common Invocation
+Options::), the `zebra' specific invocation options are listed below.
+
+`-b'
+`--batch'
+ Runs in batch mode. `zebra' parses configuration file and
+ terminates immediately.
+
+`-k'
+`--keep_kernel'
+ When zebra starts up, don't delete old self inserted routes.
+
+`-l'
+`--log_mode'
+ Set verbose logging on.
+
+`-r'
+`--retain'
+ When program terminates, retain routes added by zebra.
+
+
+\1f
+File: quagga.info, Node: Interface Commands, Next: Static Route Commands, Prev: Invoking zebra, Up: Zebra
+
+4.2 Interface Commands
+======================
+
+ -- Command: interface IFNAME
+
+ -- Interface Command: shutdown
+ -- Interface Command: no shutdown
+ Up or down the current interface.
+
+ -- Interface Command: ip address ADDRESS/PREFIX
+ -- Interface Command: ip6 address ADDRESS/PREFIX
+ -- Interface Command: no ip address ADDRESS/PREFIX
+ -- Interface Command: no ip6 address ADDRESS/PREFIX
+ Set the IPv4 or IPv6 address/prefix for the interface.
+
+ -- Interface Command: ip address ADDRESS/PREFIX secondary
+ -- Interface Command: no ip address ADDRESS/PREFIX secondary
+ Set the secondary flag for this address. This causes ospfd to not
+ treat the address as a distinct subnet.
+
+ -- Interface Command: description DESCRIPTION ...
+ Set description for the interface.
+
+ -- Interface Command: multicast
+ -- Interface Command: no multicast
+ Enable or disables multicast flag for the interface.
+
+ -- Interface Command: bandwidth <1-10000000>
+ -- Interface Command: no bandwidth <1-10000000>
+ Set bandwidth value of the interface in kilobits/sec. This is for
+ calculating OSPF cost. This command does not affect the actual
+ device configuration.
+
+ -- Interface Command: link-detect
+ -- Interface Command: no link-detect
+ Enable/disable link-detect on platforms which support this.
+ Currently only linux and with certain drivers - those which
+ properly support the IFF_RUNNING flag.
+
+\1f
+File: quagga.info, Node: Static Route Commands, Next: zebra Terminal Mode Commands, Prev: Interface Commands, Up: Zebra
+
+4.3 Static Route Commands
+=========================
+
+Static routing is a very fundamental feature of routing technology. It
+defines static prefix and gateway.
+
+ -- Command: ip route NETWORK GATEWAY
+ NETWORK is destination prefix with format of A.B.C.D/M. GATEWAY
+ is gateway for the prefix. When GATEWAY is A.B.C.D format. It is
+ taken as a IPv4 address gateway. Otherwise it is treated as an
+ interface name. If the interface name is NULL0 then zebra installs
+ a blackhole route.
+
+ ip route 10.0.0.0/8 10.0.0.2
+ ip route 10.0.0.0/8 ppp0
+ ip route 10.0.0.0/8 null0
+
+ First example defines 10.0.0.0/8 static route with gateway
+ 10.0.0.2. Second one defines the same prefix but with gateway to
+ interface ppp0. The third install a blackhole route.
+
+ -- Command: ip route NETWORK NETMASK GATEWAY
+ This is alternate version of above command. When NETWORK is
+ A.B.C.D format, user must define NETMASK value with A.B.C.D
+ format. GATEWAY is same option as above command
+
+ ip route 10.0.0.0 255.255.255.0 10.0.0.2
+ ip route 10.0.0.0 255.255.255.0 ppp0
+ ip route 10.0.0.0 255.255.255.0 null0
+
+ These statements are equivalent to those in the previous example.
+
+ -- Command: ip route NETWORK GATEWAY DISTANCE
+ Installs the route with the specified distance.
+
+ Multiple nexthop static route
+
+ ip route 10.0.0.1/32 10.0.0.2
+ ip route 10.0.0.1/32 10.0.0.3
+ ip route 10.0.0.1/32 eth0
+
+ If there is no route to 10.0.0.2 and 10.0.0.3, and interface eth0 is
+reachable, then the last route is installed into the kernel.
+
+ If zebra has been compiled with multipath support, and both 10.0.0.2
+and 10.0.0.3 are reachable, zebra will install a multipath route via
+both nexthops, if the platform supports this.
+
+ zebra> show ip route
+ S> 10.0.0.1/32 [1/0] via 10.0.0.2 inactive
+ via 10.0.0.3 inactive
+ * is directly connected, eth0
+
+ ip route 10.0.0.0/8 10.0.0.2
+ ip route 10.0.0.0/8 10.0.0.3
+ ip route 10.0.0.0/8 null0 255
+
+ This will install a multihop route via the specified next-hops if
+they are reachable, as well as a high-metric blackhole route, which can
+be useful to prevent traffic destined for a prefix to match
+less-specific routes (eg default) should the specified gateways not be
+reachable. Eg:
+
+ zebra> show ip route 10.0.0.0/8
+ Routing entry for 10.0.0.0/8
+ Known via "static", distance 1, metric 0
+ 10.0.0.2 inactive
+ 10.0.0.3 inactive
+
+ Routing entry for 10.0.0.0/8
+ Known via "static", distance 255, metric 0
+ directly connected, Null0
+
+ -- Command: ipv6 route NETWORK GATEWAY
+ -- Command: ipv6 route NETWORK GATEWAY DISTANCE
+ These behave similarly to their ipv4 counterparts.
+
+ -- Command: table TABLENO
+ Select the primary kernel routing table to be used. This only
+ works for kernels supporting multiple routing tables (like
+ GNU/Linux 2.2.x and later). After setting TABLENO with this
+ command, static routes defined after this are added to the
+ specified table.
+
+\1f
+File: quagga.info, Node: zebra Terminal Mode Commands, Prev: Static Route Commands, Up: Zebra
+
+4.4 zebra Terminal Mode Commands
+================================
+
+ -- Command: show ip route
+ Display current routes which zebra holds in its database.
+
+ Router# show ip route
+ Codes: K - kernel route, C - connected, S - static, R - RIP,
+ B - BGP * - FIB route.
+
+ K* 0.0.0.0/0 203.181.89.241
+ S 0.0.0.0/0 203.181.89.1
+ C* 127.0.0.0/8 lo
+ C* 203.181.89.240/28 eth0
+
+ -- Command: show ipv6 route
+
+ -- Command: show interface
+
+ -- Command: show ipforward
+ Display whether the host's IP forwarding function is enabled or
+ not. Almost any UNIX kernel can be configured with IP forwarding
+ disabled. If so, the box can't work as a router.
+
+ -- Command: show ipv6forward
+ Display whether the host's IP v6 forwarding is enabled or not.
+
+\1f
+File: quagga.info, Node: RIP, Next: RIPng, Prev: Zebra, Up: Top
+
+5 RIP
+*****
+
+RIP - Routing Information Protocol is widely deployed interior gateway
+protocol. RIP was developed in the 1970s at Xerox Labs as part of the
+XNS routing protocol. RIP is a "distance-vector" protocol and is based
+on the "Bellman-Ford" algorithms. As a distance-vector protocol, RIP
+router send updates to its neighbors periodically, thus allowing the
+convergence to a known topology. In each update, the distance to any
+given network will be broadcasted to its neighboring router.
+
+ `ripd' supports RIP version 2 as described in RFC2453 and RIP
+version 1 as described in RFC1058.
+
+* Menu:
+
+* Starting and Stopping ripd::
+* RIP Configuration::
+* How to Announce RIP route::
+* Filtering RIP Routes::
+* RIP Metric Manipulation::
+* RIP distance::
+* RIP route-map::
+* RIP Authentication::
+* RIP Timers::
+* Show RIP Information::
+* RIP Debug Commands::
+
+\1f
+File: quagga.info, Node: Starting and Stopping ripd, Next: RIP Configuration, Up: RIP
+
+5.1 Starting and Stopping ripd
+==============================
+
+The default configuration file name of `ripd''s is `ripd.conf'. When
+invocation `ripd' searches directory /etc/quagga. If `ripd.conf' is
+not there next search current directory.
+
+ RIP uses UDP port 520 to send and receive RIP packets. So the user
+must have the capability to bind the port, generally this means that
+the user must have superuser privileges. RIP protocol requires
+interface information maintained by `zebra' daemon. So running `zebra'
+is mandatory to run `ripd'. Thus minimum sequence for running RIP is
+like below:
+
+ # zebra -d
+ # ripd -d
+
+ Please note that `zebra' must be invoked before `ripd'.
+
+ To stop `ripd'. Please use `kill `cat /var/run/ripd.pid`'. Certain
+signals have special meaningss to `ripd'.
+
+`SIGHUP'
+ Reload configuration file `ripd.conf'. All configurations are
+ reseted. All routes learned so far are cleared and removed from
+ routing table.
+
+`SIGUSR1'
+ Rotate `ripd' logfile.
+
+`SIGINT'
+`SIGTERM'
+ `ripd' sweeps all installed RIP routes then terminates properly.
+
+ `ripd' invocation options. Common options that can be specified
+(*note Common Invocation Options::).
+
+`-r'
+`--retain'
+ When the program terminates, retain routes added by `ripd'.
+
+* Menu:
+
+* RIP netmask::
+
+\1f
+File: quagga.info, Node: RIP netmask, Up: Starting and Stopping ripd
+
+5.1.1 RIP netmask
+-----------------
+
+The netmask features of `ripd' support both version 1 and version 2 of
+RIP. Version 1 of RIP originally contained no netmask information. In
+RIP version 1, network classes were originally used to determine the
+size of the netmask. Class A networks use 8 bits of mask, Class B
+networks use 16 bits of masks, while Class C networks use 24 bits of
+mask. Today, the most widely used method of a network mask is assigned
+to the packet on the basis of the interface that received the packet.
+Version 2 of RIP supports a variable length subnet mask (VLSM). By
+extending the subnet mask, the mask can be divided and reused. Each
+subnet can be used for different purposes such as large to middle size
+LANs and WAN links. Quagga `ripd' does not support the non-sequential
+netmasks that are included in RIP Version 2.
+
+ In a case of similar information with the same prefix and metric, the
+old information will be suppressed. Ripd does not currently support
+equal cost multipath routing.
+
+\1f
+File: quagga.info, Node: RIP Configuration, Next: How to Announce RIP route, Prev: Starting and Stopping ripd, Up: RIP
+
+5.2 RIP Configuration
+=====================
+
+ -- Command: router rip
+ The `router rip' command is necessary to enable RIP. To disable
+ RIP, use the `no router rip' command. RIP must be enabled before
+ carrying out any of the RIP commands.
+
+ -- Command: no router rip
+ Disable RIP.
+
+ RIP can be configured to process either Version 1 or Version 2
+packets, the default mode is Version 2. If no version is specified,
+then the RIP daemon will default to Version 2. If RIP is set to Version
+1, the setting "Version 1" will be displayed, but the setting "Version
+2" will not be displayed whether or not Version 2 is set explicitly as
+the version of RIP being used. The version can be specified globally,
+and also on a per-interface basis (see below).
+
+ -- RIP Command: version VERSION
+ Set RIP process's version. VERSION can be `1" or `2".
+
+ -- RIP Command: network NETWORK
+ -- RIP Command: no network NETWORK
+ Set the RIP enable interface by NETWORK. The interfaces which
+ have addresses matching with NETWORK are enabled.
+
+ This group of commands either enables or disables RIP interfaces
+ between certain numbers of a specified network address. For
+ example, if the network for 10.0.0.0/24 is RIP enabled, this would
+ result in all the addresses from 10.0.0.0 to 10.0.0.255 being
+ enabled for RIP. The `no network' command will disable RIP for
+ the specified network.
+
+ -- RIP Command: network IFNAME
+ -- RIP Command: no network IFNAME
+ Set a RIP enabled interface by IFNAME. Both the sending and
+ receiving of RIP packets will be enabled on the port specified in
+ the `network ifname' command. The `no network ifname' command
+ will disable RIP on the specified interface.
+
+ -- RIP Command: neighbor A.B.C.D
+ -- RIP Command: no neighbor A.B.C.D
+ Specify RIP neighbor. When a neighbor doesn't understand
+ multicast, this command is used to specify neighbors. In some
+ cases, not all routers will be able to understand multicasting,
+ where packets are sent to a network or a group of addresses. In a
+ situation where a neighbor cannot process multicast packets, it is
+ necessary to establish a direct link between routers. The
+ neighbor command allows the network administrator to specify a
+ router as a RIP neighbor. The `no neighbor a.b.c.d' command will
+ disable the RIP neighbor.
+
+ Below is very simple RIP configuration. Interface `eth0' and
+interface which address match to `10.0.0.0/8' are RIP enabled.
+
+ !
+ router rip
+ network 10.0.0.0/8
+ network eth0
+ !
+
+ Passive interface
+
+ -- RIP command: passive-interface (IFNAME|default)
+ -- RIP command: no passive-interface IFNAME
+ This command sets the specified interface to passive mode. On
+ passive mode interface, all receiving packets are processed as
+ normal and ripd does not send either multicast or unicast RIP
+ packets except to RIP neighbors specified with `neighbor' command.
+ The interface may be specified as DEFAULT to make ripd default to
+ passive on all interfaces.
+
+ The default is to be passive on all interfaces.
+
+ RIP version handling
+
+ -- Interface command: ip rip send version VERSION
+ VERSION can be `1', `2', `1 2'. This configuration command
+ overrides the router's rip version setting. The command will
+ enable the selected interface to send packets with RIP Version 1,
+ RIP Version 2, or both. In the case of '1 2', packets will be
+ both broadcast and multicast.
+
+ The default is to send only version 2.
+
+ -- Interface command: ip rip receive version VERSION
+ Version setting for incoming RIP packets. This command will
+ enable the selected interface to receive packets in RIP Version 1,
+ RIP Version 2, or both.
+
+ The default is to receive both versions.
+
+ RIP split-horizon
+
+ -- Interface command: ip split-horizon
+ -- Interface command: no ip split-horizon
+ Control split-horizon on the interface. Default is `ip
+ split-horizon'. If you don't perform split-horizon on the
+ interface, please specify `no ip split-horizon'.
+
+\1f
+File: quagga.info, Node: How to Announce RIP route, Next: Filtering RIP Routes, Prev: RIP Configuration, Up: RIP
+
+5.3 How to Announce RIP route
+=============================
+
+ -- RIP command: redistribute kernel
+ -- RIP command: redistribute kernel metric <0-16>
+ -- RIP command: redistribute kernel route-map ROUTE-MAP
+ -- RIP command: no redistribute kernel
+ `redistribute kernel' redistributes routing information from
+ kernel route entries into the RIP tables. `no redistribute kernel'
+ disables the routes.
+
+ -- RIP command: redistribute static
+ -- RIP command: redistribute static metric <0-16>
+ -- RIP command: redistribute static route-map ROUTE-MAP
+ -- RIP command: no redistribute static
+ `redistribute static' redistributes routing information from
+ static route entries into the RIP tables. `no redistribute static'
+ disables the routes.
+
+ -- RIP command: redistribute connected
+ -- RIP command: redistribute connected metric <0-16>
+ -- RIP command: redistribute connected route-map ROUTE-MAP
+ -- RIP command: no redistribute connected
+ Redistribute connected routes into the RIP tables. `no
+ redistribute connected' disables the connected routes in the RIP
+ tables. This command redistribute connected of the interface
+ which RIP disabled. The connected route on RIP enabled interface
+ is announced by default.
+
+ -- RIP command: redistribute ospf
+ -- RIP command: redistribute ospf metric <0-16>
+ -- RIP command: redistribute ospf route-map ROUTE-MAP
+ -- RIP command: no redistribute ospf
+ `redistribute ospf' redistributes routing information from ospf
+ route entries into the RIP tables. `no redistribute ospf' disables
+ the routes.
+
+ -- RIP command: redistribute bgp
+ -- RIP command: redistribute bgp metric <0-16>
+ -- RIP command: redistribute bgp route-map ROUTE-MAP
+ -- RIP command: no redistribute bgp
+ `redistribute bgp' redistributes routing information from bgp
+ route entries into the RIP tables. `no redistribute bgp' disables
+ the routes.
+
+ If you want to specify RIP only static routes:
+
+ -- RIP command: default-information originate
+
+ -- RIP command: route A.B.C.D/M
+ -- RIP command: no route A.B.C.D/M
+ This command is specific to Quagga. The `route' command makes a
+ static route only inside RIP. This command should be used only by
+ advanced users who are particularly knowledgeable about the RIP
+ protocol. In most cases, we recommend creating a static route in
+ Quagga and redistributing it in RIP using `redistribute static'.
+
+\1f
+File: quagga.info, Node: Filtering RIP Routes, Next: RIP Metric Manipulation, Prev: How to Announce RIP route, Up: RIP
+
+5.4 Filtering RIP Routes
+========================
+
+RIP routes can be filtered by a distribute-list.
+
+ -- Command: distribute-list ACCESS_LIST DIRECT IFNAME
+ You can apply access lists to the interface with a
+ `distribute-list' command. ACCESS_LIST is the access list name.
+ DIRECT is `in' or `out'. If DIRECT is `in' the access list is
+ applied to input packets.
+
+ The `distribute-list' command can be used to filter the RIP path.
+ `distribute-list' can apply access-lists to a chosen interface.
+ First, one should specify the access-list. Next, the name of the
+ access-list is used in the distribute-list command. For example,
+ in the following configuration `eth0' will permit only the paths
+ that match the route 10.0.0.0/8
+
+ !
+ router rip
+ distribute-list private in eth0
+ !
+ access-list private permit 10 10.0.0.0/8
+ access-list private deny any
+ !
+
+ `distribute-list' can be applied to both incoming and outgoing data.
+
+ -- Command: distribute-list prefix PREFIX_LIST (in|out) IFNAME
+ You can apply prefix lists to the interface with a
+ `distribute-list' command. PREFIX_LIST is the prefix list name.
+ Next is the direction of `in' or `out'. If DIRECT is `in' the
+ access list is applied to input packets.
+
+\1f
+File: quagga.info, Node: RIP Metric Manipulation, Next: RIP distance, Prev: Filtering RIP Routes, Up: RIP
+
+5.5 RIP Metric Manipulation
+===========================
+
+RIP metric is a value for distance for the network. Usually `ripd'
+increment the metric when the network information is received.
+Redistributed routes' metric is set to 1.
+
+ -- RIP command: default-metric <1-16>
+ -- RIP command: no default-metric <1-16>
+ This command modifies the default metric value for redistributed
+ routes. The default value is 1. This command does not affect
+ connected route even if it is redistributed by `redistribute
+ connected'. To modify connected route's metric value, please use
+ `redistribute connected metric' or `route-map'. `offset-list' also
+ affects connected routes.
+
+ -- RIP command: offset-list ACCESS-LIST (in|out)
+ -- RIP command: offset-list ACCESS-LIST (in|out) IFNAME
+
+\1f
+File: quagga.info, Node: RIP distance, Next: RIP route-map, Prev: RIP Metric Manipulation, Up: RIP
+
+5.6 RIP distance
+================
+
+Distance value is used in zebra daemon. Default RIP distance is 120.
+
+ -- RIP command: distance <1-255>
+ -- RIP command: no distance <1-255>
+ Set default RIP distance to specified value.
+
+ -- RIP command: distance <1-255> A.B.C.D/M
+ -- RIP command: no distance <1-255> A.B.C.D/M
+ Set default RIP distance to specified value when the route's
+ source IP address matches the specified prefix.
+
+ -- RIP command: distance <1-255> A.B.C.D/M ACCESS-LIST
+ -- RIP command: no distance <1-255> A.B.C.D/M ACCESS-LIST
+ Set default RIP distance to specified value when the route's
+ source IP address matches the specified prefix and the specified
+ access-list.
+
+\1f
+File: quagga.info, Node: RIP route-map, Next: RIP Authentication, Prev: RIP distance, Up: RIP
+
+5.7 RIP route-map
+=================
+
+Usage of `ripd''s route-map support.
+
+ Optional argument route-map MAP_NAME can be added to each
+`redistribute' statement.
+
+ redistribute static [route-map MAP_NAME]
+ redistribute connected [route-map MAP_NAME]
+ .....
+
+ Cisco applies route-map _before_ routes will exported to rip route
+table. In current Quagga's test implementation, `ripd' applies
+route-map after routes are listed in the route table and before routes
+will be announced to an interface (something like output filter). I
+think it is not so clear, but it is draft and it may be changed at
+future.
+
+ Route-map statement (*note Route Map::) is needed to use route-map
+functionality.
+
+ -- Route Map: match interface WORD
+ This command match to incoming interface. Notation of this match
+ is different from Cisco. Cisco uses a list of interfaces - NAME1
+ NAME2 ... NAMEN. Ripd allows only one name (maybe will change in
+ the future). Next - Cisco means interface which includes next-hop
+ of routes (it is somewhat similar to "ip next-hop" statement).
+ Ripd means interface where this route will be sent. This
+ difference is because "next-hop" of same routes which sends to
+ different interfaces must be different. Maybe it'd be better to
+ made new matches - say "match interface-out NAME" or something
+ like that.
+
+ -- Route Map: match ip address WORD
+ -- Route Map: match ip address prefix-list WORD
+ Match if route destination is permitted by access-list.
+
+ -- Route Map: match ip next-hop A.B.C.D
+ Cisco uses here <access-list>, `ripd' IPv4 address. Match if route
+ has this next-hop (meaning next-hop listed in the rip route table
+ - "show ip rip")
+
+ -- Route Map: match metric <0-4294967295>
+ This command match to the metric value of RIP updates. For other
+ protocol compatibility metric range is shown as <0-4294967295>.
+ But for RIP protocol only the value range <0-16> make sense.
+
+ -- Route Map: set ip next-hop A.B.C.D
+ This command set next hop value in RIPv2 protocol. This command
+ does not affect RIPv1 because there is no next hop field in the
+ packet.
+
+ -- Route Map: set metric <0-4294967295>
+ Set a metric for matched route when sending announcement. The
+ metric value range is very large for compatibility with other
+ protocols. For RIP, valid metric values are from 1 to 16.
+
+\1f
+File: quagga.info, Node: RIP Authentication, Next: RIP Timers, Prev: RIP route-map, Up: RIP
+
+5.8 RIP Authentication
+======================
+
+ -- Interface command: ip rip authentication mode md5
+ -- Interface command: no ip rip authentication mode md5
+ Set the interface with RIPv2 MD5 authentication.
+
+ -- Interface command: ip rip authentication mode text
+ -- Interface command: no ip rip authentication mode text
+ Set the interface with RIPv2 simple password authentication.
+
+ -- Interface command: ip rip authentication string STRING
+ -- Interface command: no ip rip authentication string STRING
+ RIP version 2 has simple text authentication. This command sets
+ authentication string. The string must be shorter than 16
+ characters.
+
+ -- Interface command: ip rip authentication key-chain KEY-CHAIN
+ -- Interface command: no ip rip authentication key-chain KEY-CHAIN
+ Specifiy Keyed MD5 chain.
+
+ !
+ key chain test
+ key 1
+ key-string test
+ !
+ interface eth1
+ ip rip authentication mode md5
+ ip rip authentication key-chain test
+ !
+
+\1f
+File: quagga.info, Node: RIP Timers, Next: Show RIP Information, Prev: RIP Authentication, Up: RIP
+
+5.9 RIP Timers
+==============
+
+ -- RIP command: timers basic UPDATE TIMEOUT GARBAGE
+ RIP protocol has several timers. User can configure those timers'
+ values by `timers basic' command.
+
+ The default settings for the timers are as follows:
+
+ * The update timer is 30 seconds. Every update timer seconds,
+ the RIP process is awakened to send an unsolicited Response
+ message containing the complete routing table to all
+ neighboring RIP routers.
+
+ * The timeout timer is 180 seconds. Upon expiration of the
+ timeout, the route is no longer valid; however, it is
+ retained in the routing table for a short time so that
+ neighbors can be notified that the route has been dropped.
+
+ * The garbage collect timer is 120 seconds. Upon expiration of
+ the garbage-collection timer, the route is finally removed
+ from the routing table.
+
+
+ The `timers basic' command allows the the default values of the
+ timers listed above to be changed.
+
+ -- RIP command: no timers basic
+ The `no timers basic' command will reset the timers to the default
+ settings listed above.
+
+\1f
+File: quagga.info, Node: Show RIP Information, Next: RIP Debug Commands, Prev: RIP Timers, Up: RIP
+
+5.10 Show RIP Information
+=========================
+
+To display RIP routes.
+
+ -- Command: show ip rip
+ Show RIP routes.
+
+ The command displays all RIP routes. For routes that are received
+through RIP, this command will display the time the packet was sent and
+the tag information. This command will also display this information
+for routes redistributed into RIP.
+
+ -- Command: show ip protocols
+ The command displays current RIP status. It includes RIP timer,
+ filtering, version, RIP enabled interface and RIP peer inforation.
+
+ ripd> show ip protocols
+ Routing Protocol is "rip"
+ Sending updates every 30 seconds with +/-50%, next due in 35 seconds
+ Timeout after 180 seconds, garbage collect after 120 seconds
+ Outgoing update filter list for all interface is not set
+ Incoming update filter list for all interface is not set
+ Default redistribution metric is 1
+ Redistributing: kernel connected
+ Default version control: send version 2, receive version 2
+ Interface Send Recv
+ Routing for Networks:
+ eth0
+ eth1
+ 1.1.1.1
+ 203.181.89.241
+ Routing Information Sources:
+ Gateway BadPackets BadRoutes Distance Last Update
+
+\1f
+File: quagga.info, Node: RIP Debug Commands, Prev: Show RIP Information, Up: RIP
+
+5.11 RIP Debug Commands
+=======================
+
+Debug for RIP protocol.
+
+ -- Command: debug rip events
+ Debug rip events.
+
+ `debug rip' will show RIP events. Sending and receiving packets,
+timers, and changes in interfaces are events shown with `ripd'.
+
+ -- Command: debug rip packet
+ Debug rip packet.
+
+ `debug rip packet' will display detailed information about the RIP
+packets. The origin and port number of the packet as well as a packet
+dump is shown.
+
+ -- Command: debug rip zebra
+ Debug rip between zebra communication.
+
+ This command will show the communication between `ripd' and `zebra'.
+The main information will include addition and deletion of paths to
+the kernel and the sending and receiving of interface information.
+
+ -- Command: show debugging rip
+ Display `ripd''s debugging option.
+
+ `show debugging rip' will show all information currently set for ripd
+debug.
+
+\1f
+File: quagga.info, Node: RIPng, Next: OSPFv2, Prev: RIP, Up: Top
+
+6 RIPng
+*******
+
+`ripngd' supports the RIPng protocol as described in RFC2080. It's an
+IPv6 reincarnation of the RIP protocol.
+
+* Menu:
+
+* Invoking ripngd::
+* ripngd Configuration::
+* ripngd Terminal Mode Commands::
+* ripngd Filtering Commands::
+
+\1f
+File: quagga.info, Node: Invoking ripngd, Next: ripngd Configuration, Up: RIPng
+
+6.1 Invoking ripngd
+===================
+
+There are no `ripngd' specific invocation options. Common options can
+be specified (*note Common Invocation Options::).
+
+\1f
+File: quagga.info, Node: ripngd Configuration, Next: ripngd Terminal Mode Commands, Prev: Invoking ripngd, Up: RIPng
+
+6.2 ripngd Configuration
+========================
+
+Currently ripngd supports the following commands:
+
+ -- Command: router ripng
+ Enable RIPng.
+
+ -- RIPng Command: flush_timer TIME
+ Set flush timer.
+
+ -- RIPng Command: network NETWORK
+ Set RIPng enabled interface by NETWORK
+
+ -- RIPng Command: network IFNAME
+ Set RIPng enabled interface by IFNAME
+
+ -- RIPng Command: route NETWORK
+ Set RIPng static routing announcement of NETWORK.
+
+ -- Command: router zebra
+ This command is the default and does not appear in the
+ configuration. With this statement, RIPng routes go to the
+ `zebra' daemon.
+
+\1f
+File: quagga.info, Node: ripngd Terminal Mode Commands, Next: ripngd Filtering Commands, Prev: ripngd Configuration, Up: RIPng
+
+6.3 ripngd Terminal Mode Commands
+=================================
+
+ -- Command: show ip ripng
+
+ -- Command: show debugging ripng
+
+ -- Command: debug ripng events
+
+ -- Command: debug ripng packet
+
+ -- Command: debug ripng zebra
+
+\1f
+File: quagga.info, Node: ripngd Filtering Commands, Prev: ripngd Terminal Mode Commands, Up: RIPng
+
+6.4 ripngd Filtering Commands
+=============================
+
+ -- Command: distribute-list ACCESS_LIST (in|out) IFNAME
+ You can apply an access-list to the interface using the
+ `distribute-list' command. ACCESS_LIST is an access-list name.
+ DIRECT is `in' or `out'. If DIRECT is `in', the access-list is
+ applied only to incoming packets.
+
+ distribute-list local-only out sit1
+
+\1f
+File: quagga.info, Node: OSPFv2, Next: OSPFv3, Prev: RIPng, Up: Top
+
+7 OSPFv2
+********
+
+OSPF version 2 is a routing protocol which described in RFC2328 - `OSPF
+Version 2'. OSPF is IGP (Interior Gateway Protocols). Compared with
+RIP, OSPF can provide scalable network support and faster convergence
+time. OSPF is widely used in large networks such as ISP backbone and
+enterprise networks.
+
+* Menu:
+
+* Configuring ospfd::
+* OSPF router::
+* OSPF area::
+* OSPF interface::
+* Redistribute routes to OSPF::
+* Showing OSPF information::
+* Debugging OSPF::
+
+\1f
+File: quagga.info, Node: Configuring ospfd, Next: OSPF router, Up: OSPFv2
+
+7.1 Configuring ospfd
+=====================
+
+There is no `ospfd' specific options. Common options can be specified
+(*note Common Invocation Options::) to `ospfd'. `ospfd' needs
+interface information from `zebra'. So please make it sure `zebra' is
+running before invoking `ospfd'.
+
+ Like other daemons, `ospfd' configuration is done in OSPF specific
+configuration file `ospfd.conf'.
+
+\1f
+File: quagga.info, Node: OSPF router, Next: OSPF area, Prev: Configuring ospfd, Up: OSPFv2
+
+7.2 OSPF router
+===============
+
+To start OSPF process you have to specify the OSPF router. As of this
+writing, `ospfd' does not support multiple OSPF processes.
+
+ -- Command: router ospf
+ -- Command: no router ospf
+ Enable or disable the OSPF process. `ospfd' does not yet support
+ multiple OSPF processes. So you can not specify an OSPF process
+ number.
+
+ -- OSPF Command: ospf router-id A.B.C.D
+ -- OSPF Command: no ospf router-id
+
+ -- OSPF Command: ospf abr-type TYPE
+ -- OSPF Command: no ospf abr-type TYPE
+ TYPE can be cisco|ibm|shortcut|standard More information regarding
+ the behaviour controlled by this command can be found in
+ draft-ietf-ospf-abr-alt-05.txt and
+ draft-ietf-ospf-shortcut-abr-02.txt Quote: "Though the definition
+ of the Area Border Router (ABR) in the OSPF specification does not
+ require a router with multiple attached areas to have a backbone
+ connection, it is actually necessary to provide successful routing
+ to the inter-area and external destinations. If this requirement
+ is not met, all traffic destined for the areas not connected to
+ such an ABR or out of the OSPF domain, is dropped. This document
+ describes alternative ABR behaviors implemented in Cisco and IBM
+ routers."
+
+ -- OSPF Command: ospf rfc1583compatibility
+ -- OSPF Command: no ospf rfc1583compatibility
+ This rfc2328, the sucessor to rfc1583, suggests according to
+ section G.2 (changes) in section 16.4 a change to the path
+ preference algorithm that prevents possible routing loops that
+ were possible in the old version of OSPFv2. More specifically it
+ demands that inter-area paths and intra-area path are now of equal
+ preference but still both preferred to external paths.
+
+ -- OSPF Command: passive interface INTERFACE
+ -- OSPF Command: no passive interface INTERFACE
+
+ -- OSPF Command: timers spf <0-4294967295> <0-4294967295>
+ -- OSPF Command: no timers spf
+
+ -- OSPF Command: refresh group-limit <0-10000>
+ -- OSPF Command: refresh per-slice <0-10000>
+ -- OSPF Command: refresh age-diff <0-10000>
+
+ -- OSPF Command: auto-cost refrence-bandwidth <1-4294967>
+ -- OSPF Command: no auto-cost refrence-bandwidth
+
+ -- OSPF Command: network A.B.C.D/M area A.B.C.D
+ -- OSPF Command: network A.B.C.D/M area <0-4294967295>
+ -- OSPF Command: no network A.B.C.D/M area A.B.C.D
+ -- OSPF Command: no network A.B.C.D/M area <0-4294967295>
+ This command specifies the OSPF enabled interface(s). If the
+ interface has an address from range 192.168.1.0/24 then the
+ command below enables ospf on this interface so router can provide
+ network information to the other ospf routers via this interface.
+ router ospf
+ network 192.168.1.0/24 area 0.0.0.0
+ Prefix length in interface must be equal or bigger (ie.
+ smaller network) than prefix length in network statement. For
+ example statement above doesn't enable ospf on interface with
+ address 192.168.1.1/23, but it does on interface with address
+ 192.168.1.129/25.
+
+\1f
+File: quagga.info, Node: OSPF area, Next: OSPF interface, Prev: OSPF router, Up: OSPFv2
+
+7.3 OSPF area
+=============
+
+ -- OSPF Command: area A.B.C.D range A.B.C.D/M
+ -- OSPF Command: area <0-4294967295> range A.B.C.D/M
+ -- OSPF Command: no area A.B.C.D range A.B.C.D/M
+ -- OSPF Command: no area <0-4294967295> range A.B.C.D/M
+ Summarize intra area paths from specified area into one Type-3
+ summary-LSA announced to other areas. This command can be used
+ only in ABR and ONLY router-LSAs (Type-1) and network-LSAs
+ (Type-2) (ie. LSAs with scope area) can be summarized. Type-5
+ AS-external-LSAs can't be summarized - their scope is AS.
+ Summarizing Type-7 AS-external-LSAs isn't supported yet by Quagga.
+ router ospf
+ network 192.168.1.0/24 area 0.0.0.0
+ network 10.0.0.0/8 area 0.0.0.10
+ area 0.0.0.10 range 10.0.0.0/8
+ With configuration above one Type-3 Summary-LSA with routing
+ info 10.0.0.0/8 is announced into backbone area if area 0.0.0.10
+ contains at least one intra-area network (ie. described with
+ router or network LSA) from this range.
+
+ -- OSPF Command: area A.B.C.D range IPV4_PREFIX not-advertise
+ -- OSPF Command: no area A.B.C.D range IPV4_PREFIX not-advertise
+ Instead of summarizing intra area paths filter them - ie. intra
+ area paths from this range are not advertised into other areas.
+ This command makes sense in ABR only.
+
+ -- OSPF Command: area A.B.C.D range IPV4_PREFIX substitute IPV4_PREFIX
+ -- OSPF Command: no area A.B.C.D range IPV4_PREFIX substitute
+IPV4_PREFIX
+ Substitute summarized prefix with another prefix.
+ router ospf
+ network 192.168.1.0/24 area 0.0.0.0
+ network 10.0.0.0/8 area 0.0.0.10
+ area 0.0.0.10 range 10.0.0.0/8 substitute 11.0.0.0/8
+ One Type-3 summary-LSA with routing info 11.0.0.0/8 is
+ announced into backbone area if area 0.0.0.10 contains at least
+ one intra-area network (ie. described with router-LSA or
+ network-LSA) from range 10.0.0.0/8. This command makes sense in
+ ABR only.
+
+ -- OSPF Command: area A.B.C.D virtual-link A.B.C.D
+ -- OSPF Command: area <0-4294967295> virtual-link A.B.C.D
+ -- OSPF Command: no area A.B.C.D virtual-link A.B.C.D
+ -- OSPF Command: no area <0-4294967295> virtual-link A.B.C.D
+
+ -- OSPF Command: area A.B.C.D shortcut
+ -- OSPF Command: area <0-4294967295> shortcut
+ -- OSPF Command: no area A.B.C.D shortcut
+ -- OSPF Command: no area <0-4294967295> shortcut
+
+ -- OSPF Command: area A.B.C.D stub
+ -- OSPF Command: area <0-4294967295> stub
+ -- OSPF Command: no area A.B.C.D stub
+ -- OSPF Command: no area <0-4294967295> stub
+
+ -- OSPF Command: area A.B.C.D stub no-summary
+ -- OSPF Command: area <0-4294967295> stub no-summary
+ -- OSPF Command: no area A.B.C.D stub no-summary
+ -- OSPF Command: no area <0-4294967295> stub no-summary
+
+ -- OSPF Command: area A.B.C.D default-cost <0-16777215>
+ -- OSPF Command: no area A.B.C.D default-cost <0-16777215>
+
+ -- OSPF Command: area A.B.C.D export-list NAME
+ -- OSPF Command: area <0-4294967295> export-list NAME
+ -- OSPF Command: no area A.B.C.D export-list NAME
+ -- OSPF Command: no area <0-4294967295> export-list NAME
+ Filter Type-3 summary-LSAs announced to other areas originated
+ from intra- area paths from specified area.
+ router ospf
+ network 192.168.1.0/24 area 0.0.0.0
+ network 10.0.0.0/8 area 0.0.0.10
+ area 0.0.0.10 export-list foo
+ !
+ access-list foo permit 10.10.0.0/16
+ access-list foo deny any
+ With example above any intra-area paths from area 0.0.0.10
+ and from range 10.10.0.0/16 (for example 10.10.1.0/24 and
+ 10.10.2.128/30) are announced into other areas as Type-3
+ summary-LSA's, but any others (for example 10.11.0.0/16 or
+ 10.128.30.16/30) aren't. This command makes sense in ABR only.
+
+ -- OSPF Command: area A.B.C.D import-list NAME
+ -- OSPF Command: area <0-4294967295> import-list NAME
+ -- OSPF Command: no area A.B.C.D import-list NAME
+ -- OSPF Command: no area <0-4294967295> import-list NAME
+ Same as export-list, but it applies to paths announced into
+ specified area as Type-3 summary-LSAs.
+
+ -- OSPF Command: area A.B.C.D filter-list prefix NAME in
+ -- OSPF Command: area A.B.C.D filter-list prefix NAME out
+ -- OSPF Command: area <0-4294967295> filter-list prefix NAME in
+ -- OSPF Command: area <0-4294967295> filter-list prefix NAME out
+ -- OSPF Command: no area A.B.C.D filter-list prefix NAME in
+ -- OSPF Command: no area A.B.C.D filter-list prefix NAME out
+ -- OSPF Command: no area <0-4294967295> filter-list prefix NAME in
+ -- OSPF Command: no area <0-4294967295> filter-list prefix NAME out
+ Filtering Type-3 summary-LSAs to/from area using prefix lists.
+ This command makes sense in ABR only.
+
+ -- OSPF Command: area A.B.C.D authentication
+ -- OSPF Command: area <0-4294967295> authentication
+ -- OSPF Command: no area A.B.C.D authentication
+ -- OSPF Command: no area <0-4294967295> authentication
+
+ -- OSPF Command: area A.B.C.D authentication message-digest
+ -- OSPF Command: area <0-4294967295> authentication message-digest
+
+\1f
+File: quagga.info, Node: OSPF interface, Next: Redistribute routes to OSPF, Prev: OSPF area, Up: OSPFv2
+
+7.4 OSPF interface
+==================
+
+ -- Interface Command: ip ospf authentication-key AUTH_KEY
+ -- Interface Command: no ip ospf authentication-key
+ Set OSPF authentication key to a simple password. After setting
+ AUTH_KEY, all OSPF packets are authenticated. AUTH_KEY has length
+ up to 8 chars.
+
+ -- Interface Command: ip ospf message-digest-key KEYID md5 KEY
+ -- Interface Command: no ip ospf message-digest-key
+ Set OSPF authentication key to a cryptographic password. The
+ cryptographic algorithm is MD5. KEYID identifies secret key used
+ to create the message digest. KEY is the actual message digest
+ key up to 16 chars.
+
+ Note that OSPF MD5 authentication requires that time never go
+ backwards (correct time is not important, only that it never goes
+ backwards), even across resets, if ospfd is to be able to promptly
+ reestabish adjacencies with its neighbours after restarts/reboots.
+ The host should have system time be set at boot from an external
+ source (eg battery backed clock, NTP, etc.) or else the system
+ clock should be periodically saved to non-volative storage and
+ restored at boot if MD5 authentication is to be expected to work
+ reliably.
+
+ -- Interface Command: ip ospf cost <1-65535>
+ -- Interface Command: no ip ospf cost
+ Set link cost for the specified interface. The cost value is set
+ to router-LSA's metric field and used for SPF calculation.
+
+ -- Interface Command: ip ospf dead-interval <1-65535>
+ -- Interface Command: no ip ospf dead-interval
+ Set number of seconds for RouterDeadInterval timer value used for
+ Wait Timer and Inactivity Timer. This value must be the same for
+ all routers attached to a common network. The default value is 40
+ seconds.
+
+ -- Interface Command: ip ospf hello-interval <1-65535>
+ -- Interface Command: no ip ospf hello-interval
+ Set number of seconds for HelloInterval timer value. Setting this
+ value, Hello packet will be sent every timer value seconds on the
+ specified interface. This value must be the same for all routers
+ attached to a common network. The default value is 10 seconds.
+
+ -- Interface Command: ip ospf network
+(broadcast|non-broadcast|point-to-multipoint|point-to-point)
+ -- Interface Command: no ip ospf network
+ Set explicitly network type for specifed interface.
+
+ -- Interface Command: ip ospf priority <0-255>
+ -- Interface Command: no ip ospf priority
+ Set RouterPriority integer value. Setting higher value, router
+ will be more eligible to become Designated Router. Setting the
+ value to 0, router is no longer eligible to Designated Router.
+ The default value is 1.
+
+ -- Interface Command: ip ospf retransmit-interval <1-65535>
+ -- Interface Command: no ip ospf retransmit interval
+ Set number of seconds for RxmtInterval timer value. This value is
+ used when retransmitting Database Description and Link State
+ Request packets. The default value is 5 seconds.
+
+ -- Interface Command: ip ospf transmit-delay
+ -- Interface Command: no ip ospf transmit-delay
+ Set number of seconds for InfTransDelay value. LSAs' age should be
+ incremented by this value when transmitting. The default value is
+ 1 seconds.
+
+\1f
+File: quagga.info, Node: Redistribute routes to OSPF, Next: Showing OSPF information, Prev: OSPF interface, Up: OSPFv2
+
+7.5 Redistribute routes to OSPF
+===============================
+
+ -- OSPF Command: redistribute (kernel|connected|static|rip|bgp)
+ -- OSPF Command: redistribute (kernel|connected|static|rip|bgp)
+ROUTE-MAP
+ -- OSPF Command: redistribute (kernel|connected|static|rip|bgp)
+metric-type (1|2)
+ -- OSPF Command: redistribute (kernel|connected|static|rip|bgp)
+metric-type (1|2) route-map WORD
+ -- OSPF Command: redistribute (kernel|connected|static|rip|bgp) metric
+<0-16777214>
+ -- OSPF Command: redistribute (kernel|connected|static|rip|bgp) metric
+<0-16777214> route-map WORD
+ -- OSPF Command: redistribute (kernel|connected|static|rip|bgp)
+metric-type (1|2) metric <0-16777214>
+ -- OSPF Command: redistribute (kernel|connected|static|rip|bgp)
+metric-type (1|2) metric <0-16777214> route-map WORD
+ -- OSPF Command: no redistribute (kernel|connected|static|rip|bgp)
+
+ -- OSPF Command: default-information originate
+ -- OSPF Command: default-information originate metric <0-16777214>
+ -- OSPF Command: default-information originate metric <0-16777214>
+metric-type (1|2)
+ -- OSPF Command: default-information originate metric <0-16777214>
+metric-type (1|2) route-map WORD
+ -- OSPF Command: default-information originate always
+ -- OSPF Command: default-information originate always metric
+<0-16777214>
+ -- OSPF Command: default-information originate always metric
+<0-16777214> metric-type (1|2)
+ -- OSPF Command: default-information originate always metric
+<0-16777214> metric-type (1|2) route-map WORD
+ -- OSPF Command: no default-information originate
+
+ -- OSPF Command: distribute-list NAME out
+(kernel|connected|static|rip|ospf
+ -- OSPF Command: no distribute-list NAME out
+(kernel|connected|static|rip|ospf
+
+ -- OSPF Command: default-metric <0-16777214>
+ -- OSPF Command: no default-metric
+
+ -- OSPF Command: distance <1-255>
+ -- OSPF Command: no distance <1-255>
+
+ -- OSPF Command: distance ospf (intra-area|inter-area|external)
+ <1-255>
+ -- OSPF Command: no distance ospf
+
+ -- Command: router zebra
+ -- Command: no router zebra
+
+\1f
+File: quagga.info, Node: Showing OSPF information, Next: Debugging OSPF, Prev: Redistribute routes to OSPF, Up: OSPFv2
+
+7.6 Showing OSPF information
+============================
+
+ -- Command: show ip ospf
+
+ -- Command: show ip ospf interface [INTERFACE]
+
+ -- Command: show ip ospf neighbor
+ -- Command: show ip ospf neighbor INTERFACE
+ -- Command: show ip ospf neighbor detail
+ -- Command: show ip ospf neighbor INTERFACE detail
+
+ -- Command: show ip ospf database
+
+ -- Command: show ip ospf database
+(asbr-summary|external|network|router|summary)
+ -- Command: show ip ospf database
+(asbr-summary|external|network|router|summary) LINK-STATE-ID
+ -- Command: show ip ospf database
+(asbr-summary|external|network|router|summary) LINK-STATE-ID adv-router
+ADV-ROUTER
+ -- Command: show ip ospf database
+(asbr-summary|external|network|router|summary) adv-router ADV-ROUTER
+ -- Command: show ip ospf database
+(asbr-summary|external|network|router|summary) LINK-STATE-ID
+self-originate
+ -- Command: show ip ospf database
+(asbr-summary|external|network|router|summary) self-originate
+
+ -- Command: show ip ospf database max-age
+
+ -- Command: show ip ospf database self-originate
+
+ -- Command: show ip ospf refresher
+
+ -- Command: show ip ospf route
+
+\1f
+File: quagga.info, Node: Debugging OSPF, Prev: Showing OSPF information, Up: OSPFv2
+
+7.7 Debugging OSPF
+==================
+
+ -- Command: debug ospf packet
+(hello|dd|ls-request|ls-update|ls-ack|all) (send|recv) [detail]
+ -- Command: no debug ospf packet
+(hello|dd|ls-request|ls-update|ls-ack|all) (send|recv) [detail]
+
+ -- Command: debug ospf ism
+ -- Command: debug ospf ism (status|events|timers)
+ -- Command: no debug ospf ism
+ -- Command: no debug ospf ism (status|events|timers)
+
+ -- Command: debug ospf nsm
+ -- Command: debug ospf nsm (status|events|timers)
+ -- Command: no debug ospf nsm
+ -- Command: no debug ospf nsm (status|events|timers)
+
+ -- Command: debug ospf lsa
+ -- Command: debug ospf lsa (generate|flooding|refresh)
+ -- Command: no debug ospf lsa
+ -- Command: no debug ospf lsa (generate|flooding|refresh)
+
+ -- Command: debug ospf zebra
+ -- Command: debug ospf zebra (interface|redistribute)
+ -- Command: no debug ospf zebra
+ -- Command: no debug ospf zebra (interface|redistribute)
+
+ -- Command: show debugging ospf
+
+\1f
+File: quagga.info, Node: OSPFv3, Next: BGP, Prev: OSPFv2, Up: Top
+
+8 OSPFv3
+********
+
+`ospf6d' is a daemon support OSPF version 3 for IPv6 network. OSPF for
+IPv6 is described in RFC2740.
+
+* Menu:
+
+* OSPF6 router::
+* OSPF6 area::
+* OSPF6 interface::
+* Redistribute routes to OSPF6::
+* Showing OSPF6 information::
+
+\1f
+File: quagga.info, Node: OSPF6 router, Next: OSPF6 area, Up: OSPFv3
+
+8.1 OSPF6 router
+================
+
+ -- Command: router ospf6
+
+ -- OSPF6 Command: router-id A.B.C.D
+ Set router's Router-ID.
+
+ -- OSPF6 Command: interface IFNAME area AREA
+ Bind interface to specified area, and start sending OSPF packets.
+ AREA can be specified as 0.
+
+\1f
+File: quagga.info, Node: OSPF6 area, Next: OSPF6 interface, Prev: OSPF6 router, Up: OSPFv3
+
+8.2 OSPF6 area
+==============
+
+Area support for OSPFv3 is not yet implemented.
+
+\1f
+File: quagga.info, Node: OSPF6 interface, Next: Redistribute routes to OSPF6, Prev: OSPF6 area, Up: OSPFv3
+
+8.3 OSPF6 interface
+===================
+
+ -- Interface Command: ipv6 ospf6 cost COST
+ Sets interface's output cost. Default value is 1.
+
+ -- Interface Command: ipv6 ospf6 hello-interval HELLOINTERVAL
+ Sets interface's Hello Interval. Default 40
+
+ -- Interface Command: ipv6 ospf6 dead-interval DEADINTERVAL
+ Sets interface's Router Dead Interval. Default value is 40.
+
+ -- Interface Command: ipv6 ospf6 retransmit-interval
+ RETRANSMITINTERVAL
+ Sets interface's Rxmt Interval. Default value is 5.
+
+ -- Interface Command: ipv6 ospf6 priority PRIORITY
+ Sets interface's Router Priority. Default value is 1.
+
+ -- Interface Command: ipv6 ospf6 transmit-delay TRANSMITDELAY
+ Sets interface's Inf-Trans-Delay. Default value is 1.
+
+\1f
+File: quagga.info, Node: Redistribute routes to OSPF6, Next: Showing OSPF6 information, Prev: OSPF6 interface, Up: OSPFv3
+
+8.4 Redistribute routes to OSPF6
+================================
+
+ -- OSPF6 Command: redistribute static
+ -- OSPF6 Command: redistribute connected
+ -- OSPF6 Command: redistribute ripng
+
+\1f
+File: quagga.info, Node: Showing OSPF6 information, Prev: Redistribute routes to OSPF6, Up: OSPFv3
+
+8.5 Showing OSPF6 information
+=============================
+
+ -- Command: show ipv6 ospf6 [INSTANCE_ID]
+ INSTANCE_ID is an optional OSPF instance ID. To see router ID and
+ OSPF instance ID, simply type "show ipv6 ospf6 <cr>".
+
+ -- Command: show ipv6 ospf6 database
+ This command shows LSA database summary. You can specify the type
+ of LSA.
+
+ -- Command: show ipv6 ospf6 interface
+ To see OSPF interface configuration like costs.
+
+ -- Command: show ipv6 ospf6 neighbor
+ Shows state and chosen (Backup) DR of neighbor.
+
+ -- Command: show ipv6 ospf6 request-list A.B.C.D
+ Shows requestlist of neighbor.
+
+ -- Command: show ipv6 route ospf6
+ This command shows internal routing table.
+
+\1f
+File: quagga.info, Node: BGP, Next: Configuring Quagga as a Route Server, Prev: OSPFv3, Up: Top
+
+9 BGP
+*****
+
+BGP stands for a Border Gateway Protocol. The lastest BGP version is
+4. It is referred as BGP-4. BGP-4 is one of the Exterior Gateway
+Protocols and de-fact standard of Inter Domain routing protocol. BGP-4
+is described in `RFC1771' - `A Border Gateway Protocol 4 (BGP-4)'.
+
+ Many extentions are added to `RFC1771'. `RFC2858' - `Multiprotocol
+Extensions for BGP-4' provide multiprotocol support to BGP-4.
+
+* Menu:
+
+* Starting BGP::
+* BGP router::
+* BGP network::
+* BGP Peer::
+* BGP Peer Group::
+* BGP Address Family::
+* Autonomous System::
+* BGP Communities Attribute::
+* BGP Extended Communities Attribute::
+* Displaying BGP routes::
+* Capability Negotiation::
+* Route Reflector::
+* Route Server::
+* How to set up a 6-Bone connection::
+* Dump BGP packets and table::
+
+\1f
+File: quagga.info, Node: Starting BGP, Next: BGP router, Up: BGP
+
+9.1 Starting BGP
+================
+
+Default configuration file of `bgpd' is `bgpd.conf'. `bgpd' searches
+the current directory first then /etc/quagga/bgpd.conf. All of bgpd's
+command must be configured in `bgpd.conf'.
+
+ `bgpd' specific invocation options are described below. Common
+options may also be specified (*note Common Invocation Options::).
+
+`-p PORT'
+`--bgp_port=PORT'
+ Set the bgp protocol's port number.
+
+`-r'
+`--retain'
+ When program terminates, retain BGP routes added by zebra.
+
+\1f
+File: quagga.info, Node: BGP router, Next: BGP network, Prev: Starting BGP, Up: BGP
+
+9.2 BGP router
+==============
+
+First of all you must configure BGP router with `router bgp' command.
+To configure BGP router, you need AS number. AS number is an
+identification of autonomous system. BGP protocol uses the AS number
+for detecting whether the BGP connection is internal one or external
+one.
+
+ -- Command: router bgp ASN
+ Enable a BGP protocol process with the specified ASN. After this
+ statement you can input any `BGP Commands'. You can not create
+ different BGP process under different ASN without specifying
+ `multiple-instance' (*note Multiple instance::).
+
+ -- Command: no router bgp ASN
+ Destroy a BGP protocol process with the specified ASN.
+
+ -- BGP: bgp router-id A.B.C.D
+ This command specifies the router-ID. If `bgpd' connects to
+ `zebra' it gets interface and address information. In that case
+ default router ID value is selected as the largest IP Address of
+ the interfaces. When `router zebra' is not enabled `bgpd' can't
+ get interface information so `router-id' is set to 0.0.0.0. So
+ please set router-id by hand.
+
+* Menu:
+
+* BGP distance::
+* BGP decision process::
+
+\1f
+File: quagga.info, Node: BGP distance, Next: BGP decision process, Up: BGP router
+
+9.2.1 BGP distance
+------------------
+
+ -- BGP: distance bgp <1-255> <1-255> <1-255>
+ This command change distance value of BGP. Each argument is
+ distance value for external routes, internal routes and local
+ routes.
+
+ -- BGP: distance <1-255> A.B.C.D/M
+ -- BGP: distance <1-255> A.B.C.D/M WORD
+ This command set distance value to
+
+\1f
+File: quagga.info, Node: BGP decision process, Prev: BGP distance, Up: BGP router
+
+9.2.2 BGP decision process
+--------------------------
+
+1. Weight check
+
+2. Local preference check.
+
+3. Local route check.
+
+4. AS path length check.
+
+5. Origin check.
+
+6. MED check.
+
+\1f
+File: quagga.info, Node: BGP network, Next: BGP Peer, Prev: BGP router, Up: BGP
+
+9.3 BGP network
+===============
+
+* Menu:
+
+* BGP route::
+* Route Aggregation::
+* Redistribute to BGP::
+
+\1f
+File: quagga.info, Node: BGP route, Next: Route Aggregation, Up: BGP network
+
+9.3.1 BGP route
+---------------
+
+ -- BGP: network A.B.C.D/M
+ This command adds the announcement network.
+ router bgp 1
+ network 10.0.0.0/8
+ This configuration example says that network 10.0.0.0/8 will
+ be announced to all neighbors. Some vendors' routers don't
+ advertise routes if they aren't present in their IGP routing
+ tables; `bgp' doesn't care about IGP routes when announcing its
+ routes.
+
+ -- BGP: no network A.B.C.D/M
+
+\1f
+File: quagga.info, Node: Route Aggregation, Next: Redistribute to BGP, Prev: BGP route, Up: BGP network
+
+9.3.2 Route Aggregation
+-----------------------
+
+ -- BGP: aggregate-address A.B.C.D/M
+ This command specifies an aggregate address.
+
+ -- BGP: aggregate-address A.B.C.D/M as-set
+ This command specifies an aggregate address. Resulting routes
+ inlucde AS set.
+
+ -- BGP: aggregate-address A.B.C.D/M summary-only
+ This command specifies an aggregate address. Aggreated routes will
+ not be announce.
+
+ -- BGP: no aggregate-address A.B.C.D/M
+
+\1f
+File: quagga.info, Node: Redistribute to BGP, Prev: Route Aggregation, Up: BGP network
+
+9.3.3 Redistribute to BGP
+-------------------------
+
+ -- BGP: redistribute kernel
+ Redistribute kernel route to BGP process.
+
+ -- BGP: redistribute static
+ Redistribute static route to BGP process.
+
+ -- BGP: redistribute connected
+ Redistribute connected route to BGP process.
+
+ -- BGP: redistribute rip
+ Redistribute RIP route to BGP process.
+
+ -- BGP: redistribute ospf
+ Redistribute OSPF route to BGP process.
+
+\1f
+File: quagga.info, Node: BGP Peer, Next: BGP Peer Group, Prev: BGP network, Up: BGP
+
+9.4 BGP Peer
+============
+
+* Menu:
+
+* Defining Peer::
+* BGP Peer commands::
+* Peer filtering::
+
+\1f
+File: quagga.info, Node: Defining Peer, Next: BGP Peer commands, Up: BGP Peer
+
+9.4.1 Defining Peer
+-------------------
+
+ -- BGP: neighbor PEER remote-as ASN
+ Creates a new neighbor whose remote-as is ASN. PEER can be an
+ IPv4 address or an IPv6 address.
+ router bgp 1
+ neighbor 10.0.0.1 remote-as 2
+ In this case my router, in AS-1, is trying to peer with AS-2
+ at 10.0.0.1.
+
+ This command must be the first command used when configuring a
+ neighbor. If the remote-as is not specified, `bgpd' will complain
+ like this:
+ can't find neighbor 10.0.0.1
+
+\1f
+File: quagga.info, Node: BGP Peer commands, Next: Peer filtering, Prev: Defining Peer, Up: BGP Peer
+
+9.4.2 BGP Peer commands
+-----------------------
+
+In a `router bgp' clause there are neighbor specific configurations
+required.
+
+ -- BGP: neighbor PEER shutdown
+ -- BGP: no neighbor PEER shutdown
+ Shutdown the peer. We can delete the neighbor's configuration by
+ `no neighbor PEER remote-as AS-NUMBER' but all configuration of
+ the neighbor will be deleted. When you want to preserve the
+ configuration, but want to drop the BGP peer, use this syntax.
+
+ -- BGP: neighbor PEER ebgp-multihop
+ -- BGP: no neighbor PEER ebgp-multihop
+
+ -- BGP: neighbor PEER description ...
+ -- BGP: no neighbor PEER description ...
+ Set description of the peer.
+
+ -- BGP: neighbor PEER version VERSION
+ Set up the neighbor's BGP version. VERSION can be 4, 4+ or 4-.
+ BGP version 4 is the default value used for BGP peering. BGP
+ version 4+ means that the neighbor supports Multiprotocol
+ Extensions for BGP-4. BGP version 4- is similar but the neighbor
+ speaks the old Internet-Draft revision 00's Multiprotocol
+ Extensions for BGP-4. Some routing software is still using this
+ version.
+
+ -- BGP: neighbor PEER interface IFNAME
+ -- BGP: no neighbor PEER interface IFNAME
+ When you connect to a BGP peer over an IPv6 link-local address,
+ you have to specify the IFNAME of the interface used for the
+ connection.
+
+ -- BGP: neighbor PEER next-hop-self
+ -- BGP: no neighbor PEER next-hop-self
+ This command specifies an announced route's nexthop as being
+ equivalent to the address of the bgp router.
+
+ -- BGP: neighbor PEER update-source
+ -- BGP: no neighbor PEER update-source
+
+ -- BGP: neighbor PEER default-originate
+ -- BGP: no neighbor PEER default-originate
+ `bgpd''s default is to not announce the default route (0.0.0.0/0)
+ even it is in routing table. When you want to announce default
+ routes to the peer, use this command.
+
+ -- BGP: neighbor PEER port PORT
+ -- BGP: neighbor PEER port PORT
+
+ -- BGP: neighbor PEER send-community
+ -- BGP: neighbor PEER send-community
+
+ -- BGP: neighbor PEER weight WEIGHT
+ -- BGP: no neighbor PEER weight WEIGHT
+ This command specifies a default WEIGHT value for the neighbor's
+ routes.
+
+ -- BGP: neighbor PEER maximum-prefix NUMBER
+ -- BGP: no neighbor PEER maximum-prefix NUMBER
+
+\1f
+File: quagga.info, Node: Peer filtering, Prev: BGP Peer commands, Up: BGP Peer
+
+9.4.3 Peer filtering
+--------------------
+
+ -- BGP: neighbor PEER distribute-list NAME [in|out]
+ This command specifies a distribute-list for the peer. DIRECT is
+ `in' or `out'.
+
+ -- BGP command: neighbor PEER prefix-list NAME [in|out]
+
+ -- BGP command: neighbor PEER filter-list NAME [in|out]
+
+ -- BGP: neighbor PEER route-map NAME [in|out]
+ Apply a route-map on the neighbor. DIRECT must be `in' or `out'.
+
+\1f
+File: quagga.info, Node: BGP Peer Group, Next: BGP Address Family, Prev: BGP Peer, Up: BGP
+
+9.5 BGP Peer Group
+==================
+
+ -- BGP: neighbor WORD peer-group
+ This command defines a new peer group.
+
+ -- BGP: neighbor PEER peer-group WORD
+ This command bind specific peer to peer group WORD.
+
+\1f
+File: quagga.info, Node: BGP Address Family, Next: Autonomous System, Prev: BGP Peer Group, Up: BGP
+
+9.6 BGP Address Family
+======================
+
+\1f
+File: quagga.info, Node: Autonomous System, Next: BGP Communities Attribute, Prev: BGP Address Family, Up: BGP
+
+9.7 Autonomous System
+=====================
+
+AS (Autonomous System) is one of the essential element of BGP. BGP is
+a distance vector routing protocol. AS framework provides distance
+vector metric and loop detection to BGP. `RFC1930' - `Guidelines for
+creation, selection, and registration of an Autonomous System (AS)'
+describes how to use AS.
+
+ AS number is tow octet digita value. So the value range is from 1
+to 65535. AS numbers 64512 through 65535 are defined as private AS
+numbers. Private AS numbers must not to be advertised in the global
+Internet.
+
+* Menu:
+
+* AS Path Regular Expression::
+* Display BGP Routes by AS Path::
+* AS Path Access List::
+* Using AS Path in Route Map::
+* Private AS Numbers::
+
+\1f
+File: quagga.info, Node: AS Path Regular Expression, Next: Display BGP Routes by AS Path, Up: Autonomous System
+
+9.7.1 AS Path Regular Expression
+--------------------------------
+
+AS path regular expression can be used for displaying BGP routes and AS
+path access list. AS path regular expression is based on `POSIX
+1003.2' regular expressions. Following description is just a subset of
+`POSIX' regular expression. User can use full `POSIX' regular
+expression. Adding to that special character '_' is added for AS path
+regular expression.
+
+`.'
+ Matches any single character.
+
+`*'
+ Matches 0 or more occurrences of pattern.
+
+`+'
+ Matches 1 or more occurrences of pattern.
+
+`?'
+ Match 0 or 1 occurrences of pattern.
+
+`^'
+ Matches the beginning of the line.
+
+`$'
+ Matches the end of the line.
+
+`_'
+ Character `_' has special meanings in AS path regular expression.
+ It matches to space and comma , and AS set delimiter { and } and AS
+ confederation delimiter `(' and `)'. And it also matches to the
+ beginning of the line and the end of the line. So `_' can be used
+ for AS value boundaries match. `show ip bgp regexp _7675_'
+ matches to all of BGP routes which as AS number include 7675.
+
+\1f
+File: quagga.info, Node: Display BGP Routes by AS Path, Next: AS Path Access List, Prev: AS Path Regular Expression, Up: Autonomous System
+
+9.7.2 Display BGP Routes by AS Path
+-----------------------------------
+
+To show BGP routes which has specific AS path information `show ip bgp'
+command can be used.
+
+ -- Command: show ip bgp regexp LINE
+ This commands display BGP routes that matches AS path regular
+ expression LINE.
+
+\1f
+File: quagga.info, Node: AS Path Access List, Next: Using AS Path in Route Map, Prev: Display BGP Routes by AS Path, Up: Autonomous System
+
+9.7.3 AS Path Access List
+-------------------------
+
+AS path access list is user defined AS path.
+
+ -- Command: ip as-path access-list WORD {permit|deny} LINE
+ This command defines a new AS path access list.
+
+ -- Command: no ip as-path access-list WORD
+ -- Command: no ip as-path access-list WORD {permit|deny} LINE
+
+\1f
+File: quagga.info, Node: Using AS Path in Route Map, Next: Private AS Numbers, Prev: AS Path Access List, Up: Autonomous System
+
+9.7.4 Using AS Path in Route Map
+--------------------------------
+
+ -- Route Map: match as-path WORD
+
+ -- Route Map: set as-path prepend AS-PATH
+
+\1f
+File: quagga.info, Node: Private AS Numbers, Prev: Using AS Path in Route Map, Up: Autonomous System
+
+9.7.5 Private AS Numbers
+------------------------
+
+\1f
+File: quagga.info, Node: BGP Communities Attribute, Next: BGP Extended Communities Attribute, Prev: Autonomous System, Up: BGP
+
+9.8 BGP Communities Attribute
+=============================
+
+BGP communities attribute is widely used for implementing policy
+routing. Network operators can manipulate BGP communities attribute
+based on their network policy. BGP communities attribute is defined in
+`RFC1997' - `BGP Communities Attribute' and `RFC1998' - `An Application
+of the BGP Community Attribute in Multi-home Routing'. It is an
+optional transitive attribute, therefore local policy can travel
+through different autonomous system.
+
+ Communities attribute is a set of communities values. Each
+communities value is 4 octet long. The following format is used to
+define communities value.
+
+`AS:VAL'
+ This format represents 4 octet communities value. `AS' is high
+ order 2 octet in digit format. `VAL' is low order 2 octet in
+ digit format. This format is useful to define AS oriented policy
+ value. For example, `7675:80' can be used when AS 7675 wants to
+ pass local policy value 80 to neighboring peer.
+
+`internet'
+ `internet' represents well-known communities value 0.
+
+`no-export'
+ `no-export' represents well-known communities value `NO_EXPORT'
+ (0xFFFFFF01). All routes carry this value must not be advertised
+ to outside a BGP confederation boundary. If neighboring BGP peer
+ is part of BGP confederation, the peer is considered as inside a
+ BGP confederation boundary, so the route will be announced to the
+ peer.
+
+`no-advertise'
+ `no-advertise' represents well-known communities value
+ `NO_ADVERTISE'
+ (0xFFFFFF02). All routes carry this value must not be advertise
+ to other BGP peers.
+
+`local-AS'
+ `local-AS' represents well-known communities value
+ `NO_EXPORT_SUBCONFED' (0xFFFFFF03). All routes carry this value
+ must not be advertised to external BGP peers. Even if the
+ neighboring router is part of confederation, it is considered as
+ external BGP peer, so the route will not be announced to the peer.
+
+ When BGP communities attribute is received, duplicated communities
+value in the communities attribute is ignored and each communities
+values are sorted in numerical order.
+
+* Menu:
+
+* BGP Community Lists::
+* Numbered BGP Community Lists::
+* BGP Community in Route Map::
+* Display BGP Routes by Community::
+* Using BGP Communities Attribute::
+
+\1f
+File: quagga.info, Node: BGP Community Lists, Next: Numbered BGP Community Lists, Up: BGP Communities Attribute
+
+9.8.1 BGP Community Lists
+-------------------------
+
+BGP community list is a user defined BGP communites attribute list.
+BGP community list can be used for matching or manipulating BGP
+communities attribute in updates.
+
+ There are two types of community list. One is standard community
+list and another is expanded community list. Standard community list
+defines communities attribute. Expanded community list defines
+communities attribute string with regular expression. Standard
+community list is compiled into binary format when user define it.
+Standard community list will be directly compared to BGP communities
+attribute in BGP updates. Therefore the comparison is faster than
+expanded community list.
+
+ -- Command: ip community-list standard NAME {permit|deny} COMMUNITY
+ This command defines a new standard community list. COMMUNITY is
+ communities value. The COMMUNITY is compiled into community
+ structure. We can define multiple community list under same name.
+ In that case match will happen user defined order. Once the
+ community list matches to communities attribute in BGP updates it
+ return permit or deny by the community list definition. When
+ there is no matched entry, deny will be returned. When COMMUNITY
+ is empty it matches to any routes.
+
+ -- Command: ip community-list expanded NAME {permit|deny} LINE
+ This command defines a new expanded community list. LINE is a
+ string expression of communities attribute. LINE can include
+ regular expression to match communities attribute in BGP updates.
+
+ -- Command: no ip community-list NAME
+ -- Command: no ip community-list standard NAME
+ -- Command: no ip community-list expanded NAME
+ These commands delete community lists specified by NAME. All of
+ community lists shares a single name space. So community lists
+ can be removed simpley specifying community lists name.
+
+ -- Command: show ip community-list
+ -- Command: show ip community-list NAME
+ This command display current community list information. When
+ NAME is specified the specified community list's information is
+ shown.
+
+ # show ip community-list
+ Named Community standard list CLIST
+ permit 7675:80 7675:100 no-export
+ deny internet
+ Named Community expanded list EXPAND
+ permit :
+
+ # show ip community-list CLIST
+ Named Community standard list CLIST
+ permit 7675:80 7675:100 no-export
+ deny internet
+
+\1f
+File: quagga.info, Node: Numbered BGP Community Lists, Next: BGP Community in Route Map, Prev: BGP Community Lists, Up: BGP Communities Attribute
+
+9.8.2 Numbered BGP Community Lists
+----------------------------------
+
+When number is used for BGP community list name, the number has special
+meanings. Community list number in the range from 1 and 99 is standard
+community list. Community list number in the range from 100 to 199 is
+expanded community list. These community lists are called as numbered
+community lists. On the other hand normal community lists is called as
+named community lists.
+
+ -- Command: ip community-list <1-99> {permit|deny} COMMUNITY
+ This command defines a new community list. <1-99> is standard
+ community list number. Community list name within this range
+ defines standard community list. When COMMUNITY is empty it
+ matches to any routes.
+
+ -- Command: ip community-list <100-199> {permit|deny} COMMUNITY
+ This command defines a new community list. <100-199> is expanded
+ community list number. Community list name within this range
+ defines expanded community list.
+
+ -- Command: ip community-list NAME {permit|deny} COMMUNITY
+ When community list type is not specifed, the community list type
+ is automatically detected. If COMMUNITY can be compiled into
+ communities attribute, the community list is defined as a standard
+ community list. Otherwise it is defined as an expanded community
+ list. This feature is left for backward compability. Use of this
+ feature is not recommended.
+
+\1f
+File: quagga.info, Node: BGP Community in Route Map, Next: Display BGP Routes by Community, Prev: Numbered BGP Community Lists, Up: BGP Communities Attribute
+
+9.8.3 BGP Community in Route Map
+--------------------------------
+
+In Route Map (*note Route Map::), we can match or set BGP communities
+attribute. Using this feature network operator can implement their
+network policy based on BGP communities attribute.
+
+ Following commands can be used in Route Map.
+
+ -- Route Map: match community WORD
+ -- Route Map: match community WORD exact-match
+ This command perform match to BGP updates using community list
+ WORD. When the one of BGP communities value match to the one of
+ communities value in community list, it is match. When
+ `exact-match' keyword is spcified, match happen only when BGP
+ updates have completely same communities value specified in the
+ community list.
+
+ -- Route Map: set community none
+ -- Route Map: set community COMMUNITY
+ -- Route Map: set community COMMUNITY additive
+ This command manipulate communities value in BGP updates. When
+ `none' is specified as communities value, it removes entire
+ communities attribute from BGP updates. When COMMUNITY is not
+ `none', specified communities value is set to BGP updates. If BGP
+ updates already has BGP communities value, the existing BGP
+ communities value is replaced with specified COMMUNITY value.
+ When `additive' keyword is specified, COMMUNITY is appended to the
+ existing communities value.
+
+ -- Route Map: set comm-list WORD delete
+ This command remove communities value from BGP communities
+ attribute. The WORD is community list name. When BGP route's
+ communities value matches to the community list WORD, the
+ communities value is removed. When all of communities value is
+ removed eventually, the BGP update's communities attribute is
+ completely removed.
+
+\1f
+File: quagga.info, Node: Display BGP Routes by Community, Next: Using BGP Communities Attribute, Prev: BGP Community in Route Map, Up: BGP Communities Attribute
+
+9.8.4 Display BGP Routes by Community
+-------------------------------------
+
+To show BGP routes which has specific BGP communities attribute, `show
+ip bgp' command can be used. The COMMUNITY value and community list
+can be used for `show ip bgp' command.
+
+ -- Command: show ip bgp community
+ -- Command: show ip bgp community COMMUNITY
+ -- Command: show ip bgp community COMMUNITY exact-match
+ `show ip bgp community' displays BGP routes which has communities
+ attribute. When COMMUNITY is specified, BGP routes that matches
+ COMMUNITY value is displayed. For this command, `internet'
+ keyword can't be used for COMMUNITY value. When `exact-match' is
+ specified, it display only routes that have an exact match.
+
+ -- Command: show ip bgp community-list WORD
+ -- Command: show ip bgp community-list WORD exact-match
+ This commands display BGP routes that matches community list WORD.
+ When `exact-match' is specified, display only routes that have an
+ exact match.
+
+\1f
+File: quagga.info, Node: Using BGP Communities Attribute, Prev: Display BGP Routes by Community, Up: BGP Communities Attribute
+
+9.8.5 Using BGP Communities Attribute
+-------------------------------------
+
+Following configuration is the most typical usage of BGP communities
+attribute. AS 7675 provides upstream Internet connection to AS 100.
+When following configuration exists in AS 7675, AS 100 networks
+operator can set local preference in AS 7675 network by setting BGP
+communities attribute to the updates.
+
+ router bgp 7675
+ neighbor 192.168.0.1 remote-as 100
+ neighbor 192.168.0.1 route-map RMAP in
+ !
+ ip community-list 70 permit 7675:70
+ ip community-list 70 deny
+ ip community-list 80 permit 7675:80
+ ip community-list 80 deny
+ ip community-list 90 permit 7675:90
+ ip community-list 90 deny
+ !
+ route-map RMAP permit 10
+ match community 70
+ set local-preference 70
+ !
+ route-map RMAP permit 20
+ match community 80
+ set local-preference 80
+ !
+ route-map RMAP permit 30
+ match community 90
+ set local-preference 90
+
+ Following configuration announce 10.0.0.0/8 from AS 100 to AS 7675.
+The route has communities value 7675:80 so when above configuration
+exists in AS 7675, announced route's local preference will be set to
+value 80.
+
+ router bgp 100
+ network 10.0.0.0/8
+ neighbor 192.168.0.2 remote-as 7675
+ neighbor 192.168.0.2 route-map RMAP out
+ !
+ ip prefix-list PLIST permit 10.0.0.0/8
+ !
+ route-map RMAP permit 10
+ match ip address prefix-list PLIST
+ set community 7675:80
+
+ Following configuration is an example of BGP route filtering using
+communities attribute. This configuration only permit BGP routes which
+has BGP communities value 0:80 or 0:90. Network operator can put
+special internal communities value at BGP border router, then limit the
+BGP routes announcement into the internal network.
+
+ router bgp 7675
+ neighbor 192.168.0.1 remote-as 100
+ neighbor 192.168.0.1 route-map RMAP in
+ !
+ ip community-list 1 permit 0:80 0:90
+ !
+ route-map RMAP permit in
+ match community 1
+
+ Following exmaple filter BGP routes which has communities value 1:1.
+When there is no match community-list returns deny. To avoid filtering
+all of routes, we need to define permit any at last.
+
+ router bgp 7675
+ neighbor 192.168.0.1 remote-as 100
+ neighbor 192.168.0.1 route-map RMAP in
+ !
+ ip community-list standard FILTER deny 1:1
+ ip community-list standard FILTER permit
+ !
+ route-map RMAP permit 10
+ match community FILTER
+
+ Communities value keyword `internet' has special meanings in
+standard community lists. In below example `internet' act as match
+any. It matches all of BGP routes even if the route does not have
+communities attribute at all. So community list `INTERNET' is same as
+above example's `FILTER'.
+
+ ip community-list standard INTERNET deny 1:1
+ ip community-list standard INTERNET permit internet
+
+ Following configuration is an example of communities value deletion.
+With this configuration communities value 100:1 and 100:2 is removed
+from BGP updates. For communities value deletion, only `permit'
+community-list is used. `deny' community-list is ignored.
+
+ router bgp 7675
+ neighbor 192.168.0.1 remote-as 100
+ neighbor 192.168.0.1 route-map RMAP in
+ !
+ ip community-list standard DEL permit 100:1 100:2
+ !
+ route-map RMAP permit 10
+ set comm-list DEL delete
+
+\1f
+File: quagga.info, Node: BGP Extended Communities Attribute, Next: Displaying BGP routes, Prev: BGP Communities Attribute, Up: BGP
+
+9.9 BGP Extended Communities Attribute
+======================================
+
+BGP extended communities attribute is introduced with MPLS VPN/BGP
+technology. MPLS VPN/BGP expands capability of network infrastructure
+to provide VPN functionality. At the same time it requires a new
+framework for policy routing. With BGP Extended Communities Attribute
+we can use Route Target or Site of Origin for implementing network
+policy for MPLS VPN/BGP.
+
+ BGP Extended Communities Attribute is similar to BGP Communities
+Attribute. It is an optional transitive attribute. BGP Extended
+Communities Attribute can carry multiple Extended Community value.
+Each Extended Community value is eight octet length.
+
+ BGP Extended Communities Attribute provides an extended range
+compared with BGP Communities Attribute. Adding to that there is a
+type field in each value to provides community space structure.
+
+ There are two format to define Extended Community value. One is AS
+based format the other is IP address based format.
+
+`AS:VAL'
+ This is a format to define AS based Extended Community value.
+ `AS' part is 2 octets Global Administrator subfield in Extended
+ Community value. `VAL' part is 4 octets Local Administrator
+ subfield. `7675:100' represents AS 7675 policy value 100.
+
+`IP-Address:VAL'
+ This is a format to define IP address based Extended Community
+ value. `IP-Address' part is 4 octets Global Administrator
+ subfield. `VAL' part is 2 octets Local Administrator subfield.
+ `10.0.0.1:100' represents
+
+* Menu:
+
+* BGP Extended Community Lists::
+* BGP Extended Communities in Route Map::
+
+\1f
+File: quagga.info, Node: BGP Extended Community Lists, Next: BGP Extended Communities in Route Map, Up: BGP Extended Communities Attribute
+
+9.9.1 BGP Extended Community Lists
+----------------------------------
+
+Expanded Community Lists is a user defined BGP Expanded Community Lists.
+
+ -- Command: ip extcommunity-list standard NAME {permit|deny}
+EXTCOMMUNITY
+ This command defines a new standard extcommunity-list.
+ EXTCOMMUNITY is extended communities value. The EXTCOMMUNITY is
+ compiled into extended community structure. We can define
+ multiple extcommunity-list under same name. In that case match
+ will happen user defined order. Once the extcommunity-list
+ matches to extended communities attribute in BGP updates it return
+ permit or deny based upon the extcommunity-list definition. When
+ there is no matched entry, deny will be returned. When
+ EXTCOMMUNITY is empty it matches to any routes.
+
+ -- Command: ip extcommunity-list expanded NAME {permit|deny} LINE
+ This command defines a new expanded extcommunity-list. LINE is a
+ string expression of extended communities attribute. LINE can
+ include regular expression to match extended communities attribute
+ in BGP updates.
+
+ -- Command: no ip extcommunity-list NAME
+ -- Command: no ip extcommunity-list standard NAME
+ -- Command: no ip extcommunity-list expanded NAME
+ These commands delete extended community lists specified by NAME.
+ All of extended community lists shares a single name space. So
+ extended community lists can be removed simpley specifying the
+ name.
+
+ -- Command: show ip extcommunity-list
+ -- Command: show ip extcommunity-list NAME
+ This command display current extcommunity-list information. When
+ NAME is specified the community list's information is shown.
+
+ # show ip extcommunity-list
+
+\1f
+File: quagga.info, Node: BGP Extended Communities in Route Map, Prev: BGP Extended Community Lists, Up: BGP Extended Communities Attribute
+
+9.9.2 BGP Extended Communities in Route Map
+-------------------------------------------
+
+ -- Route Map: match extcommunity WORD
+
+ -- Route Map: set extcommunity rt EXTCOMMUNITY
+ This command set Route Target value.
+
+ -- Route Map: set extcommunity soo EXTCOMMUNITY
+ This command set Site of Origin value.
+
+\1f
+File: quagga.info, Node: Displaying BGP routes, Next: Capability Negotiation, Prev: BGP Extended Communities Attribute, Up: BGP
+
+9.10 Displaying BGP Routes
+==========================
+
+* Menu:
+
+* Show IP BGP::
+* More Show IP BGP::
+
+\1f
+File: quagga.info, Node: Show IP BGP, Next: More Show IP BGP, Up: Displaying BGP routes
+
+9.10.1 Show IP BGP
+------------------
+
+ -- Command: show ip bgp
+ -- Command: show ip bgp A.B.C.D
+ -- Command: show ip bgp X:X::X:X
+ This command displays BGP routes. When no route is specified it
+ display all of IPv4 BGP routes.
+
+ BGP table version is 0, local router ID is 10.1.1.1
+ Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
+ Origin codes: i - IGP, e - EGP, ? - incomplete
+
+ Network Next Hop Metric LocPrf Weight Path
+ *> 1.1.1.1/32 0.0.0.0 0 32768 i
+
+ Total number of prefixes 1
+
+\1f
+File: quagga.info, Node: More Show IP BGP, Prev: Show IP BGP, Up: Displaying BGP routes
+
+9.10.2 More Show IP BGP
+-----------------------
+
+ -- Command: show ip bgp regexp LINE
+ This command display BGP routes using AS path regular expression
+ (*note Display BGP Routes by AS Path::).
+
+ -- Command: show ip bgp community COMMUNITY
+ -- Command: show ip bgp community COMMUNITY exact-match
+ This command display BGP routes using COMMUNITY (*note Display BGP
+ Routes by Community::).
+
+ -- Command: show ip bgp community-list WORD
+ -- Command: show ip bgp community-list WORD exact-match
+ This command display BGP routes using community list (*note
+ Display BGP Routes by Community::).
+
+ -- Command: show ip bgp summary
+
+ -- Command: show ip bgp neighbor [PEER]
+
+ -- Command: clear ip bgp PEER
+ Clear peers which have addresses of X.X.X.X
+
+ -- Command: clear ip bgp PEER soft in
+ Clear peer using soft reconfiguration.
+
+ -- Command: show debug
+
+ -- Command: debug event
+
+ -- Command: debug update
+
+ -- Command: debug keepalive
+
+ -- Command: no debug event
+
+ -- Command: no debug update
+
+ -- Command: no debug keepalive
+
+\1f
+File: quagga.info, Node: Capability Negotiation, Next: Route Reflector, Prev: Displaying BGP routes, Up: BGP
+
+9.11 Capability Negotiation
+===========================
+
+When adding IPv6 routing information exchange feature to BGP. There
+were some proposals. IETF IDR working group finally take a proposal
+called Multiprotocol Extension for BGP. The specification is described
+in RFC2283. The protocol does not define new protocols. It defines
+new attributes to existing BGP. When it is used exchanging IPv6
+routing information it is called BGP-4+. When it is used for
+exchanging multicast routing information it is called MBGP.
+
+ `bgpd' supports Multiprotocol Extension for BGP. So if remote peer
+supports the protocol, `bgpd' can exchange IPv6 and/or multicast routing
+information.
+
+ Traditional BGP does not have the feature to detect remote peer's
+capability whether it can handle other than IPv4 unicast routes. This
+is a big problem using Multiprotocol Extension for BGP to operational
+network. `draft-ietf-idr-bgp4-cap-neg-04.txt' is proposing a feature
+called Capability Negotiation. `bgpd' use this Capability Negotiation
+to detect remote peer's capabilities. If the peer is only configured
+as IPv4 unicast neighbor, `bgpd' does not send these Capability
+Negotiation packets.
+
+ By default, Quagga will bring up peering with minimal common
+capability for the both sides. For example, local router has unicast
+and multicast capabilitie and remote router has unicast capability. In
+this case, the local router will establish the connection with unicast
+only capability. When there are no common capabilities, Quagga sends
+Unsupported Capability error and then resets the connection.
+
+ If you want to completely match capabilities with remote peer.
+Please use `strict-capability-match' command.
+
+ -- BGP: neighbor PEER strict-capability-match
+ -- BGP: no neighbor PEER strict-capability-match
+ Strictly compares remote capabilities and local capabilities. If
+ capabilities are different, send Unsupported Capability error then
+ reset connection.
+
+ You may want to disable sending Capability Negotiation OPEN message
+optional parameter to the peer when remote peer does not implement
+Capability Negotiation. Please use `dont-capability-negotiate' command
+to disable the feature.
+
+ -- BGP: neighbor PEER dont-capability-negotiate
+ -- BGP: no neighbor PEER dont-capability-negotiate
+ Suppress sending Capability Negotiation as OPEN message optional
+ parameter to the peer. This command only affects the peer is
+ configured other than IPv4 unicast configuration.
+
+ When remote peer does not have capability negotiation feature, remote
+peer will not send any capabilities at all. In that case, bgp
+configures the peer with configured capabilities.
+
+ You may prefer locally configured capabilities more than the
+negotiated capabilities even though remote peer sends capabilities. If
+the peer is configured by `override-capability', `bgpd' ignores received
+capabilities then override negotiated capabilities with configured
+values.
+
+ -- BGP: neighbor PEER override-capability
+ -- BGP: no neighbor PEER override-capability
+ Override the result of Capability Negotiation with local
+ configuration. Ignore remote peer's capability value.
+
+\1f
+File: quagga.info, Node: Route Reflector, Next: Route Server, Prev: Capability Negotiation, Up: BGP
+
+9.12 Route Reflector
+====================
+
+ -- BGP: bgp cluster-id A.B.C.D
+
+ -- BGP: neighbor PEER route-reflector-client
+ -- BGP: no neighbor PEER route-reflector-client
+
+\1f
+File: quagga.info, Node: Route Server, Next: How to set up a 6-Bone connection, Prev: Route Reflector, Up: BGP
+
+9.13 Route Server
+=================
+
+At an Internet Exchange point, many ISPs are connected to each other by
+external BGP peering. Normally these external BGP connection are done
+by `full mesh' method. As with internal BGP full mesh formation, this
+method has a scaling problem.
+
+ This scaling problem is well known. Route Server is a method to
+resolve the problem. Each ISP's BGP router only peers to Route Server.
+Route Server serves as BGP information exchange to other BGP routers.
+By applying this method, numbers of BGP connections is reduced from
+O(n*(n-1)/2) to O(n).
+
+ Unlike normal BGP router, Route Server must have several routing
+tables for managing different routing policies for each BGP speaker.
+We call the routing tables as different `view's. `bgpd' can work as
+normal BGP router or Route Server or both at the same time.
+
+* Menu:
+
+* Multiple instance::
+* BGP instance and view::
+* Routing policy::
+* Viewing the view::
+
+\1f
+File: quagga.info, Node: Multiple instance, Next: BGP instance and view, Up: Route Server
+
+9.13.1 Multiple instance
+------------------------
+
+To enable multiple view function of `bgpd', you must turn on multiple
+instance feature beforehand.
+
+ -- Command: bgp multiple-instance
+ Enable BGP multiple instance feature. After this feature is
+ enabled, you can make multiple BGP instances or multiple BGP views.
+
+ -- Command: no bgp multiple-instance
+ Disable BGP multiple instance feature. You can not disable this
+ feature when BGP multiple instances or views exist.
+
+ When you want to make configuration more Cisco like one,
+
+ -- Command: bgp config-type cisco
+ Cisco compatible BGP configuration output.
+
+ When bgp config-type cisco is specified,
+
+ "no synchronization" is displayed. "no auto-summary" is desplayed.
+
+ "network" and "aggregate-address" argument is displayed as "A.B.C.D
+M.M.M.M"
+
+ Quagga: network 10.0.0.0/8 Cisco: network 10.0.0.0
+
+ Quagga: aggregate-address 192.168.0.0/24 Cisco: aggregate-address
+192.168.0.0 255.255.255.0
+
+ Community attribute handling is also different. If there is no
+configuration is specified community attribute and extended community
+attribute are sent to neighbor. When user manually disable the feature
+community attribute is not sent to the neighbor. In case of "bgp
+config-type cisco" is specified, community attribute is not sent to the
+neighbor by default. To send community attribute user has to specify
+"neighbor A.B.C.D send-community" command.
+
+ ! router bgp 1 neighbor 10.0.0.1 remote-as 1 no neighbor 10.0.0.1
+send-community !
+
+ ! router bgp 1 neighbor 10.0.0.1 remote-as 1 neighbor 10.0.0.1
+send-community !
+
+ -- Command: bgp config-type zebra
+ Quagga style BGP configuration. This is default.
+
+\1f
+File: quagga.info, Node: BGP instance and view, Next: Routing policy, Prev: Multiple instance, Up: Route Server
+
+9.13.2 BGP instance and view
+----------------------------
+
+BGP instance is a normal BGP process. The result of route selection
+goes to the kernel routing table. You can setup different AS at the
+same time when BGP multiple instance feature is enabled.
+
+ -- Command: router bgp AS-NUMBER
+ Make a new BGP instance. You can use arbitrary word for the NAME.
+
+ bgp multiple-instance
+ !
+ router bgp 1
+ neighbor 10.0.0.1 remote-as 2
+ neighbor 10.0.0.2 remote-as 3
+ !
+ router bgp 2
+ neighbor 10.0.0.3 remote-as 4
+ neighbor 10.0.0.4 remote-as 5
+
+ BGP view is almost same as normal BGP process. The result of route
+selection does not go to the kernel routing table. BGP view is only
+for exchanging BGP routing information.
+
+ -- Command: router bgp AS-NUMBER view NAME
+ Make a new BGP view. You can use arbitrary word for the NAME.
+ This view's route selection result does not go to the kernel
+ routing table.
+
+ With this command, you can setup Route Server like below.
+
+ bgp multiple-instance
+ !
+ router bgp 1 view 1
+ neighbor 10.0.0.1 remote-as 2
+ neighbor 10.0.0.2 remote-as 3
+ !
+ router bgp 2 view 2
+ neighbor 10.0.0.3 remote-as 4
+ neighbor 10.0.0.4 remote-as 5
+
+\1f
+File: quagga.info, Node: Routing policy, Next: Viewing the view, Prev: BGP instance and view, Up: Route Server
+
+9.13.3 Routing policy
+---------------------
+
+You can set different routing policy for a peer. For example, you can
+set different filter for a peer.
+
+ bgp multiple-instance
+ !
+ router bgp 1 view 1
+ neighbor 10.0.0.1 remote-as 2
+ neighbor 10.0.0.1 distribute-list 1 in
+ !
+ router bgp 1 view 2
+ neighbor 10.0.0.1 remote-as 2
+ neighbor 10.0.0.1 distribute-list 2 in
+
+ This means BGP update from a peer 10.0.0.1 goes to both BGP view 1
+and view 2. When the update is inserted into view 1, distribute-list 1
+is applied. On the other hand, when the update is inserted into view 2,
+distribute-list 2 is applied.
+
+\1f
+File: quagga.info, Node: Viewing the view, Prev: Routing policy, Up: Route Server
+
+9.13.4 Viewing the view
+-----------------------
+
+To display routing table of BGP view, you must specify view name.
+
+ -- Command: show ip bgp view NAME
+ Display routing table of BGP view NAME.
+
+\1f
+File: quagga.info, Node: How to set up a 6-Bone connection, Next: Dump BGP packets and table, Prev: Route Server, Up: BGP
+
+9.14 How to set up a 6-Bone connection
+======================================
+
+ zebra configuration
+ ===================
+ !
+ ! Actually there is no need to configure zebra
+ !
+
+ bgpd configuration
+ ==================
+ !
+ ! This means that routes go through zebra and into the kernel.
+ !
+ router zebra
+ !
+ ! MP-BGP configuration
+ !
+ router bgp 7675
+ bgp router-id 10.0.0.1
+ neighbor 3ffe:1cfa:0:2:2a0:c9ff:fe9e:f56 remote-as AS-NUMBER
+ !
+ address-family ipv6
+ network 3ffe:506::/32
+ neighbor 3ffe:1cfa:0:2:2a0:c9ff:fe9e:f56 activate
+ neighbor 3ffe:1cfa:0:2:2a0:c9ff:fe9e:f56 route-map set-nexthop out
+ neighbor 3ffe:1cfa:0:2:2c0:4fff:fe68:a231 remote-as AS-NUMBER
+ neighbor 3ffe:1cfa:0:2:2c0:4fff:fe68:a231 route-map set-nexthop out
+ exit-address-family
+ !
+ ipv6 access-list all permit any
+ !
+ ! Set output nexthop address.
+ !
+ route-map set-nexthop permit 10
+ match ipv6 address all
+ set ipv6 nexthop global 3ffe:1cfa:0:2:2c0:4fff:fe68:a225
+ set ipv6 nexthop local fe80::2c0:4fff:fe68:a225
+ !
+ ! logfile FILENAME is obsolete. Please use log file FILENAME
+
+ log file bgpd.log
+ !
+
+\1f
+File: quagga.info, Node: Dump BGP packets and table, Prev: How to set up a 6-Bone connection, Up: BGP
+
+9.15 Dump BGP packets and table
+===============================
+
+ -- Command: dump bgp all PATH
+ -- Command: dump bgp all PATH INTERVAL
+ Dump all BGP packet and events to PATH file.
+
+ -- Command: dump bgp updates PATH
+ -- Command: dump bgp updates PATH INTERVAL
+ Dump BGP updates to PATH file.
+
+ -- Command: dump bgp routes PATH
+ -- Command: dump bgp routes PATH
+ Dump whole BGP routing table to PATH. This is heavy process.
+
+\1f
+File: quagga.info, Node: Configuring Quagga as a Route Server, Next: VTY shell, Prev: BGP, Up: Top
+
+10 Configuring Quagga as a Route Server
+***************************************
+
+The purpose of a Route Server is to centralize the peerings between BGP
+speakers. For example if we have an exchange point scenario with four
+BGP speakers, each of which maintaining a BGP peering with the other
+three (*note fig:full-mesh::), we can convert it into a centralized
+scenario where each of the four establishes a single BGP peering
+against the Route Server (*note fig:route-server::).
+
+ We will first describe briefly the Route Server model implemented by
+Quagga. We will explain the commands that have been added for
+configuring that model. And finally we will show a full example of
+Quagga configured as Route Server.
+
+* Menu:
+
+* Description of the Route Server model::
+* Commands for configuring a Route Server::
+* Example of Route Server Configuration::
+
+\1f
+File: quagga.info, Node: Description of the Route Server model, Next: Commands for configuring a Route Server, Up: Configuring Quagga as a Route Server
+
+10.1 Description of the Route Server model
+==========================================
+
+First we are going to describe the normal processing that BGP
+announcements suffer inside a standard BGP speaker, as shown in *Note
+fig:normal-processing::, it consists of three steps:
+
+ * When an announcement is received from some peer, the `In' filters
+ configured for that peer are applied to the announcement. These
+ filters can reject the announcement, accept it unmodified, or
+ accept it with some of its attributes modified.
+
+ * The announcements that pass the `In' filters go into the Best Path
+ Selection process, where they are compared to other announcements
+ referred to the same destination that have been received from
+ different peers (in case such other announcements exist). For each
+ different destination, the announcement which is selected as the
+ best is inserted into the BGP speaker's Loc-RIB.
+
+ * The routes which are inserted in the Loc-RIB are considered for
+ announcement to all the peers (except the one from which the route
+ came). This is done by passing the routes in the Loc-RIB through
+ the `Out' filters corresponding to each peer. These filters can
+ reject the route, accept it unmodified, or accept it with some of
+ its attributes modified. Those routes which are accepted by the
+ `Out' filters of a peer are announced to that peer.
+
+\0\b[image src="fig-normal-processing.eps" alt="Normal announcement processing"\0\b]
+
+Figure 10.1: Announcement processing inside a "normal" BGP speaker
+
+\0\b[image src="fig_topologies_full.eps" alt="Full Mesh BGP Topology"\0\b]
+
+Figure 10.2: Full Mesh
+
+\0\b[image src="fig_topologies_rs.eps" alt="Route Server BGP Topology"\0\b]
+
+Figure 10.3: Route Server and clients
+
+ Of course we want that the routing tables obtained in each of the
+routers are the same when using the route server than when not. But as
+a consequence of having a single BGP peering (against the route
+server), the BGP speakers can no longer distinguish from/to which peer
+each announce comes/goes. This means that the routers connected to the
+route server are not able to apply by themselves the same input/output
+filters as in the full mesh scenario, so they have to delegate those
+functions to the route server.
+
+ Even more, the "best path" selection must be also performed inside
+the route server on behalf of its clients. The reason is that if, after
+applying the filters of the announcer and the (potential) receiver, the
+route server decides to send to some client two or more different
+announcements referred to the same destination, the client will only
+retain the last one, considering it as an implicit withdrawal of the
+previous announcements for the same destination. This is the expected
+behavior of a BGP speaker as defined in `RFC1771', and even though
+there are some proposals of mechanisms that permit multiple paths for
+the same destination to be sent through a single BGP peering, none of
+them are currently supported by most of the existing BGP
+implementations.
+
+ As a consequence a route server must maintain additional information
+and perform additional tasks for a RS-client that those necessary for
+common BGP peerings. Essentially a route server must:
+
+ * Maintain a separated Routing Information Base (Loc-RIB) for each
+ peer configured as RS-client, containing the routes selected as a
+ result of the "Best Path Selection" process that is performed on
+ behalf of that RS-client.
+
+ * Whenever it receives an announcement from a RS-client, it must
+ consider it for the Loc-RIBs of the other RS-clients.
+
+ * This means that for each of them the route server must pass
+ the announcement through the appropriate `Out' filter of the
+ announcer.
+
+ * Then through the appropriate `In' filter of the potential
+ receiver.
+
+ * Only if the announcement is accepted by both filters it will
+ be passed to the "Best Path Selection" process.
+
+ * Finally, it might go into the Loc-RIB of the receiver.
+
+ When we talk about the "appropriate" filter, both the announcer and
+the receiver of the route must be taken into account. Suppose that the
+route server receives an announcement from client A, and the route
+server is considering it for the Loc-RIB of client B. The filters that
+should be applied are the same that would be used in the full mesh
+scenario, i.e., first the `Out' filter of router A for announcements
+going to router B, and then the `In' filter of router B for
+announcements coming from router A.
+
+ We call "Export Policy" of a RS-client to the set of `Out' filters
+that the client would use if there was no route server. The same
+applies for the "Import Policy" of a RS-client and the set of `In'
+filters of the client if there was no route server.
+
+ It is also common to demand from a route server that it does not
+modify some BGP attributes (next-hop, as-path and MED) that are usually
+modified by standard BGP speakers before announcing a route.
+
+ The announcement processing model implemented by Quagga is shown in
+*Note fig:rs-processing::. The figure shows a mixture of RS-clients (B,
+C and D) with normal BGP peers (A). There are some details that worth
+additional comments:
+
+ * Announcements coming from a normal BGP peer are also considered
+ for the Loc-RIBs of all the RS-clients. But logically they do not
+ pass through any export policy.
+
+ * Those peers that are configured as RS-clients do not receive any
+ announce from the `Main' Loc-RIB.
+
+ * Apart from import and export policies, `In' and `Out' filters can
+ also be set for RS-clients. `In' filters might be useful when the
+ route server has also normal BGP peers. On the other hand, `Out'
+ filters for RS-clients are probably unnecessary, but we decided
+ not to remove them as they do not hurt anybody (they can always be
+ left empty).
+
+\0\b[image src="fig-rs-processing.eps"\0\b]
+
+Figure 10.4: Announcement processing model implemented by the Route Server
+
+\1f
+File: quagga.info, Node: Commands for configuring a Route Server, Next: Example of Route Server Configuration, Prev: Description of the Route Server model, Up: Configuring Quagga as a Route Server
+
+10.2 Commands for configuring a Route Server
+============================================
+
+Now we will describe the commands that have been added to quagga in
+order to support the route server features.
+
+ -- Route-Server: neighbor PEER-GROUP route-server-client
+ -- Route-Server: neighbor A.B.C.D route-server-client
+ -- Route-Server: neighbor X:X::X:X route-server-client
+ This command configures the peer given by PEER, A.B.C.D or
+ X:X::X:X as an RS-client.
+
+ Actually this command is not new, it already existed in standard
+ Quagga. It enables the transparent mode for the specified peer.
+ This means that some BGP attributes (as-path, next-hop and MED) of
+ the routes announced to that peer are not modified.
+
+ With the route server patch, this command, apart from setting the
+ transparent mode, creates a new Loc-RIB dedicated to the specified
+ peer (those named `Loc-RIB for X' in *Note Figure 10.4:
+ fig:rs-processing.). Starting from that moment, every announcement
+ received by the route server will be also considered for the new
+ Loc-RIB.
+
+ -- Route-Server: neigbor {A.B.C.D|X.X::X.X|peer-group} route-map WORD
+{import|export}
+ This set of commands can be used to specify the route-map that
+ represents the Import or Export policy of a peer which is
+ configured as a RS-client (with the previous command).
+
+ -- Route-Server: match peer {A.B.C.D|X:X::X:X}
+ This is a new _match_ statement for use in route-maps, enabling
+ them to describe import/export policies. As we said before, an
+ import/export policy represents a set of input/output filters of
+ the RS-client. This statement makes possible that a single
+ route-map represents the full set of filters that a BGP speaker
+ would use for its different peers in a non-RS scenario.
+
+ The _match peer_ statement has different semantics whether it is
+ used inside an import or an export route-map. In the first case
+ the statement matches if the address of the peer who sends the
+ announce is the same that the address specified by
+ {A.B.C.D|X:X::X:X}. For export route-maps it matches when
+ {A.B.C.D|X:X::X:X} is the address of the RS-Client into whose
+ Loc-RIB the announce is going to be inserted (how the same export
+ policy is applied before different Loc-RIBs is shown in *Note
+ Figure 10.4: fig:rs-processing.).
+
+ -- Route-map Command: call WORD
+ This command (also used inside a route-map) jumps into a different
+ route-map, whose name is specified by WORD. When the called
+ route-map finishes, depending on its result the original route-map
+ continues or not. Apart from being useful for making import/export
+ route-maps easier to write, this command can also be used inside
+ any normal (in or out) route-map.
+
+\1f
+File: quagga.info, Node: Example of Route Server Configuration, Prev: Commands for configuring a Route Server, Up: Configuring Quagga as a Route Server
+
+10.3 Example of Route Server Configuration
+==========================================
+
+Finally we are going to show how to configure a Quagga daemon to act as
+a Route Server. For this purpose we are going to present a scenario
+without route server, and then we will show how to use the
+configurations of the BGP routers to generate the configuration of the
+route server.
+
+ All the configuration files shown in this section have been taken
+from scenarios which were tested using the VNUML tool VNUML
+(http://www.dit.upm.es/vnuml).
+
+* Menu:
+
+* Configuration of the BGP routers without Route Server::
+* Configuration of the BGP routers with Route Server::
+* Configuration of the Route Server itself::
+* Further considerations about Import and Export route-maps::
+
+\1f
+File: quagga.info, Node: Configuration of the BGP routers without Route Server, Next: Configuration of the BGP routers with Route Server, Up: Example of Route Server Configuration
+
+10.3.1 Configuration of the BGP routers without Route Server
+------------------------------------------------------------
+
+We will suppose that our initial scenario is an exchange point with
+three BGP capable routers, named RA, RB and RC. Each of the BGP
+speakers generates some routes (with the NETWORK command), and
+establishes BGP peerings against the other two routers. These peerings
+have In and Out route-maps configured, named like "PEER-X-IN" or
+"PEER-X-OUT". For example the configuration file for router RA could be
+the following:
+
+ #Configuration for router 'RA'
+ !
+ hostname RA
+ password ****
+ !
+ router bgp 65001
+ no bgp default ipv4-unicast
+ neighbor 2001:0DB8::B remote-as 65002
+ neighbor 2001:0DB8::C remote-as 65003
+ !
+ address-family ipv6
+ network 2001:0DB8:AAAA:1::/64
+ network 2001:0DB8:AAAA:2::/64
+ network 2001:0DB8:0000:1::/64
+ network 2001:0DB8:0000:2::/64
+
+ neighbor 2001:0DB8::B activate
+ neighbor 2001:0DB8::B soft-reconfiguration inbound
+ neighbor 2001:0DB8::B route-map PEER-B-IN in
+ neighbor 2001:0DB8::B route-map PEER-B-OUT out
+
+ neighbor 2001:0DB8::C activate
+ neighbor 2001:0DB8::C soft-reconfiguration inbound
+ neighbor 2001:0DB8::C route-map PEER-C-IN in
+ neighbor 2001:0DB8::C route-map PEER-C-OUT out
+ exit-address-family
+ !
+ ipv6 prefix-list COMMON-PREFIXES seq 5 permit 2001:0DB8:0000::/48 ge 64 le 64
+ ipv6 prefix-list COMMON-PREFIXES seq 10 deny any
+ !
+ ipv6 prefix-list PEER-A-PREFIXES seq 5 permit 2001:0DB8:AAAA::/48 ge 64 le 64
+ ipv6 prefix-list PEER-A-PREFIXES seq 10 deny any
+ !
+ ipv6 prefix-list PEER-B-PREFIXES seq 5 permit 2001:0DB8:BBBB::/48 ge 64 le 64
+ ipv6 prefix-list PEER-B-PREFIXES seq 10 deny any
+ !
+ ipv6 prefix-list PEER-C-PREFIXES seq 5 permit 2001:0DB8:CCCC::/48 ge 64 le 64
+ ipv6 prefix-list PEER-C-PREFIXES seq 10 deny any
+ !
+ route-map PEER-B-IN permit 10
+ match ipv6 address prefix-list COMMON-PREFIXES
+ set metric 100
+ route-map PEER-B-IN permit 20
+ match ipv6 address prefix-list PEER-B-PREFIXES
+ set community 65001:11111
+ !
+ route-map PEER-C-IN permit 10
+ match ipv6 address prefix-list COMMON-PREFIXES
+ set metric 200
+ route-map PEER-C-IN permit 20
+ match ipv6 address prefix-list PEER-C-PREFIXES
+ set community 65001:22222
+ !
+ route-map PEER-B-OUT permit 10
+ match ipv6 address prefix-list PEER-A-PREFIXES
+ !
+ route-map PEER-C-OUT permit 10
+ match ipv6 address prefix-list PEER-A-PREFIXES
+ !
+ line vty
+ !
+
+\1f
+File: quagga.info, Node: Configuration of the BGP routers with Route Server, Next: Configuration of the Route Server itself, Prev: Configuration of the BGP routers without Route Server, Up: Example of Route Server Configuration
+
+10.3.2 Configuration of the BGP routers with Route Server
+---------------------------------------------------------
+
+To convert the initial scenario into one with route server, first we
+must modify the configuration of routers RA, RB and RC. Now they must
+not peer between them, but only with the route server. For example, RA's
+configuration would turn into:
+
+ # Configuration for router 'RA'
+ !
+ hostname RA
+ password ****
+ !
+ router bgp 65001
+ no bgp default ipv4-unicast
+ neighbor 2001:0DB8::FFFF remote-as 65000
+ !
+ address-family ipv6
+ network 2001:0DB8:AAAA:1::/64
+ network 2001:0DB8:AAAA:2::/64
+ network 2001:0DB8:0000:1::/64
+ network 2001:0DB8:0000:2::/64
+
+ neighbor 2001:0DB8::FFFF activate
+ neighbor 2001:0DB8::FFFF soft-reconfiguration inbound
+ exit-address-family
+ !
+ line vty
+ !
+
+ Which is logically much simpler than its initial configuration, as
+it now maintains only one BGP peering and all the filters (route-maps)
+have disappeared.
+
+\1f
+File: quagga.info, Node: Configuration of the Route Server itself, Next: Further considerations about Import and Export route-maps, Prev: Configuration of the BGP routers with Route Server, Up: Example of Route Server Configuration
+
+10.3.3 Configuration of the Route Server itself
+-----------------------------------------------
+
+As we said when we described the functions of a route server (*note
+Description of the Route Server model::), it is in charge of all the
+route filtering. To achieve that, the In and Out filters from the RA,
+RB and RC configurations must be converted into Import and Export
+policies in the route server.
+
+ This is a fragment of the route server configuration (we only show
+the policies for client RA):
+
+ # Configuration for Route Server ('RS')
+ !
+ hostname RS
+ password ix
+ !
+ bgp multiple-instance
+ !
+ router bgp 65000 view RS
+ no bgp default ipv4-unicast
+ neighbor 2001:0DB8::A remote-as 65001
+ neighbor 2001:0DB8::B remote-as 65002
+ neighbor 2001:0DB8::C remote-as 65003
+ !
+ address-family ipv6
+ neighbor 2001:0DB8::A activate
+ neighbor 2001:0DB8::A route-server-client
+ neighbor 2001:0DB8::A route-map RSCLIENT-A-IMPORT import
+ neighbor 2001:0DB8::A route-map RSCLIENT-A-EXPORT export
+ neighbor 2001:0DB8::A soft-reconfiguration inbound
+
+ neighbor 2001:0DB8::B activate
+ neighbor 2001:0DB8::B route-server-client
+ neighbor 2001:0DB8::B route-map RSCLIENT-B-IMPORT import
+ neighbor 2001:0DB8::B route-map RSCLIENT-B-EXPORT export
+ neighbor 2001:0DB8::B soft-reconfiguration inbound
+
+ neighbor 2001:0DB8::C activate
+ neighbor 2001:0DB8::C route-server-client
+ neighbor 2001:0DB8::C route-map RSCLIENT-C-IMPORT import
+ neighbor 2001:0DB8::C route-map RSCLIENT-C-EXPORT export
+ neighbor 2001:0DB8::C soft-reconfiguration inbound
+ exit-address-family
+ !
+ ipv6 prefix-list COMMON-PREFIXES seq 5 permit 2001:0DB8:0000::/48 ge 64 le 64
+ ipv6 prefix-list COMMON-PREFIXES seq 10 deny any
+ !
+ ipv6 prefix-list PEER-A-PREFIXES seq 5 permit 2001:0DB8:AAAA::/48 ge 64 le 64
+ ipv6 prefix-list PEER-A-PREFIXES seq 10 deny any
+ !
+ ipv6 prefix-list PEER-B-PREFIXES seq 5 permit 2001:0DB8:BBBB::/48 ge 64 le 64
+ ipv6 prefix-list PEER-B-PREFIXES seq 10 deny any
+ !
+ ipv6 prefix-list PEER-C-PREFIXES seq 5 permit 2001:0DB8:CCCC::/48 ge 64 le 64
+ ipv6 prefix-list PEER-C-PREFIXES seq 10 deny any
+ !
+ route-map RSCLIENT-A-IMPORT permit 10
+ match peer 2001:0DB8::B
+ call A-IMPORT-FROM-B
+ route-map RSCLIENT-A-IMPORT permit 20
+ match peer 2001:0DB8::C
+ call A-IMPORT-FROM-C
+ !
+ route-map A-IMPORT-FROM-B permit 10
+ match ipv6 address prefix-list COMMON-PREFIXES
+ set metric 100
+ route-map A-IMPORT-FROM-B permit 20
+ match ipv6 address prefix-list PEER-B-PREFIXES
+ set community 65001:11111
+ !
+ route-map A-IMPORT-FROM-C permit 10
+ match ipv6 address prefix-list COMMON-PREFIXES
+ set metric 200
+ route-map A-IMPORT-FROM-C permit 20
+ match ipv6 address prefix-list PEER-C-PREFIXES
+ set community 65001:22222
+ !
+ route-map RSCLIENT-A-EXPORT permit 10
+ match peer 2001:0DB8::B
+ match ipv6 address prefix-list PEER-A-PREFIXES
+ route-map RSCLIENT-A-EXPORT permit 20
+ match peer 2001:0DB8::C
+ match ipv6 address prefix-list PEER-A-PREFIXES
+ !
+ ...
+ ...
+ ...
+
+ If you compare the initial configuration of RA with the route server
+configuration above, you can see how easy it is to generate the Import
+and Export policies for RA from the In and Out route-maps of RA's
+original configuration.
+
+ When there was no route server, RA maintained two peerings, one with
+RB and another with RC. Each of this peerings had an In route-map
+configured. To build the Import route-map for client RA in the route
+server, simply add route-map entries following this scheme:
+
+ route-map <NAME> permit 10
+ match peer <Peer Address>
+ call <In Route-Map for this Peer>
+ route-map <NAME> permit 20
+ match peer <Another Peer Address>
+ call <In Route-Map for this Peer>
+
+ This is exactly the process that has been followed to generate the
+route-map RSCLIENT-A-IMPORT. The route-maps that are called inside it
+(A-IMPORT-FROM-B and A-IMPORT-FROM-C) are exactly the same than the In
+route-maps from the original configuration of RA (PEER-B-IN and
+PEER-C-IN), only the name is different.
+
+ The same could have been done to create the Export policy for RA
+(route-map RSCLIENT-A-EXPORT), but in this case the original Out
+route-maps where so simple that we decided not to use the CALL WORD
+commands, and we integrated all in a single route-map
+(RSCLIENT-A-EXPORT).
+
+ The Import and Export policies for RB and RC are not shown, but the
+process would be identical.
+
+\1f
+File: quagga.info, Node: Further considerations about Import and Export route-maps, Prev: Configuration of the Route Server itself, Up: Example of Route Server Configuration
+
+10.3.4 Further considerations about Import and Export route-maps
+----------------------------------------------------------------
+
+The current version of the route server patch only allows to specify a
+route-map for import and export policies, while in a standard BGP
+speaker apart from route-maps there are other tools for performing
+input and output filtering (access-lists, community-lists, ...). But
+this does not represent any limitation, as all kinds of filters can be
+included in import/export route-maps. For example suppose that in the
+non-route-server scenario peer RA had the following filters configured
+for input from peer B:
+
+ neighbor 2001:0DB8::B prefix-list LIST-1 in
+ neighbor 2001:0DB8::B filter-list LIST-2 in
+ neighbor 2001:0DB8::B route-map PEER-B-IN in
+ ...
+ ...
+ route-map PEER-B-IN permit 10
+ match ipv6 address prefix-list COMMON-PREFIXES
+ set local-preference 100
+ route-map PEER-B-IN permit 20
+ match ipv6 address prefix-list PEER-B-PREFIXES
+ set community 65001:11111
+
+ It is posible to write a single route-map which is equivalent to the
+three filters (the community-list, the prefix-list and the route-map).
+That route-map can then be used inside the Import policy in the route
+server. Lets see how to do it:
+
+ neighbor 2001:0DB8::A route-map RSCLIENT-A-IMPORT import
+ ...
+ !
+ ...
+ route-map RSCLIENT-A-IMPORT permit 10
+ match peer 2001:0DB8::B
+ call A-IMPORT-FROM-B
+ ...
+ ...
+ !
+ route-map A-IMPORT-FROM-B permit 1
+ match ipv6 address prefix-list LIST-1
+ match as-path LIST-2
+ on-match goto 10
+ route-map A-IMPORT-FROM-B deny 2
+ route-map A-IMPORT-FROM-B permit 10
+ match ipv6 address prefix-list COMMON-PREFIXES
+ set local-preference 100
+ route-map A-IMPORT-FROM-B permit 20
+ match ipv6 address prefix-list PEER-B-PREFIXES
+ set community 65001:11111
+ !
+ ...
+ ...
+
+ The route-map A-IMPORT-FROM-B is equivalent to the three filters
+(LIST-1, LIST-2 and PEER-B-IN). The first entry of route-map
+A-IMPORT-FROM-B (sequence number 1) matches if and only if both the
+prefix-list LIST-1 and the filter-list LIST-2 match. If that happens,
+due to the "on-match goto 10" statement the next route-map entry to be
+processed will be number 10, and as of that point route-map
+A-IMPORT-FROM-B is identical to PEER-B-IN. If the first entry does not
+match, `on-match goto 10" will be ignored and the next processed entry
+will be number 2, which will deny the route.
+
+ Thus, the result is the same that with the three original filters,
+i.e., if either LIST-1 or LIST-2 rejects the route, it does not reach
+the route-map PEER-B-IN. In case both LIST-1 and LIST-2 accept the
+route, it passes to PEER-B-IN, which can reject, accept or modify the
+route.
+
+\1f
+File: quagga.info, Node: VTY shell, Next: Filtering, Prev: Configuring Quagga as a Route Server, Up: Top
+
+11 VTY shell
+************
+
+`vtysh' is integrated shell of Quagga software.
+
+ To use vtysh please specify --enable-vtysh to configure script. To
+use PAM for authentication use --with-libpam option to configure script.
+
+ vtysh only searches /etc/quagga path for vtysh.conf which is the
+vtysh configuration file. Vtysh does not search current directory for
+configuration file because the file includes user authentication
+settings.
+
+ Currently, vtysh.conf has only two commands.
+
+* Menu:
+
+* VTY shell username::
+* VTY shell integrated configuration::
+
+\1f
+File: quagga.info, Node: VTY shell username, Next: VTY shell integrated configuration, Up: VTY shell
+
+11.1 VTY shell username
+=======================
+
+ -- Command: username USERNAME nopassword
+ With this set, user foo does not need password authentication for
+ user vtysh. With PAM vtysh uses PAM authentication mechanism.
+
+ If vtysh is compiled without PAM authentication, every user can
+ use vtysh without authentication. vtysh requires read/write
+ permission to the various daemons vty sockets, this can be
+ accomplished through use of unix groups and the -enable-vty-group
+ configure option.
+
+
+\1f
+File: quagga.info, Node: VTY shell integrated configuration, Prev: VTY shell username, Up: VTY shell
+
+11.2
+====
+
+ -- Command: service integrated-vtysh-config
+ Write out integrated Quagga.conf file when 'write file' is issued.
+
+ This command controls the behaviour of vtysh when it is told to
+ write out the configuration. Per default, vtysh will instruct
+ each daemon to write out their own config files when `write file'
+ is issued. However, if `service integrated-vtysh-config' is set,
+ when `write file' is issued, vtysh will instruct the daemons will
+ write out a Quagga.conf with all daemons' commands integrated into
+ it.
+
+ Vtysh per default behaves as if `write-conf daemon' is set. Note
+ that both may be set at same time if one wishes to have both
+ Quagga.conf and daemon specific files written out. Further, note
+ that the daemons are hard-coded to first look for the integrated
+ Quagga.conf file before looking for their own file.
+
+ We recommend you do not mix the use of the two types of files.
+ Further, it is better not to use the integrated Quagga.conf file,
+ as any syntax error in it can lead to /all/ of your daemons being
+ unable to start up. Per daemon files are more robust as impact of
+ errors in configuration are limited to the daemon in whose file
+ the error is made.
+
+
+\1f
+File: quagga.info, Node: Filtering, Next: Route Map, Prev: VTY shell, Up: Top
+
+12 Filtering
+************
+
+Quagga provides many very flexible filtering features. Filtering is
+used for both input and output of the routing information. Once
+filtering is defined, it can be applied in any direction.
+
+* Menu:
+
+* IP Access List::
+* IP Prefix List::
+
+\1f
+File: quagga.info, Node: IP Access List, Next: IP Prefix List, Up: Filtering
+
+12.1 IP Access List
+===================
+
+ -- Command: access-list NAME permit IPV4-NETWORK
+ -- Command: access-list NAME deny IPV4-NETWORK
+
+ Basic filtering is done by `access-list' as shown in the following
+example.
+
+ access-list filter deny 10.0.0.0/9
+ access-list filter permit 10.0.0.0/8
+
+\1f
+File: quagga.info, Node: IP Prefix List, Prev: IP Access List, Up: Filtering
+
+12.2 IP Prefix List
+===================
+
+`ip prefix-list' provides the most powerful prefix based filtering
+mechanism. In addition to `access-list' functionality, `ip
+prefix-list' has prefix length range specification and sequential
+number specification. You can add or delete prefix based filters to
+arbitrary points of prefix-list using sequential number specification.
+
+ If no ip prefix-list is specified, it acts as permit. If `ip
+prefix-list' is defined, and no match is found, default deny is applied.
+
+ -- Command: ip prefix-list NAME (permit|deny) PREFIX [le LEN] [ge LEN]
+ -- Command: ip prefix-list NAME seq NUMBER (permit|deny) PREFIX [le
+LEN] [ge LEN]
+ You can create `ip prefix-list' using above commands.
+
+ seq
+ seq NUMBER can be set either automatically or manually. In
+ the case that sequential numbers are set manually, the user
+ may pick any number less than 4294967295. In the case that
+ sequential number are set automatically, the sequential
+ number will increase by a unit of five (5) per list. If a
+ list with no specified sequential number is created after a
+ list with a specified sequential number, the list will
+ automatically pick the next multiple of five (5) as the list
+ number. For example, if a list with number 2 already exists
+ and a new list with no specified number is created, the next
+ list will be numbered 5. If lists 2 and 7 already exist and
+ a new list with no specified number is created, the new list
+ will be numbered 10.
+
+ le
+ `le' command specifies prefix length. The prefix list will be
+ applied if the prefix length is less than or equal to the le
+ prefix length.
+
+ ge
+ `ge' command specifies prefix length. The prefix list will be
+ applied if the prefix length is greater than or equal to the
+ ge prefix length.
+
+
+
+ Less than or equal to prefix numbers and greater than or equal to
+prefix numbers can be used together. The order of the le and ge
+commands does not matter.
+
+ If a prefix list with a different sequential number but with the
+exact same rules as a previous list is created, an error will result.
+However, in the case that the sequential number and the rules are
+exactly similar, no error will result.
+
+ If a list with the same sequential number as a previous list is
+created, the new list will overwrite the old list.
+
+ Matching of IP Prefix is performed from the smaller sequential
+number to the larger. The matching will stop once any rule has been
+applied.
+
+ In the case of no le or ge command, the prefix length must match
+exactly the length specified in the prefix list.
+
+ -- Command: no ip prefix-list NAME
+
+* Menu:
+
+* ip prefix-list description::
+* ip prefix-list sequential number control::
+* Showing ip prefix-list::
+* Clear counter of ip prefix-list::
+
+\1f
+File: quagga.info, Node: ip prefix-list description, Next: ip prefix-list sequential number control, Up: IP Prefix List
+
+12.2.1 ip prefix-list description
+---------------------------------
+
+ -- Command: ip prefix-list NAME description DESC
+ Descriptions may be added to prefix lists. This command adds a
+ description to the prefix list.
+
+ -- Command: no ip prefix-list NAME description [DESC]
+ Deletes the description from a prefix list. It is possible to use
+ the command without the full description.
+
+\1f
+File: quagga.info, Node: ip prefix-list sequential number control, Next: Showing ip prefix-list, Prev: ip prefix-list description, Up: IP Prefix List
+
+12.2.2 ip prefix-list sequential number control
+-----------------------------------------------
+
+ -- Command: ip prefix-list sequence-number
+ With this command, the IP prefix list sequential number is
+ displayed. This is the default behavior.
+
+ -- Command: no ip prefix-list sequence-number
+ With this command, the IP prefix list sequential number is not
+ displayed.
+
+\1f
+File: quagga.info, Node: Showing ip prefix-list, Next: Clear counter of ip prefix-list, Prev: ip prefix-list sequential number control, Up: IP Prefix List
+
+12.2.3 Showing ip prefix-list
+-----------------------------
+
+ -- Command: show ip prefix-list
+ Display all IP prefix lists.
+
+ -- Command: show ip prefix-list NAME
+ Show IP prefix list can be used with a prefix list name.
+
+ -- Command: show ip prefix-list NAME seq NUM
+ Show IP prefix list can be used with a prefix list name and
+ sequential number.
+
+ -- Command: show ip prefix-list NAME A.B.C.D/M
+ If the command longer is used, all prefix lists with prefix
+ lengths equal to or longer than the specified length will be
+ displayed. If the command first match is used, the first prefix
+ length match will be displayed.
+
+ -- Command: show ip prefix-list NAME A.B.C.D/M longer
+
+ -- Command: show ip prefix-list NAME A.B.C.D/M first-match
+
+ -- Command: show ip prefix-list summary
+
+ -- Command: show ip prefix-list summary NAME
+
+ -- Command: show ip prefix-list detail
+
+ -- Command: show ip prefix-list detail NAME
+
+\1f
+File: quagga.info, Node: Clear counter of ip prefix-list, Prev: Showing ip prefix-list, Up: IP Prefix List
+
+12.2.4 Clear counter of ip prefix-list
+--------------------------------------
+
+ -- Command: clear ip prefix-list
+ Clears the counters of all IP prefix lists. Clear IP Prefix List
+ can be used with a specified name and prefix.
+
+ -- Command: clear ip prefix-list NAME
+
+ -- Command: clear ip prefix-list NAME A.B.C.D/M
+
+\1f
+File: quagga.info, Node: Route Map, Next: IPv6 Support, Prev: Filtering, Up: Top
+
+13 Route Map
+************
+
+Route map is a very useful function in zebra. There is a match and set
+statement permitted in a route map.
+
+ route-map test permit 10
+ match ip address 10
+ set local-preference 200
+
+ This means that if a route matches ip access-list number 10 it's
+local-preference value is set to 200.
+
+* Menu:
+
+* Route Map Command::
+* Route Map Match Command::
+* Route Map Set Command::
+
+\1f
+File: quagga.info, Node: Route Map Command, Next: Route Map Match Command, Up: Route Map
+
+13.1 Route Map Command
+======================
+
+ -- Command: route-map ROUTE-MAP-NAME permit PRIORITY
+
+\1f
+File: quagga.info, Node: Route Map Match Command, Next: Route Map Set Command, Prev: Route Map Command, Up: Route Map
+
+13.2 Route Map Match Command
+============================
+
+ -- Route-map Command: match ip address ACCESS_LIST
+ Matches the specified ACCESS_LIST
+
+ -- Route-map Command: match ip next-hop IPV4_ADDR
+ Matches the specified IPV4_ADDR.
+
+ -- Route-map Command: match aspath AS_PATH
+ Matches the specified AS_PATH.
+
+ -- Route-map Command: match metric METRIC
+ Matches the specified METRIC.
+
+ -- Route-map Command: match community COMMUNITY_LIST
+ Matches the specified COMMUNITY_LIST
+
+\1f
+File: quagga.info, Node: Route Map Set Command, Prev: Route Map Match Command, Up: Route Map
+
+13.3 Route Map Set Command
+==========================
+
+ -- Route-map Command: set ip next-hop IPV4_ADDRESS
+ Set the BGP nexthop address.
+
+ -- Route-map Command: set local-preference LOCAL_PREF
+ Set the BGP local preference.
+
+ -- Route-map Command: set weight WEIGHT
+ Set the route's weight.
+
+ -- Route-map Command: set metric METRIC
+ Set the BGP attribute MED.
+
+ -- Route-map Command: set as-path prepend AS_PATH
+ Set the BGP AS path to prepend.
+
+ -- Route-map Command: set community COMMUNITY
+ Set the BGP community attribute.
+
+ -- Route-map Command: set ipv6 next-hop global IPV6_ADDRESS
+ Set the BGP-4+ global IPv6 nexthop address.
+
+ -- Route-map Command: set ipv6 next-hop local IPV6_ADDRESS
+ Set the BGP-4+ link local IPv6 nexthop address.
+
+\1f
+File: quagga.info, Node: IPv6 Support, Next: Kernel Interface, Prev: Route Map, Up: Top
+
+14 IPv6 Support
+***************
+
+Quagga fully supports IPv6 routing. As described so far, Quagga
+supports RIPng, OSPFv3 and BGP-4+. You can give IPv6 addresses to an
+interface and configure static IPv6 routing information. Quagga IPv6
+also provides automatic address configuration via a feature called
+`address auto configuration'. To do it, the router must send router
+advertisement messages to the all nodes that exist on the network.
+
+* Menu:
+
+* Router Advertisement::
+
+\1f
+File: quagga.info, Node: Router Advertisement, Up: IPv6 Support
+
+14.1 Router Advertisement
+=========================
+
+ -- Interface Command: no ipv6 nd suppress-ra
+ Send router advertisment messages.
+
+ -- Interface Command: ipv6 nd suppress-ra
+ Don't send router advertisment messages.
+
+ -- Interface Command: ipv6 nd prefix IPV6PREFIX [VALID-LIFETIME]
+[PREFERRED-LIFETIME] [off-link] [no-autconfig]
+ Configuring the IPv6 prefix to include in router advertisements.
+ Several prefix specific optional parameters and flags may follow:
+ * VALID-LIFETIME - the length of time in seconds during what
+ the prefix is valid for the purpose of on-link determination.
+ Value INFINITE represents infinity (i.e. a value of all one
+ bits (`0xffffffff')).
+
+ Range: `<0-4294967295>' Default: `2592000'
+
+ * PREFERRED-LIFETIME - the length of time in seconds during
+ what addresses generated from the prefix remain preferred.
+ Value INFINITE represents infinity.
+
+ Range: `<0-4294967295>' Default: `604800'
+
+ * OFF-LINK - indicates that advertisement makes no statement
+ about on-link or off-link properties of the prefix.
+
+ Default: not set, i.e. this prefix can be used for on-link
+ determination.
+
+ * NO-AUTOCONFIG - indicates to hosts on the local link that the
+ specified prefix cannot be used for IPv6 autoconfiguration.
+
+ Default: not set, i.e. prefix can be used for
+ autoconfiguration.
+
+ -- Interface Command: ipv6 nd ra-interval SECONDS
+ -- Interface Command: no ipv6 nd ra-interval
+ The maximum time allowed between sending unsolicited multicast
+ router advertisements from the interface, in seconds. Must be no
+ less than 3 seconds.
+
+ Default: `600'
+
+ -- Interface Command: ipv6 nd ra-lifetime SECONDS
+ -- Interface Command: no ipv6 nd ra-lifetime
+ The value to be placed in the Router Lifetime field of router
+ advertisements sent from the interface, in seconds. Indicates the
+ usefulness of the router as a default router on this interface.
+ Setting the value to zero indicates that the router should not be
+ considered a default router on this interface. Must be either
+ zero or between value specified with IPV6 ND RA-INTERVAL (or
+ default) and 9000 seconds.
+
+ Default: `1800'
+
+ -- Interface Command: ipv6 nd reachable-time MILLISECONDS
+ -- Interface Command: no ipv6 nd reachable-time
+ The value to be placed in the Reachable Time field in the Router
+ Advertisement messages sent by the router, in milliseconds. The
+ configured time enables the router to detect unavailable
+ neighbors. The value zero means unspecified (by this router). Must
+ be no greater than `3,600,000' milliseconds (1 hour).
+
+ Default: `0'
+
+ -- Interface Command: ipv6 nd managed-config-flag
+ -- Interface Command: no ipv6 nd managed-config-flag
+ Set/unset flag in IPv6 router advertisements which indicates to
+ hosts that they should use managed (stateful) protocol for
+ addresses autoconfiguration in addition to any addresses
+ autoconfigured using stateless address autoconfiguration.
+
+ Default: not set
+
+ -- Interface Command: ipv6 nd other-config-flag
+ -- Interface Command: no ipv6 nd other-config-flag
+ Set/unset flag in IPv6 router advertisements which indicates to
+ hosts that they should use administered (stateful) protocol to
+ obtain autoconfiguration information other than addresses.
+
+ Default: not set
+
+ interface eth0
+ no ipv6 nd suppress-ra
+ ipv6 nd prefix 2001:0DB8:5009::/64
+
+ For more information see `RFC2462 (IPv6 Stateless Address
+Autoconfiguration)' and `RFC2461 (Neighbor Discovery for IP Version 6
+(IPv6))'.
+
+\1f
+File: quagga.info, Node: Kernel Interface, Next: SNMP Support, Prev: IPv6 Support, Up: Top
+
+15 Kernel Interface
+*******************
+
+There are several different methods for reading kernel routing table
+information, updating kernel routing tables, and for looking up
+interfaces.
+
+`ioctl'
+ The `ioctl' method is a very traditional way for reading or writing
+ kernel information. `ioctl' can be used for looking up interfaces
+ and for modifying interface addresses, flags, mtu settings and
+ other types of information. Also, `ioctl' can insert and delete
+ kernel routing table entries. It will soon be available on almost
+ any platform which zebra supports, but it is a little bit ugly
+ thus far, so if a better method is supported by the kernel, zebra
+ will use that.
+
+`sysctl'
+ `sysctl' can lookup kernel information using MIB (Management
+ Information Base) syntax. Normally, it only provides a way of
+ getting information from the kernel. So one would usually want to
+ change kernel information using another method such as `ioctl'.
+
+`proc filesystem'
+ `proc filesystem' provides an easy way of getting kernel
+ information.
+
+`routing socket'
+
+`netlink'
+ On recent Linux kernels (2.0.x and 2.2.x), there is a kernel/user
+ communication support called `netlink'. It makes asynchronous
+ communication between kernel and Quagga possible, similar to a
+ routing socket on BSD systems.
+
+ Before you use this feature, be sure to select (in kernel
+ configuration) the kernel/netlink support option 'Kernel/User
+ network link driver' and 'Routing messages'.
+
+ Today, the /dev/route special device file is obsolete. Netlink
+ communication is done by reading/writing over netlink socket.
+
+ After the kernel configuration, please reconfigure and rebuild
+ Quagga. You can use netlink as a dynamic routing update channel
+ between Quagga and the kernel.
+
+\1f
+File: quagga.info, Node: SNMP Support, Next: Zebra Protocol, Prev: Kernel Interface, Up: Top
+
+16 SNMP Support
+***************
+
+SNMP (Simple Network Managing Protocol) is a widely implemented feature
+for collecting network information from router and/or host. Quagga
+itself does not support SNMP agent (server daemon) functionality but is
+able to connect to a SNMP agent using the SMUX protocol (RFC1227) and
+make the routing protocol MIBs available through it.
+
+* Menu:
+
+* Getting and installing an SNMP agent::
+* SMUX configuration::
+* MIB and command reference::
+
+\1f
+File: quagga.info, Node: Getting and installing an SNMP agent, Next: SMUX configuration, Up: SNMP Support
+
+16.1 Getting and installing an SNMP agent
+=========================================
+
+There are several SNMP agent which support SMUX. We recommend to use
+the latest version of `net-snmp' which was formerly known as `ucd-snmp'.
+It is free and open software and available at `http://www.net-snmp.org/'
+and as binary package for most Linux distributions. `net-snmp' has to
+be compiled with `--with-mib-modules=smux' to be able to accept
+connections from Quagga.
+
+\1f
+File: quagga.info, Node: SMUX configuration, Next: MIB and command reference, Prev: Getting and installing an SNMP agent, Up: SNMP Support
+
+16.2 SMUX configuration
+=======================
+
+To enable SMUX protocol support, Quagga must have been build with the
+`--enable-snmp' option.
+
+ A separate connection has then to be established between between the
+SNMP agent (snmpd) and each of the Quagga daemons. This connections
+each use different OID numbers and passwords. Be aware that this OID
+number is not the one that is used in queries by clients, it is solely
+used for the intercommunication of the daemons.
+
+ In the following example the ospfd daemon will be connected to the
+snmpd daemon using the password "quagga_ospfd". For testing it is
+recommending to take exactly the below snmpd.conf as wrong access
+restrictions can be hard to debug.
+
+ /etc/snmp/snmpd.conf:
+ #
+ # example access restrictions setup
+ #
+ com2sec readonly default public
+ group MyROGroup v1 readonly
+ view all included .1 80
+ access MyROGroup "" any noauth exact all none none
+ #
+ # the following line is relevant for Quagga
+ #
+ smuxpeer .1.3.6.1.4.1.3317.1.2.5 quagga_ospfd
+
+ /etc/quagga/ospf:
+ ! ... the rest of ospfd.conf has been omitted for clarity ...
+ !
+ smux peer .1.3.6.1.4.1.3317.1.2.5 quagga_ospfd
+ !
+
+ After restarting snmpd and quagga, a successful connection can be
+verified in the syslog and by querying the SNMP daemon:
+
+ snmpd[12300]: [smux_accept] accepted fd 12 from 127.0.0.1:36255
+ snmpd[12300]: accepted smux peer: \
+ oid GNOME-PRODUCT-ZEBRA-MIB::ospfd, quagga-0.96.5
+
+ # snmpwalk -c public -v1 localhost .1.3.6.1.2.1.14.1.1
+ OSPF-MIB::ospfRouterId.0 = IpAddress: 192.168.42.109
+
+ Be warned that the current version (5.1.1) of the Net-SNMP daemon
+writes a line for every SNMP connect to the syslog which can lead to
+enormous log file sizes. If that is a problem you should consider to
+patch snmpd and comment out the troublesome `snmp_log()' line in the
+function `netsnmp_agent_check_packet()' in `agent/snmp_agent.c'.
+
+\1f
+File: quagga.info, Node: MIB and command reference, Prev: SMUX configuration, Up: SNMP Support
+
+16.3 MIB and command reference
+==============================
+
+The following OID numbers are used for the interprocess communication
+of snmpd and the Quagga daemons. Sadly, SNMP has not been implemented
+in all daemons yet.
+ (OIDs below .iso.org.dod.internet.private.enterprises)
+ zebra .1.3.6.1.4.1.3317.1.2.1 .gnome.gnomeProducts.zebra.zserv
+ bgpd .1.3.6.1.4.1.3317.1.2.2 .gnome.gnomeProducts.zebra.bgpd
+ ripd .1.3.6.1.4.1.3317.1.2.3 .gnome.gnomeProducts.zebra.ripd
+ ospfd .1.3.6.1.4.1.3317.1.2.5 .gnome.gnomeProducts.zebra.ospfd
+ ospf6d .1.3.6.1.4.1.3317.1.2.6 .gnome.gnomeProducts.zebra.ospf6d
+
+ The following OID numbers are used for querying the SNMP daemon by a
+client:
+ zebra .1.3.6.1.2.1.4.24 .iso.org.dot.internet.mgmt.mib-2.ip.ipForward
+ ospfd .1.3.6.1.2.1.14 .iso.org.dot.internet.mgmt.mib-2.ospf
+ bgpd .1.3.6.1.2.1.15 .iso.org.dot.internet.mgmt.mib-2.bgp
+ ripd .1.3.6.1.2.1.23 .iso.org.dot.internet.mgmt.mib-2.rip2
+ ospf6d .1.3.6.1.3.102 .iso.org.dod.internet.experimental.ospfv3
+
+ The following syntax is understood by the Quagga daemons for
+configuring SNMP:
+
+ -- Command: smux peer OID
+ -- Command: no smux peer OID
+
+ -- Command: smux peer OID PASSWORD
+ -- Command: no smux peer OID PASSWORD
+
+\1f
+File: quagga.info, Node: Zebra Protocol, Next: Packet Binary Dump Format, Prev: SNMP Support, Up: Top
+
+Appendix A Zebra Protocol
+*************************
+
+Zebra Protocol is a protocol which is used between protocol daemon and
+zebra. Each protocol daemon sends selected routes to zebra daemon.
+Then zebra manages which route is installed into the forwarding table.
+
+ Zebra Protocol is a TCP-based protocol. Below is common header of
+Zebra Protocol.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Length (2) | Command (1) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Length is total packet length including this header length. So
+minimum length is three. Command is Zebra Protocol command.
+
+ ZEBRA_INTERFACE_ADD 1
+ ZEBRA_INTERFACE_DELETE 2
+ ZEBRA_INTERFACE_ADDRESS_ADD 3
+ ZEBRA_INTERFACE_ADDRESS_DELETE 4
+ ZEBRA_INTERFACE_UP 5
+ ZEBRA_INTERFACE_DOWN 6
+ ZEBRA_IPV4_ROUTE_ADD 7
+ ZEBRA_IPV4_ROUTE_DELETE 8
+ ZEBRA_IPV6_ROUTE_ADD 9
+ ZEBRA_IPV6_ROUTE_DELETE 10
+ ZEBRA_REDISTRIBUTE_ADD 11
+ ZEBRA_REDISTRIBUTE_DELETE 12
+ ZEBRA_REDISTRIBUTE_DEFAULT_ADD 13
+ ZEBRA_REDISTRIBUTE_DEFAULT_DELETE 14
+ ZEBRA_IPV4_NEXTHOP_LOOKUP 15
+ ZEBRA_IPV6_NEXTHOP_LOOKUP 16
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Flags |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+\1f
+File: quagga.info, Node: Packet Binary Dump Format, Next: Command Index, Prev: Zebra Protocol, Up: Top
+
+Appendix B Packet Binary Dump Format
+************************************
+
+Quagga can dump routing protocol packet into file with a binary format
+(*note Dump BGP packets and table::).
+
+ It seems to be better that we share the MRT's header format for
+backward compatibility with MRT's dump logs. We should also define the
+binary format excluding the header, because we must support both IP v4
+and v6 addresses as socket addresses and / or routing entries.
+
+ In the last meeting, we discussed to have a version field in the
+header. But Masaki told us that we can define new `type' value rather
+than having a `version' field, and it seems to be better because we
+don't need to change header format.
+
+ Here is the common header format. This is same as that of MRT.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Time |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Subtype |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ If `type' is PROTOCOL_BGP4MP, `subtype' is BGP4MP_STATE_CHANGE, and
+Address Family == IP (version 4)
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Source AS number | Destination AS number |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Interface Index | Address Family |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Source IP address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Destination IP address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Old State | New State |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Where State is the value defined in RFC1771.
+
+ If `type' is PROTOCOL_BGP4MP, `subtype' is BGP4MP_STATE_CHANGE, and
+Address Family == IP version 6
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Source AS number | Destination AS number |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Interface Index | Address Family |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Source IP address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Source IP address (Cont'd) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Source IP address (Cont'd) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Source IP address (Cont'd) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Destination IP address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Destination IP address (Cont'd) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Destination IP address (Cont'd) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Destination IP address (Cont'd) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Old State | New State |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ If `type' is PROTOCOL_BGP4MP, `subtype' is BGP4MP_MESSAGE, and
+Address Family == IP (version 4)
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Source AS number | Destination AS number |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Interface Index | Address Family |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Source IP address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Destination IP address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | BGP Message Packet |
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Where BGP Message Packet is the whole contents of the BGP4 message
+including header portion.
+
+ If `type' is PROTOCOL_BGP4MP, `subtype' is BGP4MP_MESSAGE, and
+Address Family == IP version 6
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Source AS number | Destination AS number |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Interface Index | Address Family |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Source IP address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Source IP address (Cont'd) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Source IP address (Cont'd) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Source IP address (Cont'd) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Destination IP address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Destination IP address (Cont'd) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Destination IP address (Cont'd) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Destination IP address (Cont'd) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | BGP Message Packet |
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ If `type' is PROTOCOL_BGP4MP, `subtype' is BGP4MP_ENTRY, and Address
+Family == IP (version 4)
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | View # | Status |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Time Last Change |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Address Family | SAFI | Next-Hop-Len |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Next Hop Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Prefix Length | Address Prefix [variable] |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Attribute Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | BGP Attribute [variable length] |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ If `type' is PROTOCOL_BGP4MP, `subtype' is BGP4MP_ENTRY, and Address
+Family == IP version 6
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | View # | Status |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Time Last Change |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Address Family | SAFI | Next-Hop-Len |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Next Hop Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Next Hop Address (Cont'd) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Next Hop Address (Cont'd) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Next Hop Address (Cont'd) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Prefix Length | Address Prefix [variable] |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Address Prefix (cont'd) [variable] |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Attribute Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | BGP Attribute [variable length] |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ BGP4 Attribute must not contain MP_UNREACH_NLRI. If BGP Attribute
+has MP_REACH_NLRI field, it must has zero length NLRI, e.g.,
+MP_REACH_NLRI has only Address Family, SAFI and next-hop values.
+
+ If `type' is PROTOCOL_BGP4MP and `subtype' is BGP4MP_SNAPSHOT,
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | View # | File Name [variable] |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ The file specified in "File Name" contains all routing entries,
+which are in the format of "subtype == BGP4MP_ENTRY".
+
+ Constants:
+ /* type value */
+ #define MSG_PROTOCOL_BGP4MP 16
+ /* subtype value */
+ #define BGP4MP_STATE_CHANGE 0
+ #define BGP4MP_MESSAGE 1
+ #define BGP4MP_ENTRY 2
+ #define BGP4MP_SNAPSHOT 3
+
+\1f
+File: quagga.info, Node: Command Index, Next: VTY Key Index, Prev: Packet Binary Dump Format, Up: Top
+
+Command Index
+*************
+
+\0\b[index\0\b]
+* Menu:
+
+* access-class ACCESS-LIST: Basic Config Commands.
+ (line 83)
+* access-list NAME deny IPV4-NETWORK: IP Access List. (line 8)
+* access-list NAME permit IPV4-NETWORK: IP Access List. (line 7)
+* aggregate-address A.B.C.D/M: Route Aggregation. (line 7)
+* aggregate-address A.B.C.D/M as-set: Route Aggregation. (line 10)
+* aggregate-address A.B.C.D/M summary-only: Route Aggregation.
+ (line 14)
+* area <0-4294967295> authentication: OSPF area. (line 107)
+* area <0-4294967295> authentication message-digest: OSPF area.
+ (line 112)
+* area <0-4294967295> export-list NAME: OSPF area. (line 70)
+* area <0-4294967295> filter-list prefix NAME in: OSPF area. (line 97)
+* area <0-4294967295> filter-list prefix NAME out: OSPF area. (line 98)
+* area <0-4294967295> import-list NAME: OSPF area. (line 89)
+* area <0-4294967295> range A.B.C.D/M: OSPF area. (line 8)
+* area <0-4294967295> shortcut: OSPF area. (line 52)
+* area <0-4294967295> stub: OSPF area. (line 57)
+* area <0-4294967295> stub no-summary: OSPF area. (line 62)
+* area <0-4294967295> virtual-link A.B.C.D: OSPF area. (line 47)
+* area A.B.C.D authentication: OSPF area. (line 106)
+* area A.B.C.D authentication message-digest: OSPF area. (line 111)
+* area A.B.C.D default-cost <0-16777215>: OSPF area. (line 66)
+* area A.B.C.D export-list NAME: OSPF area. (line 69)
+* area A.B.C.D filter-list prefix NAME in: OSPF area. (line 95)
+* area A.B.C.D filter-list prefix NAME out: OSPF area. (line 96)
+* area A.B.C.D import-list NAME: OSPF area. (line 88)
+* area A.B.C.D range A.B.C.D/M: OSPF area. (line 7)
+* area A.B.C.D range IPV4_PREFIX not-advertise: OSPF area. (line 26)
+* area A.B.C.D range IPV4_PREFIX substitute IPV4_PREFIX: OSPF area.
+ (line 32)
+* area A.B.C.D shortcut: OSPF area. (line 51)
+* area A.B.C.D stub: OSPF area. (line 56)
+* area A.B.C.D stub no-summary: OSPF area. (line 61)
+* area A.B.C.D virtual-link A.B.C.D: OSPF area. (line 46)
+* auto-cost refrence-bandwidth <1-4294967>: OSPF router. (line 53)
+* bandwidth <1-10000000>: Interface Commands. (line 31)
+* banner motd default: Basic Config Commands.
+ (line 65)
+* bgp cluster-id A.B.C.D: Route Reflector. (line 7)
+* bgp config-type cisco: Multiple instance. (line 20)
+* bgp config-type zebra: Multiple instance. (line 49)
+* bgp multiple-instance: Multiple instance. (line 10)
+* bgp router-id A.B.C.D: BGP router. (line 22)
+* call WORD: Commands for configuring a Route Server.
+ (line 52)
+* clear ip bgp PEER: More Show IP BGP. (line 25)
+* clear ip bgp PEER soft in: More Show IP BGP. (line 28)
+* clear ip prefix-list: Clear counter of ip prefix-list.
+ (line 7)
+* clear ip prefix-list NAME: Clear counter of ip prefix-list.
+ (line 11)
+* clear ip prefix-list NAME A.B.C.D/M: Clear counter of ip prefix-list.
+ (line 13)
+* configure terminal: Basic Config Commands.
+ (line 36)
+* debug event: More Show IP BGP. (line 33)
+* debug keepalive: More Show IP BGP. (line 37)
+* debug ospf ism: Debugging OSPF. (line 12)
+* debug ospf ism (status|events|timers): Debugging OSPF. (line 13)
+* debug ospf lsa: Debugging OSPF. (line 22)
+* debug ospf lsa (generate|flooding|refresh): Debugging OSPF. (line 23)
+* debug ospf nsm: Debugging OSPF. (line 17)
+* debug ospf nsm (status|events|timers): Debugging OSPF. (line 18)
+* debug ospf packet (hello|dd|ls-request|ls-update|ls-ack|all) (send|recv) [detail]: Debugging OSPF.
+ (line 8)
+* debug ospf zebra: Debugging OSPF. (line 27)
+* debug ospf zebra (interface|redistribute): Debugging OSPF. (line 28)
+* debug rip events: RIP Debug Commands. (line 9)
+* debug rip packet: RIP Debug Commands. (line 15)
+* debug rip zebra: RIP Debug Commands. (line 22)
+* debug ripng events: ripngd Terminal Mode Commands.
+ (line 11)
+* debug ripng packet: ripngd Terminal Mode Commands.
+ (line 13)
+* debug ripng zebra: ripngd Terminal Mode Commands.
+ (line 15)
+* debug update: More Show IP BGP. (line 35)
+* default-information originate <1>: Redistribute routes to OSPF.
+ (line 24)
+* default-information originate: How to Announce RIP route.
+ (line 51)
+* default-information originate always: Redistribute routes to OSPF.
+ (line 30)
+* default-information originate always metric <0-16777214>: Redistribute routes to OSPF.
+ (line 32)
+* default-information originate always metric <0-16777214> metric-type (1|2): Redistribute routes to OSPF.
+ (line 34)
+* default-information originate always metric <0-16777214> metric-type (1|2) route-map WORD: Redistribute routes to OSPF.
+ (line 36)
+* default-information originate metric <0-16777214>: Redistribute routes to OSPF.
+ (line 25)
+* default-information originate metric <0-16777214> metric-type (1|2): Redistribute routes to OSPF.
+ (line 27)
+* default-information originate metric <0-16777214> metric-type (1|2) route-map WORD: Redistribute routes to OSPF.
+ (line 29)
+* default-metric <0-16777214>: Redistribute routes to OSPF.
+ (line 44)
+* default-metric <1-16>: RIP Metric Manipulation.
+ (line 11)
+* description DESCRIPTION ...: Interface Commands. (line 24)
+* distance <1-255> <1>: Redistribute routes to OSPF.
+ (line 47)
+* distance <1-255>: RIP distance. (line 9)
+* distance <1-255> A.B.C.D/M <1>: BGP distance. (line 12)
+* distance <1-255> A.B.C.D/M: RIP distance. (line 13)
+* distance <1-255> A.B.C.D/M ACCESS-LIST: RIP distance. (line 18)
+* distance <1-255> A.B.C.D/M WORD: BGP distance. (line 13)
+* distance bgp <1-255> <1-255> <1-255>: BGP distance. (line 7)
+* distance ospf (intra-area|inter-area|external) <1-255>: Redistribute routes to OSPF.
+ (line 51)
+* distribute-list ACCESS_LIST (in|out) IFNAME: ripngd Filtering Commands.
+ (line 7)
+* distribute-list ACCESS_LIST DIRECT IFNAME: Filtering RIP Routes.
+ (line 9)
+* distribute-list NAME out (kernel|connected|static|rip|ospf: Redistribute routes to OSPF.
+ (line 40)
+* distribute-list prefix PREFIX_LIST (in|out) IFNAME: Filtering RIP Routes.
+ (line 32)
+* dump bgp all PATH: Dump BGP packets and table.
+ (line 7)
+* dump bgp all PATH INTERVAL: Dump BGP packets and table.
+ (line 8)
+* dump bgp routes PATH: Dump BGP packets and table.
+ (line 15)
+* dump bgp updates PATH: Dump BGP packets and table.
+ (line 11)
+* dump bgp updates PATH INTERVAL: Dump BGP packets and table.
+ (line 12)
+* enable password PASSWORD: Basic Config Commands.
+ (line 14)
+* exec-timeout MINUTE: Basic Config Commands.
+ (line 71)
+* exec-timeout MINUTE SECOND: Basic Config Commands.
+ (line 72)
+* flush_timer TIME: ripngd Configuration.
+ (line 12)
+* hostname HOSTNAME: Basic Config Commands.
+ (line 7)
+* interface IFNAME: Interface Commands. (line 7)
+* interface IFNAME area AREA: OSPF6 router. (line 12)
+* ip address ADDRESS/PREFIX: Interface Commands. (line 13)
+* ip address ADDRESS/PREFIX secondary: Interface Commands. (line 19)
+* ip as-path access-list WORD {permit|deny} LINE: AS Path Access List.
+ (line 9)
+* ip community-list <1-99> {permit|deny} COMMUNITY: Numbered BGP Community Lists.
+ (line 14)
+* ip community-list <100-199> {permit|deny} COMMUNITY: Numbered BGP Community Lists.
+ (line 20)
+* ip community-list expanded NAME {permit|deny} LINE: BGP Community Lists.
+ (line 30)
+* ip community-list NAME {permit|deny} COMMUNITY: Numbered BGP Community Lists.
+ (line 25)
+* ip community-list standard NAME {permit|deny} COMMUNITY: BGP Community Lists.
+ (line 20)
+* ip extcommunity-list expanded NAME {permit|deny} LINE: BGP Extended Community Lists.
+ (line 21)
+* ip extcommunity-list standard NAME {permit|deny} EXTCOMMUNITY: BGP Extended Community Lists.
+ (line 10)
+* ip ospf authentication-key AUTH_KEY: OSPF interface. (line 7)
+* ip ospf cost <1-65535>: OSPF interface. (line 30)
+* ip ospf dead-interval <1-65535>: OSPF interface. (line 35)
+* ip ospf hello-interval <1-65535>: OSPF interface. (line 42)
+* ip ospf message-digest-key KEYID md5 KEY: OSPF interface. (line 13)
+* ip ospf network (broadcast|non-broadcast|point-to-multipoint|point-to-point): OSPF interface.
+ (line 50)
+* ip ospf priority <0-255>: OSPF interface. (line 54)
+* ip ospf retransmit-interval <1-65535>: OSPF interface. (line 61)
+* ip ospf transmit-delay: OSPF interface. (line 67)
+* ip prefix-list NAME (permit|deny) PREFIX [le LEN] [ge LEN]: IP Prefix List.
+ (line 16)
+* ip prefix-list NAME description DESC: ip prefix-list description.
+ (line 7)
+* ip prefix-list NAME seq NUMBER (permit|deny) PREFIX [le LEN] [ge LEN]: IP Prefix List.
+ (line 18)
+* ip prefix-list sequence-number: ip prefix-list sequential number control.
+ (line 7)
+* ip rip authentication key-chain KEY-CHAIN: RIP Authentication.
+ (line 21)
+* ip rip authentication mode md5: RIP Authentication. (line 7)
+* ip rip authentication mode text: RIP Authentication. (line 11)
+* ip rip authentication string STRING: RIP Authentication. (line 15)
+* ip rip receive version VERSION: RIP Configuration. (line 90)
+* ip rip send version VERSION: RIP Configuration. (line 81)
+* ip route NETWORK GATEWAY: Static Route Commands.
+ (line 10)
+* ip route NETWORK GATEWAY DISTANCE: Static Route Commands.
+ (line 36)
+* ip route NETWORK NETMASK GATEWAY: Static Route Commands.
+ (line 25)
+* ip split-horizon: RIP Configuration. (line 99)
+* ip6 address ADDRESS/PREFIX: Interface Commands. (line 14)
+* ipv6 nd managed-config-flag: Router Advertisement.
+ (line 72)
+* ipv6 nd other-config-flag: Router Advertisement.
+ (line 81)
+* ipv6 nd prefix IPV6PREFIX [VALID-LIFETIME] [PREFERRED-LIFETIME] [off-link] [no-autconfig]: Router Advertisement.
+ (line 14)
+* ipv6 nd ra-interval SECONDS: Router Advertisement.
+ (line 42)
+* ipv6 nd ra-lifetime SECONDS: Router Advertisement.
+ (line 50)
+* ipv6 nd reachable-time MILLISECONDS: Router Advertisement.
+ (line 62)
+* ipv6 nd suppress-ra: Router Advertisement.
+ (line 10)
+* ipv6 ospf6 cost COST: OSPF6 interface. (line 7)
+* ipv6 ospf6 dead-interval DEADINTERVAL: OSPF6 interface. (line 13)
+* ipv6 ospf6 hello-interval HELLOINTERVAL: OSPF6 interface. (line 10)
+* ipv6 ospf6 priority PRIORITY: OSPF6 interface. (line 20)
+* ipv6 ospf6 retransmit-interval RETRANSMITINTERVAL: OSPF6 interface.
+ (line 17)
+* ipv6 ospf6 transmit-delay TRANSMITDELAY: OSPF6 interface. (line 23)
+* ipv6 route NETWORK GATEWAY: Static Route Commands.
+ (line 77)
+* ipv6 route NETWORK GATEWAY DISTANCE: Static Route Commands.
+ (line 78)
+* line vty: Basic Config Commands.
+ (line 62)
+* link-detect: Interface Commands. (line 37)
+* list: Basic Config Commands.
+ (line 46)
+* log file FILENAME: Basic Config Commands.
+ (line 21)
+* log stdout: Basic Config Commands.
+ (line 17)
+* log syslog: Basic Config Commands.
+ (line 26)
+* match as-path WORD: Using AS Path in Route Map.
+ (line 7)
+* match aspath AS_PATH: Route Map Match Command.
+ (line 13)
+* match community COMMUNITY_LIST: Route Map Match Command.
+ (line 19)
+* match community WORD: BGP Community in Route Map.
+ (line 13)
+* match community WORD exact-match: BGP Community in Route Map.
+ (line 14)
+* match extcommunity WORD: BGP Extended Communities in Route Map.
+ (line 7)
+* match interface WORD: RIP route-map. (line 26)
+* match ip address ACCESS_LIST: Route Map Match Command.
+ (line 7)
+* match ip address prefix-list WORD: RIP route-map. (line 39)
+* match ip address WORD: RIP route-map. (line 38)
+* match ip next-hop A.B.C.D: RIP route-map. (line 42)
+* match ip next-hop IPV4_ADDR: Route Map Match Command.
+ (line 10)
+* match metric <0-4294967295>: RIP route-map. (line 47)
+* match metric METRIC: Route Map Match Command.
+ (line 16)
+* match peer {A.B.C.D|X:X::X:X}: Commands for configuring a Route Server.
+ (line 34)
+* multicast: Interface Commands. (line 27)
+* neigbor {A.B.C.D|X.X::X.X|peer-group} route-map WORD {import|export}: Commands for configuring a Route Server.
+ (line 29)
+* neighbor A.B.C.D: RIP Configuration. (line 45)
+* neighbor A.B.C.D route-server-client: Commands for configuring a Route Server.
+ (line 11)
+* neighbor PEER default-originate: BGP Peer commands. (line 47)
+* neighbor PEER description ...: BGP Peer commands. (line 20)
+* neighbor PEER distribute-list NAME [in|out]: Peer filtering.
+ (line 7)
+* neighbor PEER dont-capability-negotiate: Capability Negotiation.
+ (line 49)
+* neighbor PEER ebgp-multihop: BGP Peer commands. (line 17)
+* neighbor PEER filter-list NAME [in|out]: Peer filtering. (line 13)
+* neighbor PEER interface IFNAME: BGP Peer commands. (line 33)
+* neighbor PEER maximum-prefix NUMBER: BGP Peer commands. (line 64)
+* neighbor PEER next-hop-self: BGP Peer commands. (line 39)
+* neighbor PEER override-capability: Capability Negotiation.
+ (line 65)
+* neighbor PEER peer-group WORD: BGP Peer Group. (line 10)
+* neighbor PEER port PORT: BGP Peer commands. (line 53)
+* neighbor PEER prefix-list NAME [in|out]: Peer filtering. (line 11)
+* neighbor PEER remote-as ASN: Defining Peer. (line 7)
+* neighbor PEER route-map NAME [in|out]: Peer filtering. (line 15)
+* neighbor PEER route-reflector-client: Route Reflector. (line 9)
+* neighbor PEER send-community: BGP Peer commands. (line 56)
+* neighbor PEER shutdown: BGP Peer commands. (line 10)
+* neighbor PEER strict-capability-match: Capability Negotiation.
+ (line 38)
+* neighbor PEER update-source: BGP Peer commands. (line 44)
+* neighbor PEER version VERSION: BGP Peer commands. (line 24)
+* neighbor PEER weight WEIGHT: BGP Peer commands. (line 59)
+* neighbor PEER-GROUP route-server-client: Commands for configuring a Route Server.
+ (line 10)
+* neighbor WORD peer-group: BGP Peer Group. (line 7)
+* neighbor X:X::X:X route-server-client: Commands for configuring a Route Server.
+ (line 12)
+* network A.B.C.D/M: BGP route. (line 7)
+* network A.B.C.D/M area <0-4294967295>: OSPF router. (line 57)
+* network A.B.C.D/M area A.B.C.D: OSPF router. (line 56)
+* network IFNAME <1>: ripngd Configuration.
+ (line 18)
+* network IFNAME: RIP Configuration. (line 38)
+* network NETWORK <1>: ripngd Configuration.
+ (line 15)
+* network NETWORK: RIP Configuration. (line 26)
+* no aggregate-address A.B.C.D/M: Route Aggregation. (line 18)
+* no area <0-4294967295> authentication: OSPF area. (line 109)
+* no area <0-4294967295> export-list NAME: OSPF area. (line 72)
+* no area <0-4294967295> filter-list prefix NAME in: OSPF area.
+ (line 101)
+* no area <0-4294967295> filter-list prefix NAME out: OSPF area.
+ (line 102)
+* no area <0-4294967295> import-list NAME: OSPF area. (line 91)
+* no area <0-4294967295> range A.B.C.D/M: OSPF area. (line 10)
+* no area <0-4294967295> shortcut: OSPF area. (line 54)
+* no area <0-4294967295> stub: OSPF area. (line 59)
+* no area <0-4294967295> stub no-summary: OSPF area. (line 64)
+* no area <0-4294967295> virtual-link A.B.C.D: OSPF area. (line 49)
+* no area A.B.C.D authentication: OSPF area. (line 108)
+* no area A.B.C.D default-cost <0-16777215>: OSPF area. (line 67)
+* no area A.B.C.D export-list NAME: OSPF area. (line 71)
+* no area A.B.C.D filter-list prefix NAME in: OSPF area. (line 99)
+* no area A.B.C.D filter-list prefix NAME out: OSPF area. (line 100)
+* no area A.B.C.D import-list NAME: OSPF area. (line 90)
+* no area A.B.C.D range A.B.C.D/M: OSPF area. (line 9)
+* no area A.B.C.D range IPV4_PREFIX not-advertise: OSPF area. (line 27)
+* no area A.B.C.D range IPV4_PREFIX substitute IPV4_PREFIX: OSPF area.
+ (line 34)
+* no area A.B.C.D shortcut: OSPF area. (line 53)
+* no area A.B.C.D stub: OSPF area. (line 58)
+* no area A.B.C.D stub no-summary: OSPF area. (line 63)
+* no area A.B.C.D virtual-link A.B.C.D: OSPF area. (line 48)
+* no auto-cost refrence-bandwidth: OSPF router. (line 54)
+* no bandwidth <1-10000000>: Interface Commands. (line 32)
+* no banner motd: Basic Config Commands.
+ (line 68)
+* no bgp multiple-instance: Multiple instance. (line 14)
+* no debug event: More Show IP BGP. (line 39)
+* no debug keepalive: More Show IP BGP. (line 43)
+* no debug ospf ism: Debugging OSPF. (line 14)
+* no debug ospf ism (status|events|timers): Debugging OSPF. (line 15)
+* no debug ospf lsa: Debugging OSPF. (line 24)
+* no debug ospf lsa (generate|flooding|refresh): Debugging OSPF.
+ (line 25)
+* no debug ospf nsm: Debugging OSPF. (line 19)
+* no debug ospf nsm (status|events|timers): Debugging OSPF. (line 20)
+* no debug ospf packet (hello|dd|ls-request|ls-update|ls-ack|all) (send|recv) [detail]: Debugging OSPF.
+ (line 10)
+* no debug ospf zebra: Debugging OSPF. (line 29)
+* no debug ospf zebra (interface|redistribute): Debugging OSPF.
+ (line 30)
+* no debug update: More Show IP BGP. (line 41)
+* no default-information originate: Redistribute routes to OSPF.
+ (line 37)
+* no default-metric: Redistribute routes to OSPF.
+ (line 45)
+* no default-metric <1-16>: RIP Metric Manipulation.
+ (line 12)
+* no distance <1-255> <1>: Redistribute routes to OSPF.
+ (line 48)
+* no distance <1-255>: RIP distance. (line 10)
+* no distance <1-255> A.B.C.D/M: RIP distance. (line 14)
+* no distance <1-255> A.B.C.D/M ACCESS-LIST: RIP distance. (line 19)
+* no distance ospf: Redistribute routes to OSPF.
+ (line 52)
+* no distribute-list NAME out (kernel|connected|static|rip|ospf: Redistribute routes to OSPF.
+ (line 42)
+* no exec-timeout: Basic Config Commands.
+ (line 79)
+* no ip address ADDRESS/PREFIX: Interface Commands. (line 15)
+* no ip address ADDRESS/PREFIX secondary: Interface Commands. (line 20)
+* no ip as-path access-list WORD: AS Path Access List. (line 12)
+* no ip as-path access-list WORD {permit|deny} LINE: AS Path Access List.
+ (line 13)
+* no ip community-list expanded NAME: BGP Community Lists. (line 37)
+* no ip community-list NAME: BGP Community Lists. (line 35)
+* no ip community-list standard NAME: BGP Community Lists. (line 36)
+* no ip extcommunity-list expanded NAME: BGP Extended Community Lists.
+ (line 29)
+* no ip extcommunity-list NAME: BGP Extended Community Lists.
+ (line 27)
+* no ip extcommunity-list standard NAME: BGP Extended Community Lists.
+ (line 28)
+* no ip ospf authentication-key: OSPF interface. (line 8)
+* no ip ospf cost: OSPF interface. (line 31)
+* no ip ospf dead-interval: OSPF interface. (line 36)
+* no ip ospf hello-interval: OSPF interface. (line 43)
+* no ip ospf message-digest-key: OSPF interface. (line 14)
+* no ip ospf network: OSPF interface. (line 51)
+* no ip ospf priority: OSPF interface. (line 55)
+* no ip ospf retransmit interval: OSPF interface. (line 62)
+* no ip ospf transmit-delay: OSPF interface. (line 68)
+* no ip prefix-list NAME: IP Prefix List. (line 67)
+* no ip prefix-list NAME description [DESC]: ip prefix-list description.
+ (line 11)
+* no ip prefix-list sequence-number: ip prefix-list sequential number control.
+ (line 11)
+* no ip rip authentication key-chain KEY-CHAIN: RIP Authentication.
+ (line 22)
+* no ip rip authentication mode md5: RIP Authentication. (line 8)
+* no ip rip authentication mode text: RIP Authentication. (line 12)
+* no ip rip authentication string STRING: RIP Authentication. (line 16)
+* no ip split-horizon: RIP Configuration. (line 100)
+* no ip6 address ADDRESS/PREFIX: Interface Commands. (line 16)
+* no ipv6 nd managed-config-flag: Router Advertisement.
+ (line 73)
+* no ipv6 nd other-config-flag: Router Advertisement.
+ (line 82)
+* no ipv6 nd ra-interval: Router Advertisement.
+ (line 43)
+* no ipv6 nd ra-lifetime: Router Advertisement.
+ (line 51)
+* no ipv6 nd reachable-time: Router Advertisement.
+ (line 63)
+* no ipv6 nd suppress-ra: Router Advertisement.
+ (line 7)
+* no link-detect: Interface Commands. (line 38)
+* no log stdout: Basic Config Commands.
+ (line 18)
+* no log syslog: Basic Config Commands.
+ (line 27)
+* no multicast: Interface Commands. (line 28)
+* no neighbor A.B.C.D: RIP Configuration. (line 46)
+* no neighbor PEER default-originate: BGP Peer commands. (line 48)
+* no neighbor PEER description ...: BGP Peer commands. (line 21)
+* no neighbor PEER dont-capability-negotiate: Capability Negotiation.
+ (line 50)
+* no neighbor PEER ebgp-multihop: BGP Peer commands. (line 18)
+* no neighbor PEER interface IFNAME: BGP Peer commands. (line 34)
+* no neighbor PEER maximum-prefix NUMBER: BGP Peer commands. (line 65)
+* no neighbor PEER next-hop-self: BGP Peer commands. (line 40)
+* no neighbor PEER override-capability: Capability Negotiation.
+ (line 66)
+* no neighbor PEER route-reflector-client: Route Reflector. (line 10)
+* no neighbor PEER shutdown: BGP Peer commands. (line 11)
+* no neighbor PEER strict-capability-match: Capability Negotiation.
+ (line 39)
+* no neighbor PEER update-source: BGP Peer commands. (line 45)
+* no neighbor PEER weight WEIGHT: BGP Peer commands. (line 60)
+* no network A.B.C.D/M: BGP route. (line 17)
+* no network A.B.C.D/M area <0-4294967295>: OSPF router. (line 59)
+* no network A.B.C.D/M area A.B.C.D: OSPF router. (line 58)
+* no network IFNAME: RIP Configuration. (line 39)
+* no network NETWORK: RIP Configuration. (line 27)
+* no ospf abr-type TYPE: OSPF router. (line 20)
+* no ospf rfc1583compatibility: OSPF router. (line 35)
+* no ospf router-id: OSPF router. (line 17)
+* no passive interface INTERFACE: OSPF router. (line 44)
+* no passive-interface IFNAME: RIP Configuration. (line 69)
+* no redistribute (kernel|connected|static|rip|bgp): Redistribute routes to OSPF.
+ (line 22)
+* no redistribute bgp: How to Announce RIP route.
+ (line 44)
+* no redistribute connected: How to Announce RIP route.
+ (line 26)
+* no redistribute kernel: How to Announce RIP route.
+ (line 10)
+* no redistribute ospf: How to Announce RIP route.
+ (line 36)
+* no redistribute static: How to Announce RIP route.
+ (line 18)
+* no route A.B.C.D/M: How to Announce RIP route.
+ (line 54)
+* no router bgp ASN: BGP router. (line 19)
+* no router ospf: OSPF router. (line 11)
+* no router rip: RIP Configuration. (line 12)
+* no router zebra: Redistribute routes to OSPF.
+ (line 55)
+* no shutdown: Interface Commands. (line 10)
+* no smux peer OID: MIB and command reference.
+ (line 29)
+* no smux peer OID PASSWORD: MIB and command reference.
+ (line 32)
+* no timers basic: RIP Timers. (line 31)
+* no timers spf: OSPF router. (line 47)
+* offset-list ACCESS-LIST (in|out): RIP Metric Manipulation.
+ (line 20)
+* offset-list ACCESS-LIST (in|out) IFNAME: RIP Metric Manipulation.
+ (line 21)
+* ospf abr-type TYPE: OSPF router. (line 19)
+* ospf rfc1583compatibility: OSPF router. (line 34)
+* ospf router-id A.B.C.D: OSPF router. (line 16)
+* passive interface INTERFACE: OSPF router. (line 43)
+* passive-interface (IFNAME|default): RIP Configuration. (line 68)
+* password PASSWORD: Basic Config Commands.
+ (line 10)
+* redistribute (kernel|connected|static|rip|bgp): Redistribute routes to OSPF.
+ (line 7)
+* redistribute (kernel|connected|static|rip|bgp) metric <0-16777214>: Redistribute routes to OSPF.
+ (line 15)
+* redistribute (kernel|connected|static|rip|bgp) metric <0-16777214> route-map WORD: Redistribute routes to OSPF.
+ (line 17)
+* redistribute (kernel|connected|static|rip|bgp) metric-type (1|2): Redistribute routes to OSPF.
+ (line 11)
+* redistribute (kernel|connected|static|rip|bgp) metric-type (1|2) metric <0-16777214>: Redistribute routes to OSPF.
+ (line 19)
+* redistribute (kernel|connected|static|rip|bgp) metric-type (1|2) metric <0-16777214> route-map WORD: Redistribute routes to OSPF.
+ (line 21)
+* redistribute (kernel|connected|static|rip|bgp) metric-type (1|2) route-map WORD: Redistribute routes to OSPF.
+ (line 13)
+* redistribute (kernel|connected|static|rip|bgp) ROUTE-MAP: Redistribute routes to OSPF.
+ (line 9)
+* redistribute bgp: How to Announce RIP route.
+ (line 41)
+* redistribute bgp metric <0-16>: How to Announce RIP route.
+ (line 42)
+* redistribute bgp route-map ROUTE-MAP: How to Announce RIP route.
+ (line 43)
+* redistribute connected <1>: Redistribute to BGP. (line 13)
+* redistribute connected <2>: Redistribute routes to OSPF6.
+ (line 8)
+* redistribute connected: How to Announce RIP route.
+ (line 23)
+* redistribute connected metric <0-16>: How to Announce RIP route.
+ (line 24)
+* redistribute connected route-map ROUTE-MAP: How to Announce RIP route.
+ (line 25)
+* redistribute kernel <1>: Redistribute to BGP. (line 7)
+* redistribute kernel: How to Announce RIP route.
+ (line 7)
+* redistribute kernel metric <0-16>: How to Announce RIP route.
+ (line 8)
+* redistribute kernel route-map ROUTE-MAP: How to Announce RIP route.
+ (line 9)
+* redistribute ospf <1>: Redistribute to BGP. (line 19)
+* redistribute ospf: How to Announce RIP route.
+ (line 33)
+* redistribute ospf metric <0-16>: How to Announce RIP route.
+ (line 34)
+* redistribute ospf route-map ROUTE-MAP: How to Announce RIP route.
+ (line 35)
+* redistribute rip: Redistribute to BGP. (line 16)
+* redistribute ripng: Redistribute routes to OSPF6.
+ (line 9)
+* redistribute static <1>: Redistribute to BGP. (line 10)
+* redistribute static <2>: Redistribute routes to OSPF6.
+ (line 7)
+* redistribute static: How to Announce RIP route.
+ (line 15)
+* redistribute static metric <0-16>: How to Announce RIP route.
+ (line 16)
+* redistribute static route-map ROUTE-MAP: How to Announce RIP route.
+ (line 17)
+* refresh age-diff <0-10000>: OSPF router. (line 51)
+* refresh group-limit <0-10000>: OSPF router. (line 49)
+* refresh per-slice <0-10000>: OSPF router. (line 50)
+* route A.B.C.D/M: How to Announce RIP route.
+ (line 53)
+* route NETWORK: ripngd Configuration.
+ (line 21)
+* route-map ROUTE-MAP-NAME permit PRIORITY: Route Map Command.
+ (line 7)
+* router bgp AS-NUMBER: BGP instance and view.
+ (line 11)
+* router bgp AS-NUMBER view NAME: BGP instance and view.
+ (line 28)
+* router bgp ASN: BGP router. (line 13)
+* router ospf: OSPF router. (line 10)
+* router ospf6: OSPF6 router. (line 7)
+* router rip: RIP Configuration. (line 7)
+* router ripng: ripngd Configuration.
+ (line 9)
+* router zebra <1>: Redistribute routes to OSPF.
+ (line 54)
+* router zebra: ripngd Configuration.
+ (line 24)
+* router-id A.B.C.D: OSPF6 router. (line 9)
+* service advanced-vty: Basic Config Commands.
+ (line 52)
+* service integrated-vtysh-config: VTY shell integrated configuration.
+ (line 7)
+* service password-encryption: Basic Config Commands.
+ (line 49)
+* service terminal-length <0-512>: Basic Config Commands.
+ (line 55)
+* set as-path prepend AS-PATH: Using AS Path in Route Map.
+ (line 9)
+* set as-path prepend AS_PATH: Route Map Set Command.
+ (line 19)
+* set comm-list WORD delete: BGP Community in Route Map.
+ (line 34)
+* set community COMMUNITY <1>: Route Map Set Command.
+ (line 22)
+* set community COMMUNITY: BGP Community in Route Map.
+ (line 23)
+* set community COMMUNITY additive: BGP Community in Route Map.
+ (line 24)
+* set community none: BGP Community in Route Map.
+ (line 22)
+* set extcommunity rt EXTCOMMUNITY: BGP Extended Communities in Route Map.
+ (line 9)
+* set extcommunity soo EXTCOMMUNITY: BGP Extended Communities in Route Map.
+ (line 12)
+* set ip next-hop A.B.C.D: RIP route-map. (line 52)
+* set ip next-hop IPV4_ADDRESS: Route Map Set Command.
+ (line 7)
+* set ipv6 next-hop global IPV6_ADDRESS: Route Map Set Command.
+ (line 25)
+* set ipv6 next-hop local IPV6_ADDRESS: Route Map Set Command.
+ (line 28)
+* set local-preference LOCAL_PREF: Route Map Set Command.
+ (line 10)
+* set metric <0-4294967295>: RIP route-map. (line 57)
+* set metric METRIC: Route Map Set Command.
+ (line 16)
+* set weight WEIGHT: Route Map Set Command.
+ (line 13)
+* show debug: More Show IP BGP. (line 31)
+* show debugging ospf: Debugging OSPF. (line 32)
+* show debugging rip: RIP Debug Commands. (line 29)
+* show debugging ripng: ripngd Terminal Mode Commands.
+ (line 9)
+* show interface: zebra Terminal Mode Commands.
+ (line 21)
+* show ip bgp: Show IP BGP. (line 7)
+* show ip bgp A.B.C.D: Show IP BGP. (line 8)
+* show ip bgp community: Display BGP Routes by Community.
+ (line 11)
+* show ip bgp community COMMUNITY <1>: More Show IP BGP. (line 11)
+* show ip bgp community COMMUNITY: Display BGP Routes by Community.
+ (line 12)
+* show ip bgp community COMMUNITY exact-match <1>: More Show IP BGP.
+ (line 12)
+* show ip bgp community COMMUNITY exact-match: Display BGP Routes by Community.
+ (line 13)
+* show ip bgp community-list WORD <1>: More Show IP BGP. (line 16)
+* show ip bgp community-list WORD: Display BGP Routes by Community.
+ (line 20)
+* show ip bgp community-list WORD exact-match <1>: More Show IP BGP.
+ (line 17)
+* show ip bgp community-list WORD exact-match: Display BGP Routes by Community.
+ (line 21)
+* show ip bgp neighbor [PEER]: More Show IP BGP. (line 23)
+* show ip bgp regexp LINE <1>: More Show IP BGP. (line 7)
+* show ip bgp regexp LINE: Display BGP Routes by AS Path.
+ (line 10)
+* show ip bgp summary: More Show IP BGP. (line 21)
+* show ip bgp view NAME: Viewing the view. (line 9)
+* show ip bgp X:X::X:X: Show IP BGP. (line 9)
+* show ip community-list: BGP Community Lists. (line 42)
+* show ip community-list NAME: BGP Community Lists. (line 43)
+* show ip extcommunity-list: BGP Extended Community Lists.
+ (line 35)
+* show ip extcommunity-list NAME: BGP Extended Community Lists.
+ (line 36)
+* show ip ospf: Showing OSPF information.
+ (line 7)
+* show ip ospf database: Showing OSPF information.
+ (line 16)
+* show ip ospf database (asbr-summary|external|network|router|summary): Showing OSPF information.
+ (line 19)
+* show ip ospf database (asbr-summary|external|network|router|summary) adv-router ADV-ROUTER: Showing OSPF information.
+ (line 26)
+* show ip ospf database (asbr-summary|external|network|router|summary) LINK-STATE-ID: Showing OSPF information.
+ (line 21)
+* show ip ospf database (asbr-summary|external|network|router|summary) LINK-STATE-ID adv-router ADV-ROUTER: Showing OSPF information.
+ (line 24)
+* show ip ospf database (asbr-summary|external|network|router|summary) LINK-STATE-ID self-originate: Showing OSPF information.
+ (line 29)
+* show ip ospf database (asbr-summary|external|network|router|summary) self-originate: Showing OSPF information.
+ (line 31)
+* show ip ospf database max-age: Showing OSPF information.
+ (line 33)
+* show ip ospf database self-originate: Showing OSPF information.
+ (line 35)
+* show ip ospf interface [INTERFACE]: Showing OSPF information.
+ (line 9)
+* show ip ospf neighbor: Showing OSPF information.
+ (line 11)
+* show ip ospf neighbor detail: Showing OSPF information.
+ (line 13)
+* show ip ospf neighbor INTERFACE: Showing OSPF information.
+ (line 12)
+* show ip ospf neighbor INTERFACE detail: Showing OSPF information.
+ (line 14)
+* show ip ospf refresher: Showing OSPF information.
+ (line 37)
+* show ip ospf route: Showing OSPF information.
+ (line 39)
+* show ip prefix-list: Showing ip prefix-list.
+ (line 7)
+* show ip prefix-list detail: Showing ip prefix-list.
+ (line 31)
+* show ip prefix-list detail NAME: Showing ip prefix-list.
+ (line 33)
+* show ip prefix-list NAME: Showing ip prefix-list.
+ (line 10)
+* show ip prefix-list NAME A.B.C.D/M: Showing ip prefix-list.
+ (line 17)
+* show ip prefix-list NAME A.B.C.D/M first-match: Showing ip prefix-list.
+ (line 25)
+* show ip prefix-list NAME A.B.C.D/M longer: Showing ip prefix-list.
+ (line 23)
+* show ip prefix-list NAME seq NUM: Showing ip prefix-list.
+ (line 13)
+* show ip prefix-list summary: Showing ip prefix-list.
+ (line 27)
+* show ip prefix-list summary NAME: Showing ip prefix-list.
+ (line 29)
+* show ip protocols: Show RIP Information.
+ (line 17)
+* show ip rip: Show RIP Information.
+ (line 9)
+* show ip ripng: ripngd Terminal Mode Commands.
+ (line 7)
+* show ip route: zebra Terminal Mode Commands.
+ (line 7)
+* show ipforward: zebra Terminal Mode Commands.
+ (line 23)
+* show ipv6 ospf6 [INSTANCE_ID]: Showing OSPF6 information.
+ (line 7)
+* show ipv6 ospf6 database: Showing OSPF6 information.
+ (line 11)
+* show ipv6 ospf6 interface: Showing OSPF6 information.
+ (line 15)
+* show ipv6 ospf6 neighbor: Showing OSPF6 information.
+ (line 18)
+* show ipv6 ospf6 request-list A.B.C.D: Showing OSPF6 information.
+ (line 21)
+* show ipv6 route: zebra Terminal Mode Commands.
+ (line 19)
+* show ipv6 route ospf6: Showing OSPF6 information.
+ (line 24)
+* show ipv6forward: zebra Terminal Mode Commands.
+ (line 28)
+* show version: Basic Config Commands.
+ (line 59)
+* shutdown: Interface Commands. (line 9)
+* smux peer OID: MIB and command reference.
+ (line 28)
+* smux peer OID PASSWORD: MIB and command reference.
+ (line 31)
+* table TABLENO: Static Route Commands.
+ (line 81)
+* terminal length <0-512>: Basic Config Commands.
+ (line 40)
+* timers basic UPDATE TIMEOUT GARBAGE: RIP Timers. (line 7)
+* timers spf <0-4294967295> <0-4294967295>: OSPF router. (line 46)
+* username USERNAME nopassword: VTY shell username. (line 7)
+* version VERSION: RIP Configuration. (line 23)
+* who: Basic Config Commands.
+ (line 44)
+* write file: Basic Config Commands.
+ (line 33)
+* write terminal: Basic Config Commands.
+ (line 30)
+
+\1f
+File: quagga.info, Node: VTY Key Index, Prev: Command Index, Up: Top
+
+VTY Key Index
+*************
+
+\0\b[index\0\b]
+* Menu:
+
+* <DEL>: CLI Editing Commands. (line 11)
+* <DOWN>: CLI Advanced Commands.
+ (line 17)
+* <LEFT>: CLI Movement Commands.
+ (line 15)
+* <RIGHT>: CLI Movement Commands.
+ (line 11)
+* <TAB>: CLI Advanced Commands.
+ (line 24)
+* <UP>: CLI Advanced Commands.
+ (line 21)
+* ?: CLI Advanced Commands.
+ (line 27)
+* C-a: CLI Movement Commands.
+ (line 24)
+* C-b: CLI Movement Commands.
+ (line 15)
+* C-c: CLI Advanced Commands.
+ (line 10)
+* C-d: CLI Editing Commands. (line 14)
+* C-e: CLI Movement Commands.
+ (line 27)
+* C-f: CLI Movement Commands.
+ (line 11)
+* C-h: CLI Editing Commands. (line 11)
+* C-k: CLI Editing Commands. (line 23)
+* C-n: CLI Advanced Commands.
+ (line 17)
+* C-p: CLI Advanced Commands.
+ (line 21)
+* C-t: CLI Editing Commands. (line 29)
+* C-u: CLI Editing Commands. (line 26)
+* C-w: CLI Editing Commands. (line 20)
+* C-z: CLI Advanced Commands.
+ (line 13)
+* M-b: CLI Movement Commands.
+ (line 21)
+* M-d: CLI Editing Commands. (line 17)
+* M-f: CLI Movement Commands.
+ (line 18)
+
+
+\1f
+Tag Table:
+Node: Top\7f1889
+Node: Overview\7f2484
+Node: About Quagga\7f3885
+Node: System Architecture\7f6138
+Node: Supported Platforms\7f8828
+Node: Supported RFC\7f9969
+Node: How to get Quagga\7f11933
+Node: Mailing List\7f12687
+Node: Bug Reports\7f13134
+Node: Installation\7f14012
+Node: Configure the Software\7f14446
+Node: The Configure script and its options\7f14694
+Node: Least-Privilege support\7f17882
+Node: Linux notes\7f19618
+Ref: Linux notes-Footnote-1\7f21476
+Node: Build the Software\7f21542
+Node: Install the Software\7f22090
+Node: Basic commands\7f23550
+Node: Config Commands\7f24264
+Node: Basic Config Commands\7f25126
+Node: Sample Config File\7f27530
+Node: Common Invocation Options\7f28300
+Node: Virtual Terminal Interfaces\7f29707
+Node: VTY Overview\7f30218
+Node: VTY Modes\7f31469
+Node: VTY View Mode\7f31919
+Node: VTY Enable Mode\7f32169
+Node: VTY Other Modes\7f32447
+Node: VTY CLI Commands\7f32623
+Node: CLI Movement Commands\7f33083
+Node: CLI Editing Commands\7f33606
+Node: CLI Advanced Commands\7f34194
+Node: Zebra\7f34960
+Node: Invoking zebra\7f35469
+Node: Interface Commands\7f36048
+Node: Static Route Commands\7f37580
+Node: zebra Terminal Mode Commands\7f40853
+Node: RIP\7f41818
+Node: Starting and Stopping ripd\7f42755
+Node: RIP netmask\7f44168
+Node: RIP Configuration\7f45267
+Node: How to Announce RIP route\7f49532
+Node: Filtering RIP Routes\7f52095
+Node: RIP Metric Manipulation\7f53562
+Node: RIP distance\7f54475
+Node: RIP route-map\7f55290
+Node: RIP Authentication\7f57806
+Node: RIP Timers\7f58913
+Node: Show RIP Information\7f60199
+Node: RIP Debug Commands\7f61572
+Node: RIPng\7f62568
+Node: Invoking ripngd\7f62888
+Node: ripngd Configuration\7f63137
+Node: ripngd Terminal Mode Commands\7f63888
+Node: ripngd Filtering Commands\7f64252
+Node: OSPFv2\7f64761
+Node: Configuring ospfd\7f65320
+Node: OSPF router\7f65788
+Node: OSPF area\7f68944
+Node: OSPF interface\7f74126
+Node: Redistribute routes to OSPF\7f77509
+Node: Showing OSPF information\7f79672
+Node: Debugging OSPF\7f80918
+Node: OSPFv3\7f81957
+Node: OSPF6 router\7f82277
+Node: OSPF6 area\7f82631
+Node: OSPF6 interface\7f82809
+Node: Redistribute routes to OSPF6\7f83686
+Node: Showing OSPF6 information\7f84002
+Node: BGP\7f84822
+Node: Starting BGP\7f85712
+Node: BGP router\7f86289
+Node: BGP distance\7f87533
+Node: BGP decision process\7f87971
+Node: BGP network\7f88241
+Node: BGP route\7f88431
+Node: Route Aggregation\7f88987
+Node: Redistribute to BGP\7f89556
+Node: BGP Peer\7f90083
+Node: Defining Peer\7f90270
+Node: BGP Peer commands\7f90883
+Node: Peer filtering\7f93287
+Node: BGP Peer Group\7f93795
+Node: BGP Address Family\7f94108
+Node: Autonomous System\7f94262
+Node: AS Path Regular Expression\7f95099
+Node: Display BGP Routes by AS Path\7f96346
+Node: AS Path Access List\7f96786
+Node: Using AS Path in Route Map\7f97253
+Node: Private AS Numbers\7f97534
+Node: BGP Communities Attribute\7f97692
+Node: BGP Community Lists\7f100159
+Node: Numbered BGP Community Lists\7f102813
+Node: BGP Community in Route Map\7f104400
+Node: Display BGP Routes by Community\7f106343
+Node: Using BGP Communities Attribute\7f107512
+Node: BGP Extended Communities Attribute\7f111080
+Node: BGP Extended Community Lists\7f112852
+Node: BGP Extended Communities in Route Map\7f114727
+Node: Displaying BGP routes\7f115186
+Node: Show IP BGP\7f115423
+Node: More Show IP BGP\7f116123
+Node: Capability Negotiation\7f117274
+Node: Route Reflector\7f120578
+Node: Route Server\7f120857
+Node: Multiple instance\7f121923
+Node: BGP instance and view\7f123734
+Node: Routing policy\7f125114
+Node: Viewing the view\7f125882
+Node: How to set up a 6-Bone connection\7f126167
+Node: Dump BGP packets and table\7f127539
+Node: Configuring Quagga as a Route Server\7f128086
+Node: Description of the Route Server model\7f129047
+Ref: fig:normal-processing\7f130624
+Ref: fig:full-mesh\7f130774
+Ref: fig:route-server\7f130870
+Ref: filter-delegation\7f131284
+Ref: Route Server tasks\7f132468
+Ref: Route-server path filter process\7f132839
+Ref: fig:rs-processing\7f135153
+Node: Commands for configuring a Route Server\7f135270
+Node: Example of Route Server Configuration\7f138297
+Node: Configuration of the BGP routers without Route Server\7f139218
+Node: Configuration of the BGP routers with Route Server\7f142101
+Node: Configuration of the Route Server itself\7f143402
+Node: Further considerations about Import and Export route-maps\7f148401
+Node: VTY shell\7f151445
+Node: VTY shell username\7f152114
+Node: VTY shell integrated configuration\7f152746
+Node: Filtering\7f154124
+Node: IP Access List\7f154477
+Node: IP Prefix List\7f154863
+Node: ip prefix-list description\7f157882
+Node: ip prefix-list sequential number control\7f158409
+Node: Showing ip prefix-list\7f158951
+Node: Clear counter of ip prefix-list\7f160059
+Node: Route Map\7f160498
+Node: Route Map Command\7f161003
+Node: Route Map Match Command\7f161200
+Node: Route Map Set Command\7f161824
+Node: IPv6 Support\7f162701
+Node: Router Advertisement\7f163273
+Node: Kernel Interface\7f167074
+Node: SNMP Support\7f169031
+Node: Getting and installing an SNMP agent\7f169603
+Node: SMUX configuration\7f170176
+Node: MIB and command reference\7f172312
+Node: Zebra Protocol\7f173699
+Node: Packet Binary Dump Format\7f175613
+Node: Command Index\7f187223
+Node: VTY Key Index\7f241352
+\1f
+End Tag Table
projects / mirror / frr.git / commitdiff