In this section, we discuss some of the advanced BGP design topics.There is no real magic about these topics, but some of the design concepts require thinking through the IP address structure and how the various address blocks appear to the different parts of the network.The key topic we discuss is redundancy in the net- work from the access LAN to the Internet point of presence (POP).We will also identify some common design methodologies used in redundant and high avail- ability networks.
Figure 10.21Confederation Design and Function
OSPF 1 EBGP
AS 1001
AS 65500
EBGP
Router 9
Router 10 Router 8
Router 7
Router 2 Router 1 Router 3
Router 4
AS 65501 IBGP
IBGP
IBGP IBGP
IBGPIBGP
IBGP IBGP
SP 1 AS 1
Router 11 Router 12
EBGP EBGP
BGP Connection Type
Physical
IBGP IBGP
Building Network Redundancy
Network redundancy is the primary item that can either cause a network to run effectively or lead to numerous problems.The key is to keep the configuration simple by providing a stable physical topology and a stable software configuration.
Your goal in building redundancy is not to see how complex a network you can build.The goal is to build a high availability data network that will provide the 99.999 per cent up time experienced with other networks. Remember, problems will occur and you will be trouble-shooting the problems quickly.You should also be aware of the weak points of the network design. Furthermore, we always put a lot of effort into designing the physical layer redundancy, but often forget the soft- ware components.To address this problem, ask yourself the following questions:
■ Have you ever experienced a problem in your network after upgrading the network software?
■ Have you ever had an IP routing problem that affected the entire network?
■ Have you ever had an IP routing problem that rendered the redundancy useless?
Keeping these issues in mind will help you formulate a stable software design that prevents user problems and provides the high availability network your cus- tomers want. Also, remember that each time we raise the service level in the net- work, our customers also raise their service expectations. Figure 10.22 depicts a typical redundant network configuration involving dual Internet connections, multiple BGP ASs, physical redundancy, and a means to get software redundancy.
This figure depicts two BGP peering connections using a public AS of 1001. In this example, AS 1001 serves as a proxy AS for the private ASs located within the network.To accomplish this, Router 3 and Router 4 will strip the private AS information from the AS path of all network prefixes located in AS 65000, AS 65001, AS 65501, and AS 65502 before advertising them to Router 1 and Router 2. Furthermore, AS 1001 is a transit AS in relation to AS 65000, AS 65001, and the Internet.
The routing policy that we enforce will determine whether AS 1001 will serve as a transit AS between AS 65000 and AS 65001. Since these two ASs have a direct EBGP link between Router 6 and Router 7, it is preferred that the transit func- tions between these ASs occur at this level instead of at the Internet Peering layer.
Direct EBGP connections at the Core layer between all Core routers may be cost prohibitive. In this case, AS 1001 could provide the redundant connection between
The Distribution layer gains its redundancy through cross connects to the Core layer networks. In this example, we see AS 65501 connected to both AS 65000 and AS 65001. Also, AS 65502 has connectivity to both AS 65000 and AS 65001.These are two examples of multihomed ASs connecting to different ser- vice providers. Interconnecting the Distribution layers will add additional redun- dancy, but it will also add a tremendous amount of complexity to the network configuration.
The Access layer has redundancy in the form of two routers and two circuits.
Although not depicted here, we could also have redundancy in the LAN segment electronics and dual cabling to the workstations. As well, the circuits depicted could be leaving the building via a separate path to a different serving central office (CO).
Finally, we need to evaluate our software redundancy requirements in regards to an acceptable failure domain. In this example, you can see that it would be very easy to run different software versions in the Core layer, and that we have a different instance of an IGP and BGP on the two ASs.We could push this separa- tion down to the LAN segment with some creative solutions. However, this would add a degree of complexity, would be more difficult to manage, and might have more redundancy than necessary.
Figure 10.22Redundant BGP Design
OSPF 2 OSPF 1
OSPF 300 AS 1001
Internet
Router 2
AS 65001 AS 65502
EBGP IBGP
SP 1 SP 2
Router 1
OSPF 1000
Router 3 Router 4
AS 65000
Router 5 Router 6 Router 7
Router 8 IBGP
IBGP
Core Layer Internet Peering Layer
EBGP EBGP
IBGP
OSPF 200 AS 65501
IBGP
Router 10
EBGP
EBGP EBGP
Router 12 Distribution Layer
Access Layer
Router 11 Router 9
Common Design Methodologies
The methodologies for designing a BGP 4 network follow the guidelines for building a stable IGP network.Thus, BGP 4 demands as much attention to detail for a stable network design as is required for a stable IGP design. After all, we also use an IGP within the AS to carry the next hop routing information.
■ Avoid single points of failure throughout the network.
■ Evaluate geographic failure zones.
■ Evaluate power sources.
■ Consider alternate service providers.
■ Evaluate the service level that is expected and funded.
■ Carefully plan the IP network CIDR boundaries down to the lowest summarization level.
■ Always plan for optimum IP network summarization along CIDR boundaries.
■ Use a physical layer hierarchy that supports the network address summa- rization plans.
■ Do not use backdoor connections between access layer segments.
■ Use BGP 4 to solve the scaling problems of an IGP; you cannot use it in place of an IGP.
■ Use Route Reflectors or Confederations to assist full mesh peering if necessary within an AS. Route Reflectors must follow the physical topology path or routing loops will occur.
■ Design EBGP connections around stable network connections.
■ Use a loopback interface for peering between IBGP neighbors.
Loopback interfaces will not go down because of a link failure.
■ Try to build a redundant network that facilitates software redundancy.
■ Can the software version on one side of the network be different for a transition period?
■ Will an IGP failure affect the entire network?
■ Plan for multiple Internet connections to different ISPs. Even if you do not need them now, a future project will likely demand this service level.