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
