So the guys at PLIX actually send me an email that the feature I was
talking about already has a Internet-Draft. For this to become a RFC, it
needs at least two implementations before June 2009.
http://tools.ietf.org/html/draft-ietf-idr-add-paths-00
Kind regards,
Arnoud
On 3/18/09 11:00 AM, 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?
Arnoud Vermeer
Amsterdam Internet Exchange
