idnits 2.17.1 draft-ietf-ospf-deploy-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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 1097 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract 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. ** There are 31 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 53: '...static routes) MUST IMPLEMENT OSPF.....' RFC 2119 keyword, line 54: '...router MAY implement additional IGPs."...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 53 has weird spacing: '... static rout...' == Line 131 has weird spacing: '... static route...' == Line 383 has weird spacing: '...areas within ...' == Line 826 has weird spacing: '...support that...' == Line 885 has weird spacing: '...route to the ...' == (1 more instance...) -- 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 (June 1999) is 9081 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) == Missing Reference: 'RFC2401' is mentioned on line 780, but not defined ** Obsolete undefined reference: RFC 2401 (Obsoleted by RFC 4301) == Unused Reference: 'RFC1812' is defined on line 1064, but no explicit reference was found in the text == Unused Reference: 'RFC2328' is defined on line 1068, but no explicit reference was found in the text == Unused Reference: 'Moy 1998' is defined on line 1080, but no explicit reference was found in the text == Unused Reference: 'Thomas' is defined on line 1083, but no explicit reference was found in the text -- No information found for draft-berkowitz-multirqmt - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Multihome' -- Possible downref: Non-RFC (?) normative reference: ref. 'Moy 1998' -- Possible downref: Non-RFC (?) normative reference: ref. 'Thomas' Summary: 9 errors (**), 0 flaws (~~), 13 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group 2 Berkowitz 3 Internet Draft 4 Communications 5 Expiration Date: January 2000 6 June 1999 8 Techniques in OSPF-based Network 9 Deployment 10 draft-ietf-ospf-deploy-00.txt 12 Status 13 of this Memo 15 This document is an Internet-Draft and is in full 16 conformance with all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as ``work in progress''. 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 33 1. 34 Abstract 36 OSPF is the preferred interior routing protocol of the Internet. 37 It is a complex protocol intended to deal with complex networks. While it 38 is a powerful mechanism, it does not handle all situations, and 39 its appropriate use may not be obvious to beginners. Standards track 40 documents deal with protocol design, but deployment of OSPF in many 41 enterprise networks has been limited by lack of information on best current 42 practice information for interior routing. Best Current Practices 43 documents have focused on general exterior connectivity. This memorandum is 44 intended to complement the protocol specification by describing the 45 experience-based, vendor-independent techniques of OSPF and complementary 46 technologies in representative networks. Better understanding of the use 47 of OSPF features to help exterior connectivity will help reduce the demand 48 for complex user BGP configuration. 50 2. Introduction 52 RFC1812, Requirements for IPv4 Routers, says "a router that implements any 53 routing protocol (other than static routes) MUST IMPLEMENT OSPF... A 54 router MAY implement additional IGPs." This is a well-crafted 55 statement, as it recognizes that static may be a useful complement to OSPF. 56 All too often, network operators work from the limiting belief that if they 57 use OSPF, it must run everywhere in their networks. They see the two-level 58 hierarchy suggested by an Area 0 and a subordinate set of nonzero areas, 59 and assume that networks using OSPF must be strictly hierarchical with only 60 two hierarchical levels. 62 3. Barriers to Understanding OSPF Deployment 64 Some terminology used in OSPF documents may not match more recent usage, or 65 may be confusing to a reader encountering them the first time. OSPF, for 66 example, uses the term "autonomous system" differently than the most recent 67 BGP-oriented usage. OSPF's usage is discussed below. 69 In addition, the first-time reader should be careful to understand OSPF's 70 use of the concept of external routes. Another point is not to confuse 71 the hierarchy in a specific OSPF domain with the overall hierarchy of the 72 enterprise in which it is used; you are not limited to the two apparent 73 levels of OSPF, backbone versus non-backbone. 75 3.1 OSPF and Autonomous 76 Systems 78 OSPF specifications assume an enterprise's set of networks equate 79 to an 80 autonomous system. These specifications use the term autonomous 81 system 82 in a manner inconsistent with the current usage, which speaks of an 83 AS 84 in terms of exterior routing. RFC1930 defines an AS as a set 85 of 86 routers, under one or more administrations, that presents a 87 common 88 routing policy to the global Internet. 90 It is useful to define an 91 OSPF domain as an Area 0 and some number of 92 nonzero areas. In the broader 93 sense, a routing domain is a set of 94 routers, with a common set of routing 95 mechanisms and routing policies, 96 under a single administration. 98 A general 99 observation: OSPF has a terminology problem here. "Inter- 100 zone" 101 communication is the role of what OSPF calls a "Autonomous System 102 Border 103 Router," but the "zones" don't need, in reality, to be distinct 104 AS. A term 105 from the routing literature that probably is more recognized 106 than "AS" or 107 "zone" is "routing domain." 109 OSPF has a built-in mechanism for connecting 110 different domains, the 111 ASBR. ASBRs interconnect routing domains. Any 112 OSPF router 113 that advertises external routes is an ASBR. Examples 114 include: 116 1. An OSPF process that accepts routes from another separate 118 OSPF process: 120 2. An OSPF process that accepts routes from another 121 dynamic interior 122 routing process: 124 Another option is to have 125 static routes going to an 126 enterprise core network 127 from each 128 OSPF Area 0, such that the Area 0's advertise the default 129 route into 130 their subordinate areas, but the ASBR containing the 131 static route 132 advertises the default into Area 0. 134 3. An OSPF process that accepts 135 static routes and advertises the 136 default. 138 4. An OSPF process 139 that accepts routes from a BGP exterior routing 140 process and 141 advertises them into OSPF. Details of this are 142 not shown, because 143 configurations involving redistribution to 144 and from OSPF usually 145 involve fairly complex filtering and other 146 mechanisms to avoid loops 147 and injections of huge numbers of 148 routes. 150 3.2 Thinking about 151 Externals 153 The path determination workload of an OSPF area is influenced 154 most 155 strongly by the number of network, summary, and external LSAs 156 involved 157 in the routing computation. The various stub area schemes, stub, 158 not- 159 so-stubby, and the vendor-specific totally stubby, all help when a 160 large 161 number of externals would be injected into an area. 163 In medicine, 164 there is a classic piece of advice from a physician to a 165 patient who 166 complains that some odd movement of his arm hurts: if that 167 hurts, don't do 168 it. If the nature of a routing environment is such that 169 large numbers of 170 externals do not exist, then there is no benefit to 171 exploring stub area 172 techniques to control the propagation of externals. 174 Most beginners tend to 175 think of floods of externals into OSPF due 176 primarily to Internet 177 connectivity. They imagine nearly 50,000 routes of 178 a current Internet 179 default-free routing table overwhelming their 180 routers. In practice, it 181 would be extremely unlikely to find any 182 significant benefit would come from 183 injecting such a table into the OSPF 184 routing system. In most cases, no 185 more than a default route needs to 186 injected to achieve connectivity. Even 187 if preferential exits for 188 certain exterior destinations are desired, that 189 is more likely to be an 190 Interior BGP problem than an OSPF one. 192 In 193 practice, a major source of external routes can come from one's 194 own 195 enterprise, as part of a migration from RIP or IGRP, or 196 from 197 static/default routes used to connect edge routers to the main 198 routing 199 system. Another way to think of this is that large numbers of 200 external 201 routes can come from other routing domains in your own 202 organization. 204 If the intra-organizational external routes are injected 205 into OSPF 206 through ASBRs connected to Area 0, stub techniques may be 207 effective in 208 controlling the number of externals that impose workload on 209 nonzero 210 areas. Even in this case, do summarize the externals as much 211 as 212 possible. 214 More challenging situations arise when the 215 intra-organizational routes 216 come in at the edge of a nonzero area. 217 Assume, for example, that an 218 organization has a large number of small 219 offices, each with a single 220 frame relay PVC that carries its traffic to the 221 next level of the 222 corporate routing hierarchy. Each of the small edge 223 routers needs a 224 default route toward the next level. 226 The next level, 227 however, is composed of OSPF-speaking routers. Even though 228 they are in a 229 nonzero area, they are still ASBRs. Since these routers will 230 not speak OSPF 231 to the edge routers, these second-level routers will need to 232 have static 233 routes that point to these edge subnets, and then the static 234 routing 235 information needs to be advertised as external routes into OSPF. 236 Remember 237 that these externals can be summarized on the ASBR. 239 3.3 Hierarchy and 240 OSPF 242 It should never be forgotten there are two ways to achieve hierarchy 243 and 244 aggregation: address summarization, and physical topology. Many 245 newcomers 246 to OSPF think only of the first, since OSPF summarizes on ABRs 247 and ASBRs. 248 This leads to an incorrect assumption that OSPF has at best 249 three levels of 250 hierarchy: 252 1. Intra-area 253 2. Inter-area 254 3. 255 External 257 It is true that reduction in routing information and consequent 258 reduction 259 of the routing computation workload only can come at these 260 levels. But 261 there are other benefits of hierarchy, such as minimizing hop 262 count, 263 simplifying debugging as opposed to complex meshes, etc. 265 Inside a 266 nonzero area, it is perfectly reasonable to have a hierarchy of 267 internal 268 routers, leading up to area border routers at the apex of the 269 area 270 hierarchy. Several small OSPF speakers at "branch offices" might 271 single- 272 or dual home to "district level" interior routers. Groups of 273 district 274 routers might in turn single or dual home to regional routers, and 275 groups 276 of regional routers might single or dual home to area border 277 routers. 279 Hierarchy can begin anew inside area 0. ABRs can be 280 concentrated 281 topologically by homing to backbone routers, and the backbone 282 routers may 283 in turn home on ASBRs. 285 A higher-level, non-OSPF core network 286 may usefully link the top 287 hierarchical ASBRs of multiple OSPF routing 288 domains. Such a core network 289 could be statically routed or use BGP. 291 3.4 292 Virtual Links 294 A virtual link is a tunnel that has at least one end in Area 295 0. Virtual 296 Links (VL) are a mechanism that can be used within OSPF to 297 handle 298 certain connectivity patterns. The standard is a bit "soft" on 299 their 300 applications, and support engineers have seen a variety of 301 VL 302 applications. For some of the problems being raised, it appears 303 better 304 OSPF solutions may exist. 306 A matter of particular interest is the 307 potential advantages of NSSAs 308 over some of the VL solutions to bringing in 309 a new "community of 310 interest." See the discussion below of VL 311 applicability in other than 312 backbone robustness. 314 The perception of virtual 315 links' untility seems to be as a means of 316 accomodating specical 317 connectivity requirements "inside" a single "OSPF 318 domain," the latter 319 defined as a set of an Area 0 and some number of 320 nonzero areas. 322 In some of 323 these requirements, virtual links may be completely 324 appropriate, one of 325 several potential solutions, or definitiely not an 326 appropriate 327 solution. 329 Some designers may use virtual links to avoid other mechanisms 330 that they 331 do not like, such as defining the enterprise's network with 332 multiple 333 interconnected OSPF domains. 335 Virtual links are not necessarily 336 the appropriate solution, but cases 337 have been seen where they are used 338 for: 340 --- Protecting against Area 0 partitioning 341 --- Making one 342 area 0 following the merger of two enterprises, 343 both of which ran 344 independent OSPF 345 --- Providing connectivity to a newly acquired 346 enterprise 347 whose best connectivity is to a router in a nonzero 348 area 349 of the acquiring enterprise 351 4. Area Sizing and Numbering 352 Strategies 354 4.1 Communities of Interest 356 Select a set of clients and 357 servers that primarily speak to one another. 358 Is the number of routers 359 required, after growth projections have been 360 applied, less than the 361 vendor-recommended limit? 363 Let's review basic OSPF, emphasizing points that 364 can help establish 365 hierarchies of more than two levels. Let's also review 366 some sizing 367 considerations for areas, bearing in mind 368 that this can be as 369 much art and science. Experienced routing designers 370 know they won't always 371 hit the correct area structure, and expect to 372 have to monitor and tune the 373 design of a large OSPF system. Especially 374 experienced routing designers 375 know this tuning will primarily involve 376 topology and bandwidth, rather than 377 "knob twisting" for timers and 378 buffers. 380 The guideline about limiting the 381 number of nonzero areas in an ABR, in 382 practice, means that large numbers of 383 areas within a single OSPF system 384 tend to require large and expensive 385 numbers of ABRs. This is especially 386 true attempting to avoid a single point 387 of failure -- a single ABR -- 388 per area. 390 Many factors go into choosing the 391 number of OSPF speakers inside an 392 area. A few conservative guidelines for 393 these and other sizing 394 considerations: 396 1. Begin setting up area 397 definitions based on communities of interest. 398 It is highly desirable if the 399 majority of traffic can stay intra-area. 401 2. Do not exceed your vendor 402 guidelines on routers per nonzero area. 403 Counts from 50 to 200 routes are 404 often cited, although much larger numbers 405 have worked in specific 406 environments. Use the lower numbers when media 407 tend to "bounce" up and 408 down. As we will see below, this doesn't preclude 409 a large number of 410 routers in what can be considered an area, because the 411 "stub" routers need 412 not speak OSPF. 413 This is conservative, and many vendor 414 implementations have wored 415 well with larger numbers of OSPF speakers per 416 area. The specific limit will 417 vary with the OSPF software implementation, 418 the processing power of the 419 router platform, and the size and stability of 420 the topological database. 421 If areas defined on community of interest 422 contain too many routers 423 under rule #2, consider splitting the area. Look 424 for geographic/provider 425 natural boundaries for splitting. 427 3. Think 428 carefully about the relationships you want between the 429 backbone and each 430 non-backbone area. Some small OSPF environments put 431 everything into Area 432 0. This can be reasonable if the only reasons for 433 using OSPF are fast 434 convergence and flexible addressing among a small set 435 of routers. The 436 power of OSPF is only fully realized with multiple areas. 438 4. Area 0 is 439 intended as a transit area. Capacity planning and 440 troubleshooting tend to 441 be easiest when there are no application servers in 442 area 0. Given the 443 connectivity of area 0, it may be reasonable to place 444 network management or 445 DNS servers there. 446 If the application topology is hierarchical, as 447 might be found where 448 a mainframes or server farms provides most application 449 services, still use 450 caution in putting this server in area 0. Mainframes 451 or server farms often 452 have local inter-server communications, such as 453 backup, that should be kept 454 out of area 0. It may be wise to put the 455 central servers in a small area 456 of their own. 458 5. Several techniques 459 exist for setting up areas and controlling 460 advertisements in and out of 461 them. You don't need to use the same 462 techniques in every nonzero area. 463 Remember that you don't use these 464 simply to reduce the amount of routing 465 traffic, but also for stability. 466 Stability increases as the number of 467 routing table recomputations 468 decreases. 470 Summarization and the various 471 kinds of stub areas reduce routing table 472 recomputation by hiding specific 473 routes. In other words, an 474 interior router in Area 1, doesn't need to 475 recompute the Area 1 476 routing table if a link goes up or down in Area 0. 477 Media, especially, 478 have a habit of bouncing up and down; hiding links 479 outside my area 480 reduces "route flapping" leading to recomputation. 482 An Area 483 Border Router between Area 1 and Area 0 probably needs 484 to know if a link 485 in Area 0 changes state, but it doesn't need to 486 know if a link in Area 51 487 changes state. The exception to this case is 488 where finding the absolutely 489 optimal path from Area 1 to Area 0 to Area 51 490 is more important than 491 stability. This might be the case in some 492 international networks with 493 low-bandwidth links. 495 The reason to use the less general types of areas is 496 they allow reducing 497 the amount of routing information advertised from the 498 backbone into 499 nonzero areas. 501 Inside a given area, be it backbone or 502 non-backbone, there can be a 503 hierarchy among OSPF speakers. For example, 504 it is perfectly reasonable 505 to reduce the peering in the backbone by 506 connecting the Area 0 side of 507 ABRs to "collapsed backbone" router(s). In 508 large 509 networks, it can avoid problems due to excessive numbers of neighbors 510 to 511 any given Area 0 router. 513 4.2 Numbering 515 There is a widespread 516 misperception that areas will only work with a single 517 contiguous address 518 range. Even a small amount of summarization, however, 519 will considerably 520 increase the stability of OSPF systems because it hides 521 route flap. 523 A 524 common recommendation, assuming that a single contiguous block, such as 525 an 526 /18 prefix is given to the enterprise, is to "bit split" the prefix 527 such 528 that the first high-order bits below the global prefix identifies the 529 area. 530 For a routing domain with four nonzero areas, this would allocate a 531 /20 532 prefix to each area: 534 /20 starting 00xxxx... area 1 536 starting 01xxxx... area 2 537 starting 10xxxx... area 3 539 starting 11xxxx... area 4 541 This approach seems straightforward, but 542 suffers from several limitations. 544 First, what about area 0? No space has 545 been left for it. In any case, it 546 is likely that a /20 assigned to area 0 547 would waste a great deal of space, 548 since area 0 should have a small number 549 of router interfaces in it. 551 One technique when using the bit-split method, 552 and assuming registered 553 addresses are used in the nonzero areas, is to use 554 RFC1918 private address 555 space for area 0. This can be quite reasonable, 556 because there are few 557 legitimate reasons why an arbitrary external Internet 558 host would need to 559 access a backbone interface internal to an enterprise 560 network. One 561 possible criticism of this approach is that traceroutes that 562 traversed the 563 backbone might show the private address space, but it is 564 usually apparent 565 when this is happening. Another reason why area 0 566 interfaces might need 567 registered addresses is that the management of the 568 network is outsourced. 569 In outsourcing situations, the service provider 570 commonly can assign some of 571 its allocated address space for interfaces it 572 will manage, 574 Another and more general approach is to bit-split to a level 575 deeper than 576 the number of areas. In the example above, there were 4 nonzero 577 areas, and 578 4 /20 blocks. The /20 comes from it being the first power of two 579 that can 580 contain 4 areas. 582 Consider, however, going 2 or 3 powers of two 583 deeper. Divide the available 584 address space into 8, 16, or 32 blocks. These, 585 respectively, would be /21, 586 /22, or /23 address prefixes. 588 One of these 589 blocks can be assigned to Area 0. It is a reality that the 590 number of users 591 in individual areas will vary, so area 1 might, for 592 example, need three /21 593 blocks, area 2 might need two such blocks, area 1 594 might need one. Several 595 blocks can be reserved for growth as needed. 597 These blocks can still be 598 summarized to avoid route flap. 600 5. Increasing Backbone Reliability 602 A 603 failure in Area 0 is critical. 605 A single Area 0 has a single point of 606 failure. Hopefully, the ASCII 607 graphic shows this. Area 0 has two 608 interconnected Border Routers, BR1 609 and BR2. To avoid single router points 610 of failure, there are two ABRs, 611 each with three interfaces: Area 0, Area 612 1, and Area 2. 614 5.1 VL Solution 616 If the BR1-BR2 link fails, a VL can be 617 defined between the Area 1 618 interface of ABR-1 and between the Area 1 619 interface of ABR-2. This 620 reconstitutes backbone connectivity with a tunnel 621 through Area 1. 623 BR1------------------------------------------BR2 624 \ 625 / 626 \ ...to BR2 / 628 ABR-1 ABR-2--/ ABR-3 630 ========================================================= 632 | | | * | 633 | |------- * 634 | 635 | VL? * | 637 | * | 638 v * 639 v 640 Area 1 * Area 2 642 5.2 643 Alternative using Adding Circuit(s) 645 The preferred way to solve this 646 problem is adding a parallel link 647 between BR1 and BR2. Especially if 648 these links can be per-packet load 649 balanced, convergence would be extremely 650 fast. 652 This solution, however, incurs additional cost for the 653 additional 654 circuit. Balanced against this cost is the performance impact 655 the VL 656 would have on the routers and links in the nonzero area through 657 which 658 the VL is tunneled. Those routers and links may have been engineered 659 for 660 the traffic estimates and performance goals under the workload of 661 that 662 single area, not of that area with backbone traffic added to it. 664 5.3 665 Alternative using non-OSPF network 667 An alternative approach, especially 668 useful if demand OSPF is not 669 available, is to split Area 0 and create two 670 OSPF domains. Each domain 671 has a static route that points to the address 672 range in the other domain. 673 This route is advertised into the local domain 674 as a Type 1 external. 676 6. Backbones of Backbones 678 The method described in 679 5.3 above can be generalized to give more 680 effective levels of hierarchy in 681 an overall network that uses OSPF for 682 its dynamic routing. 684 True, OSPF's 685 area structure has two levels, Area 0 and everything else. 686 A routing 687 architecture for an enterprise that uses OSPF, however, can be 688 more than a 689 simple hierarchy of backbone and non-backbone areas. We can 690 extend its 691 notion of hierarchy both above Area 0 and below the nonzero 692 areas. Even 693 inside an area, there are some forms of hierarchy. 695 Such an architecture 696 also lends itself to evolution to a high-performance 697 layer 2 or Multiprotocol Label Switching (MPLS) service in 698 the core. It can 699 also be reasonable to have interior routers that 700 "concentrate" traffic, or 701 act as collapsed backbones within an area. 703 It is also perfectly reasonable 704 to have a broader OSPF routing 705 environment, in which some routers do not 706 speak OSPF but cooperate with 707 those that do. At the "high" end, this 708 involves redistribution of 709 external routes into OSPF. At the "low" end, 710 this involves static and 711 default routes from stub routers to the lowest 712 level of OSPF router 713 inside a nonzero area. Let's talk about the lowest 714 level first. 716 The lowest level is a "stub" or "edge" router with a single 717 outgoing 718 path, such as a branch office router with several LAN links, 719 perhaps a 720 STUN serial interface for IBM support, and a single WAN link. 721 There are 722 no routers on any of the LANs. 724 Such a router really doesn't need 725 to run any dynamic routing protocol. 726 It should default to a higher-level 727 router. 729 Assuming the higher-level router has multiple links going toward 730 the 731 backbone, that router does need to run OSPF. It doesn't need to 732 connect 733 directly to the backbone. 735 7. Transition and Network 736 Consolidation 738 A management imperative that often occurs after the merger 739 of two 740 enterprises is eliminating the "expense of duplicate backbones." At 741 a 742 slighly more technical level, this means an OSPF design that has a 743 single 744 Area 0. 746 Among many OSPF users, it is a matter of faith and morals that there 747 entire 748 enterprise appear as a single OSPF domain. As a consequence, 749 I've seen 750 designs with a single area 0 spanning serveral continents, 751 with each 752 continent having significantly different line quality and 753 speed, needs for 754 demand backup circuits between parts of the area, etc. 756 Two companies, A, 757 and B, merge. Each has an existing OSPF system, with 758 its own area 0. 759 These Area 0s are widely separated geographically, but 760 they each have an 761 Area 1 whose boundaries are in fairly close proximity. 762 Each ABR has a 763 single interface to Area 0. 765 In designing solutions, engineers should consider not only pure OSPF 766 mechanisms, but the use of non-OSPF tunneling mechanisms. OSPF virtual 767 links are, of course, appropriate for some topologies. 769 Also, consider having separate OSPF domains linked into a "backbone of 770 backbones," using static or BGP routing among the domains. 772 7.1 Non-OSPF tunneling 774 Generic Route Encapsulation (GRE) can solve numerous OSPF topology 775 problems, both in backbone area 0.0.0.0 and in non-backbone areas. GRE is 776 appropriate 777 when the underlying transmission infrastructure is considered adequately 778 secure. If, however, the traffic needs to cross the untrusted global 779 Internet, 780 IPsec tunnel mode [RFC2401] may be more appropriate. 782 Let's say that the 783 two companies merge, and want to put their Western Region into the same area 784 because the geographic divisions will share a good deal of information that 785 does not need to cross the backbone. 787 Both areas, of course, could be connected separately to area 0.0.0.0. There 788 might not be sufficient backbone bandwidth to carry the combined Western 789 Region traffic. 791 If there were a management directive to merge these areas immediately, and 792 dedicated WAN circuits between them were not immediately available, an 793 alternative could be to tunnel between them. The next design issue would 794 be deciding if the tunnels need to be secure. Tunneling, of course, will 795 add overhead bytes to every routed packet, and will also impose additional 796 processing workload on the routers at the endpoints of the tunnel. 798 In spite of the overhead it produces, tunneling may still be a good 799 interim step to achieving desired connectivity during network redesign. 800 OSPF has its own tunneling mechanism for routing information, the virtual 801 link, which is appropriate for other topological problems. 803 7.2 Solution using VLs 805 The two companies perceive they want "a single 806 backbone". They do not 807 wish to renumber every network and router, but are 808 willing to merge two 809 nonzero areas if that were helpful. They are also 810 unwilling, at the 811 present time, to merge their two backbones, principally 812 due to the 813 geographic distance between them. 815 They merge their Area 1's, 816 renumbering appropriately adding physical 817 connectivity between the company 818 A area 1 and the company B area 1. They 819 now have a common Area 1, and then 820 define a VL between the two ABRs. 822 There is now a "single backbone." 823 Potentially, a large amount of 824 inter-area traffic now flows through the 825 combined Area 1. Neither Area 826 1 presumably was designed to support that 827 flow, but that of the traffic 828 of the community of routers for which it 829 originally was built. 831 7.3 An Alternate Solution using External Links 832 between the Area 0's 834 Do not attempt to create a single Area 0. Rather 835 than trying to merge 836 the backbones or the area 1's, define an ASBR function 837 in each Area 0 838 that has one or more static (or even BGP) routes to the ASBR 839 of the 840 other Area 0, and vice versa. Each ASBR advertises the default, and 841 may 842 or may not advertise the external routes to the other Area 0. 843 Doing 844 this requires adding one or more links between A-Area 0 and B-Area 845 0. 847 This requires no changes to any of the nonzero areas, which still 848 can 849 default to their existing Area 0. If tuning or topology changes 850 are 851 needed to handle traffic flows, most of this can be done at the 852 core 853 tier. Such tuning would involve a smaller set of routers not 854 directly 855 connected, in most cases, to end systems. 857 The core tier now 858 consists of two Area 0's and a set of links between 859 them. 861 7.4 An Alternate 862 Solution using Two Area 0's 864 Both companies have OSPF, but topological or 865 other factors make it 866 difficult to make a direct connection between Area 867 0s. In this case, 868 establish a Company B ASBR that will advertise Company B 869 routes to 870 Company A. This ASBR might be on the Company B Area 0, or in 871 another 872 area. In either case, it advertises routes to the other ASBR, 873 using 874 multiple static routes or BGP. 876 The company A ASBR can generate a 877 default and advertise Company A 878 addresses to Company B, using appropriate 879 filtering. If the Company A 880 ASBR is in a non-zero area, NSSA may be 881 appropriate. 883 Company B has OSPF in place. Add an ASBR to its Area 0, with 884 a static 885 route to the Area 0 of Company A. 887 8. Transition of Legacy 888 Routing Protocol Domains to OSPF 890 8.1 Problems of Integrating a Newly 891 Acquired Enterprise; OSPF not used 892 by new acquisition 894 Company A acquires a 895 smaller Company B. Company B now runs RIP, or 896 possibly has a limited OSPF 897 implementation. Company B is not 898 geographically close to the Area 0 of 899 Company A. 901 There are several ways to deal with this situation while 902 imposing 903 minimal impact on Company B users. 905 8.2 An OSPF and VL 906 Solution. 908 Replace RIP with OSPF on the Company B routers, assigning the 909 Company B 910 address space to a new nonzero area. Define a VL from one of the 911 new 912 area's routers, tunneled through an existing Company A area, 913 that 914 attaches to the backbone at the edge of the Company A 915 area. 917 Eventually, provide direct connectivity to Area 0 from the Company 918 B 919 area, and delete the VL. 921 Disadvantages here include an immediate 922 conversion to OSPF, the cost of 923 connectivity between the new area and the 924 existing area that carries the 925 VL, and the additional traffic load imposed 926 on the nonzero area with the 927 Area 0 connection. 929 8.3 Run RIP in Company B 930 area, with link to Area 0 ASBR that learns RIP 932 Leave Company B running 933 RIP. Run a link to a Company A, Area 0 router. 934 Either redistribute the RIP 935 routes into Area 0, or simply run RIP on the 936 ASBR and have it originate the 937 default into Area 0. If additional 938 bandwidth or connectivity changes are 939 needed to handle the Company B 940 trafic, this primarily can be restricted to 941 Area 0 where it is not 942 visible to end users. 944 The disadvantage here is the 945 cost of additional circuits from the 946 Company B area to Area 0. Also, ASBR 947 default injection into a nonzero 948 area can create loops if conflicting 949 defaults are being advertised 950 elsewhere, as by an ABR. 952 8.4 Run RIP in 953 Company B area, with an ASBR in the transit nonzero area 954 of Company 955 A. 957 Again Company B runs RIP. It connects to the nearest potential ASBR 958 in 959 an established Company A area, and is advertised as an external 960 route 961 into that area. This nonzero area then injects the external, 962 possibly 963 summarizing it, into Area 0. This method is less flexible in terms 964 of 965 advertising defaults than is 5.2, and also has the disadvantage 966 of 967 injecting external traffic into an area not originally designed 968 to 969 handle it. Since the area with the ASBR can no longer be stubby, it 970 may 971 be flooded with significant numbers of Type 5 LSAs from the backbone 972 and 973 other areas. 975 8.5 ASBR Solution with NSSAs 977 Again Company B runs RIP. 978 It connects to the nearest potential ASBR in 979 an established Company A area, 980 and is advertised as an external route 981 into that area. This ASBR supports 982 NSSA, and translates the RIP routes 983 into Type 7 LSAs, which are sent to 984 ABRs of this area and translated to 985 externals in Area 0. 987 The established 988 nonzero area maitains its generally stubby quality, and 989 will not be flooded 990 by unnecessary Type 5 LSAs. 992 9. Traffic Management 994 In the real world, 995 situations may arise where a client in one area has a 996 significant traffic 997 exchange with a server in another area. The volume of 998 this traffic is such 999 that a special virtual circuit or dedicated line would 1000 be warranted, but 1001 establishing such a link would violate the OSPF 1002 hierarchy. If routers on 1003 both ends were in different areas, the hello 1004 protocol handshake would fail 1005 and there would be no routing between them. 1007 Again, this is a matter of if 1008 it hurts to do something, don't do it. Most 1009 routers have a mechanism for 1010 preferring one source of routing information 1011 over another. In this case, 1012 establish a static route between the client 1013 and server prefixes. 1015 In the 1016 routers along this path between client and server, give the static 1017 route a 1018 preference factor that makes it more preferable than OSPF. While 1019 the 1020 details will be specific to individual router implementations, it 1021 is 1022 usually quite practical to establish OSPF routing, through area 0, as 1023 a 1024 backup to the preferred static path. 1026 10. Multiple Exit 1027 Points/Multihoming 1029 Use the power of OSPF's two types of externals when 1030 defining your policy 1031 for Internet connectivity. Many enterprise designers 1032 assume, incorrectly, 1033 they must run BGP to deal properly with connection to 1034 multiple Points of 1035 Presence (POP) of the same ISP, or to multiple ISPs when 1036 a 1037 primary/secondary policy is desired. See [Multihome] for a discussion 1038 of 1039 multihoming. 1041 11. Security Considerations 1043 Another potentially confusing area is OSPF's use of authentication. Do not 1044 confuse OSPF authentication mechanisms with security mechanisms for user 1045 traffic. The purpose of the OSPF authentication mechanism is to protect the 1046 OSPF system itself from denial of service attacks. 1048 Cleartext authentication is useful when combining different OSPF domains. 1049 By putting a password on the new or merged domain, you get some protection 1050 against configuration errors. An old router, not configured with the 1051 password, will not have its routing advertisements accepted by the new. 1052 Cleartext passwords are a simple method to confirm all routers in the 1053 routing domain have been examined by an administrator with the new design 1054 in mind. 1056 Cryptographic authentication protects an OSPF domain against malicious 1057 attacks, typically launched from inside the OSPF domain. Such protection 1058 might, for example, be useful in a university network. 1060 12. Acknowledgments 1062 13. References 1064 [RFC1812] Baker, F., "Requirements 1065 for IP Version 4 Routers", RFC 1066 1812, June 1995. 1068 [RFC2328] Moy, J., "Open 1069 Shortest Path First version 2," 1071 [Multihome] Work in progress, H. 1072 Berkowitz, "To Be Multihomed: 1073 Requirements & Definitions," 1074 draft-berkowitz-multirqmt-01.txt. 1076 [Berkowitz 99a] H. Berkowitz. _Designing Routing and Switching 1077 Architectures for Routing and Switching_. Indianapolis: Macmillan 1078 Technical Publishing, (August 1999 publishing). 1080 [Moy 1998] J. Moy. _OSPF: Anatomy of an Internet Routing Protocol_. 1081 Reading, MA: Addison-Wesley, 1998 1083 [Thomas] T. Thomas. _OSPF Network Design Solutions_. Indianapolis: Cisco 1084 Press, 1998 1086 14. Author's Address 1088 C. Berkowitz 1089 Gett 1090 Communications 1091 PO Box 6897 1092 Arlington VA 22206 1093 Phone: +1 703 998 5819 1094 EMail: 1095 hcb@clark.net