The 'standard' (for at least one vendor's definition of standard) way
to get around this, is to slap a different route distinguisher (RD) on
each of the desired 'duplicate' paths. BGP then sees these as
individual paths and will happily communicate both concurrently.
Separate but related, is the ability to import both RD's into the same
VRF on the recipient of the BGP peering, and thus into the routing
table (FIB) to use multiple paths (load balancing) etc.
/Pete
On 18 Mar 2009, at 11:32, Claudio Jeker wrote:
On Wed, Mar 18, 2009 at 11:00:32AM +0100, Arnoud Vermeer wrote:
I have a problem with filtering on the current route server
implementation. I currently have the following setup:
* 10.0.1.0/24 10.0.1.0/24
+-----------+ +-----------+
| AS1 | | AS2 |
| 10.0.0.50 | | 10.0.0.51 |
+-----------+ +-----------+
| |
| |
+---+-----------+---+
| RS |
| 10.0.0.49 |
+-----+-----+
|
| deny to { 10.0.0.52 } AS 1
|
+-----+-----+
| AS3 |
| 10.0.0.52 |
+-----------+
(or http://www.freshway.biz/files/20090318-problem-filter.txt for the
correct ASCII)
Both AS1 and AS2 announce the same prefix, but the route server
selects
the AS1 path because of the lower nexthop value. Now I add a filter
to
AS3. I deny to send any prefixes to AS3 that match AS1. Now AS3
doesn't
receive the 10.0.1.0/24 prefix at all. It should however receive it
from
AS2.
Quagga overcomes this problem by making a per-filtered-peer RIB and
then
do best path selection
(http://www.quagga.net/docs/docs-multi/Description-of-the-Route-Server-model.html
).
I think this is just an ugly and complicated work-around as it
doesn't
solve the core of the problem.
In my eyes the best solution will be to disable the best-path-
selection
on the route server altogether, and send all routes (except the
filtered) to the peer.
Arguments to do this:
- As shown above, the best path selection breaks on the route server
when applying filters.
- A route server should not make any best-path selection, because the
peers criteria could be completely different than the route server.
- The function of the route server is to 'collect' all the routes and
send them to all of the peers, not to 'collect a subset' of the
routes
and send that to its peers.
I would love to hear your thoughts on this subject. Would it be
hard to
implement this feature?
BGP only supports one path per prefix and peer. If you send multiple
ones
as you propose the later ones will overwrite the first one no matter
what.
To support your idea we would need a per-filtered-peer local-RIB
because
the route-server needs to do the best path selection for the peer.
--
:wq Claudio
