This is quagga.info, produced by makeinfo version 4.5 from quagga.texi.

INFO-DIR-SECTION Routing Software:
START-INFO-DIR-ENTRY
* Quagga: (quagga).		The Quagga routing software
END-INFO-DIR-ENTRY

   This file documents the GNU Quagga software which manages common
TCP/IP routing protocols.

   This is Edition 0.1, last updated 12 August 2003 of `The Quagga
Manual', for Quagga Version 0.96.

   Copyright (C) 1999, 2000, 2001, 2002 Kunihiro Ishiguro

   Permission is granted to make and distribute verbatim copies of this
manual provided the copyright notice and this permission notice are
preserved on all copies.

   Permission is granted to copy and distribute modified versions of
this manual under the conditions for verbatim copying, provided that the
entire resulting derived work is distributed under the terms of a
permission notice identical to this one.

   Permission is granted to copy and distribute translations of this
manual into another language, under the above conditions for modified
versions, except that this permission notice may be stated in a
translation approved by Kunihiro Ishiguro.


File: quagga.info,  Node: BGP Community Lists,  Next: Numbered BGP Community Lists,  Prev: BGP Communities Attribute,  Up: BGP Communities Attribute

BGP Community Lists
-------------------

   BGP community list is a user defined BGP communites attribute list.
BGP community list can be used for matching or manipulating BGP
communities attribute in updates.

   There are two types of community list.  One is standard community
list and another is expanded community list.  Standard community list
defines communities attribute.  Expanded community list defines
communities attribute string with regular expression.  Standard
community list is compiled into binary format when user define it.
Standard community list will be directly compared to BGP communities
attribute in BGP updates.  Therefore the comparison is faster than
expanded community list.

 - Command: ip community-list standard NAME {permit|deny} COMMUNITY
     This command defines a new standard community list.  COMMUNITY is
     communities value.  The COMMUNITY is compiled into community
     structure.  We can define multiple community list under same name.
     In that case match will happen user defined order.  Once the
     community list matches to communities attribute in BGP updates it
     return permit or deny by the community list definition.  When
     there is no matched entry, deny will be returned.  When COMMUNITY
     is empty it matches to any routes.

 - Command: ip community-list expanded NAME {permit|deny} LINE
     This command defines a new expanded community list.  LINE is a
     string expression of communities attribute.  LINE can include
     regular expression to match communities attribute in BGP updates.

 - Command: no ip community-list NAME
 - Command: no ip community-list standard NAME
 - Command: no ip community-list expanded NAME
     These commands delete community lists specified by NAME.  All of
     community lists shares a single name space.  So community lists
     can be removed simpley specifying community lists name.

 - Command: show ip community-list
 - Command: show ip community-list NAME
     This command display current community list information.  When
     NAME is specified the specified community list's information is
     shown.

          # show ip community-list
          Named Community standard list CLIST
              permit 7675:80 7675:100 no-export
              deny internet
          Named Community expanded list EXPAND
              permit :
          
          # show ip community-list CLIST
          Named Community standard list CLIST
              permit 7675:80 7675:100 no-export
              deny internet


File: quagga.info,  Node: Numbered BGP Community Lists,  Next: BGP Community in Route Map,  Prev: BGP Community Lists,  Up: BGP Communities Attribute

Numbered BGP Community Lists
----------------------------

   When number is used for BGP community list name, the number has
special meanings.  Community list number in the range from 1 and 99 is
standard community list.  Community list number in the range from 100
to 199 is expanded community list.  These community lists are called as
numbered community lists.  On the other hand normal community lists is
called as named community lists.

 - Command: ip community-list <1-99> {permit|deny} COMMUNITY
     This command defines a new community list.  <1-99> is standard
     community list number.  Community list name within this range
     defines standard community list.  When COMMUNITY is empty it
     matches to any routes.

 - Command: ip community-list <100-199> {permit|deny} COMMUNITY
     This command defines a new community list.  <100-199> is expanded
     community list number.  Community list name within this range
     defines expanded community list.

 - Command: ip community-list NAME {permit|deny} COMMUNITY
     When community list type is not specifed, the community list type
     is automatically detected.  If COMMUNITY can be compiled into
     communities attribute, the community list is defined as a standard
     community list.  Otherwise it is defined as an expanded community
     list.  This feature is left for backward compability.  Use of this
     feature is not recommended.


File: quagga.info,  Node: BGP Community in Route Map,  Next: Display BGP Routes by Community,  Prev: Numbered BGP Community Lists,  Up: BGP Communities Attribute

BGP Community in Route Map
--------------------------

   In Route Map (*note Route Map::), we can match or set BGP
communities attribute.  Using this feature network operator can
implement their network policy based on BGP communities attribute.

   Following commands can be used in Route Map.

 - Route Map: match community WORD
 - Route Map: match community WORD exact-match
     This command perform match to BGP updates using community list
     WORD.  When the one of BGP communities value match to the one of
     communities value in community list, it is match.  When
     `exact-match' keyword is spcified, match happen only when BGP
     updates have completely same communities value specified in the
     community list.

 - Route Map: set community none
 - Route Map: set community COMMUNITY
 - Route Map: set community COMMUNITY additive
     This command manipulate communities value in BGP updates.  When
     `none' is specified as communities value, it removes entire
     communities attribute from BGP updates.  When COMMUNITY is not
     `none', specified communities value is set to BGP updates.  If BGP
     updates already has BGP communities value, the existing BGP
     communities value is replaced with specified COMMUNITY value.
     When `additive' keyword is specified, COMMUNITY is appended to the
     existing communities value.

 - Route Map: set comm-list WORD delete
     This command remove communities value from BGP communities
     attribute.  The WORD is community list name.  When BGP route's
     communities value matches to the community list WORD, the
     communities value is removed.  When all of communities value is
     removed eventually, the BGP update's communities attribute is
     completely removed.


File: quagga.info,  Node: Display BGP Routes by Community,  Next: Using BGP Communities Attribute,  Prev: BGP Community in Route Map,  Up: BGP Communities Attribute

Display BGP Routes by Community
-------------------------------

   To show BGP routes which has specific BGP communities attribute,
`show ip bgp' command can be used.  The COMMUNITY value and community
list can be used for `show ip bgp' command.

 - Command: show ip bgp community
 - Command: show ip bgp community COMMUNITY
 - Command: show ip bgp community COMMUNITY exact-match
     `show ip bgp community' displays BGP routes which has communities
     attribute.  When COMMUNITY is specified, BGP routes that matches
     COMMUNITY value is displayed.  For this command, `internet'
     keyword can't be used for COMMUNITY value.  When `exact-match' is
     specified, it display only routes that have an exact match.

 - Command: show ip bgp community-list WORD
 - Command: show ip bgp community-list WORD exact-match
     This commands display BGP routes that matches community list WORD.
     When `exact-match' is specified, display only routes that have an
     exact match.


File: quagga.info,  Node: Using BGP Communities Attribute,  Prev: Display BGP Routes by Community,  Up: BGP Communities Attribute

Using BGP Communities Attribute
-------------------------------

   Following configuration is the most typical usage of BGP communities
attribute.  AS 7675 provides upstream Internet connection to AS 100.
When following configuration exists in AS 7675, AS 100 networks
operator can set local preference in AS 7675 network by setting BGP
communities attribute to the updates.

     router bgp 7675
      neighbor 192.168.0.1 remote-as 100
      neighbor 192.168.0.1 route-map RMAP in
     !
     ip community-list 70 permit 7675:70
     ip community-list 70 deny
     ip community-list 80 permit 7675:80
     ip community-list 80 deny
     ip community-list 90 permit 7675:90
     ip community-list 90 deny
     !
     route-map RMAP permit 10
      match community 70
      set local-preference 70
     !
     route-map RMAP permit 20
      match community 80
      set local-preference 80
     !
     route-map RMAP permit 30
      match community 90
      set local-preference 90

   Following configuration announce 10.0.0.0/8 from AS 100 to AS 7675.
The route has communities value 7675:80 so when above configuration
exists in AS 7675, announced route's local preference will be set to
value 80.

     router bgp 100
      network 10.0.0.0/8
      neighbor 192.168.0.2 remote-as 7675
      neighbor 192.168.0.2 route-map RMAP out
     !
     ip prefix-list PLIST permit 10.0.0.0/8
     !
     route-map RMAP permit 10
      match ip address prefix-list PLIST
      set community 7675:80

   Following configuration is an example of BGP route filtering using
communities attribute.  This configuration only permit BGP routes which
has BGP communities value 0:80 or 0:90.  Network operator can put
special internal communities value at BGP border router, then limit the
BGP routes announcement into the internal network.

     router bgp 7675
      neighbor 192.168.0.1 remote-as 100
      neighbor 192.168.0.1 route-map RMAP in
     !
     ip community-list 1 permit 0:80 0:90
     !
     route-map RMAP permit in
      match community 1

   Following exmaple filter BGP routes which has communities value 1:1.
When there is no match community-list returns deny.  To avoid filtering
all of routes, we need to define permit any at last.

     router bgp 7675
      neighbor 192.168.0.1 remote-as 100
      neighbor 192.168.0.1 route-map RMAP in
     !
     ip community-list standard FILTER deny 1:1
     ip community-list standard FILTER permit
     !
     route-map RMAP permit 10
      match community FILTER

   Communities value keyword `internet' has special meanings in
