proxmox-mirrors/mirror_frr
1
0
Fork 0
mirror of https://git.proxmox.com/git/mirror_frr synced 2025-06-15 15:04:00 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

doc: fix more broken refs, restore routeserver.rst

Browse Source 
At some point the routeserver docs got lost, converted those from texi
and put them back. Also fixed some broken cli xrefs.

Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
This commit is contained in:
Quentin Young 2018-02-01 17:38:05 -05:00
parent 0efdf0fe50
commit 9e146a818b
No known key found for this signature in database
GPG Key ID: DAF48E0F57E0834F
4 changed files with 560 additions and 34 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

44
doc/user/bgp.rst
View File

@ -141,7 +141,7 @@ The decision process FRR BGP uses to select routes is as follows:
If multi-pathing is enabled, then check whether the routes not yet If multi-pathing is enabled, then check whether the routes not yet
distinguished in preference may be considered equal. If distinguished in preference may be considered equal. If
:ref:`bgp-bestpath-as-path-multipath-relax` is set, all such routes are :clicmd:`bgp bestpath as-path multipath-relax` is set, all such routes are
considered equal, otherwise routes received via iBGP with identical AS_PATHs considered equal, otherwise routes received via iBGP with identical AS_PATHs
or routes received from eBGP neighbours in the same AS are considered equal. or routes received from eBGP neighbours in the same AS are considered equal.
@ -149,8 +149,8 @@ The decision process FRR BGP uses to select routes is as follows:
Where both routes were received from eBGP peers, then prefer the route Where both routes were received from eBGP peers, then prefer the route
which is already selected. Note that this check is not applied if which is already selected. Note that this check is not applied if
:ref:`bgp-bestpath-compare-routerid` is configured. This check can prevent :clicmd:`bgp bestpath compare-routerid` is configured. This check can
some cases of oscillation. prevent some cases of oscillation.
11. Router-ID check 11. Router-ID check
@ -178,7 +178,6 @@ The decision process FRR BGP uses to select routes is as follows:
sequences should should be taken into account during the BGP best path sequences should should be taken into account during the BGP best path
decision process. decision process.
.. _bgp-bestpath-as-path-multipath-relax:
.. index:: bgp bestpath as-path multipath-relax .. index:: bgp bestpath as-path multipath-relax
.. clicmd:: bgp bestpath as-path multipath-relax .. clicmd:: bgp bestpath as-path multipath-relax
@ -186,7 +185,6 @@ The decision process FRR BGP uses to select routes is as follows:
of equal AS_PATH length candidates for multipath computation. Without of equal AS_PATH length candidates for multipath computation. Without
the knob, the entire AS_PATH must match for multipath computation. the knob, the entire AS_PATH must match for multipath computation.
.. _bgp-bestpath-compare-routerid:
.. clicmd:: bgp bestpath compare-routerid .. clicmd:: bgp bestpath compare-routerid
Ensure that when comparing routes where both are equal on most metrics, Ensure that when comparing routes where both are equal on most metrics,
@ -312,7 +310,7 @@ updates may be produced than at other times in reaction to some event .
This first issue can be fixed with a more deterministic route selection that This first issue can be fixed with a more deterministic route selection that
ensures routes are ordered by the neighbouring AS during selection. ensures routes are ordered by the neighbouring AS during selection.
:ref:`bgp-deterministic-med`. This may reduce the number of updates as routes :clicmd:`bgp deterministic-med`. This may reduce the number of updates as routes
are received, and may in some cases reduce routing churn. Though, it could are received, and may in some cases reduce routing churn. Though, it could
equally deterministically produce the largest possible set of updates in equally deterministically produce the largest possible set of updates in
response to the most common sequence of received updates. response to the most common sequence of received updates.
@ -389,8 +387,8 @@ avoided by speakers preferring already selected, external routes rather than
choosing to update to new a route based on a post-MED metric (e.g. router-ID), choosing to update to new a route based on a post-MED metric (e.g. router-ID),
at the cost of a non-deterministic selection process. FRR implements this, as at the cost of a non-deterministic selection process. FRR implements this, as
do many other implementations, so long as it is not overridden by setting do many other implementations, so long as it is not overridden by setting
:ref:`bgp-bestpath-compare-routerid`, and see also :ref:`bgp-decision-process`, :clicmd:`bgp bestpath compare-routerid`, and see also
. :ref:`bgp-decision-process`.
However, more complex and insidious cycles of oscillation are possible with However, more complex and insidious cycles of oscillation are possible with
iBGP route-reflection, which are not so easily avoided. These have been iBGP route-reflection, which are not so easily avoided. These have been
@ -442,8 +440,6 @@ topologies are at cross-purposes with each other - see the Flavel and Roughan
paper above for an example. Hence the guideline that the iBGP topology should paper above for an example. Hence the guideline that the iBGP topology should
follow the IGP topology. follow the IGP topology.
.. _bgp-deterministic-med:
.. index:: bgp deterministic-med .. index:: bgp deterministic-med
.. clicmd:: bgp deterministic-med .. clicmd:: bgp deterministic-med
@ -464,8 +460,6 @@ Note that there are other sources of indeterminism in the route selection
process, specifically, the preference for older and already selected routes process, specifically, the preference for older and already selected routes
from eBGP peers, :ref:`bgp-decision-process`. from eBGP peers, :ref:`bgp-decision-process`.
.. _bgp-always-compare-med:
.. index:: bgp always-compare-med .. index:: bgp always-compare-med
.. clicmd:: bgp always-compare-med .. clicmd:: bgp always-compare-med
@ -475,12 +469,12 @@ from eBGP peers, :ref:`bgp-decision-process`.
oscillations. oscillations.
If using this option, it may also be desirable to use If using this option, it may also be desirable to use
:ref:`routemap-set-metric` to set MED to 0 on routes received from external :clicmd:`set metric METRIC` to set MED to 0 on routes received from external
neighbours. neighbours.
This option can be used, together with :ref:`routemap-set-metric` to use MED This option can be used, together with :clicmd:`set metric METRIC` to use
as an intra-AS metric to steer equal-length AS_PATH routes to, e.g., desired MED as an intra-AS metric to steer equal-length AS_PATH routes to, e.g.,
exit points. desired exit points.
.. _bgp-network: .. _bgp-network:
@ -2298,23 +2292,7 @@ flaws.
route-map rm-peer-in permit 10 route-map rm-peer-in permit 10
set community additive 64512:3200 set community additive 64512:3200
.. include:: routeserver.rst
.. _configuring-frr-as-a-route-server:
Configuring FRR as a Route Server
=================================
The purpose of a Route Server is to centralize the peerings between BGP
speakers. For example if we have an exchange point scenario with four BGP
speakers, each of which maintaining a BGP peering with the other three
(:ref:`fig:full-mesh`), we can convert it into a centralized scenario where
each of the four establishes a single BGP peering against the Route Server
(:ref:`fig:route-server`).
We will first describe briefly the Route Server model implemented by FRR.
We will explain the commands that have been added for configuring that
model. And finally we will show a full example of FRR configured as Route
Server.
.. include:: rpki.rst .. include:: rpki.rst

2
doc/user/conf.py
View File

@ -123,7 +123,7 @@ language = None
# List of patterns, relative to source directory, that match files and # List of patterns, relative to source directory, that match files and
# directories to ignore when looking for source files. # directories to ignore when looking for source files.
exclude_patterns = ['_build', 'rpki.rst', 'ospf_fundamentals.rst'] exclude_patterns = ['_build', 'rpki.rst', 'routeserver.rst', 'ospf_fundamentals.rst']
# The reST default role (used for this markup: `text`) to use for all # The reST default role (used for this markup: `text`) to use for all
# documents. # documents.

2
doc/user/isisd.rst
View File

@ -410,6 +410,8 @@ Showing ISIS information
Show the ISIS routing table, as determined by the most recent SPF Show the ISIS routing table, as determined by the most recent SPF
calculation. calculation.
.. _isis-traffic-engineering:
Traffic Engineering Traffic Engineering
=================== ===================

546
doc/user/routeserver.rst Normal file
View File

@ -0,0 +1,546 @@
.. _configuring-frr-as-a-route-server:
Configuring FRR as a Route Server
=================================
The purpose of a Route Server is to centralize the peerings between BGP
speakers. For example if we have an exchange point scenario with four BGP
speakers, each of which maintaining a BGP peering with the other three
(:ref:`fig-topologies-full`), we can convert it into a centralized scenario where
each of the four establishes a single BGP peering against the Route Server
(:ref:`fig-topologies-rs`).
We will first describe briefly the Route Server model implemented by FRR.
We will explain the commands that have been added for configuring that
model. And finally we will show a full example of FRR configured as Route
Server.
.. _description-of-the-route-server-model:
Description of the Route Server model
-------------------------------------
First we are going to describe the normal processing that BGP announcements
suffer inside a standard BGP speaker, as shown in :ref:`fig-normal-processing`,
it consists of three steps:
- When an announcement is received from some peer, the `In` filters configured
for that peer are applied to the announcement. These filters can reject the
announcement, accept it unmodified, or accept it with some of its attributes
modified.
- The announcements that pass the `In` filters go into the Best Path Selection
process, where they are compared to other announcements referred to the same
destination that have been received from different peers (in case such other
announcements exist). For each different destination, the announcement which
is selected as the best is inserted into the BGP speaker's Loc-RIB.
- The routes which are inserted in the Loc-RIB are considered for announcement
to all the peers (except the one from which the route came). This is done by
passing the routes in the Loc-RIB through the `Out` filters corresponding to
each peer. These filters can reject the route, accept it unmodified, or
accept it with some of its attributes modified. Those routes which are
accepted by the `Out` filters of a peer are announced to that peer.
.. _fig-normal-processing:
.. figure:: ../figures/fig-normal-processing.png
:alt: Normal announcement processing
:align: center
Announcement processing inside a 'normal' BGP speaker
.. _fig-topologies-full:
.. figure:: ../figures/fig_topologies_full.png
:alt: Full Mesh BGP Topology
:align: center
Full Mesh
.. _fig-topologies-rs:
.. figure:: ../figures/fig_topologies_rs.png
:alt: Route Server BGP Topology
:align: center
Route server and clients
Of course we want that the routing tables obtained in each of the routers are
the same when using the route server than when not. But as a consequence of
having a single BGP peering (against the route server), the BGP speakers can no
longer distinguish from/to which peer each announce comes/goes.
.. _filter-delegation:
This means that the routers connected to the route server are not able to apply
by themselves the same input/output filters as in the full mesh scenario, so
they have to delegate those functions to the route server.
Even more, the 'best path' selection must be also performed inside the route
server on behalf of its clients. The reason is that if, after applying the
filters of the announcer and the (potential) receiver, the route server decides
to send to some client two or more different announcements referred to the same
destination, the client will only retain the last one, considering it as an
implicit withdrawal of the previous announcements for the same destination.
This is the expected behavior of a BGP speaker as defined in :rfc:`1771`,
and even though there are some proposals of mechanisms that permit multiple
paths for the same destination to be sent through a single BGP peering, none
are currently supported by most existing BGP implementations.
As a consequence a route server must maintain additional information and
perform additional tasks for a RS-client that those necessary for common BGP
peerings. Essentially a route server must:
.. _route-server-tasks:
- Maintain a separated Routing Information Base (Loc-RIB)
for each peer configured as RS-client, containing the routes
selected as a result of the 'Best Path Selection' process
that is performed on behalf of that RS-client.
- Whenever it receives an announcement from a RS-client,
it must consider it for the Loc-RIBs of the other RS-clients.
- This means that for each of them the route server must pass the
announcement through the appropriate `Out` filter of the
announcer.
- Then through the appropriate `In` filter of the potential receiver.
- Only if the announcement is accepted by both filters it will be passed
to the 'Best Path Selection' process.
- Finally, it might go into the Loc-RIB of the receiver.
When we talk about the 'appropriate' filter, both the announcer and the
receiver of the route must be taken into account. Suppose that the route server
receives an announcement from client A, and the route server is considering it
for the Loc-RIB of client B. The filters that should be applied are the same
that would be used in the full mesh scenario, i.e., first the `Out` filter of
router A for announcements going to router B, and then the `In` filter of
router B for announcements coming from router A.
We call 'Export Policy' of a RS-client to the set of `Out` filters that the
client would use if there was no route server. The same applies for the 'Import
Policy' of a RS-client and the set of `In` filters of the client if there was
no route server.
It is also common to demand from a route server that it does not modify some
BGP attributes (next-hop, as-path and MED) that are usually modified by
standard BGP speakers before announcing a route.
The announcement processing model implemented by Frr is shown in
:ref:`fig-rs-processing`. The figure shows a mixture of RS-clients (B, C and D)
with normal BGP peers (A). There are some details that worth additional
comments:
- Announcements coming from a normal BGP peer are also considered for the
Loc-RIBs of all the RS-clients. But logically they do not pass through any
export policy.
- Those peers that are configured as RS-clients do not receive any announce
from the `Main` Loc-RIB.
- Apart from import and export policies, `In` and `Out` filters can also be set
for RS-clients. `In` filters might be useful when the route server has also
normal BGP peers. On the other hand, `Out` filters for RS-clients are
probably unnecessary, but we decided not to remove them as they do not hurt
anybody (they can always be left empty).
.. _fig-rs-processing:
.. figure:: ../figures/fig-rs-processing.png
:align: center
:alt: Route Server Processing Model
Announcement processing model implemented by the Route Server
.. _commands-for-configuring-a-route-server:
Commands for configuring a Route Server
---------------------------------------
Now we will describe the commands that have been added to frr
in order to support the route server features.
.. index:: neighbor PEER-GROUP route-server-client
.. clicmd:: neighbor PEER-GROUP route-server-client
.. index:: neighbor A.B.C.D route-server-client
.. clicmd:: neighbor A.B.C.D route-server-client
.. index:: neighbor X:X::X:X route-server-client
.. clicmd:: neighbor X:X::X:X route-server-client
This command configures the peer given by `peer`, `A.B.C.D` or `X:X::X:X` as
an RS-client.
Actually this command is not new, it already existed in standard Frr. It
enables the transparent mode for the specified peer. This means that some
BGP attributes (as-path, next-hop and MED) of the routes announced to that
peer are not modified.
With the route server patch, this command, apart from setting the
transparent mode, creates a new Loc-RIB dedicated to the specified peer
(those named `Loc-RIB for X` in :ref:`fig-rs-processing`.). Starting from
that moment, every announcement received by the route server will be also
considered for the new Loc-RIB.
.. index:: neigbor A.B.C.D|X.X::X.X|peer-group route-map WORD import|export
.. clicmd:: neigbor A.B.C.D|X.X::X.X|peer-group route-map WORD import|export
This set of commands can be used to specify the route-map that represents
the Import or Export policy of a peer which is configured as a RS-client
(with the previous command).
.. index:: match peer A.B.C.D|X:X::X:X
.. clicmd:: match peer A.B.C.D|X:X::X:X
This is a new *match* statement for use in route-maps, enabling them to
describe import/export policies. As we said before, an import/export policy
represents a set of input/output filters of the RS-client. This statement
makes possible that a single route-map represents the full set of filters
that a BGP speaker would use for its different peers in a non-RS scenario.
The *match peer* statement has different semantics whether it is used inside
an import or an export route-map. In the first case the statement matches if
the address of the peer who sends the announce is the same that the address
specified by {A.B.C.D|X:X::X:X}. For export route-maps it matches when
{A.B.C.D|X:X::X:X} is the address of the RS-Client into whose Loc-RIB the
announce is going to be inserted (how the same export policy is applied
before different Loc-RIBs is shown in :ref:`fig-rs-processing`.).
.. index:: call WORD
.. clicmd:: call WORD
This command (also used inside a route-map) jumps into a different
route-map, whose name is specified by `WORD`. When the called
route-map finishes, depending on its result the original route-map
continues or not. Apart from being useful for making import/export
route-maps easier to write, this command can also be used inside
any normal (in or out) route-map.
.. _example-of-route-server-configuration:
Example of Route Server Configuration
-------------------------------------
Finally we are going to show how to configure a Frr daemon to act as a
Route Server. For this purpose we are going to present a scenario without
route server, and then we will show how to use the configurations of the BGP
routers to generate the configuration of the route server.
All the configuration files shown in this section have been taken
from scenarios which were tested using the VNUML tool
`http://www.dit.upm.es/vnuml,VNUML <http://www.dit.upm.es/vnuml,VNUML>`_.
.. _configuration-of-the-bgp-routers-without-route-server:
Configuration of the BGP routers without Route Server
-----------------------------------------------------
We will suppose that our initial scenario is an exchange point with three
BGP capable routers, named RA, RB and RC. Each of the BGP speakers generates
some routes (with the `network` command), and establishes BGP peerings
against the other two routers. These peerings have In and Out route-maps
configured, named like 'PEER-X-IN' or 'PEER-X-OUT'. For example the
configuration file for router RA could be the following:
::
#Configuration for router 'RA'
!
hostname RA
password ****
!
router bgp 65001
no bgp default ipv4-unicast
neighbor 2001:0DB8::B remote-as 65002
neighbor 2001:0DB8::C remote-as 65003
!
address-family ipv6
network 2001:0DB8:AAAA:1::/64
network 2001:0DB8:AAAA:2::/64
network 2001:0DB8:0000:1::/64
network 2001:0DB8:0000:2::/64
neighbor 2001:0DB8::B activate
neighbor 2001:0DB8::B soft-reconfiguration inbound
neighbor 2001:0DB8::B route-map PEER-B-IN in
neighbor 2001:0DB8::B route-map PEER-B-OUT out
neighbor 2001:0DB8::C activate
neighbor 2001:0DB8::C soft-reconfiguration inbound
neighbor 2001:0DB8::C route-map PEER-C-IN in
neighbor 2001:0DB8::C route-map PEER-C-OUT out
exit-address-family
!
ipv6 prefix-list COMMON-PREFIXES seq 5 permit 2001:0DB8:0000::/48 ge 64 le 64
ipv6 prefix-list COMMON-PREFIXES seq 10 deny any
!
ipv6 prefix-list PEER-A-PREFIXES seq 5 permit 2001:0DB8:AAAA::/48 ge 64 le 64
ipv6 prefix-list PEER-A-PREFIXES seq 10 deny any
!
ipv6 prefix-list PEER-B-PREFIXES seq 5 permit 2001:0DB8:BBBB::/48 ge 64 le 64
ipv6 prefix-list PEER-B-PREFIXES seq 10 deny any
!
ipv6 prefix-list PEER-C-PREFIXES seq 5 permit 2001:0DB8:CCCC::/48 ge 64 le 64
ipv6 prefix-list PEER-C-PREFIXES seq 10 deny any
!
route-map PEER-B-IN permit 10
match ipv6 address prefix-list COMMON-PREFIXES
set metric 100
route-map PEER-B-IN permit 20
match ipv6 address prefix-list PEER-B-PREFIXES
set community 65001:11111
!
route-map PEER-C-IN permit 10
match ipv6 address prefix-list COMMON-PREFIXES
set metric 200
route-map PEER-C-IN permit 20
match ipv6 address prefix-list PEER-C-PREFIXES
set community 65001:22222
!
route-map PEER-B-OUT permit 10
match ipv6 address prefix-list PEER-A-PREFIXES
!
route-map PEER-C-OUT permit 10
match ipv6 address prefix-list PEER-A-PREFIXES
!
line vty
!
.. _configuration-of-the-bgp-routers-with-route-server:
Configuration of the BGP routers with Route Server
--------------------------------------------------
To convert the initial scenario into one with route server, first we must
modify the configuration of routers RA, RB and RC. Now they must not peer
between them, but only with the route server. For example, RA's
configuration would turn into:
::
# Configuration for router 'RA'
!
hostname RA
password ****
!
router bgp 65001
no bgp default ipv4-unicast
neighbor 2001:0DB8::FFFF remote-as 65000
!
address-family ipv6
network 2001:0DB8:AAAA:1::/64
network 2001:0DB8:AAAA:2::/64
network 2001:0DB8:0000:1::/64
network 2001:0DB8:0000:2::/64
neighbor 2001:0DB8::FFFF activate
neighbor 2001:0DB8::FFFF soft-reconfiguration inbound
exit-address-family
!
line vty
!
Which is logically much simpler than its initial configuration, as it now
maintains only one BGP peering and all the filters (route-maps) have
disappeared.
.. _configuration-of-the-route-server-itself:
Configuration of the Route Server itself
----------------------------------------
As we said when we described the functions of a route server
(:ref:`description-of-the-route-server-model`), it is in charge of all the
route filtering. To achieve that, the In and Out filters from the RA, RB and RC
configurations must be converted into Import and Export policies in the route
server.
This is a fragment of the route server configuration (we only show
the policies for client RA):
::
# Configuration for Route Server ('RS')
!
hostname RS
password ix
!
bgp multiple-instance
!
router bgp 65000 view RS
no bgp default ipv4-unicast
neighbor 2001:0DB8::A remote-as 65001
neighbor 2001:0DB8::B remote-as 65002
neighbor 2001:0DB8::C remote-as 65003
!
address-family ipv6
neighbor 2001:0DB8::A activate
neighbor 2001:0DB8::A route-server-client
neighbor 2001:0DB8::A route-map RSCLIENT-A-IMPORT import
neighbor 2001:0DB8::A route-map RSCLIENT-A-EXPORT export
neighbor 2001:0DB8::A soft-reconfiguration inbound
neighbor 2001:0DB8::B activate
neighbor 2001:0DB8::B route-server-client
neighbor 2001:0DB8::B route-map RSCLIENT-B-IMPORT import
neighbor 2001:0DB8::B route-map RSCLIENT-B-EXPORT export
neighbor 2001:0DB8::B soft-reconfiguration inbound
neighbor 2001:0DB8::C activate
neighbor 2001:0DB8::C route-server-client
neighbor 2001:0DB8::C route-map RSCLIENT-C-IMPORT import
neighbor 2001:0DB8::C route-map RSCLIENT-C-EXPORT export
neighbor 2001:0DB8::C soft-reconfiguration inbound
exit-address-family
!
ipv6 prefix-list COMMON-PREFIXES seq 5 permit 2001:0DB8:0000::/48 ge 64 le 64
ipv6 prefix-list COMMON-PREFIXES seq 10 deny any
!
ipv6 prefix-list PEER-A-PREFIXES seq 5 permit 2001:0DB8:AAAA::/48 ge 64 le 64
ipv6 prefix-list PEER-A-PREFIXES seq 10 deny any
!
ipv6 prefix-list PEER-B-PREFIXES seq 5 permit 2001:0DB8:BBBB::/48 ge 64 le 64
ipv6 prefix-list PEER-B-PREFIXES seq 10 deny any
!
ipv6 prefix-list PEER-C-PREFIXES seq 5 permit 2001:0DB8:CCCC::/48 ge 64 le 64
ipv6 prefix-list PEER-C-PREFIXES seq 10 deny any
!
route-map RSCLIENT-A-IMPORT permit 10
match peer 2001:0DB8::B
call A-IMPORT-FROM-B
route-map RSCLIENT-A-IMPORT permit 20
match peer 2001:0DB8::C
call A-IMPORT-FROM-C
!
route-map A-IMPORT-FROM-B permit 10
match ipv6 address prefix-list COMMON-PREFIXES
set metric 100
route-map A-IMPORT-FROM-B permit 20
match ipv6 address prefix-list PEER-B-PREFIXES
set community 65001:11111
!
route-map A-IMPORT-FROM-C permit 10
match ipv6 address prefix-list COMMON-PREFIXES
set metric 200
route-map A-IMPORT-FROM-C permit 20
match ipv6 address prefix-list PEER-C-PREFIXES
set community 65001:22222
!
route-map RSCLIENT-A-EXPORT permit 10
match peer 2001:0DB8::B
match ipv6 address prefix-list PEER-A-PREFIXES
route-map RSCLIENT-A-EXPORT permit 20
match peer 2001:0DB8::C
match ipv6 address prefix-list PEER-A-PREFIXES
!
...
...
...
If you compare the initial configuration of RA with the route server
configuration above, you can see how easy it is to generate the Import and
Export policies for RA from the In and Out route-maps of RA's original
configuration.
When there was no route server, RA maintained two peerings, one with RB and
another with RC. Each of this peerings had an In route-map configured. To
build the Import route-map for client RA in the route server, simply add
route-map entries following this scheme:
::
route-map <NAME> permit 10
match peer <Peer Address>
call <In Route-Map for this Peer>
route-map <NAME> permit 20
match peer <Another Peer Address>
call <In Route-Map for this Peer>
This is exactly the process that has been followed to generate the route-map
RSCLIENT-A-IMPORT. The route-maps that are called inside it (A-IMPORT-FROM-B
and A-IMPORT-FROM-C) are exactly the same than the In route-maps from the
original configuration of RA (PEER-B-IN and PEER-C-IN), only the name is
different.
The same could have been done to create the Export policy for RA (route-map
RSCLIENT-A-EXPORT), but in this case the original Out route-maps where so
simple that we decided not to use the `call WORD` commands, and we
integrated all in a single route-map (RSCLIENT-A-EXPORT).
The Import and Export policies for RB and RC are not shown, but
the process would be identical.
Further considerations about Import and Export route-maps
---------------------------------------------------------
The current version of the route server patch only allows to specify a
route-map for import and export policies, while in a standard BGP speaker
apart from route-maps there are other tools for performing input and output
filtering (access-lists, community-lists, ...). But this does not represent
any limitation, as all kinds of filters can be included in import/export
route-maps. For example suppose that in the non-route-server scenario peer
RA had the following filters configured for input from peer B:
::
neighbor 2001:0DB8::B prefix-list LIST-1 in
neighbor 2001:0DB8::B filter-list LIST-2 in
neighbor 2001:0DB8::B route-map PEER-B-IN in
...
...
route-map PEER-B-IN permit 10
match ipv6 address prefix-list COMMON-PREFIXES
set local-preference 100
route-map PEER-B-IN permit 20
match ipv6 address prefix-list PEER-B-PREFIXES
set community 65001:11111
It is posible to write a single route-map which is equivalent to
the three filters (the community-list, the prefix-list and the
route-map). That route-map can then be used inside the Import
policy in the route server. Lets see how to do it:
::
neighbor 2001:0DB8::A route-map RSCLIENT-A-IMPORT import
...
!
...
route-map RSCLIENT-A-IMPORT permit 10
match peer 2001:0DB8::B
call A-IMPORT-FROM-B
...
...
!
route-map A-IMPORT-FROM-B permit 1
match ipv6 address prefix-list LIST-1
match as-path LIST-2
on-match goto 10
route-map A-IMPORT-FROM-B deny 2
route-map A-IMPORT-FROM-B permit 10
match ipv6 address prefix-list COMMON-PREFIXES
set local-preference 100
route-map A-IMPORT-FROM-B permit 20
match ipv6 address prefix-list PEER-B-PREFIXES
set community 65001:11111
!
...
...
The route-map A-IMPORT-FROM-B is equivalent to the three filters (LIST-1,
LIST-2 and PEER-B-IN). The first entry of route-map A-IMPORT-FROM-B (sequence
number 1) matches if and only if both the prefix-list LIST-1 and the
filter-list LIST-2 match. If that happens, due to the 'on-match goto 10'
statement the next route-map entry to be processed will be number 10, and as of
that point route-map A-IMPORT-FROM-B is identical to PEER-B-IN. If the first
entry does not match, `on-match goto 10`' will be ignored and the next
processed entry will be number 2, which will deny the route.
Thus, the result is the same that with the three original filters, i.e., if
either LIST-1 or LIST-2 rejects the route, it does not reach the route-map
PEER-B-IN. In case both LIST-1 and LIST-2 accept the route, it passes to
PEER-B-IN, which can reject, accept or modify the route.