[prev in list] [next in list] [prev in thread] [next in thread]
List: ms-ospf
Subject: Re: [OSPF] RFC1583Compatibility
From: "Pat Murphy - (650)329-4044" <pmurphy () noc ! usgs ! net>
Date: 2012-04-17 19:30:45
Message-ID: 01OEFBKLJ30200L702 () omega7 ! wr ! usgs ! gov
[Download RAW message or body]
Faraz,
You are right. It is set to enable by default. Sorry, it has been a long time since I looked at
this spec. I suspect almost every RFC 2328 Internet deployment is running RFC 1583 compatibility
mode. Implementations clearly provide for disabling the mode. However someone would have to know
the ramifications of keeping the mode "enabled" before they would disable it. I doubt if most do.
Hence the spec is stuck indefinitely. In truth, even though I knew the ramifications, I thought
it was "disabled" by default.
Out of curiosity I took a look at some Cisco and Juniper routers I helped deploy some time ago
and noticed the cost of my original summary range aggregations appear to use the RFC 1583 MINIMUM
as opposed to the RFC2328 MAXIMUM. These routers are running with the RFC1583Compatibility mode
"enabled". I did not try a lab experiment to see what happens when their RFC1583Compatibility
mode is "disabled". But, assuming the summary cost metric reverts to the RFC2328 MAXIMUM when the
mode is "disabled", this seems contrary to the implementations you and Acee mentioned. Perhaps
this RFC2328 vs RFC2178 issue needs some clarification, as you suggest.
For what's its worth, with router memory so large these days, OSPF summary range aggregation has
less appeal. I was surprised to find my aggregations still configured.
Pat
Date: Tue, 17 Apr 2012 11:25:54 -0500
From: Faraz Shamim <sshamim@cisco.com>
Subject: Re: [OSPF] RFC1583Compatibility
Pat,
The issue is that the RFC 2328 recommends to set this parameter to
"enabled" by default so this means you can not get rid of this parameter
and start implementing 16.4.1 as a default in new devices or old devices
with new code. Having a mix of 1583 and 2328 implementation(with respect
to AS external path preference) will cause loop. There are numerous
implementations that follow 2328 but when it comes to AS external path
preference, they follow RFC 1583 to prevent loop. Not sure if 16.4.1 will
ever see it's daylight but when it does, we can safely remove this
parameter and retire 1583.
Faraz
On 4/17/12 10:23 AM, "Pat Murphy - (650)329-4044" <pmurphy@noc.usgs.net>
wrote:
>Acee, Faraz,
>
>It is hard to believe there are any RFC 1583 implementations still in
>operation. It
>is true that back when RFC 2178 (and later RFC 2328) was published, the
>WG was dealing
>with two real routing loop issues. However it seems academic now. Can't
>RFC1583Compatibility simply be retired along with RFC 1583?
>
>As for John's text,
>
>> Unfortunately, this change is not backward compatible. While the
>> change prevents routing loops when all routers run the new preference
>> rules, it can actually create routing loops when some routers are
>> running the new preference rules and other routers implement RFC
>> 1583. For this reason, a new configuration parameter has been added:
>> RFC1583Compatibility. Only when RFC1583Compatibility is set to
>> "disabled" will the new preference rules take effect. See Appendix C
>> for more details.
>
>I feel fairly confident the "new preference rules" refer to Section
>16.4.1. It seems
>unlikely that leaving the summary cost at MAXIMUM when
>RFC1583Compatiblility is set to
>"enabled" would create more routing loops. Indeed the opposite seems
>true. My guess is
>this omission in RFC 2328 was intentional. I did hear the discussion
>about backward
>compatibility and I don't remember any mention of the summary cost change.
>
>Pat
>
>> Acee,
>>
>> I would like to know what the rest of the OSPF WG think about this. I
>>want
>> to see if anyone has implemented it differently.
>>
>> Requesting for Comments from the rest of the community ;-)
>>
>> On 4/13/12 10:57 AM, "Faraz Shamim" <sshamim@cisco.com> wrote:
>>
>>> If you read section G.7 of RFC 2178 it appears that
>>> RFC1583Compatibility would mean to apply 16.4.1 algorithm, for AS
>>> external
>>> if received from multiple area AND change the summary range cost to
>>>pick
>>> up MAXIMUM cost. But when you read C.1, under RFC1583Compatibility it
>>> says that this parameter applies to AS external. No where it mentions
>>> the summary cost should be changed to MINIMUM per RFC 1583. Since G.7
>>> does not even exist in RFC 2328 so whoever
>>> reads RFC 2328 would always think that RFC1583Compatibility is ONLY
>>> related to AS external path preference.
>>>
>>> Can you please confirm if RFC1583Compatibility should only affect AS
>>> external path preference or should it also touch the summary cost and
>>>set
>>> it to MINIMUM per RFC 1583?
>
>I agree that RFC1583Compatibility should only affect AS external path
>preference. This
>is also the interpretation in my implementation and the open source
>quagga
>implementation.
>
>Thanks,
>Acee
>
>
>
>
>
>>>
>>> Thanks,
>>>
>>> Faraz
>>
>> From RFC 2178:
>>
>> G.7 Advertising same external route from multiple areas
>>
>> This document fixes routing loops which can occur in RFC 1583 when
>> the same external destination is advertised by AS boundary routers in
>> separate areas. There are two manifestations of this problem. The
>> first, discovered by Dennis Ferguson, occurs when an aggregated
>> forwarding address is in use. In this case, the desirability of the
>> forwarding address can change for the worse as a packet crosses an
>> area aggregation boundary on the way to the forwarding address, which
>> in turn can cause the preference of AS-external-LSAs to change,
>> resulting in a routing loop.
>>
>> The second manifestation was discovered by Richard Woundy. It is
>> caused by an incomplete application of OSPF's preference of intra-
>> area routes over inter-area routes: paths to any given
>> ASBR/forwarding address are selected first based on intra-area
>> preference, while the comparison between separate ASBRs/forwarding
>> addresses is driven only by cost, ignoring intra-area preference. His
>> example is replicated in Figure 19. Both router A3 and router B3 are
>> originating an AS-external-LSA for 10.0.0.0/8, with the same type 2
>> metric. Router A1 selects B1 as its next hop towards 10.0.0.0/8,
>> based on shorter cost to ASBR B3 (via B1->B2->B3). However, the
>> shorter route to B3 is not available to B1, due to B1's preference
>> for the (higher cost) intra-area route to B3 through Area A. This
>> leads B1 to select A1 as its next hop to 10.0.0.0/8, resulting in a
>> routing loop.
>>
>>
>>
>>
>> Moy Standards Track [Page 207]
>>
>> RFC 2178 OSPF Version 2 July 1997
>>
>>
>> The following two changes have been made to prevent these routing
>> loops:
>>
>> o When originating a type 3 summary-LSA for a configured area
>> address range, the cost of the summary-LSA is now set to the
>> maximum cost of the range's component networks (instead of the
>> previous algorithm which set the cost to the minimum component
>> cost). This change affects Sections 3.5 and 12.4.3, Figures 7
>> and 8, and Tables 6 and 13.
>>
>> o The preference rules for choosing among multiple AS-
>> external-LSAs have been changed. Where previously cost was the
>> only determining factor, now the preference is driven first by
>> type of path (intra-area or inter-area, through non-backbone area
>> or through backbone) to the ASBR/forwarding address, using cost
>> only to break ties. This change affects Sections 16.4 and 16.4.1.
>>
>> After implementing this change, the example in Figure 19 is modified
>> as follows. Router A1 now chooses A3 as the next
>>
>> 10.0.0.0/8
>> ----------
>> |
>> +----+
>> | XX |
>> +----+
>> RIP / \ RIP
>> --------------------- --------------------
>> ! !
>> ! !
>> +----+ +----+ 1 +----+......+----+....
>> | A3 |------| A1 |---------------| B1 |------| B3 | .
>> +----+ 6 +----+ +----+ 8 +----+ .
>> 1| . / .
>> OSPF backbone | . / .
>> +----+ 2 / .
>> | B2 |------- Area A.
>> +----+................
>>
>> Figure 19: Example routing loop when the
>> same external route is advertised from multiple
>> areas
>>
>> hop to 10.0.0.0/8, while B1 chooses B3 as next hop. The reason for
>> both choices is that ASBRs/forwarding addresses are now chosen based
>> first on intra-area preference, and then by cost.
>>
>>
>> Moy Standards Track [Page 208]
>>
>> RFC 2178 OSPF Version 2 July 1997
>>
>>
>> Unfortunately, this change is not backward compatible. While the
>> change prevents routing loops when all routers run the new preference
>> rules, it can actually create routing loops when some routers are
>> running the new preference rules and other routers implement RFC
>> 1583. For this reason, a new configuration parameter has been added:
>> RFC1583Compatibility. Only when RFC1583Compatibility is set to
>> "disabled" will the new preference rules take effect. See Appendix C
>> for more details.
>>
>>
>>
>>
>> C.1 Global parameters
>>
>> In general, a separate copy of the OSPF protocol is run for each
>> area. Because of this, most configuration parameters are defined on
>> a per-area basis. The few global configuration parameters are listed
>> below.
>>
>> [SNIP..]
>>
>> RFC1583Compatibility
>> Controls the preference rules used in Section 16.4 when choosing
>> among multiple AS-external-LSAs advertising the same destination.
>> When set to "enabled", the preference rules remain those
>> specified by RFC 1583 ([Ref9]). When set to "disabled", the
>> preference rules are those stated in Section 16.4.1, which
>> prevent routing loops when AS- external-LSAs for the same
>> destination have been originated from different areas (see
>> Section G.7). Set to "enabled" by default.
>>
>>
>> In order to minimize the chance of routing loops, all OSPF
>> routers in an OSPF routing domain should have
>> RFC1583Compatibility set identically. When there are routers
>> present that have not been updated with the functionality
>> specified in Section 16.4.1 of this memo, all routers should have
>> RFC1583Compatibility set to "enabled". Otherwise, all routers
>> should have RFC1583Compatibility set to "disabled", preventing
>> all routing loops.
>>
>>
>>
>> _______________________________________________
>> OSPF mailing list
>> OSPF@ietf.org
>> https://www.ietf.org/mailman/listinfo/ospf
>
>_______________________________________________
>OSPF mailing list
>OSPF@ietf.org
>https://www.ietf.org/mailman/listinfo/ospf
>
>_______________________________________________
>OSPF mailing list
>OSPF@ietf.org
>https://www.ietf.org/mailman/listinfo/ospf
_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic