diff options
| author | paul <paul> | 2004-11-15 21:56:53 +0000 |
|---|---|---|
| committer | paul <paul> | 2004-11-15 21:56:53 +0000 |
| commit | 56d1d2027bc6746e1a051067b24a792595292909 (patch) | |
| tree | 17a3252c6afc5424fa755c5055d05edc41c93a17 /doc | |
| parent | cbf566e639a882e9075f61cbca8246e32a9a43fc (diff) | |
2004-11-15 Paul Jakma <paul@dishone.st>
* quagga.info: Add generated file to CVS, as it requires most recent
texinfo to build, until such time as texinfo 4.7 is more
prevalent.
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/.cvsignore | 1 | ||||
| -rw-r--r-- | doc/ChangeLog | 3 | ||||
| -rw-r--r-- | doc/quagga.info | 6049 |
3 files changed, 6052 insertions, 1 deletions
diff --git a/doc/.cvsignore b/doc/.cvsignore index 449c7ae9..faaf184a 100644 --- a/doc/.cvsignore +++ b/doc/.cvsignore @@ -6,7 +6,6 @@ zebra.info-* zebra.html defines.texi version.texi -quagga.info* quagga.html *.pdf quagga.ps diff --git a/doc/ChangeLog b/doc/ChangeLog index 6e5bbc88..9aa487f7 100644 --- a/doc/ChangeLog +++ b/doc/ChangeLog @@ -2,6 +2,9 @@ * routeserver.texi: Strip ctrl-M from line endings, note by sigma@smx.pair.com + * quagga.info: Add generated file to CVS, as it requires most recent + texinfo to build, until such time as texinfo 4.7 is more + prevalent. 2004-11-08 Paul Jakma <paul@dishone.st> diff --git a/doc/quagga.info b/doc/quagga.info new file mode 100644 index 00000000..b2db6d9a --- /dev/null +++ b/doc/quagga.info @@ -0,0 +1,6049 @@ +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. + + +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:: + + +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 + + +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. + + +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. + + +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. + + +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.' + + + +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. + + +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' + + +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'. + + +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 + + +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:: + + +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. + + +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. + + +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 + + +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 + + +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::. + + +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 + + +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. + + +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. + + +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'. + + +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. + + + +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 + + +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. + + +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. + + +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. + + +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. + + +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. + + +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 + + +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. + + + +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. + + + +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. + + + +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 + + +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. + + + +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. + + +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. + + +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. + + +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:: + + +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:: + + +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. + + +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'. + + +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'. + + +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. + + +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 + + +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. + + +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. + + +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 + ! + + +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. + + +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 + + +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. + + +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:: + + +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::). + + +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. + + +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 + + +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 + + +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:: + + +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'. + + +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. + + +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 + + +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. + + +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 + + +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 + + +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 + + +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:: + + +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. + + +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. + + +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. + + +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 + + +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. + + +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:: + + +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. + + +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:: + + +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 + + +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. + + +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:: + + +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 + + +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 + + +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. + + +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:: + + +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 + + +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 + + +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'. + + +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. + + +File: quagga.info, Node: BGP Address Family, Next: Autonomous System, Prev: BGP Peer Group, Up: BGP + +9.6 BGP Address Family +====================== + + +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:: + + +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. + + +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. + + +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 + + +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 + + +File: quagga.info, Node: Private AS Numbers, Prev: Using AS Path in Route Map, Up: Autonomous System + +9.7.5 Private AS Numbers +------------------------ + + +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:: + + +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 + + +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. + + +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. + + +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. + + +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 + + +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:: + + +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 + + +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. + + +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:: + + +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 + + +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 + + +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. + + +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 + + +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:: + + +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. + + +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 + + +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. + + +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. + + +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 + ! + + +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. + + +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:: + + +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. + + + +Figure 10.1: Announcement processing inside a "normal" BGP speaker + + + +Figure 10.2: Full Mesh + + + +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). + + + +Figure 10.4: Announcement processing model implemented by the Route Server + + +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. + + +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:: + + +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 + ! + + +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. + + +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. + + +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. + + +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:: + + +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. + + + +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. + + + +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:: + + +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 + + +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:: + + +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. + + +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. + + +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 + + +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 + + +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:: + + +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 + + +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 + + +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. + + +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:: + + +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))'. + + +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. + + +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:: + + +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. + + +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'. + + +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 + + +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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + +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 + + +File: quagga.info, Node: Command Index, Next: VTY Key Index, Prev: Packet Binary Dump Format, Up: Top + +Command Index +************* + + +* 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) + + +File: quagga.info, Node: VTY Key Index, Prev: Command Index, Up: Top + +VTY Key Index +************* + + +* 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) + + + +Tag Table: +Node: Top1889 +Node: Overview2484 +Node: About Quagga3885 +Node: System Architecture6138 +Node: Supported Platforms8828 +Node: Supported RFC9969 +Node: How to get Quagga11933 +Node: Mailing List12687 +Node: Bug Reports13134 +Node: Installation14012 +Node: Configure the Software14446 +Node: The Configure script and its options14694 +Node: Least-Privilege support17882 +Node: Linux notes19618 +Ref: Linux notes-Footnote-121476 +Node: Build the Software21542 +Node: Install the Software22090 +Node: Basic commands23550 +Node: Config Commands24264 +Node: Basic Config Commands25126 +Node: Sample Config File27530 +Node: Common Invocation Options28300 +Node: Virtual Terminal Interfaces29707 +Node: VTY Overview30218 +Node: VTY Modes31469 +Node: VTY View Mode31919 +Node: VTY Enable Mode32169 +Node: VTY Other Modes32447 +Node: VTY CLI Commands32623 +Node: CLI Movement Commands33083 +Node: CLI Editing Commands33606 +Node: CLI Advanced Commands34194 +Node: Zebra34960 +Node: Invoking zebra35469 +Node: Interface Commands36048 +Node: Static Route Commands37580 +Node: zebra Terminal Mode Commands40853 +Node: RIP41818 +Node: Starting and Stopping ripd42755 +Node: RIP netmask44168 +Node: RIP Configuration45267 +Node: How to Announce RIP route49532 +Node: Filtering RIP Routes52095 +Node: RIP Metric Manipulation53562 +Node: RIP distance54475 +Node: RIP route-map55290 +Node: RIP Authentication57806 +Node: RIP Timers58913 +Node: Show RIP Information60199 +Node: RIP Debug Commands61572 +Node: RIPng62568 +Node: Invoking ripngd62888 +Node: ripngd Configuration63137 +Node: ripngd Terminal Mode Commands63888 +Node: ripngd Filtering Commands64252 +Node: OSPFv264761 +Node: Configuring ospfd65320 +Node: OSPF router65788 +Node: OSPF area68944 +Node: OSPF interface74126 +Node: Redistribute routes to OSPF77509 +Node: Showing OSPF information79672 +Node: Debugging OSPF80918 +Node: OSPFv381957 +Node: OSPF6 router82277 +Node: OSPF6 area82631 +Node: OSPF6 interface82809 +Node: Redistribute routes to OSPF683686 +Node: Showing OSPF6 information84002 +Node: BGP84822 +Node: Starting BGP85712 +Node: BGP router86289 +Node: BGP distance87533 +Node: BGP decision process87971 +Node: BGP network88241 +Node: BGP route88431 +Node: Route Aggregation88987 +Node: Redistribute to BGP89556 +Node: BGP Peer90083 +Node: Defining Peer90270 +Node: BGP Peer commands90883 +Node: Peer filtering93287 +Node: BGP Peer Group93795 +Node: BGP Address Family94108 +Node: Autonomous System94262 +Node: AS Path Regular Expression95099 +Node: Display BGP Routes by AS Path96346 +Node: AS Path Access List96786 +Node: Using AS Path in Route Map97253 +Node: Private AS Numbers97534 +Node: BGP Communities Attribute97692 +Node: BGP Community Lists100159 +Node: Numbered BGP Community Lists102813 +Node: BGP Community in Route Map104400 +Node: Display BGP Routes by Community106343 +Node: Using BGP Communities Attribute107512 +Node: BGP Extended Communities Attribute111080 +Node: BGP Extended Community Lists112852 +Node: BGP Extended Communities in Route Map114727 +Node: Displaying BGP routes115186 +Node: Show IP BGP115423 +Node: More Show IP BGP116123 +Node: Capability Negotiation117274 +Node: Route Reflector120578 +Node: Route Server120857 +Node: Multiple instance121923 +Node: BGP instance and view123734 +Node: Routing policy125114 +Node: Viewing the view125882 +Node: How to set up a 6-Bone connection126167 +Node: Dump BGP packets and table127539 +Node: Configuring Quagga as a Route Server128086 +Node: Description of the Route Server model129047 +Ref: fig:normal-processing130624 +Ref: fig:full-mesh130774 +Ref: fig:route-server130870 +Ref: filter-delegation131284 +Ref: Route Server tasks132468 +Ref: Route-server path filter process132839 +Ref: fig:rs-processing135153 +Node: Commands for configuring a Route Server135270 +Node: Example of Route Server Configuration138297 +Node: Configuration of the BGP routers without Route Server139218 +Node: Configuration of the BGP routers with Route Server142101 +Node: Configuration of the Route Server itself143402 +Node: Further considerations about Import and Export route-maps148401 +Node: VTY shell151445 +Node: VTY shell username152114 +Node: VTY shell integrated configuration152746 +Node: Filtering154124 +Node: IP Access List154477 +Node: IP Prefix List154863 +Node: ip prefix-list description157882 +Node: ip prefix-list sequential number control158409 +Node: Showing ip prefix-list158951 +Node: Clear counter of ip prefix-list160059 +Node: Route Map160498 +Node: Route Map Command161003 +Node: Route Map Match Command161200 +Node: Route Map Set Command161824 +Node: IPv6 Support162701 +Node: Router Advertisement163273 +Node: Kernel Interface167074 +Node: SNMP Support169031 +Node: Getting and installing an SNMP agent169603 +Node: SMUX configuration170176 +Node: MIB and command reference172312 +Node: Zebra Protocol173699 +Node: Packet Binary Dump Format175613 +Node: Command Index187223 +Node: VTY Key Index241352 + +End Tag Table |