standard community lists.  In below example `internet' act as match
any.  It matches all of BGP routes even if the route does not have
communities attribute at all.  So community list `INTERNET' is same as
above example's `FILTER'.

     ip community-list standard INTERNET deny 1:1
     ip community-list standard INTERNET permit internet

   Following configuration is an example of communities value deletion.
With this configuration communities value 100:1 and 100:2 is removed
from BGP updates.  For communities value deletion, only `permit'
community-list is used.  `deny' community-list is ignored.

     router bgp 7675
      neighbor 192.168.0.1 remote-as 100
      neighbor 192.168.0.1 route-map RMAP in
     !
     ip community-list standard DEL permit 100:1 100:2
     !
     route-map RMAP permit 10
      set comm-list DEL delete


File: quagga.info,  Node: BGP Extended Communities Attribute,  Next: Displaying BGP routes,  Prev: BGP Communities Attribute,  Up: BGP

BGP Extended Communities Attribute
==================================

   BGP extended communities attribute is introduced with MPLS VPN/BGP
technology.  MPLS VPN/BGP expands capability of network infrastructure
to provide VPN functionality.  At the same time it requires a new
framework for policy routing.  With BGP Extended Communities Attribute
we can use Route Target or Site of Origin for implementing network
policy for MPLS VPN/BGP.

   BGP Extended Communities Attribute is similar to BGP Communities
