Paul -
Don and I have spoken with Alvaro Retana who wrote some of the RFC's in
question and here is his response:
----------------------
>Thanks for responding. Let me see if I can explain it better after
>talking to Donald Sharp (copied) who asked me to look at the RFCs and the
>other maintainer¹s objections. I was off by a hop in my description of
>the problem. :^)
>
>ABR‹‹‹ A‹‹‹ B ‹‹‹ C ‹‹‹ D-x
>
>A is fastpath
>B, C, and D are quagga
>
>If C defines ³max-metric router-lsa administrative² in quagga, B will not
>include C¹s interfaces in the path to the addresses advertised by D. A
>will include C's links and have a path to Dx pointing at B, but B will
>not have a path to the prefixes. If this happens to be a stub area, B
>will forward the traffic back to A following the default, causing a loop.
> Does this make sense?
Your description makes sense.
What doesn't make sense is for B to not include C's links -- that is the
pre-rfc1583 behavior.
IOW, rfc6987 is specified on top of rfc2328, which means that the decision
to include or not the links because of the max-metric should be the same
in a router implementing only rfc2328, or rfc2328 + rfc6987.
>Also, do you know if other vendors have implemented it with the RFC6987
>approach or stuck with the RFC2328 way?
See above. As far as I can tell both approaches are the same. Note that
rfc6987 doesn't say anything about route selection, it just talks about
advertising max-metric.
In summary, I think A is doing the right thing. B is doing the right
thing, but only from a pre-rfc1583 point of view.
----------------------------------
thanks!
donald
On Thu, Mar 17, 2016 at 9:03 AM, Don Slice <dsl...@cumulusnetworks.com>
wrote:
> Paul,
>
> Comments/questions in-line.
>
> On Thu, Mar 17, 2016 at 4:29 AM, Paul Jakma <p...@jakma.org> wrote:
>
>>
>> ospfd: 16.0 rfc2328 compliance
>>>>
>>>>>
>>>>>
>>>> What was the motivation for this?
>>>>
>>>>
>>> We had/have(tense? oh I hate thee) customers seeing loops without this
>>> patch?
>>>
>>>
>>> RFC3137 and 6987 both allow for routers to treat "infinite" cost links as
>>>> infinite, and the intent of the stub-router support definitely is to
>>>> wholly
>>>> prevent any infinite cost link being used for transit. Quagga is
>>>> aggressive
>>>> on that, but not incorrect in terms of those RFCs.
>>>>
>>>
> Since both of these are informational rather than standards track, is it a
> safe bet to operate as these two describe when there are potential known
> bad side-effects? The Deployment considerations section of RFC6987 states
> that inconsistent results could be seen in a mixed environment (though it
> also incorrectly states that routing loops cannot occur.) Do we know how
> many OSPF implementations default to operating in RFC2328 vs RFC6987?
>
>
>> Without this patch when I set 'max-metric router-lsa administrative' on a
>>> switch, it is no longer considered as part of the spf calculation for
>>> routes.
>>>
>>> Suppose I have
>>>
>>> source of traffic -----A ---- B ---- C ---- Network I want to talk to.
>>>
>>> A is running fastpath, B and C are running Quagga ospf. B has a default
>>> route towards A for traffic.
>>>
>>> If on 'C' I do 'max-metric router-lsa'. This causes the links cost to be
>>> infinite. On B without this patch the links are ignored
>>>
>>
>> As intended, yes.
>>
>> and the path to 'Network I want to talk to' is dropped, leaving a default
>>> route back to A, which the packet goes back out on. A picks it up and
>>> sends it right back to B. We have achieved a loopage.
>>>
>>
>> Well yes.
>>
>> There is nothing in the RFC's that specify that we should not use a
>>> max-metric link, while in Quagga we don't consider it.
>>>
>>
>> As I said, Quagga is aggressive about not using a stub-router as a
>> transit router. The RFC is pretty clear that that is an allowed outcome,
>> and indeed the "desired" one (as the RFC seems to put it).
>>
>> From motivation:
>>
>> " In some situations, it may be advantageous to inform routers in a
>> network not to use a specific router as a transit point but to still
>> route to it.
>> ..
>>
>> Otherwise, traffic
>> destined for the networks and reachable through such a stub router
>> may still be routed through it."
>>
>> (Note "may" in the last sentence).
>>
>> Deployment considerations:
>>
>> " If the path through the stub router is the only one, the routers of
>> the first type _will not use the stub router for transit_ (which is
>> _the desired behavior_), while the routers of the second type will
>> still use this path."
>>
>> Added emphasis (via underscores) is mine.
>>
>> The intent of stub-router support is to let a router 'exit' from the OSPF
>> domain gracefully - by updating its OSPF advertisement to /stop/ other
>> routers sending /any/ packets toward it for transit, while still
>> maintaining adjacencies so that it can still calculate valid routes to
>> forward any packets that happen to still arrive (i.e. cause they were sent
>> before other routers were able to react); but keeping connectivity to
>> itself intact.
>>
>> It seems to me it was intended to be fairly equivalent to shutting down
>> the router, as far as OSPF transit routing goes. If you set your only
>> router to a destination to be a "non-transit" "stub router" then, going
>> just by that language, yes, you should expect routing to that destination
>> is likely no longer to work.
>>
>> If you don't want to discourage /all/ traffic, I'd have thought you
>> really would have wanted to set a metric *less than* infinite ("infinite"
>> cost seems pretty clear to me). That starts to get into
>> traffic-engineering, and some kind of global, router-level "Set X, in: set
>> all links to min(max, link cost + X)" knob may be more what people are
>> after.
>>
>> If there are people who thought "stub-router" didn't fully mean that,
>> that's interesting. Wasn't how I read the RFC or how I would have
>> interpreted an "infinite" cost link (the original OSPF RFCs interpreted the
>> same but later removed that requirement, I see). Given existing Quagga
>> OSPF, the best way to get that relaxed sense would be to use 0xfffe, or
>> 0xffff - some X, as the cost.
>>
>> Whether to take that patch as is, or whether to have a 'strict'
>> max-metric, and also a more relaxed version, hmmm. (Even as is, the commit
>> message language should be changed).
>>
>> Was the motivation keeping the router accessible, even if the management
>>> IP was also OSPF routed?
>>>
>>
>> Yes.
>>>
>>
>> That should already be the case, certainly for the RID. If other local
>> IPs aren't, then maybe there's an issue in a later stage of the routing
>> calc where the router's stub links are added.
>>
>> If you've queried this patch a few times, I've missed it. I have 100
>>> patches I'm trying to get through the process. It was not my intention to
>>> miss anything.
>>>
>>
>>
>>
>>
>> _______________________________________________
>> Quagga-dev mailing list
>> Quagga-dev@lists.quagga.net
>> https://lists.quagga.net/mailman/listinfo/quagga-dev
>>
>
>
>
> --
> Don Slice
> Cumulus Networks
>
> _______________________________________________
> Quagga-dev mailing list
> Quagga-dev@lists.quagga.net
> https://lists.quagga.net/mailman/listinfo/quagga-dev
>
_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev
