summaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
Diffstat (limited to 'doc')
-rw-r--r--doc/ChangeLog5
-rw-r--r--doc/bgpd.texi393
-rw-r--r--doc/ospf6d.texi17
-rw-r--r--doc/quagga.info699
-rw-r--r--doc/routemap.texi174
5 files changed, 1040 insertions, 248 deletions
diff --git a/doc/ChangeLog b/doc/ChangeLog
index 4e9ae352..31f94f72 100644
--- a/doc/ChangeLog
+++ b/doc/ChangeLog
@@ -5,6 +5,11 @@
traps.
* snmp.texi: Minor formatting changes.
* quagga.info: Update auto-built file
+ * ospf6d.texi: Add example config
+ * bgpd.tex: Add example configs. Couple of cleanups of format
+ and macros.
+ * routemap.texi: Add an explanation of how route-maps work.
+ Document the call and exit-policy commands.
2005-10-29 Paul Jakma <paul@dishone.st>
diff --git a/doc/bgpd.texi b/doc/bgpd.texi
index 43d97028..a9c4810f 100644
--- a/doc/bgpd.texi
+++ b/doc/bgpd.texi
@@ -5,15 +5,15 @@
@node BGP
@chapter BGP
- BGP stands for a Border Gateway Protocol. The lastest BGP version
+@acronym{BGP} stands for a Border Gateway Protocol. The lastest BGP version
is 4. It is referred as BGP-4. BGP-4 is one of the Exterior Gateway
Protocols and de-fact standard of Inter Domain routing protocol.
-BGP-4 is described in @code{RFC1771} - @cite{A Border Gateway Protocol
+BGP-4 is described in @cite{RFC1771, A Border Gateway Protocol
4 (BGP-4)}.
- Many extentions are added to @code{RFC1771}. @code{RFC2858} -
-@cite{Multiprotocol Extensions for BGP-4} provide multiprotocol
-support to BGP-4.
+Many extensions have been added to @cite{RFC1771}. @cite{RFC2858,
+Multiprotocol Extensions for BGP-4} provides multiprotocol support to
+BGP-4.
@menu
* Starting BGP::
@@ -31,6 +31,7 @@ support to BGP-4.
* Route Server::
* How to set up a 6-Bone connection::
* Dump BGP packets and table::
+* BGP Configuration Examples::
@end menu
@node Starting BGP
@@ -338,16 +339,16 @@ This command bind specific peer to peer group @var{word}.
@node Autonomous System
@section Autonomous System
- AS (Autonomous System) is one of the essential element of BGP. BGP
-is a distance vector routing protocol. AS framework provides distance
-vector metric and loop detection to BGP. @code{RFC1930} -
-@cite{Guidelines for creation, selection, and registration of an
-Autonomous System (AS)} describes how to use AS.
+The @acronym{AS,Autonomous System} number is one of the essential
+element of BGP. BGP is a distance vector routing protocol, and the
+AS-Path framework provides distance vector metric and loop detection to
+BGP. @cite{RFC1930, Guidelines for creation, selection, and
+registration of an Autonomous System (AS)} provides some background on
+the concepts of an AS.
- AS number is tow octet digita value. So the value range is from 1
-to 65535. AS numbers 64512 through 65535 are defined as private AS
-numbers. Private AS numbers must not to be advertised in the global
-Internet.
+The AS number is a two octet value, ranging in value from 1 to 65535.
+The AS numbers 64512 through 65535 are defined as private AS numbers.
+Private AS numbers must not to be advertised in the global Internet.
@menu
* AS Path Regular Expression::
@@ -360,7 +361,7 @@ Internet.
@node AS Path Regular Expression
@subsection AS Path Regular Expression
- AS path regular expression can be used for displaying BGP routes and
+AS path regular expression can be used for displaying BGP routes and
AS path access list. AS path regular expression is based on
@code{POSIX 1003.2} regular expressions. Following description is
just a subset of @code{POSIX} regular expression. User can use full
@@ -392,7 +393,7 @@ matches to all of BGP routes which as AS number include @var{7675}.
@node Display BGP Routes by AS Path
@subsection Display BGP Routes by AS Path
- To show BGP routes which has specific AS path information @code{show
+To show BGP routes which has specific AS path information @code{show
ip bgp} command can be used.
@deffn Command {show ip bgp regexp @var{line}} {}
@@ -403,7 +404,7 @@ expression @var{line}.
@node AS Path Access List
@subsection AS Path Access List
- AS path access list is user defined AS path.
+AS path access list is user defined AS path.
@deffn {Command} {ip as-path access-list @var{word} @{permit|deny@} @var{line}} {}
This command defines a new AS path access list.
@@ -429,15 +430,15 @@ This command defines a new AS path access list.
@node BGP Communities Attribute
@section BGP Communities Attribute
- BGP communities attribute is widely used for implementing policy
+BGP communities attribute is widely used for implementing policy
routing. Network operators can manipulate BGP communities attribute
based on their network policy. BGP communities attribute is defined
-in @code{RFC1997} - @cite{BGP Communities Attribute} and
-@code{RFC1998} - @cite{An Application of the BGP Community Attribute
+in @cite{RFC1997, BGP Communities Attribute} and
+@cite{RFC1998, An Application of the BGP Community Attribute
in Multi-home Routing}. It is an optional transitive attribute,
therefore local policy can travel through different autonomous system.
- Communities attribute is a set of communities values. Each
+Communities attribute is a set of communities values. Each
communities value is 4 octet long. The following format is used to
define communities value.
@@ -487,7 +488,7 @@ values are sorted in numerical order.
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
+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
@@ -545,7 +546,7 @@ Named Community standard list CLIST
@node Numbered BGP Community Lists
@subsection Numbered BGP Community Lists
- When number is used for BGP community list name, the number has
+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
@@ -577,11 +578,11 @@ feature is not recommended.
@node BGP Community in Route Map
@subsection BGP Community in Route Map
- In Route Map (@pxref{Route Map}), we can match or set BGP
+In Route Map (@pxref{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.
+Following commands can be used in Route Map.
@deffn {Route Map} {match community @var{word}} {}
@deffnx {Route Map} {match community @var{word} exact-match} {}
@@ -617,7 +618,7 @@ BGP update's communities attribute is completely removed.
@node Display BGP Routes by Community
@subsection Display BGP Routes by Community
- To show BGP routes which has specific BGP communities attribute,
+To show BGP routes which has specific BGP communities attribute,
@code{show ip bgp} command can be used. The @var{community} value and
community list can be used for @code{show ip bgp} command.
@@ -642,7 +643,7 @@ that have an exact match.
@node Using BGP Communities Attribute
@subsection Using BGP Communities Attribute
- Following configuration is the most typical usage of BGP communities
+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
@@ -673,7 +674,7 @@ route-map RMAP permit 30
set local-preference 90
@end example
- Following configuration announce 10.0.0.0/8 from AS 100 to AS 7675.
+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.
@@ -691,7 +692,7 @@ route-map RMAP permit 10
set community 7675:80
@end example
- Following configuration is an example of BGP route filtering using
+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
@@ -708,7 +709,7 @@ route-map RMAP permit in
match community 1
@end example
- Following exmaple filter BGP routes which has communities value 1: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.
@@ -724,7 +725,7 @@ route-map RMAP permit 10
match community FILTER
@end example
- Communities value keyword @code{internet} has special meanings in
+Communities value keyword @code{internet} has special meanings in
standard community lists. In below example @code{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 @code{INTERNET}
@@ -735,7 +736,7 @@ ip community-list standard INTERNET deny 1:1
ip community-list standard INTERNET permit internet
@end example
- Following configuration is an example of communities value deletion.
+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 @code{permit}
community-list is used. @code{deny} community-list is ignored.
@@ -755,23 +756,23 @@ route-map RMAP permit 10
@node BGP Extended Communities Attribute
@section BGP Extended Communities Attribute
- BGP extended communities attribute is introduced with MPLS VPN/BGP
+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
+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
+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
+There are two format to define Extended Community value. One is AS
based format the other is IP address based format.
@table @code
@@ -795,7 +796,7 @@ This is a format to define IP address based Extended Community value.
@node BGP Extended Community Lists
@subsection BGP Extended Community Lists
- Expanded Community Lists is a user defined BGP Expanded Community
+Expanded Community Lists is a user defined BGP Expanded Community
Lists.
@deffn Command {ip extcommunity-list standard @var{name} @{permit|deny@} @var{extcommunity}} {}
@@ -937,35 +938,38 @@ Clear peer using soft reconfiguration.
@node Capability Negotiation
@section Capability Negotiation
- When adding IPv6 routing information exchange feature to BGP. There
-were some proposals. @acronym{IETF} @acronym{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.
-
- @command{bgpd} supports Multiprotocol Extension for BGP. So if remote peer
-supports the protocol, @command{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. @cite{draft-ietf-idr-bgp4-cap-neg-04.txt} is proposing a
-feature called Capability Negotiation. @command{bgpd} use this Capability
-Negotiation to detect remote peer's capabilities. If the peer is only
-configured as IPv4 unicast neighbor, @command{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
+When adding IPv6 routing information exchange feature to BGP. There
+were some proposals. @acronym{IETF,Internet Engineering Task Force}
+@acronym{IDR, Inter Domain Routing} @acronym{WG, Working group} adopted
+a proposal called Multiprotocol Extension for BGP. The specification
+is described in @cite{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.
+
+@command{bgpd} supports Multiprotocol Extension for BGP. So if remote
+peer supports the protocol, @command{bgpd} can exchange IPv6 and/or
+multicast routing information.
+
+Traditional BGP did not have the feature to detect remote peer's
+capabilities, e.g. whether it can handle prefix types other than IPv4
+unicast routes. This was a big problem using Multiprotocol Extension
+for BGP to operational network. @cite{RFC2842, Capabilities
+Advertisement with BGP-4} adopted a feature called Capability
+Negotiation. @command{bgpd} use this Capability Negotiation to detect
+the remote peer's capabilities. If the peer is only configured as IPv4
+unicast neighbor, @command{bgpd} does not send these Capability
+Negotiation packets (at least not unless other optional BGP features
+require capability negotation).
+
+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 @command{strict-capability-match} command.
@deffn {BGP} {neighbor @var{peer} strict-capability-match} {}
@@ -974,7 +978,7 @@ Strictly compares remote capabilities and local capabilities. If capabilities
are different, send Unsupported Capability error then reset connection.
@end deffn
- You may want to disable sending Capability Negotiation OPEN message
+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 @command{dont-capability-negotiate}
command to disable the feature.
@@ -986,14 +990,15 @@ parameter to the peer. This command only affects the peer is configured
other than IPv4 unicast configuration.
@end deffn
- 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.
+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 @command{override-capability}, @command{bgpd} ignores received
-capabilities then override negotiated capabilities with configured values.
+You may prefer locally configured capabilities more than the negotiated
+capabilities even though remote peer sends capabilities. If the peer
+is configured by @command{override-capability}, @command{bgpd} ignores
+received capabilities then override negotiated capabilities with
+configured values.
@deffn {BGP} {neighbor @var{peer} override-capability} {}
@deffnx {BGP} {no neighbor @var{peer} override-capability} {}
@@ -1016,7 +1021,7 @@ Ignore remote peer's capability value.
At an Internet Exchange point, many ISPs are connected to each other by
external BGP peering. Normally these external BGP connection are done by
-@code{full mesh} method. As with internal BGP full mesh formation,
+@samp{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
@@ -1077,21 +1082,21 @@ 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
+@command{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.
+to specify @command{neighbor A.B.C.D send-community} command.
+@example
!
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
!
+@end example
@deffn {Command} {bgp config-type zebra} {}
Quagga style BGP configuration. This is default.
@@ -1247,3 +1252,233 @@ Dump BGP updates to @var{path} file.
@deffnx Command {dump bgp routes @var{path}} {}
Dump whole BGP routing table to @var{path}. This is heavy process.
@end deffn
+
+@node BGP Configuration Examples
+@section BGP Configuration Examples
+
+Example of a session to an upstream, advertising only one prefix to it.
+
+@example
+router bgp 64512
+ bgp router-id 10.236.87.1
+ network 10.236.87.0/24
+ neighbor upstream peer-group
+ neighbor upstream remote-as 64515
+ neighbor upstream capability dynamic
+ neighbor upstream prefix-list pl-allowed-adv out
+ neighbor 10.1.1.1 peer-group upstream
+ neighbor 10.1.1.1 description ACME ISP
+!
+ip prefix-list pl-allowed-adv seq 5 permit 82.195.133.0/25
+ip prefix-list pl-allowed-adv seq 10 deny any
+
+@end example
+
+A more complex example. With upstream, peer and customer sessions.
+Advertising global prefixes and NO_EXPORT prefixes and providing
+actions for customer routes based on community values. Extensive use of
+route-maps and the 'call' feature to support selective advertising of
+prefixes. This example is intended as guidance only, it has NOT been
+tested and almost certainly containts silly mistakes, if not serious
+flaws.
+
+@example
+router bgp 64512
+ bgp router-id 10.236.87.1
+ network 10.123.456.0/24
+ network 10.123.456.128/25 route-map rm-no-export
+ neighbor upstream capability dynamic
+ neighbor upstream route-map rm-upstream-out out
+ neighbor cust capability dynamic
+ neighbor cust route-map rm-cust-in in
+ neighbor cust route-map rm-cust-out out
+ neighbor cust send-community both
+ neighbor peer capability dynamic
+ neighbor peer route-map rm-peer-in in
+ neighbor peer route-map rm-peer-out out
+ neighbor peer send-community both
+ neighbor 10.1.1.1 remote-as 64515
+ neighbor 10.1.1.1 peer-group upstream
+ neighbor 10.2.1.1 remote-as 64516
+ neighbor 10.2.1.1 peer-group upstream
+ neighbor 10.3.1.1 remote-as 64517
+ neighbor 10.3.1.1 peer-group cust-default
+ neighbor 10.3.1.1 description customer1
+ neighbor 10.3.1.1 prefix-list pl-cust1-network in
+ neighbor 10.4.1.1 remote-as 64518
+ neighbor 10.4.1.1 peer-group cust
+ neighbor 10.4.1.1 prefix-list pl-cust2-network in
+ neighbor 10.4.1.1 description customer2
+ neighbor 10.5.1.1 remote-as 64519
+ neighbor 10.5.1.1 peer-group peer
+ neighbor 10.5.1.1 prefix-list pl-peer1-network in
+ neighbor 10.5.1.1 description peer AS 1
+ neighbor 10.6.1.1 remote-as 64520
+ neighbor 10.6.1.1 peer-group peer
+ neighbor 10.6.1.1 prefix-list pl-peer2-network in
+ neighbor 10.6.1.1 description peer AS 2
+!
+ip prefix-list pl-default permit 0.0.0.0/0
+!
+ip prefix-list pl-upstream-peers permit 10.1.1.1/32
+ip prefix-list pl-upstream-peers permit 10.2.1.1/32
+!
+ip prefix-list pl-cust1-network permit 10.3.1.0/24
+ip prefix-list pl-cust1-network permit 10.3.2.0/24
+!
+ip prefix-list pl-cust2-network permit 10.4.1.0/24
+!
+ip prefix-list pl-peer1-network permit 10.5.1.0/24
+ip prefix-list pl-peer1-network permit 10.5.2.0/24
+ip prefix-list pl-peer1-network permit 192.168.0.0/24
+!
+ip prefix-list pl-peer2-network permit 10.6.1.0/24
+ip prefix-list pl-peer2-network permit 10.6.2.0/24
+ip prefix-list pl-peer2-network permit 192.168.1.0/24
+ip prefix-list pl-peer2-network permit 192.168.2.0/24
+ip prefix-list pl-peer2-network permit 172.16.1/24
+!
+ip as-path access-list asp-own-as permit ^$
+ip as-path access-list asp-own-as permit _64512_
+!
+! #################################################################
+! Match communities we provide actions for, on routes receives from
+! customers. Communities values of <our-ASN>:X, with X, have actions:
+!
+! 100 - blackhole the prefix
+! 200 - set no_export
+! 300 - advertise only to other customers
+! 400 - advertise only to upstreams
+! 500 - set no_export when advertising to upstreams
+! 2X00 - set local_preference to X00
+!
+! blackhole the prefix of the route
+ip community-list standard cm-blackhole permit 64512:100
+!
+! set no-export community before advertising
+ip community-list standard cm-set-no-export permit 64512:200
+!
+! advertise only to other customers
+ip community-list standard cm-cust-only permit 64512:300
+!
+! advertise only to upstreams
+ip community-list standard cm-upstream-only permit 64512:400
+!
+! advertise to upstreams with no-export
+ip community-list standard cm-upstream-noexport permit 64512:500
+!
+! set local-pref to least significant 3 digits of the community
+ip community-list standard cm-prefmod-100 permit 64512:2100
+ip community-list standard cm-prefmod-200 permit 64512:2200
+ip community-list standard cm-prefmod-300 permit 64512:2300
+ip community-list standard cm-prefmod-400 permit 64512:2400
+ip community-list expanded cme-prefmod-range permit 64512:2...
+!
+! Informational communities
+!
+! 3000 - learned from upstream
+! 3100 - learned from customer
+! 3200 - learned from peer
+!
+ip community-list standard cm-learnt-upstream permit 64512:3000
+ip community-list standard cm-learnt-cust permit 64512:3100
+ip community-list standard cm-learnt-peer permit 64512:3200
+!
+! ###################################################################
+! Utility route-maps
+!
+! These utility route-maps generally should not used to permit/deny
+! routes, i.e. they do not have meaning as filters, and hence probably
+! should be used with 'on-match next'. These all finish with an empty
+! permit entry so as not interfere with processing in the caller.
+!
+route-map rm-no-export permit 10
+ set community additive no-export
+route-map rm-no-export permit 20
+!
+route-map rm-blackhole permit 10
+ description blackhole, up-pref and ensure it cant escape this AS
+ set ip next-hop 127.0.0.1
+ set local-preference 10
+ set community additive no-export
+route-map rm-blackhole permit 20
+!
+! Set local-pref as requested
+route-map rm-prefmod permit 10
+ match community cm-prefmod-100
+ set local-preference 100
+route-map rm-prefmod permit 20
+ match community cm-prefmod-200
+ set local-preference 200
+route-map rm-prefmod permit 30
+ match community cm-prefmod-300
+ set local-preference 300
+route-map rm-prefmod permit 40
+ match community cm-prefmod-400
+ set local-preference 400
+route-map rm-prefmod permit 50
+!
+! Community actions to take on receipt of route.
+route-map rm-community-in permit 10
+ description check for blackholing, no point continuing if it matches.
+ match community cm-blackhole
+ call rm-blackhole
+route-map rm-community-in permit 20
+ match community cm-set-no-export
+ call rm-no-export
+ on-match next
+route-map rm-community-in permit 30
+ match community cme-prefmod-range
+ call rm-prefmod
+route-map rm-community-in permit 40
+!
+! #####################################################################
+! Community actions to take when advertising a route.
+! These are filtering route-maps,
+!
+! Deny customer routes to upstream with cust-only set.
+route-map rm-community-filt-to-upstream deny 10
+ match community cm-learnt-cust
+ match community cm-cust-only
+route-map rm-community-filt-to-upstream permit 20
+!
+! Deny customer routes to other customers with upstream-only set.
+route-map rm-community-filt-to-cust deny 10
+ match community cm-learnt-cust
+ match community cm-upstream-only
+route-map rm-community-filt-to-cust permit 20
+!
+! ###################################################################
+! The top-level route-maps applied to sessions. Further entries could
+! be added obviously..
+!
+! Customers
+route-map rm-cust-in permit 10
+ call rm-community-in
+ on-match next
+route-map rm-cust-in permit 20
+ set community additive 64512:3100
+route-map rm-cust-in permit 30
+!
+route-map rm-cust-out permit 10
+ call rm-community-filt-to-cust
+ on-match next
+route-map rm-cust-out permit 20
+!
+! Upstream transit ASes
+route-map rm-upstream-out permit 10
+ description filter customer prefixes which are marked cust-only
+ call rm-community-filt-to-upstream
+ on-match next
+route-map rm-upstream-out permit 20
+ description only customer routes are provided to upstreams/peers
+ match community cm-learnt-cust
+!
+! Peer ASes
+! outbound policy is same as for upstream
+route-map rm-peer-out permit 10
+ call rm-upstream-out
+!
+route-map rm-peer-in permit 10
+ set community additive 64512:3200
+@end example
diff --git a/doc/ospf6d.texi b/doc/ospf6d.texi
index 5c5e60f3..6667221c 100644
--- a/doc/ospf6d.texi
+++ b/doc/ospf6d.texi
@@ -10,6 +10,7 @@ OSPF for IPv6 is described in RFC2740.
* OSPF6 interface::
* Redistribute routes to OSPF6::
* Showing OSPF6 information::
+* OSPF6 Configuration Examples::
@end menu
@node OSPF6 router
@@ -94,3 +95,19 @@ Shows requestlist of neighbor.
@deffn {Command} {show ipv6 route ospf6} {}
This command shows internal routing table.
@end deffn
+
+@node OSPF6 Configuration Examples
+@section OSPF6 Configuration Examples
+
+Example of ospf6d configured on one interface and area:
+
+@example
+interface eth0
+ ipv6 ospf6 instance-id 0
+!
+router ospf6
+ router-id 212.17.55.53
+ area 0.0.0.0 range 2001:770:105:2::/64
+ interface eth0 area 0.0.0.0
+!
+@end example
diff --git a/doc/quagga.info b/doc/quagga.info
index ba1ccf8d..5fa72ae2 100644
--- a/doc/quagga.info
+++ b/doc/quagga.info
@@ -2679,6 +2679,7 @@ IPv6 is described in RFC2740.
* OSPF6 interface::
* Redistribute routes to OSPF6::
* Showing OSPF6 information::
+* OSPF6 Configuration Examples::

File: quagga.info, Node: OSPF6 router, Next: OSPF6 area, Up: OSPFv3
@@ -2739,7 +2740,7 @@ File: quagga.info, Node: Redistribute routes to OSPF6, Next: Showing OSPF6 inf
-- OSPF6 Command: redistribute ripng

-File: quagga.info, Node: Showing OSPF6 information, Prev: Redistribute routes to OSPF6, Up: OSPFv3
+File: quagga.info, Node: Showing OSPF6 information, Next: OSPF6 Configuration Examples, Prev: Redistribute routes to OSPF6, Up: OSPFv3
8.5 Showing OSPF6 information
=============================
@@ -2765,6 +2766,23 @@ File: quagga.info, Node: Showing OSPF6 information, Prev: Redistribute routes
This command shows internal routing table.

+File: quagga.info, Node: OSPF6 Configuration Examples, Prev: Showing OSPF6 information, Up: OSPFv3
+
+8.6 OSPF6 Configuration Examples
+================================
+
+Example of ospf6d configured on one interface and area:
+
+ interface eth0
+ ipv6 ospf6 instance-id 0
+ !
+ router ospf6
+ router-id 212.17.55.53
+ area 0.0.0.0 range 2001:770:105:2::/64
+ interface eth0 area 0.0.0.0
+ !
+
+
File: quagga.info, Node: BGP, Next: Configuring Quagga as a Route Server, Prev: OSPFv3, Up: Top
9 BGP
@@ -2773,10 +2791,11 @@ File: quagga.info, Node: BGP, Next: Configuring Quagga as a Route Server, Pre
BGP stands for a Border Gateway Protocol. The lastest BGP version is
4. It is referred as BGP-4. BGP-4 is one of the Exterior Gateway
Protocols and de-fact standard of Inter Domain routing protocol. BGP-4
-is described in `RFC1771' - `A Border Gateway Protocol 4 (BGP-4)'.
+is described in `RFC1771, A Border Gateway Protocol 4 (BGP-4)'.
- Many extentions are added to `RFC1771'. `RFC2858' - `Multiprotocol
-Extensions for BGP-4' provide multiprotocol support to BGP-4.
+ Many extensions have been added to `RFC1771'. `RFC2858,
+Multiprotocol Extensions for BGP-4' provides multiprotocol support to
+BGP-4.
* Menu:
@@ -2795,6 +2814,7 @@ Extensions for BGP-4' provide multiprotocol support to BGP-4.
* Route Server::
* How to set up a 6-Bone connection::
* Dump BGP packets and table::
+* BGP Configuration Examples::

File: quagga.info, Node: Starting BGP, Next: BGP router, Up: BGP
@@ -3097,16 +3117,16 @@ File: quagga.info, Node: Autonomous System, Next: BGP Communities Attribute,
9.7 Autonomous System
=====================
-AS (Autonomous System) is one of the essential element of BGP. BGP is
-a distance vector routing protocol. AS framework provides distance
-vector metric and loop detection to BGP. `RFC1930' - `Guidelines for
-creation, selection, and registration of an Autonomous System (AS)'
-describes how to use AS.
+The AS (Autonomous System) number is one of the essential element of
+BGP. BGP is a distance vector routing protocol, and the AS-Path
+framework provides distance vector metric and loop detection to BGP.
+`RFC1930, Guidelines for creation, selection, and registration of an
+Autonomous System (AS)' provides some background on the concepts of an
+AS.
- AS number is tow octet digita value. So the value range is from 1
-to 65535. AS numbers 64512 through 65535 are defined as private AS
-numbers. Private AS numbers must not to be advertised in the global
-Internet.
+ The AS number is a two octet value, ranging in value from 1 to 65535.
+The AS numbers 64512 through 65535 are defined as private AS numbers.
+Private AS numbers must not to be advertised in the global Internet.
* Menu:
@@ -3207,10 +3227,10 @@ File: quagga.info, Node: BGP Communities Attribute, Next: BGP Extended Communi
BGP communities attribute is widely used for implementing policy
routing. Network operators can manipulate BGP communities attribute
based on their network policy. BGP communities attribute is defined in
-`RFC1997' - `BGP Communities Attribute' and `RFC1998' - `An Application
-of the BGP Community Attribute in Multi-home Routing'. It is an
-optional transitive attribute, therefore local policy can travel
-through different autonomous system.
+`RFC1997, BGP Communities Attribute' and `RFC1998, An Application of
+the BGP Community Attribute in Multi-home Routing'. It is an optional
+transitive attribute, therefore local policy can travel through
+different autonomous system.
Communities attribute is a set of communities values. Each
communities value is 4 octet long. The following format is used to
@@ -3699,31 +3719,33 @@ File: quagga.info, Node: Capability Negotiation, Next: Route Reflector, Prev:
===========================
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.
+were some proposals. IETF (Internet Engineering Task Force) IDR (Inter
+Domain Routing) WG (Working group) adopted 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.
+supports the protocol, `bgpd' can exchange IPv6 and/or multicast
+routing information.
+
+ Traditional BGP did not have the feature to detect remote peer's
+capabilities, e.g. whether it can handle prefix types other than IPv4
+unicast routes. This was a big problem using Multiprotocol Extension
+for BGP to operational network. `RFC2842, Capabilities Advertisement
+with BGP-4' adopted a feature called Capability Negotiation. `bgpd' use
+this Capability Negotiation to detect the remote peer's capabilities.
+If the peer is only configured as IPv4 unicast neighbor, `bgpd' does
+not send these Capability Negotiation packets (at least not unless
+other optional BGP features require capability negotation).
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
+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.
@@ -3752,9 +3774,9 @@ 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.
+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
@@ -3838,16 +3860,20 @@ M.M.M.M"
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
+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 !
+`neighbor A.B.C.D send-community' command.
- ! router bgp 1 neighbor 10.0.0.1 remote-as 1 neighbor 10.0.0.1
-send-community !
+ !
+ 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.
@@ -3979,7 +4005,7 @@ File: quagga.info, Node: How to set up a 6-Bone connection, Next: Dump BGP pac
!

-File: quagga.info, Node: Dump BGP packets and table, Prev: How to set up a 6-Bone connection, Up: BGP
+File: quagga.info, Node: Dump BGP packets and table, Next: BGP Configuration Examples, Prev: How to set up a 6-Bone connection, Up: BGP
9.15 Dump BGP packets and table
===============================
@@ -3997,6 +4023,234 @@ File: quagga.info, Node: Dump BGP packets and table, Prev: How to set up a 6-B
Dump whole BGP routing table to PATH. This is heavy process.

+File: quagga.info, Node: BGP Configuration Examples, Prev: Dump BGP packets and table, Up: BGP
+
+9.16 BGP Configuration Examples
+===============================
+
+Example of a session to an upstream, advertising only one prefix to it.
+
+ router bgp 64512
+ bgp router-id 10.236.87.1
+ network 10.236.87.0/24
+ neighbor upstream peer-group
+ neighbor upstream remote-as 64515
+ neighbor upstream capability dynamic
+ neighbor upstream prefix-list pl-allowed-adv out
+ neighbor 10.1.1.1 peer-group upstream
+ neighbor 10.1.1.1 description ACME ISP
+ !
+ ip prefix-list pl-allowed-adv seq 5 permit 82.195.133.0/25
+ ip prefix-list pl-allowed-adv seq 10 deny any
+
+ A more complex example. With upstream, peer and customer sessions.
+Advertising global prefixes and NO_EXPORT prefixes and providing
+actions for customer routes based on community values. Extensive use of
+route-maps and the 'call' feature to support selective advertising of
+prefixes. This example is intended as guidance only, it has NOT been
+tested and almost certainly containts silly mistakes, if not serious
+flaws.
+
+ router bgp 64512
+ bgp router-id 10.236.87.1
+ network 10.123.456.0/24
+ network 10.123.456.128/25 route-map rm-no-export
+ neighbor upstream capability dynamic
+ neighbor upstream route-map rm-upstream-out out
+ neighbor cust capability dynamic
+ neighbor cust route-map rm-cust-in in
+ neighbor cust route-map rm-cust-out out
+ neighbor cust send-community both
+ neighbor peer capability dynamic
+ neighbor peer route-map rm-peer-in in
+ neighbor peer route-map rm-peer-out out
+ neighbor peer send-community both
+ neighbor 10.1.1.1 remote-as 64515
+ neighbor 10.1.1.1 peer-group upstream
+ neighbor 10.2.1.1 remote-as 64516
+ neighbor 10.2.1.1 peer-group upstream
+ neighbor 10.3.1.1 remote-as 64517
+ neighbor 10.3.1.1 peer-group cust-default
+ neighbor 10.3.1.1 description customer1
+ neighbor 10.3.1.1 prefix-list pl-cust1-network in
+ neighbor 10.4.1.1 remote-as 64518
+ neighbor 10.4.1.1 peer-group cust
+ neighbor 10.4.1.1 prefix-list pl-cust2-network in
+ neighbor 10.4.1.1 description customer2
+ neighbor 10.5.1.1 remote-as 64519
+ neighbor 10.5.1.1 peer-group peer
+ neighbor 10.5.1.1 prefix-list pl-peer1-network in
+ neighbor 10.5.1.1 description peer AS 1
+ neighbor 10.6.1.1 remote-as 64520
+ neighbor 10.6.1.1 peer-group peer
+ neighbor 10.6.1.1 prefix-list pl-peer2-network in
+ neighbor 10.6.1.1 description peer AS 2
+ !
+ ip prefix-list pl-default permit 0.0.0.0/0
+ !
+ ip prefix-list pl-upstream-peers permit 10.1.1.1/32
+ ip prefix-list pl-upstream-peers permit 10.2.1.1/32
+ !
+ ip prefix-list pl-cust1-network permit 10.3.1.0/24
+ ip prefix-list pl-cust1-network permit 10.3.2.0/24
+ !
+ ip prefix-list pl-cust2-network permit 10.4.1.0/24
+ !
+ ip prefix-list pl-peer1-network permit 10.5.1.0/24
+ ip prefix-list pl-peer1-network permit 10.5.2.0/24
+ ip prefix-list pl-peer1-network permit 192.168.0.0/24
+ !
+ ip prefix-list pl-peer2-network permit 10.6.1.0/24
+ ip prefix-list pl-peer2-network permit 10.6.2.0/24
+ ip prefix-list pl-peer2-network permit 192.168.1.0/24
+ ip prefix-list pl-peer2-network permit 192.168.2.0/24
+ ip prefix-list pl-peer2-network permit 172.16.1/24
+ !
+ ip as-path access-list asp-own-as permit ^$
+ ip as-path access-list asp-own-as permit _64512_
+ !
+ ! #################################################################
+ ! Match communities we provide actions for, on routes receives from
+ ! customers. Communities values of <our-ASN>:X, with X, have actions:
+ !
+ ! 100 - blackhole the prefix
+ ! 200 - set no_export
+ ! 300 - advertise only to other customers
+ ! 400 - advertise only to upstreams
+ ! 500 - set no_export when advertising to upstreams
+ ! 2X00 - set local_preference to X00
+ !
+ ! blackhole the prefix of the route
+ ip community-list standard cm-blackhole permit 64512:100
+ !
+ ! set no-export community before advertising
+ ip community-list standard cm-set-no-export permit 64512:200
+ !
+ ! advertise only to other customers
+ ip community-list standard cm-cust-only permit 64512:300
+ !
+ ! advertise only to upstreams
+ ip community-list standard cm-upstream-only permit 64512:400
+ !
+ ! advertise to upstreams with no-export
+ ip community-list standard cm-upstream-noexport permit 64512:500
+ !
+ ! set local-pref to least significant 3 digits of the community
+ ip community-list standard cm-prefmod-100 permit 64512:2100
+ ip community-list standard cm-prefmod-200 permit 64512:2200
+ ip community-list standard cm-prefmod-300 permit 64512:2300
+ ip community-list standard cm-prefmod-400 permit 64512:2400
+ ip community-list expanded cme-prefmod-range permit 64512:2...
+ !
+ ! Informational communities
+ !
+ ! 3000 - learned from upstream
+ ! 3100 - learned from customer
+ ! 3200 - learned from peer
+ !
+ ip community-list standard cm-learnt-upstream permit 64512:3000
+ ip community-list standard cm-learnt-cust permit 64512:3100
+ ip community-list standard cm-learnt-peer permit 64512:3200
+ !
+ ! ###################################################################
+ ! Utility route-maps
+ !
+ ! These utility route-maps generally should not used to permit/deny
+ ! routes, i.e. they do not have meaning as filters, and hence probably
+ ! should be used with 'on-match next'. These all finish with an empty
+ ! permit entry so as not interfere with processing in the caller.
+ !
+ route-map rm-no-export permit 10
+ set community additive no-export
+ route-map rm-no-export permit 20
+ !
+ route-map rm-blackhole permit 10
+ description blackhole, up-pref and ensure it cant escape this AS
+ set ip next-hop 127.0.0.1
+ set local-preference 10
+ set community additive no-export
+ route-map rm-blackhole permit 20
+ !
+ ! Set local-pref as requested
+ route-map rm-prefmod permit 10
+ match community cm-prefmod-100
+ set local-preference 100
+ route-map rm-prefmod permit 20
+ match community cm-prefmod-200
+ set local-preference 200
+ route-map rm-prefmod permit 30
+ match community cm-prefmod-300
+ set local-preference 300
+ route-map rm-prefmod permit 40
+ match community cm-prefmod-400
+ set local-preference 400
+ route-map rm-prefmod permit 50
+ !
+ ! Community actions to take on receipt of route.
+ route-map rm-community-in permit 10
+ description check for blackholing, no point continuing if it matches.
+ match community cm-blackhole
+ call rm-blackhole
+ route-map rm-community-in permit 20
+ match community cm-set-no-export
+ call rm-no-export
+ on-match next
+ route-map rm-community-in permit 30
+ match community cme-prefmod-range
+ call rm-prefmod
+ route-map rm-community-in permit 40
+ !
+ ! #####################################################################
+ ! Community actions to take when advertising a route.
+ ! These are filtering route-maps,
+ !
+ ! Deny customer routes to upstream with cust-only set.
+ route-map rm-community-filt-to-upstream deny 10
+ match community cm-learnt-cust
+ match community cm-cust-only
+ route-map rm-community-filt-to-upstream permit 20
+ !
+ ! Deny customer routes to other customers with upstream-only set.
+ route-map rm-community-filt-to-cust deny 10
+ match community cm-learnt-cust
+ match community cm-upstream-only
+ route-map rm-community-filt-to-cust permit 20
+ !
+ ! ###################################################################
+ ! The top-level route-maps applied to sessions. Further entries could
+ ! be added obviously..
+ !
+ ! Customers
+ route-map rm-cust-in permit 10
+ call rm-community-in
+ on-match next
+ route-map rm-cust-in permit 20
+ set community additive 64512:3100
+ route-map rm-cust-in permit 30
+ !
+ route-map rm-cust-out permit 10
+ call rm-community-filt-to-cust
+ on-match next
+ route-map rm-cust-out permit 20
+ !
+ ! Upstream transit ASes
+ route-map rm-upstream-out permit 10
+ description filter customer prefixes which are marked cust-only
+ call rm-community-filt-to-upstream
+ on-match next
+ route-map rm-upstream-out permit 20
+ description only customer routes are provided to upstreams/peers
+ match community cm-learnt-cust
+ !
+ ! Peer ASes
+ ! outbound policy is same as for upstream
+ route-map rm-peer-out permit 10
+ call rm-upstream-out
+ !
+ route-map rm-peer-in permit 10
+ set community additive 64512:3200
+
+
File: quagga.info, Node: Configuring Quagga as a Route Server, Next: VTY shell, Prev: BGP, Up: Top
10 Configuring Quagga as a Route Server
@@ -4793,21 +5047,97 @@ File: quagga.info, Node: Route Map, Next: IPv6 Support, Prev: Filtering, Up:
13 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.
+Route maps provide a means to both filter and/or apply actions to
+route, hence allowing policy to be applied to routes.
* Menu:
* Route Map Command::
* Route Map Match Command::
* Route Map Set Command::
+* Route Map Call Command::
+* Route Map Exit Action Command::
+* Route Map Examples::
+
+ Route-maps are an ordered list of route-map entries. Each entry may
+specify up to four distincts sets of clauses:
+
+`Matching Policy'
+ This specifies the policy implied if the `Matching Conditions' are
+ met or not met, and which actions of the route-map are to be
+ taken, if any. The two possibilities are:
+
+ - `permit': If the entry matches, then carry out the `Set
+ Actions'. Then finish processing the route-map, permitting
+ the route, unless an `Exit Action' indicates otherwise.
+
+ - `deny': If the entry matches, then finish processing the
+ route-map and deny the route (return `deny').
+
+ The `Matching Policy' is specified as part of the command which
+ defines the ordered entry in the route-map. See below.
+
+`Matching Conditions'
+ A route-map entry may, optionally, specify one or more conditions
+ which must be matched if the entry is to be considered further, as
+ governed by the Match Policy. If a route-map entry does not
+ explicitely specify any matching conditions, then it always
+ matches.
+
+`Set Actions'
+ A route-map entry may, optionally, specify one or more `Set
+ Actions' to set or modify attributes of the route.
+
+`Call Action'
+ Call to another route-map, after any `Set Actions' have been
+ carried out. If the route-map called returns `deny' then
+ processing of the route-map finishes and the route is denied,
+ regardless of the `Matching Policy' or the `Exit Policy'. If the
+ called route-map returns `permit', then `Matching Policy' and
+ `Exit Policy' govern further behaviour, as normal.
+
+`Exit Policy'
+ An entry may, optionally, specify an alternative `Exit Policy' to
+ take if the entry matched, rather than the normal policy of
+ exiting the route-map and permitting the route. The two
+ possibilities are:
+
+ - `next': Continue on with processing of the route-map entries.
+
+ - `goto N': Jump ahead to the first route-map entry whose order
+ in the route-map is >= N. Jumping to a previous entry is not
+ permitted.
+
+ The default action of a route-map, if no entries match, is to deny.
+I.e. a route-map essentially has as its last entry an empty `deny'
+entry, which matches all routes. To change this behaviour, one must
+specify an empty `permit' entry as the last entry in the route-map.
+
+ To summarise the above:
+
+ Match No Match
+-----------------------------
+_Permit_ action cont
+_Deny_ deny cont
+
+`action'
+ - Apply _set_ statements
+
+ - If _call_ is present, call given route-map. If that returns a
+ `deny', finish processing and return `deny'.
+
+ - If `Exit Policy' is _next_, goto next route-map entry
+
+ - If `Exit Policy' is _goto_, goto first entry whose order in
+ the list is >= the given order.
+
+ - Finish processing the route-map and permit the route.
+
+`deny'
+ - The route is denied by the route-map (return `deny').
+
+`cont'
+ - goto next route-map entry

File: quagga.info, Node: Route Map Command, Next: Route Map Match Command, Up: Route Map
@@ -4815,7 +5145,10 @@ File: quagga.info, Node: Route Map Command, Next: Route Map Match Command, Up
13.1 Route Map Command
======================
- -- Command: route-map ROUTE-MAP-NAME permit PRIORITY
+ -- Command: route-map ROUTE-MAP-NAME (permit|deny) ORDER
+ Configure the ORDER'th entry in ROUTE-MAP-NAME with `Match Policy'
+ of either _permit_ or _deny_.
+

File: quagga.info, Node: Route Map Match Command, Next: Route Map Set Command, Prev: Route Map Command, Up: Route Map
@@ -4839,7 +5172,7 @@ File: quagga.info, Node: Route Map Match Command, Next: Route Map Set Command,
Matches the specified COMMUNITY_LIST

-File: quagga.info, Node: Route Map Set Command, Prev: Route Map Match Command, Up: Route Map
+File: quagga.info, Node: Route Map Set Command, Next: Route Map Call Command, Prev: Route Map Match Command, Up: Route Map
13.3 Route Map Set Command
==========================
@@ -4869,6 +5202,49 @@ File: quagga.info, Node: Route Map Set Command, Prev: Route Map Match Command,
Set the BGP-4+ link local IPv6 nexthop address.

+File: quagga.info, Node: Route Map Call Command, Next: Route Map Exit Action Command, Prev: Route Map Set Command, Up: Route Map
+
+13.4 Route Map Call Command
+===========================
+
+ -- Route-map Command: call NAME
+ Call route-map NAME. If it returns deny, deny the route and finish
+ processing the route-map.
+
+
+File: quagga.info, Node: Route Map Exit Action Command, Next: Route Map Examples, Prev: Route Map Call Command, Up: Route Map
+
+13.5 Route Map Exit Action Command
+==================================
+
+ -- Route-map Command: on-match next
+ -- Route-map Command: continue
+ Proceed on to the next entry in the route-map.
+
+ -- Route-map Command: on-match goto N
+ -- Route-map Command: continue N
+ Proceed processing the route-map at the first entry whose order is
+ >= N
+
+
+File: quagga.info, Node: Route Map Examples, Prev: Route Map Exit Action Command, Up: Route Map
+
+13.6 Route Map Examples
+=======================
+
+A simple example of 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.
+
+ See *Note BGP Configuration Examples:: for examples of more
+sophisticated useage of route-maps, including of the `call' action.
+
+
File: quagga.info, Node: IPv6 Support, Next: Kernel Interface, Prev: Route Map, Up: Top
14 IPv6 Support
@@ -5699,9 +6075,11 @@ Command Index
(line 19)
* bgp cluster-id A.B.C.D: Route Reflector. (line 7)
* bgp config-type cisco: Multiple instance. (line 20)
-* bgp config-type zebra: Multiple instance. (line 49)
+* bgp config-type zebra: Multiple instance. (line 53)
* bgp multiple-instance: Multiple instance. (line 10)
* bgp router-id A.B.C.D: BGP router. (line 22)
+* call NAME: Route Map Call Command.
+ (line 7)
* call WORD: Commands for configuring a Route Server.
(line 52)
* clear ip bgp PEER: More Show IP BGP. (line 25)
@@ -5714,6 +6092,10 @@ Command Index
(line 13)
* configure terminal: Terminal Mode Commands.
(line 13)
+* continue: Route Map Exit Action Command.
+ (line 8)
+* continue N: Route Map Exit Action Command.
+ (line 12)
* debug event: More Show IP BGP. (line 33)
* debug keepalive: More Show IP BGP. (line 37)
* debug ospf ism: Debugging OSPF. (line 12)
@@ -5955,14 +6337,14 @@ Command Index
* neighbor PEER distribute-list NAME [in|out]: Peer filtering.
(line 7)
* neighbor PEER dont-capability-negotiate: Capability Negotiation.
- (line 49)
+ (line 51)
* neighbor PEER ebgp-multihop: BGP Peer commands. (line 17)
* neighbor PEER filter-list NAME [in|out]: Peer filtering. (line 13)
* neighbor PEER interface IFNAME: BGP Peer commands. (line 33)
* neighbor PEER maximum-prefix NUMBER: BGP Peer commands. (line 64)
* neighbor PEER next-hop-self: BGP Peer commands. (line 39)
* neighbor PEER override-capability: Capability Negotiation.
- (line 65)
+ (line 67)
* neighbor PEER peer-group WORD: BGP Peer Group. (line 10)
* neighbor PEER port PORT: BGP Peer commands. (line 53)
* neighbor PEER prefix-list NAME [in|out]: Peer filtering. (line 11)
@@ -5972,7 +6354,7 @@ Command Index
* neighbor PEER send-community: BGP Peer commands. (line 56)
* neighbor PEER shutdown: BGP Peer commands. (line 10)
* neighbor PEER strict-capability-match: Capability Negotiation.
- (line 38)
+ (line 40)
* neighbor PEER update-source: BGP Peer commands. (line 44)
* neighbor PEER version VERSION: BGP Peer commands. (line 24)
* neighbor PEER weight WEIGHT: BGP Peer commands. (line 59)
@@ -6133,17 +6515,17 @@ Command Index
* no neighbor PEER default-originate: BGP Peer commands. (line 48)
* no neighbor PEER description ...: BGP Peer commands. (line 21)
* no neighbor PEER dont-capability-negotiate: Capability Negotiation.
- (line 50)
+ (line 52)
* no neighbor PEER ebgp-multihop: BGP Peer commands. (line 18)
* no neighbor PEER interface IFNAME: BGP Peer commands. (line 34)
* no neighbor PEER maximum-prefix NUMBER: BGP Peer commands. (line 65)
* no neighbor PEER next-hop-self: BGP Peer commands. (line 40)
* no neighbor PEER override-capability: Capability Negotiation.
- (line 66)
+ (line 68)
* no neighbor PEER route-reflector-client: Route Reflector. (line 10)
* no neighbor PEER shutdown: BGP Peer commands. (line 11)
* no neighbor PEER strict-capability-match: Capability Negotiation.
- (line 39)
+ (line 41)
* no neighbor PEER update-source: BGP Peer commands. (line 45)
* no neighbor PEER weight WEIGHT: BGP Peer commands. (line 60)
* no network A.B.C.D/M: BGP route. (line 17)
@@ -6186,6 +6568,10 @@ Command Index
(line 20)
* offset-list ACCESS-LIST (in|out) IFNAME: RIP Metric Manipulation.
(line 21)
+* on-match goto N: Route Map Exit Action Command.
+ (line 11)
+* on-match next: Route Map Exit Action Command.
+ (line 7)
* ospf abr-type TYPE: OSPF router. (line 26)
* ospf rfc1583compatibility: OSPF router. (line 48)
* ospf router-id A.B.C.D: OSPF router. (line 16)
@@ -6254,7 +6640,7 @@ Command Index
(line 53)
* route NETWORK: ripngd Configuration.
(line 21)
-* route-map ROUTE-MAP-NAME permit PRIORITY: Route Map Command.
+* route-map ROUTE-MAP-NAME (permit|deny) ORDER: Route Map Command.
(line 7)
* router bgp AS-NUMBER: BGP instance and view.
(line 11)
@@ -6573,93 +6959,98 @@ Ref: show ip ospf92634
Node: Debugging OSPF93965
Node: OSPF Configuration Examples95040
Node: OSPFv396410
-Node: OSPF6 router96730
-Node: OSPF6 area97084
-Node: OSPF6 interface97262
-Node: Redistribute routes to OSPF698139
-Node: Showing OSPF6 information98455
-Node: BGP99275
-Node: Starting BGP100165
-Node: BGP router100742
-Node: BGP distance101986
-Node: BGP decision process102424
-Node: BGP network102906
-Node: BGP route103096
-Node: Route Aggregation103652
-Node: Redistribute to BGP104221
-Node: BGP Peer104748
-Node: Defining Peer104935
-Node: BGP Peer commands105548
-Node: Peer filtering107952
-Node: BGP Peer Group108460
-Node: BGP Address Family108773
-Node: Autonomous System108927
-Node: AS Path Regular Expression109764
-Node: Display BGP Routes by AS Path111011
-Node: AS Path Access List111451
-Node: Using AS Path in Route Map111918
-Node: Private AS Numbers112199
-Node: BGP Communities Attribute112357
-Node: BGP Community Lists114824
-Node: Numbered BGP Community Lists117478
-Node: BGP Community in Route Map119065
-Node: Display BGP Routes by Community121008
-Node: Using BGP Communities Attribute122177
-Node: BGP Extended Communities Attribute125745
-Node: BGP Extended Community Lists127517
-Node: BGP Extended Communities in Route Map129392
-Node: Displaying BGP routes129851
-Node: Show IP BGP130088
-Node: More Show IP BGP130788
-Node: Capability Negotiation131939
-Node: Route Reflector135243
-Node: Route Server135522
-Node: Multiple instance136588
-Node: BGP instance and view138399
-Node: Routing policy139779
-Node: Viewing the view140547
-Node: How to set up a 6-Bone connection140832
-Node: Dump BGP packets and table142204
-Node: Configuring Quagga as a Route Server142751
-Node: Description of the Route Server model143712
-Ref: fig:normal-processing145289
-Ref: fig:full-mesh145358
-Ref: fig:route-server145383
-Ref: filter-delegation145725
-Ref: Route Server tasks146909
-Ref: Route-server path filter process147280
-Ref: fig:rs-processing149594
-Node: Commands for configuring a Route Server149747
-Node: Example of Route Server Configuration152774
-Node: Configuration of the BGP routers without Route Server153695
-Node: Configuration of the BGP routers with Route Server156578
-Node: Configuration of the Route Server itself157879
-Node: Further considerations about Import and Export route-maps162878
-Node: VTY shell165922
-Node: VTY shell username166591
-Node: VTY shell integrated configuration167223
-Node: Filtering168671
-Node: IP Access List169024
-Node: IP Prefix List169410
-Node: ip prefix-list description172429
-Node: ip prefix-list sequential number control172956
-Node: Showing ip prefix-list173498
-Node: Clear counter of ip prefix-list174606
-Node: Route Map175045
-Node: Route Map Command175550
-Node: Route Map Match Command175747
-Node: Route Map Set Command176371
-Node: IPv6 Support177248
-Node: Router Advertisement177820
-Node: Kernel Interface183436
-Node: SNMP Support185393
-Node: Getting and installing an SNMP agent185992
-Node: SMUX configuration186565
-Node: MIB and command reference188701
-Node: Handling SNMP Traps190116
-Node: Zebra Protocol196195
-Node: Packet Binary Dump Format198109
-Node: Command Index209719
-Node: VTY Key Index267658
+Node: OSPF6 router96763
+Node: OSPF6 area97117
+Node: OSPF6 interface97295
+Node: Redistribute routes to OSPF698172
+Node: Showing OSPF6 information98488
+Node: OSPF6 Configuration Examples99345
+Node: BGP99766
+Node: Starting BGP100688
+Node: BGP router101265
+Node: BGP distance102509
+Node: BGP decision process102947
+Node: BGP network103429
+Node: BGP route103619
+Node: Route Aggregation104175
+Node: Redistribute to BGP104744
+Node: BGP Peer105271
+Node: Defining Peer105458
+Node: BGP Peer commands106071
+Node: Peer filtering108475
+Node: BGP Peer Group108983
+Node: BGP Address Family109296
+Node: Autonomous System109450
+Node: AS Path Regular Expression110327
+Node: Display BGP Routes by AS Path111574
+Node: AS Path Access List112014
+Node: Using AS Path in Route Map112481
+Node: Private AS Numbers112762
+Node: BGP Communities Attribute112920
+Node: BGP Community Lists115381
+Node: Numbered BGP Community Lists118035
+Node: BGP Community in Route Map119622
+Node: Display BGP Routes by Community121565
+Node: Using BGP Communities Attribute122734
+Node: BGP Extended Communities Attribute126302
+Node: BGP Extended Community Lists128074
+Node: BGP Extended Communities in Route Map129949
+Node: Displaying BGP routes130408
+Node: Show IP BGP130645
+Node: More Show IP BGP131345
+Node: Capability Negotiation132496
+Node: Route Reflector135968
+Node: Route Server136247
+Node: Multiple instance137313
+Node: BGP instance and view139158
+Node: Routing policy140538
+Node: Viewing the view141306
+Node: How to set up a 6-Bone connection141591
+Node: Dump BGP packets and table142963
+Node: BGP Configuration Examples143545
+Node: Configuring Quagga as a Route Server152496
+Node: Description of the Route Server model153457
+Ref: fig:normal-processing155034
+Ref: fig:full-mesh155103
+Ref: fig:route-server155128
+Ref: filter-delegation155470
+Ref: Route Server tasks156654
+Ref: Route-server path filter process157025
+Ref: fig:rs-processing159339
+Node: Commands for configuring a Route Server159492
+Node: Example of Route Server Configuration162519
+Node: Configuration of the BGP routers without Route Server163440
+Node: Configuration of the BGP routers with Route Server166323
+Node: Configuration of the Route Server itself167624
+Node: Further considerations about Import and Export route-maps172623
+Node: VTY shell175667
+Node: VTY shell username176336
+Node: VTY shell integrated configuration176968
+Node: Filtering178416
+Node: IP Access List178769
+Node: IP Prefix List179155
+Node: ip prefix-list description182174
+Node: ip prefix-list sequential number control182701
+Node: Showing ip prefix-list183243
+Node: Clear counter of ip prefix-list184351
+Node: Route Map184790
+Node: Route Map Command188235
+Node: Route Map Match Command188544
+Node: Route Map Set Command189168
+Node: Route Map Call Command190076
+Node: Route Map Exit Action Command190406
+Node: Route Map Examples190888
+Node: IPv6 Support191400
+Node: Router Advertisement191972
+Node: Kernel Interface197588
+Node: SNMP Support199545
+Node: Getting and installing an SNMP agent200144
+Node: SMUX configuration200717
+Node: MIB and command reference202853
+Node: Handling SNMP Traps204268
+Node: Zebra Protocol210347
+Node: Packet Binary Dump Format212261
+Node: Command Index223871
+Node: VTY Key Index282532

End Tag Table
diff --git a/doc/routemap.texi b/doc/routemap.texi
index 11351a49..db3e72d2 100644
--- a/doc/routemap.texi
+++ b/doc/routemap.texi
@@ -1,30 +1,135 @@
@node Route Map
@chapter Route Map
-Route map is a very useful function in zebra. There is a match and set
-statement permitted in a route map.
-
-@example
-@group
-route-map test permit 10
- match ip address 10
- set local-preference 200
-@end group
-@end example
-
-This means that if a route matches ip access-list number 10 it's
-local-preference value is set to 200.
+Route maps provide a means to both filter and/or apply actions to
+route, hence allowing policy to be applied to routes.
@menu
* Route Map Command::
* Route Map Match Command::
-* Route Map Set Command::
+* Route Map Set Command::
+* Route Map Call Command::
+* Route Map Exit Action Command::
+* Route Map Examples::
@end menu
+Route-maps are an ordered list of route-map entries. Each entry may
+specify up to four distincts sets of clauses:
+
+@table @samp
+@item Matching Policy
+
+This specifies the policy implied if the @samp{Matching Conditions} are
+met or not met, and which actions of the route-map are to be taken, if
+any. The two possibilities are:
+
+@itemize @minus
+@item
+@samp{permit}: If the entry matches, then carry out the @samp{Set
+Actions}. Then finish processing the route-map, permitting the route,
+unless an @samp{Exit Action} indicates otherwise.
+
+@item
+@samp{deny}: If the entry matches, then finish processing the route-map and
+deny the route (return @samp{deny}).
+@end itemize
+
+The @samp{Matching Policy} is specified as part of the command which
+defines the ordered entry in the route-map. See below.
+
+@item Matching Conditions
+
+A route-map entry may, optionally, specify one or more conditions which
+must be matched if the entry is to be considered further, as governed
+by the Match Policy. If a route-map entry does not explicitely specify
+any matching conditions, then it always matches.
+
+@item Set Actions
+
+A route-map entry may, optionally, specify one or more @samp{Set
+Actions} to set or modify attributes of the route.
+
+@item Call Action
+
+Call to another route-map, after any @samp{Set Actions} have been
+carried out. If the route-map called returns @samp{deny} then
+processing of the route-map finishes and the route is denied,
+regardless of the @samp{Matching Policy} or the @samp{Exit Policy}. If
+the called route-map returns @samp{permit}, then @samp{Matching Policy}
+and @samp{Exit Policy} govern further behaviour, as normal.
+
+@item Exit Policy
+
+An entry may, optionally, specify an alternative @samp{Exit Policy} to
+take if the entry matched, rather than the normal policy of exiting the
+route-map and permitting the route. The two possibilities are:
+
+@itemize @minus
+@item
+@samp{next}: Continue on with processing of the route-map entries.
+
+@item
+@samp{goto N}: Jump ahead to the first route-map entry whose order in
+the route-map is >= N. Jumping to a previous entry is not permitted.
+@end itemize
+@end table
+
+The default action of a route-map, if no entries match, is to deny.
+I.e. a route-map essentially has as its last entry an empty @samp{deny}
+entry, which matches all routes. To change this behaviour, one must
+specify an empty @samp{permit} entry as the last entry in the route-map.
+
+To summarise the above:
+
+@multitable {permit} {action} {No Match}
+@headitem @tab Match @tab No Match
+@item @emph{Permit} @tab action @tab cont
+@item @emph{Deny} @tab deny @tab cont
+@end multitable
+
+@table @samp
+
+@item action
+@itemize @minus
+@item
+Apply @emph{set} statements
+
+@item
+If @emph{call} is present, call given route-map. If that returns a @samp{deny}, finish
+processing and return @samp{deny}.
+
+@item
+If @samp{Exit Policy} is @emph{next}, goto next route-map entry
+
+@item
+If @samp{Exit Policy} is @emph{goto}, goto first entry whose order in the list
+is >= the given order.
+
+@item
+Finish processing the route-map and permit the route.
+@end itemize
+
+@item deny
+@itemize @minus
+@item
+The route is denied by the route-map (return @samp{deny}).
+@end itemize
+
+@item cont
+@itemize @minus
+@item
+goto next route-map entry
+@end itemize
+@end table
+
@node Route Map Command
@section Route Map Command
-@deffn {Command} {route-map @var{route-map-name} permit @var{priority}} {}
+@deffn {Command} {route-map @var{route-map-name} (permit|deny) @var{order}} {}
+
+Configure the @var{order}'th entry in @var{route-map-name} with
+@samp{Match Policy} of either @emph{permit} or @emph{deny}.
+
@end deffn
@node Route Map Match Command
@@ -85,3 +190,42 @@ Set the BGP-4+ global IPv6 nexthop address.
Set the BGP-4+ link local IPv6 nexthop address.
@end deffn
+@node Route Map Call Command
+@section Route Map Call Command
+
+@deffn {Route-map Command} {call @var{name}} {}
+Call route-map @var{name}. If it returns deny, deny the route and
+finish processing the route-map.
+@end deffn
+
+@node Route Map Exit Action Command
+@section Route Map Exit Action Command
+
+@deffn {Route-map Command} {on-match next} {}
+@deffnx {Route-map Command} {continue} {}
+Proceed on to the next entry in the route-map.
+@end deffn
+
+@deffn {Route-map Command} {on-match goto @var{N}} {}
+@deffnx {Route-map Command} {continue @var{N}} {}
+Proceed processing the route-map at the first entry whose order is >= N
+@end deffn
+
+@node Route Map Examples
+@section Route Map Examples
+
+A simple example of a route-map:
+
+@example
+@group
+route-map test permit 10
+ match ip address 10
+ set local-preference 200
+@end group
+@end example
+
+This means that if a route matches ip access-list number 10 it's
+local-preference value is set to 200.
+
+See @ref{BGP Configuration Examples} for examples of more sophisticated
+useage of route-maps, including of the @samp{call} action.
generated by cgit v1.2.1 (git 2.18.0) at 2024-11-04 21:25:20 +0000