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