Re: feature request OpenBGPD: route server ability to disable best path selection
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
Re: feature request OpenBGPD: route server ability to disable best path selection
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
Re: feature request OpenBGPD: route server ability to disable best path selection
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.
Re: feature request OpenBGPD: route server ability to disable best path selection
Hi, > > The LINX route servers currently support this. For what it's worth we took > a straw poll at the last LINX meeting of the ~100 attendees only 1 network > was doing any filtering on the route server. Everyone else was being > 'promiscuous'. It may be different at AMSIX however although LINX staff > assumed it was a must have feature the general feeling was it wasn't > imperative, particularly if it sacrificed stability. > > As ever YMMV > > Pete > Sorry all Google mail quoting strikes again. Pete
Re: feature request OpenBGPD: route server ability to disable best path selection
Hi,
The LINX route servers currently support this. For what it's worth we took a
straw poll at the last LINX meeting of the ~100 attendees only 1 network was
doing any filtering on the route server. Everyone else was being
'promiscuous'. It may be different at AMSIX however although LINX staff
assumed it was a must have feature the general feeling was it wasn't
imperative, particularly if it sacrificed stability.
As ever YMMV
Pete
On Wed, Mar 18, 2009 at 10: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.
>
> --
> :wq Claudio
Re: feature request OpenBGPD: route server ability to disable best path selection
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
feature request OpenBGPD: route server ability to disable best path selection
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
