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