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