proxmox-mirrors/mirror_frr
1
0
Fork 0
mirror of https://git.proxmox.com/git/mirror_frr synced 2025-05-02 16:57:25 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

2005-11-04 Paul Jakma <paul.jakma@sun.com>

Browse Source 
* quagga.info: Update auto-built file
	* ospf6d.texi: Add example config
	* bgpd.texi: 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.
This commit is contained in:
paul 2005-11-04 21:53:59 +00:00
parent a3957e3838
commit aa5943f771
5 changed files with 1035 additions and 243 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
doc/ChangeLog
View File

@ -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>

385
doc/bgpd.texi
View File

@ -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.
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.
@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.
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.
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
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

17
doc/ospf6d.texi
View File

@ -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

697
doc/quagga.info
View File

@ -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
=============================
@ -2764,6 +2765,23 @@ File: quagga.info, Node: Showing OSPF6 information, Prev: Redistribute routes
-- Command: show ipv6 route ospf6
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
@ -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.
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.
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.
`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 !
!
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
===============================
@ -3996,6 +4022,234 @@ File: quagga.info, Node: Dump BGP packets and table, Prev: How to set up a 6-B
-- Command: dump bgp routes PATH
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
@ -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
==========================
@ -4868,6 +5201,49 @@ File: quagga.info, Node: Route Map Set Command, Prev: Route Map Match Command,
-- Route-map Command: set ipv6 next-hop local IPV6_ADDRESS
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
@ -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

174
doc/routemap.texi
View File

@ -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.