Attribute.  It is an optional transitive attribute.  BGP Extended
Communities Attribute can carry multiple Extended Community value.
Each Extended Community value is eight octet length.

   BGP Extended Communities Attribute provides an extended range
compared with BGP Communities Attribute.  Adding to that there is a
type field in each value to provides community space structure.

   There are two format to define Extended Community value.  One is AS
based format the other is IP address based format.

`AS:VAL'
     This is a format to define AS based Extended Community value.
     `AS' part is 2 octets Global Administrator subfield in Extended
     Community value.  `VAL' part is 4 octets Local Administrator
     subfield.  `7675:100' represents AS 7675 policy value 100.

`IP-Address:VAL'
     This is a format to define IP address based Extended Community
     value.  `IP-Address' part is 4 octets Global Administrator
     subfield.  `VAL' part is 2 octets Local Administrator subfield.
     `10.0.0.1:100' represents

* Menu:

* BGP Extended Community Lists::
* BGP Extended Communities in Route Map::


File: quagga.info,  Node: BGP Extended Community Lists,  Next: BGP Extended Communities in Route Map,  Prev: BGP Extended Communities Attribute,  Up: BGP Extended Communities Attribute

BGP Extended Community Lists
----------------------------

   Expanded Community Lists is a user defined BGP Expanded Community
Lists.

 - Command: ip extcommunity-list standard NAME {permit|deny}
EXTCOMMUNITY
     This command defines a new standard extcommunity-list.
     EXTCOMMUNITY is extended communities value.  The EXTCOMMUNITY is
     compiled into extended community structure.  We can define
     multiple extcommunity-list under same name.  In that case match
     will happen user defined order.  Once the extcommunity-list
     matches to extended communities attribute in BGP updates it return
     permit or deny based upon the extcommunity-list definition.  When
     there is no matched entry, deny will be returned.  When
     EXTCOMMUNITY is empty it matches to any routes.

 - Command: ip extcommunity-list expanded NAME {permit|deny} LINE
     This command defines a new expanded extcommunity-list.  LINE is a
     string expression of extended communities attribute.  LINE can
     include regular expression to match extended communities attribute
     in BGP updates.

 - Command: no ip extcommunity-list NAME
 - Command: no ip extcommunity-list standard NAME
 - Command: no ip extcommunity-list expanded NAME
     These commands delete extended community lists specified by NAME.
     All of extended community lists shares a single name space.  So
     extended community lists can be removed simpley specifying the
     name.

 - Command: show ip extcommunity-list
 - Command: show ip extcommunity-list NAME
     This command display current extcommunity-list information.  When
     NAME is specified the community list's information is shown.

          # show ip extcommunity-list


File: quagga.info,  Node: BGP Extended Communities in Route Map,  Prev: BGP Extended Community Lists,  Up: BGP Extended Communities Attribute

BGP Extended Communities in Route Map
-------------------------------------

 - Route Map: match extcommunity WORD

 - Route Map: set extcommunity rt EXTCOMMUNITY
     This command set Route Target value.

 - Route Map: set extcommunity soo EXTCOMMUNITY
     This command set Site of Origin value.


File: quagga.info,  Node: Displaying BGP routes,  Next: Capability Negotiation,  Prev: BGP Extended Communities Attribute,  Up: BGP

Displaying BGP Routes
=====================

* Menu:

* Show IP BGP::
* More Show IP BGP::


File: quagga.info,  Node: Show IP BGP,  Next: More Show IP BGP,  Prev: Displaying BGP routes,  Up: Displaying BGP routes

Show IP BGP
-----------

 - Command: show ip bgp
 - Command: show ip bgp A.B.C.D
 - Command: show ip bgp X:X::X:X
     This command displays BGP routes.  When no route is specified it
     display all of IPv4 BGP routes.

     BGP table version is 0, local router ID is 10.1.1.1
     Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
     Origin codes: i - IGP, e - EGP, ? - incomplete
     
        Network          Next Hop            Metric LocPrf Weight Path
     *> 1.1.1.1/32       0.0.0.0                  0         32768 i
     
     Total number of prefixes 1


File: quagga.info,  Node: More Show IP BGP,  Prev: Show IP BGP,  Up: Displaying BGP routes

More Show IP BGP
----------------

 - Command: show ip bgp regexp LINE
     This command display BGP routes using AS path regular expression
     (*note Display BGP Routes by AS Path::).

 - Command: show ip bgp community COMMUNITY
 - Command: show ip bgp community COMMUNITY exact-match
     This command display BGP routes using COMMUNITY (*note Display BGP
     Routes by Community::).

 - Command: show ip bgp community-list WORD
 - Command: show ip bgp community-list WORD exact-match
     This command display BGP routes using community list (*note
     Display BGP Routes by Community::).

 - Command: show ip bgp summary

 - Command: show ip bgp neighbor [PEER]

 - Command: clear ip bgp PEER
     Clear peers which have addresses of X.X.X.X

 - Command: clear ip bgp PEER soft in
     Clear peer using soft reconfiguration.

 - Command: show debug

 - Command: debug event

 - Command: debug update

 - Command: debug keepalive

 - Command: no debug event

 - Command: no debug update

 - Command: no debug keepalive


File: quagga.info,  Node: Capability Negotiation,  Next: Route Reflector,  Prev: Displaying BGP routes,  Up: BGP

