Annotation of embedaddon/quagga/doc/quagga.info-1, revision 1.1.1.3
1.1 misho 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:
1.1.1.3 ! misho 27: This is Edition 0.99.21, last updated 4 April 2012 of `The Quagga
! 28: Manual', for Quagga Version 0.99.21.
1.1 misho 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
1.1.1.3 ! misho 53: TCP/IP based routing protocols. This is the Manual for Quagga 0.99.21.
! 54: Quagga is a fork of GNU Zebra.
1.1 misho 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::
1.1.1.3 ! misho 82: * Babel::
1.1 misho 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:
1.1.1.3 ! misho 1028: Hello, this is Quagga (version 0.99.21)
1.1 misho 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:
1.1.1.3 ! misho 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.
1.1 misho 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:
1.1.1.3 ! misho 2801: File: quagga.info, Node: OSPFv3, Next: Babel, Prev: OSPFv2, Up: Top
1.1 misho 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:
1.1.1.3 ! misho 2920: File: quagga.info, Node: Babel, Next: BGP, Prev: OSPFv3, Up: Top
1.1 misho 2921:
1.1.1.3 ! misho 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: ******
1.1 misho 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:
1.1.1.3 ! misho 3077: 10.1 Starting BGP
! 3078: =================
1.1 misho 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:
1.1.1.3 ! misho 3098: 10.2 BGP router
! 3099: ===============
1.1 misho 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:
1.1.1.3 ! misho 3133: 10.2.1 BGP distance
! 3134: -------------------
1.1 misho 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:
1.1.1.3 ! misho 3148: 10.2.2 BGP decision process
! 3149: ---------------------------
1.1 misho 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:
1.1.1.3 ! misho 3171: 10.2.3 BGP route flap dampening
! 3172: -------------------------------
1.1 misho 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:
1.1.1.3 ! misho 3196: 10.3 BGP network
! 3197: ================
1.1 misho 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:
1.1.1.3 ! misho 3208: 10.3.1 BGP route
! 3209: ----------------
1.1 misho 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:
1.1.1.3 ! misho 3225: 10.3.2 Route Aggregation
! 3226: ------------------------
1.1 misho 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:
1.1.1.3 ! misho 3244: 10.3.3 Redistribute to BGP
! 3245: --------------------------
1.1 misho 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:
1.1.1.3 ! misho 3265: 10.4 BGP Peer
! 3266: =============
1.1 misho 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:
1.1.1.3 ! misho 3277: 10.4.1 Defining Peer
! 3278: --------------------
1.1 misho 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:
1.1.1.3 ! misho 3296: 10.4.2 BGP Peer commands
! 3297: ------------------------
1.1 misho 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:
1.1.1.3 ! misho 3374: 10.4.3 Peer filtering
! 3375: ---------------------
1.1 misho 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:
1.1.1.3 ! misho 3391: 10.5 BGP Peer Group
! 3392: ===================
1.1 misho 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:
1.1.1.3 ! misho 3403: 10.6 BGP Address Family
! 3404: =======================
1.1 misho 3405:
3406:
3407: File: quagga.info, Node: Autonomous System, Next: BGP Communities Attribute, Prev: BGP Address Family, Up: BGP
3408:
1.1.1.3 ! misho 3409: 10.7 Autonomous System
! 3410: ======================
1.1 misho 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:
1.1.1.3 ! misho 3434: 10.7.1 AS Path Regular Expression
! 3435: ---------------------------------
1.1 misho 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:
1.1.1.3 ! misho 3473: 10.7.2 Display BGP Routes by AS Path
! 3474: ------------------------------------
1.1 misho 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:
1.1.1.3 ! misho 3486: 10.7.3 AS Path Access List
! 3487: --------------------------
1.1 misho 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:
1.1.1.3 ! misho 3500: 10.7.4 Using AS Path in Route Map
! 3501: ---------------------------------
1.1 misho 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:
1.1.1.3 ! misho 3510: 10.7.5 Private AS Numbers
! 3511: -------------------------
1.1 misho 3512:
3513:
3514: File: quagga.info, Node: BGP Communities Attribute, Next: BGP Extended Communities Attribute, Prev: Autonomous System, Up: BGP
3515:
1.1.1.3 ! misho 3516: 10.8 BGP Communities Attribute
! 3517: ==============================
1.1 misho 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:
1.1.1.3 ! misho 3577: 10.8.1 BGP Community Lists
! 3578: --------------------------
1.1 misho 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:
1.1.1.3 ! misho 3636: 10.8.2 Numbered BGP Community Lists
! 3637: -----------------------------------
1.1 misho 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:
1.1.1.3 ! misho 3668: 10.8.3 BGP Community in Route Map
! 3669: ---------------------------------
1.1 misho 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:
1.1.1.3 ! misho 3709: 10.8.4 Display BGP Routes by Community
! 3710: --------------------------------------
1.1 misho 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:
1.1.1.3 ! misho 3734: 10.8.5 Using BGP Communities Attribute
! 3735: --------------------------------------
1.1 misho 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:
1.1.1.3 ! misho 3837: 10.9 BGP Extended Communities Attribute
! 3838: =======================================
1.1 misho 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:
1.1.1.3 ! misho 3879: 10.9.1 BGP Extended Community Lists
! 3880: -----------------------------------
1.1 misho 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:
1.1.1.3 ! misho 3920: 10.9.2 BGP Extended Communities in Route Map
! 3921: --------------------------------------------
1.1 misho 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:
1.1.1.3 ! misho 3934: 10.10 Displaying BGP Routes
! 3935: ===========================
1.1 misho 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:
1.1.1.3 ! misho 3945: 10.10.1 Show IP BGP
! 3946: -------------------
1.1 misho 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:
1.1.1.3 ! misho 3966: 10.10.2 More Show IP BGP
! 3967: ------------------------
1.1 misho 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:
1.1.1.3 ! misho 4016: 10.11 Capability Negotiation
! 4017: ============================
1.1 misho 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:
1.1.1.3 ! misho 4087: 10.12 Route Reflector
! 4088: =====================
1.1 misho 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:
1.1.1.3 ! misho 4098: 10.13 Route Server
! 4099: ==================
1.1 misho 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:
1.1.1.3 ! misho 4127: 10.13.1 Multiple instance
! 4128: -------------------------
1.1 misho 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:
1.1.1.3 ! misho 4182: 10.13.2 BGP instance and view
! 4183: -----------------------------
1.1 misho 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:
1.1.1.3 ! misho 4226: 10.13.3 Routing policy
! 4227: ----------------------
1.1 misho 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:
1.1.1.3 ! misho 4250: 10.13.4 Viewing the view
! 4251: ------------------------
1.1 misho 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:
1.1.1.3 ! misho 4261: 10.14 How to set up a 6-Bone connection
! 4262: =======================================
1.1 misho 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:
1.1.1.3 ! misho 4308: 10.15 Dump BGP packets and table
! 4309: ================================
1.1 misho 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:
1.1.1.3 ! misho 4326: 10.16 BGP Configuration Examples
! 4327: ================================
1.1 misho 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:
1.1.1.3 ! misho 4554: 11 Configuring Quagga as a Route Server
1.1 misho 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:
1.1.1.3 ! misho 4578: 11.1 Description of the Route Server model
1.1 misho 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:
1.1.1.3 ! misho 4618: Figure 11.1: Announcement processing inside a "normal" BGP speaker
1.1 misho 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:
1.1.1.3 ! misho 4628: Figure 11.2: Full Mesh
1.1 misho 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:
1.1.1.3 ! misho 4637: Figure 11.3: Route Server and clients
1.1 misho 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:
1.1.1.3 ! misho 4770: Figure 11.4: Announcement processing model implemented by the Route
1.1 misho 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:
1.1.1.3 ! misho 4776: 11.2 Commands for configuring a Route Server
1.1 misho 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
1.1.1.3 ! misho 4795: peer (those named `Loc-RIB for X' in *note Figure 11.4:
1.1 misho 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
1.1.1.3 ! misho 4822: Figure 11.4: fig:rs-processing.).
1.1 misho 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:
1.1.1.3 ! misho 4835: 11.3 Example of Route Server Configuration
1.1 misho 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:
1.1.1.3 ! misho 4858: 11.3.1 Configuration of the BGP routers without Route Server
1.1 misho 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:
1.1.1.3 ! misho 4934: 11.3.2 Configuration of the BGP routers with Route Server
1.1 misho 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:
1.1.1.3 ! misho 4971: 11.3.3 Configuration of the Route Server itself
1.1 misho 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:
1.1.1.3 ! misho 5095: 11.3.4 Further considerations about Import and Export route-maps
1.1 misho 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:
1.1.1.3 ! misho 5168: 12 VTY shell
1.1 misho 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:
1.1.1.3 ! misho 5191: 12.1 VTY shell username
1.1 misho 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:
1.1.1.3 ! misho 5208: 12.2 VTY shell integrated configuration
1.1 misho 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:
1.1.1.3 ! misho 5239: 13 Filtering
1.1 misho 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:
1.1.1.3 ! misho 5254: 13.1 IP Access List
1.1 misho 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:
1.1.1.3 ! misho 5269: 13.2 IP Prefix List
1.1 misho 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:
1.1.1.3 ! misho 5344: 13.2.1 ip prefix-list description
1.1 misho 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:
1.1.1.3 ! misho 5358: 13.2.2 ip prefix-list sequential number control
1.1 misho 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:
1.1.1.3 ! misho 5372: 13.2.3 Showing ip prefix-list
1.1 misho 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:
1.1.1.3 ! misho 5406: 13.2.4 Clear counter of ip prefix-list
1.1 misho 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:
1.1.1.3 ! misho 5420: 14 Route Map
1.1 misho 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:
1.1.1.3 ! misho 5518: 14.1 Route Map Command
1.1 misho 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:
1.1.1.3 ! misho 5529: 14.2 Route Map Match Command
1.1 misho 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:
1.1.1.3 ! misho 5550: 14.3 Route Map Set Command
1.1 misho 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:
1.1.1.3 ! misho 5580: 14.4 Route Map Call Command
1.1 misho 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:
1.1.1.3 ! misho 5590: 14.5 Route Map Exit Action Command
1.1 misho 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:
1.1.1.3 ! misho 5605: 14.6 Route Map Examples
1.1 misho 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:
1.1.1.3 ! misho 5623: 15 IPv6 Support
1.1 misho 5624: ***************
5625:
5626: Quagga fully supports IPv6 routing. As described so far, Quagga
1.1.1.3 ! misho 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
1.1 misho 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:
1.1.1.3 ! misho 5640: 15.1 Router Advertisement
1.1 misho 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:
1.1.1.3 ! misho 5685: -- Interface Command: ipv6 nd ra-interval <1-1800>
! 5686: -- Interface Command: no ipv6 nd ra-interval [<1-1800>]
1.1 misho 5687: The maximum time allowed between sending unsolicited multicast
1.1.1.3 ! misho 5688: router advertisements from the interface, in seconds.
1.1 misho 5689:
5690: Default: `600'
5691:
1.1.1.3 ! misho 5692: -- Interface Command: ipv6 nd ra-interval msec <70-1800000>
! 5693: -- Interface Command: no ipv6 nd ra-interval [msec <70-1800000>]
1.1 misho 5694: The maximum time allowed between sending unsolicited multicast
1.1.1.3 ! misho 5695: router advertisements from the interface, in milliseconds.
1.1 misho 5696:
5697: Default: `600000'
5698:
1.1.1.3 ! misho 5699: -- Interface Command: ipv6 nd ra-lifetime <0-9000>
! 5700: -- Interface Command: no ipv6 nd ra-lifetime [<0-9000>]
1.1 misho 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:
1.1.1.3 ! misho 5711: -- Interface Command: ipv6 nd reachable-time <1-3600000>
! 5712: -- Interface Command: no ipv6 nd reachable-time [<1-3600000>]
1.1 misho 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
1.1.1.3 ! misho 5716: neighbors. The value zero means unspecified (by this router).
1.1 misho 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:
1.1.1.3 ! misho 5745: -- Interface Command: ipv6 nd home-agent-preference <0-65535>
! 5746: -- Interface Command: no ipv6 nd home-agent-preference [<0-65535>]
1.1 misho 5747: The value to be placed in Home Agent Option, when Home Agent
1.1.1.3 ! misho 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.
1.1 misho 5751:
5752: Default: 0
5753:
1.1.1.3 ! misho 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>]
1.1 misho 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.
1.1.1.3 ! misho 5762: The default value of 0 means to place the current Router Lifetime
! 5763: value.
1.1 misho 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)
1.1.1.3 ! misho 5776: -- Interface Command: no ipv6 nd router-preference [(high|medium|low)]
1.1 misho 5777: Set default router preference in IPv6 router advertisements per
5778: RFC4191.
5779:
5780: Default: medium
5781:
1.1.1.3 ! misho 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:
1.1 misho 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
1.1.1.3 ! misho 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)'.
1.1 misho 5798:
5799:
5800: File: quagga.info, Node: Kernel Interface, Next: SNMP Support, Prev: IPv6 Support, Up: Top
5801:
1.1.1.3 ! misho 5802: 16 Kernel Interface
1.1 misho 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:
1.1.1.3 ! misho 5851: 17 SNMP Support
1.1 misho 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:
1.1.1.3 ! misho 5870: 17.1 Getting and installing an SNMP agent
1.1 misho 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:
1.1.1.3 ! misho 5883: 17.2 SMUX configuration
1.1 misho 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:
1.1.1.3 ! misho 5938: 17.3 MIB and command reference
1.1 misho 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:
1.1.1.3 ! misho 5971: 17.4 Handling SNMP Traps
1.1 misho 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:
1.1.1.3 ! misho 6172: Appendix A Zebra Protocol
! 6173: *************************
1.1 misho 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:
1.1.1.3 ! misho 6273: Appendix B Packet Binary Dump Format
! 6274: ************************************
1.1 misho 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:
FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>
![[BACK]](/icons/cvsweb/back.gif){kind=icon}
Return to quagga.info-1 CVS log ![[TXT]](/icons/cvsweb/text.gif){kind=icon}
![[DIR]](/icons/cvsweb/dir.gif){kind=icon}
Up to [ELWIX - Embedded LightWeight unIX -] / embedaddon / quagga / doc