sebastian.spies at de-cix
Nov 13, 2009, 1:30 AM
Post #1 of 1
(418 views)
Permalink
|
|
Passive Route Server Ideas
|
|
Hi,
I'd like to comment on [quagga-users 1673]. I know, it's quite old, but
I've come to the same idea.
I know about the problem, that the unfeasible nlri field can not provide
a way to withdraw single routes.
The alternative is described here:
> [...] The only way
> perhaps would be to resend all the non-withdrawn announcements again,
> but this would incur the cost of lots of flaps for routes _not_
> related to the withdrawn route.
What do you think about the following approach?
- withdraw and update once to keep prefixes reachable
- delay forwarding of new announcements for these prefixes for some time
to prevent BGP route dampening
Greets,
Sebastian
[quagga-users 1673]
On Thu, 8 Apr 2004, John Smith wrote:
>/ I guess i wasnt very clear in my wording. What i wanted to know
/>/ was, that, is my understanding of what a "passive" route server is,
/>/ is correct?
/
Its hard to say what a "passive" route server is, as they dont,
AFAIK, exist. :) (least not for eBGP, which is what people are
thinking about.).
>/ So am i correct in my understanding of what a passive route server
/>/ is? Now if this is what a route server is, then do people *need*
/>/ such route servers who can blindly send BGP messages from one peer
/>/ to the other. Does anybody see any need for this?
/
_Lots_ of people would love such a thing, ie IX operators. But
(AFAIK) it does not exist and, having looked into the problem myself,
can not exist (least not if you want to interoperate with common BGP
implementations as clients).
>/ Yes, you are pre-empting my thoughts. I am looking at exactly that.
/>/ Some modifications in my BGP to accomplish that.
/
Interesting, I wish you luck :)
>/ We can think of a way. I am sure that should not be very difficult.
/
That is what I thought once, but it is. I could not find a way to
handle withdrawals, withdrawals do not carry attribute information to
identify which specific announcement is being withdrawn. The only way
perhaps would be to resend all the non-withdrawn announcements again,
but this would incur the cost of lots of flaps for routes _not_
related to the withdrawn route.
The draft BGP ECMP RFC might provide a way to implement such a route
server, whenever it is adopted and reasonably widely implemented.
That's my understanding of the problem at least.
>/ Is this way quite well-known? I would love if you could shed some
/>/ light on this.
/
Yes, its similar to the Merit Route-server (google for RSd or 'merit
rsd'). bgpd maintains one session per client and a seperate
routing-table for each client to allow best-path to be calculated
according to each client's specific policy. You of course need to run
some kind of policy database and have scripts to sync configuration
with the policy database.
Search through the archives for posts from Jose Luis Rubio, eg see
[quagga-dev 809].
>/ Regards,
/>/ Smith
/
regards,
--
Paul Jakma paul at clubi.ie <http://lists.quagga.net/mailman/listinfo/quagga-users> paul at jakma.org <http://lists.quagga.net/mailman/listinfo/quagga-users> Key ID: 64A2FF6A
warning: do not ever send email to spam at dishone.st <http://lists.quagga.net/mailman/listinfo/quagga-users>
Fortune:
There isn't any problem
--
Sebastian Spies e-mail: sebastian.spies [at] de-cix
DE-CIX Management GmbH
Lindleystr. 12, 60314 Frankfurt Mobile: +49 1577 7830883
Geschaeftsfuehrer Harald A. Summa Fax: +49 69 4056 2716
Registergericht AG Koeln, HRB 51135 http://www.de-cix.net
Zentrale: Lichtstr. 43i, 50825 Koeln
|
signature.asc