Capability Negotiation
======================

   When adding IPv6 routing information exchange feature to BGP.  There
were some proposals.  IETF IDR working group finally take a proposal
called Multiprotocol Extension for BGP.  The specification is described
in RFC2283.  The protocol does not define new protocols.  It defines
new attributes to existing BGP.  When it is used exchanging IPv6
routing information it is called BGP-4+.  When it is used for
exchanging multicast routing information it is called MBGP.

   `bgpd' supports Multiprotocol Extension for BGP.  So if remote peer
supports the protocol, `bgpd' can exchange IPv6 and/or multicast routing
information.

   Traditional BGP does not have the feature to detect remote peer's
capability whether it can handle other than IPv4 unicast routes.  This
is a big problem using Multiprotocol Extension for BGP to operational
network.  `draft-ietf-idr-bgp4-cap-neg-04.txt' is proposing a feature
called Capability Negotiation.  `bgpd' use this Capability Negotiation
to detect remote peer's capabilities.  If the peer is only configured
as IPv4 unicast neighbor, `bgpd' does not send these Capability
Negotiation packets.

   By default, Quagga will bring up peering with minimal common
capability for the both sides.  For example, local router has unicast
and multicast capabilitie and remote router has unicast capability.  In
this case, the local router will establish the connection with unicast
only capability.  When there are no common capabilities, Quagga sends
Unsupported Capability error and then resets the connection.

   If you want to completely match capabilities with remote peer.
Please use `strict-capability-match' command.

 - BGP: neighbor PEER strict-capability-match
 - BGP: no neighbor PEER strict-capability-match
     Strictly compares remote capabilities and local capabilities.  If
     capabilities are different, send Unsupported Capability error then
     reset connection.

   You may want to disable sending Capability Negotiation OPEN message
optional parameter to the peer when remote peer does not implement
Capability Negotiation.  Please use `dont-capability-negotiate' command
to disable the feature.

 - BGP: neighbor PEER dont-capability-negotiate
 - BGP: no neighbor PEER dont-capability-negotiate
     Suppress sending Capability Negotiation as OPEN message optional
     parameter to the peer.  This command only affects the peer is
     configured other than IPv4 unicast configuration.

   When remote peer does not have capability negotiation feature, remote
peer will not send any capabilities at all.  In that case, bgp
configures the peer with configured capabilities.

   You may prefer locally configured capabilities more than the
negotiated capabilities even though remote peer sends capabilities.  If
the peer is configured by `override-capability', `bgpd' ignores received
capabilities then override negotiated capabilities with configured
values.

 - BGP: neighbor PEER override-capability
 - BGP: no neighbor PEER override-capability
     Override the result of Capability Negotiation with local
     configuration.  Ignore remote peer's capability value.


File: quagga.info,  Node: Route Reflector,  Next: Route Server,  Prev: Capability Negotiation,  Up: BGP

Route Reflector
===============

 - BGP: bgp cluster-id A.B.C.D

 - BGP: neighbor PEER route-reflector-client
 - BGP: no neighbor PEER route-reflector-client


File: quagga.info,  Node: Route Server,  Next: How to set up a 6-Bone connection,  Prev: Route Reflector,  Up: BGP

Route Server
============

   At an Internet Exchange point, many ISPs are connected to each other
by external BGP peering.  Normally these external BGP connection are
done by `full mesh' method.  As with internal BGP full mesh formation,
this method has a scaling problem.

   This scaling problem is well known.  Route Server is a method to
resolve the problem.  Each ISP's BGP router only peers to Route Server.
Route Server serves as BGP information exchange to other BGP routers.
By applying this method, numbers of BGP connections is reduced from
O(n*(n-1)/2) to O(n).

   Unlike normal BGP router, Route Server must have several routing
tables for managing different routing policies for each BGP speaker.
We call the routing tables as different `view's.  `bgpd' can work as
normal BGP router or Route Server or both at the same time.

* Menu:

* Multiple instance::
* BGP instance and view::
* Routing policy::
* Viewing the view::


File: quagga.info,  Node: Multiple instance,  Next: BGP instance and view,  Prev: Route Server,  Up: Route Server

