idnits 2.17.1 draft-ietf-ospf-abr-behavior-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([Ref1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 1999) is 9199 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 641 Summary: 8 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. D. Zinin 3 Internet Draft AMT Group 4 Expiration Date: August 1999 February 1999 5 File name: draft-ietf-ospf-abr-behavior-00.txt 7 OSPF ABR Behavior 8 Alternative Implementation and Deployment Considerations 9 draft-ietf-ospf-abr-behavior-00.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its Areas, and its Working Groups. Note that other 18 groups may also distribute working documents as Internet Drafts. 20 Internet Drafts are draft documents valid for a maximum of six 21 months. Internet Drafts may be updated, replaced, or obsoleted by 22 other documents at any time. It is not appropriate to use Internet 23 Drafts as reference material or to cite them other than as a "working 24 draft" or "work in progress". 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 OSPF [Ref1] is a link-state intra-domain routing protocol used for 35 routing in IP networks. Though the definition of the ABR in the 36 current OSPF specification does not require a router with multiple 37 attached areas to have a backbone connection, it is actually 38 necessary to provide successful routing to the inter-area and 39 external destinations. If this requirement is not met all traffic, 40 destined for the areas not connected to such ab ABR or out of the 41 OSPF domain, is dropped. The rules of originating and processing 42 Summary-LSAs given in the current OSPF standard [Ref1] can also 43 result in suboptimal inter-area routing. Though all these problems 44 can be fixed using virtual links, this memo describes an alternative 45 implementation of the OSPF ABR behavior, which allows the 46 administrator to avoid it or, if virtual links are still used, to 47 decrease the number of configured virtual links. 49 This memo also describes possible situations where the proposed 50 implementation can be used. 52 Acknowledgements 54 The author would like to acknowledge Christian Hopps for his help in 55 finding weak points in early versions of this document and Thomas M. 56 Thomas II for technical and grammar review. 58 This document is a result of the discussion between the author, 59 Christian Hopps, and Acee Lindem about Cisco Systems OSPF 60 implementation. 62 1 Overview 64 1.1 Introduction 66 An OSPF routing domain can be split into several subdomains, called 67 areas, which limit the scope of LSA flooding. A router having 68 attachments to multiple areas is called an "area border router" 69 (ABR). The primary function of an ABR is to provide its attached 70 areas with Type-3 and Type-4 LSAs (which are used for describing 71 routes and ASBRs in other areas) as well as to perform actual inter- 72 area routing. 74 1.2 Motivation 76 In OSPF domains the area topology is restricted so that there must be 77 a backbone area (area 0) and all other areas must have either 78 physical or virtual connections to the backbone. The reason for this 79 star-like topology is that OSPF inter-area routing uses the 80 distance-vector approach and a strict area hierarchy permits 81 avoidance of the "counting to infinity" technique. OSPF prevents 82 inter-area routing loops by implementing a split-horizon mechanism, 83 permitting ABRs to inject into the backbone only Summary-LSAs derived 84 from the intra-area routes, and limiting ABRs' SPF calculation to 85 consider only Summary-LSAs in the backbone area's link-state 86 database. 88 The last restriction leads to a problem when an ABR has no backbone 89 connection (in OSPF an ABR does not need to be attached to the 90 backbone). Consider a sample OSPF domain depicted in the Figure 1. 92 . . 93 . Area 0 . 94 +--+ +--+ 95 ..|R1|.. ..|R2|.. 96 . +--+ .. +--+ . 97 . .. . 98 . +--+ . 99 . Area1 |R3| Area2 . 100 . +--+ +--+ . 101 . .. |R4| . 102 . . . +--+ . 103 ....... ....... 105 Figure 1. ABR dropping transit traffic 107 In this example R1, R2, and R3 are ABRs. R1 and R2 have backbone 108 connections, while R3 doesn't. 110 Following the section 12.4.1 of [Ref1], R3 will identify itself as an 111 ABR by setting the bit B in its router-LSA. Being an ABR, R3 can only 112 consider summary-LSAs from the backbone when building the routing 113 table (according to section 16.2 of [Ref1]), so it will not have any 114 inter-area routes in its routing table, but only intra-area routes 115 from both Area 1 and Area 2. Consequently, according to the section 116 12.4.3 of [Ref1], R3 will originate for Areas 1 and 2 only summary- 117 LSAs covering destinations in the directly attached areas, i.e., in 118 Area 2---the summary-LSAs for Area 1, and in Area 1---the summary- 119 LSAs for Area 2. 121 At the same time, router R2, as an ABR connected to the backbone, 122 will inject into Area 2 summary-LSAs describing the destinations in 123 Area 0 (the backbone), Area 1 and other areas reachable through the 124 backbone. 126 This results in a situation, where internal router R4 calculates its 127 routes to destinations in the backbone and areas other than Area 1 128 via R2. The topology of Area 2 itself can be such that the best path 129 from R4 to R2 is via the R3, so all traffic destined for the backbone 130 and backbone-attached areas goes through R3. Router R3 in turn, 131 having only intra-area routes for areas 1 and 2, will effectively 132 drop all traffic not destined for the areas directly attached to it. 133 The same problem can be seen when a backbone-connected ABR loses all 134 of its adjacencies in the backbone---even if there are other normally 135 functioning ABRs in the attached areas, all traffic going to the 136 backbone (destined for it or for other areas) will be dropped. 138 In a standard OSPF implementation this situation can be remedied by 139 use of the Virtual Links (see section 15 of [Ref1] for more details). 140 In this case, router R3 will have a virtual backbone connection, will 141 form an adjacency over it, will receive all summary-LSAs directly 142 from a backbone-attached router (R1 or R2, or both in our example) 143 and will install inter-area routes. 145 While being an unavoidable technique for repairing a partitioned 146 backbone area, the use of virtual links in the described situation 147 adds extra configuration headaches and system traffic overhead. 149 Consider another example, illustrated by the Figure 2: 151 . Area 2 . 152 . . 153 . +--+ . 154 ......|R5|....... 155 . +--+ . 156 . / \ . 157 . / \ . 158 . BB /10Mb \ 2Mb . 159 . / \ . 160 . | \ . 161 . +--+ +--+ . 162 ..|R1|......|R2|.. 163 . +--+ +--+ . 164 . | 10Mb |\ . 165 . ------------ | . 166 . | . 167 . +--+ . 168 . |R4| . 169 . Area 1 +--+ . 170 .................. 172 Figure 2. Suboptimal inter-area routing 174 In this example router R2 has a 2Mb link to R5. At the same time R1 175 has a better link (10 Mbps), but R2 cannot route traffic going to 176 area 2 through R1. This is because according to [Ref1] R2 is not 177 allowed to consider summary-LSAs from non-backbone areas and, 178 consequently, does not have routes covering destinations in area 2 179 via R1. The situation looks even more interesting if R4's routing 180 table is considered. Since R2 floods summary-LSAs from R1 to R4, 181 router R4 will have routes to the area 2 via R1 (the best path), 182 expecting traffic to go via 10Mbps links. In reality R2 will not 183 direct traffic to R1, but will forward it via 2Mbps link attached to 184 itself. 186 The last example shows how the main principle of the OSPF---prefer 187 the shortest path---is broken due to distance vector approach used 188 for inter-area routing. Again, the problem can be fixed using the 189 virtual links between R1 and R2 in standard OSPF, but the solution 190 proposed in this document appears to be more elegant and involving no 191 administrative and traffic overhead. 193 2 Proposed Changes to ABR Behavior 195 This section describes two alternative implementations of ABR 196 behavior. The two solutions vary in details of Type 1 and Type 3/4 197 LSA origination, as well as routing table calculation. These details 198 are described below. Any other parts of standard OSPF are not 199 changed. 201 The first solution, named "short-cut ABR", is an improvement on 202 standard ABR behavior, based on relaxation of the restrictions 203 applied to the calculation of the inter-area routes. ABRs are allowed 204 to consider summary-LSAs from all attached areas (no matter if it is 205 connected to the backbone or not). The routing loop prevention is 206 done by restricting origination of summary-LSAs---inter-area routes 207 are readvertised only if there is a valid summary-LSA for the 208 destination learned from the backbone. Origination of summary-LSAs 209 for intra-area routes is done as in standard OSPF, described in 210 [Ref1]. 212 The relaxation of the routing table calculation allows router R3 in 213 the first example (Figure 1) to route traffic between the attached 214 areas, as well as to route traffic destined for the backbone and 215 other areas using the routes derived from the summary-LSAs in each 216 attached area. This approach also enables router R2 in the second 217 example to route inter-area traffic via R1. 219 The second solution, named "transit router", is targeted to the 220 situation when an ABR has no backbone connection. It implies that a 221 router connected to multiple areas without a backbone connection is 222 not an ABR and must function as a router internal to every attached 223 area. This solution emulates a situation where separate OSPF 224 processes are run for each area and supply routes to the routing 225 table. It only remedies the situation described in the first example 226 and only in the meaning of not dropping transit traffic. This 227 approach is not ideal, though, as a router following it does not 228 function as a real border router---it doesn't originates summary- 229 LSAs. Nevertheless such a behavior may be desirable in certain 230 situations. 232 Note that the proposed solutions do not obviate the need of virtual 233 link configuration in case an area has no physical backbone 234 connection at all (except for a stub area, as described in section 235 5). The methods described here improve the behavior of a router 236 connecting two or more backbone-attached areas. 238 Note also, that in the following two subsections, an "active backbone 239 attachment" means existence of at least one fully adjacent neighbor 240 in the area 0. 242 Though this document is initially oriented to processing Type-3 LSAs 243 and, consequently, is targeted to improving OSPF inter-area routing, 244 it's acceptable to apply described methods to Type-4 LSAs, which will 245 lead to improvement of external routing in an OSPF domain. 247 2.1 Solution 1 ("short-cut ABR") 249 The following changes are made to the base OSPF described in [Ref1]: 251 1. The algorithm of Type 1 LSA (router-LSA) origination is not 252 changed, the router still identifies itself as an ABR by setting 253 the bit B in its router-LSA when it has more than one attached 254 area. 256 2. The algorithm of the routing table calculation is changed to 257 allow the router to consider the summary-LSAs from all attached 258 areas. Note that if the router has no physical (from OSPF's 259 standpoint) interface in the backbone, it does not need to 260 consider summary-LSAs from the backbone, as in this case they are 261 received via the virtual links and the ABRs at the other ends of 262 the VLs already injected summary-LSAs into the transit areas. 263 Also, an ABR doesn't need to perform the calculations described 264 in the section 16.3 of [Ref1], as summaries from other ABRs in 265 the transit area are considered by the main algorithm. So, the 266 paragraph 1 of section 16.2 of [Ref1] should be read as follows: 268 "The inter-area routes are calculated by examining summary-LSAs. 269 If the router has active attachments to multiple areas, summary- 270 LSAs from all active areas must be considered, i.e., the router 271 must perform the inter-area route computation algorithm given 272 below for each attached area (one at a time). If all of the 273 router's links to the backbone are virtual, the router must run 274 the algorithm only for non-backbone areas. Routers attached to a 275 single area examine that area's summary-LSAs..." 277 3. The algorithm of the summary-LSAs origination is changed to 278 include an explicit restriction not to originate summary-LSAs for 279 inter-area routes if the router doesn't have a summary-LSA for 280 the destination from the backbone[1]. If the ABR in question has 281 no backbone connection, it will not originate summary-LSA for any 282 inter-area route in any area. The ABR will also not readvertise 283 an inter-area route from non-backbone area if its backbone link 284 state database does not contain a summary-LSA for the 285 destination. 287 In order to implement described policy, the paragraph 2 in 288 section 12.4.3 of [Ref1] should be read as follows: 290 "... Note that only intra-area routes are advertised into the 291 backbone, while both intra-area and inter-area routes are 292 advertised into the other areas. Also, summary-LSAs for inter- 293 area routes are originated if and only if the backbone area's 294 link-state database contains a valid summary-LSA for the 295 destination (to prevent loops of summary-LSAs)." 297 The 7th step of the algorithm given in sections 12.4.3 of [Ref1] 298 must be read as shown below: 300 "Else, the Destination type is network. If this is an inter-area 301 route then do a lookup in the backbone area's link state database 302 to find a summary-LSA for this destination. If there is no such 303 LSA---examine the next routing table entry. If the LSA was found 304 and the routing table contains an entry associated with the 305 backbone for the originating ABR, generate a Type 3 summary-LSA 306 for the destination..." 308 Described changes in the ABR behavior allow a multi-area connected 309 router to function as normal area border router, forwarding traffic 310 between attached areas and still not dropping the traffic destined 311 for the backbone and backbone-attached areas, not connected to the 312 router itself. In case this behavior is used when an ABR loses all 313 its backbone connections, the administrator doesn't need to configure 314 virtual links to other ABRs in the attached areas. This solution also 315 allows an ABR to consider inter-area routes provided by another ABRs 316 in the same area, thus fixing the situation described in the second 317 example in section 1. 319 2.2 Solution 2 ("transit router") 321 The following changes are made to the base OSPF, described in [Ref1]: 323 1. The algorithm of Type 1 LSA (router-LSA) origination is changed 324 to prevent a multi-area connected router from identifying itself 325 as an ABR by the bit B until it has at least one active backbone 326 attachment. The paragraph 3 in section 12.4.1 of [Ref1] must be 327 read is given below: 329 "...Bit B should be set when the router is actively attached to 330 two or more areas and if the router has at least one active 331 backbone attachment..." 333 Note, that as soon as the router finds itself actively connected 334 to the backbone, it must revert to standard OSPF ABR behavior, 335 including setting the bit B in its router-LSA and flooding it 336 through all attached areas (see section 2.3 for more details). 337 The router can also revert to the short-cut ABR behavior. 339 2. The algorithm of the routing table calculation is changed to 340 allow the router to consider the summary-LSAs from all attached 341 areas, as described in section 2.1 of this document. The router 342 is allowed to do this only if it doesn't have a backbone 343 connection. If it does, standard rules must be applied. 345 3. The algorithm of the summary-LSAs origination is changed to 346 prevent from originating summary-LSAs, i.e., to prevent a router 347 with multiple attached areas from acting as a real ABR until it 348 has an active backbone connection. 350 In order to implement described policy, the following sentence 351 must be added to the paragraph 2 in section 12.4.3 of [Ref1]: 353 "...Also, if none of the actively attached areas is the backbone, 354 then the router must refrain from summary-LSA origination until 355 it has at least one active backbone connection. " 357 The changes in the ABR behavior described in this solution allow a 358 multi-area connected router to successfully route traffic destined 359 for the backbone and other areas. The difference from the first 360 solution is that the router does not actively attract inter-area 361 traffic, because it does not originate summary-LSAs. It still can 362 forward traffic from one attached area to another along intra-area 363 routes in case other routers in corresponding areas have the best 364 inter-area paths over it, as described in section 1.2. 366 Note, that when a router, following this strategy, finds an active 367 backbone connection, it can start acting as either standard or 368 short-cut ABR. 370 2.3 Handling Transitions 372 While the "short-cut ABR" solution does not imply changes of LSA 373 origination and routing table computation depending upon the backbone 374 connection state, the "transit router" approach requires special 375 processing when the router finds a connection to the backbone or 376 loses the last one. 378 2.3.1 First backbone adjacency found 380 The actions given below must be performed after an adjacency on an 381 interface that belongs to the OSPF backbone has reached the state 382 Full and this is the first full adjacency in the backbone. 384 1. If the current behavior strategy is the "transit router", then 385 do the following: 387 a) reconstruct the router-LSAs for all area databases, setting 388 the bit B to 1. 390 b) flood the new router-LSA to all neighbors according to 391 [Ref1]. 393 c) if the router must revert to the standard ABR behavior--- 394 schedule the routing table recalculation for all areas to 395 get rid of the inter-area routes through non-backbone areas. 397 2. Else, the behavior strategy is the "short-cut ABR" and nothing 398 must be done. 400 2.3.2 Last backbone adjacency lost 402 The actions given below must be performed when the router loses the 403 last adjacency in the OSPF backbone and all of the adjacencies in the 404 backbone area are in the state lesser than ExStart. 406 1. If the target behavior strategy is the "transit router", 407 then do the following: 409 a) reconstruct the router-LSAs for all areas, setting the bit B 410 to 0. 412 b) flood the new router-LSA to all neighbors according to 413 [Ref1]. 415 c) schedule the routing table recalculation to install the 416 inter-area routes via non-backbone areas. 418 d) flush all locally originated summary-LSAs from all non- 419 backbone areas. 421 2. Else, the target behavior strategy is the "short-cut ABR" and 422 nothing must be done. 424 3 Implementation Details 426 If the current implementation of OSPF uses the standard described in 427 [Ref1], then support of the proposed ABR behavior strategies must be 428 implemented as a configurable option, allowing to specify two types 429 of the strategies---the first one (standard, short-cut or transit) to 430 instruct the router how to behave without a backbone connection, and 431 the second one (standard or short-cut) to instruct the router how to 432 behave when it has a backbone connection. 434 The default value of the second behavior strategy (with a backbone 435 connection) must be standard, while the default for the first 436 strategy can be either of the values. If the implementation 437 originally follows one of the alternative behaviors, there must also 438 be an option to revert to the standard one. 440 4 Compatibility 442 The changes of the OSPF ABR operations do not influence any aspects 443 of the router-to-router cooperation and do not create routing loops, 444 and hence are fully compatible with standard OSPF. Proof of 445 compatibility is outside the scope of this document. 447 5 Deployment Considerations 449 This section discusses the deployments details of the ABR behaviors 450 described in this document. Note that both approaches are fully 451 compatible with standard ABR behavior, so ABRs acting as described in 452 [Ref1] and in this document can coexist in an OSPF domain and will 453 function without problems. 455 Considerations of short-cut ABR and transit router deployment are 456 given in separate subsections below. 458 5.1 Short-cut ABR 460 5.1.1 Necessity of virtual links 462 First of all it should be repeated that short-cut ABR behavior does 463 not obviate the need for virtual links in case an area has no 464 physical backbone connection except for a stub area (see section 465 5.1.4). The difference with standard OSPF is that the administrator 466 does not need to configure virtual links through all areas he or she 467 wants the inter-area traffic to go through. A short-cut ABR needs a 468 single backbone connection (physical or virtual) to achieve optimal 469 routing, since it considers summary-LSAs from all attached areas. 471 5.1.2 Change of traffic patterns 473 Use of short-cut ABR can lead to changes in the paths inter-area 474 traffic flows take comparing to those experienced with standard OSPF. 475 This happens because the short-cut ABR approach allows a router to 476 find paths better than it is possible with the standard OSPF. While 477 standard OSPF tries to forward all inter-area traffic through the 478 backbone area (though it does not guarantee it), the short-cut ABR 479 finds best routes in the domain even across non-backbone areas. With 480 short-cut ABR the backbone area is used as a dedicated place of 481 inter-area routing information exchange and inter-area traffic is 482 allowed to cross non-backbone area borders if such a path is really 483 the best. 485 5.1.3 Optimized inter-area routing 487 Use of short-cut ABR improves inter-area routing in OSPF domains by 488 allowing ABRs to consider summary-LSAs from all attached area and 489 consequently readvertise them into non-backbone areas. Consider an 490 example show in the Figure 3: 492 ....................... 493 . Backbone . ......... 494 . . . . 495 . +--+ +--+ . 496 . |R1| |R5|--| . 497 . +--+ +--+ 1| . 498 . 8/ 8\ 1/ . | . 499 . / \ -------- . | . 500 . 8/ 8\ /1 1\ . | Net N . 501 .+--+ +--+ +--+ 1| . 502 ......|R2|.....|R3|.......|R4|--| . 503 . +--+ +--+ +--+ . 504 . .|1 1/ \1 1/ . . Area 3 . 505 . .-------- -------- . .......... 506 . . . 507 . . . 508 .Area 1 . Area 2 . 509 ....... ................... 511 Figure 3. Optimized inter-area routing 513 In case all ABRs use standard OSPF approach, routing to the net N 514 would be as follows: 516 - R4 and R5 inject summary-LSAs into the backbone 517 - R4 also inject a summary-LSA into area 2 519 - R3 is limited to consider summary-LSAs from the backbone only, 520 so it doesn't see the alternative path through area 2 and always 521 routes through the backbone (though parallel paths are available) 523 - R3 injects summary-LSA for the inter-area routes derived from the 524 backbone summary-LSAs and received from R4 and R5 into Area 2 526 - R2 is not allowed to consider non-backbone summary-LSAs and routes 527 via serial links to R2, though more optimal paths do exist 529 If at least R2 and R3 use short-cut ABR approach inter-area routing 530 is improved as shown below: 532 - R4 and R5 inject summary-LSAs into the backbone 534 - R4 also inject a summary-LSA into area 2 536 - R3 considers summary-LSAs from both attached areas and installs 537 the route through area 2 (it has three routes in the routing 538 table---via R5, via R4 through the backbone, and via R4 through 539 area 2) and performs traffic sharing between the two ethernet 540 links. 542 - R3 injects summary-LSA for the inter-area routes to N (it will be 543 the same as in the previous case, actually) 545 - R2 considers summary-LSAs from all attached areas and prefers the 546 route through area 2 rather than the backbone. 548 5.1.4 Connecting a stub area with a short-cut ABR 550 Short-cut ABRs can be used to connect a stub area to another non- 551 backbone area without a virtual link configured on the ABR. One 552 restriction that is applied to such a scheme is that the stub area 553 must use default routing for both external and inter-area 554 destinations. Consider Figure 4. 556 . Backbone . 557 . +--+ . 558 .......|R1|....... 559 . +--+ . 560 . . 561 . Area 1 . 562 . . 563 . +--+ . 564 .......|R2|....... 565 . +--+ . 566 . . 567 . Stub Area 2 . 568 . . 569 .................. 571 Figure 4. Connecting a stub area with short-cut ABR 573 With standard OSPF router R2 would need to have a virtual link with 574 R1, because otherwise R2 would have no inter-area routes (OSPF 575 standard would limit R2 to consider only backbone summary-LSA while 576 calculating its routing table) and would drop all traffic going out 577 of the stub area 2. If short-cut ABR approach is used, R2 is allowed 578 to consider summary-LSAs injected into area 1 by R1, so R2 is not 579 required to have a virtual link to the backbone. Without it R2 is not 580 allowed to readvertise inter-area routes into the stub area, but the 581 default summary injected by each ABR connected to a stub area can do 582 the job in most cases. 584 5.2 Transit router 586 Deployment of ABRs using the transit router behavior is limited to 587 the situations where the ABR does not need to perform actual inter- 588 area routing, though in certain circumstances inter-area traffic will 589 be routed from one attached area to another. This can lead to 590 unexpected routing asymmetry, as described below. 592 5.2.1 Possible asymmetry in inter-area routing 594 Consider an OSPF domain depicted in Figure 5. 596 ....................... 597 . Backbone . 598 . . 599 . --------------------- . 600 . |1 1| . 601 ..+--+.............+--+.. 602 ..|R1|..... ....|R4|.. 603 . +--+ . . +--+ . 604 . 1| . . /4 . 605 . | 8 +--+ 4 / . 606 . | +-|R3|---+ . 607 . 1| / +--+\4 . 608 . +--+ / . . \ 4 +--+ . 609 . |R2|/8 . . +--|R5| . 610 . +--+ . . +--+ . 611 . | . . | . 612 . --------- . . -------- . 613 . net N . . net M . 614 . . . . 615 . Area 1 . . Area 2 . 616 ........... .......... 618 Figure 5. Inter-area routing asymmetry 620 Assume that R3 uses the transit router approach. In this case R2 will 621 have inter-area routes to network M via ABR R1 only. R5 in turn will 622 have its inter-area route to network N via R4, but as far as R4 is 623 only reachable via R3, all traffic destined to network N will get 624 into R3. R3 will have an intra-area route to network N via R2 and 625 will, of course, route it directly to it (because intra-area routes 626 are always preferred over inter-area ones). Traffic going back from 627 network N to network M will get into R2 and will be routed to R1, as 628 R2 will not have any inter-area routes via R3. So, traffic from N to 629 M will always go through the backbone while traffic from M to N will 630 cross the areas directly via R3 and, in this example, will not use a 631 more optimal path through the backbone. Note that this problem is not 632 caused by the fact that R3 uses the transit router approach, in fact 633 it would remain even in case of short-cut ABR. The reason for 634 attracting the attention to it is that R3 is not really functioning 635 as an ABR in case the transit router behavior is used, i.e., it does 636 not inject summary-LSAs into the attached areas, but inter-area 637 traffic can still go through it. 639 6 Footnotes 641 [1] In standard OSPF, it is implicitly prohibited for an ABR to 642 originate summary-LSAs for inter-area routes via non-backbone 643 area by limiting an ABR consider only backbone summary-LSAs when 644 calculating the routing table. As far as we relaxed the 645 restriction of the routing table calculation, we need to 646 introduce a similar one for summary-LSA origination. 648 7 References 650 [Ref1] J. Moy. OSPF version 2. Technical Report RFC 2328, Internet 651 Engineering Task Force, 1998. ftp://ftp.isi.edu/in- 652 notes/rfc2328.txt. 654 8 Author's Address 656 Alex D. Zinin 657 AMT Group 658 8 Maly Znamensky per., bld. 1 659 Office 3b 660 121019 Moscow, Russia 662 Phone : (7-095) 725-76-60 663 Fax : (7-095) 725-76-63 664 E-mail: zinin@amt.ru