With respect to the public Internet, you are multihomed when you run BGP to more than one other AS. Multihomed ASs may be transitornontransit.The vast majority of enterprise networks that run BGP to the outside are nontran-sit. For additional reliability, it is perfectly reasonable to combine multilink-ing, multihoming to multiple POPs of the same ISP, and multihoming to multiple ISPs.
Situations can exist where enterprises legitimately offer limited transit. They are not trying to be ISPs, but for various reasons may provide connectivity to partners. This is very common in higher education, where, for example, one campus of a state university may manage the primary connectivity for other campuses and junior colleges.
Enterprise-level transit also can have commercial applications, as shown in Figure 4.13. In this situation, there are two cases where the enterprise provides 138 Chapter 4
Figure 4.13 Complex enterprise multihoming.
TE AM FL Y
Team-Fly
®selective transit service. The first is for a manufacturing subcontractor that needs access to a second subcontractor on another continent. The main enter-prise advertises the route of the second subcontractor to the first, and will not accept traffic from the first intended for any other destination. The second case involves an academic and industry cooperative research project. The enterprise is a large enough participant in the project to justify high-speed access to the dedicated research network. The acceptable use policy of that network allows only participants to access it. One of the enterprise’s business partners has a lim-ited involvement in the research project, but is too small to justify a direct con-nection. The enterprise has agreed to provide that partner with access to the research network through its direct connection. However, the enterprise will not go so far as to allow the partner to use the enterprise’s commercial connection for backup connectivity. In other words, if the direct link to the research net-work goes down, the enterprise’s internal researchers still will have access via the commercial ISP connection, but the business partner is on its own.
Figure 4.14 shows a situation where general Internet access is at one key porate location, but there are special concerns for the Internet access of the cor-porate research lab. While this is the easiest topology to manage, it may or may
Translating Service Definitions to Technical Requirements: Policies 139
Corporate Backbone ISP1
Access
ISP 2 Access
Division 1 Division 2
(Research) Division 1 Division 1
Default Routes Full Internet Routes
ISP 3 Access
ISP 4 Access
Figure 4.14 Geographically dispersed access.
not be desirable for companies that span large geographic areas, or where other factors are involved. In this case, the research lab has far more Internet experi-ence than the operators of the corporate network. The enterprise has abundant bandwidth in the core, so while each division has multiple points of attachment to the core, the firm does not obsess about load balancing from each point. It simply makes sure that any one point of attachment can handle the load. As a result of the deliberate overprovisioning of bandwidth, the routing is fairly sim-ple: Each divisional edge router, except for those that served the research divi-sion, announces the default route into the divisional area. The research dividivi-sion, however, accepts full corporate routes (with summarization) from the core, and generates its own default from its own Internet gateway. Careful filtering is used to ensure that the research default did not propagate into the core. In this man-ner, the research division knows how to reach intranet destinations, but defaults to its own Internet connectivity for destinations outside the enterprise.
There comes a time, however, when the designer must look at the complex-ity of such routing policies and ask if the enterprise is technically competent to manage them. If it is not, then an assortment of alternatives need to be consid-ered, including outsourcing some of the management to an appropriate ISP or locating key services at a hosting center that does have the appropriate staff.
Case Study: Transition between Provider Networks
While it isn’t the classic enterprise example of multihoming to two ISPs, the case study of the Johnson City Medical Center routing policies, taken indepen-dently of Johnson City Cable, is a reasonable example of multihoming to two upstream ISPs (see Figure 4.15). In this case, the ISPs are the new optical provider and the radio system (before it is limited to medical use).
During the transition to the new provider networks, JMedNet will receive full routes from MedRadio and Upstream1. It will also accept customer routes from JCC. JCC will eventually provide mutual backup, but that is beyond the scope of our immediate discussion.
Transit
Enterprise networks may have an internal transit AS if they use BGP to form a backbone of backbones within the enterprise, but that is not within the scope of the current discussion. An enterprise AS may still need to use exterior rout-ing policies, because it provides transit services to strategic partners.
Service providers are transit networks. They carry traffic on behalf of others and pass it to the network. ISPs, of course, have this as their basic business. As shown in Figure 4.16, enterprises may provide transit services to business part-ners. Specific policies can be applied. An example of a policy for an enterprise transit AS would be that the AS will provide transit to the academic AS for its 140 Chapter 4
research partner and also for its internal researchers. If the AS link to the aca-demic network fails, however, the enterprise will still route its internal researchers via the commercial ISP, but will not pay for the partner’s access via the commercial ISP.
Transit with Provider-Independent Address Space
Transit is much less complex if all participants have provider-independent address space. In principle, all can advertise their allocated blocks to one
Translating Service Definitions to Technical Requirements: Policies 141
JCC
Figure 4.15 Multihoming to two ISPs: JMedNet in transition.
Supplier 1 Routes Only If Learned from
ABC Router
Figure 4.16 Enterprise providing transit.
another. Ideally, there will be one contiguous block per provider, but past allo-cation practices, mergers and acquisitions, divestitures, and so on, all may cause a need to advertise multiple blocks. Such advertising of multiple blocks is separate from the advertising of more specific sub-blocks of these prefixes, which may be done for reasons of fault tolerance or traffic engineering.
Transit without Provider-Independent Address Space
The idea of transit still applies if the enterprises connected to the ISP use address space delegated by the ISP. In Figure 4.17, the upstream provider AS1 is a large national ISP, which has been allocated the CIDR prefix 192.0.0.0/16. It has a small ISP customer that cannot justify its own allocation. The small ISP, however, has multiple points of connectivity to the large ISP. The large ISP has assigned 192.0.2.0/22 to the small ISP, which in turn will assign pieces of this space to its own customers. Also, AS1 has assigned a private AS number, 62222, to the small ISP.
Assume that AS1 has numerous external peers, so it is immune to single fail-ures of upstream connectivity, and it has an overprovisioned core, so there is no real concern with AS62222 being load-balanced once its traffic is inside the AS1 core. Considering those factors, there is no reason that the more specific 142 Chapter 4
Small ISP customer (AS 62222) Big ISP (AS1) with 192.0.0.0/16
Assigns 192.0.2.0/22 to small ISP customer
Router 2
Figure 4.17 Transit with PA address space.
announcements of AS62222 need to be seen outside AS1. It will be more than adequate for AS1 to advertise its aggregate. The small ISP customers that are single-homed can use NAT to either POP. If a small ISP customer needs to dual-home, it can use an allocation from the east or west side of the small ISP, but will retain connectivity even if one of the small ISP’s upstream connections fails.
In Chapter 10, we will explore more complex scenarios when multiple upstream ISPs are involved.
Translating Service Definitions to Technical Requirements: Policies 143
THE OLD ONES AMONG US
The provider for this example is hypothetical, but AS1 is assigned to Genuity, which traces its ancestry to BBN, GTE Internetworking, and so on, and has the motto, “AS1 and Proud of It!”
HOW NOT TO DO IT
Bad Things happen when you accidentally create a transit AS by doing such things as re-advertising all routes learned from one eBGP speaker to another. You really, really do not want to promise AT&T Worldnet that you will carry traffic to UUnet.
Other Bad Things can happen when you rush, and when you do not deny everything not explicitly permitted. Figure 4.18 shows a perfectly functioning enterprise with multihoming to a single provider. For this example, assume it has been properly assigned 96.0.0.0/16.
Figure 4.19 shows the network of another company just acquired by your own. The less clueful network designer there did not know of the existence of private address space, and so picked a “random” network number for what
“would only be internal.” The number picked was 3.0.0.0/8, which happens to be assigned to General Electric. Later, when that company decided it did need Internet access, its provider, AS666, set up NAT that mapped the company’s address space into AS666’s space. At the time of the merger, the acquired company’s administrator forgot to tell you about this mapping.
Your pointy-haired manager demands that you connect the new subsidiary immediately, and disconnect the AS666 connectivity to save money. Mr. Pointy Hair does know enough routing to be dangerous, and orders you to redistribute the new company’s routing into yours and then advertise the combined
addresses to AS1, resulting in the configuration in Figure 4.20.
Assuming AS1 does not filter the routes coming from your enterprise, and re-advertises them to the general Internet, it will be a race to see if the first angry calls reaching you are from the lawyers of General Electric (to which 3.0.0.0/8 is assigned), irate customers of General Electric that are trying to reach the Internet via your enterprise, or your internal users complaining of poor performance as your links are overwhelmed by traffic arriving from outside.
144
ISP 666 ISP666
POP1 NAT
New Enterprise, assigned itself
3.0.0.0/8
Internet
Valid Address Space Invalid Address Space
Figure 4.19 The company yours is acquiring, which, unbeknownst to your pointy-haired manager, was being saved from its sins by its former ISP.
Internet ISP1
ISP1 POP1
ISP1 POP2 Your Enterprise,
assigned 96.0.0.0/16
Valid Address Space
Figure 4.18 Currently clued enterprise on the path to cluelessness.
JCC and JMedNet Joint Policies
While the relationship between JCC and JMedNet and their upstreams is a clas-sic subscriber buying transit from a provider, the relationship between the two organizations themselves is bilateral peering. This peering is somewhat more extensive than is seen between major providers, who only exchange customer routes.
The basic logic of the relationship here is to send traffic that belongs to the partner’s customers directly to the partner, and Internet traffic to the upstream(s) unless the upstream is down (so to speak). In the event of such a failure, send all Internet traffic to the partner, which will forward it to its upstream. All upstreams need to know to expect address space from their cus-tomer’s partner.