Multiple instance
-----------------

   To enable multiple view function of `bgpd', you must turn on
multiple instance feature beforehand.

 - Command: bgp multiple-instance
     Enable BGP multiple instance feature.  After this feature is
     enabled, you can make multiple BGP instances or multiple BGP views.

 - Command: no bgp multiple-instance
     Disable BGP multiple instance feature.  You can not disable this
     feature when BGP multiple instances or views exist.

   When you want to make configuration more Cisco like one,

 - Command: bgp config-type cisco
     Cisco compatible BGP configuration output.

   When bgp config-type cisco is specified,

   "no synchronization" is displayed.  "no auto-summary" is desplayed.

   "network" and "aggregate-address" argument is displayed as "A.B.C.D
M.M.M.M"

   Quagga: network 10.0.0.0/8 Cisco: network 10.0.0.0

   Quagga: aggregate-address 192.168.0.0/24 Cisco: aggregate-address
192.168.0.0 255.255.255.0

   Community attribute handling is also different.  If there is no
configuration is specified community attribute and extended community
attribute are sent to neighbor.  When user manually disable the feature
community attribute is not sent to the neighbor.  In case of "bgp
config-type cisco" is specified, community attribute is not sent to the
neighbor by default.  To send community attribute user has to specify
"neighbor A.B.C.D send-community" command.

   !  router bgp 1  neighbor 10.0.0.1 remote-as 1  no neighbor 10.0.0.1
send-community !

   !  router bgp 1  neighbor 10.0.0.1 remote-as 1  neighbor 10.0.0.1
send-community !

 - Command: bgp config-type zebra
     Quagga style BGP configuration.  This is default.


File: quagga.info,  Node: BGP instance and view,  Next: Routing policy,  Prev: Multiple instance,  Up: Route Server

BGP instance and view
---------------------

   BGP instance is a normal BGP process.  The result of route selection
goes to the kernel routing table.  You can setup different AS at the
same time when BGP multiple instance feature is enabled.

 - Command: router bgp AS-NUMBER
     Make a new BGP instance.  You can use arbitrary word for the NAME.

     bgp multiple-instance
     !
     router bgp 1
      neighbor 10.0.0.1 remote-as 2
      neighbor 10.0.0.2 remote-as 3
     !
     router bgp 2
      neighbor 10.0.0.3 remote-as 4
      neighbor 10.0.0.4 remote-as 5

   BGP view is almost same as normal BGP process. The result of route
selection does not go to the kernel routing table.  BGP view is only
for exchanging BGP routing information.

 - Command: router bgp AS-NUMBER view NAME
     Make a new BGP view.  You can use arbitrary word for the NAME.
     This view's route selection result does not go to the kernel
     routing table.

   With this command, you can setup Route Server like below.

     bgp multiple-instance
     !
     router bgp 1 view 1
      neighbor 10.0.0.1 remote-as 2
      neighbor 10.0.0.2 remote-as 3
     !
     router bgp 2 view 2
      neighbor 10.0.0.3 remote-as 4
      neighbor 10.0.0.4 remote-as 5


File: quagga.info,  Node: Routing policy,  Next: Viewing the view,  Prev: BGP instance and view,  Up: Route Server

Routing policy
--------------

   You can set different routing policy for a peer.  For example, you
can set different filter for a peer.

     bgp multiple-instance
     !
     router bgp 1 view 1
      neighbor 10.0.0.1 remote-as 2
      neighbor 10.0.0.1 distribute-list 1 in
     !
     router bgp 1 view 2
      neighbor 10.0.0.1 remote-as 2
      neighbor 10.0.0.1 distribute-list 2 in

   This means BGP update from a peer 10.0.0.1 goes to both BGP view 1
and view 2.  When the update is inserted into view 1, distribute-list 1
is applied.  On the other hand, when the update is inserted into view 2,
distribute-list 2 is applied.


File: quagga.info,  Node: Viewing the view,  Prev: Routing policy,  Up: Route Server

Viewing the view
----------------

   To display routing table of BGP view, you must specify view name.

 - Command: show ip bgp view NAME
     Display routing table of BGP view NAME.


File: quagga.info,  Node: How to set up a 6-Bone connection,  Next: Dump BGP packets and table,  Prev: Route Server,  Up: BGP

How to set up a 6-Bone connection
=================================

     zebra configuration
     ===================
     !
     ! Actually there is no need to configure zebra
     !
     
     bgpd configuration
     ==================
     !
     ! This means that routes go through zebra and into the kernel.
     !
     router zebra
     !
     ! MP-BGP configuration
     !
     router bgp 7675
      bgp router-id 10.0.0.1
      neighbor 3ffe:1cfa:0:2:2a0:c9ff:fe9e:f56 remote-as AS-NUMBER
     !
      address-family ipv6
      network 3ffe:506::/32
      neighbor 3ffe:1cfa:0:2:2a0:c9ff:fe9e:f56 activate
      neighbor 3ffe:1cfa:0:2:2a0:c9ff:fe9e:f56 route-map set-nexthop out
      neighbor 3ffe:1cfa:0:2:2c0:4fff:fe68:a231 remote-as AS-NUMBER
      neighbor 3ffe:1cfa:0:2:2c0:4fff:fe68:a231 route-map set-nexthop out
      exit-address-family
     !
     ipv6 access-list all permit any
     !
     ! Set output nexthop address.
     !
     route-map set-nexthop permit 10
      match ipv6 address all
      set ipv6 nexthop global 3ffe:1cfa:0:2:2c0:4fff:fe68:a225
      set ipv6 nexthop local fe80::2c0:4fff:fe68:a225
     !
     ! logfile FILENAME is obsolete.  Please use log file FILENAME
     
     log file bgpd.log
     !


File: quagga.info,  Node: Dump BGP packets and table,  Prev: How to set up a 6-Bone connection,  Up: BGP

Dump BGP packets and table
==========================

 - Command: dump bgp all PATH
 - Command: dump bgp all PATH INTERVAL
     Dump all BGP packet and events to PATH file.

 - Command: dump bgp updates PATH
 - Command: dump bgp updates PATH INTERVAL
     Dump BGP updates to PATH file.

 - Command: dump bgp routes PATH
 - Command: dump bgp routes PATH
     Dump whole BGP routing table to PATH.  This is heavy process.


File: quagga.info,  Node: VTY shell,  Next: Filtering,  Prev: BGP,  Up: Top

VTY shell
*********

   `vtysh' is integrated shell of Quagga software.

   To use vtysh please specify --enable-vtysh to configure script.  To
