--- /dev/null
+This is quagga.info, produced by makeinfo version 6.3 from quagga.texi.
+
+Copyright (C) 1999-2005 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.
+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 1.2.3, last updated 4 February 2018 of 'The Quagga
+Manual', for Quagga Version 1.2.3.
+
+ Copyright (C) 1999-2005 Kunihiro Ishiguro, et al.
+
+ Permission is granted to make and distribute verbatim copies of
+ this manual provided the copyright notice and this permission
+ notice are preserved on all copies.
+
+ Permission is granted to copy and distribute modified versions of
+ this manual under the conditions for verbatim copying, provided
+ that the entire resulting derived work is distributed under the
+ terms of a permission notice identical to this one.
+
+ Permission is granted to copy and distribute translations of this
+ manual into another language, under the above conditions for
+ modified versions, except that this permission notice may be stated
+ in a translation approved by Kunihiro Ishiguro.
+
+\1f
+File: quagga.info, Node: Top, Next: Overview, Up: (dir)
+
+Quagga
+******
+
+Quagga is an advanced routing software package that provides a suite of
+TCP/IP based routing protocols. This is the Manual for Quagga 1.2.3.
+Quagga is a fork of GNU Zebra.
+
+ Copyright (C) 1999-2005 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.
+
+* Menu:
+
+* Overview::
+* Installation::
+* Basic commands::
+* Zebra::
+* RIP::
+* RIPng::
+* OSPFv2::
+* OSPFv3::
+* ISIS::
+* NHRP::
+* 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::
+* Index::
+
+\1f
+File: quagga.info, Node: Overview, Next: Installation, Prev: Top, Up: Top
+
+1 Overview
+**********
+
+Quagga is a routing software package that provides TCP/IP based routing
+services with routing protocols support such as RIPv1, RIPv2, RIPng,
+OSPFv2, OSPFv3, IS-IS, BGP-4, and BGP-4+ (*note Supported RFCs::).
+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 and AgentX 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 RFCs:: Supported RFCs
+* How to get Quagga::
+* Mailing List:: Mailing list information
+* Bug Reports:: Mail address for bug data
+
+\1f
+File: quagga.info, Node: About Quagga, Next: System Architecture, Up: Overview
+
+1.1 About Quagga
+================
+
+Today, TCP/IP networks are covering all of the world. The Internet has
+been deployed in many countries, companies, and to the home. When you
+connect to the Internet your packet will pass many routers which have
+TCP/IP routing functionality.
+
+ A system with Quagga installed acts as a dedicated router. With
+Quagga, your machine exchanges routing information with other routers
+using routing protocols. Quagga uses this information to update the
+kernel routing table so that the right data goes to the right place.
+You can dynamically change the configuration and you may view routing
+table information from the Quagga terminal interface.
+
+ Adding to routing protocol support, Quagga can setup interface's
+flags, interface's address, static routes and so on. If you have a
+small network, or a stub network, or xDSL connection, configuring the
+Quagga routing software is very easy. The only thing you have to do is
+to set up the interfaces and put a few commands about static routes
+and/or default routes. If the network is rather large, or if the
+network structure changes frequently, you will want to take advantage of
+Quagga's dynamic routing protocol support for protocols such as RIP,
+OSPF, IS-IS 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, that is
+BGP, OSPF, RIP and IS-IS. Upcoming for MPLS support, an implementation
+of LDP is currently being prepared for merging. Implementations of BFD
+and PIM-SSM (IPv4) also exist, but are not actively being worked on.
+
+ The ultimate goal of the Quagga project is making a productive,
+quality, free TCP/IP routing software package.
+
+\1f
+File: quagga.info, Node: System Architecture, Next: Supported Platforms, Prev: About Quagga, Up: Overview
+
+1.2 System Architecture
+=======================
+
+Traditional routing software is made as a one process program which
+provides all of the routing protocol functionalities. Quagga takes a
+different approach. It is made from a collection of several daemons
+that work together to build the routing table. There may be several
+protocol-specific routing daemons and zebra the kernel routing manager.
+
+ The 'ripd' daemon handles the RIP protocol, while 'ospfd' is a daemon
+which supports OSPF version 2. 'bgpd' supports the BGP-4 protocol. For
+changing the kernel routing table and for redistribution of routes
+between different routing protocols, there is a kernel routing table
+manager 'zebra' daemon. It is easy to add a new routing protocol
+daemons to the entire routing system without affecting any other
+software. You need to run only the protocol daemon associated with
+routing protocols in use. Thus, user may run a specific daemon and send
+routing reports to a central routing console.
+
+ There is no need for these daemons to be running on the same machine.
+You can even run several same protocol daemons on the same machine.
+This architecture creates new possibilities for the routing system.
+
+ +----+ +----+ +-----+ +-----+
+ |bgpd| |ripd| |ospfd| |zebra|
+ +----+ +----+ +-----+ +-----+
+ |
+ +---------------------------|--+
+ | v |
+ | UNIX Kernel routing table |
+ | |
+ +------------------------------+
+
+ Quagga System Architecture
+
+ Multi-process architecture brings extensibility, modularity and
+maintainability. At the same time it also brings many configuration
+files and terminal interfaces. Each daemon has it's own configuration
+file and terminal interface. When you configure a static route, it must
+be done in 'zebra' configuration file. When you configure BGP network
+it must be done in 'bgpd' configuration file. This can be a very
+annoying thing. To resolve the problem, Quagga provides integrated user
+interface shell called 'vtysh'. 'vtysh' connects to each daemon with
+UNIX domain socket and then works as a proxy for user input.
+
+ Quagga was planned to use multi-threaded mechanism when it runs with
+a kernel that supports multi-threads. But at the moment, the thread
+library which comes with GNU/Linux or FreeBSD has some problems with
+running reliable services such as routing software, so we don't use
+threads at all. Instead we use the 'select(2)' system call for
+multiplexing the events.
+
+\1f
+File: quagga.info, Node: Supported Platforms, Next: Supported RFCs, Prev: System Architecture, Up: Overview
+
+1.3 Supported Platforms
+=======================
+
+Currently Quagga supports GNU/Linux and BSD. 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
+ * FreeBSD
+ * NetBSD
+ * OpenBSD
+
+ Versions of these platforms that are older than around 2 years from
+the point of their original release (in case of GNU/Linux, this is since
+the kernel's release on kernel.org) may need some work. Similarly, the
+following platforms may work with some effort:
+
+
+ * Solaris
+ * Mac OSX
+
+ Also note that, in particular regarding proprietary platforms,
+compiler and C library choice will affect Quagga. Only recent versions
+of the following C compilers are well-tested:
+
+
+ * GNU's GCC
+ * LLVM's clang
+ * Intel's ICC
+
+\1f
+File: quagga.info, Node: Supported RFCs, Next: How to get Quagga, Prev: Supported Platforms, Up: Overview
+
+1.4 Supported RFCs
+==================
+
+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.'
+
+RFC3137
+ 'OSPF Stub Router Advertisement, A. Retana, L. Nguyen, R. White, A.
+ Zinin, D. McPherson. June 2001'
+
+ 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.'
+
+RFC2741
+ 'Agent Extensibility (AgentX) Protocol. M. Daniele, B. Wijnen.
+ January 2000.'
+
+\1f
+File: quagga.info, Node: How to get Quagga, Next: Mailing List, Prev: Supported RFCs, Up: Overview
+
+1.5 How to get Quagga
+=====================
+
+The official Quagga web-site is located at:
+
+ <http://www.quagga.net/>
+
+ and contains further information, as well as links to additional
+resources.
+
+ Quagga (http://www.quagga.net/) is a fork of GNU Zebra, whose
+web-site is located at:
+
+ <http://www.zebra.org/>.
+
+\1f
+File: quagga.info, Node: Mailing List, Next: Bug Reports, Prev: How to get Quagga, Up: Overview
+
+1.6 Mailing List
+================
+
+There is a mailing list for discussions about Quagga. If you have any
+comments or suggestions to Quagga, please subscribe to:
+
+ <http://lists.quagga.net/mailman/listinfo/quagga-users>.
+
+ The Quagga site has further information on the available mailing
+lists, see:
+
+ <http://www.quagga.net/lists.php>
+
+\1f
+File: quagga.info, Node: Bug Reports, Prev: Mailing List, Up: Overview
+
+1.7 Bug Reports
+===============
+
+If you think you have found a bug, please send a bug report to:
+
+ <http://bugzilla.quagga.net>
+
+ When you send a bug report, please be careful about the points below.
+
+ * Please note what kind of OS you are using. If you use the IPv6
+ stack please note that as well.
+ * Please show us the results of 'netstat -rn' and 'ifconfig -a'.
+ Information from zebra's VTY command 'show ip route' will also be
+ helpful.
+ * Please send your configuration file with the report. If you
+ specify arguments to the configure script please note that too.
+
+ Bug reports are very important for us to improve the quality of
+Quagga. Quagga is still in the development stage, but please don't
+hesitate to send a bug report to <http://bugzilla.quagga.net>.
+
+\1f
+File: quagga.info, Node: Installation, Next: Basic commands, Prev: Overview, Up: Top
+
+2 Installation
+**************
+
+There are three steps for installing the software: configuration,
+compilation, and installation.
+
+* Menu:
+
+* Configure the Software::
+* Build the Software::
+* Install the Software::
+
+ The easiest way to get Quagga running is to issue the following
+commands:
+
+ % configure
+ % make
+ % make install
+
+\1f
+File: quagga.info, Node: Configure the Software, Next: Build the Software, Up: Installation
+
+2.1 Configure the Software
+==========================
+
+* Menu:
+
+* The Configure script and its options::
+* Least-Privilege support::
+* Linux notes::
+
+\1f
+File: quagga.info, Node: The Configure script and its options, Next: Least-Privilege support, Up: Configure the Software
+
+2.1.1 The Configure script and its options
+------------------------------------------
+
+Quagga has an excellent configure script which automatically detects
+most host configurations. There are several additional configure
+options you can use to turn off IPv6 support, to disable the compilation
+of specific daemons, and to enable SNMP support.
+
+'--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.
+'--disable-opaque-lsa'
+ Disable 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.
+'--disable-ospf-te'
+ Disable support for OSPF Traffic Engineering Extension (RFC3630)
+ this requires support for Opaque LSAs.
+'--disable-ospf-ri'
+ Disable support for OSPF Router Information (RFC4970 & RFC5088)
+ this requires support for Opaque LSAs and Traffic Engineering.
+'--enable-isisd'
+ Build isisd.
+'--enable-isis-topology'
+ Enable IS-IS topology generator.
+'--enable-isis-te'
+ Enable Traffic Engineering Extension for ISIS (RFC5305)
+'--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.
+'--disable-rtadv'
+ Disable support IPV6 router advertisement in zebra.
+'--enable-gcc-rdynamic'
+ Pass the '-rdynamic' option to the linker driver. This is in most
+ cases neccessary for getting usable backtraces. This option
+ defaults to on if the compiler is detected as gcc, but giving an
+ explicit enable/disable is suggested.
+'--enable-backtrace'
+ Controls backtrace support for the crash handlers. This is
+ autodetected by default. Using the switch will enforce the
+ requested behaviour, failing with an error if support is requested
+ but not available. On BSD systems, this needs libexecinfo, while
+ on glibc support for this is part of libc itself.
+
+ You may specify any combination of the above options to the configure
+script. By default, the executables are placed in '/usr/local/sbin' and
+the configuration files in '/usr/local/etc'. The '/usr/local/'
+installation prefix and other directories may be changed using the
+following options to the configuration script.
+
+'--prefix=PREFIX'
+ Install architecture-independent files in PREFIX [/usr/local].
+'--sysconfdir=DIR'
+ Look for configuration files in DIR [PREFIX/etc]. Note that sample
+ configuration files will be installed here.
+'--localstatedir=DIR'
+ Configure zebra to use DIR for local state files, such as pid files
+ and unix sockets.
+
+ % ./configure --disable-ipv6
+
+ This command will configure zebra and the routing daemons.
+
+\1f
+File: quagga.info, Node: Least-Privilege support, Next: Linux notes, Prev: The Configure script and its options, Up: Configure the Software
+
+2.1.2 Least-Privilege support
+-----------------------------
+
+Additionally, you may configure zebra to drop its elevated privileges
+shortly after startup and switch to another user. The configure script
+will automatically try to configure this support. There are three
+configure options to control the behaviour of Quagga daemons.
+
+'--enable-user=USER'
+ Switch to user ARG shortly after startup, and run as user ARG in
+ normal operation.
+'--enable-group=GROUP'
+ Switch real and effective group to GROUP shortly after startup.
+'--enable-vty-group=GROUP'
+ Create Unix Vty sockets (for use with vtysh) with group owndership
+ set to GROUP. This allows one to create a seperate group which is
+ restricted to accessing only the Vty sockets, hence allowing one to
+ delegate this group to individual users, or to run vtysh setgid to
+ this group.
+
+ The default user and group which will be configured is 'quagga' if no
+user or group is specified. Note that this user or group requires write
+access to the local state directory (see -localstatedir) and requires at
+least read access, and write access if you wish to allow daemons to
+write out their configuration, to the configuration directory (see
+-sysconfdir).
+
+ On systems which have the 'libcap' capabilities manipulation library
+(currently only linux), the quagga system will retain only minimal
+capabilities required, further it will only raise these capabilities for
+brief periods. On systems without libcap, quagga will run as the user
+specified and only raise its uid back to uid 0 for brief periods.
+
+\1f
+File: quagga.info, Node: Linux notes, Prev: Least-Privilege support, Up: Configure the Software
+
+2.1.3 Linux Notes
+-----------------
+
+There are several options available only to GNU/Linux systems: (1). If
+you use GNU/Linux, make sure that the current kernel configuration is
+what you want. Quagga will run with any kernel configuration but some
+recommendations do exist.
+
+CONFIG_NETLINK
+ Kernel/User netlink socket. This is a brand new feature which
+ enables an advanced interface between the Linux kernel and zebra
+ (*note Kernel Interface::).
+
+CONFIG_RTNETLINK
+ Routing messages. This makes it possible to receive netlink
+ routing messages. If you specify this option, 'zebra' can detect
+ routing information updates directly from the kernel (*note Kernel
+ Interface::).
+
+CONFIG_IP_MULTICAST
+ IP: multicasting. This option should be specified when you use
+ 'ripd' (*note RIP::) or 'ospfd' (*note OSPFv2::) because these
+ protocols use multicast.
+
+ IPv6 support has been added in GNU/Linux kernel version 2.2. If you
+try to use the Quagga IPv6 feature on a GNU/Linux kernel, please make
+sure the following libraries have been installed. Please note that
+these libraries will not be needed when you uses GNU C library 2.1 or
+upper.
+
+'inet6-apps'
+ The 'inet6-apps' package includes basic IPv6 related libraries such
+ as 'inet_ntop' and 'inet_pton'. Some basic IPv6 programs such as
+ 'ping', 'ftp', and 'inetd' are also included. The 'inet-apps' can
+ be found at <ftp://ftp.inner.net/pub/ipv6/>.
+
+'net-tools'
+ The 'net-tools' package provides an IPv6 enabled interface and
+ routing utility. It contains 'ifconfig', 'route', 'netstat', and
+ other tools. 'net-tools' may be found at
+ <http://www.tazenda.demon.co.uk/phil/net-tools/>.
+
+ ---------- Footnotes ----------
+
+ (1) GNU/Linux has very flexible kernel configuration features
+
+\1f
+File: quagga.info, Node: Build the Software, Next: Install the Software, Prev: Configure the Software, Up: Installation
+
+2.2 Build the Software
+======================
+
+After configuring the software, you will need to compile it for your
+system. Simply issue the command 'make' in the root of the source
+directory and the software will be compiled. If you have *any* problems
+at this stage, be certain to send a bug report *Note Bug Reports::.
+
+ % ./configure
+ .
+ .
+ .
+ ./configure output
+ .
+ .
+ .
+ % make
+
+\1f
+File: quagga.info, Node: Install the Software, Prev: Build the Software, Up: Installation
+
+2.3 Install the Software
+========================
+
+Installing the software to your system consists of copying the compiled
+programs and supporting files to a standard location. After the
+installation process has completed, these files have been copied from
+your work directory to '/usr/local/bin', and '/usr/local/etc'.
+
+ To install the Quagga suite, issue the following command at your
+shell prompt: 'make install'.
+
+ %
+ % make install
+ %
+
+ Quagga daemons have their own terminal interface or VTY. After
+installation, you have to setup each beast's port number to connect to
+them. Please add the following entries to '/etc/services'.
+
+ zebrasrv 2600/tcp # zebra service
+ zebra 2601/tcp # zebra vty
+ ripd 2602/tcp # RIPd vty
+ ripngd 2603/tcp # RIPngd vty
+ ospfd 2604/tcp # OSPFd vty
+ bgpd 2605/tcp # BGPd vty
+ ospf6d 2606/tcp # OSPF6d vty
+ ospfapi 2607/tcp # ospfapi
+ isisd 2608/tcp # ISISd vty
+ pimd 2611/tcp # PIMd vty
+ nhrpd 2612/tcp # nhrpd vty
+
+ If you use a FreeBSD newer than 2.2.8, the above entries are already
+added to '/etc/services' so there is no need to add it. If you specify
+a port number when starting the daemon, these entries may not be needed.
+
+ You may need to make changes to the config files in
+'/etc/quagga/*.conf'. *Note Config Commands::.
+
+\1f
+File: quagga.info, Node: Basic commands, Next: Zebra, Prev: Installation, Up: Top
+
+3 Basic commands
+****************
+
+There are five routing daemons in use, and there is one manager daemon.
+These daemons may be located on separate machines from the manager
+daemon. Each of these daemons will listen on a particular port for
+incoming VTY connections. The routing daemons are:
+
+ * 'ripd', 'ripngd', 'ospfd', 'ospf6d', 'bgpd'
+ * 'zebra'
+
+ The following sections discuss commands common to all the routing
+daemons.
+
+* Menu:
+
+* Config Commands:: Commands used in config files
+* Terminal Mode Commands:: Common commands used in a VTY
+* Common Invocation Options:: Starting the daemons
+* Virtual Terminal Interfaces:: Interacting with the daemons
+
+\1f
+File: quagga.info, Node: Config Commands, Next: Terminal Mode Commands, Up: Basic commands
+
+3.1 Config Commands
+===================
+
+* Menu:
+
+* Basic Config Commands:: Some of the generic config commands
+* Sample Config File:: An example config file
+
+In a config file, you can write the debugging options, a vty's password,
+routing daemon configurations, a log file name, and so forth. This
+information forms the initial command set for a routing beast as it is
+starting.
+
+ Config files are generally found in:
+
+ '/etc/quagga/*.conf'
+
+ Each of the daemons has its own config file. For example, zebra's
+default config file name is:
+
+ '/etc/quagga/zebra.conf'
+
+ The daemon name plus '.conf' is the default config file name. You
+can specify a config file using the '-f' or '--config-file' options when
+starting the daemon.
+
+\1f
+File: quagga.info, Node: Basic Config Commands, Next: Sample Config File, Up: Config Commands
+
+3.1.1 Basic Config Commands
+---------------------------
+
+ -- Command: hostname HOSTNAME
+ Set hostname of the router.
+
+ -- Command: password PASSWORD
+ Set password for vty interface. If there is no password, a vty
+ won't accept connections.
+
+ -- Command: enable password PASSWORD
+ Set enable password.
+
+ -- Command: log trap LEVEL
+ -- Command: no log trap
+ These commands are deprecated and are present only for historical
+ compatibility. The log trap command sets the current logging level
+ for all enabled logging destinations, and it sets the default for
+ all future logging commands that do not specify a level. The
+ normal default logging level is debugging. The 'no' form of the
+ command resets the default level for future logging commands to
+ debugging, but it does not change the logging level of existing
+ logging destinations.
+
+ -- Command: log stdout
+ -- Command: log stdout LEVEL
+ -- Command: no log stdout
+ Enable logging output to stdout. If the optional second argument
+ specifying the logging level is not present, the default logging
+ level (typically debugging, but can be changed using the deprecated
+ 'log trap' command) will be used. The 'no' form of the command
+ disables logging to stdout. The 'level' argument must have one of
+ these values: emergencies, alerts, critical, errors, warnings,
+ notifications, informational, or debugging. Note that the existing
+ code logs its most important messages with severity 'errors'.
+
+ -- Command: log file FILENAME
+ -- Command: log file FILENAME LEVEL
+ -- Command: no log file
+ If you want to log into a file, please specify 'filename' as in
+ this example:
+ log file /var/log/quagga/bgpd.log informational
+ If the optional second argument specifying the logging level is not
+ present, the default logging level (typically debugging, but can be
+ changed using the deprecated 'log trap' command) will be used. The
+ 'no' form of the command disables logging to a file.
+
+ Note: if you do not configure any file logging, and a daemon
+ crashes due to a signal or an assertion failure, it will attempt to
+ save the crash information in a file named /var/tmp/quagga.<daemon
+ name>.crashlog. For security reasons, this will not happen if the
+ file exists already, so it is important to delete the file after
+ reporting the crash information.
+
+ -- Command: log syslog
+ -- Command: log syslog LEVEL
+ -- Command: no log syslog
+ Enable logging output to syslog. If the optional second argument
+ specifying the logging level is not present, the default logging
+ level (typically debugging, but can be changed using the deprecated
+ 'log trap' command) will be used. The 'no' form of the command
+ disables logging to syslog.
+
+ -- Command: log monitor
+ -- Command: log monitor LEVEL
+ -- Command: no log monitor
+ Enable logging output to vty terminals that have enabled logging
+ using the 'terminal monitor' command. By default, monitor logging
+ is enabled at the debugging level, but this command (or the
+ deprecated 'log trap' command) can be used to change the monitor
+ logging level. If the optional second argument specifying the
+ logging level is not present, the default logging level (typically
+ debugging, but can be changed using the deprecated 'log trap'
+ command) will be used. The 'no' form of the command disables
+ logging to terminal monitors.
+
+ -- Command: log facility FACILITY
+ -- Command: no log facility
+ This command changes the facility used in syslog messages. The
+ default facility is 'daemon'. The 'no' form of the command resets
+ the facility to the default 'daemon' facility.
+
+ -- Command: log record-priority
+ -- Command: no log record-priority
+ To include the severity in all messages logged to a file, to
+ stdout, or to a terminal monitor (i.e. anything except syslog),
+ use the 'log record-priority' global configuration command. To
+ disable this option, use the 'no' form of the command. By default,
+ the severity level is not included in logged messages. Note: some
+ versions of syslogd (including Solaris) can be configured to
+ include the facility and level in the messages emitted.
+
+ -- Command: log timestamp precision <0-6>
+ -- Command: no log timestamp precision
+ This command sets the precision of log message timestamps to the
+ given number of digits after the decimal point. Currently, the
+ value must be in the range 0 to 6 (i.e. the maximum precision is
+ microseconds). To restore the default behavior (1-second
+ accuracy), use the 'no' form of the command, or set the precision
+ explicitly to 0.
+
+ log timestamp precision 3
+
+ In this example, the precision is set to provide timestamps with
+ millisecond accuracy.
+
+ -- Command: log commands
+ This command enables the logging of all commands typed by a user to
+ all enabled log destinations. The note that logging includes full
+ command lines, including passwords. Once set, command logging can
+ only be turned off by restarting the daemon.
+
+ -- 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: line vty
+ Enter vty configuration mode.
+
+ -- Command: banner motd default
+ Set default motd string.
+
+ -- Command: no banner motd
+ No motd banner string will be printed.
+
+ -- Line Command: exec-timeout MINUTE
+ -- Line Command: exec-timeout MINUTE SECOND
+ Set VTY connection timeout value. When only one argument is
+ specified it is used for timeout value in minutes. Optional second
+ argument is used for timeout value in seconds. Default timeout
+ value is 10 minutes. When timeout value is zero, it means no
+ timeout.
+
+ -- Line Command: no exec-timeout
+ Do not perform timeout at all. This command is as same as
+ 'exec-timeout 0 0'.
+
+ -- Line Command: access-class ACCESS-LIST
+ Restrict vty connections with an access list.
+
+\1f
+File: quagga.info, Node: Sample Config File, Prev: Basic Config Commands, Up: Config Commands
+
+3.1.2 Sample Config File
+------------------------
+
+Below is a sample configuration file for the zebra daemon.
+
+ !
+ ! Zebra configuration file
+ !
+ hostname Router
+ password zebra
+ enable password zebra
+ !
+ log stdout
+ !
+ !
+
+ '!' and '#' are comment characters. If the first character of the
+word is one of the comment characters then from the rest of the line
+forward will be ignored as a comment.
+
+ password zebra!password
+
+ If a comment character is not the first character of the word, it's a
+normal character. So in the above example '!' will not be regarded as
+a comment and the password is set to 'zebra!password'.
+
+\1f
+File: quagga.info, Node: Terminal Mode Commands, Next: Common Invocation Options, Prev: Config Commands, Up: Basic commands
+
+3.2 Terminal Mode Commands
+==========================
+
+ -- 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
+ Show a list of currently connected vty sessions.
+
+ -- Command: list
+ List all available commands.
+
+ -- Command: show version
+ Show the current version of Quagga and its build host information.
+
+ -- Command: show logging
+ Shows the current configuration of the logging system. This
+ includes the status of all logging destinations.
+
+ -- Command: logmsg LEVEL MESSAGE
+ Send a message to all logging destinations that are enabled for
+ messages of the given severity.
+
+\1f
+File: quagga.info, Node: Common Invocation Options, Next: Virtual Terminal Interfaces, Prev: Terminal Mode Commands, Up: Basic commands
+
+3.3 Common Invocation Options
+=============================
+
+These options apply to all Quagga daemons.
+
+'-d'
+'--daemon'
+ Runs in daemon mode.
+
+'-f FILE'
+'--config_file=FILE'
+ Set configuration file name.
+
+'-h'
+'--help'
+ Display this help and exit.
+
+'-i FILE'
+'--pid_file=FILE'
+
+ Upon startup the process identifier of the daemon is written to a
+ file, typically in '/var/run'. This file can be used by the init
+ system to implement commands such as '.../init.d/zebra status',
+ '.../init.d/zebra restart' or '.../init.d/zebra stop'.
+
+ The file name is an run-time option rather than a configure-time
+ option so that multiple routing daemons can be run simultaneously.
+ This is useful when using Quagga to implement a routing looking
+ glass. One machine can be used to collect differing routing views
+ from differing points in the network.
+
+'-A ADDRESS'
+'--vty_addr=ADDRESS'
+ Set the VTY local address to bind to. If set, the VTY socket will
+ only be bound to this address.
+
+'-P PORT'
+'--vty_port=PORT'
+ Set the VTY TCP port number. If set to 0 then the TCP VTY sockets
+ will not be opened.
+
+'-u USER'
+'--vty_addr=USER'
+ Set the user and group to run as.
+
+'-v'
+'--version'
+ Print program version.
+
+\1f
+File: quagga.info, Node: Virtual Terminal Interfaces, Prev: Common Invocation Options, Up: Basic commands
+
+3.4 Virtual Terminal Interfaces
+===============================
+
+VTY - Virtual Terminal [aka TeletYpe] Interface is a command line
+interface (CLI) for user interaction with the routing daemon.
+
+* Menu:
+
+* VTY Overview:: Basics about VTYs
+* VTY Modes:: View, Enable, and Other VTY modes
+* VTY CLI Commands:: Commands for movement, edition, and management
+
+\1f
+File: quagga.info, Node: VTY Overview, Next: VTY Modes, Up: Virtual Terminal Interfaces
+
+3.4.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 1.2.3)
+ Copyright (C) 1999-2005 Kunihiro Ishiguro, et al.
+
+ User Access Verification
+
+ Password: XXXXX
+ Router> ?
+ enable Turn on privileged commands
+ exit Exit current mode and down to previous mode
+ help Description of the interactive help system
+ list Print command list
+ show Show running system information
+ who Display who is on a vty
+ Router> enable
+ Password: XXXXX
+ Router# configure terminal
+ Router(config)# interface eth0
+ Router(config-if)# ip address 10.0.0.1/8
+ Router(config-if)# ^Z
+ Router#
+
+ '?' is very useful for looking up commands.
+
+\1f
+File: quagga.info, Node: VTY Modes, Next: VTY CLI Commands, Prev: VTY Overview, Up: Virtual Terminal Interfaces
+
+3.4.2 VTY Modes
+---------------
+
+There are three basic VTY modes:
+
+* Menu:
+
+* VTY View Mode:: Mode for read-only interaction
+* VTY Enable Mode:: Mode for read-write interaction
+* VTY Other Modes:: Special modes (tftp, etc)
+
+ There are commands that may be restricted to specific VTY modes.
+
+\1f
+File: quagga.info, Node: VTY View Mode, Next: VTY Enable Mode, Up: VTY Modes
+
+3.4.2.1 VTY View Mode
+.....................
+
+This mode is for read-only access to the CLI. One may exit the mode by
+leaving the system, or by entering 'enable' mode.
+
+\1f
+File: quagga.info, Node: VTY Enable Mode, Next: VTY Other Modes, Prev: VTY View Mode, Up: VTY Modes
+
+3.4.2.2 VTY Enable Mode
+.......................
+
+This mode is for read-write access to the CLI. One may exit the mode by
+leaving the system, or by escaping to view mode.
+
+\1f
+File: quagga.info, Node: VTY Other Modes, Prev: VTY Enable Mode, Up: VTY Modes
+
+3.4.2.3 VTY Other Modes
+.......................
+
+This page is for describing other modes.
+
+\1f
+File: quagga.info, Node: VTY CLI Commands, Prev: VTY Modes, Up: Virtual Terminal Interfaces
+
+3.4.3 VTY CLI Commands
+----------------------
+
+Commands that you may use at the command-line are described in the
+following three subsubsections.
+
+* Menu:
+
+* CLI Movement Commands:: Commands for moving the cursor about
+* CLI Editing Commands:: Commands for changing text
+* CLI Advanced Commands:: Other commands, session management and so on
+
+\1f
+File: quagga.info, Node: CLI Movement Commands, Next: CLI Editing Commands, Up: VTY CLI Commands
+
+3.4.3.1 CLI Movement Commands
+.............................
+
+These commands are used for moving the CLI cursor. The <C> character
+means press the Control Key.
+
+'C-f'
+'<RIGHT>'
+ Move forward one character.
+
+'C-b'
+'<LEFT>'
+ Move backward one character.
+
+'M-f'
+ Move forward one word.
+
+'M-b'
+ Move backward one word.
+
+'C-a'
+ Move to the beginning of the line.
+
+'C-e'
+ Move to the end of the line.
+
+\1f
+File: quagga.info, Node: CLI Editing Commands, Next: CLI Advanced Commands, Prev: CLI Movement Commands, Up: VTY CLI Commands
+
+3.4.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.
+
+'C-v'
+ Interpret following character literally. Do not treat it
+ specially. This can be used to, e.g., type in a literal '?' rather
+ than do help completion.
+
+\1f
+File: quagga.info, Node: CLI Advanced Commands, Prev: CLI Editing Commands, Up: VTY CLI Commands
+
+3.4.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.
+
+ To enter an actual '?' character rather show completions, e.g. to
+ enter into a regexp, use '<C>-v ?'.
+
+\1f
+File: quagga.info, Node: Zebra, Next: RIP, Prev: Basic commands, Up: Top
+
+4 Zebra
+*******
+
+'zebra' is an IP routing manager. It provides kernel routing table
+updates, interface lookups, and redistribution of routes between
+different routing protocols.
+
+* Menu:
+
+* Invoking zebra:: Running the program
+* Interface Commands:: Commands for zebra interfaces
+* Static Route Commands:: Commands for adding static routes
+* Multicast RIB Commands:: Commands for controlling MRIB behavior
+* zebra Route Filtering:: Commands for zebra route filtering
+* zebra FIB push interface:: Interface to optional FPM component
+* zebra Terminal Mode Commands:: Commands for zebra's VTY
+
+\1f
+File: quagga.info, Node: Invoking zebra, Next: Interface Commands, Up: Zebra
+
+4.1 Invoking zebra
+==================
+
+Besides the common invocation options (*note Common Invocation
+Options::), the 'zebra' specific invocation options are listed below.
+
+'-b'
+'--batch'
+ Runs in batch mode. 'zebra' parses configuration file and
+ terminates immediately.
+
+'-k'
+'--keep_kernel'
+ When zebra starts up, don't delete old self inserted routes.
+
+'-r'
+'--retain'
+ When program terminates, retain routes added by zebra.
+
+\1f
+File: quagga.info, Node: Interface Commands, Next: Static Route Commands, Prev: Invoking zebra, Up: Zebra
+
+4.2 Interface Commands
+======================
+
+* Menu:
+
+* Standard Commands::
+* Link Parameters Commands::
+
+\1f
+File: quagga.info, Node: Standard Commands, Next: Link Parameters Commands, Up: Interface Commands
+
+4.2.1 Standard 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: ipv6 address ADDRESS/PREFIX
+ -- Interface Command: no ip address ADDRESS/PREFIX
+ -- Interface Command: no ipv6 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 Solaris, and only where network interface
+ drivers support reporting link-state via the IFF_RUNNING flag.
+
+\1f
+File: quagga.info, Node: Link Parameters Commands, Prev: Standard Commands, Up: Interface Commands
+
+4.2.2 Link Parameters Commands
+------------------------------
+
+ -- Interface Command: link-params
+ -- Interface Command: no link-param
+ Enter into the link parameters sub node. At least 'enable' must be
+ set to activate the link parameters, and consequently Traffic
+ Engineering on this interface. MPLS-TE must be enable at the OSPF
+ (*note OSPF Traffic Engineering::) or ISIS (*note ISIS Traffic
+ Engineering::) router level in complement to this. Disable link
+ parameters for this interface.
+
+ Under link parameter statement, the following commands set the
+different TE values:
+
+ -- link-params: enable
+ Enable link parameters for this interface.
+
+ -- link-params: metric <0-4294967295>
+ -- link-params: max-bw BANDWIDTH
+ -- link-params: max-rsv-bw BANDWIDTH
+ -- link-params: unrsv-bw <0-7> BANDWIDTH
+ -- link-params: admin-grp BANDWIDTH
+ These commands specifies the Traffic Engineering parameters of the
+ interface in conformity to RFC3630 (OSPF) or RFC5305 (ISIS). There
+ are respectively the TE Metric (different from the OSPF or ISIS
+ metric), Maximum Bandwidth (interface speed by default), Maximum
+ Reservable Bandwidth, Unreserved Bandwidth for each 0-7 priority
+ and Admin Group (ISIS) or Resource Class/Color (OSPF).
+
+ Note that BANDWIDTH are specified in IEEE floating point format and
+ express in Bytes/second.
+
+ -- link-param: delay <0-16777215> [min <0-16777215> | max <0-16777215>]
+ -- link-param: delay-variation <0-16777215>
+ -- link-param: packet-loss PERCENTAGE
+ -- link-param: res-bw BANDWIDTH
+ -- link-param: ava-bw BANDWIDTH
+ -- link-param: use-bw BANDWIDTH
+ These command specifies additionnal Traffic Engineering parameters
+ of the interface in conformity to
+ draft-ietf-ospf-te-metrics-extension-05.txt and
+ draft-ietf-isis-te-metrics-extension-03.txt. There are
+ respectively the delay, jitter, loss, available bandwidth,
+ reservable bandwidth and utilized bandwidth.
+
+ Note that BANDWIDTH are specified in IEEE floating point format and
+ express in Bytes/second. Delays and delay variation are express in
+ micro-second (µs). Loss is specified in PERCENTAGE ranging from 0
+ to 50.331642% by step of 0.000003.
+
+ -- link-param: neighbor <A.B.C.D> as <0-65535>
+ -- link-param: no neighbor
+ Specifies the remote ASBR IP address and Autonomous System (AS)
+ number for InterASv2 link in OSPF (RFC5392). Note that this option
+ is not yet supported for ISIS (RFC5316).
+
+\1f
+File: quagga.info, Node: Static Route Commands, Next: Multicast RIB 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.0.0.0 10.0.0.2
+ ip route 10.0.0.0 255.0.0.0 ppp0
+ ip route 10.0.0.0 255.0.0.0 null0
+
+ These statements are equivalent to those in the previous example.
+
+ -- Command: ip route NETWORK GATEWAY DISTANCE
+ Installs the route with the specified distance.
+
+ Multiple nexthop static route
+
+ ip route 10.0.0.1/32 10.0.0.2
+ ip route 10.0.0.1/32 10.0.0.3
+ ip route 10.0.0.1/32 eth0
+
+ If there is no route to 10.0.0.2 and 10.0.0.3, and interface eth0 is
+reachable, then the last route is installed into the kernel.
+
+ If zebra has been compiled with multipath support, and both 10.0.0.2
+and 10.0.0.3 are reachable, zebra will install a multipath route via
+both nexthops, if the platform supports this.
+
+ zebra> show ip route
+ S> 10.0.0.1/32 [1/0] via 10.0.0.2 inactive
+ via 10.0.0.3 inactive
+ * is directly connected, eth0
+
+ ip route 10.0.0.0/8 10.0.0.2
+ ip route 10.0.0.0/8 10.0.0.3
+ ip route 10.0.0.0/8 null0 255
+
+ This will install a multihop route via the specified next-hops if
+they are reachable, as well as a high-metric blackhole route, which can
+be useful to prevent traffic destined for a prefix to match
+less-specific routes (eg default) should the specified gateways not be
+reachable. Eg:
+
+ zebra> show ip route 10.0.0.0/8
+ Routing entry for 10.0.0.0/8
+ Known via "static", distance 1, metric 0
+ 10.0.0.2 inactive
+ 10.0.0.3 inactive
+
+ Routing entry for 10.0.0.0/8
+ Known via "static", distance 255, metric 0
+ directly connected, Null0
+
+ -- Command: ipv6 route NETWORK GATEWAY
+ -- Command: ipv6 route NETWORK GATEWAY DISTANCE
+ These behave similarly to their ipv4 counterparts.
+
+ -- Command: table TABLENO
+ Select the primary kernel routing table to be used. This only
+ works for kernels supporting multiple routing tables (like
+ GNU/Linux 2.2.x and later). After setting TABLENO with this
+ command, static routes defined after this are added to the
+ specified table.
+
+\1f
+File: quagga.info, Node: Multicast RIB Commands, Next: zebra Route Filtering, Prev: Static Route Commands, Up: Zebra
+
+4.4 Multicast RIB Commands
+==========================
+
+The Multicast RIB provides a separate table of unicast destinations
+which is used for Multicast Reverse Path Forwarding decisions. It is
+used with a multicast source's IP address, hence contains not multicast
+group addresses but unicast addresses.
+
+ This table is fully separate from the default unicast table.
+However, RPF lookup can include the unicast table.
+
+ WARNING: RPF lookup results are non-responsive in this version of
+Quagga, i.e. multicast routing does not actively react to changes in
+underlying unicast topology!
+
+ -- Command: ip multicast rpf-lookup-mode MODE
+ -- Command: no ip multicast rpf-lookup-mode [MODE]
+
+ MODE sets the method used to perform RPF lookups. Supported modes:
+
+ 'urib-only'
+ Performs the lookup on the Unicast RIB. The Multicast RIB is
+ never used.
+ 'mrib-only'
+ Performs the lookup on the Multicast RIB. The Unicast RIB is
+ never used.
+ 'mrib-then-urib'
+ Tries to perform the lookup on the Multicast RIB. If any route
+ is found, that route is used. Otherwise, the Unicast RIB is
+ tried.
+ 'lower-distance'
+ Performs a lookup on the Multicast RIB and Unicast RIB each.
+ The result with the lower administrative distance is used; if
+ they're equal, the Multicast RIB takes precedence.
+ 'longer-prefix'
+ Performs a lookup on the Multicast RIB and Unicast RIB each.
+ The result with the longer prefix length is used; if they're
+ equal, the Multicast RIB takes precedence.
+
+ The 'mrib-then-urib' setting is the default behavior if nothing is
+ configured. If this is the desired behavior, it should be
+ explicitly configured to make the configuration immune against
+ possible changes in what the default behavior is.
+
+ WARNING: Unreachable routes do not receive special treatment and do
+ not cause fallback to a second lookup.
+
+ -- Command: show ip rpf ADDR
+
+ Performs a Multicast RPF lookup, as configured with 'ip multicast
+ rpf-lookup-mode MODE'. ADDR specifies the multicast source address
+ to look up.
+
+ > show ip rpf 192.0.2.1
+ Routing entry for 192.0.2.0/24 using Unicast RIB
+ Known via "kernel", distance 0, metric 0, best
+ * 198.51.100.1, via eth0
+
+ Indicates that a multicast source lookup for 192.0.2.1 would use an
+ Unicast RIB entry for 192.0.2.0/24 with a gateway of 198.51.100.1.
+
+ -- Command: show ip rpf
+
+ Prints the entire Multicast RIB. Note that this is independent of
+ the configured RPF lookup mode, the Multicast RIB may be printed
+ yet not used at all.
+
+ -- Command: ip mroute PREFIX NEXTHOP [DISTANCE]
+ -- Command: no ip mroute PREFIX NEXTHOP [DISTANCE]
+
+ Adds a static route entry to the Multicast RIB. This performs
+ exactly as the 'ip route' command, except that it inserts the route
+ in the Multicast RIB instead of the Unicast RIB.
+
+\1f
+File: quagga.info, Node: zebra Route Filtering, Next: zebra FIB push interface, Prev: Multicast RIB Commands, Up: Zebra
+
+4.5 zebra Route Filtering
+=========================
+
+Zebra supports 'prefix-list' and 'route-map' to match routes received
+from other quagga components. The 'permit'/'deny' facilities provided
+by these commands can be used to filter which routes zebra will install
+in the kernel.
+
+ -- Command: ip protocol PROTOCOL route-map ROUTEMAP
+ Apply a route-map filter to routes for the specified protocol.
+ PROTOCOL can be any or one of system, kernel, connected, static,
+ rip, ripng, ospf, ospf6, isis, bgp, hsls.
+
+ -- Route Map: set src ADDRESS
+ Within a route-map, set the preferred source address for matching
+ routes when installing in the kernel.
+
+ The following creates a prefix-list that matches all addresses, a
+route-map that sets the preferred source address, and applies the
+route-map to all 'rip' routes.
+
+ ip prefix-list ANY permit 0.0.0.0/0 le 32
+ route-map RM1 permit 10
+ match ip address prefix-list ANY
+ set src 10.0.0.1
+
+ ip protocol rip route-map RM1
+
+\1f
+File: quagga.info, Node: zebra FIB push interface, Next: zebra Terminal Mode Commands, Prev: zebra Route Filtering, Up: Zebra
+
+4.6 zebra FIB push interface
+============================
+
+Zebra supports a 'FIB push' interface that allows an external component
+to learn the forwarding information computed by the Quagga routing
+suite.
+
+ In Quagga, the Routing Information Base (RIB) resides inside zebra.
+Routing protocols communicate their best routes to zebra, and zebra
+computes the best route across protocols for each prefix. This latter
+information makes up the Forwarding Information Base (FIB). Zebra feeds
+the FIB to the kernel, which allows the IP stack in the kernel to
+forward packets according to the routes computed by Quagga. The kernel
+FIB is updated in an OS-specific way. For example, the 'netlink'
+interface is used on Linux, and route sockets are used on FreeBSD.
+
+ The FIB push interface aims to provide a cross-platform mechanism to
+support scenarios where the router has a forwarding path that is
+distinct from the kernel, commonly a hardware-based fast path. In these
+cases, the FIB needs to be maintained reliably in the fast path as well.
+We refer to the component that programs the forwarding plane (directly
+or indirectly) as the Forwarding Plane Manager or FPM.
+
+ The FIB push interface comprises of a TCP connection between zebra
+and the FPM. The connection is initiated by zebra - that is, the FPM
+acts as the TCP server.
+
+ The relevant zebra code kicks in when zebra is configured with the
+'--enable-fpm' flag. Zebra periodically attempts to connect to the
+well-known FPM port. Once the connection is up, zebra starts sending
+messages containing routes over the socket to the FPM. Zebra sends a
+complete copy of the forwarding table to the FPM, including routes that
+it may have picked up from the kernel. The existing interaction of
+zebra with the kernel remains unchanged - that is, the kernel continues
+to receive FIB updates as before.
+
+ The encapsulation header for the messages exchanged with the FPM is
+defined by the file 'fpm/fpm.h' in the quagga tree. The routes
+themselves are encoded in netlink or protobuf format, with netlink being
+the default.
+
+ Protobuf is one of a number of new serialization formats wherein the
+message schema is expressed in a purpose-built language. Code for
+encoding/decoding to/from the wire format is generated from the schema.
+Protobuf messages can be extended easily while maintaining
+backward-compatibility with older code. Protobuf has the following
+advantages over netlink:
+
+ * Code for serialization/deserialization is generated automatically.
+ This reduces the likelihood of bugs, allows third-party programs to
+ be integrated quickly, and makes it easy to add fields.
+ * The message format is not tied to an OS (Linux), and can be evolved
+ independently.
+
+ As mentioned before, zebra encodes routes sent to the FPM in netlink
+format by default. The format can be controlled via the '--fpm_format'
+command-line option to zebra, which currently takes the values 'netlink'
+and 'protobuf'.
+
+ The zebra FPM interface uses replace semantics. That is, if a 'route
+add' message for a prefix is followed by another 'route add' message,
+the information in the second message is complete by itself, and
+replaces the information sent in the first message.
+
+ If the connection to the FPM goes down for some reason, zebra sends
+the FPM a complete copy of the forwarding table(s) when it reconnects.
+
+\1f
+File: quagga.info, Node: zebra Terminal Mode Commands, Prev: zebra FIB push interface, Up: Zebra
+
+4.7 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 ip prefix-list [NAME]
+
+ -- Command: show route-map [NAME]
+
+ -- Command: show ip protocol
+
+ -- 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.
+
+ -- Command: show zebra fpm stats
+ Display statistics related to the zebra code that interacts with
+ the optional Forwarding Plane Manager (FPM) component.
+
+ -- Command: clear zebra fpm stats
+ Reset statistics related to the zebra code that interacts with the
+ optional Forwarding Plane Manager (FPM) component.
+
+\1f
+File: quagga.info, Node: RIP, Next: RIPng, Prev: Zebra, Up: Top
+
+5 RIP
+*****
+
+RIP - Routing Information Protocol is widely deployed interior gateway
+protocol. RIP was developed in the 1970s at Xerox Labs as part of the
+XNS routing protocol. RIP is a "distance-vector" protocol and is based
+on the "Bellman-Ford" algorithms. As a distance-vector protocol, RIP
+router send updates to its neighbors periodically, thus allowing the
+convergence to a known topology. In each update, the distance to any
+given network will be broadcasted to its neighboring router.
+
+ 'ripd' supports RIP version 2 as described in RFC2453 and RIP version
+1 as described in RFC1058.
+
+* Menu:
+
+* Starting and Stopping ripd::
+* RIP Configuration::
+* RIP Version Control::
+* How to Announce RIP route::
+* Filtering RIP Routes::
+* RIP Metric Manipulation::
+* RIP distance::
+* RIP route-map::
+* RIP Authentication::
+* RIP Timers::
+* Show RIP Information::
+* RIP Debug Commands::
+
+\1f
+File: quagga.info, Node: Starting and Stopping ripd, Next: RIP Configuration, Up: RIP
+
+5.1 Starting and Stopping ripd
+==============================
+
+The default configuration file name of 'ripd''s is 'ripd.conf'. When
+invocation 'ripd' searches directory /etc/quagga. If 'ripd.conf' is not
+there next search current directory.
+
+ RIP uses UDP port 520 to send and receive RIP packets. So the user
+must have the capability to bind the port, generally this means that the
+user must have superuser privileges. RIP protocol requires interface
+information maintained by 'zebra' daemon. So running 'zebra' is
+mandatory to run 'ripd'. Thus minimum sequence for running RIP is like
+below:
+
+ # zebra -d
+ # ripd -d
+
+ Please note that 'zebra' must be invoked before 'ripd'.
+
+ To stop 'ripd'. Please use 'kill `cat /var/run/ripd.pid`'. Certain
+signals have special meaningss to 'ripd'.
+
+'SIGHUP'
+ Reload configuration file 'ripd.conf'. All configurations are
+ reseted. All routes learned so far are cleared and removed from
+ routing table.
+'SIGUSR1'
+ Rotate 'ripd' logfile.
+'SIGINT'
+'SIGTERM'
+ 'ripd' sweeps all installed RIP routes then terminates properly.
+
+ 'ripd' invocation options. Common options that can be specified
+(*note Common Invocation Options::).
+
+'-r'
+'--retain'
+ When the program terminates, retain routes added by 'ripd'.
+
+* Menu:
+
+* RIP netmask::
+
+\1f
+File: quagga.info, Node: RIP netmask, Up: Starting and Stopping ripd
+
+5.1.1 RIP netmask
+-----------------
+
+The netmask features of 'ripd' support both version 1 and version 2 of
+RIP. Version 1 of RIP originally contained no netmask information. In
+RIP version 1, network classes were originally used to determine the
+size of the netmask. Class A networks use 8 bits of mask, Class B
+networks use 16 bits of masks, while Class C networks use 24 bits of
+mask. Today, the most widely used method of a network mask is assigned
+to the packet on the basis of the interface that received the packet.
+Version 2 of RIP supports a variable length subnet mask (VLSM). By
+extending the subnet mask, the mask can be divided and reused. Each
+subnet can be used for different purposes such as large to middle size
+LANs and WAN links. Quagga 'ripd' does not support the non-sequential
+netmasks that are included in RIP Version 2.
+
+ In a case of similar information with the same prefix and metric, the
+old information will be suppressed. Ripd does not currently support
+equal cost multipath routing.
+
+\1f
+File: quagga.info, Node: RIP Configuration, Next: RIP Version Control, 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 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 split-horizon
+
+ -- Interface command: ip split-horizon
+ -- Interface command: no ip split-horizon
+ Control split-horizon on the interface. Default is 'ip
+ split-horizon'. If you don't perform split-horizon on the
+ interface, please specify 'no ip split-horizon'.
+
+\1f
+File: quagga.info, Node: RIP Version Control, Next: How to Announce RIP route, Prev: RIP Configuration, Up: RIP
+
+5.3 RIP Version Control
+=======================
+
+RIP can be configured to send either Version 1 or Version 2 packets.
+The default is to send RIPv2 while accepting both RIPv1 and RIPv2 (and
+replying with packets of the appropriate version for REQUESTS /
+triggered updates). The version to receive and send can be specified
+globally, and further overriden on a per-interface basis if needs be for
+send and receive seperately (see below).
+
+ It is important to note that RIPv1 can not be authenticated.
+Further, if RIPv1 is enabled then RIP will reply to REQUEST packets,
+sending the state of its RIP routing table to any remote routers that
+ask on demand. For a more detailed discussion on the security
+implications of RIPv1 see *note RIP Authentication::.
+
+ -- RIP Command: version VERSION
+ Set RIP version to accept for reads and send. VERSION can be
+ either '1" or '2".
+
+ Disabling RIPv1 by specifying version 2 is STRONGLY encouraged,
+ *Note RIP Authentication::. This may become the default in a
+ future release.
+
+ Default: Send Version 2, and accept either version.
+
+ -- RIP Command: no version
+ Reset the global version setting back to the default.
+
+ -- Interface command: ip rip send version VERSION
+ VERSION can be '1', '2' or '1 2'.
+
+ This interface command overrides the global rip version setting,
+ and selects which version of RIP to send packets with, for this
+ interface specifically. Choice of RIP Version 1, RIP Version 2, or
+ both versions. In the latter case, where '1 2' is specified,
+ packets will be both broadcast and multicast.
+
+ Default: Send packets according to the global version (version 2)
+
+ -- Interface command: ip rip receive version VERSION
+ VERSION can be '1', '2' or '1 2'.
+
+ This interface command overrides the global rip version setting,
+ and selects which versions of RIP packets will be accepted on this
+ interface. Choice of RIP Version 1, RIP Version 2, or both.
+
+ Default: Accept packets according to the global setting (both 1 and
+ 2).
+
+\1f
+File: quagga.info, Node: How to Announce RIP route, Next: Filtering RIP Routes, Prev: RIP Version Control, Up: RIP
+
+5.4 How to Announce RIP route
+=============================
+
+ -- RIP command: redistribute kernel
+ -- RIP command: redistribute kernel metric <0-16>
+ -- RIP command: redistribute kernel route-map ROUTE-MAP
+ -- RIP command: no redistribute kernel
+ 'redistribute kernel' redistributes routing information from kernel
+ route entries into the RIP tables. 'no redistribute kernel'
+ disables the routes.
+
+ -- RIP command: redistribute static
+ -- RIP command: redistribute static metric <0-16>
+ -- RIP command: redistribute static route-map ROUTE-MAP
+ -- RIP command: no redistribute static
+ 'redistribute static' redistributes routing information from static
+ route entries into the RIP tables. 'no redistribute static'
+ disables the routes.
+
+ -- RIP command: redistribute connected
+ -- RIP command: redistribute connected metric <0-16>
+ -- RIP command: redistribute connected route-map ROUTE-MAP
+ -- RIP command: no redistribute connected
+ Redistribute connected routes into the RIP tables. 'no
+ redistribute connected' disables the connected routes in the RIP
+ tables. This command redistribute connected of the interface which
+ RIP disabled. The connected route on RIP enabled interface is
+ announced by default.
+
+ -- RIP command: redistribute ospf
+ -- RIP command: redistribute ospf metric <0-16>
+ -- RIP command: redistribute ospf route-map ROUTE-MAP
+ -- RIP command: no redistribute ospf
+ 'redistribute ospf' redistributes routing information from ospf
+ route entries into the RIP tables. 'no redistribute ospf' disables
+ the routes.
+
+ -- RIP command: redistribute bgp
+ -- RIP command: redistribute bgp metric <0-16>
+ -- RIP command: redistribute bgp route-map ROUTE-MAP
+ -- RIP command: no redistribute bgp
+ 'redistribute bgp' redistributes routing information from bgp route
+ entries into the RIP tables. 'no redistribute bgp' disables the
+ routes.
+
+ If you want to specify RIP only static routes:
+
+ -- RIP command: default-information originate
+
+ -- RIP command: route A.B.C.D/M
+ -- RIP command: no route A.B.C.D/M
+ This command is specific to Quagga. The 'route' command makes a
+ static route only inside RIP. This command should be used only by
+ advanced users who are particularly knowledgeable about the RIP
+ protocol. In most cases, we recommend creating a static route in
+ Quagga and redistributing it in RIP using 'redistribute static'.
+
+\1f
+File: quagga.info, Node: Filtering RIP Routes, Next: RIP Metric Manipulation, Prev: How to Announce RIP route, Up: RIP
+
+5.5 Filtering RIP Routes
+========================
+
+RIP routes can be filtered by a distribute-list.
+
+ -- Command: distribute-list ACCESS_LIST DIRECT IFNAME
+ You can apply access lists to the interface with a
+ 'distribute-list' command. ACCESS_LIST is the access list name.
+ DIRECT is 'in' or 'out'. If DIRECT is 'in' the access list is
+ applied to input packets.
+
+ The 'distribute-list' command can be used to filter the RIP path.
+ 'distribute-list' can apply access-lists to a chosen interface.
+ First, one should specify the access-list. Next, the name of the
+ access-list is used in the distribute-list command. For example,
+ in the following configuration 'eth0' will permit only the paths
+ that match the route 10.0.0.0/8
+
+ !
+ router rip
+ distribute-list private in eth0
+ !
+ access-list private permit 10 10.0.0.0/8
+ access-list private deny any
+ !
+
+ 'distribute-list' can be applied to both incoming and outgoing data.
+
+ -- Command: distribute-list prefix PREFIX_LIST (in|out) IFNAME
+ You can apply prefix lists to the interface with a
+ 'distribute-list' command. PREFIX_LIST is the prefix list name.
+ Next is the direction of 'in' or 'out'. If DIRECT is 'in' the
+ access list is applied to input packets.
+
+\1f
+File: quagga.info, Node: RIP Metric Manipulation, Next: RIP distance, Prev: Filtering RIP Routes, Up: RIP
+
+5.6 RIP Metric Manipulation
+===========================
+
+RIP metric is a value for distance for the network. Usually 'ripd'
+increment the metric when the network information is received.
+Redistributed routes' metric is set to 1.
+
+ -- RIP command: default-metric <1-16>
+ -- RIP command: no default-metric <1-16>
+ This command modifies the default metric value for redistributed
+ routes. The default value is 1. This command does not affect
+ connected route even if it is redistributed by 'redistribute
+ connected'. To modify connected route's metric value, please use
+ 'redistribute connected metric' or 'route-map'. 'offset-list' also
+ affects connected routes.
+
+ -- RIP command: offset-list ACCESS-LIST (in|out)
+ -- RIP command: offset-list ACCESS-LIST (in|out) IFNAME
+
+\1f
+File: quagga.info, Node: RIP distance, Next: RIP route-map, Prev: RIP Metric Manipulation, Up: RIP
+
+5.7 RIP distance
+================
+
+Distance value is used in zebra daemon. Default RIP distance is 120.
+
+ -- RIP command: distance <1-255>
+ -- RIP command: no distance <1-255>
+ Set default RIP distance to specified value.
+
+ -- RIP command: distance <1-255> A.B.C.D/M
+ -- RIP command: no distance <1-255> A.B.C.D/M
+ Set default RIP distance to specified value when the route's source
+ IP address matches the specified prefix.
+
+ -- RIP command: distance <1-255> A.B.C.D/M ACCESS-LIST
+ -- RIP command: no distance <1-255> A.B.C.D/M ACCESS-LIST
+ Set default RIP distance to specified value when the route's source
+ IP address matches the specified prefix and the specified
+ access-list.
+
+\1f
+File: quagga.info, Node: RIP route-map, Next: RIP Authentication, Prev: RIP distance, Up: RIP
+
+5.8 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 WORD
+ -- Route Map: match ip next-hop prefix-list WORD
+ Match if route next-hop (meaning next-hop listed in the rip
+ route-table as displayed by "show ip rip") is permitted by
+ access-list.
+
+ -- Route Map: match metric <0-4294967295>
+ This command match to the metric value of RIP updates. For other
+ protocol compatibility metric range is shown as <0-4294967295>.
+ But for RIP protocol only the value range <0-16> make sense.
+
+ -- Route Map: set ip next-hop A.B.C.D
+ This command set next hop value in RIPv2 protocol. This command
+ does not affect RIPv1 because there is no next hop field in the
+ packet.
+
+ -- Route Map: set metric <0-4294967295>
+ Set a metric for matched route when sending announcement. The
+ metric value range is very large for compatibility with other
+ protocols. For RIP, valid metric values are from 1 to 16.
+
+\1f
+File: quagga.info, Node: RIP Authentication, Next: RIP Timers, Prev: RIP route-map, Up: RIP
+
+5.9 RIP Authentication
+======================
+
+RIPv2 allows packets to be authenticated via either an insecure plain
+text password, included with the packet, or via a more secure MD5 based
+HMAC (keyed-Hashing for Message AuthentiCation), RIPv1 can not be
+authenticated at all, thus when authentication is configured 'ripd' will
+discard routing updates received via RIPv1 packets.
+
+ However, unless RIPv1 reception is disabled entirely, *Note RIP
+Version Control::, RIPv1 REQUEST packets which are received, which query
+the router for routing information, will still be honoured by 'ripd',
+and 'ripd' WILL reply to such packets. This allows 'ripd' to honour
+such REQUESTs (which sometimes is used by old equipment and very simple
+devices to bootstrap their default route), while still providing
+security for route updates which are received.
+
+ In short: Enabling authentication prevents routes being updated by
+unauthenticated remote routers, but still can allow routes (I.e. the
+entire RIP routing table) to be queried remotely, potentially by anyone
+on the internet, via RIPv1.
+
+ To prevent such unauthenticated querying of routes disable RIPv1,
+*Note RIP Version Control::.
+
+ -- Interface command: ip rip authentication mode md5
+ -- Interface command: no ip rip authentication mode md5
+ Set the interface with RIPv2 MD5 authentication.
+
+ -- Interface command: ip rip authentication mode text
+ -- Interface command: no ip rip authentication mode text
+ Set the interface with RIPv2 simple password authentication.
+
+ -- Interface command: ip rip authentication string STRING
+ -- Interface command: no ip rip authentication string STRING
+ RIP version 2 has simple text authentication. This command sets
+ authentication string. The string must be shorter than 16
+ characters.
+
+ -- Interface command: ip rip authentication key-chain KEY-CHAIN
+ -- Interface command: no ip rip authentication key-chain KEY-CHAIN
+ Specifiy Keyed MD5 chain.
+
+ !
+ key chain test
+ key 1
+ key-string test
+ !
+ interface eth1
+ ip rip authentication mode md5
+ ip rip authentication key-chain test
+ !
+
+\1f
+File: quagga.info, Node: RIP Timers, Next: Show RIP Information, Prev: RIP Authentication, Up: RIP
+
+5.10 RIP Timers
+===============
+
+ -- RIP command: timers basic UPDATE TIMEOUT GARBAGE
+
+ RIP protocol has several timers. User can configure those timers'
+ values by 'timers basic' command.
+
+ The default settings for the timers are as follows:
+
+ * The update timer is 30 seconds. Every update timer seconds,
+ the RIP process is awakened to send an unsolicited Response
+ message containing the complete routing table to all
+ neighboring RIP routers.
+
+ * The timeout timer is 180 seconds. Upon expiration of the
+ timeout, the route is no longer valid; however, it is retained
+ in the routing table for a short time so that neighbors can be
+ notified that the route has been dropped.
+
+ * The garbage collect timer is 120 seconds. Upon expiration of
+ the garbage-collection timer, the route is finally removed
+ from the routing table.
+
+ The 'timers basic' command allows the the default values of the
+ timers listed above to be changed.
+
+ -- RIP command: no timers basic
+ The 'no timers basic' command will reset the timers to the default
+ settings listed above.
+
+\1f
+File: quagga.info, Node: Show RIP Information, Next: RIP Debug Commands, Prev: RIP Timers, Up: RIP
+
+5.11 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 rip status
+ The command displays current RIP status. It includes RIP timer,
+ filtering, version, RIP enabled interface and RIP peer inforation.
+
+ ripd> show ip rip status
+ Routing Protocol is "rip"
+ Sending updates every 30 seconds with +/-50%, next due in 35 seconds
+ Timeout after 180 seconds, garbage collect after 120 seconds
+ Outgoing update filter list for all interface is not set
+ Incoming update filter list for all interface is not set
+ Default redistribution metric is 1
+ Redistributing: kernel connected
+ Default version control: send version 2, receive version 2
+ Interface Send Recv
+ Routing for Networks:
+ eth0
+ eth1
+ 1.1.1.1
+ 203.181.89.241
+ Routing Information Sources:
+ Gateway BadPackets BadRoutes Distance Last Update
+
+\1f
+File: quagga.info, Node: RIP Debug Commands, Prev: Show RIP Information, Up: RIP
+
+5.12 RIP Debug Commands
+=======================
+
+Debug for RIP protocol.
+
+ -- Command: debug rip events
+ Debug rip events.
+
+ 'debug rip' will show RIP events. Sending and receiving packets,
+timers, and changes in interfaces are events shown with 'ripd'.
+
+ -- Command: debug rip packet
+ Debug rip packet.
+
+ 'debug rip packet' will display detailed information about the RIP
+packets. The origin and port number of the packet as well as a packet
+dump is shown.
+
+ -- Command: debug rip zebra
+ Debug rip between zebra communication.
+
+ This command will show the communication between 'ripd' and 'zebra'.
+The main information will include addition and deletion of paths to the
+kernel and the sending and receiving of interface information.
+
+ -- Command: show debugging rip
+ Display 'ripd''s debugging option.
+
+ 'show debugging rip' will show all information currently set for ripd
+debug.
+
+\1f
+File: quagga.info, Node: RIPng, Next: OSPFv2, Prev: RIP, Up: Top
+
+6 RIPng
+*******
+
+'ripngd' supports the RIPng protocol as described in RFC2080. It's an
+IPv6 reincarnation of the RIP protocol.
+
+* Menu:
+
+* Invoking ripngd::
+* ripngd Configuration::
+* ripngd Terminal Mode Commands::
+* ripngd Filtering Commands::
+
+\1f
+File: quagga.info, Node: Invoking ripngd, Next: ripngd Configuration, Up: RIPng
+
+6.1 Invoking ripngd
+===================
+
+There are no 'ripngd' specific invocation options. Common options can
+be specified (*note Common Invocation Options::).
+
+\1f
+File: quagga.info, Node: ripngd Configuration, Next: ripngd Terminal Mode Commands, Prev: Invoking ripngd, Up: RIPng
+
+6.2 ripngd Configuration
+========================
+
+Currently ripngd supports the following commands:
+
+ -- Command: router ripng
+ Enable RIPng.
+
+ -- RIPng Command: flush_timer TIME
+ Set flush timer.
+
+ -- RIPng Command: network NETWORK
+ Set RIPng enabled interface by NETWORK
+
+ -- RIPng Command: network IFNAME
+ Set RIPng enabled interface by IFNAME
+
+ -- RIPng Command: route NETWORK
+ Set RIPng static routing announcement of NETWORK.
+
+ -- Command: router zebra
+ This command is the default and does not appear in the
+ configuration. With this statement, RIPng routes go to the 'zebra'
+ daemon.
+
+\1f
+File: quagga.info, Node: ripngd Terminal Mode Commands, Next: ripngd Filtering Commands, Prev: ripngd Configuration, Up: RIPng
+
+6.3 ripngd Terminal Mode Commands
+=================================
+
+ -- Command: show ip ripng
+
+ -- Command: show debugging ripng
+
+ -- Command: debug ripng events
+
+ -- Command: debug ripng packet
+
+ -- Command: debug ripng zebra
+
+\1f
+File: quagga.info, Node: ripngd Filtering Commands, Prev: ripngd Terminal Mode Commands, Up: RIPng
+
+6.4 ripngd Filtering Commands
+=============================
+
+ -- Command: distribute-list ACCESS_LIST (in|out) IFNAME
+ You can apply an access-list to the interface using the
+ 'distribute-list' command. ACCESS_LIST is an access-list name.
+ DIRECT is 'in' or 'out'. If DIRECT is 'in', the access-list is
+ applied only to incoming packets.
+
+ distribute-list local-only out sit1
+
+\1f
+File: quagga.info, Node: OSPFv2, Next: OSPFv3, Prev: RIPng, Up: Top
+
+7 OSPFv2
+********
+
+OSPF (Open Shortest Path First) version 2 is a routing protocol which is
+described in 'RFC2328, OSPF Version 2'. OSPF is an IGP (Interior
+Gateway Protocol). Compared with RIP, OSPF can provide scalable network
+support and faster convergence times. OSPF is widely used in large
+networks such as ISP (Internet Service Provider) backbone and enterprise
+networks.
+
+* Menu:
+
+* OSPF Fundamentals::
+* Configuring ospfd::
+* OSPF router::
+* OSPF area::
+* OSPF interface::
+* Redistribute routes to OSPF::
+* Showing OSPF information::
+* Opaque LSA::
+* OSPF Traffic Engineering::
+* Router Information::
+* Debugging OSPF::
+* OSPF Configuration Examples::
+
+\1f
+File: quagga.info, Node: OSPF Fundamentals, Next: Configuring ospfd, Up: OSPFv2
+
+7.1 OSPF Fundamentals
+=====================
+
+OSPF is, mostly, a link-state routing protocol. In contrast to
+"distance-vector" protocols, such as RIP or BGP, where routers describe
+available "paths" (i.e. routes) to each other, in "link-state"
+protocols routers instead describe the state of their links to their
+immediate neighbouring routers.
+
+ Each router describes their link-state information in a message known
+as an LSA (Link State Advertisement), which is then propogated through
+to all other routers in a link-state routing domain, by a process called
+"flooding". Each router thus builds up an LSDB (Link State Database) of
+all the link-state messages. From this collection of LSAs in the LSDB,
+each router can then calculate the shortest path to any other router,
+based on some common metric, by using an algorithm such as Edgser
+Dijkstra (http://www.cs.utexas.edu/users/EWD/)'s SPF (Shortest Path
+First).
+
+ By describing connectivity of a network in this way, in terms of
+routers and links rather than in terms of the paths through a network, a
+link-state protocol can use less bandwidth and converge more quickly
+than other protocols. A link-state protocol need distribute only one
+link-state message throughout the link-state domain when a link on any
+single given router changes state, in order for all routers to
+reconverge on the best paths through the network. In contrast, distance
+vector protocols can require a progression of different path update
+messages from a series of different routers in order to converge.
+
+ The disadvantage to a link-state protocol is that the process of
+computing the best paths can be relatively intensive when compared to
+distance-vector protocols, in which near to no computation need be done
+other than (potentially) select between multiple routes. This overhead
+is mostly negligible for modern embedded CPUs, even for networks with
+thousands of nodes. The primary scaling overhead lies more in coping
+with the ever greater frequency of LSA updates as the size of a
+link-state area increases, in managing the LSDB and required flooding.
+
+ This section aims to give a distilled, but accurate, description of
+the more important workings of OSPF which an administrator may need to
+know to be able best configure and trouble-shoot OSPF.
+
+7.1.1 OSPF Mechanisms
+---------------------
+
+OSPF defines a range of mechanisms, concerned with detecting, describing
+and propogating state through a network. These mechanisms will nearly
+all be covered in greater detail further on. They may be broadly
+classed as:
+
+"The Hello Protocol"
+
+ The OSPF Hello protocol allows OSPF to quickly detect changes in
+ two-way reachability between routers on a link. OSPF can
+ additionally avail of other sources of reachability information,
+ such as link-state information provided by hardware, or through
+ dedicated reachability protocols such as BFD (Bi-directional
+ Forwarding Detection).
+
+ OSPF also uses the Hello protocol to propagate certain state
+ between routers sharing a link, for example:
+
+ * Hello protocol configured state, such as the dead-interval.
+ * Router priority, for DR/BDR election.
+ * DR/BDR election results.
+ * Any optional capabilities supported by each router.
+
+ The Hello protocol is comparatively trivial and will not be
+ explored in greater detail than here.
+
+"LSAs"
+
+ At the heart of OSPF are LSA (Link State Advertisement) messages.
+ Despite the name, some LSAs do not, strictly speaking, describe
+ link-state information. Common LSAs describe information such as:
+
+ * Routers, in terms of their links.
+ * Networks, in terms of attached routers.
+ * Routes, external to a link-state domain:
+
+ * External Routes
+
+ Routes entirely external to OSPF. Routers originating
+ such routes are known as ASBR (Autonomous-System Border
+ Router) routers.
+
+ * Summary Routes
+
+ Routes which summarise routing information relating to
+ OSPF areas external to the OSPF link-state area at hand,
+ originated by ABR (Area Boundary Router) routers.
+
+"LSA Flooding"
+ OSPF defines several related mechanisms, used to manage
+ synchronisation of LSDBs between neighbours as neighbours form
+ adjacencies and the propogation, or "flooding" of new or updated
+ LSAs.
+
+ *Note OSPF Flooding::.
+
+"Areas"
+ OSPF provides for the protocol to be broken up into multiple
+ smaller and independent link-state areas. Each area must be
+ connected to a common backbone area by an ABR (Area Boundary
+ Router). These ABR routers are responsible for summarising the
+ link-state routing information of an area into "Summary LSAs",
+ possibly in a condensed (i.e. aggregated) form, and then
+ originating these summaries into all other areas the ABR is
+ connected to.
+
+ Note that only summaries and external routes are passed between
+ areas. As these describe _paths_, rather than any router
+ link-states, routing between areas hence is by "distance-vector",
+ *not* link-state.
+
+ *Note OSPF Areas::.
+
+7.1.2 OSPF LSAs
+---------------
+
+LSAs are the core object in OSPF. Everything else in OSPF revolves
+around detecting what to describe in LSAs, when to update them, how to
+flood them throughout a network and how to calculate routes from them.
+
+ There are a variety of different LSAs, for purposes such as
+describing actual link-state information, describing paths (i.e.
+routes), describing bandwidth usage of links for TE (Traffic
+Engineering) purposes, and even arbitrary data by way of _Opaque_ LSAs.
+
+7.1.2.1 LSA Header
+..................
+
+All LSAs share a common header with the following information:
+
+ * Type
+
+ Different types of LSAs describe different things in OSPF. Types
+ include:
+
+ * Router LSA
+ * Network LSA
+ * Network Summary LSA
+ * Router Summary LSA
+ * AS-External LSA
+
+ The specifics of the different types of LSA are examined below.
+
+ * Advertising Router
+
+ The Router ID of the router originating the LSA, see *note ospf
+ router-id::.
+
+ * LSA ID
+
+ The ID of the LSA, which is typically derived in some way from the
+ information the LSA describes, e.g. a Router LSA uses the Router
+ ID as the LSA ID, a Network LSA will have the IP address of the DR
+ as its LSA ID.
+
+ The combination of the Type, ID and Advertising Router ID must
+ uniquely identify the LSA. There can however be multiple instances
+ of an LSA with the same Type, LSA ID and Advertising Router ID, see
+ *note LSA Sequence Number: OSPF LSA sequence number.
+
+ * Age
+
+ A number to allow stale LSAs to, eventually, be purged by routers
+ from their LSDBs.
+
+ The value nominally is one of seconds. An age of 3600, i.e. 1
+ hour, is called the "MaxAge". MaxAge LSAs are ignored in routing
+ calculations. LSAs must be periodically refreshed by their
+ Advertising Router before reaching MaxAge if they are to remain
+ valid.
+
+ Routers may deliberately flood LSAs with the age artificially set
+ to 3600 to indicate an LSA is no longer valid. This is called
+ "flushing" of an LSA.
+
+ It is not abnormal to see stale LSAs in the LSDB, this can occur
+ where a router has shutdown without flushing its LSA(s), e.g.
+ where it has become disconnected from the network. Such LSAs do
+ little harm.
+
+ * Sequence Number
+
+ A number used to distinguish newer instances of an LSA from older
+ instances.
+
+7.1.2.2 Link-State LSAs
+.......................
+
+Of all the various kinds of LSAs, just two types comprise the actual
+link-state part of OSPF, Router LSAs and Network LSAs. These LSA types
+are absolutely core to the protocol.
+
+ Instances of these LSAs are specific to the link-state area in which
+they are originated. Routes calculated from these two LSA types are
+called "intra-area routes".
+
+ * Router LSA
+
+ Each OSPF Router must originate a router LSA to describe itself.
+ In it, the router lists each of its OSPF enabled interfaces, for
+ the given link-state area, in terms of:
+
+ * Cost
+
+ The output cost of that interface, scaled inversely to some
+ commonly known reference value, *Note auto-cost
+ reference-bandwidth: OSPF auto-cost reference-bandwidth.
+
+ * Link Type
+ * Transit Network
+
+ A link to a multi-access network, on which the router has
+ at least one Full adjacency with another router.
+
+ * PtP (Point-to-Point)
+
+ A link to a single remote router, with a Full adjacency.
+ No DR (Designated Router) is elected on such links; no
+ network LSA is originated for such a link.
+
+ * Stub
+
+ A link with no adjacent neighbours, or a host route.
+
+ * Link ID and Data
+
+ These values depend on the Link Type:
+
+ Link Type Link ID Link Data
+
+ --------------------------------------------------------------
+ Transit Link IP address of Interface IP address
+ the DR
+ Point-to-PointRouter ID of the Local interface IP
+ remote router address, or the
+ ifindex (MIB-II
+ interface index) for
+ unnumbered links
+
+ Stub IP address Subnet Mask
+
+
+ Links on a router may be listed multiple times in the Router LSA,
+ e.g. a PtP interface on which OSPF is enabled must _always_ be
+ described by a Stub link in the Router LSA, in addition to being
+ listed as PtP link in the Router LSA if the adjacency with the
+ remote router is Full.
+
+ Stub links may also be used as a way to describe links on which
+ OSPF is _not_ spoken, known as "passive interfaces", see *note
+ passive-interface: OSPF passive-interface.
+
+ * Network LSA
+
+ On multi-access links (e.g. ethernets, certain kinds of ATM and
+ X.25 configurations), routers elect a DR. The DR is responsible
+ for originating a Network LSA, which helps reduce the information
+ needed to describe multi-access networks with multiple routers
+ attached. The DR also acts as a hub for the flooding of LSAs on
+ that link, thus reducing flooding overheads.
+
+ The contents of the Network LSA describes the:
+
+ * Subnet Mask
+
+ As the LSA ID of a Network LSA must be the IP address of the
+ DR, the Subnet Mask together with the LSA ID gives you the
+ network address.
+
+ * Attached Routers
+
+ Each router fully-adjacent with the DR is listed in the LSA,
+ by their Router-ID. This allows the corresponding Router LSAs
+ to be easily retrieved from the LSDB.
+
+ Summary of Link State LSAs:
+
+LSA Type LSA ID Describes LSA Data Describes
+
+--------------------------------------------------------------------
+Router LSA The Router ID The OSPF enabled links of
+ the router, within a
+ specific link-state area.
+
+Network LSA The IP address of the The Subnet Mask of the
+ DR for the network network, and the Router IDs
+ of all routers on the
+ network.
+
+ With an LSDB composed of just these two types of LSA, it is possible
+to construct a directed graph of the connectivity between all routers
+and networks in a given OSPF link-state area. So, not surprisingly,
+when OSPF routers build updated routing tables, the first stage of SPF
+calculation concerns itself only with these two LSA types.
+
+7.1.2.3 Link-State LSA Examples
+...............................
+
+The example below (*note OSPF Link-State LSA Example::) shows two LSAs,
+both originated by the same router (Router ID 192.168.0.49) and with the
+same LSA ID (192.168.0.49), but of different LSA types.
+
+ The first LSA being the router LSA describing 192.168.0.49's links: 2
+links to multi-access networks with fully-adjacent neighbours (i.e.
+Transit links) and 1 being a Stub link (no adjacent neighbours).
+
+ The second LSA being a Network LSA, for which 192.168.0.49 is the DR,
+listing the Router IDs of 4 routers on that network which are fully
+adjacent with 192.168.0.49.
+
+ # show ip ospf database router 192.168.0.49
+
+ OSPF Router with ID (192.168.0.53)
+
+
+ Router Link States (Area 0.0.0.0)
+
+ LS age: 38
+ Options: 0x2 : *|-|-|-|-|-|E|*
+ LS Flags: 0x6
+ Flags: 0x2 : ASBR
+ LS Type: router-LSA
+ Link State ID: 192.168.0.49
+ Advertising Router: 192.168.0.49
+ LS Seq Number: 80000f90
+ Checksum: 0x518b
+ Length: 60
+ Number of Links: 3
+
+ Link connected to: a Transit Network
+ (Link ID) Designated Router address: 192.168.1.3
+ (Link Data) Router Interface address: 192.168.1.3
+ Number of TOS metrics: 0
+ TOS 0 Metric: 10
+
+ Link connected to: a Transit Network
+ (Link ID) Designated Router address: 192.168.0.49
+ (Link Data) Router Interface address: 192.168.0.49
+ Number of TOS metrics: 0
+ TOS 0 Metric: 10
+
+ Link connected to: Stub Network
+ (Link ID) Net: 192.168.3.190
+ (Link Data) Network Mask: 255.255.255.255
+ Number of TOS metrics: 0
+ TOS 0 Metric: 39063
+ # show ip ospf database network 192.168.0.49
+
+ OSPF Router with ID (192.168.0.53)
+
+
+ Net Link States (Area 0.0.0.0)
+
+ LS age: 285
+ Options: 0x2 : *|-|-|-|-|-|E|*
+ LS Flags: 0x6
+ LS Type: network-LSA
+ Link State ID: 192.168.0.49 (address of Designated Router)
+ Advertising Router: 192.168.0.49
+ LS Seq Number: 80000074
+ Checksum: 0x0103
+ Length: 40
+ Network Mask: /29
+ Attached Router: 192.168.0.49
+ Attached Router: 192.168.0.52
+ Attached Router: 192.168.0.53
+ Attached Router: 192.168.0.54
+
+ Note that from one LSA, you can find the other. E.g. Given the
+Network-LSA you have a list of Router IDs on that network, from which
+you can then look up, in the local LSDB, the matching Router LSA. From
+that Router-LSA you may (potentially) find links to other Transit
+networks and Routers IDs which can be used to lookup the corresponding
+Router or Network LSA. And in that fashion, one can find all the
+Routers and Networks reachable from that starting LSA.
+
+ Given the Router LSA instead, you have the IP address of the DR of
+any attached transit links. Network LSAs will have that IP as their LSA
+ID, so you can then look up that Network LSA and from that find all the
+attached routers on that link, leading potentially to more links and
+Network and Router LSAs, etc. etc.
+
+ From just the above two LSAs, one can already see the following
+partial topology:
+
+
+ --------------------- Network: ......
+ | Designated Router IP: 192.168.1.3
+ |
+ IP: 192.168.1.3
+ (transit link)
+ (cost: 10)
+ Router ID: 192.168.0.49(stub)---------- IP: 192.168.3.190/32
+ (cost: 10) (cost: 39063)
+ (transit link)
+ IP: 192.168.0.49
+ |
+ |
+ ------------------------------ Network: 192.168.0.48/29
+ | | | Designated Router IP: 192.168.0.49
+ | | |
+ | | Router ID: 192.168.0.54
+ | |
+ | Router ID: 192.168.0.53
+ |
+ Router ID: 192.168.0.52
+
+ Note the Router IDs, though they look like IP addresses and often are
+IP addresses, are not strictly speaking IP addresses, nor need they be
+reachable addresses (though, OSPF will calculate routes to Router IDs).
+
+7.1.2.4 External LSAs
+.....................
+
+External, or "Type 5", LSAs describe routing information which is
+entirely external to OSPF, and is "injected" into OSPF. Such routing
+information may have come from another routing protocol, such as RIP or
+BGP, they may represent static routes or they may represent a default
+route.
+
+ An OSPF router which originates External LSAs is known as an ASBR (AS
+Boundary Router). Unlike the link-state LSAs, and most other LSAs,
+which are flooded only within the area in which they originate, External
+LSAs are flooded through-out the OSPF network to all areas capable of
+carrying External LSAs (*note OSPF Areas::).
+
+ Routes internal to OSPF (intra-area or inter-area) are always
+preferred over external routes.
+
+ The External LSA describes the following:
+
+ * IP Network number
+
+ The IP Network number of the route is described by the LSA ID
+ field.
+
+ * IP Network Mask
+
+ The body of the External LSA describes the IP Network Mask of the
+ route. This, together with the LSA ID, describes the prefix of the
+ IP route concerned.
+
+ * Metric
+
+ The cost of the External Route. This cost may be an OSPF cost
+ (also known as a "Type 1" metric), i.e. equivalent to the normal
+ OSPF costs, or an externally derived cost ("Type 2" metric) which
+ is not comparable to OSPF costs and always considered larger than
+ any OSPF cost. Where there are both Type 1 and 2 External routes
+ for a route, the Type 1 is always preferred.
+
+ * Forwarding Address
+
+ The address of the router to forward packets to for the route.
+ This may be, and usually is, left as 0 to specify that the ASBR
+ originating the External LSA should be used. There must be an
+ internal OSPF route to the forwarding address, for the forwarding
+ address to be useable.
+
+ * Tag
+
+ An arbitrary 4-bytes of data, not interpreted by OSPF, which may
+ carry whatever information about the route which OSPF speakers
+ desire.
+
+7.1.2.5 AS External LSA Example
+...............................
+
+To illustrate, below is an example of an External LSA in the LSDB of an
+OSPF router. It describes a route to the IP prefix of 192.168.165.0/24,
+originated by the ASBR with Router-ID 192.168.0.49. The metric of 20 is
+external to OSPF. The forwarding address is 0, so the route should
+forward to the originating ASBR if selected.
+
+ # show ip ospf database external 192.168.165.0
+ LS age: 995
+ Options: 0x2 : *|-|-|-|-|-|E|*
+ LS Flags: 0x9
+ LS Type: AS-external-LSA
+ Link State ID: 192.168.165.0 (External Network Number)
+ Advertising Router: 192.168.0.49
+ LS Seq Number: 800001d8
+ Checksum: 0xea27
+ Length: 36
+ Network Mask: /24
+ Metric Type: 2 (Larger than any link state path)
+ TOS: 0
+ Metric: 20
+ Forward Address: 0.0.0.0
+ External Route Tag: 0
+
+ We can add this to our partial topology from above, which now looks
+like:
+ --------------------- Network: ......
+ | Designated Router IP: 192.168.1.3
+ |
+ IP: 192.168.1.3 /---- External route: 192.168.165.0/24
+ (transit link) / Cost: 20 (External metric)
+ (cost: 10) /
+ Router ID: 192.168.0.49(stub)---------- IP: 192.168.3.190/32
+ (cost: 10) (cost: 39063)
+ (transit link)
+ IP: 192.168.0.49
+ |
+ |
+ ------------------------------ Network: 192.168.0.48/29
+ | | | Designated Router IP: 192.168.0.49
+ | | |
+ | | Router ID: 192.168.0.54
+ | |
+ | Router ID: 192.168.0.53
+ |
+ Router ID: 192.168.0.52
+
+7.1.2.6 Summary LSAs
+....................
+
+Summary LSAs are created by ABRs to summarise the destinations available
+within one area to other areas. These LSAs may describe IP networks,
+potentially in aggregated form, or ASBR routers.
+
+7.1.3 OSPF Flooding
+-------------------
+
+7.1.4 OSPF Areas
+----------------
+
+\1f
+File: quagga.info, Node: Configuring ospfd, Next: OSPF router, Prev: OSPF Fundamentals, Up: OSPFv2
+
+7.2 Configuring ospfd
+=====================
+
+There are no 'ospfd' specific options. Common options can be specified
+(*note Common Invocation Options::) to 'ospfd'. 'ospfd' needs to
+acquire interface information from 'zebra' in order to function.
+Therefore 'zebra' must be running before invoking 'ospfd'. Also, if
+'zebra' is restarted then 'ospfd' must be too.
+
+ Like other daemons, 'ospfd' configuration is done in OSPF specific
+configuration file 'ospfd.conf'.
+
+\1f
+File: quagga.info, Node: OSPF router, Next: OSPF area, Prev: Configuring ospfd, Up: OSPFv2
+
+7.3 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
+ This sets the router-ID of the OSPF process. The router-ID may be
+ an IP address of the router, but need not be - it can be any
+ arbitrary 32bit number. However it MUST be unique within the
+ entire OSPF domain to the OSPF speaker - bad things will happen if
+ multiple OSPF speakers are configured with the same router-ID! If
+ one is not specified then 'ospfd' will obtain a router-ID
+ automatically from 'zebra'.
+
+ -- OSPF Command: ospf abr-type TYPE
+ -- OSPF Command: no ospf abr-type TYPE
+ TYPE can be cisco|ibm|shortcut|standard. The "Cisco" and "IBM"
+ types are equivalent.
+
+ The OSPF standard for ABR behaviour does not allow an ABR to
+ consider routes through non-backbone areas when its links to the
+ backbone are down, even when there are other ABRs in attached
+ non-backbone areas which still can reach the backbone - this
+ restriction exists primarily to ensure routing-loops are avoided.
+
+ With the "Cisco" or "IBM" ABR type, the default in this release of
+ Quagga, this restriction is lifted, allowing an ABR to consider
+ summaries learnt from other ABRs through non-backbone areas, and
+ hence route via non-backbone areas as a last resort when, and only
+ when, backbone links are down.
+
+ Note that areas with fully-adjacent virtual-links are considered to
+ be "transit capable" and can always be used to route backbone
+ traffic, and hence are unaffected by this setting (*note OSPF
+ virtual-link::).
+
+ More information regarding the behaviour controlled by this command
+ can be found in 'RFC 3509, Alternative Implementations of OSPF Area
+ Border Routers', and 'draft-ietf-ospf-shortcut-abr-02.txt'.
+
+ Quote: "Though the definition of the ABR (Area Border Router) 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
+ '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 backbone path are now of equal
+ preference but still both preferred to external paths.
+
+ This command should NOT be set normally.
+
+ -- OSPF Command: log-adjacency-changes [detail]
+ -- OSPF Command: no log-adjacency-changes [detail]
+ Configures ospfd to log changes in adjacency. With the optional
+ detail argument, all changes in adjacency status are shown.
+ Without detail, only changes to full or regressions are shown.
+
+ -- OSPF Command: passive-interface INTERFACE
+ -- OSPF Command: no passive-interface INTERFACE
+ Do not speak OSPF interface on the given interface, but do
+ advertise the interface as a stub link in the router-LSA (Link
+ State Advertisement) for this router. This allows one to advertise
+ addresses on such connected interfaces without having to originate
+ AS-External/Type-5 LSAs (which have global flooding scope) - as
+ would occur if connected addresses were redistributed into OSPF
+ (*note Redistribute routes to OSPF::). This is the only way to
+ advertise non-OSPF links into stub areas.
+
+ -- OSPF Command: timers throttle spf DELAY INITIAL-HOLDTIME
+ MAX-HOLDTIME
+ -- OSPF Command: no timers throttle spf
+ This command sets the initial DELAY, the INITIAL-HOLDTIME and the
+ MAXIMUM-HOLDTIME between when SPF is calculated and the event which
+ triggered the calculation. The times are specified in milliseconds
+ and must be in the range of 0 to 600000 milliseconds.
+
+ The DELAY specifies the minimum amount of time to delay SPF
+ calculation (hence it affects how long SPF calculation is delayed
+ after an event which occurs outside of the holdtime of any previous
+ SPF calculation, and also serves as a minimum holdtime).
+
+ Consecutive SPF calculations will always be seperated by at least
+ 'hold-time' milliseconds. The hold-time is adaptive and initially
+ is set to the INITIAL-HOLDTIME configured with the above command.
+ Events which occur within the holdtime of the previous SPF
+ calculation will cause the holdtime to be increased by
+ INITIAL-HOLDTIME, bounded by the MAXIMUM-HOLDTIME configured with
+ this command. If the adaptive hold-time elapses without any
+ SPF-triggering event occuring then the current holdtime is reset to
+ the INITIAL-HOLDTIME. The current holdtime can be viewed with
+ *note show ip ospf::, where it is expressed as a multiplier of the
+ INITIAL-HOLDTIME.
+
+ router ospf
+ timers throttle spf 200 400 10000
+
+ In this example, the DELAY is set to 200ms, the INITIAL HOLDTIME is
+ set to 400ms and the MAXIMUM HOLDTIME to 10s. Hence there will
+ always be at least 200ms between an event which requires SPF
+ calculation and the actual SPF calculation. Further consecutive
+ SPF calculations will always be seperated by between 400ms to 10s,
+ the hold-time increasing by 400ms each time an SPF-triggering event
+ occurs within the hold-time of the previous SPF calculation.
+
+ This command supercedes the 'timers spf' command in previous Quagga
+ releases.
+
+ -- OSPF Command: max-metric router-lsa [on-startup|on-shutdown]
+ <5-86400>
+ -- OSPF Command: max-metric router-lsa administrative
+ -- OSPF Command: no max-metric router-lsa
+ [on-startup|on-shutdown|administrative]
+ This enables 'RFC3137, OSPF Stub Router Advertisement' support,
+ where the OSPF process describes its transit links in its
+ router-LSA as having infinite distance so that other routers will
+ avoid calculating transit paths through the router while still
+ being able to reach networks through the router.
+
+ This support may be enabled administratively (and indefinitely) or
+ conditionally. Conditional enabling of max-metric router-lsas can
+ be for a period of seconds after startup and/or for a period of
+ seconds prior to shutdown.
+
+ Enabling this for a period after startup allows OSPF to converge
+ fully first without affecting any existing routes used by other
+ routers, while still allowing any connected stub links and/or
+ redistributed routes to be reachable. Enabling this for a period
+ of time in advance of shutdown allows the router to gracefully
+ excuse itself from the OSPF domain.
+
+ Enabling this feature administratively allows for administrative
+ intervention for whatever reason, for an indefinite period of time.
+ Note that if the configuration is written to file, this
+ administrative form of the stub-router command will also be written
+ to file. If 'ospfd' is restarted later, the command will then take
+ effect until manually deconfigured.
+
+ Configured state of this feature as well as current status, such as
+ the number of second remaining till on-startup or on-shutdown ends,
+ can be viewed with the *note show ip ospf:: command.
+
+ -- OSPF Command: auto-cost reference-bandwidth <1-4294967>
+ -- OSPF Command: no auto-cost reference-bandwidth
+ This sets the reference bandwidth for cost calculations, where this
+ bandwidth is considered equivalent to an OSPF cost of 1, specified
+ in Mbits/s. The default is 100Mbit/s (i.e. a link of bandwidth
+ 100Mbit/s or higher will have a cost of 1. Cost of lower bandwidth
+ links will be scaled with reference to this cost).
+
+ This configuration setting MUST be consistent across all routers
+ within the OSPF domain.
+
+ -- 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.
+
+ Note that the behavior when there is a peer address defined on an
+ interface changed after release 0.99.7. Currently, if a peer
+ prefix has been configured, then we test whether the prefix in the
+ network command contains the destination prefix. Otherwise, we
+ test whether the network command prefix contains the local address
+ prefix of the interface.
+
+ In some cases it may be more convenient to enable OSPF on a per
+ interface/subnet basis (*note OSPF ip ospf area command::).
+
+\1f
+File: quagga.info, Node: OSPF area, Next: OSPF interface, Prev: OSPF router, Up: OSPFv2
+
+7.4 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
+ Configure the area as Shortcut capable. See 'RFC3509'. This
+ requires that the 'abr-type' be set to '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
+ Configure the area to be a stub area. That is, an area where no
+ router originates routes external to OSPF and hence an area where
+ all external routes are via the ABR(s). Hence, ABRs for such an
+ area do not need to pass AS-External LSAs (type-5s) or ASBR-Summary
+ LSAs (type-4) into the area. They need only pass Network-Summary
+ (type-3) LSAs into such an area, along with a default-route
+ summary.
+
+ -- 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
+ Prevents an 'ospfd' ABR from injecting inter-area summaries into
+ the specified stub area.
+
+ -- OSPF Command: area A.B.C.D default-cost <0-16777215>
+ -- OSPF Command: no area A.B.C.D default-cost <0-16777215>
+ Set the cost of default-summary LSAs announced to stubby areas.
+
+ -- 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 is only relevant if the router is an ABR for the
+ specified area.
+
+ -- 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
+ Specify that simple password authentication should be used for the
+ given area.
+
+ -- OSPF Command: area A.B.C.D authentication message-digest
+ -- OSPF Command: area <0-4294967295> authentication message-digest
+
+ Specify that OSPF packets must be authenticated with MD5 HMACs
+ within the given area. Keying material must also be configured on
+ a per-interface basis (*note ip ospf message-digest-key::).
+
+ MD5 authentication may also be configured on a per-interface basis
+ (*note ip ospf authentication message-digest::). Such
+ per-interface settings will override any per-area authentication
+ setting.
+
+\1f
+File: quagga.info, Node: OSPF interface, Next: Redistribute routes to OSPF, Prev: OSPF area, Up: OSPFv2
+
+7.5 OSPF interface
+==================
+
+ -- Interface Command: ip ospf area AREA [ADDR]
+ -- Interface Command: no ip ospf area [ADDR]
+
+ Enable OSPF on the interface, optionally restricted to just the IP
+ address given by ADDR, putting it in the AREA area. Per interface
+ area settings take precedence to network commands (*note OSPF
+ network command::).
+
+ If you have a lot of interfaces, and/or a lot of subnets, then
+ enabling OSPF via this command may result in a slight performance
+ improvement.
+
+ -- 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.
+
+ Simple text password authentication is insecure and deprecated in
+ favour of MD5 HMAC authentication (*note ip ospf authentication
+ message-digest::).
+
+ -- Interface Command: ip ospf authentication message-digest
+ Specify that MD5 HMAC authentication must be used on this
+ interface. MD5 keying material must also be configured (*note ip
+ ospf message-digest-key::). Overrides any authentication enabled
+ on a per-area basis (*note area authentication message-digest::).
+
+ 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 or
+ non-volatile 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 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.
+ This ID is part of the protocol and must be consistent across
+ routers on a link.
+
+ KEY is the actual message digest key, of up to 16 chars (larger
+ strings will be truncated), and is associated with the given KEYID.
+
+ -- 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: ip ospf dead-interval minimal hello-multiplier
+ <2-20>
+ -- 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.
+
+ If 'minimal' is specified instead, then the dead-interval is set to
+ 1 second and one must specify a hello-multiplier. The
+ hello-multiplier specifies how many Hellos to send per second, from
+ 2 (every 500ms) to 20 (every 50ms). Thus one can have 1s
+ convergence time for OSPF. If this form is specified, then the
+ hello-interval advertised in Hello packets is set to 0 and the
+ hello-interval on received Hello packets is not checked, thus the
+ hello-multiplier need NOT be the same across multiple routers on a
+ common link.
+
+ -- 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.
+
+ This command has no effect if *note ip ospf dead-interval minimal::
+ is also specified for the interface.
+
+ -- 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. The router with the highest
+ priority will be more eligible to become Designated Router.
+ Setting the value to 0, makes the router ineligible to become
+ Designated Router. The default value is 1.
+
+ -- Interface Command: ip ospf retransmit-interval <1-65535>
+ -- Interface Command: no ip ospf retransmit interval
+ Set number of seconds for RxmtInterval timer value. This value is
+ used when retransmitting Database Description and Link State
+ Request packets. The default value is 5 seconds.
+
+ -- Interface Command: ip ospf transmit-delay
+ -- Interface Command: no ip ospf transmit-delay
+ Set number of seconds for InfTransDelay value. LSAs' age should be
+ incremented by this value when transmitting. The default value is
+ 1 seconds.
+
+\1f
+File: quagga.info, Node: Redistribute routes to OSPF, Next: Showing OSPF information, Prev: OSPF interface, Up: OSPFv2
+
+7.6 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)
+ Redistribute routes of the specified protocol or kind into OSPF,
+ with the metric type and metric set if specified, filtering the
+ routes using the given route-map if specified. Redistributed
+ routes may also be filtered with distribute-lists, see *note ospf
+ distribute-list::.
+
+ Redistributed routes are distributed as into OSPF as Type-5
+ External LSAs into links to areas that accept external routes,
+ Type-7 External LSAs for NSSA areas and are not redistributed at
+ all into Stub areas, where external routes are not permitted.
+
+ Note that for connected routes, one may instead use
+ "passive-interface", see *note OSPF passive-interface::.
+
+ -- 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
+ Originate an AS-External (type-5) LSA describing a default route
+ into all external-routing capable areas, of the specified metric
+ and metric type. If the 'always' keyword is given then the default
+ is always advertised, even when there is no default present in the
+ routing table.
+
+ -- OSPF Command: distribute-list NAME out
+ (kernel|connected|static|rip|ospf
+ -- OSPF Command: no distribute-list NAME out
+ (kernel|connected|static|rip|ospf
+ Apply the access-list filter, NAME, to redistributed routes of the
+ given type before allowing the routes to redistributed into OSPF
+ (*note OSPF redistribute::).
+
+ -- 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
+
+\1f
+File: quagga.info, Node: Showing OSPF information, Next: Opaque LSA, Prev: Redistribute routes to OSPF, Up: OSPFv2
+
+7.7 Showing OSPF information
+============================
+
+ -- Command: show ip ospf
+ Show information on a variety of general OSPF and area state and
+ configuration information.
+
+ -- Command: show ip ospf interface [INTERFACE]
+ Show state and configuration of OSPF the specified interface, or
+ all interfaces if no interface is given.
+
+ -- 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
+ -- Command: show ip ospf database external
+ -- Command: show ip ospf database network
+ -- Command: show ip ospf database asbr-router
+ -- Command: show ip ospf database summary
+ -- Command: show ip ospf database ... LINK-STATE-ID
+ -- Command: show ip ospf database ... LINK-STATE-ID adv-router
+ ADV-ROUTER
+ -- Command: show ip ospf database ... adv-router ADV-ROUTER
+ -- Command: show ip ospf database ... LINK-STATE-ID self-originate
+ -- Command: show ip ospf database ... self-originate
+
+ -- Command: show ip ospf database max-age
+
+ -- Command: show ip ospf database self-originate
+
+ -- Command: show ip ospf route
+ Show the OSPF routing table, as determined by the most recent SPF
+ calculation.
+
+\1f
+File: quagga.info, Node: Opaque LSA, Next: OSPF Traffic Engineering, Prev: Showing OSPF information, Up: OSPFv2
+
+7.8 Opaque LSA
+==============
+
+ -- OSPF Command: ospf opaque-lsa
+ -- OSPF Command: capability opaque
+ -- OSPF Command: no ospf opaque-lsa
+ -- OSPF Command: no capability opaque
+ 'ospfd' support Opaque LSA (RFC2370) as fondment for MPLS Traffic
+ Engineering LSA. Prior to used MPLS TE, opaque-lsa must be enable
+ in the configuration file. Alternate command could be "mpls-te on"
+ (*note OSPF Traffic Engineering::).
+
+ -- Command: show ip ospf database
+ (opaque-link|opaque-area|opaque-external)
+ -- Command: show ip ospf database
+ (opaque-link|opaque-area|opaque-external) LINK-STATE-ID
+ -- Command: show ip ospf database
+ (opaque-link|opaque-area|opaque-external) LINK-STATE-ID
+ adv-router ADV-ROUTER
+ -- Command: show ip ospf database
+ (opaque-link|opaque-area|opaque-external) adv-router
+ ADV-ROUTER
+ -- Command: show ip ospf database
+ (opaque-link|opaque-area|opaque-external) LINK-STATE-ID
+ self-originate
+ -- Command: show ip ospf database
+ (opaque-link|opaque-area|opaque-external) self-originate
+ Show Opaque LSA from the database.
+
+\1f
+File: quagga.info, Node: OSPF Traffic Engineering, Next: Router Information, Prev: Opaque LSA, Up: OSPFv2
+
+7.9 Traffic Engineering
+=======================
+
+ -- OSPF Command: mpls-te on
+ -- OSPF Command: no mpls-te
+ Enable Traffic Engineering LSA flooding.
+
+ -- OSPF Command: mpls-te router-address <A.B.C.D>
+ -- OSPF Command: no mpls-te
+ Configure stable IP address for MPLS-TE. This IP address is then
+ advertise in Opaque LSA Type-10 TLV=1 (TE) option 1
+ (Router-Address).
+
+ -- OSPF Command: mpls-te inter-as area <area-id>|as
+ -- OSPF Command: no mpls-te inter-as
+ Enable RFC5392 suuport - Inter-AS TE v2 - to flood Traffic
+ Engineering parameters of Inter-AS link. 2 modes are supported:
+ AREA and AS; LSA are flood in AREA <area-id> with Opaque Type-10,
+ respectively in AS with Opaque Type-11. In all case, Opaque-LSA
+ TLV=6.
+
+ -- Command: show ip ospf mpls-te interface
+ -- Command: show ip ospf mpls-te interface INTERFACE
+ Show MPLS Traffic Engineering parameters for all or specified
+ interface.
+
+ -- Command: show ip ospf mpls-te router
+ Show Traffic Engineering router parameters.
+
+\1f
+File: quagga.info, Node: Router Information, Next: Debugging OSPF, Prev: OSPF Traffic Engineering, Up: OSPFv2
+
+7.10 Router Information
+=======================
+
+ -- OSPF Command: router-info [as | area <A.B.C.D>]
+ -- OSPF Command: no router-info
+ Enable Router Information (RFC4970) LSA advertisement with AS scope
+ (default) or Area scope flooding when area is specified.
+
+ -- OSPF Command: pce address <A.B.C.D>
+ -- OSPF Command: no pce address
+ -- OSPF Command: pce domain as <0-65535>
+ -- OSPF Command: no pce domain as <0-65535>
+ -- OSPF Command: pce neighbor as <0-65535>
+ -- OSPF Command: no pce neighbor as <0-65535>
+ -- OSPF Command: pce flag BITPATTERN
+ -- OSPF Command: no pce flag
+ -- OSPF Command: pce scope BITPATTERN
+ -- OSPF Command: no pce scope
+ The commands are conform to RFC 5088 and allow OSPF router announce
+ Path Compuatation Elemenent (PCE) capabilities through the Router
+ Information (RI) LSA. Router Information must be enable prior to
+ this. The command set/unset respectively the PCE IP adress,
+ Autonomous System (AS) numbers of controlled domains, neighbor ASs,
+ flag and scope. For flag and scope, please refer to RFC5088 for
+ the BITPATTERN recognition. Multiple 'pce neighbor' command could
+ be specified in order to specify all PCE neighbours.
+
+ -- Command: show ip ospf router-info
+ Show Router Capabilities flag.
+ -- Command: show ip ospf router-info pce
+ Show Router Capabilities PCE parameters.
+
+\1f
+File: quagga.info, Node: Debugging OSPF, Next: OSPF Configuration Examples, Prev: Router Information, Up: OSPFv2
+
+7.11 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]
+ Dump Packet for debugging
+
+ -- Command: debug ospf ism
+ -- Command: debug ospf ism (status|events|timers)
+ -- Command: no debug ospf ism
+ -- Command: no debug ospf ism (status|events|timers)
+ Show debug information of Interface State Machine
+
+ -- Command: debug ospf nsm
+ -- Command: debug ospf nsm (status|events|timers)
+ -- Command: no debug ospf nsm
+ -- Command: no debug ospf nsm (status|events|timers)
+ Show debug information of Network State Machine
+
+ -- Command: debug ospf event
+ -- Command: no debug ospf event
+ Show debug information of OSPF event
+
+ -- Command: debug ospf nssa
+ -- Command: no debug ospf nssa
+ Show debug information about Not So Stub Area
+
+ -- Command: debug ospf lsa
+ -- Command: debug ospf lsa (generate|flooding|refresh)
+ -- Command: no debug ospf lsa
+ -- Command: no debug ospf lsa (generate|flooding|refresh)
+ Show debug detail of Link State messages
+
+ -- Command: debug ospf te
+ -- Command: no debug ospf te
+ Show debug information about Traffic Engineering LSA
+
+ -- Command: debug ospf zebra
+ -- Command: debug ospf zebra (interface|redistribute)
+ -- Command: no debug ospf zebra
+ -- Command: no debug ospf zebra (interface|redistribute)
+ Show debug information of ZEBRA API
+
+ -- Command: show debugging ospf
+
+\1f
+File: quagga.info, Node: OSPF Configuration Examples, Prev: Debugging OSPF, Up: OSPFv2
+
+7.12 OSPF Configuration Examples
+================================
+
+A simple example, with MD5 authentication enabled:
+
+ !
+ interface bge0
+ ip ospf authentication message-digest
+ ip ospf message-digest-key 1 md5 ABCDEFGHIJK
+ !
+ router ospf
+ network 192.168.0.0/16 area 0.0.0.1
+ area 0.0.0.1 authentication message-digest
+
+ An ABR router, with MD5 authentication and performing summarisation
+of networks between the areas:
+
+ !
+ password ABCDEF
+ log file /var/log/quagga/ospfd.log
+ service advanced-vty
+ !
+ interface eth0
+ ip ospf authentication message-digest
+ ip ospf message-digest-key 1 md5 ABCDEFGHIJK
+ !
+ interface ppp0
+ !
+ interface br0
+ ip ospf authentication message-digest
+ ip ospf message-digest-key 2 md5 XYZ12345
+ !
+ router ospf
+ ospf router-id 192.168.0.1
+ redistribute connected
+ passive interface ppp0
+ network 192.168.0.0/24 area 0.0.0.0
+ network 10.0.0.0/16 area 0.0.0.0
+ network 192.168.1.0/24 area 0.0.0.1
+ area 0.0.0.0 authentication message-digest
+ area 0.0.0.0 range 10.0.0.0/16
+ area 0.0.0.0 range 192.168.0.0/24
+ area 0.0.0.1 authentication message-digest
+ area 0.0.0.1 range 10.2.0.0/16
+ !
+
+ A Traffic Engineering configuration, with Inter-ASv2 support.
+
+ - First, the 'zebra.conf' part:
+
+ hostname HOSTNAME
+ password PASSWORD
+ log file /var/log/zebra.log
+ !
+ interface eth0
+ ip address 198.168.1.1/24
+ mpls-te on
+ mpls-te link metric 10
+ mpls-te link max-bw 1.25e+06
+ mpls-te link max-rsv-bw 1.25e+06
+ mpls-te link unrsv-bw 0 1.25e+06
+ mpls-te link unrsv-bw 1 1.25e+06
+ mpls-te link unrsv-bw 2 1.25e+06
+ mpls-te link unrsv-bw 3 1.25e+06
+ mpls-te link unrsv-bw 4 1.25e+06
+ mpls-te link unrsv-bw 5 1.25e+06
+ mpls-te link unrsv-bw 6 1.25e+06
+ mpls-te link unrsv-bw 7 1.25e+06
+ mpls-te link rsc-clsclr 0xab
+ !
+ interface eth1
+ ip address 192.168.2.1/24
+ mpls-te on
+ mpls-te link metric 10
+ mpls-te link max-bw 1.25e+06
+ mpls-te link max-rsv-bw 1.25e+06
+ mpls-te link unrsv-bw 0 1.25e+06
+ mpls-te link unrsv-bw 1 1.25e+06
+ mpls-te link unrsv-bw 2 1.25e+06
+ mpls-te link unrsv-bw 3 1.25e+06
+ mpls-te link unrsv-bw 4 1.25e+06
+ mpls-te link unrsv-bw 5 1.25e+06
+ mpls-te link unrsv-bw 6 1.25e+06
+ mpls-te link unrsv-bw 7 1.25e+06
+ mpls-te link rsc-clsclr 0xab
+ mpls-te neighbor 192.168.2.2 as 65000
+
+ - Then the 'ospfd.conf' itself:
+
+ hostname HOSTNAME
+ password PASSWORD
+ log file /var/log/ospfd.log
+ !
+ !
+ interface eth0
+ ip ospf hello-interval 60
+ ip ospf dead-interval 240
+ !
+ interface eth1
+ ip ospf hello-interval 60
+ ip ospf dead-interval 240
+ !
+ !
+ router ospf
+ ospf router-id 192.168.1.1
+ network 192.168.0.0/16 area 1
+ ospf opaque-lsa
+ mpls-te
+ mpls-te router-address 192.168.1.1
+ mpls-te inter-as area 1
+ !
+ line vty
+
+ A router information example with PCE advsertisement:
+
+ !
+ router ospf
+ ospf router-id 192.168.1.1
+ network 192.168.0.0/16 area 1
+ capability opaque
+ mpls-te
+ mpls-te router-address 192.168.1.1
+ router-info area 0.0.0.1
+ pce address 192.168.1.1
+ pce flag 0x80
+ pce domain as 65400
+ pce neighbor as 65500
+ pce neighbor as 65200
+ pce scope 0x80
+ !
+
+\1f
+File: quagga.info, Node: OSPFv3, Next: ISIS, 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::
+* OSPF6 Configuration Examples::
+
+\1f
+File: quagga.info, Node: OSPF6 router, Next: OSPF6 area, Up: OSPFv3
+
+8.1 OSPF6 router
+================
+
+ -- Command: router ospf6
+
+ -- OSPF6 Command: router-id A.B.C.D
+ Set router's Router-ID.
+
+ -- OSPF6 Command: interface IFNAME area AREA
+ Bind interface to specified area, and start sending OSPF packets.
+ AREA can be specified as 0.
+
+ -- OSPF6 Command: timers throttle spf DELAY INITIAL-HOLDTIME
+ MAX-HOLDTIME
+ -- OSPF6 Command: no timers throttle spf
+ This command sets the initial DELAY, the INITIAL-HOLDTIME and the
+ MAXIMUM-HOLDTIME between when SPF is calculated and the event which
+ triggered the calculation. The times are specified in milliseconds
+ and must be in the range of 0 to 600000 milliseconds.
+
+ The DELAY specifies the minimum amount of time to delay SPF
+ calculation (hence it affects how long SPF calculation is delayed
+ after an event which occurs outside of the holdtime of any previous
+ SPF calculation, and also serves as a minimum holdtime).
+
+ Consecutive SPF calculations will always be seperated by at least
+ 'hold-time' milliseconds. The hold-time is adaptive and initially
+ is set to the INITIAL-HOLDTIME configured with the above command.
+ Events which occur within the holdtime of the previous SPF
+ calculation will cause the holdtime to be increased by
+ INITIAL-HOLDTIME, bounded by the MAXIMUM-HOLDTIME configured with
+ this command. If the adaptive hold-time elapses without any
+ SPF-triggering event occuring then the current holdtime is reset to
+ the INITIAL-HOLDTIME.
+
+ router ospf6
+ timers throttle spf 200 400 10000
+
+ In this example, the DELAY is set to 200ms, the INITIAL HOLDTIME is
+ set to 400ms and the MAXIMUM HOLDTIME to 10s. Hence there will
+ always be at least 200ms between an event which requires SPF
+ calculation and the actual SPF calculation. Further consecutive
+ SPF calculations will always be seperated by between 400ms to 10s,
+ the hold-time increasing by 400ms each time an SPF-triggering event
+ occurs within the hold-time of the previous SPF calculation.
+
+ -- OSPF6 Command: auto-cost reference-bandwidth COST
+ -- OSPF6 Command: no auto-cost reference-bandwidth
+ This sets the reference bandwidth for cost calculations, where this
+ bandwidth is considered equivalent to an OSPF cost of 1, specified
+ in Mbits/s. The default is 100Mbit/s (i.e. a link of bandwidth
+ 100Mbit/s or higher will have a cost of 1. Cost of lower bandwidth
+ links will be scaled with reference to this cost).
+
+ This configuration setting MUST be consistent across all routers
+ within the OSPF domain.
+
+\1f
+File: quagga.info, Node: OSPF6 area, Next: OSPF6 interface, Prev: OSPF6 router, Up: OSPFv3
+
+8.2 OSPF6 area
+==============
+
+Area support for OSPFv3 is not yet implemented.
+
+\1f
+File: quagga.info, Node: OSPF6 interface, Next: Redistribute routes to OSPF6, Prev: OSPF6 area, Up: OSPFv3
+
+8.3 OSPF6 interface
+===================
+
+ -- Interface Command: ipv6 ospf6 cost COST
+ Sets interface's output cost. Default value depends on the
+ interface bandwidth and on the auto-cost reference bandwidth.
+
+ -- 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.
+
+ -- Interface Command: ipv6 ospf6 network (broadcast|point-to-point)
+ Set explicitly network type for specifed interface.
+
+\1f
+File: quagga.info, Node: Redistribute routes to OSPF6, Next: Showing OSPF6 information, Prev: OSPF6 interface, Up: OSPFv3
+
+8.4 Redistribute routes to OSPF6
+================================
+
+ -- OSPF6 Command: redistribute static
+ -- OSPF6 Command: redistribute connected
+ -- OSPF6 Command: redistribute ripng
+
+\1f
+File: quagga.info, Node: Showing OSPF6 information, Next: OSPF6 Configuration Examples, Prev: Redistribute routes to OSPF6, Up: OSPFv3
+
+8.5 Showing OSPF6 information
+=============================
+
+ -- Command: show ipv6 ospf6 [INSTANCE_ID]
+ INSTANCE_ID is an optional OSPF instance ID. To see router ID and
+ OSPF instance ID, simply type "show ipv6 ospf6 <cr>".
+
+ -- Command: show ipv6 ospf6 database
+ This command shows LSA database summary. You can specify the type
+ of LSA.
+
+ -- Command: show ipv6 ospf6 interface
+ To see OSPF interface configuration like costs.
+
+ -- Command: show ipv6 ospf6 neighbor
+ Shows state and chosen (Backup) DR of neighbor.
+
+ -- Command: show ipv6 ospf6 request-list A.B.C.D
+ Shows requestlist of neighbor.
+
+ -- Command: show ipv6 route ospf6
+ This command shows internal routing table.
+
+\1f
+File: quagga.info, Node: OSPF6 Configuration Examples, Prev: Showing OSPF6 information, Up: OSPFv3
+
+8.6 OSPF6 Configuration Examples
+================================
+
+Example of ospf6d configured on one interface and area:
+
+ interface eth0
+ ipv6 ospf6 instance-id 0
+ !
+ router ospf6
+ router-id 212.17.55.53
+ area 0.0.0.0 range 2001:770:105:2::/64
+ interface eth0 area 0.0.0.0
+ !
+
+\1f
+File: quagga.info, Node: ISIS, Next: NHRP, Prev: OSPFv3, Up: Top
+
+9 ISIS
+******
+
+ISIS (Intermediate System to Intermediate System) is a routing protocol
+which is described in 'ISO10589, RFC1195, RFC5308'. ISIS is an IGP
+(Interior Gateway Protocol). Compared with RIP, ISIS can provide
+scalable network support and faster convergence times like OSPF. ISIS
+is widely used in large networks such as ISP (Internet Service Provider)
+and carrier backbone networks.
+
+* Menu:
+
+* Configuring isisd::
+* ISIS router::
+* ISIS Timer::
+* ISIS region::
+* ISIS interface::
+* Showing ISIS information::
+* ISIS Traffic Engineering::
+* Debugging ISIS::
+* ISIS Configuration Examples::
+
+\1f
+File: quagga.info, Node: Configuring isisd, Next: ISIS router, Up: ISIS
+
+9.1 Configuring isisd
+=====================
+
+There are no 'isisd' specific options. Common options can be specified
+(*note Common Invocation Options::) to 'isisd'. 'isisd' needs to
+acquire interface information from 'zebra' in order to function.
+Therefore 'zebra' must be running before invoking 'isisd'. Also, if
+'zebra' is restarted then 'isisd' must be too.
+
+ Like other daemons, 'isisd' configuration is done in ISIS specific
+configuration file 'isisd.conf'.
+
+\1f
+File: quagga.info, Node: ISIS router, Next: ISIS Timer, Prev: Configuring isisd, Up: ISIS
+
+9.2 ISIS router
+===============
+
+To start ISIS process you have to specify the ISIS router. As of this
+writing, 'isisd' does not support multiple ISIS processes.
+
+ -- Command: router isis WORD
+ -- Command: no router isis WORD
+ Enable or disable the ISIS process by specifying the ISIS domain
+ with 'WORD'. 'isisd' does not yet support multiple ISIS processes
+ but you must specify the name of ISIS process. The ISIS process
+ name 'WORD' is then used for interface (see command *note ip router
+ isis WORD::).
+
+ -- ISIS Command: net XX.XXXX. ... .XXX.XX
+ -- ISIS Command: no net XX.XXXX. ... .XXX.XX
+ Set/Unset network entity title (NET) provided in ISO format.
+
+ -- ISIS Command: hostname dynamic
+ -- ISIS Command: no hostname dynamic
+ Enable support for dynamic hostname.
+
+ -- ISIS Command: area-password [clear | md5] <password>
+ -- ISIS Command: domain-password [clear | md5] <password>
+ -- ISIS Command: no area-password
+ -- ISIS Command: no domain-password
+ Configure the authentication password for an area, respectively a
+ domain, as clear text or md5 one.
+
+ -- ISIS Command: log-adjacency-changes
+ -- ISIS Command: no log-adjacency-changes
+ Log changes in adjacency state.
+
+ -- ISIS Command: metric-style [narrow | transition | wide]
+ -- ISIS Command: no metric-style
+ Set old-style (ISO 10589) or new-style packet formats: - narrow Use
+ old style of TLVs with narrow metric - transition Send and accept
+ both styles of TLVs during transition - wide Use new style of TLVs
+ to carry wider metric
+
+ -- ISIS Command: set-overload-bit
+ -- ISIS Command: no set-overload-bit
+ Set overload bit to avoid any transit traffic.
+
+\1f
+File: quagga.info, Node: ISIS Timer, Next: ISIS region, Prev: ISIS router, Up: ISIS
+
+9.3 ISIS Timer
+==============
+
+ -- ISIS Command: lsp-gen-interval <1-120>
+ -- ISIS Command: lsp-gen-interval [level-1 | level-2] <1-120>
+ -- ISIS Command: no lsp-gen-interval
+ -- ISIS Command: no lsp-gen-interval [level-1 | level-2]
+ Set minimum interval in seconds between regenerating same LSP,
+ globally, for an area (level-1) or a domain (level-2).
+
+ -- ISIS Command: lsp-refresh-interval <1-65235>
+ -- ISIS Command: lsp-refresh-interval [level-1 | level-2] <1-65235>
+ -- ISIS Command: no lsp-refresh-interval
+ -- ISIS Command: no lsp-refresh-interval [level-1 | level-2]
+ Set LSP refresh interval in seconds, globally, for an area
+ (level-1) or a domain (level-2).
+
+ -- ISIS Command: lsp-refresh-interval <1-65235>
+ -- ISIS Command: lsp-refresh-interval [level-1 | level-2] <1-65235>
+ -- ISIS Command: no lsp-refresh-interval
+ -- ISIS Command: no lsp-refresh-interval [level-1 | level-2]
+ Set LSP refresh interval in seconds, globally, for an area
+ (level-1) or a domain (level-2).
+
+ -- ISIS Command: max-lsp-lifetime <360-65535>
+ -- ISIS Command: max-lsp-lifetime [level-1 | level-2] <360-65535>
+ -- ISIS Command: no max-lsp-lifetime
+ -- ISIS Command: no max-lsp-lifetime [level-1 | level-2]
+ Set LSP maximum LSP lifetime in seconds, globally, for an area
+ (level-1) or a domain (level-2).
+
+ -- ISIS Command: spf-interval <1-120>
+ -- ISIS Command: spf-interval [level-1 | level-2] <1-120>
+ -- ISIS Command: no spf-interval
+ -- ISIS Command: no spf-interval [level-1 | level-2]
+ Set minimum interval between consecutive SPF calculations in
+ seconds.
+
+\1f
+File: quagga.info, Node: ISIS region, Next: ISIS interface, Prev: ISIS Timer, Up: ISIS
+
+9.4 ISIS region
+===============
+
+ -- ISIS Command: is-type [level-1 | level-1-2 | level-2-only]
+ -- ISIS Command: no is-type
+ Define the ISIS router behavior: - level-1 Act as a station router
+ only - level-1-2 Act as both a station router and an area router -
+ level-2-only Act as an area router only
+
+\1f
+File: quagga.info, Node: ISIS interface, Next: Showing ISIS information, Prev: ISIS region, Up: ISIS
+
+9.5 ISIS interface
+==================
+
+ -- Interface Command: ip router isis WORD
+ -- Interface Command: no ip router isis WORD
+ Activate ISIS adjacency on this interface. Note that the name of
+ ISIS instance must be the same as the one used to configure the
+ ISIS process (see command *note router isis WORD::).
+
+ -- Interface Command: isis circuit-type [level-1 | level-1-2 | level-2]
+ -- Interface Command: no isis circuit-type
+ Configure circuit type for interface: - level-1 Level-1 only
+ adjacencies are formed - level-1-2 Level-1-2 adjacencies are formed
+ - level-2-only Level-2 only adjacencies are formed
+
+ -- Interface Command: isis csnp-interval <1-600>
+ -- Interface Command: isis csnp-interval <1-600> [level-1 | level-2]
+ -- Interface Command: no isis csnp-interval
+ -- Interface Command: no isis csnp-interval [level-1 | level-2]
+ Set CSNP interval in seconds globally, for an area (level-1) or a
+ domain (level-2).
+
+ -- Interface Command: isis hello padding
+ Add padding to IS-IS hello packets.
+
+ -- Interface Command: isis hello-interval <1-600>
+ -- Interface Command: isis hello-interval <1-600> [level-1 | level-2]
+ -- Interface Command: no isis hello-interval
+ -- Interface Command: no isis hello-interval [level-1 | level-2]
+ Set Hello interval in seconds globally, for an area (level-1) or a
+ domain (level-2).
+
+ -- Interface Command: isis hello-multiplier <2-100>
+ -- Interface Command: isis hello-multiplier <2-100> [level-1 | level-2]
+ -- Interface Command: no isis hello-multiplier
+ -- Interface Command: no isis hello-multiplier [level-1 | level-2]
+ Set multiplier for Hello holding time globally, for an area
+ (level-1) or a domain (level-2).
+
+ -- Interface Command: isis metric [<0-255> | <0-16777215>]
+ -- Interface Command: isis metric [<0-255> | <0-16777215>] [level-1 |
+ level-2]
+ -- Interface Command: no isis metric
+ -- Interface Command: no isis metric [level-1 | level-2]
+ Set default metric value globally, for an area (level-1) or a
+ domain (level-2). Max value depend if metric support narrow or
+ wide value (see command *note metric-style::).
+
+ -- Interface Command: isis network point-to-point
+ -- Interface Command: no isis network point-to-point
+ Set network type to 'Point-to-Point' (broadcast by default).
+
+ -- Interface Command: isis passive
+ -- Interface Command: no isis passive
+ Configure the passive mode for this interface.
+
+ -- Interface Command: isis password [clear | md5] <password>
+ -- Interface Command: no isis password
+ Configure the authentication password (clear or encoded text) for
+ the interface.
+
+ -- Interface Command: isis priority <0-127>
+ -- Interface Command: isis priority <0-127> [level-1 | level-2]
+ -- Interface Command: no isis priority
+ -- Interface Command: no isis priority [level-1 | level-2]
+ Set priority for Designated Router election, globally, for the area
+ (level-1) or the domain (level-2).
+
+ -- Interface Command: isis psnp-interval <1-120>
+ -- Interface Command: isis psnp-interval <1-120> [level-1 | level-2]
+ -- Interface Command: no isis psnp-interval
+ -- Interface Command: no isis psnp-interval [level-1 | level-2]
+ Set PSNP interval in seconds globally, for an area (level-1) or a
+ domain (level-2).
+
+\1f
+File: quagga.info, Node: Showing ISIS information, Next: ISIS Traffic Engineering, Prev: ISIS interface, Up: ISIS
+
+9.6 Showing ISIS information
+============================
+
+ -- Command: show isis summary
+ Show summary information about ISIS.
+
+ -- Command: show isis hostname
+ Show information about ISIS node.
+
+ -- Command: show isis interface
+ -- Command: show isis interface detail
+ -- Command: show isis interface <interface name>
+ Show state and configuration of ISIS specified interface, or all
+ interfaces if no interface is given with or without details.
+
+ -- Command: show isis neighbor
+ -- Command: show isis neighbor <System Id>
+ -- Command: show isis neighbor detail
+ Show state and information of ISIS specified neighbor, or all
+ neighbors if no system id is given with or without details.
+
+ -- Command: show isis database
+ -- Command: show isis database [detail]
+ -- Command: show isis database <LSP id> [detail]
+ -- Command: show isis database detail <LSP id>
+ Show the ISIS database globally, for a specific LSP id without or
+ with details.
+
+ -- Command: show isis topology
+ -- Command: show isis topology [level-1|level-2]
+ Show topology IS-IS paths to Intermediate Systems, globally, in
+ area (level-1) or domain (level-2).
+
+ -- Command: show ip route isis
+ Show the ISIS routing table, as determined by the most recent SPF
+ calculation.
+
+\1f
+File: quagga.info, Node: ISIS Traffic Engineering, Next: Debugging ISIS, Prev: Showing ISIS information, Up: ISIS
+
+9.7 Traffic Engineering
+=======================
+
+ -- ISIS Command: mpls-te on
+ -- ISIS Command: no mpls-te
+ Enable Traffic Engineering LSP flooding.
+
+ -- ISIS Command: mpls-te router-address <A.B.C.D>
+ -- ISIS Command: no mpls-te router-address
+ Configure stable IP address for MPLS-TE.
+
+ -- Command: show isis mpls-te interface
+ -- Command: show isis mpls-te interface INTERFACE
+ Show MPLS Traffic Engineering parameters for all or specified
+ interface.
+
+ -- Command: show isis mpls-te router
+ Show Traffic Engineering router parameters.
+
+\1f
+File: quagga.info, Node: Debugging ISIS, Next: ISIS Configuration Examples, Prev: ISIS Traffic Engineering, Up: ISIS
+
+9.8 Debugging ISIS
+==================
+
+ -- Command: debug isis adj-packets
+ -- Command: no debug isis adj-packets
+ IS-IS Adjacency related packets.
+
+ -- Command: debug isis checksum-errors
+ -- Command: no debug isis checksum-errors
+ IS-IS LSP checksum errors.
+
+ -- Command: debug isis events
+ -- Command: no debug isis events
+ IS-IS Events.
+
+ -- Command: debug isis local-updates
+ -- Command: no debug isis local-updates
+ IS-IS local update packets.
+
+ -- Command: debug isis packet-dump
+ -- Command: no debug isis packet-dump
+ IS-IS packet dump.
+
+ -- Command: debug isis protocol-errors
+ -- Command: no debug isis protocol-errors
+ IS-IS LSP protocol errors.
+
+ -- Command: debug isis route-events
+ -- Command: no debug isis route-events
+ IS-IS Route related events.
+
+ -- Command: debug isis snp-packets
+ -- Command: no debug isis snp-packets
+ IS-IS CSNP/PSNP packets.
+
+ -- Command: debug isis spf-events
+ -- Command: debug isis spf-statistics
+ -- Command: debug isis spf-triggers
+ -- Command: no debug isis spf-events
+ -- Command: no debug isis spf-statistics
+ -- Command: no debug isis spf-triggers
+ IS-IS Shortest Path First Events, Timing and Statistic Data and
+ triggering events.
+
+ -- Command: debug isis update-packets
+ -- Command: no debug isis update-packets
+ Update related packets.
+
+ -- Command: show debugging isis
+ Print which ISIS debug level is activate.
+
+\1f
+File: quagga.info, Node: ISIS Configuration Examples, Prev: Debugging ISIS, Up: ISIS
+
+9.9 ISIS Configuration Examples
+===============================
+
+A simple example, with MD5 authentication enabled:
+
+ !
+ interface eth0
+ ip router isis FOO
+ isis network point-to-point
+ isis circuit-type level-2-only
+ !
+ router isis FOO
+ net 47.0023.0000.0000.0000.0000.0000.0000.1900.0004.00
+ metric-style wide
+ is-type level-2-only
+
+ A Traffic Engineering configuration, with Inter-ASv2 support.
+
+ - First, the 'zebra.conf' part:
+
+ hostname HOSTNAME
+ password PASSWORD
+ log file /var/log/zebra.log
+ !
+ interface eth0
+ ip address 10.2.2.2/24
+ mpls-te on
+ mpls-te link metric 10
+ mpls-te link max-bw 1.25e+06
+ mpls-te link max-rsv-bw 1.25e+06
+ mpls-te link unrsv-bw 0 1.25e+06
+ mpls-te link unrsv-bw 1 1.25e+06
+ mpls-te link unrsv-bw 2 1.25e+06
+ mpls-te link unrsv-bw 3 1.25e+06
+ mpls-te link unrsv-bw 4 1.25e+06
+ mpls-te link unrsv-bw 5 1.25e+06
+ mpls-te link unrsv-bw 6 1.25e+06
+ mpls-te link unrsv-bw 7 1.25e+06
+ mpls-te link rsc-clsclr 0xab
+ !
+ interface eth1
+ ip address 10.1.1.1/24
+ mpls-te on
+ mpls-te link metric 10
+ mpls-te link max-bw 1.25e+06
+ mpls-te link max-rsv-bw 1.25e+06
+ mpls-te link unrsv-bw 0 1.25e+06
+ mpls-te link unrsv-bw 1 1.25e+06
+ mpls-te link unrsv-bw 2 1.25e+06
+ mpls-te link unrsv-bw 3 1.25e+06
+ mpls-te link unrsv-bw 4 1.25e+06
+ mpls-te link unrsv-bw 5 1.25e+06
+ mpls-te link unrsv-bw 6 1.25e+06
+ mpls-te link unrsv-bw 7 1.25e+06
+ mpls-te link rsc-clsclr 0xab
+ mpls-te neighbor 10.1.1.2 as 65000
+
+ - Then the 'isisd.conf' itself:
+
+ hostname HOSTNAME
+ password PASSWORD
+ log file /var/log/isisd.log
+ !
+ !
+ interface eth0
+ ip router isis FOO
+ !
+ interface eth1
+ ip router isis FOO
+ !
+ !
+ router isis FOO
+ isis net 47.0023.0000.0000.0000.0000.0000.0000.1900.0004.00
+ mpls-te on
+ mpls-te router-address 10.1.1.1
+ !
+ line vty
+
+\1f
+File: quagga.info, Node: NHRP, Next: BGP, Prev: ISIS, Up: Top
+
+10 NHRP
+*******
+
+'nhrpd' is a daemon to support Next Hop Routing Protocol (NHRP). NHRP is
+described in RFC2332.
+
+ NHRP is used to improve the efficiency of routing computer network
+traffic over Non-Broadcast, Multiple Access (NBMA) Networks. NHRP
+provides an ARP-like solution that allows a system to dynamically learn
+the NBMA address of the other systems that are part of that network,
+allowing these systems to directly communicate without requiring traffic
+to use an intermediate hop.
+
+ Cisco Dynamic Multipoint VPN (DMVPN) is based on NHRP, and Quagga
+nrhpd implements this scenario.
+
+* Menu:
+
+* Routing Design::
+* Configuring NHRP::
+* Hub Functionality::
+* Integration with IKE::
+* NHRP Events::
+* Configuration Example::
+
+\1f
+File: quagga.info, Node: Routing Design, Next: Configuring NHRP, Up: NHRP
+
+10.1 Routing Design
+===================
+
+nhrpd never handles routing of prefixes itself. You need to run some
+real routing protocol (e.g. BGP) to advertise routes over the tunnels.
+What nhrpd does it establishes 'shortcut routes' that optimizes the
+routing protocol to avoid going through extra nodes in NBMA GRE mesh.
+
+ nhrpd does route NHRP domain addresses individually using per-host
+prefixes. This is similar to Cisco FlexVPN; but in contrast to opennhrp
+which uses a generic subnet route.
+
+ To create NBMA GRE tunnel you might use the following (linux terminal
+commands):
+ ip tunnel add gre1 mode gre key 42 ttl 64
+ ip addr add 10.255.255.2/32 dev gre1
+ ip link set gre1 up
+
+ Note that the IP-address is assigned as host prefix to gre1. nhrpd
+will automatically create additional host routes pointing to gre1 when a
+connection with these hosts is established.
+
+ The gre1 subnet prefix should be announced by routing protocol from
+the hub nodes (e.g. BGP 'network' announce). This allows the routing
+protocol to decide which is the closest hub and determine the relay hub
+on prefix basis when direct tunnel is not established.
+
+ nhrpd will redistribute directly connected neighbors to zebra.
+Within hub nodes, these routes should be internally redistributed using
+some routing protocol (e.g. iBGP) to allow hubs to be able to relay all
+traffic.
+
+ This can be achieved in hubs with the following bgp configuration
+(network command defines the GRE subnet):
+ router bgp 65555
+ network 172.16.0.0/16
+ redistribute nhrp
+
+\1f
+File: quagga.info, Node: Configuring NHRP, Next: Hub Functionality, Prev: Routing Design, Up: NHRP
+
+10.2 Configuring NHRP
+=====================
+
+FIXME
+
+\1f
+File: quagga.info, Node: Hub Functionality, Next: Integration with IKE, Prev: Configuring NHRP, Up: NHRP
+
+10.3 Hub Functionality
+======================
+
+In addition to routing nhrp redistributed host prefixes, the hub nodes
+are also responsible to send NHRP Traffic Indication messages that
+trigger creation of the shortcut tunnels.
+
+ nhrpd sends Traffic Indication messages based on network traffic
+captured using NFLOG. Typically you want to send Traffic Indications for
+network traffic that is routed from gre1 back to gre1 in rate limited
+manner. This can be achieved with the following iptables rule.
+
+ iptables -A FORWARD -i gre1 -o gre1 \
+ -m hashlimit --hashlimit-upto 4/minute --hashlimit-burst 1 \
+ --hashlimit-mode srcip,dstip --hashlimit-srcmask 24 \
+ --hashlimit-dstmask 24 --hashlimit-name loglimit-0 \
+ -j NFLOG --nflog-group 1 --nflog-range 128
+
+ You can fine tune the src/dstmask according to the prefix lengths you
+announce internal, add additional IP range matches, or rate limitation
+if needed. However, the above should be good in most cases.
+
+ This kernel NFLOG target's nflog-group is configured in global nhrp
+config with:
+ nhrp nflog-group 1
+
+ To start sending these traffic notices out from hubs, use the nhrp
+per-interface directive:
+ interface gre1
+ ip nhrp redirect
+
+\1f
+File: quagga.info, Node: Integration with IKE, Next: NHRP Events, Prev: Hub Functionality, Up: NHRP
+
+10.4 Integration with IKE
+=========================
+
+nhrpd needs tight integration with IKE daemon for various reasons.
+Currently only strongSwan is supported as IKE daemon.
+
+ nhrpd connects to strongSwan using VICI protocol based on UNIX socket
+(hardcoded now as /var/run/charon.vici).
+
+ strongSwan currently needs few patches applied. Please check out the
+release
+(http://git.alpinelinux.org/cgit/user/tteras/strongswan/log/?h=tteras-release)
+and working tree
+(http://git.alpinelinux.org/cgit/user/tteras/strongswan/log/?h=tteras)
+git repositories for the patches.
+
+\1f
+File: quagga.info, Node: NHRP Events, Next: Configuration Example, Prev: Integration with IKE, Up: NHRP
+
+10.5 NHRP Events
+================
+
+FIXME
+
+\1f
+File: quagga.info, Node: Configuration Example, Prev: NHRP Events, Up: NHRP
+
+10.6 Configuration Example
+==========================
+
+FIXME
+
+\1f
+File: quagga.info, Node: BGP, Next: Configuring Quagga as a Route Server, Prev: NHRP, Up: Top
+
+11 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 extensions have been added to 'RFC1771'. 'RFC2858,
+Multiprotocol Extensions for BGP-4' provides multiprotocol support to
+BGP-4.
+
+* Menu:
+
+* Starting BGP::
+* BGP router::
+* BGP MED::
+* 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::
+* BGP Configuration Examples::
+
+\1f
+File: quagga.info, Node: Starting BGP, Next: BGP router, Up: BGP
+
+11.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.
+
+'-l'
+'--listenon'
+ Specify a specific IP address for bgpd to listen on, rather than
+ its default of INADDR_ANY / IN6ADDR_ANY. This can be useful to
+ constrain bgpd to an internal address, or to run multiple bgpd
+ processes on one host.
+
+\1f
+File: quagga.info, Node: BGP router, Next: BGP MED, Prev: Starting BGP, Up: BGP
+
+11.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::
+* BGP route flap dampening::
+
+\1f
+File: quagga.info, Node: BGP distance, Next: BGP decision process, Up: BGP router
+
+11.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.
+
+ To have this command applied to existing routes requires a hard
+ clear.
+
+ -- BGP: distance <1-255> A.B.C.D/M
+ -- BGP: distance <1-255> A.B.C.D/M WORD
+ This command set distance value to
+
+\1f
+File: quagga.info, Node: BGP decision process, Next: BGP route flap dampening, Prev: BGP distance, Up: BGP router
+
+11.2.2 BGP decision process
+---------------------------
+
+The decision process Quagga BGP uses to select routes is as follows:
+
+1. Weight check
+ prefer higher local weight routes to lower routes.
+
+2. Local preference check
+ prefer higher local preference routes to lower.
+
+3. Local route check
+ Prefer local routes (statics, aggregates, redistributed) to
+ received routes.
+
+4. AS path length check
+ Prefer shortest hop-count AS_PATHs.
+
+5. Origin check
+ Prefer the lowest origin type route. That is, prefer IGP origin
+ routes to EGP, to Incomplete routes.
+
+6. MED check
+ Where routes with a MED were received from the same AS, prefer the
+ route with the lowest MED. *Note BGP MED::.
+
+7. External check
+ Prefer the route received from an external, eBGP peer over routes
+ received from other types of peers.
+
+8. IGP cost check
+ Prefer the route with the lower IGP cost.
+
+9. Multi-path check
+ If multi-pathing is enabled, then check whether the routes not yet
+ distinguished in preference may be considered equal. If *note bgp
+ bestpath as-path multipath-relax:: is set, all such routes are
+ considered equal, otherwise routes received via iBGP with identical
+ AS_PATHs or routes received from eBGP neighbours in the same AS are
+ considered equal.
+
+10 Already-selected external check
+
+ Where both routes were received from eBGP peers, then prefer the
+ route which is already selected. Note that this check is not
+ applied if *note bgp bestpath compare-routerid:: is configured.
+ This check can prevent some cases of oscillation.
+
+11. Router-ID check
+ Prefer the route with the lowest router-ID. If the route has an
+ ORIGINATOR_ID attribute, through iBGP reflection, then that router
+ ID is used, otherwise the router-ID of the peer the route was
+ received from is used.
+
+12. Cluster-List length check
+ The route with the shortest cluster-list length is used. The
+ cluster-list reflects the iBGP reflection path the route has taken.
+
+13. Peer address
+ Prefer the route received from the peer with the higher transport
+ layer address, as a last-resort tie-breaker.
+
+ -- BGP: bgp bestpath as-path confed
+ This command specifies that the length of confederation path sets
+ and sequences should should be taken into account during the BGP
+ best path decision process.
+
+ -- BGP: bgp bestpath as-path multipath-relax
+ This command specifies that BGP decision process should consider
+ paths of equal AS_PATH length candidates for multipath computation.
+ Without the knob, the entire AS_PATH must match for multipath
+ computation.
+
+ -- BGP: bgp bestpath compare-routerid
+
+ Ensure that when comparing routes where both are equal on most
+ metrics, including local-pref, AS_PATH length, IGP cost, MED, that
+ the tie is broken based on router-ID.
+
+ If this option is enabled, then the already-selected check, where
+ already selected eBGP routes are preferred, is skipped.
+
+ If a route has an ORIGINATOR_ID attribute because it has been
+ reflected, that ORIGINATOR_ID will be used. Otherwise, the
+ router-ID of the peer the route was received from will be used.
+
+ The advantage of this is that the route-selection (at this point)
+ will be more deterministic. The disadvantage is that a few or even
+ one lowest-ID router may attract all trafic to otherwise-equal
+ paths because of this check. It may increase the possibility of
+ MED or IGP oscillation, unless other measures were taken to avoid
+ these. The exact behaviour will be sensitive to the iBGP and
+ reflection topology.
+
+\1f
+File: quagga.info, Node: BGP route flap dampening, Prev: BGP decision process, Up: BGP router
+
+11.2.3 BGP route flap dampening
+-------------------------------
+
+ -- BGP: bgp dampening <1-45> <1-20000> <1-20000> <1-255>
+ This command enables BGP route-flap dampening and specifies
+ dampening parameters.
+
+ half-life
+ Half-life time for the penalty
+ reuse-threshold
+ Value to start reusing a route
+ suppress-threshold
+ Value to start suppressing a route
+ max-suppress
+ Maximum duration to suppress a stable route
+
+ The route-flap damping algorithm is compatible with 'RFC2439'. The
+ use of this command is not recommended nowadays, see RIPE-378.
+
+\1f
+File: quagga.info, Node: BGP MED, Next: BGP network, Prev: BGP router, Up: BGP
+
+11.3 BGP MED
+============
+
+The BGP MED (Multi_Exit_Discriminator) attribute has properties which
+can cause subtle convergence problems in BGP. These properties and
+problems have proven to be hard to understand, at least historically,
+and may still not be widely understood. The following attempts to
+collect together and present what is known about MED, to help operators
+and Quagga users in designing and configuring their networks.
+
+ The BGP MED (Multi_Exit_Discriminator) attribute is intended to allow
+one AS to indicate its preferences for its ingress points to another AS.
+The MED attribute will not be propagated on to another AS by the
+receiving AS - it is 'non-transitive' in the BGP sense.
+
+ E.g., if AS X and AS Y have 2 different BGP peering points, then AS X
+might set a MED of 100 on routes advertised at one and a MED of 200 at
+the other. When AS Y selects between otherwise equal routes to or via
+AS X, AS Y should prefer to take the path via the lower MED peering of
+100 with AS X. Setting the MED allows an AS to influence the routing
+taken to it within another, neighbouring AS.
+
+ In this use of MED it is not really meaningful to compare the MED
+value on routes where the next AS on the paths differs. E.g., if AS Y
+also had a route for some destination via AS Z in addition to the routes
+from AS X, and AS Z had also set a MED, it wouldn't make sense for AS Y
+to compare AS Z's MED values to those of AS X. The MED values have been
+set by different administrators, with different frames of reference.
+
+ The default behaviour of BGP therefore is to not compare MED values
+across routes received from different neighbouring ASes. In Quagga this
+is done by comparing the neighbouring, left-most AS in the received
+AS_PATHs of the routes and only comparing MED if those are the same.
+
+ Unfortunately, this behaviour of MED, of sometimes being compared
+across routes and sometimes not, depending on the properties of those
+other routes, means MED can cause the order of preference over all the
+routes to be undefined. That is, given routes A, B, and C, if A is
+preferred to B, and B is preferred to C, then a well-defined order
+should mean the preference is transitive (in the sense of orders (1))
+and that A would be preferred to C.
+
+ However, when MED is involved this need not be the case. With MED it
+is possible that C is actually preferred over A. So A is preferred to B,
+B is preferred to C, but C is preferred to A. This can be true even
+where BGP defines a deterministic "most preferred" route out of the full
+set of A,B,C. With MED, for any given set of routes there may be a
+deterministically preferred route, but there need not be any way to
+arrange them into any order of preference. With unmodified MED, the
+order of preference of routes literally becomes undefined.
+
+ That MED can induce non-transitive preferences over routes can cause
+issues. Firstly, it may be perceived to cause routing table churn
+locally at speakers; secondly, and more seriously, it may cause routing
+instability in iBGP topologies, where sets of speakers continually
+oscillate between different paths.
+
+ The first issue arises from how speakers often implement routing
+decisions. Though BGP defines a selection process that will
+deterministically select the same route as best at any given speaker,
+even with MED, that process requires evaluating all routes together.
+For performance and ease of implementation reasons, many implementations
+evaluate route preferences in a pair-wise fashion instead. Given there
+is no well-defined order when MED is involved, the best route that will
+be chosen becomes subject to implementation details, such as the order
+the routes are stored in. That may be (locally) non-deterministic, e.g.
+it may be the order the routes were received in.
+
+ This indeterminism may be considered undesirable, though it need not
+cause problems. It may mean additional routing churn is perceived, as
+sometimes more updates may be produced than at other times in reaction
+to some event .
+
+ This first issue can be fixed with a more deterministic route
+selection that ensures routes are ordered by the neighbouring AS during
+selection. *Note bgp deterministic-med::. This may reduce the number
+of updates as routes are received, and may in some cases reduce routing
+churn. Though, it could equally deterministically produce the largest
+possible set of updates in response to the most common sequence of
+received updates.
+
+ A deterministic order of evaluation tends to imply an additional
+overhead of sorting over any set of n routes to a destination. The
+implementation of deterministic MED in Quagga scales significantly worse
+than most sorting algorithms at present, with the number of paths to a
+given destination. That number is often low enough to not cause any
+issues, but where there are many paths, the deterministic comparison may
+quickly become increasingly expensive in terms of CPU.
+
+ Deterministic local evaluation can _not_ fix the second, more major,
+issue of MED however. Which is that the non-transitive preference of
+routes MED can cause may lead to routing instability or oscillation
+across multiple speakers in iBGP topologies. This can occur with
+full-mesh iBGP, but is particularly problematic in non-full-mesh iBGP
+topologies that further reduce the routing information known to each
+speaker. This has primarily been documented with iBGP route-reflection
+topologies. However, any route-hiding technologies potentially could
+also exacerbate oscillation with MED.
+
+ This second issue occurs where speakers each have only a subset of
+routes, and there are cycles in the preferences between different
+combinations of routes - as the undefined order of preference of MED
+allows - and the routes are distributed in a way that causes the BGP
+speakers to 'chase' those cycles. This can occur even if all speakers
+use a deterministic order of evaluation in route selection.
+
+ E.g., speaker 4 in AS A might receive a route from speaker 2 in AS X,
+and from speaker 3 in AS Y; while speaker 5 in AS A might receive that
+route from speaker 1 in AS Y. AS Y might set a MED of 200 at speaker 1,
+and 100 at speaker 3. I.e, using ASN:ID:MED to label the speakers:
+
+
+ /---------------\
+ X:2------|--A:4-------A:5--|-Y:1:200
+ Y:3:100--|-/ |
+ \---------------/
+
+
+ Assuming all other metrics are equal (AS_PATH, ORIGIN, 0 IGP costs),
+then based on the RFC4271 decision process speaker 4 will choose X:2
+over Y:3:100, based on the lower ID of 2. Speaker 4 advertises X:2 to
+speaker 5. Speaker 5 will continue to prefer Y:1:200 based on the ID,
+and advertise this to speaker 4. Speaker 4 will now have the full set
+of routes, and the Y:1:200 it receives from 5 will beat X:2, but when
+speaker 4 compares Y:1:200 to Y:3:100 the MED check now becomes active
+as the ASes match, and now Y:3:100 is preferred. Speaker 4 therefore
+now advertises Y:3:100 to 5, which will also agrees that Y:3:100 is
+preferred to Y:1:200, and so withdraws the latter route from 4. Speaker
+4 now has only X:2 and Y:3:100, and X:2 beats Y:3:100, and so speaker 4
+implicitly updates its route to speaker 5 to X:2. Speaker 5 sees that
+Y:1:200 beats X:2 based on the ID, and advertises Y:1:200 to speaker 4,
+and the cycle continues.
+
+ The root cause is the lack of a clear order of preference caused by
+how MED sometimes is and sometimes is not compared, leading to this
+cycle in the preferences between the routes:
+
+
+ /---> X:2 ---beats---> Y:3:100 --\
+ | |
+ | |
+ \---beats--- Y:1:200 <---beats---/
+
+
+ This particular type of oscillation in full-mesh iBGP topologies can
+be avoided by speakers preferring already selected, external routes
+rather than choosing to update to new a route based on a post-MED metric
+(e.g. router-ID), at the cost of a non-deterministic selection process.
+Quagga implements this, as do many other implementations, so long as it
+is not overridden by setting *note bgp bestpath compare-routerid::, and
+see also *note BGP decision process::, .
+
+ However, more complex and insidious cycles of oscillation are
+possible with iBGP route-reflection, which are not so easily avoided.
+These have been documented in various places. See, e.g., 'McPherson, D.
+and Gill, V. and Walton, D., "Border Gateway Protocol (BGP) Persistent
+Route Oscillation Condition", IETF RFC3345', and 'Flavel, A. and M.
+Roughan, "Stable and flexible iBGP", ACM SIGCOMM 2009', and 'Griffin, T.
+and G. Wilfong, "On the correctness of IBGP configuration", ACM SIGCOMM
+2002' for concrete examples and further references.
+
+ There is as of this writing _no_ known way to use MED for its
+original purpose; _and_ reduce routing information in iBGP topologies;
+_and_ be sure to avoid the instability problems of MED due the
+non-transitive routing preferences it can induce; in general on
+arbitrary networks.
+
+ There may be iBGP topology specific ways to reduce the instability
+risks, even while using MED, e.g. by constraining the reflection
+topology and by tuning IGP costs between route-reflector clusters, see
+RFC3345 for details. In the near future, the Add-Path extension to BGP
+may also solve MED oscillation while still allowing MED to be used as
+intended, by distributing "best-paths per neighbour AS". This would be
+at the cost of distributing at least as many routes to all speakers as a
+full-mesh iBGP would, if not more, while also imposing similar CPU
+overheads as the "Deterministic MED" feature at each Add-Path reflector.
+
+ More generally, the instability problems that MED can introduce on
+more complex, non-full-mesh, iBGP topologies may be avoided either by:
+
+ * Setting *note bgp always-compare-med::, however this allows MED to
+ be compared across values set by different neighbour ASes, which
+ may not produce coherent desirable results, of itself.
+
+ * Effectively ignoring MED by setting MED to the same value (e.g. 0)
+ using *note routemap set metric:: on all received routes, in
+ combination with setting *note bgp always-compare-med:: on all
+ speakers. This is the simplest and most performant way to avoid
+ MED oscillation issues, where an AS is happy not to allow
+ neighbours to inject this problematic metric.
+
+ As MED is evaluated after the AS_PATH length check, another possible
+use for MED is for intra-AS steering of routes with equal AS_PATH
+length, as an extension of the last case above. As MED is evaluated
+before IGP metric, this can allow cold-potato routing to be implemented
+to send traffic to preferred hand-offs with neighbours, rather than the
+closest hand-off according to the IGP metric.
+
+ Note that even if action is taken to address the MED non-transitivity
+issues, other oscillations may still be possible. E.g., on IGP cost if
+iBGP and IGP topologies are at cross-purposes with each other - see the
+Flavel and Roughan paper above for an example. Hence the guideline that
+the iBGP topology should follow the IGP topology.
+
+ -- BGP: bgp deterministic-med
+
+ Carry out route-selection in way that produces deterministic
+ answers locally, even in the face of MED and the lack of a
+ well-defined order of preference it can induce on routes. Without
+ this option the preferred route with MED may be determined largely
+ by the order that routes were received in.
+
+ Setting this option will have a performance cost that may be
+ noticeable when there are many routes for each destination.
+ Currently in Quagga it is implemented in a way that scales poorly
+ as the number of routes per destination increases.
+
+ The default is that this option is not set.
+
+ Note that there are other sources of indeterminism in the route
+selection process, specifically, the preference for older and already
+selected routes from eBGP peers, *Note BGP decision process::.
+
+ -- BGP: bgp always-compare-med
+
+ Always compare the MED on routes, even when they were received from
+ different neighbouring ASes. Setting this option makes the order
+ of preference of routes more defined, and should eliminate MED
+ induced oscillations.
+
+ If using this option, it may also be desirable to use *note
+ routemap set metric:: to set MED to 0 on routes received from
+ external neighbours.
+
+ This option can be used, together with *note routemap set metric::
+ to use MED as an intra-AS metric to steer equal-length AS_PATH
+ routes to, e.g., desired exit points.
+
+ ---------- Footnotes ----------
+
+ (1) For some set of objects to have an order, there _must_ be some
+binary ordering relation that is defined for _every_ combination of
+those objects, and that relation _must_ be transitive. I.e., if the
+relation operator is ≺, and if a ≺ b and b ≺ c then that relation
+must carry over and it _must_ be that a ≺ c for the objects to have an
+order. The ordering relation may allow for equality, i.e. a ≺ b and
+b ≺ a may both be true amd imply that a and b are equal in the order
+and not distinguished by it, in which case the set has a partial order.
+Otherwise, if there is an order, all the objects have a distinct place
+in the order and the set has a total order.
+
+\1f
+File: quagga.info, Node: BGP network, Next: BGP Peer, Prev: BGP MED, Up: BGP
+
+11.4 BGP network
+================
+
+* Menu:
+
+* BGP route::
+* Route Aggregation::
+* Redistribute to BGP::
+
+\1f
+File: quagga.info, Node: BGP route, Next: Route Aggregation, Up: BGP network
+
+11.4.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; 'bgpd'
+ doesn't care about IGP routes when announcing its routes.
+
+ -- BGP: no network A.B.C.D/M
+
+\1f
+File: quagga.info, Node: Route Aggregation, Next: Redistribute to BGP, Prev: BGP route, Up: BGP network
+
+11.4.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
+ include AS set.
+
+ -- BGP: aggregate-address A.B.C.D/M summary-only
+ This command specifies an aggregate address. Aggreated routes will
+ not be announce.
+
+ -- BGP: no aggregate-address A.B.C.D/M
+
+\1f
+File: quagga.info, Node: Redistribute to BGP, Prev: Route Aggregation, Up: BGP network
+
+11.4.3 Redistribute to BGP
+--------------------------
+
+ -- BGP: redistribute kernel
+ Redistribute kernel route to BGP process.
+
+ -- BGP: redistribute static
+ Redistribute static route to BGP process.
+
+ -- BGP: redistribute connected
+ Redistribute connected route to BGP process.
+
+ -- BGP: redistribute rip
+ Redistribute RIP route to BGP process.
+
+ -- BGP: redistribute ospf
+ Redistribute OSPF route to BGP process.
+
+\1f
+File: quagga.info, Node: BGP Peer, Next: BGP Peer Group, Prev: BGP network, Up: BGP
+
+11.5 BGP Peer
+=============
+
+* Menu:
+
+* Defining Peer::
+* BGP Peer commands::
+* Peer filtering::
+
+\1f
+File: quagga.info, Node: Defining Peer, Next: BGP Peer commands, Up: BGP Peer
+
+11.5.1 Defining Peer
+--------------------
+
+ -- BGP: neighbor PEER remote-as ASN
+ Creates a new neighbor whose remote-as is ASN. PEER can be an IPv4
+ address or an IPv6 address.
+ router bgp 1
+ neighbor 10.0.0.1 remote-as 2
+ In this case my router, in AS-1, is trying to peer with AS-2 at
+ 10.0.0.1.
+
+ This command must be the first command used when configuring a
+ neighbor. If the remote-as is not specified, 'bgpd' will complain
+ like this:
+ can't find neighbor 10.0.0.1
+
+\1f
+File: quagga.info, Node: BGP Peer commands, Next: Peer filtering, Prev: Defining Peer, Up: BGP Peer
+
+11.5.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. To specify IPv4 session addresses, see the 'neighbor
+ PEER update-source' command below.
+
+ This command is deprecated and may be removed in a future release.
+ Its use should be avoided.
+
+ -- BGP: neighbor PEER next-hop-self [all]
+ -- BGP: no neighbor PEER next-hop-self [all]
+ This command specifies an announced route's nexthop as being
+ equivalent to the address of the bgp router if it is learned via
+ eBGP. If the optional keyword 'all' is specified the modifiation is
+ done also for routes learned via iBGP.
+
+ -- BGP: neighbor PEER update-source <IFNAME|ADDRESS>
+ -- BGP: no neighbor PEER update-source
+ Specify the IPv4 source address to use for the BGP session to this
+ neighbour, may be specified as either an IPv4 address directly or
+ as an interface name (in which case the 'zebra' daemon MUST be
+ running in order for 'bgpd' to be able to retrieve interface
+ state).
+ router bgp 64555
+ neighbor foo update-source 192.168.0.1
+ neighbor bar update-source lo0
+
+ -- 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
+
+ -- BGP: neighbor PEER local-as AS-NUMBER
+ -- BGP: neighbor PEER local-as AS-NUMBER no-prepend
+ -- BGP: neighbor PEER local-as AS-NUMBER no-prepend replace-as
+ -- BGP: no neighbor PEER local-as
+ Specify an alternate AS for this BGP process when interacting with
+ the specified peer. With no modifiers, the specified local-as is
+ prepended to the received AS_PATH when receiving routing updates
+ from the peer, and prepended to the outgoing AS_PATH (after the
+ process local AS) when transmitting local routes to the peer.
+
+ If the no-prepend attribute is specified, then the supplied
+ local-as is not prepended to the received AS_PATH.
+
+ If the replace-as attribute is specified, then only the supplied
+ local-as is prepended to the AS_PATH when transmitting local-route
+ updates to this peer.
+
+ Note that replace-as can only be specified if no-prepend is.
+
+ This command is only allowed for eBGP peers.
+
+ -- BGP: neighbor PEER ttl-security hops NUMBER
+ -- BGP: no neighbor PEER ttl-security hops NUMBER
+ This command enforces Generalized TTL Security Mechanism (GTSM), as
+ specified in RFC 5082. With this command, only neighbors that are
+ the specified number of hops away will be allowed to become
+ neighbors. This command is mututally exclusive with
+ 'ebgp-multihop'.
+
+\1f
+File: quagga.info, Node: Peer filtering, Prev: BGP Peer commands, Up: BGP Peer
+
+11.5.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'.
+
+ -- BGP: bgp route-reflector allow-outbound-policy
+ By default, attribute modification via route-map policy out is not
+ reflected on reflected routes. This option allows the
+ modifications to be reflected as well. Once enabled, it affects
+ all reflected routes.
+
+\1f
+File: quagga.info, Node: BGP Peer Group, Next: BGP Address Family, Prev: BGP Peer, Up: BGP
+
+11.6 BGP Peer Group
+===================
+
+ -- BGP: neighbor WORD peer-group
+ This command defines a new peer group.
+
+ -- BGP: neighbor PEER peer-group WORD
+ This command bind specific peer to peer group WORD.
+
+\1f
+File: quagga.info, Node: BGP Address Family, Next: Autonomous System, Prev: BGP Peer Group, Up: BGP
+
+11.7 BGP Address Family
+=======================
+
+Multiprotocol BGP enables BGP to carry routing information for multiple
+Network Layer protocols. BGP supports multiple Address Family
+Identifier (AFI), namely IPv4 and IPv6. Support is also provided for
+multiple sets of per-AFI information via Subsequent Address Family
+Identifiers (SAFI). In addition to unicast information, VPN information
+'RFC4364' and 'RFC4659', and Encapsulation information 'RFC5512' is
+supported.
+
+ -- Command: show ip bgp vpnv4 all
+ -- Command: show ipv6 bgp vpn all
+ Print active IPV4 or IPV6 routes advertised via the VPN SAFI.
+
+ -- Command: show ip bgp encap all
+ -- Command: show ipv6 bgp encap all
+ Print active IPV4 or IPV6 routes advertised via the Encapsulation
+ SAFI.
+
+ -- Command: show bgp ipv4 encap summary
+ -- Command: show bgp ipv4 vpn summary
+ -- Command: show bgp ipv6 encap summary
+ -- Command: show bgp ipv6 vpn summary
+ Print a summary of neighbor connections for the specified AFI/SAFI
+ combination.
+
+\1f
+File: quagga.info, Node: Autonomous System, Next: BGP Communities Attribute, Prev: BGP Address Family, Up: BGP
+
+11.8 Autonomous System
+======================
+
+The AS (Autonomous System) number is one of the essential element of
+BGP. BGP is a distance vector routing protocol, and the AS-Path
+framework provides distance vector metric and loop detection to BGP.
+'RFC1930, Guidelines for creation, selection, and registration of an
+Autonomous System (AS)' provides some background on the concepts of an
+AS.
+
+ The AS number is a two octet value, ranging in value from 1 to 65535.
+The AS numbers 64512 through 65535 are defined as private AS numbers.
+Private AS numbers must not to be advertised in the global Internet.
+
+* Menu:
+
+* AS Path Regular Expression::
+* Display BGP Routes by AS Path::
+* AS Path Access List::
+* Using AS Path in Route Map::
+* Private AS Numbers::
+
+\1f
+File: quagga.info, Node: AS Path Regular Expression, Next: Display BGP Routes by AS Path, Up: Autonomous System
+
+11.8.1 AS Path Regular Expression
+---------------------------------
+
+AS path regular expression can be used for displaying BGP routes and AS
+path access list. AS path regular expression is based on 'POSIX 1003.2'
+regular expressions. Following description is just a subset of 'POSIX'
+regular expression. User can use full 'POSIX' regular expression.
+Adding to that special character '_' is added for AS path regular
+expression.
+
+'.'
+ Matches any single character.
+'*'
+ Matches 0 or more occurrences of pattern.
+'+'
+ Matches 1 or more occurrences of pattern.
+'?'
+ Match 0 or 1 occurrences of pattern.
+'^'
+ Matches the beginning of the line.
+'$'
+ Matches the end of the line.
+'_'
+ Character '_' has special meanings in AS path regular expression.
+ It matches to space and comma , and AS set delimiter { and } and AS
+ confederation delimiter '(' and ')'. And it also matches to the
+ beginning of the line and the end of the line. So '_' can be used
+ for AS value boundaries match. 'show ip bgp regexp _7675_' matches
+ to all of BGP routes which as AS number include 7675.
+
+\1f
+File: quagga.info, Node: Display BGP Routes by AS Path, Next: AS Path Access List, Prev: AS Path Regular Expression, Up: Autonomous System
+
+11.8.2 Display BGP Routes by AS Path
+------------------------------------
+
+To show BGP routes which has specific AS path information 'show ip bgp'
+command can be used.
+
+ -- Command: show ip bgp regexp LINE
+ This commands display BGP routes that matches AS path regular
+ expression LINE.
+
+\1f
+File: quagga.info, Node: AS Path Access List, Next: Using AS Path in Route Map, Prev: Display BGP Routes by AS Path, Up: Autonomous System
+
+11.8.3 AS Path Access List
+--------------------------
+
+AS path access list is user defined AS path.
+
+ -- Command: ip as-path access-list WORD {permit|deny} LINE
+ This command defines a new AS path access list.
+
+ -- Command: no ip as-path access-list WORD
+ -- Command: no ip as-path access-list WORD {permit|deny} LINE
+
+\1f
+File: quagga.info, Node: Using AS Path in Route Map, Next: Private AS Numbers, Prev: AS Path Access List, Up: Autonomous System
+
+11.8.4 Using AS Path in Route Map
+---------------------------------
+
+ -- Route Map: match as-path WORD
+
+ -- Route Map: set as-path prepend AS-PATH
+ Prepend the given string of AS numbers to the AS_PATH.
+
+ -- Route Map: set as-path prepend last-as NUM
+ Prepend the existing last AS number (the leftmost ASN) to the
+ AS_PATH.
+
+\1f
+File: quagga.info, Node: Private AS Numbers, Prev: Using AS Path in Route Map, Up: Autonomous System
+
+11.8.5 Private AS Numbers
+-------------------------
+
+\1f
+File: quagga.info, Node: BGP Communities Attribute, Next: BGP Extended Communities Attribute, Prev: Autonomous System, Up: BGP
+
+11.9 BGP Communities Attribute
+==============================
+
+BGP communities attribute is widely used for implementing policy
+routing. Network operators can manipulate BGP communities attribute
+based on their network policy. BGP communities attribute is defined in
+'RFC1997, BGP Communities Attribute' and 'RFC1998, An Application of the
+BGP Community Attribute in Multi-home Routing'. It is an optional
+transitive attribute, therefore local policy can travel through
+different autonomous system.
+
+ Communities attribute is a set of communities values. Each
+communities value is 4 octet long. The following format is used to
+define communities value.
+
+'AS:VAL'
+ This format represents 4 octet communities value. 'AS' is high
+ order 2 octet in digit format. 'VAL' is low order 2 octet in digit
+ format. This format is useful to define AS oriented policy value.
+ For example, '7675:80' can be used when AS 7675 wants to pass local
+ policy value 80 to neighboring peer.
+'internet'
+ 'internet' represents well-known communities value 0.
+'no-export'
+ 'no-export' represents well-known communities value 'NO_EXPORT'
+ (0xFFFFFF01). All routes carry this value must not be advertised
+ to outside a BGP confederation boundary. If neighboring BGP peer
+ is part of BGP confederation, the peer is considered as inside a
+ BGP confederation boundary, so the route will be announced to the
+ peer.
+'no-advertise'
+ 'no-advertise' represents well-known communities value
+ 'NO_ADVERTISE'
+ (0xFFFFFF02). All routes carry this value must not be advertise to
+ other BGP peers.
+'local-AS'
+ 'local-AS' represents well-known communities value
+ 'NO_EXPORT_SUBCONFED' (0xFFFFFF03). All routes carry this value
+ must not be advertised to external BGP peers. Even if the
+ neighboring router is part of confederation, it is considered as
+ external BGP peer, so the route will not be announced to the peer.
+
+ When BGP communities attribute is received, duplicated communities
+value in the communities attribute is ignored and each communities
+values are sorted in numerical order.
+
+* Menu:
+
+* BGP Community Lists::
+* Numbered BGP Community Lists::
+* BGP Community in Route Map::
+* Display BGP Routes by Community::
+* Using BGP Communities Attribute::
+
+\1f
+File: quagga.info, Node: BGP Community Lists, Next: Numbered BGP Community Lists, Up: BGP Communities Attribute
+
+11.9.1 BGP Community Lists
+--------------------------
+
+BGP community list is a user defined BGP communites attribute list. BGP
+community list can be used for matching or manipulating BGP communities
+attribute in updates.
+
+ There are two types of community list. One is standard community
+list and another is expanded community list. Standard community list
+defines communities attribute. Expanded community list defines
+communities attribute string with regular expression. Standard
+community list is compiled into binary format when user define it.
+Standard community list will be directly compared to BGP communities
+attribute in BGP updates. Therefore the comparison is faster than
+expanded community list.
+
+ -- Command: ip community-list standard NAME {permit|deny} COMMUNITY
+ This command defines a new standard community list. COMMUNITY is
+ communities value. The COMMUNITY is compiled into community
+ structure. We can define multiple community list under same name.
+ In that case match will happen user defined order. Once the
+ community list matches to communities attribute in BGP updates it
+ return permit or deny by the community list definition. When there
+ is no matched entry, deny will be returned. When COMMUNITY is
+ empty it matches to any routes.
+
+ -- Command: ip community-list expanded NAME {permit|deny} LINE
+ This command defines a new expanded community list. LINE is a
+ string expression of communities attribute. LINE can include
+ regular expression to match communities attribute in BGP updates.
+
+ -- Command: no ip community-list NAME
+ -- Command: no ip community-list standard NAME
+ -- Command: no ip community-list expanded NAME
+ These commands delete community lists specified by NAME. All of
+ community lists shares a single name space. So community lists can
+ be removed simpley specifying community lists name.
+
+ -- Command: show ip community-list
+ -- Command: show ip community-list NAME
+ This command display current community list information. When NAME
+ is specified the specified community list's information is shown.
+
+ # show ip community-list
+ Named Community standard list CLIST
+ permit 7675:80 7675:100 no-export
+ deny internet
+ Named Community expanded list EXPAND
+ permit :
+
+ # show ip community-list CLIST
+ Named Community standard list CLIST
+ permit 7675:80 7675:100 no-export
+ deny internet
+
+\1f
+File: quagga.info, Node: Numbered BGP Community Lists, Next: BGP Community in Route Map, Prev: BGP Community Lists, Up: BGP Communities Attribute
+
+11.9.2 Numbered BGP Community Lists
+-----------------------------------
+
+When number is used for BGP community list name, the number has special
+meanings. Community list number in the range from 1 and 99 is standard
+community list. Community list number in the range from 100 to 199 is
+expanded community list. These community lists are called as numbered
+community lists. On the other hand normal community lists is called as
+named community lists.
+
+ -- Command: ip community-list <1-99> {permit|deny} COMMUNITY
+ This command defines a new community list. <1-99> is standard
+ community list number. Community list name within this range
+ defines standard community list. When COMMUNITY is empty it
+ matches to any routes.
+
+ -- Command: ip community-list <100-199> {permit|deny} COMMUNITY
+ This command defines a new community list. <100-199> is expanded
+ community list number. Community list name within this range
+ defines expanded community list.
+
+ -- Command: ip community-list NAME {permit|deny} COMMUNITY
+ When community list type is not specifed, the community list type
+ is automatically detected. If COMMUNITY can be compiled into
+ communities attribute, the community list is defined as a standard
+ community list. Otherwise it is defined as an expanded community
+ list. This feature is left for backward compability. Use of this
+ feature is not recommended.
+
+\1f
+File: quagga.info, Node: BGP Community in Route Map, Next: Display BGP Routes by Community, Prev: Numbered BGP Community Lists, Up: BGP Communities Attribute
+
+11.9.3 BGP Community in Route Map
+---------------------------------
+
+In Route Map (*note Route Map::), we can match or set BGP communities
+attribute. Using this feature network operator can implement their
+network policy based on BGP communities attribute.
+
+ Following commands can be used in Route Map.
+
+ -- Route Map: match community WORD
+ -- Route Map: match community WORD exact-match
+ This command perform match to BGP updates using community list
+ WORD. When the one of BGP communities value match to the one of
+ communities value in community list, it is match. When
+ 'exact-match' keyword is spcified, match happen only when BGP
+ updates have completely same communities value specified in the
+ community list.
+
+ -- Route Map: set community none
+ -- Route Map: set community COMMUNITY
+ -- Route Map: set community COMMUNITY additive
+ This command manipulate communities value in BGP updates. When
+ 'none' is specified as communities value, it removes entire
+ communities attribute from BGP updates. When COMMUNITY is not
+ 'none', specified communities value is set to BGP updates. If BGP
+ updates already has BGP communities value, the existing BGP
+ communities value is replaced with specified COMMUNITY value. When
+ 'additive' keyword is specified, COMMUNITY is appended to the
+ existing communities value.
+
+ -- Route Map: set comm-list WORD delete
+ This command remove communities value from BGP communities
+ attribute. The WORD is community list name. When BGP route's
+ communities value matches to the community list WORD, the
+ communities value is removed. When all of communities value is
+ removed eventually, the BGP update's communities attribute is
+ completely removed.
+
+\1f
+File: quagga.info, Node: Display BGP Routes by Community, Next: Using BGP Communities Attribute, Prev: BGP Community in Route Map, Up: BGP Communities Attribute
+
+11.9.4 Display BGP Routes by Community
+--------------------------------------
+
+To show BGP routes which has specific BGP communities attribute, 'show
+ip bgp' command can be used. The COMMUNITY value and community list can
+be used for 'show ip bgp' command.
+
+ -- Command: show ip bgp community
+ -- Command: show ip bgp community COMMUNITY
+ -- Command: show ip bgp community COMMUNITY exact-match
+ 'show ip bgp community' displays BGP routes which has communities
+ attribute. When COMMUNITY is specified, BGP routes that matches
+ COMMUNITY value is displayed. For this command, 'internet' keyword
+ can't be used for COMMUNITY value. When 'exact-match' is
+ specified, it display only routes that have an exact match.
+
+ -- Command: show ip bgp community-list WORD
+ -- Command: show ip bgp community-list WORD exact-match
+ This commands display BGP routes that matches community list WORD.
+ When 'exact-match' is specified, display only routes that have an
+ exact match.
+
+\1f
+File: quagga.info, Node: Using BGP Communities Attribute, Prev: Display BGP Routes by Community, Up: BGP Communities Attribute
+
+11.9.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 and 0:90. Network operator can put
+special internal communities value at BGP border router, then limit the
+BGP routes announcement into the internal network.
+
+ router bgp 7675
+ neighbor 192.168.0.1 remote-as 100
+ neighbor 192.168.0.1 route-map RMAP in
+ !
+ ip community-list 1 permit 0:80 0:90
+ !
+ route-map RMAP permit in
+ match community 1
+
+ Following exmaple filter BGP routes which has communities value 1:1.
+When there is no match community-list returns deny. To avoid filtering
+all of routes, we need to define permit any at last.
+
+ router bgp 7675
+ neighbor 192.168.0.1 remote-as 100
+ neighbor 192.168.0.1 route-map RMAP in
+ !
+ ip community-list standard FILTER deny 1:1
+ ip community-list standard FILTER permit
+ !
+ route-map RMAP permit 10
+ match community FILTER
+
+ Communities value keyword 'internet' has special meanings in standard
+community lists. In below example 'internet' act as match any. It
+matches all of BGP routes even if the route does not have communities
+attribute at all. So community list 'INTERNET' is same as above
+example's 'FILTER'.
+
+ ip community-list standard INTERNET deny 1:1
+ ip community-list standard INTERNET permit internet
+
+ Following configuration is an example of communities value deletion.
+With this configuration communities value 100:1 and 100:2 is removed
+from BGP updates. For communities value deletion, only 'permit'
+community-list is used. 'deny' community-list is ignored.
+
+ router bgp 7675
+ neighbor 192.168.0.1 remote-as 100
+ neighbor 192.168.0.1 route-map RMAP in
+ !
+ ip community-list standard DEL permit 100:1 100:2
+ !
+ route-map RMAP permit 10
+ set comm-list DEL delete
+
+\1f
+File: quagga.info, Node: BGP Extended Communities Attribute, Next: Displaying BGP routes, Prev: BGP Communities Attribute, Up: BGP
+
+11.10 BGP Extended Communities Attribute
+========================================
+
+BGP extended communities attribute is introduced with MPLS VPN/BGP
+technology. MPLS VPN/BGP expands capability of network infrastructure
+to provide VPN functionality. At the same time it requires a new
+framework for policy routing. With BGP Extended Communities Attribute
+we can use Route Target or Site of Origin for implementing network
+policy for MPLS VPN/BGP.
+
+ BGP Extended Communities Attribute is similar to BGP Communities
+Attribute. It is an optional transitive attribute. BGP Extended
+Communities Attribute can carry multiple Extended Community value. Each
+Extended Community value is eight octet length.
+
+ BGP Extended Communities Attribute provides an extended range
+compared with BGP Communities Attribute. Adding to that there is a type
+field in each value to provides community space structure.
+
+ There are two format to define Extended Community value. One is AS
+based format the other is IP address based format.
+
+'AS:VAL'
+ This is a format to define AS based Extended Community value. 'AS'
+ part is 2 octets Global Administrator subfield in Extended
+ Community value. 'VAL' part is 4 octets Local Administrator
+ subfield. '7675:100' represents AS 7675 policy value 100.
+'IP-Address:VAL'
+ This is a format to define IP address based Extended Community
+ value. 'IP-Address' part is 4 octets Global Administrator
+ subfield. 'VAL' part is 2 octets Local Administrator subfield.
+ '10.0.0.1:100' represents
+
+* Menu:
+
+* BGP Extended Community Lists::
+* BGP Extended Communities in Route Map::
+
+\1f
+File: quagga.info, Node: BGP Extended Community Lists, Next: BGP Extended Communities in Route Map, Up: BGP Extended Communities Attribute
+
+11.10.1 BGP Extended Community Lists
+------------------------------------
+
+Expanded Community Lists is a user defined BGP Expanded Community Lists.
+
+ -- Command: ip extcommunity-list standard NAME {permit|deny}
+ EXTCOMMUNITY
+ This command defines a new standard extcommunity-list.
+ EXTCOMMUNITY is extended communities value. The EXTCOMMUNITY is
+ compiled into extended community structure. We can define multiple
+ extcommunity-list under same name. In that case match will happen
+ user defined order. Once the extcommunity-list matches to extended
+ communities attribute in BGP updates it return permit or deny based
+ upon the extcommunity-list definition. When there is no matched
+ entry, deny will be returned. When EXTCOMMUNITY is empty it
+ matches to any routes.
+
+ -- Command: ip extcommunity-list expanded NAME {permit|deny} LINE
+ This command defines a new expanded extcommunity-list. LINE is a
+ string expression of extended communities attribute. LINE can
+ include regular expression to match extended communities attribute
+ in BGP updates.
+
+ -- Command: no ip extcommunity-list NAME
+ -- Command: no ip extcommunity-list standard NAME
+ -- Command: no ip extcommunity-list expanded NAME
+ These commands delete extended community lists specified by NAME.
+ All of extended community lists shares a single name space. So
+ extended community lists can be removed simpley specifying the
+ name.
+
+ -- Command: show ip extcommunity-list
+ -- Command: show ip extcommunity-list NAME
+ This command display current extcommunity-list information. When
+ NAME is specified the community list's information is shown.
+
+ # show ip extcommunity-list
+
+\1f
+File: quagga.info, Node: BGP Extended Communities in Route Map, Prev: BGP Extended Community Lists, Up: BGP Extended Communities Attribute
+
+11.10.2 BGP Extended Communities in Route Map
+---------------------------------------------
+
+ -- Route Map: match extcommunity WORD
+
+ -- Route Map: set extcommunity rt EXTCOMMUNITY
+ This command set Route Target value.
+
+ -- Route Map: set extcommunity soo EXTCOMMUNITY
+ This command set Site of Origin value.
+
+\1f
+File: quagga.info, Node: Displaying BGP routes, Next: Capability Negotiation, Prev: BGP Extended Communities Attribute, Up: BGP
+
+11.11 Displaying BGP Routes
+===========================
+
+* Menu:
+
+* Show IP BGP::
+* More Show IP BGP::
+
+\1f
+File: quagga.info, Node: Show IP BGP, Next: More Show IP BGP, Up: Displaying BGP routes
+
+11.11.1 Show IP BGP
+-------------------
+
+ -- Command: show ip bgp
+ -- Command: show ip bgp A.B.C.D
+ -- Command: show ip bgp X:X::X:X
+ This command displays BGP routes. When no route is specified it
+ display all of IPv4 BGP routes.
+
+ BGP table version is 0, local router ID is 10.1.1.1
+ Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
+ Origin codes: i - IGP, e - EGP, ? - incomplete
+
+ Network Next Hop Metric LocPrf Weight Path
+ *> 1.1.1.1/32 0.0.0.0 0 32768 i
+
+ Total number of prefixes 1
+
+\1f
+File: quagga.info, Node: More Show IP BGP, Prev: Show IP BGP, Up: Displaying BGP routes
+
+11.11.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 ip bgp dampened-paths
+ Display paths suppressed due to dampening
+
+ -- Command: show ip bgp flap-statistics
+ Display flap statistics of routes
+
+ -- Command: show debug
+
+ -- Command: debug event
+
+ -- Command: debug update
+
+ -- Command: debug keepalive
+
+ -- Command: no debug event
+
+ -- Command: no debug update
+
+ -- Command: no debug keepalive
+
+\1f
+File: quagga.info, Node: Capability Negotiation, Next: Route Reflector, Prev: Displaying BGP routes, Up: BGP
+
+11.12 Capability Negotiation
+============================
+
+When adding IPv6 routing information exchange feature to BGP. There were
+some proposals. IETF (Internet Engineering Task Force) IDR (Inter
+Domain Routing) WG (Working group) adopted 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 did not have the feature to detect remote peer's
+capabilities, e.g. whether it can handle prefix types other than IPv4
+unicast routes. This was a big problem using Multiprotocol Extension
+for BGP to operational network. 'RFC2842, Capabilities Advertisement
+with BGP-4' adopted a feature called Capability Negotiation. 'bgpd' use
+this Capability Negotiation to detect the remote peer's capabilities.
+If the peer is only configured as IPv4 unicast neighbor, 'bgpd' does not
+send these Capability Negotiation packets (at least not unless other
+optional BGP features require capability negotation).
+
+ By default, Quagga will bring up peering with minimal common
+capability for the both sides. For example, local router has unicast
+and multicast capabilitie and remote router has unicast capability. In
+this case, the local router will establish the connection with unicast
+only capability. When there are no common capabilities, Quagga sends
+Unsupported Capability error and then resets the connection.
+
+ If you want to completely match capabilities with remote peer.
+Please use 'strict-capability-match' command.
+
+ -- BGP: neighbor PEER strict-capability-match
+ -- BGP: no neighbor PEER strict-capability-match
+ Strictly compares remote capabilities and local capabilities. If
+ capabilities are different, send Unsupported Capability error then
+ reset connection.
+
+ You may want to disable sending Capability Negotiation OPEN message
+optional parameter to the peer when remote peer does not implement
+Capability Negotiation. Please use 'dont-capability-negotiate' command
+to disable the feature.
+
+ -- BGP: neighbor PEER dont-capability-negotiate
+ -- BGP: no neighbor PEER dont-capability-negotiate
+ Suppress sending Capability Negotiation as OPEN message optional
+ parameter to the peer. This command only affects the peer is
+ configured other than IPv4 unicast configuration.
+
+ When remote peer does not have capability negotiation feature, remote
+peer will not send any capabilities at all. In that case, bgp
+configures the peer with configured capabilities.
+
+ You may prefer locally configured capabilities more than the
+negotiated capabilities even though remote peer sends capabilities. If
+the peer is configured by 'override-capability', 'bgpd' ignores received
+capabilities then override negotiated capabilities with configured
+values.
+
+ -- BGP: neighbor PEER override-capability
+ -- BGP: no neighbor PEER override-capability
+ Override the result of Capability Negotiation with local
+ configuration. Ignore remote peer's capability value.
+
+\1f
+File: quagga.info, Node: Route Reflector, Next: Route Server, Prev: Capability Negotiation, Up: BGP
+
+11.13 Route Reflector
+=====================
+
+ -- BGP: bgp cluster-id A.B.C.D
+
+ -- BGP: neighbor PEER route-reflector-client
+ -- BGP: no neighbor PEER route-reflector-client
+
+\1f
+File: quagga.info, Node: Route Server, Next: How to set up a 6-Bone connection, Prev: Route Reflector, Up: BGP
+
+11.14 Route Server
+==================
+
+At an Internet Exchange point, many ISPs are connected to each other by
+external BGP peering. Normally these external BGP connection are done
+by 'full mesh' method. As with internal BGP full mesh formation, this
+method has a scaling problem.
+
+ This scaling problem is well known. Route Server is a method to
+resolve the problem. Each ISP's BGP router only peers to Route Server.
+Route Server serves as BGP information exchange to other BGP routers.
+By applying this method, numbers of BGP connections is reduced from
+O(n*(n-1)/2) to O(n).
+
+ Unlike normal BGP router, Route Server must have several routing
+tables for managing different routing policies for each BGP speaker. We
+call the routing tables as different 'view's. 'bgpd' can work as normal
+BGP router or Route Server or both at the same time.
+
+* Menu:
+
+* Multiple instance::
+* BGP instance and view::
+* Routing policy::
+* Viewing the view::
+
+\1f
+File: quagga.info, Node: Multiple instance, Next: BGP instance and view, Up: Route Server
+
+11.14.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 displayed.
+
+ "network" and "aggregate-address" argument is displayed as "A.B.C.D
+M.M.M.M"
+
+ Quagga: network 10.0.0.0/8 Cisco: network 10.0.0.0
+
+ Quagga: aggregate-address 192.168.0.0/24 Cisco: aggregate-address
+192.168.0.0 255.255.255.0
+
+ Community attribute handling is also different. If there is no
+configuration is specified community attribute and extended community
+attribute are sent to neighbor. When user manually disable the feature
+community attribute is not sent to the neighbor. In case of 'bgp
+config-type cisco' is specified, community attribute is not sent to the
+neighbor by default. To send community attribute user has to specify
+'neighbor A.B.C.D send-community' command.
+
+ !
+ router bgp 1
+ neighbor 10.0.0.1 remote-as 1
+ no neighbor 10.0.0.1 send-community
+ !
+ router bgp 1
+ neighbor 10.0.0.1 remote-as 1
+ neighbor 10.0.0.1 send-community
+ !
+
+ -- Command: bgp config-type zebra
+ Quagga style BGP configuration. This is default.
+
+\1f
+File: quagga.info, Node: BGP instance and view, Next: Routing policy, Prev: Multiple instance, Up: Route Server
+
+11.14.2 BGP instance and view
+-----------------------------
+
+BGP instance is a normal BGP process. The result of route selection
+goes to the kernel routing table. You can setup different AS at the
+same time when BGP multiple instance feature is enabled.
+
+ -- Command: router bgp AS-NUMBER
+ Make a new BGP instance. You can use arbitrary word for the NAME.
+
+ bgp multiple-instance
+ !
+ router bgp 1
+ neighbor 10.0.0.1 remote-as 2
+ neighbor 10.0.0.2 remote-as 3
+ !
+ router bgp 2
+ neighbor 10.0.0.3 remote-as 4
+ neighbor 10.0.0.4 remote-as 5
+
+ BGP view is almost same as normal BGP process. The result of route
+selection does not go to the kernel routing table. BGP view is only for
+exchanging BGP routing information.
+
+ -- Command: router bgp AS-NUMBER view NAME
+ Make a new BGP view. You can use arbitrary word for the NAME.
+ This view's route selection result does not go to the kernel
+ routing table.
+
+ With this command, you can setup Route Server like below.
+
+ bgp multiple-instance
+ !
+ router bgp 1 view 1
+ neighbor 10.0.0.1 remote-as 2
+ neighbor 10.0.0.2 remote-as 3
+ !
+ router bgp 2 view 2
+ neighbor 10.0.0.3 remote-as 4
+ neighbor 10.0.0.4 remote-as 5
+
+\1f
+File: quagga.info, Node: Routing policy, Next: Viewing the view, Prev: BGP instance and view, Up: Route Server
+
+11.14.3 Routing policy
+----------------------
+
+You can set different routing policy for a peer. For example, you can
+set different filter for a peer.
+
+ bgp multiple-instance
+ !
+ router bgp 1 view 1
+ neighbor 10.0.0.1 remote-as 2
+ neighbor 10.0.0.1 distribute-list 1 in
+ !
+ router bgp 1 view 2
+ neighbor 10.0.0.1 remote-as 2
+ neighbor 10.0.0.1 distribute-list 2 in
+
+ This means BGP update from a peer 10.0.0.1 goes to both BGP view 1
+and view 2. When the update is inserted into view 1, distribute-list 1
+is applied. On the other hand, when the update is inserted into view 2,
+distribute-list 2 is applied.
+
+\1f
+File: quagga.info, Node: Viewing the view, Prev: Routing policy, Up: Route Server
+
+11.14.4 Viewing the view
+------------------------
+
+To display routing table of BGP view, you must specify view name.
+
+ -- Command: show ip bgp view NAME
+ Display routing table of BGP view NAME.
+
+\1f
+File: quagga.info, Node: How to set up a 6-Bone connection, Next: Dump BGP packets and table, Prev: Route Server, Up: BGP
+
+11.15 How to set up a 6-Bone connection
+=======================================
+
+ zebra configuration
+ ===================
+ !
+ ! Actually there is no need to configure zebra
+ !
+
+ bgpd configuration
+ ==================
+ !
+ ! This means that routes go through zebra and into the kernel.
+ !
+ router zebra
+ !
+ ! MP-BGP configuration
+ !
+ router bgp 7675
+ bgp router-id 10.0.0.1
+ neighbor 3ffe:1cfa:0:2:2a0:c9ff:fe9e:f56 remote-as AS-NUMBER
+ !
+ address-family ipv6
+ network 3ffe:506::/32
+ neighbor 3ffe:1cfa:0:2:2a0:c9ff:fe9e:f56 activate
+ neighbor 3ffe:1cfa:0:2:2a0:c9ff:fe9e:f56 route-map set-nexthop out
+ neighbor 3ffe:1cfa:0:2:2c0:4fff:fe68:a231 remote-as AS-NUMBER
+ neighbor 3ffe:1cfa:0:2:2c0:4fff:fe68:a231 route-map set-nexthop out
+ exit-address-family
+ !
+ ipv6 access-list all permit any
+ !
+ ! Set output nexthop address.
+ !
+ route-map set-nexthop permit 10
+ match ipv6 address all
+ set ipv6 nexthop global 3ffe:1cfa:0:2:2c0:4fff:fe68:a225
+ set ipv6 nexthop local fe80::2c0:4fff:fe68:a225
+ !
+ ! logfile FILENAME is obsolete. Please use log file FILENAME
+
+ log file bgpd.log
+ !
+
+\1f
+File: quagga.info, Node: Dump BGP packets and table, Next: BGP Configuration Examples, Prev: How to set up a 6-Bone connection, Up: BGP
+
+11.16 Dump BGP packets and table
+================================
+
+ -- Command: dump bgp all PATH [INTERVAL]
+ -- Command: dump bgp all-et PATH [INTERVAL]
+ -- Command: no dump bgp all [PATH] [INTERVAL]
+ Dump all BGP packet and events to PATH file. If INTERVAL is set, a
+ new file will be created for echo INTERVAL of seconds. The path
+ PATH can be set with date and time formatting (strftime). The type
+ ‘all-et’ enables support for Extended Timestamp Header (*note
+ Packet Binary Dump Format::). (*note Packet Binary Dump Format::)
+
+ -- Command: dump bgp updates PATH [INTERVAL]
+ -- Command: dump bgp updates-et PATH [INTERVAL]
+ -- Command: no dump bgp updates [PATH] [INTERVAL]
+ Dump only BGP updates messages to PATH file. If INTERVAL is set, a
+ new file will be created for echo INTERVAL of seconds. The path
+ PATH can be set with date and time formatting (strftime). The type
+ ‘updates-et’ enables support for Extended Timestamp Header
+ (*note Packet Binary Dump Format::).
+
+ -- Command: dump bgp routes-mrt PATH
+ -- Command: dump bgp routes-mrt PATH INTERVAL
+ -- Command: no dump bgp route-mrt [PATH] [INTERVAL]
+ Dump whole BGP routing table to PATH. This is heavy process. The
+ path PATH can be set with date and time formatting (strftime). If
+ INTERVAL is set, a new file will be created for echo INTERVAL of
+ seconds.
+
+ Note: the interval variable can also be set using hours and minutes:
+04h20m00.
+
+\1f
+File: quagga.info, Node: BGP Configuration Examples, Prev: Dump BGP packets and table, Up: BGP
+
+11.17 BGP Configuration Examples
+================================
+
+Example of a session to an upstream, advertising only one prefix to it.
+
+ router bgp 64512
+ bgp router-id 10.236.87.1
+ network 10.236.87.0/24
+ neighbor upstream peer-group
+ neighbor upstream remote-as 64515
+ neighbor upstream capability dynamic
+ neighbor upstream prefix-list pl-allowed-adv out
+ neighbor 10.1.1.1 peer-group upstream
+ neighbor 10.1.1.1 description ACME ISP
+ !
+ ip prefix-list pl-allowed-adv seq 5 permit 82.195.133.0/25
+ ip prefix-list pl-allowed-adv seq 10 deny any
+
+
+ A more complex example. With upstream, peer and customer sessions.
+Advertising global prefixes and NO_EXPORT prefixes and providing actions
+for customer routes based on community values. Extensive use of
+route-maps and the 'call' feature to support selective advertising of
+prefixes. This example is intended as guidance only, it has NOT been
+tested and almost certainly containts silly mistakes, if not serious
+flaws.
+
+ router bgp 64512
+ bgp router-id 10.236.87.1
+ network 10.123.456.0/24
+ network 10.123.456.128/25 route-map rm-no-export
+ neighbor upstream capability dynamic
+ neighbor upstream route-map rm-upstream-out out
+ neighbor cust capability dynamic
+ neighbor cust route-map rm-cust-in in
+ neighbor cust route-map rm-cust-out out
+ neighbor cust send-community both
+ neighbor peer capability dynamic
+ neighbor peer route-map rm-peer-in in
+ neighbor peer route-map rm-peer-out out
+ neighbor peer send-community both
+ neighbor 10.1.1.1 remote-as 64515
+ neighbor 10.1.1.1 peer-group upstream
+ neighbor 10.2.1.1 remote-as 64516
+ neighbor 10.2.1.1 peer-group upstream
+ neighbor 10.3.1.1 remote-as 64517
+ neighbor 10.3.1.1 peer-group cust-default
+ neighbor 10.3.1.1 description customer1
+ neighbor 10.3.1.1 prefix-list pl-cust1-network in
+ neighbor 10.4.1.1 remote-as 64518
+ neighbor 10.4.1.1 peer-group cust
+ neighbor 10.4.1.1 prefix-list pl-cust2-network in
+ neighbor 10.4.1.1 description customer2
+ neighbor 10.5.1.1 remote-as 64519
+ neighbor 10.5.1.1 peer-group peer
+ neighbor 10.5.1.1 prefix-list pl-peer1-network in
+ neighbor 10.5.1.1 description peer AS 1
+ neighbor 10.6.1.1 remote-as 64520
+ neighbor 10.6.1.1 peer-group peer
+ neighbor 10.6.1.1 prefix-list pl-peer2-network in
+ neighbor 10.6.1.1 description peer AS 2
+ !
+ ip prefix-list pl-default permit 0.0.0.0/0
+ !
+ ip prefix-list pl-upstream-peers permit 10.1.1.1/32
+ ip prefix-list pl-upstream-peers permit 10.2.1.1/32
+ !
+ ip prefix-list pl-cust1-network permit 10.3.1.0/24
+ ip prefix-list pl-cust1-network permit 10.3.2.0/24
+ !
+ ip prefix-list pl-cust2-network permit 10.4.1.0/24
+ !
+ ip prefix-list pl-peer1-network permit 10.5.1.0/24
+ ip prefix-list pl-peer1-network permit 10.5.2.0/24
+ ip prefix-list pl-peer1-network permit 192.168.0.0/24
+ !
+ ip prefix-list pl-peer2-network permit 10.6.1.0/24
+ ip prefix-list pl-peer2-network permit 10.6.2.0/24
+ ip prefix-list pl-peer2-network permit 192.168.1.0/24
+ ip prefix-list pl-peer2-network permit 192.168.2.0/24
+ ip prefix-list pl-peer2-network permit 172.16.1/24
+ !
+ ip as-path access-list asp-own-as permit ^$
+ ip as-path access-list asp-own-as permit _64512_
+ !
+ ! #################################################################
+ ! Match communities we provide actions for, on routes receives from
+ ! customers. Communities values of <our-ASN>:X, with X, have actions:
+ !
+ ! 100 - blackhole the prefix
+ ! 200 - set no_export
+ ! 300 - advertise only to other customers
+ ! 400 - advertise only to upstreams
+ ! 500 - set no_export when advertising to upstreams
+ ! 2X00 - set local_preference to X00
+ !
+ ! blackhole the prefix of the route
+ ip community-list standard cm-blackhole permit 64512:100
+ !
+ ! set no-export community before advertising
+ ip community-list standard cm-set-no-export permit 64512:200
+ !
+ ! advertise only to other customers
+ ip community-list standard cm-cust-only permit 64512:300
+ !
+ ! advertise only to upstreams
+ ip community-list standard cm-upstream-only permit 64512:400
+ !
+ ! advertise to upstreams with no-export
+ ip community-list standard cm-upstream-noexport permit 64512:500
+ !
+ ! set local-pref to least significant 3 digits of the community
+ ip community-list standard cm-prefmod-100 permit 64512:2100
+ ip community-list standard cm-prefmod-200 permit 64512:2200
+ ip community-list standard cm-prefmod-300 permit 64512:2300
+ ip community-list standard cm-prefmod-400 permit 64512:2400
+ ip community-list expanded cme-prefmod-range permit 64512:2...
+ !
+ ! Informational communities
+ !
+ ! 3000 - learned from upstream
+ ! 3100 - learned from customer
+ ! 3200 - learned from peer
+ !
+ ip community-list standard cm-learnt-upstream permit 64512:3000
+ ip community-list standard cm-learnt-cust permit 64512:3100
+ ip community-list standard cm-learnt-peer permit 64512:3200
+ !
+ ! ###################################################################
+ ! Utility route-maps
+ !
+ ! These utility route-maps generally should not used to permit/deny
+ ! routes, i.e. they do not have meaning as filters, and hence probably
+ ! should be used with 'on-match next'. These all finish with an empty
+ ! permit entry so as not interfere with processing in the caller.
+ !
+ route-map rm-no-export permit 10
+ set community additive no-export
+ route-map rm-no-export permit 20
+ !
+ route-map rm-blackhole permit 10
+ description blackhole, up-pref and ensure it cant escape this AS
+ set ip next-hop 127.0.0.1
+ set local-preference 10
+ set community additive no-export
+ route-map rm-blackhole permit 20
+ !
+ ! Set local-pref as requested
+ route-map rm-prefmod permit 10
+ match community cm-prefmod-100
+ set local-preference 100
+ route-map rm-prefmod permit 20
+ match community cm-prefmod-200
+ set local-preference 200
+ route-map rm-prefmod permit 30
+ match community cm-prefmod-300
+ set local-preference 300
+ route-map rm-prefmod permit 40
+ match community cm-prefmod-400
+ set local-preference 400
+ route-map rm-prefmod permit 50
+ !
+ ! Community actions to take on receipt of route.
+ route-map rm-community-in permit 10
+ description check for blackholing, no point continuing if it matches.
+ match community cm-blackhole
+ call rm-blackhole
+ route-map rm-community-in permit 20
+ match community cm-set-no-export
+ call rm-no-export
+ on-match next
+ route-map rm-community-in permit 30
+ match community cme-prefmod-range
+ call rm-prefmod
+ route-map rm-community-in permit 40
+ !
+ ! #####################################################################
+ ! Community actions to take when advertising a route.
+ ! These are filtering route-maps,
+ !
+ ! Deny customer routes to upstream with cust-only set.
+ route-map rm-community-filt-to-upstream deny 10
+ match community cm-learnt-cust
+ match community cm-cust-only
+ route-map rm-community-filt-to-upstream permit 20
+ !
+ ! Deny customer routes to other customers with upstream-only set.
+ route-map rm-community-filt-to-cust deny 10
+ match community cm-learnt-cust
+ match community cm-upstream-only
+ route-map rm-community-filt-to-cust permit 20
+ !
+ ! ###################################################################
+ ! The top-level route-maps applied to sessions. Further entries could
+ ! be added obviously..
+ !
+ ! Customers
+ route-map rm-cust-in permit 10
+ call rm-community-in
+ on-match next
+ route-map rm-cust-in permit 20
+ set community additive 64512:3100
+ route-map rm-cust-in permit 30
+ !
+ route-map rm-cust-out permit 10
+ call rm-community-filt-to-cust
+ on-match next
+ route-map rm-cust-out permit 20
+ !
+ ! Upstream transit ASes
+ route-map rm-upstream-out permit 10
+ description filter customer prefixes which are marked cust-only
+ call rm-community-filt-to-upstream
+ on-match next
+ route-map rm-upstream-out permit 20
+ description only customer routes are provided to upstreams/peers
+ match community cm-learnt-cust
+ !
+ ! Peer ASes
+ ! outbound policy is same as for upstream
+ route-map rm-peer-out permit 10
+ call rm-upstream-out
+ !
+ route-map rm-peer-in permit 10
+ set community additive 64512:3200
+
+\1f
+File: quagga.info, Node: Configuring Quagga as a Route Server, Next: VTY shell, Prev: BGP, Up: Top
+
+12 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 we can convert it into a centralized scenario where each of the
+four establishes a single BGP peering against the Route Server.
+
+ We will first describe briefly the Route Server model implemented by
+Quagga. We will explain the commands that have been added for
+configuring that model. And finally we will show a full example of
+Quagga configured as Route Server.
+
+* Menu:
+
+* Description of the Route Server model::
+* Commands for configuring a Route Server::
+* Example of Route Server Configuration::
+
+\1f
+File: quagga.info, Node: Description of the Route Server model, Next: Commands for configuring a Route Server, Up: Configuring Quagga as a Route Server
+
+12.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
+Figure 12.1: fig:normal-processing, it consists of three steps:
+
+ * When an announcement is received from some peer, the 'In' filters
+ configured for that peer are applied to the announcement. These
+ filters can reject the announcement, accept it unmodified, or
+ accept it with some of its attributes modified.
+
+ * The announcements that pass the 'In' filters go into the Best Path
+ Selection process, where they are compared to other announcements
+ referred to the same destination that have been received from
+ different peers (in case such other announcements exist). For each
+ different destination, the announcement which is selected as the
+ best is inserted into the BGP speaker's Loc-RIB.
+
+ * The routes which are inserted in the Loc-RIB are considered for
+ announcement to all the peers (except the one from which the route
+ came). This is done by passing the routes in the Loc-RIB through
+ the 'Out' filters corresponding to each peer. These filters can
+ reject the route, accept it unmodified, or accept it with some of
+ its attributes modified. Those routes which are accepted by the
+ 'Out' filters of a peer are announced to that peer.
+
+\0\b[image src="fig-normal-processing.png" alt="Normal announcement processing" text="
+ _______________________________
+ / _________ _________ \\
+From Peer A --->|(A)-|Best | | |-[A]|--->To Peer A
+From Peer B --->|(B)-|Path |-->|Local-RIB|-[B]|--->To Peer B
+From Peer C --->|(C)-|Selection| | |-[C]|--->To Peer C
+From Peer D --->|(D)-|_________| |_________|-[D]|--->To Peer D
+ \\_______________________________/
+
+Key: (X) - 'In' Filter applied to Peer X's announcements
+ [X] - 'Out' Filter applied to announcements to Peer X"\0\b]
+
+Figure 12.1: Announcement processing inside a "normal" BGP speaker
+
+ 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 are currently
+supported by most 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 Figure 12.2: fig:rs-processing. The figure shows a mixture of
+RS-clients (B, C and D) with normal BGP peers (A). There are some
+details that worth additional comments:
+
+ * Announcements coming from a normal BGP peer are also considered for
+ the Loc-RIBs of all the RS-clients. But logically they do not pass
+ through any export policy.
+
+ * Those peers that are configured as RS-clients do not receive any
+ announce from the 'Main' Loc-RIB.
+
+ * Apart from import and export policies, 'In' and 'Out' filters can
+ also be set for RS-clients. 'In' filters might be useful when the
+ route server has also normal BGP peers. On the other hand, 'Out'
+ filters for RS-clients are probably unnecessary, but we decided not
+ to remove them as they do not hurt anybody (they can always be left
+ empty).
+
+\0\b[image src="fig-rs-processing.png" alt="Route Server Processing Model" text="From Peer A
+ | From RS-Client B
+ | | From RS-Client C
+ | | | From RS-Client D
+ | | | |
+ | | | | Main / Normal RIB
+ | | | | ________________________________
+ | | | | / _________ _________ \\
+ | | | +--->|(D)-|Best | | Main | |
+ | | +--|--->|(C)-|Path |-->|Local-RIB|->[A]|--->To Peer A
+ | +--|--|--->|(B)-|Selection| | | |
+ +--|--|--|--->|(A)-|_________| |_________| |
+ | | | | \\________________________________/
+ | | | |
+ | | | | ________________________________
+ | | | | / _________ _________ \\
+ | | | +--->*D*->|{B}-|Best | |RS-Client| |
+ | | +--|--->*C*->|{B}-|Path |-->|Local-RIB|->[B]|--->To RS-Client B
+ | | | | | |Selection| | for B | |
+ +--|--|--|-------->|{B}-|_________| |_________| |
+ | | | | \\________________________________/
+ | | | |
+ | | | | ________________________________
+ | | | | / _________ _________ \\
+ | | | +--->*D*->|{C}-|Best | |RS-Client| |
+ | | | | | |Path |-->|Local-RIB|->[C]|--->To RS-Client C
+ | +--|--|--->*B*->|{C}-|Selection| | for C | |
+ +--|--|--|-------->|{C}-|_________| |_________| |
+ | | | \\________________________________/
+ | | |
+ | | | ________________________________
+ | | | / _________ _________ \\
+ | | | | |Best | |RS-Client| |
+ | | +------>*C*->|{D}-|Path |-->|Local-RIB|->[D]|--->To RS-Client D
+ | +--------->*B*->|{D}-|Selection| | for D | |
+ +----------------->|{D}-|_________| |_________| |
+ \\________________________________/
+
+
+Key: (X) - 'In' Filter applied to Peer X's announcements before
+ considering announcement for the normal main Local-RIB
+ [X] - 'Out' Filter applied to announcements to Peer X
+ *X* - 'Export' Filter of RS-Client X, to apply X's policies
+ before its routes may be considered for other RS-Clients
+ RIBs.
+ {X} - 'Import' Filter of RS-Client X, to apply X's policies
+ on routes before allowing them into X's RIB."\0\b]
+
+Figure 12.2: Announcement processing model implemented by the Route
+Server
+
+\1f
+File: quagga.info, Node: Commands for configuring a Route Server, Next: Example of Route Server Configuration, Prev: Description of the Route Server model, Up: Configuring Quagga as a Route Server
+
+12.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 12.2:
+ 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 12.2: fig:rs-processing.).
+
+ -- Route-map Command: call WORD
+ This command (also used inside a route-map) jumps into a different
+ route-map, whose name is specified by WORD. When the called
+ route-map finishes, depending on its result the original route-map
+ continues or not. Apart from being useful for making import/export
+ route-maps easier to write, this command can also be used inside
+ any normal (in or out) route-map.
+
+\1f
+File: quagga.info, Node: Example of Route Server Configuration, Prev: Commands for configuring a Route Server, Up: Configuring Quagga as a Route Server
+
+12.3 Example of Route Server Configuration
+==========================================
+
+Finally we are going to show how to configure a Quagga daemon to act as
+a Route Server. For this purpose we are going to present a scenario
+without route server, and then we will show how to use the
+configurations of the BGP routers to generate the configuration of the
+route server.
+
+ All the configuration files shown in this section have been taken
+from scenarios which were tested using the VNUML tool VNUML
+(http://www.dit.upm.es/vnuml).
+
+* Menu:
+
+* Configuration of the BGP routers without Route Server::
+* Configuration of the BGP routers with Route Server::
+* Configuration of the Route Server itself::
+* Further considerations about Import and Export route-maps::
+
+\1f
+File: quagga.info, Node: Configuration of the BGP routers without Route Server, Next: Configuration of the BGP routers with Route Server, Up: Example of Route Server Configuration
+
+12.3.1 Configuration of the BGP routers without Route Server
+------------------------------------------------------------
+
+We will suppose that our initial scenario is an exchange point with
+three BGP capable routers, named RA, RB and RC. Each of the BGP speakers
+generates some routes (with the NETWORK command), and establishes BGP
+peerings against the other two routers. These peerings have In and Out
+route-maps configured, named like "PEER-X-IN" or "PEER-X-OUT". For
+example the configuration file for router RA could be the following:
+
+ #Configuration for router 'RA'
+ !
+ hostname RA
+ password ****
+ !
+ router bgp 65001
+ no bgp default ipv4-unicast
+ neighbor 2001:0DB8::B remote-as 65002
+ neighbor 2001:0DB8::C remote-as 65003
+ !
+ address-family ipv6
+ network 2001:0DB8:AAAA:1::/64
+ network 2001:0DB8:AAAA:2::/64
+ network 2001:0DB8:0000:1::/64
+ network 2001:0DB8:0000:2::/64
+
+ neighbor 2001:0DB8::B activate
+ neighbor 2001:0DB8::B soft-reconfiguration inbound
+ neighbor 2001:0DB8::B route-map PEER-B-IN in
+ neighbor 2001:0DB8::B route-map PEER-B-OUT out
+
+ neighbor 2001:0DB8::C activate
+ neighbor 2001:0DB8::C soft-reconfiguration inbound
+ neighbor 2001:0DB8::C route-map PEER-C-IN in
+ neighbor 2001:0DB8::C route-map PEER-C-OUT out
+ exit-address-family
+ !
+ ipv6 prefix-list COMMON-PREFIXES seq 5 permit 2001:0DB8:0000::/48 ge 64 le 64
+ ipv6 prefix-list COMMON-PREFIXES seq 10 deny any
+ !
+ ipv6 prefix-list PEER-A-PREFIXES seq 5 permit 2001:0DB8:AAAA::/48 ge 64 le 64
+ ipv6 prefix-list PEER-A-PREFIXES seq 10 deny any
+ !
+ ipv6 prefix-list PEER-B-PREFIXES seq 5 permit 2001:0DB8:BBBB::/48 ge 64 le 64
+ ipv6 prefix-list PEER-B-PREFIXES seq 10 deny any
+ !
+ ipv6 prefix-list PEER-C-PREFIXES seq 5 permit 2001:0DB8:CCCC::/48 ge 64 le 64
+ ipv6 prefix-list PEER-C-PREFIXES seq 10 deny any
+ !
+ route-map PEER-B-IN permit 10
+ match ipv6 address prefix-list COMMON-PREFIXES
+ set metric 100
+ route-map PEER-B-IN permit 20
+ match ipv6 address prefix-list PEER-B-PREFIXES
+ set community 65001:11111
+ !
+ route-map PEER-C-IN permit 10
+ match ipv6 address prefix-list COMMON-PREFIXES
+ set metric 200
+ route-map PEER-C-IN permit 20
+ match ipv6 address prefix-list PEER-C-PREFIXES
+ set community 65001:22222
+ !
+ route-map PEER-B-OUT permit 10
+ match ipv6 address prefix-list PEER-A-PREFIXES
+ !
+ route-map PEER-C-OUT permit 10
+ match ipv6 address prefix-list PEER-A-PREFIXES
+ !
+ line vty
+ !
+
+\1f
+File: quagga.info, Node: Configuration of the BGP routers with Route Server, Next: Configuration of the Route Server itself, Prev: Configuration of the BGP routers without Route Server, Up: Example of Route Server Configuration
+
+12.3.2 Configuration of the BGP routers with Route Server
+---------------------------------------------------------
+
+To convert the initial scenario into one with route server, first we
+must modify the configuration of routers RA, RB and RC. Now they must
+not peer between them, but only with the route server. For example,
+RA's configuration would turn into:
+
+ # Configuration for router 'RA'
+ !
+ hostname RA
+ password ****
+ !
+ router bgp 65001
+ no bgp default ipv4-unicast
+ neighbor 2001:0DB8::FFFF remote-as 65000
+ !
+ address-family ipv6
+ network 2001:0DB8:AAAA:1::/64
+ network 2001:0DB8:AAAA:2::/64
+ network 2001:0DB8:0000:1::/64
+ network 2001:0DB8:0000:2::/64
+
+ neighbor 2001:0DB8::FFFF activate
+ neighbor 2001:0DB8::FFFF soft-reconfiguration inbound
+ exit-address-family
+ !
+ line vty
+ !
+
+ Which is logically much simpler than its initial configuration, as it
+now maintains only one BGP peering and all the filters (route-maps) have
+disappeared.
+
+\1f
+File: quagga.info, Node: Configuration of the Route Server itself, Next: Further considerations about Import and Export route-maps, Prev: Configuration of the BGP routers with Route Server, Up: Example of Route Server Configuration
+
+12.3.3 Configuration of the Route Server itself
+-----------------------------------------------
+
+As we said when we described the functions of a route server (*note
+Description of the Route Server model::), it is in charge of all the
+route filtering. To achieve that, the In and Out filters from the RA,
+RB and RC configurations must be converted into Import and Export
+policies in the route server.
+
+ This is a fragment of the route server configuration (we only show
+the policies for client RA):
+
+ # Configuration for Route Server ('RS')
+ !
+ hostname RS
+ password ix
+ !
+ bgp multiple-instance
+ !
+ router bgp 65000 view RS
+ no bgp default ipv4-unicast
+ neighbor 2001:0DB8::A remote-as 65001
+ neighbor 2001:0DB8::B remote-as 65002
+ neighbor 2001:0DB8::C remote-as 65003
+ !
+ address-family ipv6
+ neighbor 2001:0DB8::A activate
+ neighbor 2001:0DB8::A route-server-client
+ neighbor 2001:0DB8::A route-map RSCLIENT-A-IMPORT import
+ neighbor 2001:0DB8::A route-map RSCLIENT-A-EXPORT export
+ neighbor 2001:0DB8::A soft-reconfiguration inbound
+
+ neighbor 2001:0DB8::B activate
+ neighbor 2001:0DB8::B route-server-client
+ neighbor 2001:0DB8::B route-map RSCLIENT-B-IMPORT import
+ neighbor 2001:0DB8::B route-map RSCLIENT-B-EXPORT export
+ neighbor 2001:0DB8::B soft-reconfiguration inbound
+
+ neighbor 2001:0DB8::C activate
+ neighbor 2001:0DB8::C route-server-client
+ neighbor 2001:0DB8::C route-map RSCLIENT-C-IMPORT import
+ neighbor 2001:0DB8::C route-map RSCLIENT-C-EXPORT export
+ neighbor 2001:0DB8::C soft-reconfiguration inbound
+ exit-address-family
+ !
+ ipv6 prefix-list COMMON-PREFIXES seq 5 permit 2001:0DB8:0000::/48 ge 64 le 64
+ ipv6 prefix-list COMMON-PREFIXES seq 10 deny any
+ !
+ ipv6 prefix-list PEER-A-PREFIXES seq 5 permit 2001:0DB8:AAAA::/48 ge 64 le 64
+ ipv6 prefix-list PEER-A-PREFIXES seq 10 deny any
+ !
+ ipv6 prefix-list PEER-B-PREFIXES seq 5 permit 2001:0DB8:BBBB::/48 ge 64 le 64
+ ipv6 prefix-list PEER-B-PREFIXES seq 10 deny any
+ !
+ ipv6 prefix-list PEER-C-PREFIXES seq 5 permit 2001:0DB8:CCCC::/48 ge 64 le 64
+ ipv6 prefix-list PEER-C-PREFIXES seq 10 deny any
+ !
+ route-map RSCLIENT-A-IMPORT permit 10
+ match peer 2001:0DB8::B
+ call A-IMPORT-FROM-B
+ route-map RSCLIENT-A-IMPORT permit 20
+ match peer 2001:0DB8::C
+ call A-IMPORT-FROM-C
+ !
+ route-map A-IMPORT-FROM-B permit 10
+ match ipv6 address prefix-list COMMON-PREFIXES
+ set metric 100
+ route-map A-IMPORT-FROM-B permit 20
+ match ipv6 address prefix-list PEER-B-PREFIXES
+ set community 65001:11111
+ !
+ route-map A-IMPORT-FROM-C permit 10
+ match ipv6 address prefix-list COMMON-PREFIXES
+ set metric 200
+ route-map A-IMPORT-FROM-C permit 20
+ match ipv6 address prefix-list PEER-C-PREFIXES
+ set community 65001:22222
+ !
+ route-map RSCLIENT-A-EXPORT permit 10
+ match peer 2001:0DB8::B
+ match ipv6 address prefix-list PEER-A-PREFIXES
+ route-map RSCLIENT-A-EXPORT permit 20
+ match peer 2001:0DB8::C
+ match ipv6 address prefix-list PEER-A-PREFIXES
+ !
+ ...
+ ...
+ ...
+
+ If you compare the initial configuration of RA with the route server
+configuration above, you can see how easy it is to generate the Import
+and Export policies for RA from the In and Out route-maps of RA's
+original configuration.
+
+ When there was no route server, RA maintained two peerings, one with
+RB and another with RC. Each of this peerings had an In route-map
+configured. To build the Import route-map for client RA in the route
+server, simply add route-map entries following this scheme:
+
+ route-map <NAME> permit 10
+ match peer <Peer Address>
+ call <In Route-Map for this Peer>
+ route-map <NAME> permit 20
+ match peer <Another Peer Address>
+ call <In Route-Map for this Peer>
+
+ This is exactly the process that has been followed to generate the
+route-map RSCLIENT-A-IMPORT. The route-maps that are called inside it
+(A-IMPORT-FROM-B and A-IMPORT-FROM-C) are exactly the same than the In
+route-maps from the original configuration of RA (PEER-B-IN and
+PEER-C-IN), only the name is different.
+
+ The same could have been done to create the Export policy for RA
+(route-map RSCLIENT-A-EXPORT), but in this case the original Out
+route-maps where so simple that we decided not to use the CALL WORD
+commands, and we integrated all in a single route-map
+(RSCLIENT-A-EXPORT).
+
+ The Import and Export policies for RB and RC are not shown, but the
+process would be identical.
+
+\1f
+File: quagga.info, Node: Further considerations about Import and Export route-maps, Prev: Configuration of the Route Server itself, Up: Example of Route Server Configuration
+
+12.3.4 Further considerations about Import and Export route-maps
+----------------------------------------------------------------
+
+The current version of the route server patch only allows to specify a
+route-map for import and export policies, while in a standard BGP
+speaker apart from route-maps there are other tools for performing input
+and output filtering (access-lists, community-lists, ...). But this
+does not represent any limitation, as all kinds of filters can be
+included in import/export route-maps. For example suppose that in the
+non-route-server scenario peer RA had the following filters configured
+for input from peer B:
+
+ neighbor 2001:0DB8::B prefix-list LIST-1 in
+ neighbor 2001:0DB8::B filter-list LIST-2 in
+ neighbor 2001:0DB8::B route-map PEER-B-IN in
+ ...
+ ...
+ route-map PEER-B-IN permit 10
+ match ipv6 address prefix-list COMMON-PREFIXES
+ set local-preference 100
+ route-map PEER-B-IN permit 20
+ match ipv6 address prefix-list PEER-B-PREFIXES
+ set community 65001:11111
+
+ It is posible to write a single route-map which is equivalent to the
+three filters (the community-list, the prefix-list and the route-map).
+That route-map can then be used inside the Import policy in the route
+server. Lets see how to do it:
+
+ neighbor 2001:0DB8::A route-map RSCLIENT-A-IMPORT import
+ ...
+ !
+ ...
+ route-map RSCLIENT-A-IMPORT permit 10
+ match peer 2001:0DB8::B
+ call A-IMPORT-FROM-B
+ ...
+ ...
+ !
+ route-map A-IMPORT-FROM-B permit 1
+ match ipv6 address prefix-list LIST-1
+ match as-path LIST-2
+ on-match goto 10
+ route-map A-IMPORT-FROM-B deny 2
+ route-map A-IMPORT-FROM-B permit 10
+ match ipv6 address prefix-list COMMON-PREFIXES
+ set local-preference 100
+ route-map A-IMPORT-FROM-B permit 20
+ match ipv6 address prefix-list PEER-B-PREFIXES
+ set community 65001:11111
+ !
+ ...
+ ...
+
+ The route-map A-IMPORT-FROM-B is equivalent to the three filters
+(LIST-1, LIST-2 and PEER-B-IN). The first entry of route-map
+A-IMPORT-FROM-B (sequence number 1) matches if and only if both the
+prefix-list LIST-1 and the filter-list LIST-2 match. If that happens,
+due to the "on-match goto 10" statement the next route-map entry to be
+processed will be number 10, and as of that point route-map
+A-IMPORT-FROM-B is identical to PEER-B-IN. If the first entry does not
+match, 'on-match goto 10" will be ignored and the next processed entry
+will be number 2, which will deny the route.
+
+ Thus, the result is the same that with the three original filters,
+i.e., if either LIST-1 or LIST-2 rejects the route, it does not reach
+the route-map PEER-B-IN. In case both LIST-1 and LIST-2 accept the
+route, it passes to PEER-B-IN, which can reject, accept or modify the
+route.
+
+\1f
+File: quagga.info, Node: VTY shell, Next: Filtering, Prev: Configuring Quagga as a Route Server, Up: Top
+
+13 VTY shell
+************
+
+'vtysh' is integrated shell of Quagga software.
+
+ To use vtysh please specify --enable-vtysh to configure script. To
+use PAM for authentication use --with-libpam option to configure script.
+
+ vtysh only searches /etc/quagga path for vtysh.conf which is the
+vtysh configuration file. Vtysh does not search current directory for
+configuration file because the file includes user authentication
+settings.
+
+ Currently, vtysh.conf has only two commands.
+
+* Menu:
+
+* VTY shell username::
+* VTY shell integrated configuration::
+
+\1f
+File: quagga.info, Node: VTY shell username, Next: VTY shell integrated configuration, Up: VTY shell
+
+13.1 VTY shell username
+=======================
+
+ -- Command: username USERNAME nopassword
+
+ With this set, user foo does not need password authentication for
+ user vtysh. With PAM vtysh uses PAM authentication mechanism.
+
+ If vtysh is compiled without PAM authentication, every user can use
+ vtysh without authentication. vtysh requires read/write permission
+ to the various daemons vty sockets, this can be accomplished
+ through use of unix groups and the -enable-vty-group configure
+ option.
+
+\1f
+File: quagga.info, Node: VTY shell integrated configuration, Prev: VTY shell username, Up: VTY shell
+
+13.2 VTY shell integrated configuration
+=======================================
+
+ -- Command: service integrated-vtysh-config
+ Write out integrated Quagga.conf file when 'write file' is issued.
+
+ This command controls the behaviour of vtysh when it is told to
+ write out the configuration. Per default, vtysh will instruct each
+ daemon to write out their own config files when 'write file' is
+ issued. However, if 'service integrated-vtysh-config' is set, when
+ 'write file' is issued, vtysh will instruct the daemons will write
+ out a Quagga.conf with all daemons' commands integrated into it.
+
+ Vtysh per default behaves as if 'write-conf daemon' is set. Note
+ that both may be set at same time if one wishes to have both
+ Quagga.conf and daemon specific files written out. Further, note
+ that the daemons are hard-coded to first look for the integrated
+ Quagga.conf file before looking for their own file.
+
+ We recommend you do not mix the use of the two types of files.
+ Further, it is better not to use the integrated Quagga.conf file,
+ as any syntax error in it can lead to /all/ of your daemons being
+ unable to start up. Per daemon files are more robust as impact of
+ errors in configuration are limited to the daemon in whose file the
+ error is made.
+
+\1f
+File: quagga.info, Node: Filtering, Next: Route Map, Prev: VTY shell, Up: Top
+
+14 Filtering
+************
+
+Quagga provides many very flexible filtering features. Filtering is
+used for both input and output of the routing information. Once
+filtering is defined, it can be applied in any direction.
+
+* Menu:
+
+* IP Access List::
+* IP Prefix List::
+
+\1f
+File: quagga.info, Node: IP Access List, Next: IP Prefix List, Up: Filtering
+
+14.1 IP Access List
+===================
+
+ -- Command: access-list NAME permit IPV4-NETWORK
+ -- Command: access-list NAME deny IPV4-NETWORK
+
+ Basic filtering is done by 'access-list' as shown in the following
+example.
+
+ access-list filter deny 10.0.0.0/9
+ access-list filter permit 10.0.0.0/8
+
+\1f
+File: quagga.info, Node: IP Prefix List, Prev: IP Access List, Up: Filtering
+
+14.2 IP Prefix List
+===================
+
+'ip prefix-list' provides the most powerful prefix based filtering
+mechanism. In addition to 'access-list' functionality, 'ip prefix-list'
+has prefix length range specification and sequential number
+specification. You can add or delete prefix based filters to arbitrary
+points of prefix-list using sequential number specification.
+
+ If no ip prefix-list is specified, it acts as permit. If 'ip
+prefix-list' is defined, and no match is found, default deny is applied.
+
+ -- Command: ip prefix-list NAME (permit|deny) PREFIX [le LEN] [ge LEN]
+ -- Command: ip prefix-list NAME seq NUMBER (permit|deny) PREFIX [le
+ LEN] [ge LEN]
+
+ You can create 'ip prefix-list' using above commands.
+
+ seq
+ seq NUMBER can be set either automatically or manually. In
+ the case that sequential numbers are set manually, the user
+ may pick any number less than 4294967295. In the case that
+ sequential number are set automatically, the sequential number
+ will increase by a unit of five (5) per list. If a list with
+ no specified sequential number is created after a list with a
+ specified sequential number, the list will automatically pick
+ the next multiple of five (5) as the list number. For
+ example, if a list with number 2 already exists and a new list
+ with no specified number is created, the next list will be
+ numbered 5. If lists 2 and 7 already exist and a new list
+ with no specified number is created, the new list will be
+ numbered 10.
+
+ le
+ 'le' command specifies prefix length. The prefix list will be
+ applied if the prefix length is less than or equal to the le
+ prefix length.
+
+ ge
+ 'ge' command specifies prefix length. The prefix list will be
+ applied if the prefix length is greater than or equal to the
+ ge prefix length.
+
+ Less than or equal to prefix numbers and greater than or equal to
+prefix numbers can be used together. The order of the le and ge
+commands does not matter.
+
+ If a prefix list with a different sequential number but with the
+exact same rules as a previous list is created, an error will result.
+However, in the case that the sequential number and the rules are
+exactly similar, no error will result.
+
+ If a list with the same sequential number as a previous list is
+created, the new list will overwrite the old list.
+
+ Matching of IP Prefix is performed from the smaller sequential number
+to the larger. The matching will stop once any rule has been applied.
+
+ In the case of no le or ge command, the prefix length must match
+exactly the length specified in the prefix list.
+
+ -- Command: no ip prefix-list NAME
+
+* Menu:
+
+* ip prefix-list description::
+* ip prefix-list sequential number control::
+* Showing ip prefix-list::
+* Clear counter of ip prefix-list::
+
+\1f
+File: quagga.info, Node: ip prefix-list description, Next: ip prefix-list sequential number control, Up: IP Prefix List
+
+14.2.1 ip prefix-list description
+---------------------------------
+
+ -- Command: ip prefix-list NAME description DESC
+ Descriptions may be added to prefix lists. This command adds a
+ description to the prefix list.
+
+ -- Command: no ip prefix-list NAME description [DESC]
+ Deletes the description from a prefix list. It is possible to use
+ the command without the full description.
+
+\1f
+File: quagga.info, Node: ip prefix-list sequential number control, Next: Showing ip prefix-list, Prev: ip prefix-list description, Up: IP Prefix List
+
+14.2.2 ip prefix-list sequential number control
+-----------------------------------------------
+
+ -- Command: ip prefix-list sequence-number
+ With this command, the IP prefix list sequential number is
+ displayed. This is the default behavior.
+
+ -- Command: no ip prefix-list sequence-number
+ With this command, the IP prefix list sequential number is not
+ displayed.
+
+\1f
+File: quagga.info, Node: Showing ip prefix-list, Next: Clear counter of ip prefix-list, Prev: ip prefix-list sequential number control, Up: IP Prefix List
+
+14.2.3 Showing ip prefix-list
+-----------------------------
+
+ -- Command: show ip prefix-list
+ Display all IP prefix lists.
+
+ -- Command: show ip prefix-list NAME
+ Show IP prefix list can be used with a prefix list name.
+
+ -- Command: show ip prefix-list NAME seq NUM
+ Show IP prefix list can be used with a prefix list name and
+ sequential number.
+
+ -- Command: show ip prefix-list NAME A.B.C.D/M
+ If the command longer is used, all prefix lists with prefix lengths
+ equal to or longer than the specified length will be displayed. If
+ the command first match is used, the first prefix length match will
+ be displayed.
+
+ -- Command: show ip prefix-list NAME A.B.C.D/M longer
+
+ -- Command: show ip prefix-list NAME A.B.C.D/M first-match
+
+ -- Command: show ip prefix-list summary
+ -- Command: show ip prefix-list summary NAME
+
+ -- Command: show ip prefix-list detail
+ -- Command: show ip prefix-list detail NAME
+
+\1f
+File: quagga.info, Node: Clear counter of ip prefix-list, Prev: Showing ip prefix-list, Up: IP Prefix List
+
+14.2.4 Clear counter of ip prefix-list
+--------------------------------------
+
+ -- Command: clear ip prefix-list
+ Clears the counters of all IP prefix lists. Clear IP Prefix List
+ can be used with a specified name and prefix.
+
+ -- Command: clear ip prefix-list NAME
+
+ -- Command: clear ip prefix-list NAME A.B.C.D/M
+
+\1f
+File: quagga.info, Node: Route Map, Next: IPv6 Support, Prev: Filtering, Up: Top
+
+15 Route Map
+************
+
+Route maps provide a means to both filter and/or apply actions to route,
+hence allowing policy to be applied to routes.
+
+* Menu:
+
+* Route Map Command::
+* Route Map Match Command::
+* Route Map Set Command::
+* Route Map Call Command::
+* Route Map Exit Action Command::
+* Route Map Examples::
+
+ Route-maps are an ordered list of route-map entries. Each entry may
+specify up to four distincts sets of clauses:
+
+'Matching Policy'
+
+ This specifies the policy implied if the 'Matching Conditions' are
+ met or not met, and which actions of the route-map are to be taken,
+ if any. The two possibilities are:
+
+ - 'permit': If the entry matches, then carry out the 'Set
+ Actions'. Then finish processing the route-map, permitting
+ the route, unless an 'Exit Action' indicates otherwise.
+
+ - 'deny': If the entry matches, then finish processing the
+ route-map and deny the route (return 'deny').
+
+ The 'Matching Policy' is specified as part of the command which
+ defines the ordered entry in the route-map. See below.
+
+'Matching Conditions'
+
+ A route-map entry may, optionally, specify one or more conditions
+ which must be matched if the entry is to be considered further, as
+ governed by the Match Policy. If a route-map entry does not
+ explicitely specify any matching conditions, then it always
+ matches.
+
+'Set Actions'
+
+ A route-map entry may, optionally, specify one or more 'Set
+ Actions' to set or modify attributes of the route.
+
+'Call Action'
+
+ Call to another route-map, after any 'Set Actions' have been
+ carried out. If the route-map called returns 'deny' then
+ processing of the route-map finishes and the route is denied,
+ regardless of the 'Matching Policy' or the 'Exit Policy'. If the
+ called route-map returns 'permit', then 'Matching Policy' and 'Exit
+ Policy' govern further behaviour, as normal.
+
+'Exit Policy'
+
+ An entry may, optionally, specify an alternative 'Exit Policy' to
+ take if the entry matched, rather than the normal policy of exiting
+ the route-map and permitting the route. The two possibilities are:
+
+ - 'next': Continue on with processing of the route-map entries.
+
+ - 'goto N': Jump ahead to the first route-map entry whose order
+ in the route-map is >= N. Jumping to a previous entry is not
+ permitted.
+
+ The default action of a route-map, if no entries match, is to deny.
+I.e. a route-map essentially has as its last entry an empty 'deny'
+entry, which matches all routes. To change this behaviour, one must
+specify an empty 'permit' entry as the last entry in the route-map.
+
+ To summarise the above:
+
+ Match No Match
+-----------------------------
+_Permit_ action cont
+_Deny_ deny cont
+
+'action'
+ - Apply _set_ statements
+
+ - If _call_ is present, call given route-map. If that returns a
+ 'deny', finish processing and return 'deny'.
+
+ - If 'Exit Policy' is _next_, goto next route-map entry
+
+ - If 'Exit Policy' is _goto_, goto first entry whose order in
+ the list is >= the given order.
+
+ - Finish processing the route-map and permit the route.
+
+'deny'
+ - The route is denied by the route-map (return 'deny').
+
+'cont'
+ - goto next route-map entry
+
+\1f
+File: quagga.info, Node: Route Map Command, Next: Route Map Match Command, Up: Route Map
+
+15.1 Route Map Command
+======================
+
+ -- Command: route-map ROUTE-MAP-NAME (permit|deny) ORDER
+
+ Configure the ORDER'th entry in ROUTE-MAP-NAME with 'Match Policy'
+ of either _permit_ or _deny_.
+
+\1f
+File: quagga.info, Node: Route Map Match Command, Next: Route Map Set Command, Prev: Route Map Command, Up: Route Map
+
+15.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 as-path AS_PATH
+ Matches the specified AS_PATH.
+
+ -- Route-map Command: match metric METRIC
+ Matches the specified METRIC.
+
+ -- Route-map Command: match local-preference METRIC
+ Matches the specified LOCAL-PREFERENCE.
+
+ -- Route-map Command: match community COMMUNITY_LIST
+ Matches the specified COMMUNITY_LIST
+
+\1f
+File: quagga.info, Node: Route Map Set Command, Next: Route Map Call Command, Prev: Route Map Match Command, Up: Route Map
+
+15.3 Route Map Set Command
+==========================
+
+ -- Route-map Command: set ip next-hop IPV4_ADDRESS
+ Set the BGP nexthop address.
+
+ -- Route-map Command: set local-preference LOCAL_PREF
+ Set the BGP local preference.
+
+ -- Route-map Command: set weight WEIGHT
+ Set the route's weight.
+
+ -- Route-map Command: set metric METRIC
+ Set the BGP attribute MED.
+
+ -- Route-map Command: set as-path prepend AS_PATH
+ Set the BGP AS path to prepend.
+
+ -- Route-map Command: set community COMMUNITY
+ Set the BGP community attribute.
+
+ -- Route-map Command: set ipv6 next-hop global IPV6_ADDRESS
+ Set the BGP-4+ global IPv6 nexthop address.
+
+ -- Route-map Command: set ipv6 next-hop local IPV6_ADDRESS
+ Set the BGP-4+ link local IPv6 nexthop address.
+
+\1f
+File: quagga.info, Node: Route Map Call Command, Next: Route Map Exit Action Command, Prev: Route Map Set Command, Up: Route Map
+
+15.4 Route Map Call Command
+===========================
+
+ -- Route-map Command: call NAME
+ Call route-map NAME. If it returns deny, deny the route and finish
+ processing the route-map.
+
+\1f
+File: quagga.info, Node: Route Map Exit Action Command, Next: Route Map Examples, Prev: Route Map Call Command, Up: Route Map
+
+15.5 Route Map Exit Action Command
+==================================
+
+ -- Route-map Command: on-match next
+ -- Route-map Command: continue
+ Proceed on to the next entry in the route-map.
+
+ -- Route-map Command: on-match goto N
+ -- Route-map Command: continue N
+ Proceed processing the route-map at the first entry whose order is
+ >= N
+
+\1f
+File: quagga.info, Node: Route Map Examples, Prev: Route Map Exit Action Command, Up: Route Map
+
+15.6 Route Map Examples
+=======================
+
+A simple example of 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.
+
+ See *note BGP Configuration Examples:: for examples of more
+sophisticated useage of route-maps, including of the 'call' action.
+
+\1f
+File: quagga.info, Node: IPv6 Support, Next: Kernel Interface, Prev: Route Map, Up: Top
+
+16 IPv6 Support
+***************
+
+Quagga fully supports IPv6 routing. As described so far, Quagga
+supports RIPng, OSPFv3, and BGP-4+. You can give IPv6 addresses to an
+interface and configure static IPv6 routing information. Quagga IPv6
+also provides automatic address configuration via a feature called
+'address auto configuration'. To do it, the router must send router
+advertisement messages to the all nodes that exist on the network.
+
+* Menu:
+
+* Router Advertisement::
+
+\1f
+File: quagga.info, Node: Router Advertisement, Up: IPv6 Support
+
+16.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-autoconfig]
+ [router-address]
+ 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.
+
+ * ROUTER-ADDRESS - indicates to hosts on the local link that the
+ specified prefix contains a complete IP address by setting R
+ flag.
+
+ Default: not set, i.e. hosts do not assume a complete IP
+ address is placed.
+
+ -- Interface Command: ipv6 nd ra-interval <1-1800>
+ -- Interface Command: no ipv6 nd ra-interval [<1-1800>]
+ The maximum time allowed between sending unsolicited multicast
+ router advertisements from the interface, in seconds.
+
+ Default: '600'
+
+ -- Interface Command: ipv6 nd ra-interval msec <70-1800000>
+ -- Interface Command: no ipv6 nd ra-interval [msec <70-1800000>]
+ The maximum time allowed between sending unsolicited multicast
+ router advertisements from the interface, in milliseconds.
+
+ Default: '600000'
+
+ -- Interface Command: ipv6 nd ra-lifetime <0-9000>
+ -- Interface Command: no ipv6 nd ra-lifetime [<0-9000>]
+ 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 <1-3600000>
+ -- Interface Command: no ipv6 nd reachable-time [<1-3600000>]
+ 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).
+
+ 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 Command: ipv6 nd home-agent-config-flag
+ -- Interface Command: no ipv6 nd home-agent-config-flag
+ Set/unset flag in IPv6 router advertisements which indicates to
+ hosts that the router acts as a Home Agent and includes a Home
+ Agent Option.
+
+ Default: not set
+
+ -- Interface Command: ipv6 nd home-agent-preference <0-65535>
+ -- Interface Command: no ipv6 nd home-agent-preference [<0-65535>]
+ The value to be placed in Home Agent Option, when Home Agent config
+ flag is set, which indicates to hosts Home Agent preference. The
+ default value of 0 stands for the lowest preference possible.
+
+ Default: 0
+
+ -- Interface Command: ipv6 nd home-agent-lifetime <0-65520>
+ -- Interface Command: no ipv6 nd home-agent-lifetime [<0-65520>]
+ The value to be placed in Home Agent Option, when Home Agent config
+ flag is set, which indicates to hosts Home Agent Lifetime. The
+ default value of 0 means to place the current Router Lifetime
+ value.
+
+ Default: 0
+
+ -- Interface Command: ipv6 nd adv-interval-option
+ -- Interface Command: no ipv6 nd adv-interval-option
+ Include an Advertisement Interval option which indicates to hosts
+ the maximum time, in milliseconds, between successive unsolicited
+ Router Advertisements.
+
+ Default: not set
+
+ -- Interface Command: ipv6 nd router-preference (high|medium|low)
+ -- Interface Command: no ipv6 nd router-preference [(high|medium|low)]
+ Set default router preference in IPv6 router advertisements per
+ RFC4191.
+
+ Default: medium
+
+ -- Interface Command: ipv6 nd mtu <1-65535>
+ -- Interface Command: no ipv6 nd mtu [<1-65535>]
+ Include an MTU (type 5) option in each RA packet to assist the
+ attached hosts in proper interface configuration. The announced
+ value is not verified to be consistent with router interface MTU.
+
+ Default: don't advertise any MTU option
+
+ interface eth0
+ no ipv6 nd suppress-ra
+ ipv6 nd prefix 2001:0DB8:5009::/64
+
+ For more information see 'RFC2462 (IPv6 Stateless Address
+Autoconfiguration)' , 'RFC4861 (Neighbor Discovery for IP Version 6
+(IPv6))' , 'RFC6275 (Mobility Support in IPv6)' and 'RFC4191 (Default
+Router Preferences and More-Specific Routes)'.
+
+\1f
+File: quagga.info, Node: Kernel Interface, Next: SNMP Support, Prev: IPv6 Support, Up: Top
+
+17 Kernel Interface
+*******************
+
+There are several different methods for reading kernel routing table
+information, updating kernel routing tables, and for looking up
+interfaces.
+
+'ioctl'
+ The 'ioctl' method is a very traditional way for reading or writing
+ kernel information. 'ioctl' can be used for looking up interfaces
+ and for modifying interface addresses, flags, mtu settings and
+ other types of information. Also, 'ioctl' can insert and delete
+ kernel routing table entries. It will soon be available on almost
+ any platform which zebra supports, but it is a little bit ugly thus
+ far, so if a better method is supported by the kernel, zebra will
+ use that.
+
+'sysctl'
+ 'sysctl' can lookup kernel information using MIB (Management
+ Information Base) syntax. Normally, it only provides a way of
+ getting information from the kernel. So one would usually want to
+ change kernel information using another method such as 'ioctl'.
+
+'proc filesystem'
+ 'proc filesystem' provides an easy way of getting kernel
+ information.
+
+'routing socket'
+
+'netlink'
+ On recent Linux kernels (2.0.x and 2.2.x), there is a kernel/user
+ communication support called 'netlink'. It makes asynchronous
+ communication between kernel and Quagga possible, similar to a
+ routing socket on BSD systems.
+
+ Before you use this feature, be sure to select (in kernel
+ configuration) the kernel/netlink support option 'Kernel/User
+ network link driver' and 'Routing messages'.
+
+ Today, the /dev/route special device file is obsolete. Netlink
+ communication is done by reading/writing over netlink socket.
+
+ After the kernel configuration, please reconfigure and rebuild
+ Quagga. You can use netlink as a dynamic routing update channel
+ between Quagga and the kernel.
+
+\1f
+File: quagga.info, Node: SNMP Support, Next: Zebra Protocol, Prev: Kernel Interface, Up: Top
+
+18 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') or
+the AgentX protocol ('RFC2741') and make the routing protocol MIBs
+available through it.
+
+* Menu:
+
+* Getting and installing an SNMP agent::
+* AgentX configuration::
+* SMUX configuration::
+* MIB and command reference::
+* Handling SNMP Traps::
+
+\1f
+File: quagga.info, Node: Getting and installing an SNMP agent, Next: AgentX configuration, Up: SNMP Support
+
+18.1 Getting and installing an SNMP agent
+=========================================
+
+There are several SNMP agent which support SMUX or AgentX. 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=agentx' to be able to accept connections from Quagga
+using AgentX protocol or with '--with-mib-modules=smux' to use SMUX
+protocol.
+
+ Nowadays, SMUX is a legacy protocol. The AgentX protocol should be
+preferred for any new deployment. Both protocols have the same
+coverage.
+
+\1f
+File: quagga.info, Node: AgentX configuration, Next: SMUX configuration, Prev: Getting and installing an SNMP agent, Up: SNMP Support
+
+18.2 AgentX configuration
+=========================
+
+To enable AgentX protocol support, Quagga must have been build with the
+'--enable-snmp' or '--enable-snmp=agentx' option. Both the master SNMP
+agent (snmpd) and each of the Quagga daemons must be configured. In
+'/etc/snmp/snmpd.conf', 'master agentx' directive should be added. In
+each of the Quagga daemons, 'agentx' command will enable AgentX support.
+
+ /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
+ #
+ # enable master agent for AgentX subagents
+ #
+ master agentx
+
+ /etc/quagga/ospfd.conf:
+ ! ... the rest of ospfd.conf has been omitted for clarity ...
+ !
+ agentx
+ !
+
+ Upon successful connection, you should get something like this in the
+log of each Quagga daemons:
+
+ 2012/05/25 11:39:08 ZEBRA: snmp[info]: NET-SNMP version 5.4.3 AgentX subagent connected
+
+ Then, you can use the following command to check everything works as
+expected:
+
+ # snmpwalk -c public -v1 localhost .1.3.6.1.2.1.14.1.1
+ OSPF-MIB::ospfRouterId.0 = IpAddress: 192.168.42.109
+ [...]
+
+ The AgentX protocol can be transported over a Unix socket or using
+TCP or UDP. It usually defaults to a Unix socket and depends on how
+NetSNMP was built. If need to configure Quagga to use another
+transport, you can configure it through '/etc/snmp/quagga.conf':
+
+ /etc/snmp/quagga.conf:
+ [snmpd]
+ # Use a remote master agent
+ agentXSocket tcp:192.168.15.12:705
+
+\1f
+File: quagga.info, Node: SMUX configuration, Next: MIB and command reference, Prev: AgentX configuration, Up: SNMP Support
+
+18.3 SMUX configuration
+=======================
+
+To enable SMUX protocol support, Quagga must have been build with the
+'--enable-snmp=smux' option.
+
+ A separate connection has then to be established 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'.
+
projects / quagga-debian.git / blobdiff