>
> +@deffn {BGP} {bgp bestpath compare-routerid} {}
>> +@anchor{bgp bestpath compare-routerid}
>> +
>> +Ensure that where iBGP routes are equal on most metrics,
>> including
>> +local-pref, AS_PATH length, IGP cost, MED, the tie is broken
>> based on
>> +router-ID. If a route has an ORIGINATOR_ID attribute, i.e. it
>> has been
>> +reflected, that ID will be used. Otherwise, the router-ID of
>> the peer the
>> +route was received from will be used.
>> +
>> +The advantage of this is that the route-selection (at this
>> point) will be
>> +deterministic, across iBGP. The disadvantage is that such
>> equal routes will
>> +tend to take the same exit out of the AS, via the lowest-ID
>> router.
>> +
>>
>
> Comparing the router-id always happens if both paths are from iBGP peers,
>> it is only if they are both from eBGP peers that it applies.
>>
>
> "iBGP routes" in the above is probably badly worded. I didn't mean that to
> be iBGP origin there, but routes being compared where both were received
> from iBGP (or both from eBGP, as you note - but then only if the
> external-age check didn't do a return).
>
> Or did you mean something else?
If both routes are received from iBGP peers (doesn't matter if they were
originated in our AS or not) then we compare the router-id. The compare
router-id knob only comes into play when comparing two paths from eBGP
peers because it causes us to skip the 'prefer oldest' check.
My point being that it is confusing to explain the knob in the context of
iBGP when the knob only has an impact for eBGP peers.
> +A deterministic comparison tends to imply an additional
>> overhead of sorting
>> +over any set of n routes to a destination. The implementation
>> of
>> +deterministic MED in Quagga scales significantly worse than
>> most sorting
>> +algorithms at present, with the number of paths to a given
>> destination.
>> +That number is often low enough to not cause any issues, but
>> where there are
>> +many paths, the deterministic comparison may quickly become
>> increasingly
>> +expensive in terms of CPU.
>>
>
> I would say that the details of the sorting algorithm used is probably more
>> info that the average person is interested in if they are trying to
>> understand how bestpath works.
>>
>
> It seems relevant to an operator. DMED is not free, it has an intrinsic
> cost. Operators surely will want to have the information they need to be
> able to balance the costs against the benefits?
It is an implemenation detail though. We should explain what the knob does
and based on that the operator can decide whether or not he/she wants to
enable it. If doing so causes performance issues then we address those and
fix them.
Nothing is free and we don't go into the details of how the algorithms work
for other features/knobs so it feels inconsistent to do it here. I could
say that the algorithm for replicating updates among members of a
peer-group is non-existent and that therefore you shouldn't configure lots
of peers because it will have a performance impact. That would be a true
statement but the operator doesn't really need to know that unless they
configure so many peers and carry so many prefixes that they notice poor
performance.
> +There is as of this writing @emph{no} known way to use MED for
>> its original
>> +purpose; @emph{and} reduce routing information in non-full-mesh
>> iBGP
>> +topologies (e.g with reflectors); @emph{and} be sure to avoid
>> the
>> +instability problems of MED due the non-transitive routing
>> preferences it
>> +can induce.
>>
>>
>> But there is a way :)
>>
>
> Is is _sure to avoid_ though? There are many many networks, and there are
> different ways BGP can behave even on the same network.
>
I have not done a mathmatical proof on it but it has been 14 years since we
found MED churn and we do not know of any flavor of MED churn that is not
solved by the three bullets below.
MED intrinsically has an undefined order of preference across routes,
> that's the source of all the issues with it. iBGP topologies are getting
> bigger and more complex (though some, DCs, are getting more regular in
> structure), and we ship with defaults that leave the more complex iBGP
> networks wide open to problems caused by MED.
>
We have 'prefer oldest external' enabled by default which does help. The
only other knob we could flip is always-compare-med but I don't think
customers would like it much if we did. The reality is that not many
people actually hit MED churn and almost all of the ones that do hit the
Type I scenario which is easily solved. To hit Type II you have to have
multiple tiers of route-reflectors (or confed sub ASNs) which isn't that
common...and even then you can use addpath to fix it.
>
> * Preferring the oldest external path solves one scenario
>> * "Type I" churn (as described in RFC 3345) can be solved by tweaking
>> IGP
>> metrics. If you are using RRs you just have to make your
>> inter-cluster
>> links have a higher cost than your intra-cluster links (same theory
>> with
>> confeds). When we first discovered MED churn most customers that were
>> hitting it were able to solve it via this approach.
>> * "Type II" churn can be solved by using addpath to TX the bestpath per
>> neighbor-AS...see draft-ietf-idr-route-oscillation-stop-01
>>
>
> I don't know how to describe these cases in a way that an operator could
> apply the advice and be sure they had avoided MED issues though. Patch to
> the doc welcome though. ;)
>
I think it would be best to just refer them to RFC3345 and say "read this
if you are seeing oscillating routes in bgp".
Indeed, can you prove the issues are solved with those approaches? There
> are papers that derive quite simple rules that engineers can apply and be
> _sure_ that their path-vector protocol will converge, and even will
> converge on optimal routes. The IGP cost case potentially can be proven to
> meet those rules, but that proof will be specific to the network - not a
> general proof to any network.
>
Mathmatically prove...no, I have never attempted to do so and we've never
been asked to provide a mathmatical proof. Am I confident that MED churn
is solved with these approaches, absolutely.
>
> +Setting this option will have a performance cost that may be
>> noticeable when +there are many routes for each destination.
>> Currently in Quagga it is +implemented in a way that scales poorly
>> as the number of routes per +destination increases.
>>
>
>
> Why don't we fix our implementation so that it is less expensive and chop
>> the paragraph above? I am worried that we will end up discouraging
>> customers from enabling deterministic-med.
>>
>
> Well, I'm not aware of DMED fixing anything, so I'm not going to spend my
> time on that. Someone else could, and update the above.
>
I have a concrete example of where it is needed buried in an old email
somewhere...let me see if I can dig that up.
>
> Till then, it seems like important information for admins. If they choose
> not to enable DMED, they're not losing anything afaik.
>
> Really, they should enable always-compare and set all MEDs to 0 when
> received from eBGP, unless they have a specific use for MED. In which case,
> DMED would be irrelevant anyway.
>
>
>> +Note that there are other sources of indeterminism in the route
>> selection
>> +process, @xref{BGP decision process}.
>>
>
> Other than "prefer oldest external" what sources of indeterminism are
>> there?
>>
>
> That's the one I had in mind.
>
Maybe mention it in the section on 'prefer oldest external' and compare
router-id and chop the mention here?
Daniel
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