use PAM for authentication use --with-libpam option to configure script.

   vtysh only searches /usr/local/etc path for vtysh.conf which is the
vtysh configuration file.  Vtysh does not search current directory for
configuration file because the file includes user authentication
settings.

   Currently, vtysh.conf has only two commands.

 - Command: username USERNAME nopassword
     With this set, user foo does not need password authentication for
     user vtysh.  With PAM vtysh uses PAM authentication mechanism.

     If vtysh is compiled without PAM authentication, every user can
     use vtysh without authentication. vtysh requires read/write
     permission to the various daemons vty sockets, this can be
     accomplished through use of unix groups and the -enable-vty-group
     configure option.


 - Command: write-conf daemon
     Instruct daemons to write out their config files when 'write file'
     is issued.

 - Command: write-conf integrated
     Write out integrated Quagga.conf file when 'write file' is issued.

   This command controls the behaviour of vtysh when it is told to
write out the configuration.  If `write-conf integrated' is set, the
daemon will write out a Quagga.conf with all daemons' commands
integrated into it. If `write-conf daemon' is set, vtysh will instruct
each daemon to write out their config files.

   Vtysh per default behaves as if `write-conf daemon' is set. Note
that both may be set at same time if one wishes to have both
Quagga.conf and daemon specific files written out. Further, note that
the daemons are hard-coded to first look for the integrated Quagga.conf
file before looking for their own file.

   We recommend you do not mix the use of the two types of files.
Further, it is better not to use the integrated Quagga.conf file, as
any syntax error in it can lead to /all/ of your daemons being unable
to start up. Per daemon files are more robust as impact of errors in
configuration are limited to the daemon in whose file the error is made.


File: quagga.info,  Node: Filtering,  Next: Route Map,  Prev: VTY shell,  Up: Top

Filtering
*********

   Quagga provides many very flexible filtering features.  Filtering is
used for both input and output of the routing information.  Once
filtering is defined, it can be applied in any direction.

* Menu:

* IP Access List::
* IP Prefix List::


File: quagga.info,  Node: IP Access List,  Next: IP Prefix List,  Prev: Filtering,  Up: Filtering

IP Access List
--------------

 - Command: access-list NAME permit IPV4-NETWORK
 - Command: access-list NAME deny IPV4-NETWORK

   Basic filtering is done by `access-list' as shown in the following
example.

     access-list filter deny 10.0.0.0/9
     access-list filter permit 10.0.0.0/8


File: quagga.info,  Node: IP Prefix List,  Prev: IP Access List,  Up: Filtering

IP Prefix List
--------------

   `ip prefix-list' provides the most powerful prefix based filtering
mechanism.  In addition to `access-list' functionality, `ip
prefix-list' has prefix length range specification and sequential
number specification.  You can add or delete prefix based filters to
arbitrary points of prefix-list using sequential number specification.

   If no ip prefix-list is specified, it acts as permit.  If `ip
prefix-list' is defined, and no match is found, default deny is applied.

 - Command: ip prefix-list NAME (permit|deny) PREFIX [le LEN] [ge LEN]
 - Command: ip prefix-list NAME seq NUMBER (permit|deny) PREFIX [le
LEN] [ge LEN]
     You can create `ip prefix-list' using above commands.

    seq
          seq NUMBER can be set either automatically or manually.  In
          the case that sequential numbers are set manually, the user
          may pick any number less than 4294967295.  In the case that
          sequential number are set automatically, the sequential
          number will increase by a unit of five (5) per list.  If a
          list with no specified sequential number is created after a
          list with a specified sequential number, the list will
          automatically pick the next multiple of five (5) as the list
          number.  For example, if a list with number 2 already exists
          and a new list with no specified number is created, the next
          list will be numbered 5.  If lists 2 and 7 already exist and
          a new list with no specified number is created, the new list
          will be numbered 10.

    le
          `le' command specifies prefix length.  The prefix list will be
          applied if the prefix length is less than or equal to the le
          prefix length.

    ge
          `ge' command specifies prefix length.  The prefix list will be
          applied if the prefix length is greater than or equal to the
          ge prefix length.



   Less than or equal to prefix numbers and greater than or equal to
prefix numbers can be used together.  The order of the le and ge
commands does not matter.

   If a prefix list with a different sequential number but with the
exact same rules as a previous list is created, an error will result.
However, in the case that the sequential number and the rules are
exactly similar, no error will result.

   If a list with the same sequential number as a previous list is
created, the new list will overwrite the old list.

   Matching of IP Prefix is performed from the smaller sequential
number to the larger.  The matching will stop once any rule has been
applied.

   In the case of no le or ge command,

   Version 0.85: the matching rule will apply to all prefix lengths that
matched the prefix list.

   Version 0.86 or later: In the case of no le or ge command, the prefix
length must match exactly the length specified in the prefix list.

 - Command: no ip prefix-list NAME

* Menu:

* ip prefix-list description::
* ip prefix-list sequential number control::
* Showing ip prefix-list::
* Clear counter of ip prefix-list::


File: quagga.info,  Node: ip prefix-list description,  Next: ip prefix-list sequential number control,  Prev: IP Prefix List,  Up: IP Prefix List

ip prefix-list description
..........................

 - Command: ip prefix-list NAME description DESC
     Descriptions may be added to prefix lists.  This command adds a
     description to the prefix list.

 - Command: no ip prefix-list NAME description [DESC]
     Deletes the description from a prefix list.  It is possible to use
     the command without the full description.


File: quagga.info,  Node: ip prefix-list sequential number control,  Next: Showing ip prefix-list,  Prev: ip prefix-list description,  Up: IP Prefix List

ip prefix-list sequential number control
........................................

 - Command: ip prefix-list sequence-number
     With this command, the IP prefix list sequential number is
     displayed.  This is the default behavior.

 - Command: no ip prefix-list sequence-number
     With this command, the IP prefix list sequential number is not
     displayed.


File: quagga.info,  Node: Showing ip prefix-list,  Next: Clear counter of ip prefix-list,  Prev: ip prefix-list sequential number control,  Up: IP Prefix List

Showing ip prefix-list
......................

 - Command: show ip prefix-list
     Display all IP prefix lists.

 - Command: show ip prefix-list NAME
     Show IP prefix list can be used with a prefix list name.

 - Command: show ip prefix-list NAME seq NUM
     Show IP prefix list can be used with a prefix list name and
     sequential number.

 - Command: show ip prefix-list NAME A.B.C.D/M
     If the command longer is used, all prefix lists with prefix
     lengths equal to or longer than the specified length will be
     displayed.  If the command first match is used, the first prefix
     length match will be displayed.

 - Command: show ip prefix-list NAME A.B.C.D/M longer

 - Command: show ip prefix-list NAME A.B.C.D/M first-match

 - Command: show ip prefix-list summary

 - Command: show ip prefix-list summary NAME

 - Command: show ip prefix-list detail

 - Command: show ip prefix-list detail NAME


File: quagga.info,  Node: Clear counter of ip prefix-list,  Prev: Showing ip prefix-list,  Up: IP Prefix List

Clear counter of ip prefix-list
...............................

 - Command: clear ip prefix-list
     Clears the counters of all IP prefix lists.  Clear IP Prefix List
     can be used with a specified name and prefix.

 - Command: clear ip prefix-list NAME

 - Command: clear ip prefix-list NAME A.B.C.D/M


File: quagga.info,  Node: Route Map,  Next: IPv6 Support,  Prev: Filtering,  Up: Top

Route Map
*********

   Route map is a very useful function in zebra.  There is a match and
set statement permitted in a route map.

     route-map test permit 10
      match ip address 10
      set local-preference 200

   This means that if a route matches ip access-list number 10 it's
local-preference value is set to 200.

* Menu:

* Route Map Command::
* Route Map Match Command::
* Route Map Set Command::


File: quagga.info,  Node: Route Map Command,  Next: Route Map Match Command,  Prev: Route Map,  Up: Route Map

Route Map Command
-----------------

 - Command: route-map ROUTE-MAP-NAME permit PRIORITY


File: quagga.info,  Node: Route Map Match Command,  Next: Route Map Set Command,  Prev: Route Map Command,  Up: Route Map

Route Map Match Command
-----------------------

 - Route-map Command: match ip address ACCESS_LIST
     Matches the specified ACCESS_LIST

 - Route-map Command: match ip next-hop IPV4_ADDR
     Matches the specified IPV4_ADDR.

 - Route-map Command: match aspath AS_PATH
     Matches the specified AS_PATH.

 - Route-map Command: match metric METRIC
     Matches the specified METRIC.

 - Route-map Command: match community COMMUNITY_LIST
     Matches the specified  COMMUNITY_LIST


File: quagga.info,  Node: Route Map Set Command,  Prev: Route Map Match Command,  Up: Route Map

Route Map Set Command
---------------------

 - Route-map Command: set ip next-hop IPV4_ADDRESS
     Set the BGP nexthop address.

 - Route-map Command: set local-preference LOCAL_PREF
     Set the BGP local preference.

 - Route-map Command: set weight WEIGHT
     Set the route's weight.

 - Route-map Command: set metric METRIC
     Set the BGP attribute MED.

 - Route-map Command: set as-path prepend AS_PATH
     Set the BGP AS path to prepend.

 - Route-map Command: set community COMMUNITY
     Set the BGP community attribute.

 - Route-map Command: set ipv6 next-hop global IPV6_ADDRESS
     Set the BGP-4+ global IPv6 nexthop address.

 - Route-map Command: set ipv6 next-hop local IPV6_ADDRESS
     Set the BGP-4+ link local IPv6 nexthop address.


File: quagga.info,  Node: IPv6 Support,  Next: Kernel Interface,  Prev: Route Map,  Up: Top

IPv6 Support
************

   Quagga fully supports IPv6 routing.  As described so far, Quagga
supports RIPng, OSPFv3 and BGP-4+.  You can give IPv6 addresses to an
interface and configure static IPv6 routing information.  Quagga-IPv6
also provides automatic address configuration via a feature called
`address auto configuration'.  To do it, the router must send router
advertisement messages to the all nodes that exist on the network.

* Menu:

* Router Advertisement::


File: quagga.info,  Node: Router Advertisement,  Prev: IPv6 Support,  Up: IPv6 Support

Router Advertisement
====================

 - Interface Command: ipv6 nd send-ra

 - Interface Command: ipv6 nd prefix-advertisement IPV6PREFIX

     interface eth0
      ipv6 nd send-ra
      ipv6 nd prefix-advertisement 3ffe:506:5009::/64


File: quagga.info,  Node: Kernel Interface,  Next: SNMP Support,  Prev: IPv6 Support,  Up: Top

Kernel Interface
****************

   There are several different methods for reading kernel routing table
information, updating kernel routing tables, and for looking up
interfaces.

`ioctl'
     The `ioctl' method is a very traditional way for reading or writing
     kernel information.  `ioctl' can be used for looking up interfaces
     and for modifying interface addresses, flags, mtu settings and
     other types of information.  Also, `ioctl' can insert and delete
     kernel routing table entries.  It will soon be available on almost
     any platform which zebra supports, but it is a little bit ugly
     thus far, so if a better method is supported by the kernel, zebra
     will use that.

`sysctl'
     `sysctl' can lookup kernel information using MIB (Management
     Information Base) syntax.  Normally, it only provides a way of
     getting information from the kernel.  So one would usually want to
     change kernel information using another method such as `ioctl'.

