Conclusion
This section gave an example of how to work out an addressing scheme for a developing ISP network. This is intended to help the growing ISP business work out how to apply addressing to its network and how to allocate assigned address space to its infrastructure. Indeed, following these processes should aid in the application process for address space from the RIRs.
Interior Routing
One of the hardest questions that a vendor is posed at the time of an RFP is which IGP the new ISP network should choose. As mentioned previously, the choice should be made for technical reasons, not for any others. Furthermore, the choice should be made by the ISP because the engineering and operations staff must run the network after the equipment has been installed. For all intents and purposes, there is little to choose among EIGRP, OSPF, and IS-IS. Because EIGRP is a Cisco-proprietary IGP, its deployment in the ISP world is somewhat less common than the deployment of OSPF and IS-IS. OSPF and IS-IS have a lot in common for most network implementations today, and the choice between the two really comes down to which IGP has the most operational experience with the staff employed. It's quite interesting to observe the spread of IS-IS around the Internet. As engineers leave the established ISPs and move to new jobs, they implement IS-IS as the IGP of choice simply because they are most familiar with it. A similar thing can be seen for OSPF, resulting in interesting debates over which IGP is better.
The ISP IGP Versus BGP Model
Chapter 3 covered the details of setting up the configuration for the three popular IGPs. If those configuration guidelines are followed, there is very little else to say about IGP choice and configuration. The key to a scalable network is simple: Keep the IGP small. BGP is designed to carry a large number of prefixes around the ISP backbone. To that end, iBGP is considered by some network engineers to be the interior routing protocol for their network. The actual model used is quite simple and is best displayed in Figure 5-18:
Figure 5-18. Routing Protocol Relationships
Figure 5-18. Routing Protocol Relationships
• The IGP carries infrastructure prefixes, typically backbone point-to-point links and router loopback interface addresses.
• iBGP carries customer-assigned address blocks, access network address pools, and any other prefixes that do not need to be carried in the IGP. iBGP also is used to carry some or all of the Internet Route Table (depending on the ISPs internal policy).
• eBGP is used to carry prefixes between ISPs and to implement routing policy between ISPs.
This model is very different from earlier models used in the infancy of the Internet, in which the IGP carried all prefixes in the ISP backbone and BGP was restricted to simply exchanging prefixes between different autonomous systems. The relative lack of scalability of IGPs and the great scalability now available in iBGP through route reflectors and confederations means that iBGP is an excellent tool for carrying prefixes across the ISP's backbone.
When first faced with this model, many network engineers are skeptical about running iBGP to all corners of their backbone. A common misperception in the Internet community is that substantial routers are required before BGP can be run-many engineers forget that several ISP backbones have been built out of nothing more than Cisco 2500 routers that have limited RAM and CPU capabilities. Indeed, the 2500 shares many features with its predecessor, the IGS, which was used in many ISP backbones in the early 1990s. Because iBGP supports routing policy and route filter capabilities, there is no need to carry the full routing table across the entire ISP backbone. It is quite common for ISPs to limit full or large routing table support to the core of their network and simply announce their domestic prefixes to the rest of their backbone. A Cisco 2500 router, for example, is quite happy running BGP with 10,000 prefixes; it will be quite slow at processing updates, but then there are unlikely to be many updates inside an ISP's backbone. Updates are most likely to be generated by new customers being added to the ISP's network, hardly a per-second or even per-minute occurrence in all but the largest of networks.
A typical deployment scenario is the following:
1. An ISP installs all the loopback addresses in the backbone into the IGP. The ISP also installs all the point-to-point link addresses in the backbone into the IGP.
2. All routers in the backbone participate in the IGP. Any that cannot participate in the IGP generally have static default routes pointing to those that can (these are typically dumb access-aggregation devices).
3. The ISP sets up iBGP across the entire ISP backbone using route reflectors (our preferred technique) or confederations. iBGP is configured to peer the routers with the loopback interfaces. As the loopbacks are carried in IGP, the routers can see each other because there is an entry in the forwarding table courtesy of the IGP.
4. The ISP implements a policy for iBGP. All domestic prefixes (the ISP's own prefixes not in the IGP and address space assigned to its customers) are tagged with a certain community.
5. The route reflectors have filters so that the clients receive only the routes that belong to this special community. This way, the ISP ensures that the core routers (the route reflectors) are the only ones carrying the full routing table. The remaining routers in the backbone, the clients in each cluster, carry only the reduced list of prefixes.
6. The clients use a couple of predetermined networks as default networks so that they have an exit path to the backbone core. The two special networks could belong to the ISP itself or, more likely, will belong to the upstream ISPs. If one of these networks disappears, the second will be available as a backup.
This type of deployment makes for a very scalable network and allows the ISP to implement BGP on virtually every router device within its own backbone. This method is much preferred over having an iBGP island in the middle of the network and either pointing static routes or using redistribution from other routing protocols at the edge. The latter has proven itself risky and unreliable in many situations.
Continue reading here: Route Reflectors
Was this article helpful?