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" <[email protected]> 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? > >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 [email protected] https://www.ietf.org/mailman/listinfo/ospf