`proc filesystem'
     `proc filesystem' provides an easy way of getting kernel
     information.

`routing socket'

`netlink'
     On recent Linux kernels (2.0.x and 2.2.x), there is a kernel/user
     communication support called `netlink'.  It makes asynchronous
     communication between kernel and Quagga possible, similar to a
     routing socket on BSD systems.

     Before you use this feature, be sure to select (in kernel
     configuration) the kernel/netlink support option 'Kernel/User
     network link driver' and 'Routing messages'.

     Today, the /dev/route special device file is obsolete.  Netlink
     communication is done by reading/writing over netlink socket.

     After the kernel configuration, please reconfigure and rebuild
     Quagga.  You can use netlink as a dynamic routing update channel
     between Quagga and the kernel.


File: quagga.info,  Node: SNMP Support,  Next: Zebra Protocol,  Prev: Kernel Interface,  Up: Top

SNMP Support
************

   SNMP (Simple Network Managing Protocol) is widely implemented feature
for collecting network information from router and/or host.  Quagga
itself does not support SNMP agent functionality.  But conjuction with
SNMP agent, Quagga provides routing protocol MIBs.

   Quagga uses SMUX protocol (RFC1227) for making communication with
SNMP agent.  There are several SNMP agent which support SMUX.  We
recommend to use the latest `ucd-snmp' software.

* Menu:

* How to get ucd-snmp::
* SMUX configuration::


File: quagga.info,  Node: How to get ucd-snmp,  Next: SMUX configuration,  Prev: SNMP Support,  Up: SNMP Support

How to get ucd-snmp
===================

   ucd-snmp is a free software which distributed so called "as is"
software license.  Please check the license which comes with
distribution of `ucd-snmp'.  The authors of ucd-snmp are the University
of California, the University of California at Davis, and the Electrical
Engineering department at the University of California at Davis.

   You can get ucd-snmp from <ftp://ucd-snmp.ucdavis.edu/>.  As of this
writing we are testing with `ucd-snmp-4.1.pre1.tar.gz'.

   To enable SMUX protocol support, please configure `ucd-snmp' like
below.

     % configure --with-mib-modules=smux

   After compile and install `ucd-snmp', you will need to configure
smuxpeer.  I'm now using configuration shown below.  This means SMUX
client connects to MIB 1.3.6.1.6.3.1 with password test.

     /usr/local/share/snmp/snmpd.conf
     ================================
     smuxpeer 1.3.6.1.6.3.1 test


File: quagga.info,  Node: SMUX configuration,  Prev: How to get ucd-snmp,  Up: SNMP Support

SMUX configuration
==================

   To enable SNMP support of Quagga, you have to configure Quagga with
`--enable-snmp' (*note Configure the Software::).

 - Command: smux peer OID
 - Command: no smux peer OID

 - Command: smux peer OID PASSWORD
 - Command: no smux peer OID PASSWORD

     !
     smux peer .1.3.6.1.6.3.1 test
     !


File: quagga.info,  Node: Zebra Protocol,  Next: Packet Binary Dump Format,  Prev: SNMP Support,  Up: Top

Zebra Protocol
**************

   Zebra Protocol is a protocol which is used between protocol daemon
and zebra.  Each protocol daemon sends selected routes to zebra daemon.
Then zebra manages which route is installed into the forwarding table.

   Zebra Protocol is a TCP-based protocol.  Below is common header of
Zebra Protocol.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |           Length (2)          |   Command (1) |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length is total packet length including this header length.  So
minimum length is three.  Command is Zebra Protocol command.

     ZEBRA_INTERFACE_ADD                1
     ZEBRA_INTERFACE_DELETE             2
     ZEBRA_INTERFACE_ADDRESS_ADD        3
     ZEBRA_INTERFACE_ADDRESS_DELETE     4
     ZEBRA_INTERFACE_UP                 5
     ZEBRA_INTERFACE_DOWN               6
     ZEBRA_IPV4_ROUTE_ADD               7
     ZEBRA_IPV4_ROUTE_DELETE            8
     ZEBRA_IPV6_ROUTE_ADD               9
     ZEBRA_IPV6_ROUTE_DELETE           10
     ZEBRA_REDISTRIBUTE_ADD            11
     ZEBRA_REDISTRIBUTE_DELETE         12
     ZEBRA_REDISTRIBUTE_DEFAULT_ADD    13
     ZEBRA_REDISTRIBUTE_DEFAULT_DELETE 14
     ZEBRA_IPV4_NEXTHOP_LOOKUP         15
     ZEBRA_IPV6_NEXTHOP_LOOKUP         16

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             Type              |             Flags             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

