embedaddon/quagga/doc/quagga.info-1 - view

File: [ELWIX - Embedded LightWeight unIX -] / embedaddon / quagga / doc / quagga.info-1
Revision 1.1.1.3 (vendor branch): download - view: text, annotated - select for diffs - revision graph
Tue Oct 9 09:22:28 2012 UTC (11 years, 9 months ago) by misho
Branches: quagga, MAIN
CVS tags: v0_99_21, HEAD

quagga

1: This is quagga.info, produced by makeinfo version 4.13 from quagga.texi. 2: 3: Copyright (C) 1999-2005 Kunihiro Ishiguro, et al. 4: 5: Permission is granted to make and distribute verbatim copies of 6: this manual provided the copyright notice and this permission 7: notice are preserved on all copies. 8: 9: Permission is granted to copy and distribute modified versions of 10: this manual under the conditions for verbatim copying, provided 11: that the entire resulting derived work is distributed under the 12: terms of a permission notice identical to this one. 13: 14: Permission is granted to copy and distribute translations of this 15: manual into another language, under the above conditions for 16: modified versions, except that this permission notice may be 17: stated in a translation approved by Kunihiro Ishiguro. 18: 19: INFO-DIR-SECTION Routing Software: 20: START-INFO-DIR-ENTRY 21: * Quagga: (quagga). The Quagga Software Routing Suite 22: END-INFO-DIR-ENTRY 23: 24: This file documents the Quagga Software Routing Suite which manages 25: common TCP/IP routing protocols. 26: 27: This is Edition 0.99.21, last updated 4 April 2012 of `The Quagga 28: Manual', for Quagga Version 0.99.21. 29: 30: Copyright (C) 1999-2005 Kunihiro Ishiguro, et al. 31: 32: Permission is granted to make and distribute verbatim copies of 33: this manual provided the copyright notice and this permission 34: notice are preserved on all copies. 35: 36: Permission is granted to copy and distribute modified versions of 37: this manual under the conditions for verbatim copying, provided 38: that the entire resulting derived work is distributed under the 39: terms of a permission notice identical to this one. 40: 41: Permission is granted to copy and distribute translations of this 42: manual into another language, under the above conditions for 43: modified versions, except that this permission notice may be 44: stated in a translation approved by Kunihiro Ishiguro. 45: 46: 47: File: quagga.info, Node: Top, Next: Overview, Up: (dir) 48: 49: Quagga 50: ****** 51: 52: Quagga is an advanced routing software package that provides a suite of 53: TCP/IP based routing protocols. This is the Manual for Quagga 0.99.21. 54: Quagga is a fork of GNU Zebra. 55: 56: Copyright (C) 1999-2005 Kunihiro Ishiguro, et al. 57: 58: Permission is granted to make and distribute verbatim copies of 59: this manual provided the copyright notice and this permission 60: notice are preserved on all copies. 61: 62: Permission is granted to copy and distribute modified versions of 63: this manual under the conditions for verbatim copying, provided 64: that the entire resulting derived work is distributed under the 65: terms of a permission notice identical to this one. 66: 67: Permission is granted to copy and distribute translations of this 68: manual into another language, under the above conditions for 69: modified versions, except that this permission notice may be 70: stated in a translation approved by Kunihiro Ishiguro. 71: 72: * Menu: 73: 74: * Overview:: 75: * Installation:: 76: * Basic commands:: 77: * Zebra:: 78: * RIP:: 79: * RIPng:: 80: * OSPFv2:: 81: * OSPFv3:: 82: * Babel:: 83: * BGP:: 84: * Configuring Quagga as a Route Server:: 85: * VTY shell:: 86: * Filtering:: 87: * Route Map:: 88: * IPv6 Support:: 89: * Kernel Interface:: 90: * SNMP Support:: 91: * Zebra Protocol:: 92: * Packet Binary Dump Format:: 93: * Command Index:: 94: * VTY Key Index:: 95: * Index:: 96: 97: 98: File: quagga.info, Node: Overview, Next: Installation, Prev: Top, Up: Top 99: 100: 1 Overview 101: ********** 102: 103: Quagga is a routing software package that provides TCP/IP based routing 104: services with routing protocols support such as RIPv1, RIPv2, RIPng, 105: OSPFv2, OSPFv3, BGP-4, and BGP-4+ (*note Supported RFCs::). Quagga also 106: supports special BGP Route Reflector and Route Server behavior. In 107: addition to traditional IPv4 routing protocols, Quagga also supports 108: IPv6 routing protocols. With SNMP daemon which supports SMUX protocol, 109: Quagga provides routing protocol MIBs (*note SNMP Support::). 110: 111: Quagga uses an advanced software architecture to provide you with a 112: high quality, multi server routing engine. Quagga has an interactive 113: user interface for each routing protocol and supports common client 114: commands. Due to this design, you can add new protocol daemons to 115: Quagga easily. You can use Quagga library as your program's client 116: user interface. 117: 118: Quagga is distributed under the GNU General Public License. 119: 120: * Menu: 121: 122: * About Quagga:: Basic information about Quagga 123: * System Architecture:: The Quagga system architecture 124: * Supported Platforms:: Supported platforms and future plans 125: * Supported RFCs:: Supported RFCs 126: * How to get Quagga:: 127: * Mailing List:: Mailing list information 128: * Bug Reports:: Mail address for bug data 129: 130: 131: File: quagga.info, Node: About Quagga, Next: System Architecture, Up: Overview 132: 133: 1.1 About Quagga 134: ================ 135: 136: Today, TCP/IP networks are covering all of the world. The Internet has 137: been deployed in many countries, companies, and to the home. When you 138: connect to the Internet your packet will pass many routers which have 139: TCP/IP routing functionality. 140: 141: A system with Quagga installed acts as a dedicated router. With 142: Quagga, your machine exchanges routing information with other routers 143: using routing protocols. Quagga uses this information to update the 144: kernel routing table so that the right data goes to the right place. 145: You can dynamically change the configuration and you may view routing 146: table information from the Quagga terminal interface. 147: 148: Adding to routing protocol support, Quagga can setup interface's 149: flags, interface's address, static routes and so on. If you have a 150: small network, or a stub network, or xDSL connection, configuring the 151: Quagga routing software is very easy. The only thing you have to do is 152: to set up the interfaces and put a few commands about static routes 153: and/or default routes. If the network is rather large, or if the 154: network structure changes frequently, you will want to take advantage 155: of Quagga's dynamic routing protocol support for protocols such as RIP, 156: OSPF or BGP. 157: 158: Traditionally, UNIX based router configuration is done by `ifconfig' 159: and `route' commands. Status of routing table is displayed by 160: `netstat' utility. Almost of these commands work only if the user has 161: root privileges. Quagga has a different system administration method. 162: There are two user modes in Quagga. One is normal mode, the other is 163: enable mode. Normal mode user can only view system status, enable mode 164: user can change system configuration. This UNIX account independent 165: feature will be great help to the router administrator. 166: 167: Currently, Quagga supports common unicast routing protocols. 168: Multicast routing protocols such as BGMP, PIM-SM, PIM-DM may be 169: supported in Quagga 2.0. MPLS support is going on. In the future, 170: TCP/IP filtering control, QoS control, diffserv configuration will be 171: added to Quagga. Quagga project's final goal is making a productive, 172: quality, free TCP/IP routing software. 173: 174: 175: File: quagga.info, Node: System Architecture, Next: Supported Platforms, Prev: About Quagga, Up: Overview 176: 177: 1.2 System Architecture 178: ======================= 179: 180: Traditional routing software is made as a one process program which 181: provides all of the routing protocol functionalities. Quagga takes a 182: different approach. It is made from a collection of several daemons 183: that work together to build the routing table. There may be several 184: protocol-specific routing daemons and zebra the kernel routing manager. 185: 186: The `ripd' daemon handles the RIP protocol, while `ospfd' is a 187: daemon which supports OSPF version 2. `bgpd' supports the BGP-4 188: protocol. For changing the kernel routing table and for redistribution 189: of routes between different routing protocols, there is a kernel 190: routing table manager `zebra' daemon. It is easy to add a new routing 191: protocol daemons to the entire routing system without affecting any 192: other software. You need to run only the protocol daemon associated 193: with routing protocols in use. Thus, user may run a specific daemon 194: and send routing reports to a central routing console. 195: 196: There is no need for these daemons to be running on the same 197: machine. You can even run several same protocol daemons on the same 198: machine. This architecture creates new possibilities for the routing 199: system. 200: 201: +----+ +----+ +-----+ +-----+ 202: |bgpd| |ripd| |ospfd| |zebra| 203: +----+ +----+ +-----+ +-----+ 204: | 205: +---------------------------|--+ 206: | v | 207: | UNIX Kernel routing table | 208: | | 209: +------------------------------+ 210: 211: Quagga System Architecture 212: 213: Multi-process architecture brings extensibility, modularity and 214: maintainability. At the same time it also brings many configuration 215: files and terminal interfaces. Each daemon has it's own configuration 216: file and terminal interface. When you configure a static route, it 217: must be done in `zebra' configuration file. When you configure BGP 218: network it must be done in `bgpd' configuration file. This can be a 219: very annoying thing. To resolve the problem, Quagga provides 220: integrated user interface shell called `vtysh'. `vtysh' connects to 221: each daemon with UNIX domain socket and then works as a proxy for user 222: input. 223: 224: Quagga was planned to use multi-threaded mechanism when it runs with 225: a kernel that supports multi-threads. But at the moment, the thread 226: library which comes with GNU/Linux or FreeBSD has some problems with 227: running reliable services such as routing software, so we don't use 228: threads at all. Instead we use the `select(2)' system call for 229: multiplexing the events. 230: 231: 232: File: quagga.info, Node: Supported Platforms, Next: Supported RFCs, Prev: System Architecture, Up: Overview 233: 234: 1.3 Supported Platforms 235: ======================= 236: 237: Currently Quagga supports GNU/Linux, BSD and Solaris. Porting Quagga to 238: other platforms is not too difficult as platform dependent code should 239: most be limited to the `zebra' daemon. Protocol daemons are mostly 240: platform independent. Please let us know when you find out Quagga runs 241: on a platform which is not listed below. 242: 243: The list of officially supported platforms are listed below. Note 244: that Quagga may run correctly on other platforms, and may run with 245: partial functionality on further platforms. 246: 247: 248: * GNU/Linux 2.4.x and higher 249: 250: * FreeBSD 4.x and higher 251: 252: * NetBSD 1.6 and higher 253: 254: * OpenBSD 2.5 and higher 255: 256: * Solaris 8 and higher 257: 258: 259: File: quagga.info, Node: Supported RFCs, Next: How to get Quagga, Prev: Supported Platforms, Up: Overview 260: 261: 1.4 Supported RFCs 262: ================== 263: 264: Below is the list of currently supported RFC's. 265: 266: RFC1058 267: `Routing Information Protocol. C.L. Hedrick. Jun-01-1988.' 268: 269: RF2082 270: `RIP-2 MD5 Authentication. F. Baker, R. Atkinson. January 1997.' 271: 272: RFC2453 273: `RIP Version 2. G. Malkin. November 1998.' 274: 275: RFC2080 276: `RIPng for IPv6. G. Malkin, R. Minnear. January 1997.' 277: 278: RFC2328 279: `OSPF Version 2. J. Moy. April 1998.' 280: 281: RFC2370 282: `The OSPF Opaque LSA Option R. Coltun. July 1998.' 283: 284: RFC3101 285: `The OSPF Not-So-Stubby Area (NSSA) Option P. Murphy. January 286: 2003.' 287: 288: RFC2740 289: `OSPF for IPv6. R. Coltun, D. Ferguson, J. Moy. December 1999.' 290: 291: RFC1771 292: `A Border Gateway Protocol 4 (BGP-4). Y. Rekhter & T. Li. March 293: 1995.' 294: 295: RFC1965 296: `Autonomous System Confederations for BGP. P. Traina. June 1996.' 297: 298: RFC1997 299: `BGP Communities Attribute. R. Chandra, P. Traina & T. Li. August 300: 1996.' 301: 302: RFC2545 303: `Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain 304: Routing. P. Marques, F. Dupont. March 1999.' 305: 306: RFC2796 307: `BGP Route Reflection An alternative to full mesh IBGP. T. Bates & 308: R. Chandrasekeran. June 1996.' 309: 310: RFC2858 311: `Multiprotocol Extensions for BGP-4. T. Bates, Y. Rekhter, R. 312: Chandra, D. Katz. June 2000.' 313: 314: RFC2842 315: `Capabilities Advertisement with BGP-4. R. Chandra, J. Scudder. 316: May 2000.' 317: 318: RFC3137 319: `OSPF Stub Router Advertisement, A. Retana, L. Nguyen, R. White, 320: A. Zinin, D. McPherson. June 2001' 321: 322: When SNMP support is enabled, below RFC is also supported. 323: 324: RFC1227 325: `SNMP MUX protocol and MIB. M.T. Rose. May-01-1991.' 326: 327: RFC1657 328: `Definitions of Managed Objects for the Fourth Version of the 329: Border Gateway Protocol (BGP-4) using SMIv2. S. Willis, J. Burruss, 330: J. Chu, Editor. July 1994.' 331: 332: RFC1724 333: `RIP Version 2 MIB Extension. G. Malkin & F. Baker. November 1994.' 334: 335: RFC1850 336: `OSPF Version 2 Management Information Base. F. Baker, R. Coltun. 337: November 1995.' 338: 339: 340: 341: File: quagga.info, Node: How to get Quagga, Next: Mailing List, Prev: Supported RFCs, Up: Overview 342: 343: 1.5 How to get Quagga 344: ===================== 345: 346: The official Quagga web-site is located at: 347: 348: `http://www.quagga.net/' 349: 350: and contains further information, as well as links to additional 351: resources. 352: 353: Quagga (http://www.quagga.net/) is a fork of GNU Zebra, whose 354: web-site is located at: 355: 356: `http://www.zebra.org/'. 357: 358: 359: File: quagga.info, Node: Mailing List, Next: Bug Reports, Prev: How to get Quagga, Up: Overview 360: 361: 1.6 Mailing List 362: ================ 363: 364: There is a mailing list for discussions about Quagga. If you have any 365: comments or suggestions to Quagga, please subscribe to: 366: 367: `http://lists.quagga.net/mailman/listinfo/quagga-users'. 368: 369: The Quagga site has further information on the available mailing 370: lists, see: 371: 372: `http://www.quagga.net/lists.php' 373: 374: 375: File: quagga.info, Node: Bug Reports, Prev: Mailing List, Up: Overview 376: 377: 1.7 Bug Reports 378: =============== 379: 380: If you think you have found a bug, please send a bug report to: 381: 382: `http://bugzilla.quagga.net' 383: 384: When you send a bug report, please be careful about the points below. 385: 386: * Please note what kind of OS you are using. If you use the IPv6 387: stack please note that as well. 388: 389: * Please show us the results of `netstat -rn' and `ifconfig -a'. 390: Information from zebra's VTY command `show ip route' will also be 391: helpful. 392: 393: * Please send your configuration file with the report. If you 394: specify arguments to the configure script please note that too. 395: 396: Bug reports are very important for us to improve the quality of 397: Quagga. Quagga is still in the development stage, but please don't 398: hesitate to send a bug report to `http://bugzilla.quagga.net'. 399: 400: 401: File: quagga.info, Node: Installation, Next: Basic commands, Prev: Overview, Up: Top 402: 403: 2 Installation 404: ************** 405: 406: There are three steps for installing the software: configuration, 407: compilation, and installation. 408: 409: * Menu: 410: 411: * Configure the Software:: 412: * Build the Software:: 413: * Install the Software:: 414: 415: The easiest way to get Quagga running is to issue the following 416: commands: 417: 418: % configure 419: % make 420: % make install 421: 422: 423: File: quagga.info, Node: Configure the Software, Next: Build the Software, Up: Installation 424: 425: 2.1 Configure the Software 426: ========================== 427: 428: * Menu: 429: 430: * The Configure script and its options:: 431: * Least-Privilege support:: 432: * Linux notes:: 433: 434: 435: File: quagga.info, Node: The Configure script and its options, Next: Least-Privilege support, Up: Configure the Software 436: 437: 2.1.1 The Configure script and its options 438: ------------------------------------------ 439: 440: Quagga has an excellent configure script which automatically detects 441: most host configurations. There are several additional configure 442: options you can use to turn off IPv6 support, to disable the 443: compilation of specific daemons, and to enable SNMP support. 444: 445: `--enable-guile' 446: Turn on compilation of the zebra-guile interpreter. You will need 447: the guile library to make this. zebra-guile implementation is not 448: yet finished. So this option is only useful for zebra-guile 449: developers. 450: 451: `--disable-ipv6' 452: Turn off IPv6 related features and daemons. Quagga configure 453: script automatically detects IPv6 stack. But sometimes you might 454: want to disable IPv6 support of Quagga. 455: 456: `--disable-zebra' 457: Do not build zebra daemon. 458: 459: `--disable-ripd' 460: Do not build ripd. 461: 462: `--disable-ripngd' 463: Do not build ripngd. 464: 465: `--disable-ospfd' 466: Do not build ospfd. 467: 468: `--disable-ospf6d' 469: Do not build ospf6d. 470: 471: `--disable-bgpd' 472: Do not build bgpd. 473: 474: `--disable-bgp-announce' 475: Make `bgpd' which does not make bgp announcements at all. This 476: feature is good for using `bgpd' as a BGP announcement listener. 477: 478: `--enable-netlink' 479: Force to enable GNU/Linux netlink interface. Quagga configure 480: script detects netlink interface by checking a header file. When 481: the header file does not match to the current running kernel, 482: configure script will not turn on netlink support. 483: 484: `--enable-snmp' 485: Enable SNMP support. By default, SNMP support is disabled. 486: 487: `--enable-opaque-lsa' 488: Enable support for Opaque LSAs (RFC2370) in ospfd. 489: 490: `--disable-ospfapi' 491: Disable support for OSPF-API, an API to interface directly with 492: ospfd. OSPF-API is enabled if -enable-opaque-lsa is set. 493: 494: `--disable-ospfclient' 495: Disable building of the example OSPF-API client. 496: 497: `--enable-ospf-te' 498: Enable support for OSPF Traffic Engineering Extension 499: (internet-draft) this requires support for Opaque LSAs. 500: 501: `--enable-multipath=ARG' 502: Enable support for Equal Cost Multipath. ARG is the maximum number 503: of ECMP paths to allow, set to 0 to allow unlimited number of 504: paths. 505: 506: `--enable-rtadv' 507: Enable support IPV6 router advertisement in zebra. 508: 509: You may specify any combination of the above options to the configure 510: script. By default, the executables are placed in `/usr/local/sbin' 511: and the configuration files in `/usr/local/etc'. The `/usr/local/' 512: installation prefix and other directories may be changed using the 513: following options to the configuration script. 514: 515: `--prefix=PREFIX' 516: Install architecture-independent files in PREFIX [/usr/local]. 517: 518: `--sysconfdir=DIR' 519: Look for configuration files in DIR [PREFIX/etc]. Note that sample 520: configuration files will be installed here. 521: 522: `--localstatedir=DIR' 523: Configure zebra to use DIR for local state files, such as pid 524: files and unix sockets. 525: 526: % ./configure --disable-ipv6 527: 528: This command will configure zebra and the routing daemons. 529: 530: 531: File: quagga.info, Node: Least-Privilege support, Next: Linux notes, Prev: The Configure script and its options, Up: Configure the Software 532: 533: 2.1.2 Least-Privilege support 534: ----------------------------- 535: 536: Additionally, you may configure zebra to drop its elevated privileges 537: shortly after startup and switch to another user. The configure script 538: will automatically try to configure this support. There are three 539: configure options to control the behaviour of Quagga daemons. 540: 541: `--enable-user=USER' 542: Switch to user ARG shortly after startup, and run as user ARG in 543: normal operation. 544: 545: `--enable-group=GROUP' 546: Switch real and effective group to GROUP shortly after startup. 547: 548: `--enable-vty-group=GROUP' 549: Create Unix Vty sockets (for use with vtysh) with group owndership 550: set to GROUP. This allows one to create a seperate group which is 551: restricted to accessing only the Vty sockets, hence allowing one to 552: delegate this group to individual users, or to run vtysh setgid to 553: this group. 554: 555: The default user and group which will be configured is 'quagga' if 556: no user or group is specified. Note that this user or group requires 557: write access to the local state directory (see -localstatedir) and 558: requires at least read access, and write access if you wish to allow 559: daemons to write out their configuration, to the configuration 560: directory (see -sysconfdir). 561: 562: On systems which have the 'libcap' capabilities manipulation library 563: (currently only linux), the quagga system will retain only minimal 564: capabilities required, further it will only raise these capabilities for 565: brief periods. On systems without libcap, quagga will run as the user 566: specified and only raise its uid back to uid 0 for brief periods. 567: 568: 569: File: quagga.info, Node: Linux notes, Prev: Least-Privilege support, Up: Configure the Software 570: 571: 2.1.3 Linux Notes 572: ----------------- 573: 574: There are several options available only to GNU/Linux systems: (1). If 575: you use GNU/Linux, make sure that the current kernel configuration is 576: what you want. Quagga will run with any kernel configuration but some 577: recommendations do exist. 578: 579: CONFIG_NETLINK 580: Kernel/User netlink socket. This is a brand new feature which 581: enables an advanced interface between the Linux kernel and zebra 582: (*note Kernel Interface::). 583: 584: CONFIG_RTNETLINK 585: Routing messages. This makes it possible to receive netlink 586: routing messages. If you specify this option, `zebra' can detect 587: routing information updates directly from the kernel (*note Kernel 588: Interface::). 589: 590: CONFIG_IP_MULTICAST 591: IP: multicasting. This option should be specified when you use 592: `ripd' (*note RIP::) or `ospfd' (*note OSPFv2::) because these 593: protocols use multicast. 594: 595: 596: IPv6 support has been added in GNU/Linux kernel version 2.2. If you 597: try to use the Quagga IPv6 feature on a GNU/Linux kernel, please make 598: sure the following libraries have been installed. Please note that 599: these libraries will not be needed when you uses GNU C library 2.1 or 600: upper. 601: 602: `inet6-apps' 603: The `inet6-apps' package includes basic IPv6 related libraries such 604: as `inet_ntop' and `inet_pton'. Some basic IPv6 programs such as 605: `ping', `ftp', and `inetd' are also included. The `inet-apps' can 606: be found at `ftp://ftp.inner.net/pub/ipv6/'. 607: 608: `net-tools' 609: The `net-tools' package provides an IPv6 enabled interface and 610: routing utility. It contains `ifconfig', `route', `netstat', and 611: other tools. `net-tools' may be found at 612: `http://www.tazenda.demon.co.uk/phil/net-tools/'. 613: 614: 615: ---------- Footnotes ---------- 616: 617: (1) GNU/Linux has very flexible kernel configuration features 618: 619: 620: File: quagga.info, Node: Build the Software, Next: Install the Software, Prev: Configure the Software, Up: Installation 621: 622: 2.2 Build the Software 623: ====================== 624: 625: After configuring the software, you will need to compile it for your 626: system. Simply issue the command `make' in the root of the source 627: directory and the software will be compiled. If you have *any* problems 628: at this stage, be certain to send a bug report *Note Bug Reports::. 629: 630: % ./configure 631: . 632: . 633: . 634: ./configure output 635: . 636: . 637: . 638: % make 639: 640: 641: File: quagga.info, Node: Install the Software, Prev: Build the Software, Up: Installation 642: 643: 2.3 Install the Software 644: ======================== 645: 646: Installing the software to your system consists of copying the compiled 647: programs and supporting files to a standard location. After the 648: installation process has completed, these files have been copied from 649: your work directory to `/usr/local/bin', and `/usr/local/etc'. 650: 651: To install the Quagga suite, issue the following command at your 652: shell prompt: `make install'. 653: 654: % 655: % make install 656: % 657: 658: Quagga daemons have their own terminal interface or VTY. After 659: installation, you have to setup each beast's port number to connect to 660: them. Please add the following entries to `/etc/services'. 661: 662: zebrasrv 2600/tcp # zebra service 663: zebra 2601/tcp # zebra vty 664: ripd 2602/tcp # RIPd vty 665: ripngd 2603/tcp # RIPngd vty 666: ospfd 2604/tcp # OSPFd vty 667: bgpd 2605/tcp # BGPd vty 668: ospf6d 2606/tcp # OSPF6d vty 669: ospfapi 2607/tcp # ospfapi 670: isisd 2608/tcp # ISISd vty 671: 672: If you use a FreeBSD newer than 2.2.8, the above entries are already 673: added to `/etc/services' so there is no need to add it. If you specify 674: a port number when starting the daemon, these entries may not be needed. 675: 676: You may need to make changes to the config files in 677: `/etc/quagga/*.conf'. *Note Config Commands::. 678: 679: 680: File: quagga.info, Node: Basic commands, Next: Zebra, Prev: Installation, Up: Top 681: 682: 3 Basic commands 683: **************** 684: 685: There are five routing daemons in use, and there is one manager daemon. 686: These daemons may be located on separate machines from the manager 687: daemon. Each of these daemons will listen on a particular port for 688: incoming VTY connections. The routing daemons are: 689: 690: * `ripd', `ripngd', `ospfd', `ospf6d', `bgpd' 691: 692: * `zebra' 693: 694: The following sections discuss commands common to all the routing 695: daemons. 696: 697: * Menu: 698: 699: * Terminal Mode Commands:: Common commands used in a VTY 700: * Config Commands:: Commands used in config files 701: * Common Invocation Options:: Starting the daemons 702: * Virtual Terminal Interfaces:: Interacting with the daemons 703: 704: 705: File: quagga.info, Node: Config Commands, Next: Common Invocation Options, Prev: Terminal Mode Commands, Up: Basic commands 706: 707: 3.1 Config Commands 708: =================== 709: 710: * Menu: 711: 712: * Basic Config Commands:: Some of the generic config commands 713: * Sample Config File:: An example config file 714: 715: In a config file, you can write the debugging options, a vty's 716: password, routing daemon configurations, a log file name, and so forth. 717: This information forms the initial command set for a routing beast as 718: it is starting. 719: 720: Config files are generally found in: 721: 722: `/etc/quagga/*.conf' 723: 724: Each of the daemons has its own config file. For example, zebra's 725: default config file name is: 726: 727: `/etc/quagga/zebra.conf' 728: 729: The daemon name plus `.conf' is the default config file name. You 730: can specify a config file using the `-f' or `--config-file' options 731: when starting the daemon. 732: 733: 734: File: quagga.info, Node: Basic Config Commands, Next: Sample Config File, Up: Config Commands 735: 736: 3.1.1 Basic Config Commands 737: --------------------------- 738: 739: -- Command: hostname HOSTNAME 740: Set hostname of the router. 741: 742: -- Command: password PASSWORD 743: Set password for vty interface. If there is no password, a vty 744: won't accept connections. 745: 746: -- Command: enable password PASSWORD 747: Set enable password. 748: 749: -- Command: log trap LEVEL 750: -- Command: no log trap 751: These commands are deprecated and are present only for historical 752: compatibility. The log trap command sets the current logging 753: level for all enabled logging destinations, and it sets the 754: default for all future logging commands that do not specify a 755: level. The normal default logging level is debugging. The `no' 756: form of the command resets the default level for future logging 757: commands to debugging, but it does not change the logging level of 758: existing logging destinations. 759: 760: -- Command: log stdout 761: -- Command: log stdout LEVEL 762: -- Command: no log stdout 763: Enable logging output to stdout. If the optional second argument 764: specifying the logging level is not present, the default logging 765: level (typically debugging, but can be changed using the 766: deprecated `log trap' command) will be used. The `no' form of the 767: command disables logging to stdout. The `level' argument must 768: have one of these values: emergencies, alerts, critical, errors, 769: warnings, notifications, informational, or debugging. Note that 770: the existing code logs its most important messages with severity 771: `errors'. 772: 773: -- Command: log file FILENAME 774: -- Command: log file FILENAME LEVEL 775: -- Command: no log file 776: If you want to log into a file, please specify `filename' as in 777: this example: 778: log file /var/log/quagga/bgpd.log informational 779: If the optional second argument specifying the logging level is 780: not present, the default logging level (typically debugging, but 781: can be changed using the deprecated `log trap' command) will be 782: used. The `no' form of the command disables logging to a file. 783: 784: Note: if you do not configure any file logging, and a daemon 785: crashes due to a signal or an assertion failure, it will attempt 786: to save the crash information in a file named 787: /var/tmp/quagga.<daemon name>.crashlog. For security reasons, 788: this will not happen if the file exists already, so it is 789: important to delete the file after reporting the crash information. 790: 791: -- Command: log syslog 792: -- Command: log syslog LEVEL 793: -- Command: no log syslog 794: Enable logging output to syslog. If the optional second argument 795: specifying the logging level is not present, the default logging 796: level (typically debugging, but can be changed using the 797: deprecated `log trap' command) will be used. The `no' form of the 798: command disables logging to syslog. 799: 800: -- Command: log monitor 801: -- Command: log monitor LEVEL 802: -- Command: no log monitor 803: Enable logging output to vty terminals that have enabled logging 804: using the `terminal monitor' command. By default, monitor logging 805: is enabled at the debugging level, but this command (or the 806: deprecated `log trap' command) can be used to change the monitor 807: logging level. If the optional second argument specifying the 808: logging level is not present, the default logging level (typically 809: debugging, but can be changed using the deprecated `log trap' 810: command) will be used. The `no' form of the command disables 811: logging to terminal monitors. 812: 813: -- Command: log facility FACILITY 814: -- Command: no log facility 815: This command changes the facility used in syslog messages. The 816: default facility is `daemon'. The `no' form of the command resets 817: the facility to the default `daemon' facility. 818: 819: -- Command: log record-priority 820: -- Command: no log record-priority 821: To include the severity in all messages logged to a file, to 822: stdout, or to a terminal monitor (i.e. anything except syslog), 823: use the `log record-priority' global configuration command. To 824: disable this option, use the `no' form of the command. By default, 825: the severity level is not included in logged messages. Note: some 826: versions of syslogd (including Solaris) can be configured to 827: include the facility and level in the messages emitted. 828: 829: -- Command: log timestamp precision <0-6> 830: -- Command: no log timestamp precision 831: This command sets the precision of log message timestamps to the 832: given number of digits after the decimal point. Currently, the 833: value must be in the range 0 to 6 (i.e. the maximum precision is 834: microseconds). To restore the default behavior (1-second 835: accuracy), use the `no' form of the command, or set the precision 836: explicitly to 0. 837: 838: log timestamp precision 3 839: 840: In this example, the precision is set to provide timestamps with 841: millisecond accuracy. 842: 843: -- Command: service password-encryption 844: Encrypt password. 845: 846: -- Command: service advanced-vty 847: Enable advanced mode VTY. 848: 849: -- Command: service terminal-length <0-512> 850: Set system wide line configuration. This configuration command 851: applies to all VTY interfaces. 852: 853: -- Command: line vty 854: Enter vty configuration mode. 855: 856: -- Command: banner motd default 857: Set default motd string. 858: 859: -- Command: no banner motd 860: No motd banner string will be printed. 861: 862: -- Line Command: exec-timeout MINUTE 863: -- Line Command: exec-timeout MINUTE SECOND 864: Set VTY connection timeout value. When only one argument is 865: specified it is used for timeout value in minutes. Optional 866: second argument is used for timeout value in seconds. Default 867: timeout value is 10 minutes. When timeout value is zero, it means 868: no timeout. 869: 870: -- Line Command: no exec-timeout 871: Do not perform timeout at all. This command is as same as 872: `exec-timeout 0 0'. 873: 874: -- Line Command: access-class ACCESS-LIST 875: Restrict vty connections with an access list. 876: 877: 878: File: quagga.info, Node: Sample Config File, Prev: Basic Config Commands, Up: Config Commands 879: 880: 3.1.2 Sample Config File 881: ------------------------ 882: 883: Below is a sample configuration file for the zebra daemon. 884: 885: ! 886: ! Zebra configuration file 887: ! 888: hostname Router 889: password zebra 890: enable password zebra 891: ! 892: log stdout 893: ! 894: ! 895: 896: '!' and '#' are comment characters. If the first character of the 897: word is one of the comment characters then from the rest of the line 898: forward will be ignored as a comment. 899: 900: password zebra!password 901: 902: If a comment character is not the first character of the word, it's a 903: normal character. So in the above example '!' will not be regarded as a 904: comment and the password is set to 'zebra!password'. 905: 906: 907: File: quagga.info, Node: Terminal Mode Commands, Next: Config Commands, Up: Basic commands 908: 909: 3.2 Terminal Mode Commands 910: ========================== 911: 912: -- Command: write terminal 913: Displays the current configuration to the vty interface. 914: 915: -- Command: write file 916: Write current configuration to configuration file. 917: 918: -- Command: configure terminal 919: Change to configuration mode. This command is the first step to 920: configuration. 921: 922: -- Command: terminal length <0-512> 923: Set terminal display length to <0-512>. If length is 0, no 924: display control is performed. 925: 926: -- Command: who 927: Show a list of currently connected vty sessions. 928: 929: -- Command: list 930: List all available commands. 931: 932: -- Command: show version 933: Show the current version of Quagga and its build host information. 934: 935: -- Command: show logging 936: Shows the current configuration of the logging system. This 937: includes the status of all logging destinations. 938: 939: -- Command: logmsg LEVEL MESSAGE 940: Send a message to all logging destinations that are enabled for 941: messages of the given severity. 942: 943: 944: File: quagga.info, Node: Common Invocation Options, Next: Virtual Terminal Interfaces, Prev: Config Commands, Up: Basic commands 945: 946: 3.3 Common Invocation Options 947: ============================= 948: 949: These options apply to all Quagga daemons. 950: 951: `-d' 952: `--daemon' 953: Runs in daemon mode. 954: 955: `-f FILE' 956: `--config_file=FILE' 957: Set configuration file name. 958: 959: `-h' 960: `--help' 961: Display this help and exit. 962: 963: `-i FILE' 964: `--pid_file=FILE' 965: Upon startup the process identifier of the daemon is written to a 966: file, typically in `/var/run'. This file can be used by the init 967: system to implement commands such as `.../init.d/zebra status', 968: `.../init.d/zebra restart' or `.../init.d/zebra stop'. 969: 970: The file name is an run-time option rather than a configure-time 971: option so that multiple routing daemons can be run simultaneously. 972: This is useful when using Quagga to implement a routing looking 973: glass. One machine can be used to collect differing routing views 974: from differing points in the network. 975: 976: `-A ADDRESS' 977: `--vty_addr=ADDRESS' 978: Set the VTY local address to bind to. If set, the VTY socket will 979: only be bound to this address. 980: 981: `-P PORT' 982: `--vty_port=PORT' 983: Set the VTY TCP port number. If set to 0 then the TCP VTY sockets 984: will not be opened. 985: 986: `-u USER' 987: `--vty_addr=USER' 988: Set the user and group to run as. 989: 990: `-v' 991: `--version' 992: Print program version. 993: 994: 995: 996: File: quagga.info, Node: Virtual Terminal Interfaces, Prev: Common Invocation Options, Up: Basic commands 997: 998: 3.4 Virtual Terminal Interfaces 999: =============================== 1000: 1001: VTY - Virtual Terminal [aka TeletYpe] Interface is a command line 1002: interface (CLI) for user interaction with the routing daemon. 1003: 1004: * Menu: 1005: 1006: * VTY Overview:: Basics about VTYs 1007: * VTY Modes:: View, Enable, and Other VTY modes 1008: * VTY CLI Commands:: Commands for movement, edition, and management 1009: 1010: 1011: File: quagga.info, Node: VTY Overview, Next: VTY Modes, Up: Virtual Terminal Interfaces 1012: 1013: 3.4.1 VTY Overview 1014: ------------------ 1015: 1016: VTY stands for Virtual TeletYpe interface. It means you can connect to 1017: the daemon via the telnet protocol. 1018: 1019: To enable a VTY interface, you have to setup a VTY password. If 1020: there is no VTY password, one cannot connect to the VTY interface at 1021: all. 1022: 1023: % telnet localhost 2601 1024: Trying 127.0.0.1... 1025: Connected to localhost. 1026: Escape character is '^]'. 1027: 1028: Hello, this is Quagga (version 0.99.21) 1029: Copyright (C) 1999-2005 Kunihiro Ishiguro, et al. 1030: 1031: User Access Verification 1032: 1033: Password: XXXXX 1034: Router> ? 1035: enable Turn on privileged commands 1036: exit Exit current mode and down to previous mode 1037: help Description of the interactive help system 1038: list Print command list 1039: show Show running system information 1040: who Display who is on a vty 1041: Router> enable 1042: Password: XXXXX 1043: Router# configure terminal 1044: Router(config)# interface eth0 1045: Router(config-if)# ip address 10.0.0.1/8 1046: Router(config-if)# ^Z 1047: Router# 1048: 1049: '?' is very useful for looking up commands. 1050: 1051: 1052: File: quagga.info, Node: VTY Modes, Next: VTY CLI Commands, Prev: VTY Overview, Up: Virtual Terminal Interfaces 1053: 1054: 3.4.2 VTY Modes 1055: --------------- 1056: 1057: There are three basic VTY modes: 1058: 1059: * Menu: 1060: 1061: * VTY View Mode:: Mode for read-only interaction 1062: * VTY Enable Mode:: Mode for read-write interaction 1063: * VTY Other Modes:: Special modes (tftp, etc) 1064: 1065: There are commands that may be restricted to specific VTY modes. 1066: 1067: 1068: File: quagga.info, Node: VTY View Mode, Next: VTY Enable Mode, Up: VTY Modes 1069: 1070: 3.4.2.1 VTY View Mode 1071: ..................... 1072: 1073: This mode is for read-only access to the CLI. One may exit the mode by 1074: leaving the system, or by entering `enable' mode. 1075: 1076: 1077: File: quagga.info, Node: VTY Enable Mode, Next: VTY Other Modes, Prev: VTY View Mode, Up: VTY Modes 1078: 1079: 3.4.2.2 VTY Enable Mode 1080: ....................... 1081: 1082: This mode is for read-write access to the CLI. One may exit the mode by 1083: leaving the system, or by escaping to view mode. 1084: 1085: 1086: File: quagga.info, Node: VTY Other Modes, Prev: VTY Enable Mode, Up: VTY Modes 1087: 1088: 3.4.2.3 VTY Other Modes 1089: ....................... 1090: 1091: This page is for describing other modes. 1092: 1093: 1094: File: quagga.info, Node: VTY CLI Commands, Prev: VTY Modes, Up: Virtual Terminal Interfaces 1095: 1096: 3.4.3 VTY CLI Commands 1097: ---------------------- 1098: 1099: Commands that you may use at the command-line are described in the 1100: following three subsubsections. 1101: 1102: * Menu: 1103: 1104: * CLI Movement Commands:: Commands for moving the cursor about 1105: * CLI Editing Commands:: Commands for changing text 1106: * CLI Advanced Commands:: Other commands, session management and so on 1107: 1108: 1109: File: quagga.info, Node: CLI Movement Commands, Next: CLI Editing Commands, Up: VTY CLI Commands 1110: 1111: 3.4.3.1 CLI Movement Commands 1112: ............................. 1113: 1114: These commands are used for moving the CLI cursor. The <C> character 1115: means press the Control Key. 1116: 1117: `C-f' 1118: `<RIGHT>' 1119: Move forward one character. 1120: 1121: `C-b' 1122: `<LEFT>' 1123: Move backward one character. 1124: 1125: `M-f' 1126: Move forward one word. 1127: 1128: `M-b' 1129: Move backward one word. 1130: 1131: `C-a' 1132: Move to the beginning of the line. 1133: 1134: `C-e' 1135: Move to the end of the line. 1136: 1137: 1138: 1139: File: quagga.info, Node: CLI Editing Commands, Next: CLI Advanced Commands, Prev: CLI Movement Commands, Up: VTY CLI Commands 1140: 1141: 3.4.3.2 CLI Editing Commands 1142: ............................ 1143: 1144: These commands are used for editing text on a line. The <C> character 1145: means press the Control Key. 1146: 1147: `C-h' 1148: `<DEL>' 1149: Delete the character before point. 1150: 1151: `C-d' 1152: Delete the character after point. 1153: 1154: `M-d' 1155: Forward kill word. 1156: 1157: `C-w' 1158: Backward kill word. 1159: 1160: `C-k' 1161: Kill to the end of the line. 1162: 1163: `C-u' 1164: Kill line from the beginning, erasing input. 1165: 1166: `C-t' 1167: Transpose character. 1168: 1169: 1170: 1171: File: quagga.info, Node: CLI Advanced Commands, Prev: CLI Editing Commands, Up: VTY CLI Commands 1172: 1173: 3.4.3.3 CLI Advanced Commands 1174: ............................. 1175: 1176: There are several additional CLI commands for command line completions, 1177: insta-help, and VTY session management. 1178: 1179: `C-c' 1180: Interrupt current input and moves to the next line. 1181: 1182: `C-z' 1183: End current configuration session and move to top node. 1184: 1185: `C-n' 1186: `<DOWN>' 1187: Move down to next line in the history buffer. 1188: 1189: `C-p' 1190: `<UP>' 1191: Move up to previous line in the history buffer. 1192: 1193: `TAB' 1194: Use command line completion by typing <TAB>. 1195: 1196: `' 1197: You can use command line help by typing `help' at the beginning of 1198: the line. Typing `?' at any point in the line will show possible 1199: completions. 1200: 1201: 1202: 1203: File: quagga.info, Node: Zebra, Next: RIP, Prev: Basic commands, Up: Top 1204: 1205: 4 Zebra 1206: ******* 1207: 1208: `zebra' is an IP routing manager. It provides kernel routing table 1209: updates, interface lookups, and redistribution of routes between 1210: different routing protocols. 1211: 1212: * Menu: 1213: 1214: * Invoking zebra:: Running the program 1215: * Interface Commands:: Commands for zebra interfaces 1216: * Static Route Commands:: Commands for adding static routes 1217: * zebra Route Filtering:: Commands for zebra route filtering 1218: * zebra Terminal Mode Commands:: Commands for zebra's VTY 1219: 1220: 1221: File: quagga.info, Node: Invoking zebra, Next: Interface Commands, Up: Zebra 1222: 1223: 4.1 Invoking zebra 1224: ================== 1225: 1226: Besides the common invocation options (*note Common Invocation 1227: Options::), the `zebra' specific invocation options are listed below. 1228: 1229: `-b' 1230: `--batch' 1231: Runs in batch mode. `zebra' parses configuration file and 1232: terminates immediately. 1233: 1234: `-k' 1235: `--keep_kernel' 1236: When zebra starts up, don't delete old self inserted routes. 1237: 1238: `-r' 1239: `--retain' 1240: When program terminates, retain routes added by zebra. 1241: 1242: 1243: 1244: File: quagga.info, Node: Interface Commands, Next: Static Route Commands, Prev: Invoking zebra, Up: Zebra 1245: 1246: 4.2 Interface Commands 1247: ====================== 1248: 1249: -- Command: interface IFNAME 1250: 1251: -- Interface Command: shutdown 1252: -- Interface Command: no shutdown 1253: Up or down the current interface. 1254: 1255: -- Interface Command: ip address ADDRESS/PREFIX 1256: -- Interface Command: ipv6 address ADDRESS/PREFIX 1257: -- Interface Command: no ip address ADDRESS/PREFIX 1258: -- Interface Command: no ipv6 address ADDRESS/PREFIX 1259: Set the IPv4 or IPv6 address/prefix for the interface. 1260: 1261: -- Interface Command: ip address ADDRESS/PREFIX secondary 1262: -- Interface Command: no ip address ADDRESS/PREFIX secondary 1263: Set the secondary flag for this address. This causes ospfd to not 1264: treat the address as a distinct subnet. 1265: 1266: -- Interface Command: description DESCRIPTION ... 1267: Set description for the interface. 1268: 1269: -- Interface Command: multicast 1270: -- Interface Command: no multicast 1271: Enable or disables multicast flag for the interface. 1272: 1273: -- Interface Command: bandwidth <1-10000000> 1274: -- Interface Command: no bandwidth <1-10000000> 1275: Set bandwidth value of the interface in kilobits/sec. This is for 1276: calculating OSPF cost. This command does not affect the actual 1277: device configuration. 1278: 1279: -- Interface Command: link-detect 1280: -- Interface Command: no link-detect 1281: Enable/disable link-detect on platforms which support this. 1282: Currently only Linux and Solaris, and only where network interface 1283: drivers support reporting link-state via the IFF_RUNNING flag. 1284: 1285: 1286: File: quagga.info, Node: Static Route Commands, Next: zebra Route Filtering, Prev: Interface Commands, Up: Zebra 1287: 1288: 4.3 Static Route Commands 1289: ========================= 1290: 1291: Static routing is a very fundamental feature of routing technology. It 1292: defines static prefix and gateway. 1293: 1294: -- Command: ip route NETWORK GATEWAY 1295: NETWORK is destination prefix with format of A.B.C.D/M. GATEWAY 1296: is gateway for the prefix. When GATEWAY is A.B.C.D format. It is 1297: taken as a IPv4 address gateway. Otherwise it is treated as an 1298: interface name. If the interface name is NULL0 then zebra installs 1299: a blackhole route. 1300: 1301: ip route 10.0.0.0/8 10.0.0.2 1302: ip route 10.0.0.0/8 ppp0 1303: ip route 10.0.0.0/8 null0 1304: 1305: First example defines 10.0.0.0/8 static route with gateway 1306: 10.0.0.2. Second one defines the same prefix but with gateway to 1307: interface ppp0. The third install a blackhole route. 1308: 1309: -- Command: ip route NETWORK NETMASK GATEWAY 1310: This is alternate version of above command. When NETWORK is 1311: A.B.C.D format, user must define NETMASK value with A.B.C.D 1312: format. GATEWAY is same option as above command 1313: 1314: ip route 10.0.0.0 255.255.255.0 10.0.0.2 1315: ip route 10.0.0.0 255.255.255.0 ppp0 1316: ip route 10.0.0.0 255.255.255.0 null0 1317: 1318: These statements are equivalent to those in the previous example. 1319: 1320: -- Command: ip route NETWORK GATEWAY DISTANCE 1321: Installs the route with the specified distance. 1322: 1323: Multiple nexthop static route 1324: 1325: ip route 10.0.0.1/32 10.0.0.2 1326: ip route 10.0.0.1/32 10.0.0.3 1327: ip route 10.0.0.1/32 eth0 1328: 1329: If there is no route to 10.0.0.2 and 10.0.0.3, and interface eth0 is 1330: reachable, then the last route is installed into the kernel. 1331: 1332: If zebra has been compiled with multipath support, and both 10.0.0.2 1333: and 10.0.0.3 are reachable, zebra will install a multipath route via 1334: both nexthops, if the platform supports this. 1335: 1336: zebra> show ip route 1337: S> 10.0.0.1/32 [1/0] via 10.0.0.2 inactive 1338: via 10.0.0.3 inactive 1339: * is directly connected, eth0 1340: 1341: ip route 10.0.0.0/8 10.0.0.2 1342: ip route 10.0.0.0/8 10.0.0.3 1343: ip route 10.0.0.0/8 null0 255 1344: 1345: This will install a multihop route via the specified next-hops if 1346: they are reachable, as well as a high-metric blackhole route, which can 1347: be useful to prevent traffic destined for a prefix to match 1348: less-specific routes (eg default) should the specified gateways not be 1349: reachable. Eg: 1350: 1351: zebra> show ip route 10.0.0.0/8 1352: Routing entry for 10.0.0.0/8 1353: Known via "static", distance 1, metric 0 1354: 10.0.0.2 inactive 1355: 10.0.0.3 inactive 1356: 1357: Routing entry for 10.0.0.0/8 1358: Known via "static", distance 255, metric 0 1359: directly connected, Null0 1360: 1361: -- Command: ipv6 route NETWORK GATEWAY 1362: -- Command: ipv6 route NETWORK GATEWAY DISTANCE 1363: These behave similarly to their ipv4 counterparts. 1364: 1365: -- Command: table TABLENO 1366: Select the primary kernel routing table to be used. This only 1367: works for kernels supporting multiple routing tables (like 1368: GNU/Linux 2.2.x and later). After setting TABLENO with this 1369: command, static routes defined after this are added to the 1370: specified table. 1371: 1372: 1373: File: quagga.info, Node: zebra Route Filtering, Next: zebra Terminal Mode Commands, Prev: Static Route Commands, Up: Zebra 1374: 1375: 4.4 zebra Route Filtering 1376: ========================= 1377: 1378: Zebra supports `prefix-list' and `route-map' to match routes received 1379: from other quagga components. The `permit'/`deny' facilities provided 1380: by these commands can be used to filter which routes zebra will install 1381: in the kernel. 1382: 1383: -- Command: ip protocol PROTOCOL route-map ROUTEMAP 1384: Apply a route-map filter to routes for the specified protocol. 1385: PROTOCOL can be any or one of system, kernel, connected, static, 1386: rip, ripng, ospf, ospf6, isis, bgp, hsls. 1387: 1388: -- Route Map: set src ADDRESS 1389: Within a route-map, set the preferred source address for matching 1390: routes when installing in the kernel. 1391: 1392: The following creates a prefix-list that matches all addresses, a route-map 1393: that sets the preferred source address, and applies the route-map to all 1394: `rip' routes. 1395: 1396: ip prefix-list ANY permit 0.0.0.0/0 le 32 1397: route-map RM1 permit 10 1398: match ip address prefix-list ANY 1399: set src 10.0.0.1 1400: 1401: ip protocol rip route-map RM1 1402: 1403: 1404: File: quagga.info, Node: zebra Terminal Mode Commands, Prev: zebra Route Filtering, Up: Zebra 1405: 1406: 4.5 zebra Terminal Mode Commands 1407: ================================ 1408: 1409: -- Command: show ip route 1410: Display current routes which zebra holds in its database. 1411: 1412: Router# show ip route 1413: Codes: K - kernel route, C - connected, S - static, R - RIP, 1414: B - BGP * - FIB route. 1415: 1416: K* 0.0.0.0/0 203.181.89.241 1417: S 0.0.0.0/0 203.181.89.1 1418: C* 127.0.0.0/8 lo 1419: C* 203.181.89.240/28 eth0 1420: 1421: -- Command: show ipv6 route 1422: 1423: -- Command: show interface 1424: 1425: -- Command: show ip prefix-list [NAME] 1426: 1427: -- Command: show route-map [NAME] 1428: 1429: -- Command: show ip protocol 1430: 1431: -- Command: show ipforward 1432: Display whether the host's IP forwarding function is enabled or 1433: not. Almost any UNIX kernel can be configured with IP forwarding 1434: disabled. If so, the box can't work as a router. 1435: 1436: -- Command: show ipv6forward 1437: Display whether the host's IP v6 forwarding is enabled or not. 1438: 1439: 1440: File: quagga.info, Node: RIP, Next: RIPng, Prev: Zebra, Up: Top 1441: 1442: 5 RIP 1443: ***** 1444: 1445: RIP - Routing Information Protocol is widely deployed interior gateway 1446: protocol. RIP was developed in the 1970s at Xerox Labs as part of the 1447: XNS routing protocol. RIP is a "distance-vector" protocol and is based 1448: on the "Bellman-Ford" algorithms. As a distance-vector protocol, RIP 1449: router send updates to its neighbors periodically, thus allowing the 1450: convergence to a known topology. In each update, the distance to any 1451: given network will be broadcasted to its neighboring router. 1452: 1453: `ripd' supports RIP version 2 as described in RFC2453 and RIP 1454: version 1 as described in RFC1058. 1455: 1456: * Menu: 1457: 1458: * Starting and Stopping ripd:: 1459: * RIP Configuration:: 1460: * RIP Version Control:: 1461: * How to Announce RIP route:: 1462: * Filtering RIP Routes:: 1463: * RIP Metric Manipulation:: 1464: * RIP distance:: 1465: * RIP route-map:: 1466: * RIP Authentication:: 1467: * RIP Timers:: 1468: * Show RIP Information:: 1469: * RIP Debug Commands:: 1470: 1471: 1472: File: quagga.info, Node: Starting and Stopping ripd, Next: RIP Configuration, Up: RIP 1473: 1474: 5.1 Starting and Stopping ripd 1475: ============================== 1476: 1477: The default configuration file name of `ripd''s is `ripd.conf'. When 1478: invocation `ripd' searches directory /etc/quagga. If `ripd.conf' is 1479: not there next search current directory. 1480: 1481: RIP uses UDP port 520 to send and receive RIP packets. So the user 1482: must have the capability to bind the port, generally this means that 1483: the user must have superuser privileges. RIP protocol requires 1484: interface information maintained by `zebra' daemon. So running `zebra' 1485: is mandatory to run `ripd'. Thus minimum sequence for running RIP is 1486: like below: 1487: 1488: # zebra -d 1489: # ripd -d 1490: 1491: Please note that `zebra' must be invoked before `ripd'. 1492: 1493: To stop `ripd'. Please use `kill `cat /var/run/ripd.pid`'. Certain 1494: signals have special meaningss to `ripd'. 1495: 1496: `SIGHUP' 1497: Reload configuration file `ripd.conf'. All configurations are 1498: reseted. All routes learned so far are cleared and removed from 1499: routing table. 1500: 1501: `SIGUSR1' 1502: Rotate `ripd' logfile. 1503: 1504: `SIGINT' 1505: `SIGTERM' 1506: `ripd' sweeps all installed RIP routes then terminates properly. 1507: 1508: `ripd' invocation options. Common options that can be specified 1509: (*note Common Invocation Options::). 1510: 1511: `-r' 1512: `--retain' 1513: When the program terminates, retain routes added by `ripd'. 1514: 1515: * Menu: 1516: 1517: * RIP netmask:: 1518: 1519: 1520: File: quagga.info, Node: RIP netmask, Up: Starting and Stopping ripd 1521: 1522: 5.1.1 RIP netmask 1523: ----------------- 1524: 1525: The netmask features of `ripd' support both version 1 and version 2 of 1526: RIP. Version 1 of RIP originally contained no netmask information. In 1527: RIP version 1, network classes were originally used to determine the 1528: size of the netmask. Class A networks use 8 bits of mask, Class B 1529: networks use 16 bits of masks, while Class C networks use 24 bits of 1530: mask. Today, the most widely used method of a network mask is assigned 1531: to the packet on the basis of the interface that received the packet. 1532: Version 2 of RIP supports a variable length subnet mask (VLSM). By 1533: extending the subnet mask, the mask can be divided and reused. Each 1534: subnet can be used for different purposes such as large to middle size 1535: LANs and WAN links. Quagga `ripd' does not support the non-sequential 1536: netmasks that are included in RIP Version 2. 1537: 1538: In a case of similar information with the same prefix and metric, the 1539: old information will be suppressed. Ripd does not currently support 1540: equal cost multipath routing. 1541: 1542: 1543: File: quagga.info, Node: RIP Configuration, Next: RIP Version Control, Prev: Starting and Stopping ripd, Up: RIP 1544: 1545: 5.2 RIP Configuration 1546: ===================== 1547: 1548: -- Command: router rip 1549: The `router rip' command is necessary to enable RIP. To disable 1550: RIP, use the `no router rip' command. RIP must be enabled before 1551: carrying out any of the RIP commands. 1552: 1553: -- Command: no router rip 1554: Disable RIP. 1555: 1556: -- RIP Command: network NETWORK 1557: -- RIP Command: no network NETWORK 1558: Set the RIP enable interface by NETWORK. The interfaces which 1559: have addresses matching with NETWORK are enabled. 1560: 1561: This group of commands either enables or disables RIP interfaces 1562: between certain numbers of a specified network address. For 1563: example, if the network for 10.0.0.0/24 is RIP enabled, this would 1564: result in all the addresses from 10.0.0.0 to 10.0.0.255 being 1565: enabled for RIP. The `no network' command will disable RIP for 1566: the specified network. 1567: 1568: -- RIP Command: network IFNAME 1569: -- RIP Command: no network IFNAME 1570: Set a RIP enabled interface by IFNAME. Both the sending and 1571: receiving of RIP packets will be enabled on the port specified in 1572: the `network ifname' command. The `no network ifname' command 1573: will disable RIP on the specified interface. 1574: 1575: -- RIP Command: neighbor A.B.C.D 1576: -- RIP Command: no neighbor A.B.C.D 1577: Specify RIP neighbor. When a neighbor doesn't understand 1578: multicast, this command is used to specify neighbors. In some 1579: cases, not all routers will be able to understand multicasting, 1580: where packets are sent to a network or a group of addresses. In a 1581: situation where a neighbor cannot process multicast packets, it is 1582: necessary to establish a direct link between routers. The 1583: neighbor command allows the network administrator to specify a 1584: router as a RIP neighbor. The `no neighbor a.b.c.d' command will 1585: disable the RIP neighbor. 1586: 1587: Below is very simple RIP configuration. Interface `eth0' and 1588: interface which address match to `10.0.0.0/8' are RIP enabled. 1589: 1590: ! 1591: router rip 1592: network 10.0.0.0/8 1593: network eth0 1594: ! 1595: 1596: Passive interface 1597: 1598: -- RIP command: passive-interface (IFNAME|default) 1599: -- RIP command: no passive-interface IFNAME 1600: This command sets the specified interface to passive mode. On 1601: passive mode interface, all receiving packets are processed as 1602: normal and ripd does not send either multicast or unicast RIP 1603: packets except to RIP neighbors specified with `neighbor' command. 1604: The interface may be specified as DEFAULT to make ripd default to 1605: passive on all interfaces. 1606: 1607: The default is to be passive on all interfaces. 1608: 1609: RIP split-horizon 1610: 1611: -- Interface command: ip split-horizon 1612: -- Interface command: no ip split-horizon 1613: Control split-horizon on the interface. Default is `ip 1614: split-horizon'. If you don't perform split-horizon on the 1615: interface, please specify `no ip split-horizon'. 1616: 1617: 1618: File: quagga.info, Node: RIP Version Control, Next: How to Announce RIP route, Prev: RIP Configuration, Up: RIP 1619: 1620: 5.3 RIP Version Control 1621: ======================= 1622: 1623: RIP can be configured to send either Version 1 or Version 2 packets. 1624: The default is to send RIPv2 while accepting both RIPv1 and RIPv2 (and 1625: replying with packets of the appropriate version for REQUESTS / 1626: triggered updates). The version to receive and send can be specified 1627: globally, and further overriden on a per-interface basis if needs be 1628: for send and receive seperately (see below). 1629: 1630: It is important to note that RIPv1 can not be authenticated. Further, 1631: if RIPv1 is enabled then RIP will reply to REQUEST packets, sending the 1632: state of its RIP routing table to any remote routers that ask on 1633: demand. For a more detailed discussion on the security implications of 1634: RIPv1 see *note RIP Authentication::. 1635: 1636: -- RIP Command: version VERSION 1637: Set RIP version to accept for reads and send. VERSION can be 1638: either `1" or `2". 1639: 1640: Disabling RIPv1 by specifying version 2 is STRONGLY encouraged, 1641: *Note RIP Authentication::. This may become the default in a future 1642: release. 1643: 1644: Default: Send Version 2, and accept either version. 1645: 1646: -- RIP Command: no version 1647: Reset the global version setting back to the default. 1648: 1649: -- Interface command: ip rip send version VERSION 1650: VERSION can be `1', `2' or `1 2'. 1651: 1652: This interface command overrides the global rip version setting, 1653: and selects which version of RIP to send packets with, for this 1654: interface specifically. Choice of RIP Version 1, RIP Version 2, or 1655: both versions. In the latter case, where `1 2' is specified, 1656: packets will be both broadcast and multicast. 1657: 1658: Default: Send packets according to the global version (version 2) 1659: 1660: -- Interface command: ip rip receive version VERSION 1661: VERSION can be `1', `2' or `1 2'. 1662: 1663: This interface command overrides the global rip version setting, 1664: and selects which versions of RIP packets will be accepted on this 1665: interface. Choice of RIP Version 1, RIP Version 2, or both. 1666: 1667: Default: Accept packets according to the global setting (both 1 1668: and 2). 1669: 1670: 1671: File: quagga.info, Node: How to Announce RIP route, Next: Filtering RIP Routes, Prev: RIP Version Control, Up: RIP 1672: 1673: 5.4 How to Announce RIP route 1674: ============================= 1675: 1676: -- RIP command: redistribute kernel 1677: -- RIP command: redistribute kernel metric <0-16> 1678: -- RIP command: redistribute kernel route-map ROUTE-MAP 1679: -- RIP command: no redistribute kernel 1680: `redistribute kernel' redistributes routing information from 1681: kernel route entries into the RIP tables. `no redistribute kernel' 1682: disables the routes. 1683: 1684: -- RIP command: redistribute static 1685: -- RIP command: redistribute static metric <0-16> 1686: -- RIP command: redistribute static route-map ROUTE-MAP 1687: -- RIP command: no redistribute static 1688: `redistribute static' redistributes routing information from 1689: static route entries into the RIP tables. `no redistribute static' 1690: disables the routes. 1691: 1692: -- RIP command: redistribute connected 1693: -- RIP command: redistribute connected metric <0-16> 1694: -- RIP command: redistribute connected route-map ROUTE-MAP 1695: -- RIP command: no redistribute connected 1696: Redistribute connected routes into the RIP tables. `no 1697: redistribute connected' disables the connected routes in the RIP 1698: tables. This command redistribute connected of the interface 1699: which RIP disabled. The connected route on RIP enabled interface 1700: is announced by default. 1701: 1702: -- RIP command: redistribute ospf 1703: -- RIP command: redistribute ospf metric <0-16> 1704: -- RIP command: redistribute ospf route-map ROUTE-MAP 1705: -- RIP command: no redistribute ospf 1706: `redistribute ospf' redistributes routing information from ospf 1707: route entries into the RIP tables. `no redistribute ospf' disables 1708: the routes. 1709: 1710: -- RIP command: redistribute bgp 1711: -- RIP command: redistribute bgp metric <0-16> 1712: -- RIP command: redistribute bgp route-map ROUTE-MAP 1713: -- RIP command: no redistribute bgp 1714: `redistribute bgp' redistributes routing information from bgp 1715: route entries into the RIP tables. `no redistribute bgp' disables 1716: the routes. 1717: 1718: If you want to specify RIP only static routes: 1719: 1720: -- RIP command: default-information originate 1721: 1722: -- RIP command: route A.B.C.D/M 1723: -- RIP command: no route A.B.C.D/M 1724: This command is specific to Quagga. The `route' command makes a 1725: static route only inside RIP. This command should be used only by 1726: advanced users who are particularly knowledgeable about the RIP 1727: protocol. In most cases, we recommend creating a static route in 1728: Quagga and redistributing it in RIP using `redistribute static'. 1729: 1730: 1731: File: quagga.info, Node: Filtering RIP Routes, Next: RIP Metric Manipulation, Prev: How to Announce RIP route, Up: RIP 1732: 1733: 5.5 Filtering RIP Routes 1734: ======================== 1735: 1736: RIP routes can be filtered by a distribute-list. 1737: 1738: -- Command: distribute-list ACCESS_LIST DIRECT IFNAME 1739: You can apply access lists to the interface with a 1740: `distribute-list' command. ACCESS_LIST is the access list name. 1741: DIRECT is `in' or `out'. If DIRECT is `in' the access list is 1742: applied to input packets. 1743: 1744: The `distribute-list' command can be used to filter the RIP path. 1745: `distribute-list' can apply access-lists to a chosen interface. 1746: First, one should specify the access-list. Next, the name of the 1747: access-list is used in the distribute-list command. For example, 1748: in the following configuration `eth0' will permit only the paths 1749: that match the route 10.0.0.0/8 1750: 1751: ! 1752: router rip 1753: distribute-list private in eth0 1754: ! 1755: access-list private permit 10 10.0.0.0/8 1756: access-list private deny any 1757: ! 1758: 1759: `distribute-list' can be applied to both incoming and outgoing data. 1760: 1761: -- Command: distribute-list prefix PREFIX_LIST (in|out) IFNAME 1762: You can apply prefix lists to the interface with a 1763: `distribute-list' command. PREFIX_LIST is the prefix list name. 1764: Next is the direction of `in' or `out'. If DIRECT is `in' the 1765: access list is applied to input packets. 1766: 1767: 1768: File: quagga.info, Node: RIP Metric Manipulation, Next: RIP distance, Prev: Filtering RIP Routes, Up: RIP 1769: 1770: 5.6 RIP Metric Manipulation 1771: =========================== 1772: 1773: RIP metric is a value for distance for the network. Usually `ripd' 1774: increment the metric when the network information is received. 1775: Redistributed routes' metric is set to 1. 1776: 1777: -- RIP command: default-metric <1-16> 1778: -- RIP command: no default-metric <1-16> 1779: This command modifies the default metric value for redistributed 1780: routes. The default value is 1. This command does not affect 1781: connected route even if it is redistributed by `redistribute 1782: connected'. To modify connected route's metric value, please use 1783: `redistribute connected metric' or `route-map'. `offset-list' also 1784: affects connected routes. 1785: 1786: -- RIP command: offset-list ACCESS-LIST (in|out) 1787: -- RIP command: offset-list ACCESS-LIST (in|out) IFNAME 1788: 1789: 1790: File: quagga.info, Node: RIP distance, Next: RIP route-map, Prev: RIP Metric Manipulation, Up: RIP 1791: 1792: 5.7 RIP distance 1793: ================ 1794: 1795: Distance value is used in zebra daemon. Default RIP distance is 120. 1796: 1797: -- RIP command: distance <1-255> 1798: -- RIP command: no distance <1-255> 1799: Set default RIP distance to specified value. 1800: 1801: -- RIP command: distance <1-255> A.B.C.D/M 1802: -- RIP command: no distance <1-255> A.B.C.D/M 1803: Set default RIP distance to specified value when the route's 1804: source IP address matches the specified prefix. 1805: 1806: -- RIP command: distance <1-255> A.B.C.D/M ACCESS-LIST 1807: -- RIP command: no distance <1-255> A.B.C.D/M ACCESS-LIST 1808: Set default RIP distance to specified value when the route's 1809: source IP address matches the specified prefix and the specified 1810: access-list. 1811: 1812: 1813: File: quagga.info, Node: RIP route-map, Next: RIP Authentication, Prev: RIP distance, Up: RIP 1814: 1815: 5.8 RIP route-map 1816: ================= 1817: 1818: Usage of `ripd''s route-map support. 1819: 1820: Optional argument route-map MAP_NAME can be added to each 1821: `redistribute' statement. 1822: 1823: redistribute static [route-map MAP_NAME] 1824: redistribute connected [route-map MAP_NAME] 1825: ..... 1826: 1827: Cisco applies route-map _before_ routes will exported to rip route 1828: table. In current Quagga's test implementation, `ripd' applies 1829: route-map after routes are listed in the route table and before routes 1830: will be announced to an interface (something like output filter). I 1831: think it is not so clear, but it is draft and it may be changed at 1832: future. 1833: 1834: Route-map statement (*note Route Map::) is needed to use route-map 1835: functionality. 1836: 1837: -- Route Map: match interface WORD 1838: This command match to incoming interface. Notation of this match 1839: is different from Cisco. Cisco uses a list of interfaces - NAME1 1840: NAME2 ... NAMEN. Ripd allows only one name (maybe will change in 1841: the future). Next - Cisco means interface which includes next-hop 1842: of routes (it is somewhat similar to "ip next-hop" statement). 1843: Ripd means interface where this route will be sent. This 1844: difference is because "next-hop" of same routes which sends to 1845: different interfaces must be different. Maybe it'd be better to 1846: made new matches - say "match interface-out NAME" or something 1847: like that. 1848: 1849: -- Route Map: match ip address WORD 1850: -- Route Map: match ip address prefix-list WORD 1851: Match if route destination is permitted by access-list. 1852: 1853: -- Route Map: match ip next-hop WORD 1854: -- Route Map: match ip next-hop prefix-list WORD 1855: Match if route next-hop (meaning next-hop listed in the rip 1856: route-table as displayed by "show ip rip") is permitted by 1857: access-list. 1858: 1859: -- Route Map: match metric <0-4294967295> 1860: This command match to the metric value of RIP updates. For other 1861: protocol compatibility metric range is shown as <0-4294967295>. 1862: But for RIP protocol only the value range <0-16> make sense. 1863: 1864: -- Route Map: set ip next-hop A.B.C.D 1865: This command set next hop value in RIPv2 protocol. This command 1866: does not affect RIPv1 because there is no next hop field in the 1867: packet. 1868: 1869: -- Route Map: set metric <0-4294967295> 1870: Set a metric for matched route when sending announcement. The 1871: metric value range is very large for compatibility with other 1872: protocols. For RIP, valid metric values are from 1 to 16. 1873: 1874: 1875: File: quagga.info, Node: RIP Authentication, Next: RIP Timers, Prev: RIP route-map, Up: RIP 1876: 1877: 5.9 RIP Authentication 1878: ====================== 1879: 1880: RIPv2 allows packets to be authenticated via either an insecure plain 1881: text password, included with the packet, or via a more secure MD5 based 1882: HMAC (keyed-Hashing for Message AuthentiCation), RIPv1 can not be 1883: authenticated at all, thus when authentication is configured `ripd' 1884: will discard routing updates received via RIPv1 packets. 1885: 1886: However, unless RIPv1 reception is disabled entirely, *Note RIP 1887: Version Control::, RIPv1 REQUEST packets which are received, which 1888: query the router for routing information, will still be honoured by 1889: `ripd', and `ripd' WILL reply to such packets. This allows `ripd' to 1890: honour such REQUESTs (which sometimes is used by old equipment and very 1891: simple devices to bootstrap their default route), while still providing 1892: security for route updates which are received. 1893: 1894: In short: Enabling authentication prevents routes being updated by 1895: unauthenticated remote routers, but still can allow routes (I.e. the 1896: entire RIP routing table) to be queried remotely, potentially by anyone 1897: on the internet, via RIPv1. 1898: 1899: To prevent such unauthenticated querying of routes disable RIPv1, 1900: *Note RIP Version Control::. 1901: 1902: -- Interface command: ip rip authentication mode md5 1903: -- Interface command: no ip rip authentication mode md5 1904: Set the interface with RIPv2 MD5 authentication. 1905: 1906: -- Interface command: ip rip authentication mode text 1907: -- Interface command: no ip rip authentication mode text 1908: Set the interface with RIPv2 simple password authentication. 1909: 1910: -- Interface command: ip rip authentication string STRING 1911: -- Interface command: no ip rip authentication string STRING 1912: RIP version 2 has simple text authentication. This command sets 1913: authentication string. The string must be shorter than 16 1914: characters. 1915: 1916: -- Interface command: ip rip authentication key-chain KEY-CHAIN 1917: -- Interface command: no ip rip authentication key-chain KEY-CHAIN 1918: Specifiy Keyed MD5 chain. 1919: 1920: ! 1921: key chain test 1922: key 1 1923: key-string test 1924: ! 1925: interface eth1 1926: ip rip authentication mode md5 1927: ip rip authentication key-chain test 1928: ! 1929: 1930: 1931: File: quagga.info, Node: RIP Timers, Next: Show RIP Information, Prev: RIP Authentication, Up: RIP 1932: 1933: 5.10 RIP Timers 1934: =============== 1935: 1936: -- RIP command: timers basic UPDATE TIMEOUT GARBAGE 1937: RIP protocol has several timers. User can configure those timers' 1938: values by `timers basic' command. 1939: 1940: The default settings for the timers are as follows: 1941: 1942: * The update timer is 30 seconds. Every update timer seconds, 1943: the RIP process is awakened to send an unsolicited Response 1944: message containing the complete routing table to all 1945: neighboring RIP routers. 1946: 1947: * The timeout timer is 180 seconds. Upon expiration of the 1948: timeout, the route is no longer valid; however, it is 1949: retained in the routing table for a short time so that 1950: neighbors can be notified that the route has been dropped. 1951: 1952: * The garbage collect timer is 120 seconds. Upon expiration of 1953: the garbage-collection timer, the route is finally removed 1954: from the routing table. 1955: 1956: 1957: The `timers basic' command allows the the default values of the 1958: timers listed above to be changed. 1959: 1960: -- RIP command: no timers basic 1961: The `no timers basic' command will reset the timers to the default 1962: settings listed above. 1963: 1964: 1965: File: quagga.info, Node: Show RIP Information, Next: RIP Debug Commands, Prev: RIP Timers, Up: RIP 1966: 1967: 5.11 Show RIP Information 1968: ========================= 1969: 1970: To display RIP routes. 1971: 1972: -- Command: show ip rip 1973: Show RIP routes. 1974: 1975: The command displays all RIP routes. For routes that are received 1976: through RIP, this command will display the time the packet was sent and 1977: the tag information. This command will also display this information 1978: for routes redistributed into RIP. 1979: 1980: -- Command: show ip protocols 1981: The command displays current RIP status. It includes RIP timer, 1982: filtering, version, RIP enabled interface and RIP peer inforation. 1983: 1984: ripd> show ip protocols 1985: Routing Protocol is "rip" 1986: Sending updates every 30 seconds with +/-50%, next due in 35 seconds 1987: Timeout after 180 seconds, garbage collect after 120 seconds 1988: Outgoing update filter list for all interface is not set 1989: Incoming update filter list for all interface is not set 1990: Default redistribution metric is 1 1991: Redistributing: kernel connected 1992: Default version control: send version 2, receive version 2 1993: Interface Send Recv 1994: Routing for Networks: 1995: eth0 1996: eth1 1997: 1.1.1.1 1998: 203.181.89.241 1999: Routing Information Sources: 2000: Gateway BadPackets BadRoutes Distance Last Update 2001: 2002: 2003: File: quagga.info, Node: RIP Debug Commands, Prev: Show RIP Information, Up: RIP 2004: 2005: 5.12 RIP Debug Commands 2006: ======================= 2007: 2008: Debug for RIP protocol. 2009: 2010: -- Command: debug rip events 2011: Debug rip events. 2012: 2013: `debug rip' will show RIP events. Sending and receiving packets, 2014: timers, and changes in interfaces are events shown with `ripd'. 2015: 2016: -- Command: debug rip packet 2017: Debug rip packet. 2018: 2019: `debug rip packet' will display detailed information about the RIP 2020: packets. The origin and port number of the packet as well as a packet 2021: dump is shown. 2022: 2023: -- Command: debug rip zebra 2024: Debug rip between zebra communication. 2025: 2026: This command will show the communication between `ripd' and `zebra'. 2027: The main information will include addition and deletion of paths to the 2028: kernel and the sending and receiving of interface information. 2029: 2030: -- Command: show debugging rip 2031: Display `ripd''s debugging option. 2032: 2033: `show debugging rip' will show all information currently set for ripd 2034: debug. 2035: 2036: 2037: File: quagga.info, Node: RIPng, Next: OSPFv2, Prev: RIP, Up: Top 2038: 2039: 6 RIPng 2040: ******* 2041: 2042: `ripngd' supports the RIPng protocol as described in RFC2080. It's an 2043: IPv6 reincarnation of the RIP protocol. 2044: 2045: * Menu: 2046: 2047: * Invoking ripngd:: 2048: * ripngd Configuration:: 2049: * ripngd Terminal Mode Commands:: 2050: * ripngd Filtering Commands:: 2051: 2052: 2053: File: quagga.info, Node: Invoking ripngd, Next: ripngd Configuration, Up: RIPng 2054: 2055: 6.1 Invoking ripngd 2056: =================== 2057: 2058: There are no `ripngd' specific invocation options. Common options can 2059: be specified (*note Common Invocation Options::). 2060: 2061: 2062: File: quagga.info, Node: ripngd Configuration, Next: ripngd Terminal Mode Commands, Prev: Invoking ripngd, Up: RIPng 2063: 2064: 6.2 ripngd Configuration 2065: ======================== 2066: 2067: Currently ripngd supports the following commands: 2068: 2069: -- Command: router ripng 2070: Enable RIPng. 2071: 2072: -- RIPng Command: flush_timer TIME 2073: Set flush timer. 2074: 2075: -- RIPng Command: network NETWORK 2076: Set RIPng enabled interface by NETWORK 2077: 2078: -- RIPng Command: network IFNAME 2079: Set RIPng enabled interface by IFNAME 2080: 2081: -- RIPng Command: route NETWORK 2082: Set RIPng static routing announcement of NETWORK. 2083: 2084: -- Command: router zebra 2085: This command is the default and does not appear in the 2086: configuration. With this statement, RIPng routes go to the 2087: `zebra' daemon. 2088: 2089: 2090: File: quagga.info, Node: ripngd Terminal Mode Commands, Next: ripngd Filtering Commands, Prev: ripngd Configuration, Up: RIPng 2091: 2092: 6.3 ripngd Terminal Mode Commands 2093: ================================= 2094: 2095: -- Command: show ip ripng 2096: 2097: -- Command: show debugging ripng 2098: 2099: -- Command: debug ripng events 2100: 2101: -- Command: debug ripng packet 2102: 2103: -- Command: debug ripng zebra 2104: 2105: 2106: File: quagga.info, Node: ripngd Filtering Commands, Prev: ripngd Terminal Mode Commands, Up: RIPng 2107: 2108: 6.4 ripngd Filtering Commands 2109: ============================= 2110: 2111: -- Command: distribute-list ACCESS_LIST (in|out) IFNAME 2112: You can apply an access-list to the interface using the 2113: `distribute-list' command. ACCESS_LIST is an access-list name. 2114: DIRECT is `in' or `out'. If DIRECT is `in', the access-list is 2115: applied only to incoming packets. 2116: 2117: distribute-list local-only out sit1 2118: 2119: 2120: File: quagga.info, Node: OSPFv2, Next: OSPFv3, Prev: RIPng, Up: Top 2121: 2122: 7 OSPFv2 2123: ******** 2124: 2125: OSPF (Open Shortest Path First) version 2 is a routing protocol which 2126: is described in `RFC2328, OSPF Version 2'. OSPF is an IGP (Interior 2127: Gateway Protocol). Compared with RIP, OSPF can provide scalable 2128: network support and faster convergence times. OSPF is widely used in 2129: large networks such as ISP (Internet Service Provider) backbone and 2130: enterprise networks. 2131: 2132: * Menu: 2133: 2134: * Configuring ospfd:: 2135: * OSPF router:: 2136: * OSPF area:: 2137: * OSPF interface:: 2138: * Redistribute routes to OSPF:: 2139: * Showing OSPF information:: 2140: * Debugging OSPF:: 2141: * OSPF Configuration Examples:: 2142: 2143: 2144: File: quagga.info, Node: Configuring ospfd, Next: OSPF router, Up: OSPFv2 2145: 2146: 7.1 Configuring ospfd 2147: ===================== 2148: 2149: There are no `ospfd' specific options. Common options can be specified 2150: (*note Common Invocation Options::) to `ospfd'. `ospfd' needs to 2151: acquire interface information from `zebra' in order to function. 2152: Therefore `zebra' must be running before invoking `ospfd'. Also, if 2153: `zebra' is restarted then `ospfd' must be too. 2154: 2155: Like other daemons, `ospfd' configuration is done in OSPF specific 2156: configuration file `ospfd.conf'. 2157: 2158: 2159: File: quagga.info, Node: OSPF router, Next: OSPF area, Prev: Configuring ospfd, Up: OSPFv2 2160: 2161: 7.2 OSPF router 2162: =============== 2163: 2164: To start OSPF process you have to specify the OSPF router. As of this 2165: writing, `ospfd' does not support multiple OSPF processes. 2166: 2167: -- Command: router ospf 2168: -- Command: no router ospf 2169: Enable or disable the OSPF process. `ospfd' does not yet support 2170: multiple OSPF processes. So you can not specify an OSPF process 2171: number. 2172: 2173: -- OSPF Command: ospf router-id A.B.C.D 2174: -- OSPF Command: no ospf router-id 2175: This sets the router-ID of the OSPF process. The router-ID may be 2176: an IP address of the router, but need not be - it can be any 2177: arbitrary 32bit number. However it MUST be unique within the 2178: entire OSPF domain to the OSPF speaker - bad things will happen if 2179: multiple OSPF speakers are configured with the same router-ID! If 2180: one is not specified then `ospfd' will obtain a router-ID 2181: automatically from `zebra'. 2182: 2183: -- OSPF Command: ospf abr-type TYPE 2184: -- OSPF Command: no ospf abr-type TYPE 2185: TYPE can be cisco|ibm|shortcut|standard. The "Cisco" and "IBM" 2186: types are equivalent. 2187: 2188: The OSPF standard for ABR behaviour does not allow an ABR to 2189: consider routes through non-backbone areas when its links to the 2190: backbone are down, even when there are other ABRs in attached 2191: non-backbone areas which still can reach the backbone - this 2192: restriction exists primarily to ensure routing-loops are avoided. 2193: 2194: With the "Cisco" or "IBM" ABR type, the default in this release of 2195: Quagga, this restriction is lifted, allowing an ABR to consider 2196: summaries learnt from other ABRs through non-backbone areas, and 2197: hence route via non-backbone areas as a last resort when, and only 2198: when, backbone links are down. 2199: 2200: Note that areas with fully-adjacent virtual-links are considered 2201: to be "transit capable" and can always be used to route backbone 2202: traffic, and hence are unaffected by this setting (*note OSPF 2203: virtual-link::). 2204: 2205: More information regarding the behaviour controlled by this 2206: command can be found in `RFC 3509, Alternative Implementations of 2207: OSPF Area Border Routers', and 2208: `draft-ietf-ospf-shortcut-abr-02.txt'. 2209: 2210: Quote: "Though the definition of the ABR (Area Border Router) in 2211: the OSPF specification does not require a router with multiple 2212: attached areas to have a backbone connection, it is actually 2213: necessary to provide successful routing to the inter-area and 2214: external destinations. If this requirement is not met, all traffic 2215: destined for the areas not connected to such an ABR or out of the 2216: OSPF domain, is dropped. This document describes alternative ABR 2217: behaviors implemented in Cisco and IBM routers." 2218: 2219: -- OSPF Command: ospf rfc1583compatibility 2220: -- OSPF Command: no ospf rfc1583compatibility 2221: `RFC2328', the sucessor to `RFC1583', suggests according to 2222: section G.2 (changes) in section 16.4 a change to the path 2223: preference algorithm that prevents possible routing loops that were 2224: possible in the old version of OSPFv2. More specifically it demands 2225: that inter-area paths and intra-area backbone path are now of 2226: equal preference but still both preferred to external paths. 2227: 2228: This command should NOT be set normally. 2229: 2230: -- OSPF Command: log-adjacency-changes [detail] 2231: -- OSPF Command: no log-adjacency-changes [detail] 2232: Configures ospfd to log changes in adjacency. With the optional 2233: detail argument, all changes in adjacency status are shown. 2234: Without detail, only changes to full or regressions are shown. 2235: 2236: -- OSPF Command: passive-interface INTERFACE 2237: -- OSPF Command: no passive-interface INTERFACE 2238: Do not speak OSPF interface on the given interface, but do 2239: advertise the interface as a stub link in the router-LSA (Link 2240: State Advertisement) for this router. This allows one to advertise 2241: addresses on such connected interfaces without having to originate 2242: AS-External/Type-5 LSAs (which have global flooding scope) - as 2243: would occur if connected addresses were redistributed into OSPF 2244: (*note Redistribute routes to OSPF::). This is the only way to 2245: advertise non-OSPF links into stub areas. 2246: 2247: -- OSPF Command: timers throttle spf DELAY INITIAL-HOLDTIME 2248: MAX-HOLDTIME 2249: -- OSPF Command: no timers throttle spf 2250: This command sets the initial DELAY, the INITIAL-HOLDTIME and the 2251: MAXIMUM-HOLDTIME between when SPF is calculated and the event 2252: which triggered the calculation. The times are specified in 2253: milliseconds and must be in the range of 0 to 600000 milliseconds. 2254: 2255: The DELAY specifies the minimum amount of time to delay SPF 2256: calculation (hence it affects how long SPF calculation is delayed 2257: after an event which occurs outside of the holdtime of any 2258: previous SPF calculation, and also serves as a minimum holdtime). 2259: 2260: Consecutive SPF calculations will always be seperated by at least 2261: 'hold-time' milliseconds. The hold-time is adaptive and initially 2262: is set to the INITIAL-HOLDTIME configured with the above command. 2263: Events which occur within the holdtime of the previous SPF 2264: calculation will cause the holdtime to be increased by 2265: INITIAL-HOLDTIME, bounded by the MAXIMUM-HOLDTIME configured with 2266: this command. If the adaptive hold-time elapses without any 2267: SPF-triggering event occuring then the current holdtime is reset 2268: to the INITIAL-HOLDTIME. The current holdtime can be viewed with 2269: *note show ip ospf::, where it is expressed as a multiplier of the 2270: INITIAL-HOLDTIME. 2271: 2272: router ospf 2273: timers throttle spf 200 400 10000 2274: 2275: In this example, the DELAY is set to 200ms, the INITIAL HOLDTIME 2276: is set to 400ms and the MAXIMUM HOLDTIME to 10s. Hence there will 2277: always be at least 200ms between an event which requires SPF 2278: calculation and the actual SPF calculation. Further consecutive SPF 2279: calculations will always be seperated by between 400ms to 10s, the 2280: hold-time increasing by 400ms each time an SPF-triggering event 2281: occurs within the hold-time of the previous SPF calculation. 2282: 2283: This command supercedes the `timers spf' command in previous Quagga 2284: releases. 2285: 2286: -- OSPF Command: max-metric router-lsa [on-startup|on-shutdown] 2287: <5-86400> 2288: -- OSPF Command: max-metric router-lsa administrative 2289: -- OSPF Command: no max-metric router-lsa 2290: [on-startup|on-shutdown|administrative] 2291: This enables `RFC3137, OSPF Stub Router Advertisement' support, 2292: where the OSPF process describes its transit links in its 2293: router-LSA as having infinite distance so that other routers will 2294: avoid calculating transit paths through the router while still 2295: being able to reach networks through the router. 2296: 2297: This support may be enabled administratively (and indefinitely) or 2298: conditionally. Conditional enabling of max-metric router-lsas can 2299: be for a period of seconds after startup and/or for a period of 2300: seconds prior to shutdown. 2301: 2302: Enabling this for a period after startup allows OSPF to converge 2303: fully first without affecting any existing routes used by other 2304: routers, while still allowing any connected stub links and/or 2305: redistributed routes to be reachable. Enabling this for a period 2306: of time in advance of shutdown allows the router to gracefully 2307: excuse itself from the OSPF domain. 2308: 2309: Enabling this feature administratively allows for administrative 2310: intervention for whatever reason, for an indefinite period of time. 2311: Note that if the configuration is written to file, this 2312: administrative form of the stub-router command will also be 2313: written to file. If `ospfd' is restarted later, the command will 2314: then take effect until manually deconfigured. 2315: 2316: Configured state of this feature as well as current status, such 2317: as the number of second remaining till on-startup or on-shutdown 2318: ends, can be viewed with the *note show ip ospf:: command. 2319: 2320: -- OSPF Command: auto-cost reference-bandwidth <1-4294967> 2321: -- OSPF Command: no auto-cost reference-bandwidth 2322: This sets the reference bandwidth for cost calculations, where 2323: this bandwidth is considered equivalent to an OSPF cost of 1, 2324: specified in Mbits/s. The default is 100Mbit/s (i.e. a link of 2325: bandwidth 100Mbit/s or higher will have a cost of 1. Cost of lower 2326: bandwidth links will be scaled with reference to this cost). 2327: 2328: This configuration setting MUST be consistent across all routers 2329: within the OSPF domain. 2330: 2331: -- OSPF Command: network A.B.C.D/M area A.B.C.D 2332: -- OSPF Command: network A.B.C.D/M area <0-4294967295> 2333: -- OSPF Command: no network A.B.C.D/M area A.B.C.D 2334: -- OSPF Command: no network A.B.C.D/M area <0-4294967295> 2335: This command specifies the OSPF enabled interface(s). If the 2336: interface has an address from range 192.168.1.0/24 then the 2337: command below enables ospf on this interface so router can provide 2338: network information to the other ospf routers via this interface. 2339: 2340: router ospf 2341: network 192.168.1.0/24 area 0.0.0.0 2342: 2343: Prefix length in interface must be equal or bigger (ie. smaller 2344: network) than prefix length in network statement. For example 2345: statement above doesn't enable ospf on interface with address 2346: 192.168.1.1/23, but it does on interface with address 2347: 192.168.1.129/25. 2348: 2349: Note that the behavior when there is a peer address defined on an 2350: interface changed after release 0.99.7. Currently, if a peer 2351: prefix has been configured, then we test whether the prefix in the 2352: network command contains the destination prefix. Otherwise, we 2353: test whether the network command prefix contains the local address 2354: prefix of the interface. 2355: 2356: 2357: File: quagga.info, Node: OSPF area, Next: OSPF interface, Prev: OSPF router, Up: OSPFv2 2358: 2359: 7.3 OSPF area 2360: ============= 2361: 2362: -- OSPF Command: area A.B.C.D range A.B.C.D/M 2363: -- OSPF Command: area <0-4294967295> range A.B.C.D/M 2364: -- OSPF Command: no area A.B.C.D range A.B.C.D/M 2365: -- OSPF Command: no area <0-4294967295> range A.B.C.D/M 2366: Summarize intra area paths from specified area into one Type-3 2367: summary-LSA announced to other areas. This command can be used 2368: only in ABR and ONLY router-LSAs (Type-1) and network-LSAs 2369: (Type-2) (ie. LSAs with scope area) can be summarized. Type-5 2370: AS-external-LSAs can't be summarized - their scope is AS. 2371: Summarizing Type-7 AS-external-LSAs isn't supported yet by Quagga. 2372: 2373: router ospf 2374: network 192.168.1.0/24 area 0.0.0.0 2375: network 10.0.0.0/8 area 0.0.0.10 2376: area 0.0.0.10 range 10.0.0.0/8 2377: 2378: With configuration above one Type-3 Summary-LSA with routing info 2379: 10.0.0.0/8 is announced into backbone area if area 0.0.0.10 2380: contains at least one intra-area network (ie. described with 2381: router or network LSA) from this range. 2382: 2383: -- OSPF Command: area A.B.C.D range IPV4_PREFIX not-advertise 2384: -- OSPF Command: no area A.B.C.D range IPV4_PREFIX not-advertise 2385: Instead of summarizing intra area paths filter them - ie. intra 2386: area paths from this range are not advertised into other areas. 2387: This command makes sense in ABR only. 2388: 2389: -- OSPF Command: area A.B.C.D range IPV4_PREFIX substitute IPV4_PREFIX 2390: -- OSPF Command: no area A.B.C.D range IPV4_PREFIX substitute 2391: IPV4_PREFIX 2392: Substitute summarized prefix with another prefix. 2393: 2394: router ospf 2395: network 192.168.1.0/24 area 0.0.0.0 2396: network 10.0.0.0/8 area 0.0.0.10 2397: area 0.0.0.10 range 10.0.0.0/8 substitute 11.0.0.0/8 2398: 2399: One Type-3 summary-LSA with routing info 11.0.0.0/8 is announced 2400: into backbone area if area 0.0.0.10 contains at least one 2401: intra-area network (ie. described with router-LSA or network-LSA) 2402: from range 10.0.0.0/8. This command makes sense in ABR only. 2403: 2404: -- OSPF Command: area A.B.C.D virtual-link A.B.C.D 2405: -- OSPF Command: area <0-4294967295> virtual-link A.B.C.D 2406: -- OSPF Command: no area A.B.C.D virtual-link A.B.C.D 2407: -- OSPF Command: no area <0-4294967295> virtual-link A.B.C.D 2408: 2409: -- OSPF Command: area A.B.C.D shortcut 2410: -- OSPF Command: area <0-4294967295> shortcut 2411: -- OSPF Command: no area A.B.C.D shortcut 2412: -- OSPF Command: no area <0-4294967295> shortcut 2413: Configure the area as Shortcut capable. See `RFC3509'. This 2414: requires that the 'abr-type' be set to 'shortcut'. 2415: 2416: -- OSPF Command: area A.B.C.D stub 2417: -- OSPF Command: area <0-4294967295> stub 2418: -- OSPF Command: no area A.B.C.D stub 2419: -- OSPF Command: no area <0-4294967295> stub 2420: Configure the area to be a stub area. That is, an area where no 2421: router originates routes external to OSPF and hence an area where 2422: all external routes are via the ABR(s). Hence, ABRs for such an 2423: area do not need to pass AS-External LSAs (type-5s) or 2424: ASBR-Summary LSAs (type-4) into the area. They need only pass 2425: Network-Summary (type-3) LSAs into such an area, along with a 2426: default-route summary. 2427: 2428: -- OSPF Command: area A.B.C.D stub no-summary 2429: -- OSPF Command: area <0-4294967295> stub no-summary 2430: -- OSPF Command: no area A.B.C.D stub no-summary 2431: -- OSPF Command: no area <0-4294967295> stub no-summary 2432: Prevents an `ospfd' ABR from injecting inter-area summaries into 2433: the specified stub area. 2434: 2435: -- OSPF Command: area A.B.C.D default-cost <0-16777215> 2436: -- OSPF Command: no area A.B.C.D default-cost <0-16777215> 2437: Set the cost of default-summary LSAs announced to stubby areas. 2438: 2439: -- OSPF Command: area A.B.C.D export-list NAME 2440: -- OSPF Command: area <0-4294967295> export-list NAME 2441: -- OSPF Command: no area A.B.C.D export-list NAME 2442: -- OSPF Command: no area <0-4294967295> export-list NAME 2443: Filter Type-3 summary-LSAs announced to other areas originated 2444: from intra- area paths from specified area. 2445: 2446: router ospf 2447: network 192.168.1.0/24 area 0.0.0.0 2448: network 10.0.0.0/8 area 0.0.0.10 2449: area 0.0.0.10 export-list foo 2450: ! 2451: access-list foo permit 10.10.0.0/16 2452: access-list foo deny any 2453: 2454: With example above any intra-area paths from area 0.0.0.10 and 2455: from range 10.10.0.0/16 (for example 10.10.1.0/24 and 2456: 10.10.2.128/30) are announced into other areas as Type-3 2457: summary-LSA's, but any others (for example 10.11.0.0/16 or 2458: 10.128.30.16/30) aren't. 2459: 2460: This command is only relevant if the router is an ABR for the 2461: specified area. 2462: 2463: -- OSPF Command: area A.B.C.D import-list NAME 2464: -- OSPF Command: area <0-4294967295> import-list NAME 2465: -- OSPF Command: no area A.B.C.D import-list NAME 2466: -- OSPF Command: no area <0-4294967295> import-list NAME 2467: Same as export-list, but it applies to paths announced into 2468: specified area as Type-3 summary-LSAs. 2469: 2470: -- OSPF Command: area A.B.C.D filter-list prefix NAME in 2471: -- OSPF Command: area A.B.C.D filter-list prefix NAME out 2472: -- OSPF Command: area <0-4294967295> filter-list prefix NAME in 2473: -- OSPF Command: area <0-4294967295> filter-list prefix NAME out 2474: -- OSPF Command: no area A.B.C.D filter-list prefix NAME in 2475: -- OSPF Command: no area A.B.C.D filter-list prefix NAME out 2476: -- OSPF Command: no area <0-4294967295> filter-list prefix NAME in 2477: -- OSPF Command: no area <0-4294967295> filter-list prefix NAME out 2478: Filtering Type-3 summary-LSAs to/from area using prefix lists. 2479: This command makes sense in ABR only. 2480: 2481: -- OSPF Command: area A.B.C.D authentication 2482: -- OSPF Command: area <0-4294967295> authentication 2483: -- OSPF Command: no area A.B.C.D authentication 2484: -- OSPF Command: no area <0-4294967295> authentication 2485: Specify that simple password authentication should be used for the 2486: given area. 2487: 2488: -- OSPF Command: area A.B.C.D authentication message-digest 2489: -- OSPF Command: area <0-4294967295> authentication message-digest 2490: Specify that OSPF packets must be authenticated with MD5 HMACs 2491: within the given area. Keying material must also be configured on 2492: a per-interface basis (*note ip ospf message-digest-key::). 2493: 2494: MD5 authentication may also be configured on a per-interface basis 2495: (*note ip ospf authentication message-digest::). Such per-interface 2496: settings will override any per-area authentication setting. 2497: 2498: 2499: File: quagga.info, Node: OSPF interface, Next: Redistribute routes to OSPF, Prev: OSPF area, Up: OSPFv2 2500: 2501: 7.4 OSPF interface 2502: ================== 2503: 2504: -- Interface Command: ip ospf authentication-key AUTH_KEY 2505: -- Interface Command: no ip ospf authentication-key 2506: Set OSPF authentication key to a simple password. After setting 2507: AUTH_KEY, all OSPF packets are authenticated. AUTH_KEY has length 2508: up to 8 chars. 2509: 2510: Simple text password authentication is insecure and deprecated in 2511: favour of MD5 HMAC authentication (*note ip ospf authentication 2512: message-digest::). 2513: 2514: -- Interface Command: ip ospf authentication message-digest 2515: Specify that MD5 HMAC authentication must be used on this 2516: interface. MD5 keying material must also be configured (*note ip 2517: ospf message-digest-key::). Overrides any authentication enabled 2518: on a per-area basis (*note area authentication message-digest::). 2519: 2520: Note that OSPF MD5 authentication requires that time never go 2521: backwards (correct time is NOT important, only that it never goes 2522: backwards), even across resets, if ospfd is to be able to promptly 2523: reestabish adjacencies with its neighbours after restarts/reboots. 2524: The host should have system time be set at boot from an external 2525: or non-volatile source (eg battery backed clock, NTP, etc.) or 2526: else the system clock should be periodically saved to non-volative 2527: storage and restored at boot if MD5 authentication is to be 2528: expected to work reliably. 2529: 2530: -- Interface Command: ip ospf message-digest-key KEYID md5 KEY 2531: -- Interface Command: no ip ospf message-digest-key 2532: Set OSPF authentication key to a cryptographic password. The 2533: cryptographic algorithm is MD5. 2534: 2535: KEYID identifies secret key used to create the message digest. 2536: This ID is part of the protocol and must be consistent across 2537: routers on a link. 2538: 2539: KEY is the actual message digest key, of up to 16 chars (larger 2540: strings will be truncated), and is associated with the given KEYID. 2541: 2542: -- Interface Command: ip ospf cost <1-65535> 2543: -- Interface Command: no ip ospf cost 2544: Set link cost for the specified interface. The cost value is set 2545: to router-LSA's metric field and used for SPF calculation. 2546: 2547: -- Interface Command: ip ospf dead-interval <1-65535> 2548: -- Interface Command: ip ospf dead-interval minimal hello-multiplier 2549: <2-20> 2550: -- Interface Command: no ip ospf dead-interval 2551: Set number of seconds for RouterDeadInterval timer value used for 2552: Wait Timer and Inactivity Timer. This value must be the same for 2553: all routers attached to a common network. The default value is 40 2554: seconds. 2555: 2556: If 'minimal' is specified instead, then the dead-interval is set 2557: to 1 second and one must specify a hello-multiplier. The 2558: hello-multiplier specifies how many Hellos to send per second, 2559: from 2 (every 500ms) to 20 (every 50ms). Thus one can have 1s 2560: convergence time for OSPF. If this form is specified, then the 2561: hello-interval advertised in Hello packets is set to 0 and the 2562: hello-interval on received Hello packets is not checked, thus the 2563: hello-multiplier need NOT be the same across multiple routers on a 2564: common link. 2565: 2566: -- Interface Command: ip ospf hello-interval <1-65535> 2567: -- Interface Command: no ip ospf hello-interval 2568: Set number of seconds for HelloInterval timer value. Setting this 2569: value, Hello packet will be sent every timer value seconds on the 2570: specified interface. This value must be the same for all routers 2571: attached to a common network. The default value is 10 seconds. 2572: 2573: This command has no effect if *note ip ospf dead-interval 2574: minimal:: is also specified for the interface. 2575: 2576: -- Interface Command: ip ospf network 2577: (broadcast|non-broadcast|point-to-multipoint|point-to-point) 2578: -- Interface Command: no ip ospf network 2579: Set explicitly network type for specifed interface. 2580: 2581: -- Interface Command: ip ospf priority <0-255> 2582: -- Interface Command: no ip ospf priority 2583: Set RouterPriority integer value. The router with the highest 2584: priority will be more eligible to become Designated Router. 2585: Setting the value to 0, makes the router ineligible to become 2586: Designated Router. The default value is 1. 2587: 2588: -- Interface Command: ip ospf retransmit-interval <1-65535> 2589: -- Interface Command: no ip ospf retransmit interval 2590: Set number of seconds for RxmtInterval timer value. This value is 2591: used when retransmitting Database Description and Link State 2592: Request packets. The default value is 5 seconds. 2593: 2594: -- Interface Command: ip ospf transmit-delay 2595: -- Interface Command: no ip ospf transmit-delay 2596: Set number of seconds for InfTransDelay value. LSAs' age should be 2597: incremented by this value when transmitting. The default value is 2598: 1 seconds. 2599: 2600: 2601: File: quagga.info, Node: Redistribute routes to OSPF, Next: Showing OSPF information, Prev: OSPF interface, Up: OSPFv2 2602: 2603: 7.5 Redistribute routes to OSPF 2604: =============================== 2605: 2606: -- OSPF Command: redistribute (kernel|connected|static|rip|bgp) 2607: -- OSPF Command: redistribute (kernel|connected|static|rip|bgp) 2608: ROUTE-MAP 2609: -- OSPF Command: redistribute (kernel|connected|static|rip|bgp) 2610: metric-type (1|2) 2611: -- OSPF Command: redistribute (kernel|connected|static|rip|bgp) 2612: metric-type (1|2) route-map WORD 2613: -- OSPF Command: redistribute (kernel|connected|static|rip|bgp) metric 2614: <0-16777214> 2615: -- OSPF Command: redistribute (kernel|connected|static|rip|bgp) metric 2616: <0-16777214> route-map WORD 2617: -- OSPF Command: redistribute (kernel|connected|static|rip|bgp) 2618: metric-type (1|2) metric <0-16777214> 2619: -- OSPF Command: redistribute (kernel|connected|static|rip|bgp) 2620: metric-type (1|2) metric <0-16777214> route-map WORD 2621: -- OSPF Command: no redistribute (kernel|connected|static|rip|bgp) 2622: Redistribute routes of the specified protocol or kind into OSPF, 2623: with the metric type and metric set if specified, filtering the 2624: routes using the given route-map if specified. Redistributed 2625: routes may also be filtered with distribute-lists, see *note ospf 2626: distribute-list::. 2627: 2628: Redistributed routes are distributed as into OSPF as Type-5 2629: External LSAs into links to areas that accept external routes, 2630: Type-7 External LSAs for NSSA areas and are not redistributed at 2631: all into Stub areas, where external routes are not permitted. 2632: 2633: Note that for connected routes, one may instead use 2634: "passive-interface", see *note OSPF passive-interface::. 2635: 2636: -- OSPF Command: default-information originate 2637: -- OSPF Command: default-information originate metric <0-16777214> 2638: -- OSPF Command: default-information originate metric <0-16777214> 2639: metric-type (1|2) 2640: -- OSPF Command: default-information originate metric <0-16777214> 2641: metric-type (1|2) route-map WORD 2642: -- OSPF Command: default-information originate always 2643: -- OSPF Command: default-information originate always metric 2644: <0-16777214> 2645: -- OSPF Command: default-information originate always metric 2646: <0-16777214> metric-type (1|2) 2647: -- OSPF Command: default-information originate always metric 2648: <0-16777214> metric-type (1|2) route-map WORD 2649: -- OSPF Command: no default-information originate 2650: Originate an AS-External (type-5) LSA describing a default route 2651: into all external-routing capable areas, of the specified metric 2652: and metric type. If the 'always' keyword is given then the default 2653: is always advertised, even when there is no default present in the 2654: routing table. 2655: 2656: -- OSPF Command: distribute-list NAME out 2657: (kernel|connected|static|rip|ospf 2658: -- OSPF Command: no distribute-list NAME out 2659: (kernel|connected|static|rip|ospf 2660: Apply the access-list filter, NAME, to redistributed routes of the 2661: given type before allowing the routes to redistributed into OSPF 2662: (*note OSPF redistribute::). 2663: 2664: -- OSPF Command: default-metric <0-16777214> 2665: -- OSPF Command: no default-metric 2666: 2667: -- OSPF Command: distance <1-255> 2668: -- OSPF Command: no distance <1-255> 2669: 2670: -- OSPF Command: distance ospf (intra-area|inter-area|external) 2671: <1-255> 2672: -- OSPF Command: no distance ospf 2673: 2674: 2675: File: quagga.info, Node: Showing OSPF information, Next: Debugging OSPF, Prev: Redistribute routes to OSPF, Up: OSPFv2 2676: 2677: 7.6 Showing OSPF information 2678: ============================ 2679: 2680: -- Command: show ip ospf 2681: Show information on a variety of general OSPF and area state and 2682: configuration information. 2683: 2684: -- Command: show ip ospf interface [INTERFACE] 2685: Show state and configuration of OSPF the specified interface, or 2686: all interfaces if no interface is given. 2687: 2688: -- Command: show ip ospf neighbor 2689: -- Command: show ip ospf neighbor INTERFACE 2690: -- Command: show ip ospf neighbor detail 2691: -- Command: show ip ospf neighbor INTERFACE detail 2692: 2693: -- Command: show ip ospf database 2694: 2695: -- Command: show ip ospf database 2696: (asbr-summary|external|network|router|summary) 2697: -- Command: show ip ospf database 2698: (asbr-summary|external|network|router|summary) LINK-STATE-ID 2699: -- Command: show ip ospf database 2700: (asbr-summary|external|network|router|summary) LINK-STATE-ID adv-router 2701: ADV-ROUTER 2702: -- Command: show ip ospf database 2703: (asbr-summary|external|network|router|summary) adv-router ADV-ROUTER 2704: -- Command: show ip ospf database 2705: (asbr-summary|external|network|router|summary) LINK-STATE-ID 2706: self-originate 2707: -- Command: show ip ospf database 2708: (asbr-summary|external|network|router|summary) self-originate 2709: 2710: -- Command: show ip ospf database max-age 2711: 2712: -- Command: show ip ospf database self-originate 2713: 2714: -- Command: show ip ospf route 2715: Show the OSPF routing table, as determined by the most recent SPF 2716: calculation. 2717: 2718: 2719: File: quagga.info, Node: Debugging OSPF, Next: OSPF Configuration Examples, Prev: Showing OSPF information, Up: OSPFv2 2720: 2721: 7.7 Debugging OSPF 2722: ================== 2723: 2724: -- Command: debug ospf packet 2725: (hello|dd|ls-request|ls-update|ls-ack|all) (send|recv) [detail] 2726: -- Command: no debug ospf packet 2727: (hello|dd|ls-request|ls-update|ls-ack|all) (send|recv) [detail] 2728: 2729: -- Command: debug ospf ism 2730: -- Command: debug ospf ism (status|events|timers) 2731: -- Command: no debug ospf ism 2732: -- Command: no debug ospf ism (status|events|timers) 2733: 2734: -- Command: debug ospf nsm 2735: -- Command: debug ospf nsm (status|events|timers) 2736: -- Command: no debug ospf nsm 2737: -- Command: no debug ospf nsm (status|events|timers) 2738: 2739: -- Command: debug ospf lsa 2740: -- Command: debug ospf lsa (generate|flooding|refresh) 2741: -- Command: no debug ospf lsa 2742: -- Command: no debug ospf lsa (generate|flooding|refresh) 2743: 2744: -- Command: debug ospf zebra 2745: -- Command: debug ospf zebra (interface|redistribute) 2746: -- Command: no debug ospf zebra 2747: -- Command: no debug ospf zebra (interface|redistribute) 2748: 2749: -- Command: show debugging ospf 2750: 2751: 2752: File: quagga.info, Node: OSPF Configuration Examples, Prev: Debugging OSPF, Up: OSPFv2 2753: 2754: 7.8 OSPF Configuration Examples 2755: =============================== 2756: 2757: A simple example, with MD5 authentication enabled: 2758: 2759: ! 2760: interface bge0 2761: ip ospf authentication message-digest 2762: ip ospf message-digest-key 1 md5 ABCDEFGHIJK 2763: ! 2764: router ospf 2765: network 192.168.0.0/16 area 0.0.0.1 2766: area 0.0.0.1 authentication message-digest 2767: 2768: An ABR router, with MD5 authentication and performing summarisation 2769: of networks between the areas: 2770: 2771: ! 2772: password ABCDEF 2773: log file /var/log/quagga/ospfd.log 2774: service advanced-vty 2775: ! 2776: interface eth0 2777: ip ospf authentication message-digest 2778: ip ospf message-digest-key 1 md5 ABCDEFGHIJK 2779: ! 2780: interface ppp0 2781: ! 2782: interface br0 2783: ip ospf authentication message-digest 2784: ip ospf message-digest-key 2 md5 XYZ12345 2785: ! 2786: router ospf 2787: ospf router-id 192.168.0.1 2788: redistribute connected 2789: passive interface ppp0 2790: network 192.168.0.0/24 area 0.0.0.0 2791: network 10.0.0.0/16 area 0.0.0.0 2792: network 192.168.1.0/24 area 0.0.0.1 2793: area 0.0.0.0 authentication message-digest 2794: area 0.0.0.0 range 10.0.0.0/16 2795: area 0.0.0.0 range 192.168.0.0/24 2796: area 0.0.0.1 authentication message-digest 2797: area 0.0.0.1 range 10.2.0.0/16 2798: ! 2799: 2800: 2801: File: quagga.info, Node: OSPFv3, Next: Babel, Prev: OSPFv2, Up: Top 2802: 2803: 8 OSPFv3 2804: ******** 2805: 2806: `ospf6d' is a daemon support OSPF version 3 for IPv6 network. OSPF for 2807: IPv6 is described in RFC2740. 2808: 2809: * Menu: 2810: 2811: * OSPF6 router:: 2812: * OSPF6 area:: 2813: * OSPF6 interface:: 2814: * Redistribute routes to OSPF6:: 2815: * Showing OSPF6 information:: 2816: * OSPF6 Configuration Examples:: 2817: 2818: 2819: File: quagga.info, Node: OSPF6 router, Next: OSPF6 area, Up: OSPFv3 2820: 2821: 8.1 OSPF6 router 2822: ================ 2823: 2824: -- Command: router ospf6 2825: 2826: -- OSPF6 Command: router-id A.B.C.D 2827: Set router's Router-ID. 2828: 2829: -- OSPF6 Command: interface IFNAME area AREA 2830: Bind interface to specified area, and start sending OSPF packets. 2831: AREA can be specified as 0. 2832: 2833: 2834: File: quagga.info, Node: OSPF6 area, Next: OSPF6 interface, Prev: OSPF6 router, Up: OSPFv3 2835: 2836: 8.2 OSPF6 area 2837: ============== 2838: 2839: Area support for OSPFv3 is not yet implemented. 2840: 2841: 2842: File: quagga.info, Node: OSPF6 interface, Next: Redistribute routes to OSPF6, Prev: OSPF6 area, Up: OSPFv3 2843: 2844: 8.3 OSPF6 interface 2845: =================== 2846: 2847: -- Interface Command: ipv6 ospf6 cost COST 2848: Sets interface's output cost. Default value is 1. 2849: 2850: -- Interface Command: ipv6 ospf6 hello-interval HELLOINTERVAL 2851: Sets interface's Hello Interval. Default 40 2852: 2853: -- Interface Command: ipv6 ospf6 dead-interval DEADINTERVAL 2854: Sets interface's Router Dead Interval. Default value is 40. 2855: 2856: -- Interface Command: ipv6 ospf6 retransmit-interval 2857: RETRANSMITINTERVAL 2858: Sets interface's Rxmt Interval. Default value is 5. 2859: 2860: -- Interface Command: ipv6 ospf6 priority PRIORITY 2861: Sets interface's Router Priority. Default value is 1. 2862: 2863: -- Interface Command: ipv6 ospf6 transmit-delay TRANSMITDELAY 2864: Sets interface's Inf-Trans-Delay. Default value is 1. 2865: 2866: 2867: File: quagga.info, Node: Redistribute routes to OSPF6, Next: Showing OSPF6 information, Prev: OSPF6 interface, Up: OSPFv3 2868: 2869: 8.4 Redistribute routes to OSPF6 2870: ================================ 2871: 2872: -- OSPF6 Command: redistribute static 2873: -- OSPF6 Command: redistribute connected 2874: -- OSPF6 Command: redistribute ripng 2875: 2876: 2877: File: quagga.info, Node: Showing OSPF6 information, Next: OSPF6 Configuration Examples, Prev: Redistribute routes to OSPF6, Up: OSPFv3 2878: 2879: 8.5 Showing OSPF6 information 2880: ============================= 2881: 2882: -- Command: show ipv6 ospf6 [INSTANCE_ID] 2883: INSTANCE_ID is an optional OSPF instance ID. To see router ID and 2884: OSPF instance ID, simply type "show ipv6 ospf6 <cr>". 2885: 2886: -- Command: show ipv6 ospf6 database 2887: This command shows LSA database summary. You can specify the type 2888: of LSA. 2889: 2890: -- Command: show ipv6 ospf6 interface 2891: To see OSPF interface configuration like costs. 2892: 2893: -- Command: show ipv6 ospf6 neighbor 2894: Shows state and chosen (Backup) DR of neighbor. 2895: 2896: -- Command: show ipv6 ospf6 request-list A.B.C.D 2897: Shows requestlist of neighbor. 2898: 2899: -- Command: show ipv6 route ospf6 2900: This command shows internal routing table. 2901: 2902: 2903: File: quagga.info, Node: OSPF6 Configuration Examples, Prev: Showing OSPF6 information, Up: OSPFv3 2904: 2905: 8.6 OSPF6 Configuration Examples 2906: ================================ 2907: 2908: Example of ospf6d configured on one interface and area: 2909: 2910: interface eth0 2911: ipv6 ospf6 instance-id 0 2912: ! 2913: router ospf6 2914: router-id 212.17.55.53 2915: area 0.0.0.0 range 2001:770:105:2::/64 2916: interface eth0 area 0.0.0.0 2917: ! 2918: 2919: 2920: File: quagga.info, Node: Babel, Next: BGP, Prev: OSPFv3, Up: Top 2921: 2922: 9 Babel 2923: ******* 2924: 2925: Babel is an interior gateway protocol that is suitable both for wired 2926: networks and for wireless mesh networks. Babel has been described as 2927: "RIP on speed" -- it is based on the same principles as RIP, but 2928: includes a number of refinements that make it react much faster to 2929: topology changes without ever counting to infinity, and allow it to 2930: perform reliable link quality estimation on wireless links. Babel is a 2931: double-stack routing protocol, meaning that a single Babel instance is 2932: able to perform routing for both IPv4 and IPv6. 2933: 2934: Quagga implements Babel as described in RFC6126. 2935: 2936: * Menu: 2937: 2938: * Configuring babeld:: 2939: * Babel configuration:: 2940: * Babel redistribution:: 2941: * Show Babel information:: 2942: * Babel debugging commands:: 2943: 2944: 2945: File: quagga.info, Node: Configuring babeld, Next: Babel configuration, Prev: Babel, Up: Babel 2946: 2947: 9.1 Configuring babeld 2948: ====================== 2949: 2950: The `babeld' daemon can be invoked with any of the common options 2951: (*note Common Invocation Options::). 2952: 2953: The `zebra' daemon must be running before `babeld' is invoked. Also, 2954: if `zebra' is restarted then `babeld' must be too. 2955: 2956: Configuration of `babeld' is done in its configuration file 2957: `babeld.conf'. 2958: 2959: 2960: File: quagga.info, Node: Babel configuration, Next: Babel redistribution, Prev: Configuring babeld, Up: Babel 2961: 2962: 9.2 Babel configuration 2963: ======================= 2964: 2965: -- Command: router babel 2966: -- Command: no router babel 2967: Enable or disable Babel routing. 2968: 2969: -- Babel Command: network IFNAME 2970: -- Babel Command: no network IFNAME 2971: Enable or disable Babel on the given interface. 2972: 2973: -- Interface Command: babel wired 2974: -- Interface Command: babel wireless 2975: Specifies whether this interface is wireless, which disables a 2976: number of optimisations that are only correct on wired interfaces. 2977: Specifying `wireless' (the default) is always correct, but may 2978: cause slower convergence and extra routing traffic. 2979: 2980: -- Interface Command: babel split-horizon 2981: -- Interface Command: no babel split-horizon 2982: Specifies whether to perform split-horizon on the interface. 2983: Specifying `no babel split-horizon' (the default) is always 2984: correct, while `babel split-horizon' is an optimisation that 2985: should only be used on symmetric and transitive (wired) networks. 2986: 2987: -- Interface Command: babel hello-interval <20-655340> 2988: Specifies the time in milliseconds between two scheduled hellos. 2989: On wired links, Babel notices a link failure within two hello 2990: intervals; on wireless links, the link quality value is 2991: reestimated at every hello interval. The default is 4000ms. 2992: 2993: -- Interface Command: babel update-interval <20-655340> 2994: Specifies the time in milliseconds between two scheduled updates. 2995: Since Babel makes extensive use of triggered updates, this can be 2996: set to fairly high values on links with little packet loss. The 2997: default is 20000ms. 2998: 2999: -- Babel Command: babel resend-delay <20-655340> 3000: Specifies the time in milliseconds after which an "important" 3001: request or update will be resent. The default is 2000ms. You 3002: probably don't want to tweak this value. 3003: 3004: 3005: File: quagga.info, Node: Babel redistribution, Next: Show Babel information, Prev: Babel configuration, Up: Babel 3006: 3007: 9.3 Babel redistribution 3008: ======================== 3009: 3010: -- Babel command: redistribute KIND 3011: -- Babel command: no redistribute KIND 3012: Specify which kind of routes should be redistributed into Babel. 3013: 3014: 3015: File: quagga.info, Node: Show Babel information, Next: Babel debugging commands, Prev: Babel redistribution, Up: Babel 3016: 3017: 9.4 Show Babel information 3018: ========================== 3019: 3020: -- Command: show babel database 3021: -- Command: show babel interface 3022: -- Command: show babel neighbour 3023: -- Command: show babel parameters 3024: These commands dump various parts of `babeld''s internal state. 3025: They are mostly useful for troubleshooting. 3026: 3027: 3028: File: quagga.info, Node: Babel debugging commands, Prev: Show Babel information, Up: Babel 3029: 3030: 9.5 Babel debugging commands 3031: ============================ 3032: 3033: -- Babel Command: debug babel KIND 3034: -- Babel Command: no debug babel KIND 3035: Enable or disable debugging messages of a given kind. KIND can be 3036: one of `common', `kernel', `filter', `timeout', `interface', 3037: `route' or `all'. Note that if you have compiled with the 3038: NO_DEBUG flag, then these commands aren't available. 3039: 3040: 3041: File: quagga.info, Node: BGP, Next: Configuring Quagga as a Route Server, Prev: Babel, Up: Top 3042: 3043: 10 BGP 3044: ****** 3045: 3046: BGP stands for a Border Gateway Protocol. The lastest BGP version is 3047: 4. It is referred as BGP-4. BGP-4 is one of the Exterior Gateway 3048: Protocols and de-fact standard of Inter Domain routing protocol. BGP-4 3049: is described in `RFC1771, A Border Gateway Protocol 4 (BGP-4)'. 3050: 3051: Many extensions have been added to `RFC1771'. `RFC2858, 3052: Multiprotocol Extensions for BGP-4' provides multiprotocol support to 3053: BGP-4. 3054: 3055: * Menu: 3056: 3057: * Starting BGP:: 3058: * BGP router:: 3059: * BGP network:: 3060: * BGP Peer:: 3061: * BGP Peer Group:: 3062: * BGP Address Family:: 3063: * Autonomous System:: 3064: * BGP Communities Attribute:: 3065: * BGP Extended Communities Attribute:: 3066: * Displaying BGP routes:: 3067: * Capability Negotiation:: 3068: * Route Reflector:: 3069: * Route Server:: 3070: * How to set up a 6-Bone connection:: 3071: * Dump BGP packets and table:: 3072: * BGP Configuration Examples:: 3073: 3074: 3075: File: quagga.info, Node: Starting BGP, Next: BGP router, Up: BGP 3076: 3077: 10.1 Starting BGP 3078: ================= 3079: 3080: Default configuration file of `bgpd' is `bgpd.conf'. `bgpd' searches 3081: the current directory first then /etc/quagga/bgpd.conf. All of bgpd's 3082: command must be configured in `bgpd.conf'. 3083: 3084: `bgpd' specific invocation options are described below. Common 3085: options may also be specified (*note Common Invocation Options::). 3086: 3087: `-p PORT' 3088: `--bgp_port=PORT' 3089: Set the bgp protocol's port number. 3090: 3091: `-r' 3092: `--retain' 3093: When program terminates, retain BGP routes added by zebra. 3094: 3095: 3096: File: quagga.info, Node: BGP router, Next: BGP network, Prev: Starting BGP, Up: BGP 3097: 3098: 10.2 BGP router 3099: =============== 3100: 3101: First of all you must configure BGP router with `router bgp' command. 3102: To configure BGP router, you need AS number. AS number is an 3103: identification of autonomous system. BGP protocol uses the AS number 3104: for detecting whether the BGP connection is internal one or external 3105: one. 3106: 3107: -- Command: router bgp ASN 3108: Enable a BGP protocol process with the specified ASN. After this 3109: statement you can input any `BGP Commands'. You can not create 3110: different BGP process under different ASN without specifying 3111: `multiple-instance' (*note Multiple instance::). 3112: 3113: -- Command: no router bgp ASN 3114: Destroy a BGP protocol process with the specified ASN. 3115: 3116: -- BGP: bgp router-id A.B.C.D 3117: This command specifies the router-ID. If `bgpd' connects to 3118: `zebra' it gets interface and address information. In that case 3119: default router ID value is selected as the largest IP Address of 3120: the interfaces. When `router zebra' is not enabled `bgpd' can't 3121: get interface information so `router-id' is set to 0.0.0.0. So 3122: please set router-id by hand. 3123: 3124: * Menu: 3125: 3126: * BGP distance:: 3127: * BGP decision process:: 3128: * BGP route flap dampening:: 3129: 3130: 3131: File: quagga.info, Node: BGP distance, Next: BGP decision process, Up: BGP router 3132: 3133: 10.2.1 BGP distance 3134: ------------------- 3135: 3136: -- BGP: distance bgp <1-255> <1-255> <1-255> 3137: This command change distance value of BGP. Each argument is 3138: distance value for external routes, internal routes and local 3139: routes. 3140: 3141: -- BGP: distance <1-255> A.B.C.D/M 3142: -- BGP: distance <1-255> A.B.C.D/M WORD 3143: This command set distance value to 3144: 3145: 3146: File: quagga.info, Node: BGP decision process, Next: BGP route flap dampening, Prev: BGP distance, Up: BGP router 3147: 3148: 10.2.2 BGP decision process 3149: --------------------------- 3150: 3151: 1. Weight check 3152: 3153: 2. Local preference check. 3154: 3155: 3. Local route check. 3156: 3157: 4. AS path length check. 3158: 3159: 5. Origin check. 3160: 3161: 6. MED check. 3162: 3163: -- BGP: bgp bestpath as-path confed 3164: This command specifies that the length of confederation path sets 3165: and sequences should should be taken into account during the BGP 3166: best path decision process. 3167: 3168: 3169: File: quagga.info, Node: BGP route flap dampening, Prev: BGP decision process, Up: BGP router 3170: 3171: 10.2.3 BGP route flap dampening 3172: ------------------------------- 3173: 3174: -- BGP: bgp dampening <1-45> <1-20000> <1-20000> <1-255> 3175: This command enables BGP route-flap dampening and specifies 3176: dampening parameters. 3177: 3178: half-life 3179: Half-life time for the penalty 3180: 3181: reuse-threshold 3182: Value to start reusing a route 3183: 3184: suppress-threshold 3185: Value to start suppressing a route 3186: 3187: max-suppress 3188: Maximum duration to suppress a stable route 3189: 3190: The route-flap damping algorithm is compatible with `RFC2439'. The 3191: use of this command is not recommended nowadays, see RIPE-378. 3192: 3193: 3194: File: quagga.info, Node: BGP network, Next: BGP Peer, Prev: BGP router, Up: BGP 3195: 3196: 10.3 BGP network 3197: ================ 3198: 3199: * Menu: 3200: 3201: * BGP route:: 3202: * Route Aggregation:: 3203: * Redistribute to BGP:: 3204: 3205: 3206: File: quagga.info, Node: BGP route, Next: Route Aggregation, Up: BGP network 3207: 3208: 10.3.1 BGP route 3209: ---------------- 3210: 3211: -- BGP: network A.B.C.D/M 3212: This command adds the announcement network. 3213: router bgp 1 3214: network 10.0.0.0/8 3215: This configuration example says that network 10.0.0.0/8 will be 3216: announced to all neighbors. Some vendors' routers don't advertise 3217: routes if they aren't present in their IGP routing tables; `bgpd' 3218: doesn't care about IGP routes when announcing its routes. 3219: 3220: -- BGP: no network A.B.C.D/M 3221: 3222: 3223: File: quagga.info, Node: Route Aggregation, Next: Redistribute to BGP, Prev: BGP route, Up: BGP network 3224: 3225: 10.3.2 Route Aggregation 3226: ------------------------ 3227: 3228: -- BGP: aggregate-address A.B.C.D/M 3229: This command specifies an aggregate address. 3230: 3231: -- BGP: aggregate-address A.B.C.D/M as-set 3232: This command specifies an aggregate address. Resulting routes 3233: inlucde AS set. 3234: 3235: -- BGP: aggregate-address A.B.C.D/M summary-only 3236: This command specifies an aggregate address. Aggreated routes will 3237: not be announce. 3238: 3239: -- BGP: no aggregate-address A.B.C.D/M 3240: 3241: 3242: File: quagga.info, Node: Redistribute to BGP, Prev: Route Aggregation, Up: BGP network 3243: 3244: 10.3.3 Redistribute to BGP 3245: -------------------------- 3246: 3247: -- BGP: redistribute kernel 3248: Redistribute kernel route to BGP process. 3249: 3250: -- BGP: redistribute static 3251: Redistribute static route to BGP process. 3252: 3253: -- BGP: redistribute connected 3254: Redistribute connected route to BGP process. 3255: 3256: -- BGP: redistribute rip 3257: Redistribute RIP route to BGP process. 3258: 3259: -- BGP: redistribute ospf 3260: Redistribute OSPF route to BGP process. 3261: 3262: 3263: File: quagga.info, Node: BGP Peer, Next: BGP Peer Group, Prev: BGP network, Up: BGP 3264: 3265: 10.4 BGP Peer 3266: ============= 3267: 3268: * Menu: 3269: 3270: * Defining Peer:: 3271: * BGP Peer commands:: 3272: * Peer filtering:: 3273: 3274: 3275: File: quagga.info, Node: Defining Peer, Next: BGP Peer commands, Up: BGP Peer 3276: 3277: 10.4.1 Defining Peer 3278: -------------------- 3279: 3280: -- BGP: neighbor PEER remote-as ASN 3281: Creates a new neighbor whose remote-as is ASN. PEER can be an 3282: IPv4 address or an IPv6 address. 3283: router bgp 1 3284: neighbor 10.0.0.1 remote-as 2 3285: In this case my router, in AS-1, is trying to peer with AS-2 at 3286: 10.0.0.1. 3287: 3288: This command must be the first command used when configuring a 3289: neighbor. If the remote-as is not specified, `bgpd' will complain 3290: like this: 3291: can't find neighbor 10.0.0.1 3292: 3293: 3294: File: quagga.info, Node: BGP Peer commands, Next: Peer filtering, Prev: Defining Peer, Up: BGP Peer 3295: 3296: 10.4.2 BGP Peer commands 3297: ------------------------ 3298: 3299: In a `router bgp' clause there are neighbor specific configurations 3300: required. 3301: 3302: -- BGP: neighbor PEER shutdown 3303: -- BGP: no neighbor PEER shutdown 3304: Shutdown the peer. We can delete the neighbor's configuration by 3305: `no neighbor PEER remote-as AS-NUMBER' but all configuration of 3306: the neighbor will be deleted. When you want to preserve the 3307: configuration, but want to drop the BGP peer, use this syntax. 3308: 3309: -- BGP: neighbor PEER ebgp-multihop 3310: -- BGP: no neighbor PEER ebgp-multihop 3311: 3312: -- BGP: neighbor PEER description ... 3313: -- BGP: no neighbor PEER description ... 3314: Set description of the peer. 3315: 3316: -- BGP: neighbor PEER version VERSION 3317: Set up the neighbor's BGP version. VERSION can be 4, 4+ or 4-. 3318: BGP version 4 is the default value used for BGP peering. BGP 3319: version 4+ means that the neighbor supports Multiprotocol 3320: Extensions for BGP-4. BGP version 4- is similar but the neighbor 3321: speaks the old Internet-Draft revision 00's Multiprotocol 3322: Extensions for BGP-4. Some routing software is still using this 3323: version. 3324: 3325: -- BGP: neighbor PEER interface IFNAME 3326: -- BGP: no neighbor PEER interface IFNAME 3327: When you connect to a BGP peer over an IPv6 link-local address, you 3328: have to specify the IFNAME of the interface used for the 3329: connection. To specify IPv4 session addresses, see the `neighbor 3330: PEER update-source' command below. 3331: 3332: This command is deprecated and may be removed in a future release. 3333: Its use should be avoided. 3334: 3335: -- BGP: neighbor PEER next-hop-self 3336: -- BGP: no neighbor PEER next-hop-self 3337: This command specifies an announced route's nexthop as being 3338: equivalent to the address of the bgp router. 3339: 3340: -- BGP: neighbor PEER update-source <IFNAME|ADDRESS> 3341: -- BGP: no neighbor PEER update-source 3342: Specify the IPv4 source address to use for the BGP session to this 3343: neighbour, may be specified as either an IPv4 address directly or 3344: as an interface name (in which case the `zebra' daemon MUST be 3345: running in order for `bgpd' to be able to retrieve interface 3346: state). 3347: router bgp 64555 3348: neighbor foo update-source 192.168.0.1 3349: neighbor bar update-source lo0 3350: 3351: -- BGP: neighbor PEER default-originate 3352: -- BGP: no neighbor PEER default-originate 3353: `bgpd''s default is to not announce the default route (0.0.0.0/0) 3354: even it is in routing table. When you want to announce default 3355: routes to the peer, use this command. 3356: 3357: -- BGP: neighbor PEER port PORT 3358: -- BGP: neighbor PEER port PORT 3359: 3360: -- BGP: neighbor PEER send-community 3361: -- BGP: neighbor PEER send-community 3362: 3363: -- BGP: neighbor PEER weight WEIGHT 3364: -- BGP: no neighbor PEER weight WEIGHT 3365: This command specifies a default WEIGHT value for the neighbor's 3366: routes. 3367: 3368: -- BGP: neighbor PEER maximum-prefix NUMBER 3369: -- BGP: no neighbor PEER maximum-prefix NUMBER 3370: 3371: 3372: File: quagga.info, Node: Peer filtering, Prev: BGP Peer commands, Up: BGP Peer 3373: 3374: 10.4.3 Peer filtering 3375: --------------------- 3376: 3377: -- BGP: neighbor PEER distribute-list NAME [in|out] 3378: This command specifies a distribute-list for the peer. DIRECT is 3379: `in' or `out'. 3380: 3381: -- BGP command: neighbor PEER prefix-list NAME [in|out] 3382: 3383: -- BGP command: neighbor PEER filter-list NAME [in|out] 3384: 3385: -- BGP: neighbor PEER route-map NAME [in|out] 3386: Apply a route-map on the neighbor. DIRECT must be `in' or `out'. 3387: 3388: 3389: File: quagga.info, Node: BGP Peer Group, Next: BGP Address Family, Prev: BGP Peer, Up: BGP 3390: 3391: 10.5 BGP Peer Group 3392: =================== 3393: 3394: -- BGP: neighbor WORD peer-group 3395: This command defines a new peer group. 3396: 3397: -- BGP: neighbor PEER peer-group WORD 3398: This command bind specific peer to peer group WORD. 3399: 3400: 3401: File: quagga.info, Node: BGP Address Family, Next: Autonomous System, Prev: BGP Peer Group, Up: BGP 3402: 3403: 10.6 BGP Address Family 3404: ======================= 3405: 3406: 3407: File: quagga.info, Node: Autonomous System, Next: BGP Communities Attribute, Prev: BGP Address Family, Up: BGP 3408: 3409: 10.7 Autonomous System 3410: ====================== 3411: 3412: The AS (Autonomous System) number is one of the essential element of 3413: BGP. BGP is a distance vector routing protocol, and the AS-Path 3414: framework provides distance vector metric and loop detection to BGP. 3415: `RFC1930, Guidelines for creation, selection, and registration of an 3416: Autonomous System (AS)' provides some background on the concepts of an 3417: AS. 3418: 3419: The AS number is a two octet value, ranging in value from 1 to 65535. 3420: The AS numbers 64512 through 65535 are defined as private AS numbers. 3421: Private AS numbers must not to be advertised in the global Internet. 3422: 3423: * Menu: 3424: 3425: * AS Path Regular Expression:: 3426: * Display BGP Routes by AS Path:: 3427: * AS Path Access List:: 3428: * Using AS Path in Route Map:: 3429: * Private AS Numbers:: 3430: 3431: 3432: File: quagga.info, Node: AS Path Regular Expression, Next: Display BGP Routes by AS Path, Up: Autonomous System 3433: 3434: 10.7.1 AS Path Regular Expression 3435: --------------------------------- 3436: 3437: AS path regular expression can be used for displaying BGP routes and AS 3438: path access list. AS path regular expression is based on `POSIX 3439: 1003.2' regular expressions. Following description is just a subset of 3440: `POSIX' regular expression. User can use full `POSIX' regular 3441: expression. Adding to that special character '_' is added for AS path 3442: regular expression. 3443: 3444: `.' 3445: Matches any single character. 3446: 3447: `*' 3448: Matches 0 or more occurrences of pattern. 3449: 3450: `+' 3451: Matches 1 or more occurrences of pattern. 3452: 3453: `?' 3454: Match 0 or 1 occurrences of pattern. 3455: 3456: `^' 3457: Matches the beginning of the line. 3458: 3459: `$' 3460: Matches the end of the line. 3461: 3462: `_' 3463: Character `_' has special meanings in AS path regular expression. 3464: It matches to space and comma , and AS set delimiter { and } and AS 3465: confederation delimiter `(' and `)'. And it also matches to the 3466: beginning of the line and the end of the line. So `_' can be used 3467: for AS value boundaries match. `show ip bgp regexp _7675_' 3468: matches to all of BGP routes which as AS number include 7675. 3469: 3470: 3471: File: quagga.info, Node: Display BGP Routes by AS Path, Next: AS Path Access List, Prev: AS Path Regular Expression, Up: Autonomous System 3472: 3473: 10.7.2 Display BGP Routes by AS Path 3474: ------------------------------------ 3475: 3476: To show BGP routes which has specific AS path information `show ip bgp' 3477: command can be used. 3478: 3479: -- Command: show ip bgp regexp LINE 3480: This commands display BGP routes that matches AS path regular 3481: expression LINE. 3482: 3483: 3484: 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 3485: 3486: 10.7.3 AS Path Access List 3487: -------------------------- 3488: 3489: AS path access list is user defined AS path. 3490: 3491: -- Command: ip as-path access-list WORD {permit|deny} LINE 3492: This command defines a new AS path access list. 3493: 3494: -- Command: no ip as-path access-list WORD 3495: -- Command: no ip as-path access-list WORD {permit|deny} LINE 3496: 3497: 3498: File: quagga.info, Node: Using AS Path in Route Map, Next: Private AS Numbers, Prev: AS Path Access List, Up: Autonomous System 3499: 3500: 10.7.4 Using AS Path in Route Map 3501: --------------------------------- 3502: 3503: -- Route Map: match as-path WORD 3504: 3505: -- Route Map: set as-path prepend AS-PATH 3506: 3507: 3508: File: quagga.info, Node: Private AS Numbers, Prev: Using AS Path in Route Map, Up: Autonomous System 3509: 3510: 10.7.5 Private AS Numbers 3511: ------------------------- 3512: 3513: 3514: File: quagga.info, Node: BGP Communities Attribute, Next: BGP Extended Communities Attribute, Prev: Autonomous System, Up: BGP 3515: 3516: 10.8 BGP Communities Attribute 3517: ============================== 3518: 3519: BGP communities attribute is widely used for implementing policy 3520: routing. Network operators can manipulate BGP communities attribute 3521: based on their network policy. BGP communities attribute is defined in 3522: `RFC1997, BGP Communities Attribute' and `RFC1998, An Application of 3523: the BGP Community Attribute in Multi-home Routing'. It is an optional 3524: transitive attribute, therefore local policy can travel through 3525: different autonomous system. 3526: 3527: Communities attribute is a set of communities values. Each 3528: communities value is 4 octet long. The following format is used to 3529: define communities value. 3530: 3531: `AS:VAL' 3532: This format represents 4 octet communities value. `AS' is high 3533: order 2 octet in digit format. `VAL' is low order 2 octet in 3534: digit format. This format is useful to define AS oriented policy 3535: value. For example, `7675:80' can be used when AS 7675 wants to 3536: pass local policy value 80 to neighboring peer. 3537: 3538: `internet' 3539: `internet' represents well-known communities value 0. 3540: 3541: `no-export' 3542: `no-export' represents well-known communities value `NO_EXPORT' 3543: (0xFFFFFF01). All routes carry this value must not be advertised 3544: to outside a BGP confederation boundary. If neighboring BGP peer 3545: is part of BGP confederation, the peer is considered as inside a 3546: BGP confederation boundary, so the route will be announced to the 3547: peer. 3548: 3549: `no-advertise' 3550: `no-advertise' represents well-known communities value 3551: `NO_ADVERTISE' 3552: (0xFFFFFF02). All routes carry this value must not be advertise 3553: to other BGP peers. 3554: 3555: `local-AS' 3556: `local-AS' represents well-known communities value 3557: `NO_EXPORT_SUBCONFED' (0xFFFFFF03). All routes carry this value 3558: must not be advertised to external BGP peers. Even if the 3559: neighboring router is part of confederation, it is considered as 3560: external BGP peer, so the route will not be announced to the peer. 3561: 3562: When BGP communities attribute is received, duplicated communities 3563: value in the communities attribute is ignored and each communities 3564: values are sorted in numerical order. 3565: 3566: * Menu: 3567: 3568: * BGP Community Lists:: 3569: * Numbered BGP Community Lists:: 3570: * BGP Community in Route Map:: 3571: * Display BGP Routes by Community:: 3572: * Using BGP Communities Attribute:: 3573: 3574: 3575: File: quagga.info, Node: BGP Community Lists, Next: Numbered BGP Community Lists, Up: BGP Communities Attribute 3576: 3577: 10.8.1 BGP Community Lists 3578: -------------------------- 3579: 3580: BGP community list is a user defined BGP communites attribute list. 3581: BGP community list can be used for matching or manipulating BGP 3582: communities attribute in updates. 3583: 3584: There are two types of community list. One is standard community 3585: list and another is expanded community list. Standard community list 3586: defines communities attribute. Expanded community list defines 3587: communities attribute string with regular expression. Standard 3588: community list is compiled into binary format when user define it. 3589: Standard community list will be directly compared to BGP communities 3590: attribute in BGP updates. Therefore the comparison is faster than 3591: expanded community list. 3592: 3593: -- Command: ip community-list standard NAME {permit|deny} COMMUNITY 3594: This command defines a new standard community list. COMMUNITY is 3595: communities value. The COMMUNITY is compiled into community 3596: structure. We can define multiple community list under same name. 3597: In that case match will happen user defined order. Once the 3598: community list matches to communities attribute in BGP updates it 3599: return permit or deny by the community list definition. When 3600: there is no matched entry, deny will be returned. When COMMUNITY 3601: is empty it matches to any routes. 3602: 3603: -- Command: ip community-list expanded NAME {permit|deny} LINE 3604: This command defines a new expanded community list. LINE is a 3605: string expression of communities attribute. LINE can include 3606: regular expression to match communities attribute in BGP updates. 3607: 3608: -- Command: no ip community-list NAME 3609: -- Command: no ip community-list standard NAME 3610: -- Command: no ip community-list expanded NAME 3611: These commands delete community lists specified by NAME. All of 3612: community lists shares a single name space. So community lists 3613: can be removed simpley specifying community lists name. 3614: 3615: -- Command: show ip community-list 3616: -- Command: show ip community-list NAME 3617: This command display current community list information. When 3618: NAME is specified the specified community list's information is 3619: shown. 3620: 3621: # show ip community-list 3622: Named Community standard list CLIST 3623: permit 7675:80 7675:100 no-export 3624: deny internet 3625: Named Community expanded list EXPAND 3626: permit : 3627: 3628: # show ip community-list CLIST 3629: Named Community standard list CLIST 3630: permit 7675:80 7675:100 no-export 3631: deny internet 3632: 3633: 3634: File: quagga.info, Node: Numbered BGP Community Lists, Next: BGP Community in Route Map, Prev: BGP Community Lists, Up: BGP Communities Attribute 3635: 3636: 10.8.2 Numbered BGP Community Lists 3637: ----------------------------------- 3638: 3639: When number is used for BGP community list name, the number has special 3640: meanings. Community list number in the range from 1 and 99 is standard 3641: community list. Community list number in the range from 100 to 199 is 3642: expanded community list. These community lists are called as numbered 3643: community lists. On the other hand normal community lists is called as 3644: named community lists. 3645: 3646: -- Command: ip community-list <1-99> {permit|deny} COMMUNITY 3647: This command defines a new community list. <1-99> is standard 3648: community list number. Community list name within this range 3649: defines standard community list. When COMMUNITY is empty it 3650: matches to any routes. 3651: 3652: -- Command: ip community-list <100-199> {permit|deny} COMMUNITY 3653: This command defines a new community list. <100-199> is expanded 3654: community list number. Community list name within this range 3655: defines expanded community list. 3656: 3657: -- Command: ip community-list NAME {permit|deny} COMMUNITY 3658: When community list type is not specifed, the community list type 3659: is automatically detected. If COMMUNITY can be compiled into 3660: communities attribute, the community list is defined as a standard 3661: community list. Otherwise it is defined as an expanded community 3662: list. This feature is left for backward compability. Use of this 3663: feature is not recommended. 3664: 3665: 3666: File: quagga.info, Node: BGP Community in Route Map, Next: Display BGP Routes by Community, Prev: Numbered BGP Community Lists, Up: BGP Communities Attribute 3667: 3668: 10.8.3 BGP Community in Route Map 3669: --------------------------------- 3670: 3671: In Route Map (*note Route Map::), we can match or set BGP communities 3672: attribute. Using this feature network operator can implement their 3673: network policy based on BGP communities attribute. 3674: 3675: Following commands can be used in Route Map. 3676: 3677: -- Route Map: match community WORD 3678: -- Route Map: match community WORD exact-match 3679: This command perform match to BGP updates using community list 3680: WORD. When the one of BGP communities value match to the one of 3681: communities value in community list, it is match. When 3682: `exact-match' keyword is spcified, match happen only when BGP 3683: updates have completely same communities value specified in the 3684: community list. 3685: 3686: -- Route Map: set community none 3687: -- Route Map: set community COMMUNITY 3688: -- Route Map: set community COMMUNITY additive 3689: This command manipulate communities value in BGP updates. When 3690: `none' is specified as communities value, it removes entire 3691: communities attribute from BGP updates. When COMMUNITY is not 3692: `none', specified communities value is set to BGP updates. If BGP 3693: updates already has BGP communities value, the existing BGP 3694: communities value is replaced with specified COMMUNITY value. 3695: When `additive' keyword is specified, COMMUNITY is appended to the 3696: existing communities value. 3697: 3698: -- Route Map: set comm-list WORD delete 3699: This command remove communities value from BGP communities 3700: attribute. The WORD is community list name. When BGP route's 3701: communities value matches to the community list WORD, the 3702: communities value is removed. When all of communities value is 3703: removed eventually, the BGP update's communities attribute is 3704: completely removed. 3705: 3706: 3707: File: quagga.info, Node: Display BGP Routes by Community, Next: Using BGP Communities Attribute, Prev: BGP Community in Route Map, Up: BGP Communities Attribute 3708: 3709: 10.8.4 Display BGP Routes by Community 3710: -------------------------------------- 3711: 3712: To show BGP routes which has specific BGP communities attribute, `show 3713: ip bgp' command can be used. The COMMUNITY value and community list 3714: can be used for `show ip bgp' command. 3715: 3716: -- Command: show ip bgp community 3717: -- Command: show ip bgp community COMMUNITY 3718: -- Command: show ip bgp community COMMUNITY exact-match 3719: `show ip bgp community' displays BGP routes which has communities 3720: attribute. When COMMUNITY is specified, BGP routes that matches 3721: COMMUNITY value is displayed. For this command, `internet' 3722: keyword can't be used for COMMUNITY value. When `exact-match' is 3723: specified, it display only routes that have an exact match. 3724: 3725: -- Command: show ip bgp community-list WORD 3726: -- Command: show ip bgp community-list WORD exact-match 3727: This commands display BGP routes that matches community list WORD. 3728: When `exact-match' is specified, display only routes that have an 3729: exact match. 3730: 3731: 3732: File: quagga.info, Node: Using BGP Communities Attribute, Prev: Display BGP Routes by Community, Up: BGP Communities Attribute 3733: 3734: 10.8.5 Using BGP Communities Attribute 3735: -------------------------------------- 3736: 3737: Following configuration is the most typical usage of BGP communities 3738: attribute. AS 7675 provides upstream Internet connection to AS 100. 3739: When following configuration exists in AS 7675, AS 100 networks 3740: operator can set local preference in AS 7675 network by setting BGP 3741: communities attribute to the updates. 3742: 3743: router bgp 7675 3744: neighbor 192.168.0.1 remote-as 100 3745: neighbor 192.168.0.1 route-map RMAP in 3746: ! 3747: ip community-list 70 permit 7675:70 3748: ip community-list 70 deny 3749: ip community-list 80 permit 7675:80 3750: ip community-list 80 deny 3751: ip community-list 90 permit 7675:90 3752: ip community-list 90 deny 3753: ! 3754: route-map RMAP permit 10 3755: match community 70 3756: set local-preference 70 3757: ! 3758: route-map RMAP permit 20 3759: match community 80 3760: set local-preference 80 3761: ! 3762: route-map RMAP permit 30 3763: match community 90 3764: set local-preference 90 3765: 3766: Following configuration announce 10.0.0.0/8 from AS 100 to AS 7675. 3767: The route has communities value 7675:80 so when above configuration 3768: exists in AS 7675, announced route's local preference will be set to 3769: value 80. 3770: 3771: router bgp 100 3772: network 10.0.0.0/8 3773: neighbor 192.168.0.2 remote-as 7675 3774: neighbor 192.168.0.2 route-map RMAP out 3775: ! 3776: ip prefix-list PLIST permit 10.0.0.0/8 3777: ! 3778: route-map RMAP permit 10 3779: match ip address prefix-list PLIST 3780: set community 7675:80 3781: 3782: Following configuration is an example of BGP route filtering using 3783: communities attribute. This configuration only permit BGP routes which 3784: has BGP communities value 0:80 or 0:90. Network operator can put 3785: special internal communities value at BGP border router, then limit the 3786: BGP routes announcement into the internal network. 3787: 3788: router bgp 7675 3789: neighbor 192.168.0.1 remote-as 100 3790: neighbor 192.168.0.1 route-map RMAP in 3791: ! 3792: ip community-list 1 permit 0:80 0:90 3793: ! 3794: route-map RMAP permit in 3795: match community 1 3796: 3797: Following exmaple filter BGP routes which has communities value 1:1. 3798: When there is no match community-list returns deny. To avoid filtering 3799: all of routes, we need to define permit any at last. 3800: 3801: router bgp 7675 3802: neighbor 192.168.0.1 remote-as 100 3803: neighbor 192.168.0.1 route-map RMAP in 3804: ! 3805: ip community-list standard FILTER deny 1:1 3806: ip community-list standard FILTER permit 3807: ! 3808: route-map RMAP permit 10 3809: match community FILTER 3810: 3811: Communities value keyword `internet' has special meanings in 3812: standard community lists. In below example `internet' act as match 3813: any. It matches all of BGP routes even if the route does not have 3814: communities attribute at all. So community list `INTERNET' is same as 3815: above example's `FILTER'. 3816: 3817: ip community-list standard INTERNET deny 1:1 3818: ip community-list standard INTERNET permit internet 3819: 3820: Following configuration is an example of communities value deletion. 3821: With this configuration communities value 100:1 and 100:2 is removed 3822: from BGP updates. For communities value deletion, only `permit' 3823: community-list is used. `deny' community-list is ignored. 3824: 3825: router bgp 7675 3826: neighbor 192.168.0.1 remote-as 100 3827: neighbor 192.168.0.1 route-map RMAP in 3828: ! 3829: ip community-list standard DEL permit 100:1 100:2 3830: ! 3831: route-map RMAP permit 10 3832: set comm-list DEL delete 3833: 3834: 3835: File: quagga.info, Node: BGP Extended Communities Attribute, Next: Displaying BGP routes, Prev: BGP Communities Attribute, Up: BGP 3836: 3837: 10.9 BGP Extended Communities Attribute 3838: ======================================= 3839: 3840: BGP extended communities attribute is introduced with MPLS VPN/BGP 3841: technology. MPLS VPN/BGP expands capability of network infrastructure 3842: to provide VPN functionality. At the same time it requires a new 3843: framework for policy routing. With BGP Extended Communities Attribute 3844: we can use Route Target or Site of Origin for implementing network 3845: policy for MPLS VPN/BGP. 3846: 3847: BGP Extended Communities Attribute is similar to BGP Communities 3848: Attribute. It is an optional transitive attribute. BGP Extended 3849: Communities Attribute can carry multiple Extended Community value. 3850: Each Extended Community value is eight octet length. 3851: 3852: BGP Extended Communities Attribute provides an extended range 3853: compared with BGP Communities Attribute. Adding to that there is a 3854: type field in each value to provides community space structure. 3855: 3856: There are two format to define Extended Community value. One is AS 3857: based format the other is IP address based format. 3858: 3859: `AS:VAL' 3860: This is a format to define AS based Extended Community value. 3861: `AS' part is 2 octets Global Administrator subfield in Extended 3862: Community value. `VAL' part is 4 octets Local Administrator 3863: subfield. `7675:100' represents AS 7675 policy value 100. 3864: 3865: `IP-Address:VAL' 3866: This is a format to define IP address based Extended Community 3867: value. `IP-Address' part is 4 octets Global Administrator 3868: subfield. `VAL' part is 2 octets Local Administrator subfield. 3869: `10.0.0.1:100' represents 3870: 3871: * Menu: 3872: 3873: * BGP Extended Community Lists:: 3874: * BGP Extended Communities in Route Map:: 3875: 3876: 3877: File: quagga.info, Node: BGP Extended Community Lists, Next: BGP Extended Communities in Route Map, Up: BGP Extended Communities Attribute 3878: 3879: 10.9.1 BGP Extended Community Lists 3880: ----------------------------------- 3881: 3882: Expanded Community Lists is a user defined BGP Expanded Community Lists. 3883: 3884: -- Command: ip extcommunity-list standard NAME {permit|deny} 3885: EXTCOMMUNITY 3886: This command defines a new standard extcommunity-list. 3887: EXTCOMMUNITY is extended communities value. The EXTCOMMUNITY is 3888: compiled into extended community structure. We can define 3889: multiple extcommunity-list under same name. In that case match 3890: will happen user defined order. Once the extcommunity-list 3891: matches to extended communities attribute in BGP updates it return 3892: permit or deny based upon the extcommunity-list definition. When 3893: there is no matched entry, deny will be returned. When 3894: EXTCOMMUNITY is empty it matches to any routes. 3895: 3896: -- Command: ip extcommunity-list expanded NAME {permit|deny} LINE 3897: This command defines a new expanded extcommunity-list. LINE is a 3898: string expression of extended communities attribute. LINE can 3899: include regular expression to match extended communities attribute 3900: in BGP updates. 3901: 3902: -- Command: no ip extcommunity-list NAME 3903: -- Command: no ip extcommunity-list standard NAME 3904: -- Command: no ip extcommunity-list expanded NAME 3905: These commands delete extended community lists specified by NAME. 3906: All of extended community lists shares a single name space. So 3907: extended community lists can be removed simpley specifying the 3908: name. 3909: 3910: -- Command: show ip extcommunity-list 3911: -- Command: show ip extcommunity-list NAME 3912: This command display current extcommunity-list information. When 3913: NAME is specified the community list's information is shown. 3914: 3915: # show ip extcommunity-list 3916: 3917: 3918: File: quagga.info, Node: BGP Extended Communities in Route Map, Prev: BGP Extended Community Lists, Up: BGP Extended Communities Attribute 3919: 3920: 10.9.2 BGP Extended Communities in Route Map 3921: -------------------------------------------- 3922: 3923: -- Route Map: match extcommunity WORD 3924: 3925: -- Route Map: set extcommunity rt EXTCOMMUNITY 3926: This command set Route Target value. 3927: 3928: -- Route Map: set extcommunity soo EXTCOMMUNITY 3929: This command set Site of Origin value. 3930: 3931: 3932: File: quagga.info, Node: Displaying BGP routes, Next: Capability Negotiation, Prev: BGP Extended Communities Attribute, Up: BGP 3933: 3934: 10.10 Displaying BGP Routes 3935: =========================== 3936: 3937: * Menu: 3938: 3939: * Show IP BGP:: 3940: * More Show IP BGP:: 3941: 3942: 3943: File: quagga.info, Node: Show IP BGP, Next: More Show IP BGP, Up: Displaying BGP routes 3944: 3945: 10.10.1 Show IP BGP 3946: ------------------- 3947: 3948: -- Command: show ip bgp 3949: -- Command: show ip bgp A.B.C.D 3950: -- Command: show ip bgp X:X::X:X 3951: This command displays BGP routes. When no route is specified it 3952: display all of IPv4 BGP routes. 3953: 3954: BGP table version is 0, local router ID is 10.1.1.1 3955: Status codes: s suppressed, d damped, h history, * valid, > best, i - internal 3956: Origin codes: i - IGP, e - EGP, ? - incomplete 3957: 3958: Network Next Hop Metric LocPrf Weight Path 3959: *> 1.1.1.1/32 0.0.0.0 0 32768 i 3960: 3961: Total number of prefixes 1 3962: 3963: 3964: File: quagga.info, Node: More Show IP BGP, Prev: Show IP BGP, Up: Displaying BGP routes 3965: 3966: 10.10.2 More Show IP BGP 3967: ------------------------ 3968: 3969: -- Command: show ip bgp regexp LINE 3970: This command display BGP routes using AS path regular expression 3971: (*note Display BGP Routes by AS Path::). 3972: 3973: -- Command: show ip bgp community COMMUNITY 3974: -- Command: show ip bgp community COMMUNITY exact-match 3975: This command display BGP routes using COMMUNITY (*note Display BGP 3976: Routes by Community::). 3977: 3978: -- Command: show ip bgp community-list WORD 3979: -- Command: show ip bgp community-list WORD exact-match 3980: This command display BGP routes using community list (*note 3981: Display BGP Routes by Community::). 3982: 3983: -- Command: show ip bgp summary 3984: 3985: -- Command: show ip bgp neighbor [PEER] 3986: 3987: -- Command: clear ip bgp PEER 3988: Clear peers which have addresses of X.X.X.X 3989: 3990: -- Command: clear ip bgp PEER soft in 3991: Clear peer using soft reconfiguration. 3992: 3993: -- Command: show ip bgp dampened-paths 3994: Display paths suppressed due to dampening 3995: 3996: -- Command: show ip bgp flap-statistics 3997: Display flap statistics of routes 3998: 3999: -- Command: show debug 4000: 4001: -- Command: debug event 4002: 4003: -- Command: debug update 4004: 4005: -- Command: debug keepalive 4006: 4007: -- Command: no debug event 4008: 4009: -- Command: no debug update 4010: 4011: -- Command: no debug keepalive 4012: 4013: 4014: File: quagga.info, Node: Capability Negotiation, Next: Route Reflector, Prev: Displaying BGP routes, Up: BGP 4015: 4016: 10.11 Capability Negotiation 4017: ============================ 4018: 4019: When adding IPv6 routing information exchange feature to BGP. There 4020: were some proposals. IETF (Internet Engineering Task Force) IDR (Inter 4021: Domain Routing) WG (Working group) adopted a proposal called 4022: Multiprotocol Extension for BGP. The specification is described in 4023: `RFC2283'. The protocol does not define new protocols. It defines new 4024: attributes to existing BGP. When it is used exchanging IPv6 routing 4025: information it is called BGP-4+. When it is used for exchanging 4026: multicast routing information it is called MBGP. 4027: 4028: `bgpd' supports Multiprotocol Extension for BGP. So if remote peer 4029: supports the protocol, `bgpd' can exchange IPv6 and/or multicast 4030: routing information. 4031: 4032: Traditional BGP did not have the feature to detect remote peer's 4033: capabilities, e.g. whether it can handle prefix types other than IPv4 4034: unicast routes. This was a big problem using Multiprotocol Extension 4035: for BGP to operational network. `RFC2842, Capabilities Advertisement 4036: with BGP-4' adopted a feature called Capability Negotiation. `bgpd' use 4037: this Capability Negotiation to detect the remote peer's capabilities. 4038: If the peer is only configured as IPv4 unicast neighbor, `bgpd' does 4039: not send these Capability Negotiation packets (at least not unless 4040: other optional BGP features require capability negotation). 4041: 4042: By default, Quagga will bring up peering with minimal common 4043: capability for the both sides. For example, local router has unicast 4044: and multicast capabilitie and remote router has unicast capability. In 4045: this case, the local router will establish the connection with unicast 4046: only capability. When there are no common capabilities, Quagga sends 4047: Unsupported Capability error and then resets the connection. 4048: 4049: If you want to completely match capabilities with remote peer. 4050: Please use `strict-capability-match' command. 4051: 4052: -- BGP: neighbor PEER strict-capability-match 4053: -- BGP: no neighbor PEER strict-capability-match 4054: Strictly compares remote capabilities and local capabilities. If 4055: capabilities are different, send Unsupported Capability error then 4056: reset connection. 4057: 4058: You may want to disable sending Capability Negotiation OPEN message 4059: optional parameter to the peer when remote peer does not implement 4060: Capability Negotiation. Please use `dont-capability-negotiate' command 4061: to disable the feature. 4062: 4063: -- BGP: neighbor PEER dont-capability-negotiate 4064: -- BGP: no neighbor PEER dont-capability-negotiate 4065: Suppress sending Capability Negotiation as OPEN message optional 4066: parameter to the peer. This command only affects the peer is 4067: configured other than IPv4 unicast configuration. 4068: 4069: When remote peer does not have capability negotiation feature, remote 4070: peer will not send any capabilities at all. In that case, bgp 4071: configures the peer with configured capabilities. 4072: 4073: You may prefer locally configured capabilities more than the 4074: negotiated capabilities even though remote peer sends capabilities. If 4075: the peer is configured by `override-capability', `bgpd' ignores 4076: received capabilities then override negotiated capabilities with 4077: configured values. 4078: 4079: -- BGP: neighbor PEER override-capability 4080: -- BGP: no neighbor PEER override-capability 4081: Override the result of Capability Negotiation with local 4082: configuration. Ignore remote peer's capability value. 4083: 4084: 4085: File: quagga.info, Node: Route Reflector, Next: Route Server, Prev: Capability Negotiation, Up: BGP 4086: 4087: 10.12 Route Reflector 4088: ===================== 4089: 4090: -- BGP: bgp cluster-id A.B.C.D 4091: 4092: -- BGP: neighbor PEER route-reflector-client 4093: -- BGP: no neighbor PEER route-reflector-client 4094: 4095: 4096: File: quagga.info, Node: Route Server, Next: How to set up a 6-Bone connection, Prev: Route Reflector, Up: BGP 4097: 4098: 10.13 Route Server 4099: ================== 4100: 4101: At an Internet Exchange point, many ISPs are connected to each other by 4102: external BGP peering. Normally these external BGP connection are done 4103: by `full mesh' method. As with internal BGP full mesh formation, this 4104: method has a scaling problem. 4105: 4106: This scaling problem is well known. Route Server is a method to 4107: resolve the problem. Each ISP's BGP router only peers to Route Server. 4108: Route Server serves as BGP information exchange to other BGP routers. 4109: By applying this method, numbers of BGP connections is reduced from 4110: O(n*(n-1)/2) to O(n). 4111: 4112: Unlike normal BGP router, Route Server must have several routing 4113: tables for managing different routing policies for each BGP speaker. 4114: We call the routing tables as different `view's. `bgpd' can work as 4115: normal BGP router or Route Server or both at the same time. 4116: 4117: * Menu: 4118: 4119: * Multiple instance:: 4120: * BGP instance and view:: 4121: * Routing policy:: 4122: * Viewing the view:: 4123: 4124: 4125: File: quagga.info, Node: Multiple instance, Next: BGP instance and view, Up: Route Server 4126: 4127: 10.13.1 Multiple instance 4128: ------------------------- 4129: 4130: To enable multiple view function of `bgpd', you must turn on multiple 4131: instance feature beforehand. 4132: 4133: -- Command: bgp multiple-instance 4134: Enable BGP multiple instance feature. After this feature is 4135: enabled, you can make multiple BGP instances or multiple BGP views. 4136: 4137: -- Command: no bgp multiple-instance 4138: Disable BGP multiple instance feature. You can not disable this 4139: feature when BGP multiple instances or views exist. 4140: 4141: When you want to make configuration more Cisco like one, 4142: 4143: -- Command: bgp config-type cisco 4144: Cisco compatible BGP configuration output. 4145: 4146: When bgp config-type cisco is specified, 4147: 4148: "no synchronization" is displayed. "no auto-summary" is displayed. 4149: 4150: "network" and "aggregate-address" argument is displayed as "A.B.C.D 4151: M.M.M.M" 4152: 4153: Quagga: network 10.0.0.0/8 Cisco: network 10.0.0.0 4154: 4155: Quagga: aggregate-address 192.168.0.0/24 Cisco: aggregate-address 4156: 192.168.0.0 255.255.255.0 4157: 4158: Community attribute handling is also different. If there is no 4159: configuration is specified community attribute and extended community 4160: attribute are sent to neighbor. When user manually disable the feature 4161: community attribute is not sent to the neighbor. In case of `bgp 4162: config-type cisco' is specified, community attribute is not sent to the 4163: neighbor by default. To send community attribute user has to specify 4164: `neighbor A.B.C.D send-community' command. 4165: 4166: ! 4167: router bgp 1 4168: neighbor 10.0.0.1 remote-as 1 4169: no neighbor 10.0.0.1 send-community 4170: ! 4171: router bgp 1 4172: neighbor 10.0.0.1 remote-as 1 4173: neighbor 10.0.0.1 send-community 4174: ! 4175: 4176: -- Command: bgp config-type zebra 4177: Quagga style BGP configuration. This is default. 4178: 4179: 4180: File: quagga.info, Node: BGP instance and view, Next: Routing policy, Prev: Multiple instance, Up: Route Server 4181: 4182: 10.13.2 BGP instance and view 4183: ----------------------------- 4184: 4185: BGP instance is a normal BGP process. The result of route selection 4186: goes to the kernel routing table. You can setup different AS at the 4187: same time when BGP multiple instance feature is enabled. 4188: 4189: -- Command: router bgp AS-NUMBER 4190: Make a new BGP instance. You can use arbitrary word for the NAME. 4191: 4192: bgp multiple-instance 4193: ! 4194: router bgp 1 4195: neighbor 10.0.0.1 remote-as 2 4196: neighbor 10.0.0.2 remote-as 3 4197: ! 4198: router bgp 2 4199: neighbor 10.0.0.3 remote-as 4 4200: neighbor 10.0.0.4 remote-as 5 4201: 4202: BGP view is almost same as normal BGP process. The result of route 4203: selection does not go to the kernel routing table. BGP view is only 4204: for exchanging BGP routing information. 4205: 4206: -- Command: router bgp AS-NUMBER view NAME 4207: Make a new BGP view. You can use arbitrary word for the NAME. 4208: This view's route selection result does not go to the kernel 4209: routing table. 4210: 4211: With this command, you can setup Route Server like below. 4212: 4213: bgp multiple-instance 4214: ! 4215: router bgp 1 view 1 4216: neighbor 10.0.0.1 remote-as 2 4217: neighbor 10.0.0.2 remote-as 3 4218: ! 4219: router bgp 2 view 2 4220: neighbor 10.0.0.3 remote-as 4 4221: neighbor 10.0.0.4 remote-as 5 4222: 4223: 4224: File: quagga.info, Node: Routing policy, Next: Viewing the view, Prev: BGP instance and view, Up: Route Server 4225: 4226: 10.13.3 Routing policy 4227: ---------------------- 4228: 4229: You can set different routing policy for a peer. For example, you can 4230: set different filter for a peer. 4231: 4232: bgp multiple-instance 4233: ! 4234: router bgp 1 view 1 4235: neighbor 10.0.0.1 remote-as 2 4236: neighbor 10.0.0.1 distribute-list 1 in 4237: ! 4238: router bgp 1 view 2 4239: neighbor 10.0.0.1 remote-as 2 4240: neighbor 10.0.0.1 distribute-list 2 in 4241: 4242: This means BGP update from a peer 10.0.0.1 goes to both BGP view 1 4243: and view 2. When the update is inserted into view 1, distribute-list 1 4244: is applied. On the other hand, when the update is inserted into view 2, 4245: distribute-list 2 is applied. 4246: 4247: 4248: File: quagga.info, Node: Viewing the view, Prev: Routing policy, Up: Route Server 4249: 4250: 10.13.4 Viewing the view 4251: ------------------------ 4252: 4253: To display routing table of BGP view, you must specify view name. 4254: 4255: -- Command: show ip bgp view NAME 4256: Display routing table of BGP view NAME. 4257: 4258: 4259: File: quagga.info, Node: How to set up a 6-Bone connection, Next: Dump BGP packets and table, Prev: Route Server, Up: BGP 4260: 4261: 10.14 How to set up a 6-Bone connection 4262: ======================================= 4263: 4264: zebra configuration 4265: =================== 4266: ! 4267: ! Actually there is no need to configure zebra 4268: ! 4269: 4270: bgpd configuration 4271: ================== 4272: ! 4273: ! This means that routes go through zebra and into the kernel. 4274: ! 4275: router zebra 4276: ! 4277: ! MP-BGP configuration 4278: ! 4279: router bgp 7675 4280: bgp router-id 10.0.0.1 4281: neighbor 3ffe:1cfa:0:2:2a0:c9ff:fe9e:f56 remote-as AS-NUMBER 4282: ! 4283: address-family ipv6 4284: network 3ffe:506::/32 4285: neighbor 3ffe:1cfa:0:2:2a0:c9ff:fe9e:f56 activate 4286: neighbor 3ffe:1cfa:0:2:2a0:c9ff:fe9e:f56 route-map set-nexthop out 4287: neighbor 3ffe:1cfa:0:2:2c0:4fff:fe68:a231 remote-as AS-NUMBER 4288: neighbor 3ffe:1cfa:0:2:2c0:4fff:fe68:a231 route-map set-nexthop out 4289: exit-address-family 4290: ! 4291: ipv6 access-list all permit any 4292: ! 4293: ! Set output nexthop address. 4294: ! 4295: route-map set-nexthop permit 10 4296: match ipv6 address all 4297: set ipv6 nexthop global 3ffe:1cfa:0:2:2c0:4fff:fe68:a225 4298: set ipv6 nexthop local fe80::2c0:4fff:fe68:a225 4299: ! 4300: ! logfile FILENAME is obsolete. Please use log file FILENAME 4301: 4302: log file bgpd.log 4303: ! 4304: 4305: 4306: File: quagga.info, Node: Dump BGP packets and table, Next: BGP Configuration Examples, Prev: How to set up a 6-Bone connection, Up: BGP 4307: 4308: 10.15 Dump BGP packets and table 4309: ================================ 4310: 4311: -- Command: dump bgp all PATH 4312: -- Command: dump bgp all PATH INTERVAL 4313: Dump all BGP packet and events to PATH file. 4314: 4315: -- Command: dump bgp updates PATH 4316: -- Command: dump bgp updates PATH INTERVAL 4317: Dump BGP updates to PATH file. 4318: 4319: -- Command: dump bgp routes PATH 4320: -- Command: dump bgp routes PATH 4321: Dump whole BGP routing table to PATH. This is heavy process. 4322: 4323: 4324: File: quagga.info, Node: BGP Configuration Examples, Prev: Dump BGP packets and table, Up: BGP 4325: 4326: 10.16 BGP Configuration Examples 4327: ================================ 4328: 4329: Example of a session to an upstream, advertising only one prefix to it. 4330: 4331: router bgp 64512 4332: bgp router-id 10.236.87.1 4333: network 10.236.87.0/24 4334: neighbor upstream peer-group 4335: neighbor upstream remote-as 64515 4336: neighbor upstream capability dynamic 4337: neighbor upstream prefix-list pl-allowed-adv out 4338: neighbor 10.1.1.1 peer-group upstream 4339: neighbor 10.1.1.1 description ACME ISP 4340: ! 4341: ip prefix-list pl-allowed-adv seq 5 permit 82.195.133.0/25 4342: ip prefix-list pl-allowed-adv seq 10 deny any 4343: 4344: A more complex example. With upstream, peer and customer sessions. 4345: Advertising global prefixes and NO_EXPORT prefixes and providing 4346: actions for customer routes based on community values. Extensive use of 4347: route-maps and the 'call' feature to support selective advertising of 4348: prefixes. This example is intended as guidance only, it has NOT been 4349: tested and almost certainly containts silly mistakes, if not serious 4350: flaws. 4351: 4352: router bgp 64512 4353: bgp router-id 10.236.87.1 4354: network 10.123.456.0/24 4355: network 10.123.456.128/25 route-map rm-no-export 4356: neighbor upstream capability dynamic 4357: neighbor upstream route-map rm-upstream-out out 4358: neighbor cust capability dynamic 4359: neighbor cust route-map rm-cust-in in 4360: neighbor cust route-map rm-cust-out out 4361: neighbor cust send-community both 4362: neighbor peer capability dynamic 4363: neighbor peer route-map rm-peer-in in 4364: neighbor peer route-map rm-peer-out out 4365: neighbor peer send-community both 4366: neighbor 10.1.1.1 remote-as 64515 4367: neighbor 10.1.1.1 peer-group upstream 4368: neighbor 10.2.1.1 remote-as 64516 4369: neighbor 10.2.1.1 peer-group upstream 4370: neighbor 10.3.1.1 remote-as 64517 4371: neighbor 10.3.1.1 peer-group cust-default 4372: neighbor 10.3.1.1 description customer1 4373: neighbor 10.3.1.1 prefix-list pl-cust1-network in 4374: neighbor 10.4.1.1 remote-as 64518 4375: neighbor 10.4.1.1 peer-group cust 4376: neighbor 10.4.1.1 prefix-list pl-cust2-network in 4377: neighbor 10.4.1.1 description customer2 4378: neighbor 10.5.1.1 remote-as 64519 4379: neighbor 10.5.1.1 peer-group peer 4380: neighbor 10.5.1.1 prefix-list pl-peer1-network in 4381: neighbor 10.5.1.1 description peer AS 1 4382: neighbor 10.6.1.1 remote-as 64520 4383: neighbor 10.6.1.1 peer-group peer 4384: neighbor 10.6.1.1 prefix-list pl-peer2-network in 4385: neighbor 10.6.1.1 description peer AS 2 4386: ! 4387: ip prefix-list pl-default permit 0.0.0.0/0 4388: ! 4389: ip prefix-list pl-upstream-peers permit 10.1.1.1/32 4390: ip prefix-list pl-upstream-peers permit 10.2.1.1/32 4391: ! 4392: ip prefix-list pl-cust1-network permit 10.3.1.0/24 4393: ip prefix-list pl-cust1-network permit 10.3.2.0/24 4394: ! 4395: ip prefix-list pl-cust2-network permit 10.4.1.0/24 4396: ! 4397: ip prefix-list pl-peer1-network permit 10.5.1.0/24 4398: ip prefix-list pl-peer1-network permit 10.5.2.0/24 4399: ip prefix-list pl-peer1-network permit 192.168.0.0/24 4400: ! 4401: ip prefix-list pl-peer2-network permit 10.6.1.0/24 4402: ip prefix-list pl-peer2-network permit 10.6.2.0/24 4403: ip prefix-list pl-peer2-network permit 192.168.1.0/24 4404: ip prefix-list pl-peer2-network permit 192.168.2.0/24 4405: ip prefix-list pl-peer2-network permit 172.16.1/24 4406: ! 4407: ip as-path access-list asp-own-as permit ^$ 4408: ip as-path access-list asp-own-as permit _64512_ 4409: ! 4410: ! ################################################################# 4411: ! Match communities we provide actions for, on routes receives from 4412: ! customers. Communities values of <our-ASN>:X, with X, have actions: 4413: ! 4414: ! 100 - blackhole the prefix 4415: ! 200 - set no_export 4416: ! 300 - advertise only to other customers 4417: ! 400 - advertise only to upstreams 4418: ! 500 - set no_export when advertising to upstreams 4419: ! 2X00 - set local_preference to X00 4420: ! 4421: ! blackhole the prefix of the route 4422: ip community-list standard cm-blackhole permit 64512:100 4423: ! 4424: ! set no-export community before advertising 4425: ip community-list standard cm-set-no-export permit 64512:200 4426: ! 4427: ! advertise only to other customers 4428: ip community-list standard cm-cust-only permit 64512:300 4429: ! 4430: ! advertise only to upstreams 4431: ip community-list standard cm-upstream-only permit 64512:400 4432: ! 4433: ! advertise to upstreams with no-export 4434: ip community-list standard cm-upstream-noexport permit 64512:500 4435: ! 4436: ! set local-pref to least significant 3 digits of the community 4437: ip community-list standard cm-prefmod-100 permit 64512:2100 4438: ip community-list standard cm-prefmod-200 permit 64512:2200 4439: ip community-list standard cm-prefmod-300 permit 64512:2300 4440: ip community-list standard cm-prefmod-400 permit 64512:2400 4441: ip community-list expanded cme-prefmod-range permit 64512:2... 4442: ! 4443: ! Informational communities 4444: ! 4445: ! 3000 - learned from upstream 4446: ! 3100 - learned from customer 4447: ! 3200 - learned from peer 4448: ! 4449: ip community-list standard cm-learnt-upstream permit 64512:3000 4450: ip community-list standard cm-learnt-cust permit 64512:3100 4451: ip community-list standard cm-learnt-peer permit 64512:3200 4452: ! 4453: ! ################################################################### 4454: ! Utility route-maps 4455: ! 4456: ! These utility route-maps generally should not used to permit/deny 4457: ! routes, i.e. they do not have meaning as filters, and hence probably 4458: ! should be used with 'on-match next'. These all finish with an empty 4459: ! permit entry so as not interfere with processing in the caller. 4460: ! 4461: route-map rm-no-export permit 10 4462: set community additive no-export 4463: route-map rm-no-export permit 20 4464: ! 4465: route-map rm-blackhole permit 10 4466: description blackhole, up-pref and ensure it cant escape this AS 4467: set ip next-hop 127.0.0.1 4468: set local-preference 10 4469: set community additive no-export 4470: route-map rm-blackhole permit 20 4471: ! 4472: ! Set local-pref as requested 4473: route-map rm-prefmod permit 10 4474: match community cm-prefmod-100 4475: set local-preference 100 4476: route-map rm-prefmod permit 20 4477: match community cm-prefmod-200 4478: set local-preference 200 4479: route-map rm-prefmod permit 30 4480: match community cm-prefmod-300 4481: set local-preference 300 4482: route-map rm-prefmod permit 40 4483: match community cm-prefmod-400 4484: set local-preference 400 4485: route-map rm-prefmod permit 50 4486: ! 4487: ! Community actions to take on receipt of route. 4488: route-map rm-community-in permit 10 4489: description check for blackholing, no point continuing if it matches. 4490: match community cm-blackhole 4491: call rm-blackhole 4492: route-map rm-community-in permit 20 4493: match community cm-set-no-export 4494: call rm-no-export 4495: on-match next 4496: route-map rm-community-in permit 30 4497: match community cme-prefmod-range 4498: call rm-prefmod 4499: route-map rm-community-in permit 40 4500: ! 4501: ! ##################################################################### 4502: ! Community actions to take when advertising a route. 4503: ! These are filtering route-maps, 4504: ! 4505: ! Deny customer routes to upstream with cust-only set. 4506: route-map rm-community-filt-to-upstream deny 10 4507: match community cm-learnt-cust 4508: match community cm-cust-only 4509: route-map rm-community-filt-to-upstream permit 20 4510: ! 4511: ! Deny customer routes to other customers with upstream-only set. 4512: route-map rm-community-filt-to-cust deny 10 4513: match community cm-learnt-cust 4514: match community cm-upstream-only 4515: route-map rm-community-filt-to-cust permit 20 4516: ! 4517: ! ################################################################### 4518: ! The top-level route-maps applied to sessions. Further entries could 4519: ! be added obviously.. 4520: ! 4521: ! Customers 4522: route-map rm-cust-in permit 10 4523: call rm-community-in 4524: on-match next 4525: route-map rm-cust-in permit 20 4526: set community additive 64512:3100 4527: route-map rm-cust-in permit 30 4528: ! 4529: route-map rm-cust-out permit 10 4530: call rm-community-filt-to-cust 4531: on-match next 4532: route-map rm-cust-out permit 20 4533: ! 4534: ! Upstream transit ASes 4535: route-map rm-upstream-out permit 10 4536: description filter customer prefixes which are marked cust-only 4537: call rm-community-filt-to-upstream 4538: on-match next 4539: route-map rm-upstream-out permit 20 4540: description only customer routes are provided to upstreams/peers 4541: match community cm-learnt-cust 4542: ! 4543: ! Peer ASes 4544: ! outbound policy is same as for upstream 4545: route-map rm-peer-out permit 10 4546: call rm-upstream-out 4547: ! 4548: route-map rm-peer-in permit 10 4549: set community additive 64512:3200 4550: 4551: 4552: File: quagga.info, Node: Configuring Quagga as a Route Server, Next: VTY shell, Prev: BGP, Up: Top 4553: 4554: 11 Configuring Quagga as a Route Server 4555: *************************************** 4556: 4557: The purpose of a Route Server is to centralize the peerings between BGP 4558: speakers. For example if we have an exchange point scenario with four 4559: BGP speakers, each of which maintaining a BGP peering with the other 4560: three (*note fig:full-mesh::), we can convert it into a centralized 4561: scenario where each of the four establishes a single BGP peering 4562: against the Route Server (*note fig:route-server::). 4563: 4564: We will first describe briefly the Route Server model implemented by 4565: Quagga. We will explain the commands that have been added for 4566: configuring that model. And finally we will show a full example of 4567: Quagga configured as Route Server. 4568: 4569: * Menu: 4570: 4571: * Description of the Route Server model:: 4572: * Commands for configuring a Route Server:: 4573: * Example of Route Server Configuration:: 4574: 4575: 4576: File: quagga.info, Node: Description of the Route Server model, Next: Commands for configuring a Route Server, Up: Configuring Quagga as a Route Server 4577: 4578: 11.1 Description of the Route Server model 4579: ========================================== 4580: 4581: First we are going to describe the normal processing that BGP 4582: announcements suffer inside a standard BGP speaker, as shown in *note 4583: fig:normal-processing::, it consists of three steps: 4584: 4585: * When an announcement is received from some peer, the `In' filters 4586: configured for that peer are applied to the announcement. These 4587: filters can reject the announcement, accept it unmodified, or 4588: accept it with some of its attributes modified. 4589: 4590: * The announcements that pass the `In' filters go into the Best Path 4591: Selection process, where they are compared to other announcements 4592: referred to the same destination that have been received from 4593: different peers (in case such other announcements exist). For each 4594: different destination, the announcement which is selected as the 4595: best is inserted into the BGP speaker's Loc-RIB. 4596: 4597: * The routes which are inserted in the Loc-RIB are considered for 4598: announcement to all the peers (except the one from which the route 4599: came). This is done by passing the routes in the Loc-RIB through 4600: the `Out' filters corresponding to each peer. These filters can 4601: reject the route, accept it unmodified, or accept it with some of 4602: its attributes modified. Those routes which are accepted by the 4603: `Out' filters of a peer are announced to that peer. 4604: 4605: [image src="fig-normal-processing.png" alt="Normal announcement processing" text=" 4606: _______________________________ 4607: / _________ _________ \\ 4608: From Peer A --->|(A)-|Best | | |-[A]|--->To Peer A 4609: From Peer B --->|(B)-|Path |-->|Local-RIB|-[B]|--->To Peer B 4610: From Peer C --->|(C)-|Selection| | |-[C]|--->To Peer C 4611: From Peer D --->|(D)-|_________| |_________|-[D]|--->To Peer D 4612: \\_______________________________/ 4613: 4614: Key: (X) - 'In' Filter applied to Peer X's announcements 4615: [X] - 'Out' Filter applied to announcements to Peer X 4616: "] 4617: 4618: Figure 11.1: Announcement processing inside a "normal" BGP speaker 4619: 4620: [image src="fig_topologies_full.png" alt="Full Mesh BGP Topology" text="(RF1)--(RF2) 4621: | \\ / | 4622: | \\/ | 4623: | /\\ | 4624: | / \\ | 4625: (RF3)--(RF4) 4626: "] 4627: 4628: Figure 11.2: Full Mesh 4629: 4630: [image src="fig_topologies_rs.png" alt="Route Server BGP Topology" text="(RF1) (RF2) 4631: \\ / 4632: [RS] 4633: / \\ 4634: (RF3) (RF4) 4635: "] 4636: 4637: Figure 11.3: Route Server and clients 4638: 4639: Of course we want that the routing tables obtained in each of the 4640: routers are the same when using the route server than when not. But as 4641: a consequence of having a single BGP peering (against the route 4642: server), the BGP speakers can no longer distinguish from/to which peer 4643: each announce comes/goes. This means that the routers connected to the 4644: route server are not able to apply by themselves the same input/output 4645: filters as in the full mesh scenario, so they have to delegate those 4646: functions to the route server. 4647: 4648: Even more, the "best path" selection must be also performed inside 4649: the route server on behalf of its clients. The reason is that if, after 4650: applying the filters of the announcer and the (potential) receiver, the 4651: route server decides to send to some client two or more different 4652: announcements referred to the same destination, the client will only 4653: retain the last one, considering it as an implicit withdrawal of the 4654: previous announcements for the same destination. This is the expected 4655: behavior of a BGP speaker as defined in `RFC1771', and even though 4656: there are some proposals of mechanisms that permit multiple paths for 4657: the same destination to be sent through a single BGP peering, none are 4658: currently supported by most existing BGP implementations. 4659: 4660: As a consequence a route server must maintain additional information 4661: and perform additional tasks for a RS-client that those necessary for 4662: common BGP peerings. Essentially a route server must: 4663: 4664: * Maintain a separated Routing Information Base (Loc-RIB) for each 4665: peer configured as RS-client, containing the routes selected as a 4666: result of the "Best Path Selection" process that is performed on 4667: behalf of that RS-client. 4668: 4669: * Whenever it receives an announcement from a RS-client, it must 4670: consider it for the Loc-RIBs of the other RS-clients. 4671: 4672: * This means that for each of them the route server must pass 4673: the announcement through the appropriate `Out' filter of the 4674: announcer. 4675: 4676: * Then through the appropriate `In' filter of the potential 4677: receiver. 4678: 4679: * Only if the announcement is accepted by both filters it will 4680: be passed to the "Best Path Selection" process. 4681: 4682: * Finally, it might go into the Loc-RIB of the receiver. 4683: 4684: When we talk about the "appropriate" filter, both the announcer and 4685: the receiver of the route must be taken into account. Suppose that the 4686: route server receives an announcement from client A, and the route 4687: server is considering it for the Loc-RIB of client B. The filters that 4688: should be applied are the same that would be used in the full mesh 4689: scenario, i.e., first the `Out' filter of router A for announcements 4690: going to router B, and then the `In' filter of router B for 4691: announcements coming from router A. 4692: 4693: We call "Export Policy" of a RS-client to the set of `Out' filters 4694: that the client would use if there was no route server. The same 4695: applies for the "Import Policy" of a RS-client and the set of `In' 4696: filters of the client if there was no route server. 4697: 4698: It is also common to demand from a route server that it does not 4699: modify some BGP attributes (next-hop, as-path and MED) that are usually 4700: modified by standard BGP speakers before announcing a route. 4701: 4702: The announcement processing model implemented by Quagga is shown in 4703: *note fig:rs-processing::. The figure shows a mixture of RS-clients (B, 4704: C and D) with normal BGP peers (A). There are some details that worth 4705: additional comments: 4706: 4707: * Announcements coming from a normal BGP peer are also considered 4708: for the Loc-RIBs of all the RS-clients. But logically they do not 4709: pass through any export policy. 4710: 4711: * Those peers that are configured as RS-clients do not receive any 4712: announce from the `Main' Loc-RIB. 4713: 4714: * Apart from import and export policies, `In' and `Out' filters can 4715: also be set for RS-clients. `In' filters might be useful when the 4716: route server has also normal BGP peers. On the other hand, `Out' 4717: filters for RS-clients are probably unnecessary, but we decided 4718: not to remove them as they do not hurt anybody (they can always be 4719: left empty). 4720: 4721: [image src="fig-rs-processing.png" alt="Route Server Processing Model" text="From Peer A 4722: | From RS-Client B 4723: | | From RS-Client C 4724: | | | From RS-Client D 4725: | | | | 4726: | | | | Main / Normal RIB 4727: | | | | ________________________________ 4728: | | | | / _________ _________ \\ 4729: | | | +--->|(D)-|Best | | Main | | 4730: | | +--|--->|(C)-|Path |-->|Local-RIB|->[A]|--->To Peer A 4731: | +--|--|--->|(B)-|Selection| | | | 4732: +--|--|--|--->|(A)-|_________| |_________| | 4733: | | | | \\________________________________/ 4734: | | | | 4735: | | | | ________________________________ 4736: | | | | / _________ _________ \\ 4737: | | | +--->*D*->|{B}-|Best | |RS-Client| | 4738: | | +--|--->*C*->|{B}-|Path |-->|Local-RIB|->[B]|--->To RS-Client B 4739: | | | | | |Selection| | for B | | 4740: +--|--|--|-------->|{B}-|_________| |_________| | 4741: | | | | \\________________________________/ 4742: | | | | 4743: | | | | ________________________________ 4744: | | | | / _________ _________ \\ 4745: | | | +--->*D*->|{C}-|Best | |RS-Client| | 4746: | | | | | |Path |-->|Local-RIB|->[C]|--->To RS-Client C 4747: | +--|--|--->*B*->|{C}-|Selection| | for C | | 4748: +--|--|--|-------->|{C}-|_________| |_________| | 4749: | | | \\________________________________/ 4750: | | | 4751: | | | ________________________________ 4752: | | | / _________ _________ \\ 4753: | | | | |Best | |RS-Client| | 4754: | | +------>*C*->|{D}-|Path |-->|Local-RIB|->[D]|--->To RS-Client D 4755: | +--------->*B*->|{D}-|Selection| | for D | | 4756: +----------------->|{D}-|_________| |_________| | 4757: \\________________________________/ 4758: 4759: 4760: Key: (X) - 'In' Filter applied to Peer X's announcements before 4761: considering announcement for the normal main Local-RIB 4762: [X] - 'Out' Filter applied to announcements to Peer X 4763: *X* - 'Export' Filter of RS-Client X, to apply X's policies 4764: before its routes may be considered for other RS-Clients 4765: RIBs. 4766: {X} - 'Import' Filter of RS-Client X, to apply X's policies 4767: on routes before allowing them into X's RIB. 4768: "] 4769: 4770: Figure 11.4: Announcement processing model implemented by the Route 4771: Server 4772: 4773: 4774: 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 4775: 4776: 11.2 Commands for configuring a Route Server 4777: ============================================ 4778: 4779: Now we will describe the commands that have been added to quagga in 4780: order to support the route server features. 4781: 4782: -- Route-Server: neighbor PEER-GROUP route-server-client 4783: -- Route-Server: neighbor A.B.C.D route-server-client 4784: -- Route-Server: neighbor X:X::X:X route-server-client 4785: This command configures the peer given by PEER, A.B.C.D or 4786: X:X::X:X as an RS-client. 4787: 4788: Actually this command is not new, it already existed in standard 4789: Quagga. It enables the transparent mode for the specified peer. 4790: This means that some BGP attributes (as-path, next-hop and MED) of 4791: the routes announced to that peer are not modified. 4792: 4793: With the route server patch, this command, apart from setting the 4794: transparent mode, creates a new Loc-RIB dedicated to the specified 4795: peer (those named `Loc-RIB for X' in *note Figure 11.4: 4796: fig:rs-processing.). Starting from that moment, every announcement 4797: received by the route server will be also considered for the new 4798: Loc-RIB. 4799: 4800: -- Route-Server: neigbor {A.B.C.D|X.X::X.X|peer-group} route-map WORD 4801: {import|export} 4802: This set of commands can be used to specify the route-map that 4803: represents the Import or Export policy of a peer which is 4804: configured as a RS-client (with the previous command). 4805: 4806: -- Route-Server: match peer {A.B.C.D|X:X::X:X} 4807: This is a new _match_ statement for use in route-maps, enabling 4808: them to describe import/export policies. As we said before, an 4809: import/export policy represents a set of input/output filters of 4810: the RS-client. This statement makes possible that a single 4811: route-map represents the full set of filters that a BGP speaker 4812: would use for its different peers in a non-RS scenario. 4813: 4814: The _match peer_ statement has different semantics whether it is 4815: used inside an import or an export route-map. In the first case 4816: the statement matches if the address of the peer who sends the 4817: announce is the same that the address specified by 4818: {A.B.C.D|X:X::X:X}. For export route-maps it matches when 4819: {A.B.C.D|X:X::X:X} is the address of the RS-Client into whose 4820: Loc-RIB the announce is going to be inserted (how the same export 4821: policy is applied before different Loc-RIBs is shown in *note 4822: Figure 11.4: fig:rs-processing.). 4823: 4824: -- Route-map Command: call WORD 4825: This command (also used inside a route-map) jumps into a different 4826: route-map, whose name is specified by WORD. When the called 4827: route-map finishes, depending on its result the original route-map 4828: continues or not. Apart from being useful for making import/export 4829: route-maps easier to write, this command can also be used inside 4830: any normal (in or out) route-map. 4831: 4832: 4833: File: quagga.info, Node: Example of Route Server Configuration, Prev: Commands for configuring a Route Server, Up: Configuring Quagga as a Route Server 4834: 4835: 11.3 Example of Route Server Configuration 4836: ========================================== 4837: 4838: Finally we are going to show how to configure a Quagga daemon to act as 4839: a Route Server. For this purpose we are going to present a scenario 4840: without route server, and then we will show how to use the 4841: configurations of the BGP routers to generate the configuration of the 4842: route server. 4843: 4844: All the configuration files shown in this section have been taken 4845: from scenarios which were tested using the VNUML tool VNUML 4846: (http://www.dit.upm.es/vnuml). 4847: 4848: * Menu: 4849: 4850: * Configuration of the BGP routers without Route Server:: 4851: * Configuration of the BGP routers with Route Server:: 4852: * Configuration of the Route Server itself:: 4853: * Further considerations about Import and Export route-maps:: 4854: 4855: 4856: 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 4857: 4858: 11.3.1 Configuration of the BGP routers without Route Server 4859: ------------------------------------------------------------ 4860: 4861: We will suppose that our initial scenario is an exchange point with 4862: three BGP capable routers, named RA, RB and RC. Each of the BGP 4863: speakers generates some routes (with the NETWORK command), and 4864: establishes BGP peerings against the other two routers. These peerings 4865: have In and Out route-maps configured, named like "PEER-X-IN" or 4866: "PEER-X-OUT". For example the configuration file for router RA could be 4867: the following: 4868: 4869: #Configuration for router 'RA' 4870: ! 4871: hostname RA 4872: password **** 4873: ! 4874: router bgp 65001 4875: no bgp default ipv4-unicast 4876: neighbor 2001:0DB8::B remote-as 65002 4877: neighbor 2001:0DB8::C remote-as 65003 4878: ! 4879: address-family ipv6 4880: network 2001:0DB8:AAAA:1::/64 4881: network 2001:0DB8:AAAA:2::/64 4882: network 2001:0DB8:0000:1::/64 4883: network 2001:0DB8:0000:2::/64 4884: 4885: neighbor 2001:0DB8::B activate 4886: neighbor 2001:0DB8::B soft-reconfiguration inbound 4887: neighbor 2001:0DB8::B route-map PEER-B-IN in 4888: neighbor 2001:0DB8::B route-map PEER-B-OUT out 4889: 4890: neighbor 2001:0DB8::C activate 4891: neighbor 2001:0DB8::C soft-reconfiguration inbound 4892: neighbor 2001:0DB8::C route-map PEER-C-IN in 4893: neighbor 2001:0DB8::C route-map PEER-C-OUT out 4894: exit-address-family 4895: ! 4896: ipv6 prefix-list COMMON-PREFIXES seq 5 permit 2001:0DB8:0000::/48 ge 64 le 64 4897: ipv6 prefix-list COMMON-PREFIXES seq 10 deny any 4898: ! 4899: ipv6 prefix-list PEER-A-PREFIXES seq 5 permit 2001:0DB8:AAAA::/48 ge 64 le 64 4900: ipv6 prefix-list PEER-A-PREFIXES seq 10 deny any 4901: ! 4902: ipv6 prefix-list PEER-B-PREFIXES seq 5 permit 2001:0DB8:BBBB::/48 ge 64 le 64 4903: ipv6 prefix-list PEER-B-PREFIXES seq 10 deny any 4904: ! 4905: ipv6 prefix-list PEER-C-PREFIXES seq 5 permit 2001:0DB8:CCCC::/48 ge 64 le 64 4906: ipv6 prefix-list PEER-C-PREFIXES seq 10 deny any 4907: ! 4908: route-map PEER-B-IN permit 10 4909: match ipv6 address prefix-list COMMON-PREFIXES 4910: set metric 100 4911: route-map PEER-B-IN permit 20 4912: match ipv6 address prefix-list PEER-B-PREFIXES 4913: set community 65001:11111 4914: ! 4915: route-map PEER-C-IN permit 10 4916: match ipv6 address prefix-list COMMON-PREFIXES 4917: set metric 200 4918: route-map PEER-C-IN permit 20 4919: match ipv6 address prefix-list PEER-C-PREFIXES 4920: set community 65001:22222 4921: ! 4922: route-map PEER-B-OUT permit 10 4923: match ipv6 address prefix-list PEER-A-PREFIXES 4924: ! 4925: route-map PEER-C-OUT permit 10 4926: match ipv6 address prefix-list PEER-A-PREFIXES 4927: ! 4928: line vty 4929: ! 4930: 4931: 4932: 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 4933: 4934: 11.3.2 Configuration of the BGP routers with Route Server 4935: --------------------------------------------------------- 4936: 4937: To convert the initial scenario into one with route server, first we 4938: must modify the configuration of routers RA, RB and RC. Now they must 4939: not peer between them, but only with the route server. For example, RA's 4940: configuration would turn into: 4941: 4942: # Configuration for router 'RA' 4943: ! 4944: hostname RA 4945: password **** 4946: ! 4947: router bgp 65001 4948: no bgp default ipv4-unicast 4949: neighbor 2001:0DB8::FFFF remote-as 65000 4950: ! 4951: address-family ipv6 4952: network 2001:0DB8:AAAA:1::/64 4953: network 2001:0DB8:AAAA:2::/64 4954: network 2001:0DB8:0000:1::/64 4955: network 2001:0DB8:0000:2::/64 4956: 4957: neighbor 2001:0DB8::FFFF activate 4958: neighbor 2001:0DB8::FFFF soft-reconfiguration inbound 4959: exit-address-family 4960: ! 4961: line vty 4962: ! 4963: 4964: Which is logically much simpler than its initial configuration, as 4965: it now maintains only one BGP peering and all the filters (route-maps) 4966: have disappeared. 4967: 4968: 4969: 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 4970: 4971: 11.3.3 Configuration of the Route Server itself 4972: ----------------------------------------------- 4973: 4974: As we said when we described the functions of a route server (*note 4975: Description of the Route Server model::), it is in charge of all the 4976: route filtering. To achieve that, the In and Out filters from the RA, 4977: RB and RC configurations must be converted into Import and Export 4978: policies in the route server. 4979: 4980: This is a fragment of the route server configuration (we only show 4981: the policies for client RA): 4982: 4983: # Configuration for Route Server ('RS') 4984: ! 4985: hostname RS 4986: password ix 4987: ! 4988: bgp multiple-instance 4989: ! 4990: router bgp 65000 view RS 4991: no bgp default ipv4-unicast 4992: neighbor 2001:0DB8::A remote-as 65001 4993: neighbor 2001:0DB8::B remote-as 65002 4994: neighbor 2001:0DB8::C remote-as 65003 4995: ! 4996: address-family ipv6 4997: neighbor 2001:0DB8::A activate 4998: neighbor 2001:0DB8::A route-server-client 4999: neighbor 2001:0DB8::A route-map RSCLIENT-A-IMPORT import 5000: neighbor 2001:0DB8::A route-map RSCLIENT-A-EXPORT export 5001: neighbor 2001:0DB8::A soft-reconfiguration inbound 5002: 5003: neighbor 2001:0DB8::B activate 5004: neighbor 2001:0DB8::B route-server-client 5005: neighbor 2001:0DB8::B route-map RSCLIENT-B-IMPORT import 5006: neighbor 2001:0DB8::B route-map RSCLIENT-B-EXPORT export 5007: neighbor 2001:0DB8::B soft-reconfiguration inbound 5008: 5009: neighbor 2001:0DB8::C activate 5010: neighbor 2001:0DB8::C route-server-client 5011: neighbor 2001:0DB8::C route-map RSCLIENT-C-IMPORT import 5012: neighbor 2001:0DB8::C route-map RSCLIENT-C-EXPORT export 5013: neighbor 2001:0DB8::C soft-reconfiguration inbound 5014: exit-address-family 5015: ! 5016: ipv6 prefix-list COMMON-PREFIXES seq 5 permit 2001:0DB8:0000::/48 ge 64 le 64 5017: ipv6 prefix-list COMMON-PREFIXES seq 10 deny any 5018: ! 5019: ipv6 prefix-list PEER-A-PREFIXES seq 5 permit 2001:0DB8:AAAA::/48 ge 64 le 64 5020: ipv6 prefix-list PEER-A-PREFIXES seq 10 deny any 5021: ! 5022: ipv6 prefix-list PEER-B-PREFIXES seq 5 permit 2001:0DB8:BBBB::/48 ge 64 le 64 5023: ipv6 prefix-list PEER-B-PREFIXES seq 10 deny any 5024: ! 5025: ipv6 prefix-list PEER-C-PREFIXES seq 5 permit 2001:0DB8:CCCC::/48 ge 64 le 64 5026: ipv6 prefix-list PEER-C-PREFIXES seq 10 deny any 5027: ! 5028: route-map RSCLIENT-A-IMPORT permit 10 5029: match peer 2001:0DB8::B 5030: call A-IMPORT-FROM-B 5031: route-map RSCLIENT-A-IMPORT permit 20 5032: match peer 2001:0DB8::C 5033: call A-IMPORT-FROM-C 5034: ! 5035: route-map A-IMPORT-FROM-B permit 10 5036: match ipv6 address prefix-list COMMON-PREFIXES 5037: set metric 100 5038: route-map A-IMPORT-FROM-B permit 20 5039: match ipv6 address prefix-list PEER-B-PREFIXES 5040: set community 65001:11111 5041: ! 5042: route-map A-IMPORT-FROM-C permit 10 5043: match ipv6 address prefix-list COMMON-PREFIXES 5044: set metric 200 5045: route-map A-IMPORT-FROM-C permit 20 5046: match ipv6 address prefix-list PEER-C-PREFIXES 5047: set community 65001:22222 5048: ! 5049: route-map RSCLIENT-A-EXPORT permit 10 5050: match peer 2001:0DB8::B 5051: match ipv6 address prefix-list PEER-A-PREFIXES 5052: route-map RSCLIENT-A-EXPORT permit 20 5053: match peer 2001:0DB8::C 5054: match ipv6 address prefix-list PEER-A-PREFIXES 5055: ! 5056: ... 5057: ... 5058: ... 5059: 5060: If you compare the initial configuration of RA with the route server 5061: configuration above, you can see how easy it is to generate the Import 5062: and Export policies for RA from the In and Out route-maps of RA's 5063: original configuration. 5064: 5065: When there was no route server, RA maintained two peerings, one with 5066: RB and another with RC. Each of this peerings had an In route-map 5067: configured. To build the Import route-map for client RA in the route 5068: server, simply add route-map entries following this scheme: 5069: 5070: route-map <NAME> permit 10 5071: match peer <Peer Address> 5072: call <In Route-Map for this Peer> 5073: route-map <NAME> permit 20 5074: match peer <Another Peer Address> 5075: call <In Route-Map for this Peer> 5076: 5077: This is exactly the process that has been followed to generate the 5078: route-map RSCLIENT-A-IMPORT. The route-maps that are called inside it 5079: (A-IMPORT-FROM-B and A-IMPORT-FROM-C) are exactly the same than the In 5080: route-maps from the original configuration of RA (PEER-B-IN and 5081: PEER-C-IN), only the name is different. 5082: 5083: The same could have been done to create the Export policy for RA 5084: (route-map RSCLIENT-A-EXPORT), but in this case the original Out 5085: route-maps where so simple that we decided not to use the CALL WORD 5086: commands, and we integrated all in a single route-map 5087: (RSCLIENT-A-EXPORT). 5088: 5089: The Import and Export policies for RB and RC are not shown, but the 5090: process would be identical. 5091: 5092: 5093: 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 5094: 5095: 11.3.4 Further considerations about Import and Export route-maps 5096: ---------------------------------------------------------------- 5097: 5098: The current version of the route server patch only allows to specify a 5099: route-map for import and export policies, while in a standard BGP 5100: speaker apart from route-maps there are other tools for performing 5101: input and output filtering (access-lists, community-lists, ...). But 5102: this does not represent any limitation, as all kinds of filters can be 5103: included in import/export route-maps. For example suppose that in the 5104: non-route-server scenario peer RA had the following filters configured 5105: for input from peer B: 5106: 5107: neighbor 2001:0DB8::B prefix-list LIST-1 in 5108: neighbor 2001:0DB8::B filter-list LIST-2 in 5109: neighbor 2001:0DB8::B route-map PEER-B-IN in 5110: ... 5111: ... 5112: route-map PEER-B-IN permit 10 5113: match ipv6 address prefix-list COMMON-PREFIXES 5114: set local-preference 100 5115: route-map PEER-B-IN permit 20 5116: match ipv6 address prefix-list PEER-B-PREFIXES 5117: set community 65001:11111 5118: 5119: It is posible to write a single route-map which is equivalent to the 5120: three filters (the community-list, the prefix-list and the route-map). 5121: That route-map can then be used inside the Import policy in the route 5122: server. Lets see how to do it: 5123: 5124: neighbor 2001:0DB8::A route-map RSCLIENT-A-IMPORT import 5125: ... 5126: ! 5127: ... 5128: route-map RSCLIENT-A-IMPORT permit 10 5129: match peer 2001:0DB8::B 5130: call A-IMPORT-FROM-B 5131: ... 5132: ... 5133: ! 5134: route-map A-IMPORT-FROM-B permit 1 5135: match ipv6 address prefix-list LIST-1 5136: match as-path LIST-2 5137: on-match goto 10 5138: route-map A-IMPORT-FROM-B deny 2 5139: route-map A-IMPORT-FROM-B permit 10 5140: match ipv6 address prefix-list COMMON-PREFIXES 5141: set local-preference 100 5142: route-map A-IMPORT-FROM-B permit 20 5143: match ipv6 address prefix-list PEER-B-PREFIXES 5144: set community 65001:11111 5145: ! 5146: ... 5147: ... 5148: 5149: The route-map A-IMPORT-FROM-B is equivalent to the three filters 5150: (LIST-1, LIST-2 and PEER-B-IN). The first entry of route-map 5151: A-IMPORT-FROM-B (sequence number 1) matches if and only if both the 5152: prefix-list LIST-1 and the filter-list LIST-2 match. If that happens, 5153: due to the "on-match goto 10" statement the next route-map entry to be 5154: processed will be number 10, and as of that point route-map 5155: A-IMPORT-FROM-B is identical to PEER-B-IN. If the first entry does not 5156: match, `on-match goto 10" will be ignored and the next processed entry 5157: will be number 2, which will deny the route. 5158: 5159: Thus, the result is the same that with the three original filters, 5160: i.e., if either LIST-1 or LIST-2 rejects the route, it does not reach 5161: the route-map PEER-B-IN. In case both LIST-1 and LIST-2 accept the 5162: route, it passes to PEER-B-IN, which can reject, accept or modify the 5163: route. 5164: 5165: 5166: File: quagga.info, Node: VTY shell, Next: Filtering, Prev: Configuring Quagga as a Route Server, Up: Top 5167: 5168: 12 VTY shell 5169: ************ 5170: 5171: `vtysh' is integrated shell of Quagga software. 5172: 5173: To use vtysh please specify --enable-vtysh to configure script. To 5174: use PAM for authentication use --with-libpam option to configure script. 5175: 5176: vtysh only searches /etc/quagga path for vtysh.conf which is the 5177: vtysh configuration file. Vtysh does not search current directory for 5178: configuration file because the file includes user authentication 5179: settings. 5180: 5181: Currently, vtysh.conf has only two commands. 5182: 5183: * Menu: 5184: 5185: * VTY shell username:: 5186: * VTY shell integrated configuration:: 5187: 5188: 5189: File: quagga.info, Node: VTY shell username, Next: VTY shell integrated configuration, Up: VTY shell 5190: 5191: 12.1 VTY shell username 5192: ======================= 5193: 5194: -- Command: username USERNAME nopassword 5195: With this set, user foo does not need password authentication for 5196: user vtysh. With PAM vtysh uses PAM authentication mechanism. 5197: 5198: If vtysh is compiled without PAM authentication, every user can 5199: use vtysh without authentication. vtysh requires read/write 5200: permission to the various daemons vty sockets, this can be 5201: accomplished through use of unix groups and the -enable-vty-group 5202: configure option. 5203: 5204: 5205: 5206: File: quagga.info, Node: VTY shell integrated configuration, Prev: VTY shell username, Up: VTY shell 5207: 5208: 12.2 VTY shell integrated configuration 5209: ======================================= 5210: 5211: -- Command: service integrated-vtysh-config 5212: Write out integrated Quagga.conf file when 'write file' is issued. 5213: 5214: This command controls the behaviour of vtysh when it is told to 5215: write out the configuration. Per default, vtysh will instruct 5216: each daemon to write out their own config files when `write file' 5217: is issued. However, if `service integrated-vtysh-config' is set, 5218: when `write file' is issued, vtysh will instruct the daemons will 5219: write out a Quagga.conf with all daemons' commands integrated into 5220: it. 5221: 5222: Vtysh per default behaves as if `write-conf daemon' is set. Note 5223: that both may be set at same time if one wishes to have both 5224: Quagga.conf and daemon specific files written out. Further, note 5225: that the daemons are hard-coded to first look for the integrated 5226: Quagga.conf file before looking for their own file. 5227: 5228: We recommend you do not mix the use of the two types of files. 5229: Further, it is better not to use the integrated Quagga.conf file, 5230: as any syntax error in it can lead to /all/ of your daemons being 5231: unable to start up. Per daemon files are more robust as impact of 5232: errors in configuration are limited to the daemon in whose file 5233: the error is made. 5234: 5235: 5236: 5237: File: quagga.info, Node: Filtering, Next: Route Map, Prev: VTY shell, Up: Top 5238: 5239: 13 Filtering 5240: ************ 5241: 5242: Quagga provides many very flexible filtering features. Filtering is 5243: used for both input and output of the routing information. Once 5244: filtering is defined, it can be applied in any direction. 5245: 5246: * Menu: 5247: 5248: * IP Access List:: 5249: * IP Prefix List:: 5250: 5251: 5252: File: quagga.info, Node: IP Access List, Next: IP Prefix List, Up: Filtering 5253: 5254: 13.1 IP Access List 5255: =================== 5256: 5257: -- Command: access-list NAME permit IPV4-NETWORK 5258: -- Command: access-list NAME deny IPV4-NETWORK 5259: 5260: Basic filtering is done by `access-list' as shown in the following 5261: example. 5262: 5263: access-list filter deny 10.0.0.0/9 5264: access-list filter permit 10.0.0.0/8 5265: 5266: 5267: File: quagga.info, Node: IP Prefix List, Prev: IP Access List, Up: Filtering 5268: 5269: 13.2 IP Prefix List 5270: =================== 5271: 5272: `ip prefix-list' provides the most powerful prefix based filtering 5273: mechanism. In addition to `access-list' functionality, `ip 5274: prefix-list' has prefix length range specification and sequential 5275: number specification. You can add or delete prefix based filters to 5276: arbitrary points of prefix-list using sequential number specification. 5277: 5278: If no ip prefix-list is specified, it acts as permit. If `ip 5279: prefix-list' is defined, and no match is found, default deny is applied. 5280: 5281: -- Command: ip prefix-list NAME (permit|deny) PREFIX [le LEN] [ge LEN] 5282: -- Command: ip prefix-list NAME seq NUMBER (permit|deny) PREFIX [le 5283: LEN] [ge LEN] 5284: You can create `ip prefix-list' using above commands. 5285: 5286: seq 5287: seq NUMBER can be set either automatically or manually. In 5288: the case that sequential numbers are set manually, the user 5289: may pick any number less than 4294967295. In the case that 5290: sequential number are set automatically, the sequential 5291: number will increase by a unit of five (5) per list. If a 5292: list with no specified sequential number is created after a 5293: list with a specified sequential number, the list will 5294: automatically pick the next multiple of five (5) as the list 5295: number. For example, if a list with number 2 already exists 5296: and a new list with no specified number is created, the next 5297: list will be numbered 5. If lists 2 and 7 already exist and 5298: a new list with no specified number is created, the new list 5299: will be numbered 10. 5300: 5301: le 5302: `le' command specifies prefix length. The prefix list will be 5303: applied if the prefix length is less than or equal to the le 5304: prefix length. 5305: 5306: ge 5307: `ge' command specifies prefix length. The prefix list will be 5308: applied if the prefix length is greater than or equal to the 5309: ge prefix length. 5310: 5311: 5312: 5313: Less than or equal to prefix numbers and greater than or equal to 5314: prefix numbers can be used together. The order of the le and ge 5315: commands does not matter. 5316: 5317: If a prefix list with a different sequential number but with the 5318: exact same rules as a previous list is created, an error will result. 5319: However, in the case that the sequential number and the rules are 5320: exactly similar, no error will result. 5321: 5322: If a list with the same sequential number as a previous list is 5323: created, the new list will overwrite the old list. 5324: 5325: Matching of IP Prefix is performed from the smaller sequential 5326: number to the larger. The matching will stop once any rule has been 5327: applied. 5328: 5329: In the case of no le or ge command, the prefix length must match 5330: exactly the length specified in the prefix list. 5331: 5332: -- Command: no ip prefix-list NAME 5333: 5334: * Menu: 5335: 5336: * ip prefix-list description:: 5337: * ip prefix-list sequential number control:: 5338: * Showing ip prefix-list:: 5339: * Clear counter of ip prefix-list:: 5340: 5341: 5342: File: quagga.info, Node: ip prefix-list description, Next: ip prefix-list sequential number control, Up: IP Prefix List 5343: 5344: 13.2.1 ip prefix-list description 5345: --------------------------------- 5346: 5347: -- Command: ip prefix-list NAME description DESC 5348: Descriptions may be added to prefix lists. This command adds a 5349: description to the prefix list. 5350: 5351: -- Command: no ip prefix-list NAME description [DESC] 5352: Deletes the description from a prefix list. It is possible to use 5353: the command without the full description. 5354: 5355: 5356: File: quagga.info, Node: ip prefix-list sequential number control, Next: Showing ip prefix-list, Prev: ip prefix-list description, Up: IP Prefix List 5357: 5358: 13.2.2 ip prefix-list sequential number control 5359: ----------------------------------------------- 5360: 5361: -- Command: ip prefix-list sequence-number 5362: With this command, the IP prefix list sequential number is 5363: displayed. This is the default behavior. 5364: 5365: -- Command: no ip prefix-list sequence-number 5366: With this command, the IP prefix list sequential number is not 5367: displayed. 5368: 5369: 5370: 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 5371: 5372: 13.2.3 Showing ip prefix-list 5373: ----------------------------- 5374: 5375: -- Command: show ip prefix-list 5376: Display all IP prefix lists. 5377: 5378: -- Command: show ip prefix-list NAME 5379: Show IP prefix list can be used with a prefix list name. 5380: 5381: -- Command: show ip prefix-list NAME seq NUM 5382: Show IP prefix list can be used with a prefix list name and 5383: sequential number. 5384: 5385: -- Command: show ip prefix-list NAME A.B.C.D/M 5386: If the command longer is used, all prefix lists with prefix 5387: lengths equal to or longer than the specified length will be 5388: displayed. If the command first match is used, the first prefix 5389: length match will be displayed. 5390: 5391: -- Command: show ip prefix-list NAME A.B.C.D/M longer 5392: 5393: -- Command: show ip prefix-list NAME A.B.C.D/M first-match 5394: 5395: -- Command: show ip prefix-list summary 5396: 5397: -- Command: show ip prefix-list summary NAME 5398: 5399: -- Command: show ip prefix-list detail 5400: 5401: -- Command: show ip prefix-list detail NAME 5402: 5403: 5404: File: quagga.info, Node: Clear counter of ip prefix-list, Prev: Showing ip prefix-list, Up: IP Prefix List 5405: 5406: 13.2.4 Clear counter of ip prefix-list 5407: -------------------------------------- 5408: 5409: -- Command: clear ip prefix-list 5410: Clears the counters of all IP prefix lists. Clear IP Prefix List 5411: can be used with a specified name and prefix. 5412: 5413: -- Command: clear ip prefix-list NAME 5414: 5415: -- Command: clear ip prefix-list NAME A.B.C.D/M 5416: 5417: 5418: File: quagga.info, Node: Route Map, Next: IPv6 Support, Prev: Filtering, Up: Top 5419: 5420: 14 Route Map 5421: ************ 5422: 5423: Route maps provide a means to both filter and/or apply actions to 5424: route, hence allowing policy to be applied to routes. 5425: 5426: * Menu: 5427: 5428: * Route Map Command:: 5429: * Route Map Match Command:: 5430: * Route Map Set Command:: 5431: * Route Map Call Command:: 5432: * Route Map Exit Action Command:: 5433: * Route Map Examples:: 5434: 5435: Route-maps are an ordered list of route-map entries. Each entry may 5436: specify up to four distincts sets of clauses: 5437: 5438: `Matching Policy' 5439: This specifies the policy implied if the `Matching Conditions' are 5440: met or not met, and which actions of the route-map are to be 5441: taken, if any. The two possibilities are: 5442: 5443: - `permit': If the entry matches, then carry out the `Set 5444: Actions'. Then finish processing the route-map, permitting 5445: the route, unless an `Exit Action' indicates otherwise. 5446: 5447: - `deny': If the entry matches, then finish processing the 5448: route-map and deny the route (return `deny'). 5449: 5450: The `Matching Policy' is specified as part of the command which 5451: defines the ordered entry in the route-map. See below. 5452: 5453: `Matching Conditions' 5454: A route-map entry may, optionally, specify one or more conditions 5455: which must be matched if the entry is to be considered further, as 5456: governed by the Match Policy. If a route-map entry does not 5457: explicitely specify any matching conditions, then it always 5458: matches. 5459: 5460: `Set Actions' 5461: A route-map entry may, optionally, specify one or more `Set 5462: Actions' to set or modify attributes of the route. 5463: 5464: `Call Action' 5465: Call to another route-map, after any `Set Actions' have been 5466: carried out. If the route-map called returns `deny' then 5467: processing of the route-map finishes and the route is denied, 5468: regardless of the `Matching Policy' or the `Exit Policy'. If the 5469: called route-map returns `permit', then `Matching Policy' and 5470: `Exit Policy' govern further behaviour, as normal. 5471: 5472: `Exit Policy' 5473: An entry may, optionally, specify an alternative `Exit Policy' to 5474: take if the entry matched, rather than the normal policy of 5475: exiting the route-map and permitting the route. The two 5476: possibilities are: 5477: 5478: - `next': Continue on with processing of the route-map entries. 5479: 5480: - `goto N': Jump ahead to the first route-map entry whose order 5481: in the route-map is >= N. Jumping to a previous entry is not 5482: permitted. 5483: 5484: The default action of a route-map, if no entries match, is to deny. 5485: I.e. a route-map essentially has as its last entry an empty `deny' 5486: entry, which matches all routes. To change this behaviour, one must 5487: specify an empty `permit' entry as the last entry in the route-map. 5488: 5489: To summarise the above: 5490: 5491: Match No Match 5492: ----------------------------- 5493: _Permit_ action cont 5494: _Deny_ deny cont 5495: 5496: `action' 5497: - Apply _set_ statements 5498: 5499: - If _call_ is present, call given route-map. If that returns a 5500: `deny', finish processing and return `deny'. 5501: 5502: - If `Exit Policy' is _next_, goto next route-map entry 5503: 5504: - If `Exit Policy' is _goto_, goto first entry whose order in 5505: the list is >= the given order. 5506: 5507: - Finish processing the route-map and permit the route. 5508: 5509: `deny' 5510: - The route is denied by the route-map (return `deny'). 5511: 5512: `cont' 5513: - goto next route-map entry 5514: 5515: 5516: File: quagga.info, Node: Route Map Command, Next: Route Map Match Command, Up: Route Map 5517: 5518: 14.1 Route Map Command 5519: ====================== 5520: 5521: -- Command: route-map ROUTE-MAP-NAME (permit|deny) ORDER 5522: Configure the ORDER'th entry in ROUTE-MAP-NAME with `Match Policy' 5523: of either _permit_ or _deny_. 5524: 5525: 5526: 5527: File: quagga.info, Node: Route Map Match Command, Next: Route Map Set Command, Prev: Route Map Command, Up: Route Map 5528: 5529: 14.2 Route Map Match Command 5530: ============================ 5531: 5532: -- Route-map Command: match ip address ACCESS_LIST 5533: Matches the specified ACCESS_LIST 5534: 5535: -- Route-map Command: match ip next-hop IPV4_ADDR 5536: Matches the specified IPV4_ADDR. 5537: 5538: -- Route-map Command: match aspath AS_PATH 5539: Matches the specified AS_PATH. 5540: 5541: -- Route-map Command: match metric METRIC 5542: Matches the specified METRIC. 5543: 5544: -- Route-map Command: match community COMMUNITY_LIST 5545: Matches the specified COMMUNITY_LIST 5546: 5547: 5548: File: quagga.info, Node: Route Map Set Command, Next: Route Map Call Command, Prev: Route Map Match Command, Up: Route Map 5549: 5550: 14.3 Route Map Set Command 5551: ========================== 5552: 5553: -- Route-map Command: set ip next-hop IPV4_ADDRESS 5554: Set the BGP nexthop address. 5555: 5556: -- Route-map Command: set local-preference LOCAL_PREF 5557: Set the BGP local preference. 5558: 5559: -- Route-map Command: set weight WEIGHT 5560: Set the route's weight. 5561: 5562: -- Route-map Command: set metric METRIC 5563: Set the BGP attribute MED. 5564: 5565: -- Route-map Command: set as-path prepend AS_PATH 5566: Set the BGP AS path to prepend. 5567: 5568: -- Route-map Command: set community COMMUNITY 5569: Set the BGP community attribute. 5570: 5571: -- Route-map Command: set ipv6 next-hop global IPV6_ADDRESS 5572: Set the BGP-4+ global IPv6 nexthop address. 5573: 5574: -- Route-map Command: set ipv6 next-hop local IPV6_ADDRESS 5575: Set the BGP-4+ link local IPv6 nexthop address. 5576: 5577: 5578: File: quagga.info, Node: Route Map Call Command, Next: Route Map Exit Action Command, Prev: Route Map Set Command, Up: Route Map 5579: 5580: 14.4 Route Map Call Command 5581: =========================== 5582: 5583: -- Route-map Command: call NAME 5584: Call route-map NAME. If it returns deny, deny the route and finish 5585: processing the route-map. 5586: 5587: 5588: File: quagga.info, Node: Route Map Exit Action Command, Next: Route Map Examples, Prev: Route Map Call Command, Up: Route Map 5589: 5590: 14.5 Route Map Exit Action Command 5591: ================================== 5592: 5593: -- Route-map Command: on-match next 5594: -- Route-map Command: continue 5595: Proceed on to the next entry in the route-map. 5596: 5597: -- Route-map Command: on-match goto N 5598: -- Route-map Command: continue N 5599: Proceed processing the route-map at the first entry whose order is 5600: >= N 5601: 5602: 5603: File: quagga.info, Node: Route Map Examples, Prev: Route Map Exit Action Command, Up: Route Map 5604: 5605: 14.6 Route Map Examples 5606: ======================= 5607: 5608: A simple example of a route-map: 5609: 5610: route-map test permit 10 5611: match ip address 10 5612: set local-preference 200 5613: 5614: This means that if a route matches ip access-list number 10 it's 5615: local-preference value is set to 200. 5616: 5617: See *note BGP Configuration Examples:: for examples of more 5618: sophisticated useage of route-maps, including of the `call' action. 5619: 5620: 5621: File: quagga.info, Node: IPv6 Support, Next: Kernel Interface, Prev: Route Map, Up: Top 5622: 5623: 15 IPv6 Support 5624: *************** 5625: 5626: Quagga fully supports IPv6 routing. As described so far, Quagga 5627: supports RIPng, OSPFv3, Babel and BGP-4+. You can give IPv6 addresses 5628: to an interface and configure static IPv6 routing information. Quagga 5629: IPv6 also provides automatic address configuration via a feature called 5630: `address auto configuration'. To do it, the router must send router 5631: advertisement messages to the all nodes that exist on the network. 5632: 5633: * Menu: 5634: 5635: * Router Advertisement:: 5636: 5637: 5638: File: quagga.info, Node: Router Advertisement, Up: IPv6 Support 5639: 5640: 15.1 Router Advertisement 5641: ========================= 5642: 5643: -- Interface Command: no ipv6 nd suppress-ra 5644: Send router advertisment messages. 5645: 5646: -- Interface Command: ipv6 nd suppress-ra 5647: Don't send router advertisment messages. 5648: 5649: -- Interface Command: ipv6 nd prefix IPV6PREFIX [VALID-LIFETIME] 5650: [PREFERRED-LIFETIME] [off-link] [no-autoconfig] [router-address] 5651: Configuring the IPv6 prefix to include in router advertisements. 5652: Several prefix specific optional parameters and flags may follow: 5653: * VALID-LIFETIME - the length of time in seconds during what 5654: the prefix is valid for the purpose of on-link determination. 5655: Value INFINITE represents infinity (i.e. a value of all one 5656: bits (`0xffffffff')). 5657: 5658: Range: `<0-4294967295>' Default: `2592000' 5659: 5660: * PREFERRED-LIFETIME - the length of time in seconds during 5661: what addresses generated from the prefix remain preferred. 5662: Value INFINITE represents infinity. 5663: 5664: Range: `<0-4294967295>' Default: `604800' 5665: 5666: * OFF-LINK - indicates that advertisement makes no statement 5667: about on-link or off-link properties of the prefix. 5668: 5669: Default: not set, i.e. this prefix can be used for on-link 5670: determination. 5671: 5672: * NO-AUTOCONFIG - indicates to hosts on the local link that the 5673: specified prefix cannot be used for IPv6 autoconfiguration. 5674: 5675: Default: not set, i.e. prefix can be used for 5676: autoconfiguration. 5677: 5678: * ROUTER-ADDRESS - indicates to hosts on the local link that 5679: the specified prefix contains a complete IP address by 5680: setting R flag. 5681: 5682: Default: not set, i.e. hosts do not assume a complete IP 5683: address is placed. 5684: 5685: -- Interface Command: ipv6 nd ra-interval <1-1800> 5686: -- Interface Command: no ipv6 nd ra-interval [<1-1800>] 5687: The maximum time allowed between sending unsolicited multicast 5688: router advertisements from the interface, in seconds. 5689: 5690: Default: `600' 5691: 5692: -- Interface Command: ipv6 nd ra-interval msec <70-1800000> 5693: -- Interface Command: no ipv6 nd ra-interval [msec <70-1800000>] 5694: The maximum time allowed between sending unsolicited multicast 5695: router advertisements from the interface, in milliseconds. 5696: 5697: Default: `600000' 5698: 5699: -- Interface Command: ipv6 nd ra-lifetime <0-9000> 5700: -- Interface Command: no ipv6 nd ra-lifetime [<0-9000>] 5701: The value to be placed in the Router Lifetime field of router 5702: advertisements sent from the interface, in seconds. Indicates the 5703: usefulness of the router as a default router on this interface. 5704: Setting the value to zero indicates that the router should not be 5705: considered a default router on this interface. Must be either 5706: zero or between value specified with IPV6 ND RA-INTERVAL (or 5707: default) and 9000 seconds. 5708: 5709: Default: `1800' 5710: 5711: -- Interface Command: ipv6 nd reachable-time <1-3600000> 5712: -- Interface Command: no ipv6 nd reachable-time [<1-3600000>] 5713: The value to be placed in the Reachable Time field in the Router 5714: Advertisement messages sent by the router, in milliseconds. The 5715: configured time enables the router to detect unavailable 5716: neighbors. The value zero means unspecified (by this router). 5717: 5718: Default: `0' 5719: 5720: -- Interface Command: ipv6 nd managed-config-flag 5721: -- Interface Command: no ipv6 nd managed-config-flag 5722: Set/unset flag in IPv6 router advertisements which indicates to 5723: hosts that they should use managed (stateful) protocol for 5724: addresses autoconfiguration in addition to any addresses 5725: autoconfigured using stateless address autoconfiguration. 5726: 5727: Default: not set 5728: 5729: -- Interface Command: ipv6 nd other-config-flag 5730: -- Interface Command: no ipv6 nd other-config-flag 5731: Set/unset flag in IPv6 router advertisements which indicates to 5732: hosts that they should use administered (stateful) protocol to 5733: obtain autoconfiguration information other than addresses. 5734: 5735: Default: not set 5736: 5737: -- Interface Command: ipv6 nd home-agent-config-flag 5738: -- Interface Command: no ipv6 nd home-agent-config-flag 5739: Set/unset flag in IPv6 router advertisements which indicates to 5740: hosts that the router acts as a Home Agent and includes a Home 5741: Agent Option. 5742: 5743: Default: not set 5744: 5745: -- Interface Command: ipv6 nd home-agent-preference <0-65535> 5746: -- Interface Command: no ipv6 nd home-agent-preference [<0-65535>] 5747: The value to be placed in Home Agent Option, when Home Agent 5748: config flag is set, which indicates to hosts Home Agent 5749: preference. The default value of 0 stands for the lowest 5750: preference possible. 5751: 5752: Default: 0 5753: 5754: + 5755: 5756: -- Interface Command: ipv6 nd home-agent-lifetime <0-65520> 5757: + 5758: 5759: -- Interface Command: no ipv6 nd home-agent-lifetime [<0-65520>] 5760: The value to be placed in Home Agent Option, when Home Agent 5761: config flag is set, which indicates to hosts Home Agent Lifetime. 5762: The default value of 0 means to place the current Router Lifetime 5763: value. 5764: 5765: Default: 0 5766: 5767: -- Interface Command: ipv6 nd adv-interval-option 5768: -- Interface Command: no ipv6 nd adv-interval-option 5769: Include an Advertisement Interval option which indicates to hosts 5770: the maximum time, in milliseconds, between successive unsolicited 5771: Router Advertisements. 5772: 5773: Default: not set 5774: 5775: -- Interface Command: ipv6 nd router-preference (high|medium|low) 5776: -- Interface Command: no ipv6 nd router-preference [(high|medium|low)] 5777: Set default router preference in IPv6 router advertisements per 5778: RFC4191. 5779: 5780: Default: medium 5781: 5782: -- Interface Command: ipv6 nd mtu <1-65535> 5783: -- Interface Command: no ipv6 nd mtu [<1-65535>] 5784: Include an MTU (type 5) option in each RA packet to assist the 5785: attached hosts in proper interface configuration. The announced 5786: value is not verified to be consistent with router interface MTU. 5787: 5788: Default: don't advertise any MTU option 5789: 5790: interface eth0 5791: no ipv6 nd suppress-ra 5792: ipv6 nd prefix 2001:0DB8:5009::/64 5793: 5794: For more information see `RFC2462 (IPv6 Stateless Address 5795: Autoconfiguration)' , `RFC4861 (Neighbor Discovery for IP Version 6 5796: (IPv6))' , `RFC6275 (Mobility Support in IPv6)' and `RFC4191 (Default 5797: Router Preferences and More-Specific Routes)'. 5798: 5799: 5800: File: quagga.info, Node: Kernel Interface, Next: SNMP Support, Prev: IPv6 Support, Up: Top 5801: 5802: 16 Kernel Interface 5803: ******************* 5804: 5805: There are several different methods for reading kernel routing table 5806: information, updating kernel routing tables, and for looking up 5807: interfaces. 5808: 5809: `ioctl' 5810: The `ioctl' method is a very traditional way for reading or writing 5811: kernel information. `ioctl' can be used for looking up interfaces 5812: and for modifying interface addresses, flags, mtu settings and 5813: other types of information. Also, `ioctl' can insert and delete 5814: kernel routing table entries. It will soon be available on almost 5815: any platform which zebra supports, but it is a little bit ugly 5816: thus far, so if a better method is supported by the kernel, zebra 5817: will use that. 5818: 5819: `sysctl' 5820: `sysctl' can lookup kernel information using MIB (Management 5821: Information Base) syntax. Normally, it only provides a way of 5822: getting information from the kernel. So one would usually want to 5823: change kernel information using another method such as `ioctl'. 5824: 5825: `proc filesystem' 5826: `proc filesystem' provides an easy way of getting kernel 5827: information. 5828: 5829: `routing socket' 5830: 5831: `netlink' 5832: On recent Linux kernels (2.0.x and 2.2.x), there is a kernel/user 5833: communication support called `netlink'. It makes asynchronous 5834: communication between kernel and Quagga possible, similar to a 5835: routing socket on BSD systems. 5836: 5837: Before you use this feature, be sure to select (in kernel 5838: configuration) the kernel/netlink support option 'Kernel/User 5839: network link driver' and 'Routing messages'. 5840: 5841: Today, the /dev/route special device file is obsolete. Netlink 5842: communication is done by reading/writing over netlink socket. 5843: 5844: After the kernel configuration, please reconfigure and rebuild 5845: Quagga. You can use netlink as a dynamic routing update channel 5846: between Quagga and the kernel. 5847: 5848: 5849: File: quagga.info, Node: SNMP Support, Next: Zebra Protocol, Prev: Kernel Interface, Up: Top 5850: 5851: 17 SNMP Support 5852: *************** 5853: 5854: SNMP (Simple Network Managing Protocol) is a widely implemented feature 5855: for collecting network information from router and/or host. Quagga 5856: itself does not support SNMP agent (server daemon) functionality but is 5857: able to connect to a SNMP agent using the SMUX protocol (`RFC1227') and 5858: make the routing protocol MIBs available through it. 5859: 5860: * Menu: 5861: 5862: * Getting and installing an SNMP agent:: 5863: * SMUX configuration:: 5864: * MIB and command reference:: 5865: * Handling SNMP Traps:: 5866: 5867: 5868: File: quagga.info, Node: Getting and installing an SNMP agent, Next: SMUX configuration, Up: SNMP Support 5869: 5870: 17.1 Getting and installing an SNMP agent 5871: ========================================= 5872: 5873: There are several SNMP agent which support SMUX. We recommend to use 5874: the latest version of `net-snmp' which was formerly known as `ucd-snmp'. 5875: It is free and open software and available at `http://www.net-snmp.org/' 5876: and as binary package for most Linux distributions. `net-snmp' has to 5877: be compiled with `--with-mib-modules=smux' to be able to accept 5878: connections from Quagga. 5879: 5880: 5881: File: quagga.info, Node: SMUX configuration, Next: MIB and command reference, Prev: Getting and installing an SNMP agent, Up: SNMP Support 5882: 5883: 17.2 SMUX configuration 5884: ======================= 5885: 5886: To enable SMUX protocol support, Quagga must have been build with the 5887: `--enable-snmp' option. 5888: 5889: A separate connection has then to be established between between the 5890: SNMP agent (snmpd) and each of the Quagga daemons. This connections 5891: each use different OID numbers and passwords. Be aware that this OID 5892: number is not the one that is used in queries by clients, it is solely 5893: used for the intercommunication of the daemons. 5894: 5895: In the following example the ospfd daemon will be connected to the 5896: snmpd daemon using the password "quagga_ospfd". For testing it is 5897: recommending to take exactly the below snmpd.conf as wrong access 5898: restrictions can be hard to debug. 5899: 5900: /etc/snmp/snmpd.conf: 5901: # 5902: # example access restrictions setup 5903: # 5904: com2sec readonly default public 5905: group MyROGroup v1 readonly 5906: view all included .1 80 5907: access MyROGroup "" any noauth exact all none none 5908: # 5909: # the following line is relevant for Quagga 5910: # 5911: smuxpeer .1.3.6.1.4.1.3317.1.2.5 quagga_ospfd 5912: 5913: /etc/quagga/ospf: 5914: ! ... the rest of ospfd.conf has been omitted for clarity ... 5915: ! 5916: smux peer .1.3.6.1.4.1.3317.1.2.5 quagga_ospfd 5917: ! 5918: 5919: After restarting snmpd and quagga, a successful connection can be 5920: verified in the syslog and by querying the SNMP daemon: 5921: 5922: snmpd[12300]: [smux_accept] accepted fd 12 from 127.0.0.1:36255 5923: snmpd[12300]: accepted smux peer: \ 5924: oid GNOME-PRODUCT-ZEBRA-MIB::ospfd, quagga-0.96.5 5925: 5926: # snmpwalk -c public -v1 localhost .1.3.6.1.2.1.14.1.1 5927: OSPF-MIB::ospfRouterId.0 = IpAddress: 192.168.42.109 5928: 5929: Be warned that the current version (5.1.1) of the Net-SNMP daemon 5930: writes a line for every SNMP connect to the syslog which can lead to 5931: enormous log file sizes. If that is a problem you should consider to 5932: patch snmpd and comment out the troublesome `snmp_log()' line in the 5933: function `netsnmp_agent_check_packet()' in `agent/snmp_agent.c'. 5934: 5935: 5936: File: quagga.info, Node: MIB and command reference, Next: Handling SNMP Traps, Prev: SMUX configuration, Up: SNMP Support 5937: 5938: 17.3 MIB and command reference 5939: ============================== 5940: 5941: The following OID numbers are used for the interprocess communication 5942: of snmpd and the Quagga daemons. Sadly, SNMP has not been implemented 5943: in all daemons yet. 5944: (OIDs below .iso.org.dod.internet.private.enterprises) 5945: zebra .1.3.6.1.4.1.3317.1.2.1 .gnome.gnomeProducts.zebra.zserv 5946: bgpd .1.3.6.1.4.1.3317.1.2.2 .gnome.gnomeProducts.zebra.bgpd 5947: ripd .1.3.6.1.4.1.3317.1.2.3 .gnome.gnomeProducts.zebra.ripd 5948: ospfd .1.3.6.1.4.1.3317.1.2.5 .gnome.gnomeProducts.zebra.ospfd 5949: ospf6d .1.3.6.1.4.1.3317.1.2.6 .gnome.gnomeProducts.zebra.ospf6d 5950: 5951: The following OID numbers are used for querying the SNMP daemon by a 5952: client: 5953: zebra .1.3.6.1.2.1.4.24 .iso.org.dot.internet.mgmt.mib-2.ip.ipForward 5954: ospfd .1.3.6.1.2.1.14 .iso.org.dot.internet.mgmt.mib-2.ospf 5955: bgpd .1.3.6.1.2.1.15 .iso.org.dot.internet.mgmt.mib-2.bgp 5956: ripd .1.3.6.1.2.1.23 .iso.org.dot.internet.mgmt.mib-2.rip2 5957: ospf6d .1.3.6.1.3.102 .iso.org.dod.internet.experimental.ospfv3 5958: 5959: The following syntax is understood by the Quagga daemons for 5960: configuring SNMP: 5961: 5962: -- Command: smux peer OID 5963: -- Command: no smux peer OID 5964: 5965: -- Command: smux peer OID PASSWORD 5966: -- Command: no smux peer OID PASSWORD 5967: 5968: 5969: File: quagga.info, Node: Handling SNMP Traps, Prev: MIB and command reference, Up: SNMP Support 5970: 5971: 17.4 Handling SNMP Traps 5972: ======================== 5973: 5974: To handle snmp traps make sure your snmp setup of quagga works 5975: correctly as described in the quagga documentation in *Note SNMP 5976: Support::. 5977: 5978: The BGP4 mib will send traps on peer up/down events. These should be 5979: visible in your snmp logs with a message similar to: 5980: 5981: `snmpd[13733]: Got trap from peer on fd 14' 5982: 5983: To react on these traps they should be handled by a trapsink. 5984: Configure your trapsink by adding the following lines to 5985: `/etc/snmpd/snmpd.conf': 5986: 5987: # send traps to the snmptrapd on localhost 5988: trapsink localhost 5989: 5990: This will send all traps to an snmptrapd running on localhost. You 5991: can of course also use a dedicated management station to catch traps. 5992: Configure the snmptrapd daemon by adding the following line to 5993: `/etc/snmpd/snmptrapd.conf': 5994: 5995: traphandle .1.3.6.1.4.1.3317.1.2.2 /etc/snmp/snmptrap_handle.sh 5996: 5997: This will use the bash script `/etc/snmp/snmptrap_handle.sh' to 5998: handle the BGP4 traps. To add traps for other protocol daemons, lookup 5999: their appropriate OID from their mib. (For additional information about 6000: which traps are supported by your mib, lookup the mib on 6001: `http://www.oidview.com/mibs/detail.html'). 6002: 6003: Make sure snmptrapd is started. 6004: 6005: The snmptrap_handle.sh script I personally use for handling BGP4 6006: traps is below. You can of course do all sorts of things when handling 6007: traps, like sound a siren, have your display flash, etc., be creative 6008: ;). 6009: 6010: #!/bin/bash 6011: 6012: # routers name 6013: ROUTER=`hostname -s` 6014: 6015: #email address use to sent out notification 6016: EMAILADDR="john@doe.com" 6017: #email address used (allongside above) where warnings should be sent 6018: EMAILADDR_WARN="sms-john@doe.com" 6019: 6020: # type of notification 6021: TYPE="Notice" 6022: 6023: # local snmp community for getting AS belonging to peer 6024: COMMUNITY="<community>" 6025: 6026: # if a peer address is in $WARN_PEERS a warning should be sent 6027: WARN_PEERS="192.0.2.1" 6028: 6029: 6030: # get stdin 6031: INPUT=`cat -` 6032: 6033: # get some vars from stdin 6034: uptime=`echo $INPUT | cut -d' ' -f5` 6035: peer=`echo $INPUT | cut -d' ' -f8 | sed -e 's/SNMPv2-SMI::mib-2.15.3.1.14.//g'` 6036: peerstate=`echo $INPUT | cut -d' ' -f13` 6037: errorcode=`echo $INPUT | cut -d' ' -f9 | sed -e 's/\"//g'` 6038: suberrorcode=`echo $INPUT | cut -d' ' -f10 | sed -e 's/\"//g'` 6039: remoteas=`snmpget -v2c -c $COMMUNITY localhost SNMPv2-SMI::mib-2.15.3.1.9.$peer | cut -d' ' -f4` 6040: 6041: WHOISINFO=`whois -h whois.ripe.net " -r AS$remoteas" | egrep '(as-name|descr)'` 6042: asname=`echo "$WHOISINFO" | grep "^as-name:" | sed -e 's/^as-name://g' -e 's/ //g' -e 's/^ //g' | uniq` 6043: asdescr=`echo "$WHOISINFO" | grep "^descr:" | sed -e 's/^descr://g' -e 's/ //g' -e 's/^ //g' | uniq` 6044: 6045: # if peer address is in $WARN_PEER, the email should also 6046: # be sent to $EMAILADDR_WARN 6047: for ip in $WARN_PEERS; do 6048: if [ "x$ip" == "x$peer" ]; then 6049: EMAILADDR="$EMAILADDR,$EMAILADDR_WARN" 6050: TYPE="WARNING" 6051: break 6052: fi 6053: done 6054: 6055: 6056: # convert peer state 6057: case "$peerstate" in 6058: 1) peerstate="Idle" ;; 6059: 2) peerstate="Connect" ;; 6060: 3) peerstate="Active" ;; 6061: 4) peerstate="Opensent" ;; 6062: 5) peerstate="Openconfirm" ;; 6063: 6) peerstate="Established" ;; 6064: *) peerstate="Unknown" ;; 6065: esac 6066: 6067: # get textual messages for errors 6068: case "$errorcode" in 6069: 00) 6070: error="No error" 6071: suberror="" 6072: ;; 6073: 01) 6074: error="Message Header Error" 6075: case "$suberrorcode" in 6076: 01) suberror="Connection Not Synchronized" ;; 6077: 02) suberror="Bad Message Length" ;; 6078: 03) suberror="Bad Message Type" ;; 6079: *) suberror="Unknown" ;; 6080: esac 6081: ;; 6082: 02) 6083: error="OPEN Message Error" 6084: case "$suberrorcode" in 6085: 01) suberror="Unsupported Version Number" ;; 6086: 02) suberror="Bad Peer AS" ;; 6087: 03) suberror="Bad BGP Identifier" ;; 6088: 04) suberror="Unsupported Optional Parameter" ;; 6089: 05) suberror="Authentication Failure" ;; 6090: 06) suberror="Unacceptable Hold Time" ;; 6091: *) suberror="Unknown" ;; 6092: esac 6093: ;; 6094: 03) 6095: error="UPDATE Message Error" 6096: case "$suberrorcode" in 6097: 01) suberror="Malformed Attribute List" ;; 6098: 02) suberror="Unrecognized Well-known Attribute" ;; 6099: 03) suberror="Missing Well-known Attribute" ;; 6100: 04) suberror="Attribute Flags Error" ;; 6101: 05) suberror="Attribute Length Error" ;; 6102: 06) suberror="Invalid ORIGIN Attribute" ;; 6103: 07) suberror="AS Routing Loop" ;; 6104: 08) suberror="Invalid NEXT_HOP Attribute" ;; 6105: 09) suberror="Optional Attribute Error" ;; 6106: 10) suberror="Invalid Network Field" ;; 6107: 11) suberror="Malformed AS_PATH" ;; 6108: *) suberror="Unknown" ;; 6109: esac 6110: ;; 6111: 04) 6112: error="Hold Timer Expired" 6113: suberror="" 6114: ;; 6115: 05) 6116: error="Finite State Machine Error" 6117: suberror="" 6118: ;; 6119: 06) 6120: error="Cease" 6121: case "$suberrorcode" in 6122: 01) suberror="Maximum Number of Prefixes Reached" ;; 6123: 02) suberror="Administratively Shutdown" ;; 6124: 03) suberror="Peer Unconfigured" ;; 6125: 04) suberror="Administratively Reset" ;; 6126: 05) suberror="Connection Rejected" ;; 6127: 06) suberror="Other Configuration Change" ;; 6128: 07) suberror="Connection collision resolution" ;; 6129: 08) suberror="Out of Resource" ;; 6130: 09) suberror="MAX" ;; 6131: *) suberror="Unknown" ;; 6132: esac 6133: ;; 6134: *) 6135: error="Unknown" 6136: suberror="" 6137: ;; 6138: esac 6139: 6140: # create textual message from errorcodes 6141: if [ "x$suberror" == "x" ]; then 6142: NOTIFY="$errorcode ($error)" 6143: else 6144: NOTIFY="$errorcode/$suberrorcode ($error/$suberror)" 6145: fi 6146: 6147: 6148: # form a decent subject 6149: SUBJECT="$TYPE: $ROUTER [bgp] $peer is $peerstate: $NOTIFY" 6150: # create the email body 6151: MAIL=`cat << EOF 6152: BGP notification on router $ROUTER. 6153: 6154: Peer: $peer 6155: AS: $remoteas 6156: New state: $peerstate 6157: Notification: $NOTIFY 6158: 6159: Info: 6160: $asname 6161: $asdescr 6162: 6163: Snmpd uptime: $uptime 6164: EOF` 6165: 6166: # mail the notification 6167: echo "$MAIL" | mail -s "$SUBJECT" $EMAILADDR 6168: 6169: 6170: File: quagga.info, Node: Zebra Protocol, Next: Packet Binary Dump Format, Prev: SNMP Support, Up: Top 6171: 6172: Appendix A Zebra Protocol 6173: ************************* 6174: 6175: A.1 Overview of the Zebra Protocol 6176: ================================== 6177: 6178: Zebra Protocol is used by protocol daemons to communicate with the 6179: zebra daemon. 6180: 6181: Each protocol daemon may request and send information to and from the 6182: zebra daemon such as interface states, routing state, 6183: nexthop-validation, and so on. Protocol daemons may also install routes 6184: with zebra. The zebra daemon manages which route is installed into the 6185: forwarding table with the kernel. 6186: 6187: Zebra Protocol is a streaming protocol, with a common header. Two 6188: versions of the header are in use. Version 0 is implicitely versioned. 6189: Version 1 has an explicit version field. Version 0 can be distinguished 6190: from all other versions by examining the 3rd byte of the header, which 6191: contains a marker value for all versions bar version 0. The marker byte 6192: corresponds to the command field in version 0, and the marker value is 6193: a reserved command in version 0. 6194: 6195: We do not anticipate there will be further versions of the header for 6196: the foreseeable future, as the command field in version 1 is wide 6197: enough to allow for future extensions to done compatibly through 6198: seperate commands. 6199: 6200: Version 0 is used by all versions of GNU Zebra as of this writing, 6201: and versions of Quagga up to and including Quagga 0.98. Version 1 will 6202: be used as of Quagga 1.0. 6203: 6204: A.2 Zebra Protocol Definition 6205: ============================= 6206: 6207: A.2.1 Zebra Protocol Header (version 0) 6208: --------------------------------------- 6209: 6210: 0 1 2 3 6211: 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 6212: +-------------------------------+---------------+ 6213: | Length (2) | Command (1) | 6214: +-------------------------------+---------------+ 6215: 6216: A.2.2 Zebra Protocol Common Header (version 1) 6217: ---------------------------------------------- 6218: 6219: 0 1 2 3 6220: 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 6221: +-------------------------------+---------------+-------------+ 6222: | Length (2) | Marker (1) | Version (1) | 6223: +-------------------------------+---------------+-------------+ 6224: | Command (2) | 6225: +-------------------------------+ 6226: 6227: A.2.3 Zebra Protocol Header Field Definitions 6228: --------------------------------------------- 6229: 6230: `Length' 6231: Total packet length including this header. The minimum length is 3 6232: bytes for version 0 messages and 6 bytes for version 1 messages. 6233: 6234: `Marker' 6235: Static marker with a value of 255 always. This is to allow version 6236: 0 Zserv headers (which do not include version explicitely) to be 6237: distinguished from versioned headers. Not present in version 0 6238: messages. 6239: 6240: `Version' 6241: Version number of the Zserv message. Clients should not continue 6242: processing messages past the version field for versions they do not 6243: recognise. Not present in version 0 messages. 6244: 6245: `Command' 6246: The Zebra Protocol command. 6247: 6248: A.2.4 Zebra Protocol Commands 6249: ----------------------------- 6250: 6251: Command Value 6252: ----------------------------------------------------- 6253: ZEBRA_INTERFACE_ADD 1 6254: ZEBRA_INTERFACE_DELETE 2 6255: ZEBRA_INTERFACE_ADDRESS_ADD 3 6256: ZEBRA_INTERFACE_ADDRESS_DELETE 4 6257: ZEBRA_INTERFACE_UP 5 6258: ZEBRA_INTERFACE_DOWN 6 6259: ZEBRA_IPV4_ROUTE_ADD 7 6260: ZEBRA_IPV4_ROUTE_DELETE 8 6261: ZEBRA_IPV6_ROUTE_ADD 9 6262: ZEBRA_IPV6_ROUTE_DELETE 10 6263: ZEBRA_REDISTRIBUTE_ADD 11 6264: ZEBRA_REDISTRIBUTE_DELETE 12 6265: ZEBRA_REDISTRIBUTE_DEFAULT_ADD 13 6266: ZEBRA_REDISTRIBUTE_DEFAULT_DELETE 14 6267: ZEBRA_IPV4_NEXTHOP_LOOKUP 15 6268: ZEBRA_IPV6_NEXTHOP_LOOKUP 16 6269: 6270: 6271: File: quagga.info, Node: Packet Binary Dump Format, Next: Command Index, Prev: Zebra Protocol, Up: Top 6272: 6273: Appendix B Packet Binary Dump Format 6274: ************************************ 6275: 6276: Quagga can dump routing protocol packet into file with a binary format 6277: (*note Dump BGP packets and table::). 6278: 6279: It seems to be better that we share the MRT's header format for 6280: backward compatibility with MRT's dump logs. We should also define the 6281: binary format excluding the header, because we must support both IP v4 6282: and v6 addresses as socket addresses and / or routing entries. 6283: 6284: In the last meeting, we discussed to have a version field in the 6285: header. But Masaki told us that we can define new `type' value rather 6286: than having a `version' field, and it seems to be better because we 6287: don't need to change header format. 6288: 6289: Here is the common header format. This is same as that of MRT. 6290: 6291: 0 1 2 3 6292: 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 6293: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6294: | Time | 6295: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6296: | Type | Subtype | 6297: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6298: | Length | 6299: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6300: 6301: If `type' is PROTOCOL_BGP4MP, `subtype' is BGP4MP_STATE_CHANGE, and 6302: Address Family == IP (version 4) 6303: 6304: 0 1 2 3 6305: 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 6306: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6307: | Source AS number | Destination AS number | 6308: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6309: | Interface Index | Address Family | 6310: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6311: | Source IP address | 6312: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6313: | Destination IP address | 6314: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6315: | Old State | New State | 6316: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6317: 6318: Where State is the value defined in RFC1771. 6319: 6320: If `type' is PROTOCOL_BGP4MP, `subtype' is BGP4MP_STATE_CHANGE, and 6321: Address Family == IP version 6 6322: 6323: 0 1 2 3 6324: 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 6325: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6326: | Source AS number | Destination AS number | 6327: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6328: | Interface Index | Address Family | 6329: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6330: | Source IP address | 6331: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6332: | Source IP address (Cont'd) | 6333: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6334: | Source IP address (Cont'd) | 6335: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6336: | Source IP address (Cont'd) | 6337: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6338: | Destination IP address | 6339: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6340: | Destination IP address (Cont'd) | 6341: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6342: | Destination IP address (Cont'd) | 6343: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6344: | Destination IP address (Cont'd) | 6345: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6346: | Old State | New State | 6347: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6348: 6349: If `type' is PROTOCOL_BGP4MP, `subtype' is BGP4MP_MESSAGE, and 6350: Address Family == IP (version 4) 6351: 6352: 0 1 2 3 6353: 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 6354: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6355: | Source AS number | Destination AS number | 6356: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6357: | Interface Index | Address Family | 6358: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6359: | Source IP address | 6360: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6361: | Destination IP address | 6362: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6363: | BGP Message Packet | 6364: | | 6365: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6366: 6367: Where BGP Message Packet is the whole contents of the BGP4 message 6368: including header portion. 6369: 6370: If `type' is PROTOCOL_BGP4MP, `subtype' is BGP4MP_MESSAGE, and 6371: Address Family == IP version 6 6372: 6373: 0 1 2 3 6374: 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 6375: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6376: | Source AS number | Destination AS number | 6377: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6378: | Interface Index | Address Family | 6379: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6380: | Source IP address | 6381: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6382: | Source IP address (Cont'd) | 6383: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6384: | Source IP address (Cont'd) | 6385: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6386: | Source IP address (Cont'd) | 6387: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6388: | Destination IP address | 6389: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6390: | Destination IP address (Cont'd) | 6391: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6392: | Destination IP address (Cont'd) | 6393: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6394: | Destination IP address (Cont'd) | 6395: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6396: | BGP Message Packet | 6397: | | 6398: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6399: 6400: If `type' is PROTOCOL_BGP4MP, `subtype' is BGP4MP_ENTRY, and Address 6401: Family == IP (version 4) 6402: 6403: 0 1 2 3 6404: 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 6405: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6406: | View # | Status | 6407: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6408: | Time Last Change | 6409: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6410: | Address Family | SAFI | Next-Hop-Len | 6411: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6412: | Next Hop Address | 6413: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6414: | Prefix Length | Address Prefix [variable] | 6415: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6416: | Attribute Length | 6417: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6418: | BGP Attribute [variable length] | 6419: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6420: 6421: If `type' is PROTOCOL_BGP4MP, `subtype' is BGP4MP_ENTRY, and Address 6422: Family == IP version 6 6423: 6424: 0 1 2 3 6425: 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 6426: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6427: | View # | Status | 6428: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6429: | Time Last Change | 6430: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6431: | Address Family | SAFI | Next-Hop-Len | 6432: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6433: | Next Hop Address | 6434: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6435: | Next Hop Address (Cont'd) | 6436: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6437: | Next Hop Address (Cont'd) | 6438: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6439: | Next Hop Address (Cont'd) | 6440: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6441: | Prefix Length | Address Prefix [variable] | 6442: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6443: | Address Prefix (cont'd) [variable] | 6444: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6445: | Attribute Length | 6446: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6447: | BGP Attribute [variable length] | 6448: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6449: 6450: BGP4 Attribute must not contain MP_UNREACH_NLRI. If BGP 6451: Attribute has MP_REACH_NLRI field, it must has zero length NLRI, e.g., 6452: MP_REACH_NLRI has only Address Family, SAFI and next-hop values. 6453: 6454: If `type' is PROTOCOL_BGP4MP and `subtype' is BGP4MP_SNAPSHOT, 6455: 6456: 0 1 2 3 6457: 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 6458: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6459: | View # | File Name [variable] | 6460: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6461: 6462: The file specified in "File Name" contains all routing entries, 6463: which are in the format of "subtype == BGP4MP_ENTRY". 6464: 6465: Constants: 6466: /* type value */ 6467: #define MSG_PROTOCOL_BGP4MP 16 6468: /* subtype value */ 6469: #define BGP4MP_STATE_CHANGE 0 6470: #define BGP4MP_MESSAGE 1 6471: #define BGP4MP_ENTRY 2 6472: #define BGP4MP_SNAPSHOT 3 6473: