On 23.11.2011 20:07, Ondrej Zajicek wrote:
On Mon, Nov 21, 2011 at 06:12:19PM +0400, Alexander V. Chernikov wrote:
Hello list!
This patch implements RFC 4271 MED comparison.
This patch may introduce significant performance penalty (unfortunately
I haven't got any real numbers at the moment).
However, this comparison is absolutely necessary at least for RR setups.
rte_better cost has changed from O(1) to O(n) (should not affect
performance much)
rte_recalculate can execute 2-3 times slower in worst case (this can
consume more resources when preferred BGP neighbor goes down)
This is an issue we (developers) discussed privately about half a year
ago and came to conclusion that strict RFC 4271 behavior - deterministic
MED comparison - is not really meaningful, hard to implement in current
BIRD design and probably not worth the effort. As the deterministic MED
behavior is not even default on Ciscos (as far as i read), there are
probably not many problems with compatibility.
Yes, it is not. Small networks does not require this behavior.
Perhaps the better way to solve problems with nondeterministic selection
is to enable 'med metric' (i.e. always compare med) and tweak MEDs on AS
boundaries to have consistent values (or just reset all MEDs to 0).
Sometimes 'non-deterministic' is not enough.
Imagine the following:
AS1 is the customer of AS2 and AS3
AS4 peers with both AS2 and AS3
-------
| AS1 |
-------
/ \
-------- --------
| AS2 | | AS3 |
-------- --------
| | | |
---------------------------------
/ \
| AS 4 |
\---------------------------------/
AS2 has 2 links with AS4 (MED 100 and 200) in one city/country
AS3 has 2 links with AS4 (MED 300 and 400) in the other city
All this 4 links comes via iBGP to on of route reflectors in AS3 city.
In the normal situation (deterministic med on)
best paths from AS2 and AS3 to AS1 will be compared by IGP metric
which is reasonable (link capacity/delay can be different so the best
_local_ exit is selected).
In case of always-compare-med traffic flow became suboptimal and fixing
this (due to large number of peers) will significantly increase number
of such hacks in route-maps on border routers.
I do not insist to make RFC4271 behavior the default one, but the
ability to turn this on is (IMHO) mandatory.
It is supported for example by Quagga and Juniper. The latter one uses
deterministic MED by default.
But as you already wrote the patch i could look at it.
It will be great. This version is rather hackish.
BTW, do you have some kind of IM? or IRC ? Or you prefer ML discussions?
--
WBR, Alexander
