In that case, if this is the only work-around possible, then I would
like to send in a feature request for per-filtered-peer local-RIB.
Currently it is the only thing blocking us from putting OpenBGPD in
production as a route server. Filtering is just an absolute requirement
for us at AMS-IX, and as you can read, it's the same at LINX. There is a
general meeting for all the participants of Euro-IX, where 'the route
server issue' will be discussed. This shows that this is a broader issue
than just the AMS-IX.
Are there any plans for OpenBGPD to put 'per-filtered-peer local-RIB' on
the roadmap?
Arnoud
On 3/18/09 11:32 AM, 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.
