9.6 Practical BGP Design Example
9.6.1 Example problem
We will build the configuration shown in the figure step by step and see what can go wrong along the way. Whenever you have an AS that is connected to two ISPs via EBGP, it is always good to run IBGP within your AS in order to have better control of your routes. In this example, we will run IBGP inside AS100 between RTA and RTB and we will run OSPF as an IGP. Assuming that AS200 and AS300 are the two ISPs we are connected to, the following are the first run of configuration for all the routers. This is NOT the final configuration.

It is always better to use the network command or redistribute static entries into BGP to advertise networks, rather than redistributing IGP into BGP. This is why throughout this example we will use only the network command to inject networks into BGP.

Note: Click on topology to view command outputs.

We start by assuming that s1 on RTB is shut down, as if the link between RTB and RTD does not exist. In the table, the "i" at the beginning means that the entry was learned via an internal BGP peer. The "i" at the end indicates the ORIGIN of the path information to be IGP. The path information is intuitive. For example, network 128.213.0.0 is learned via path 200 with a next hop of 128.213.63.2. Note that any locally generated entry such as 203.250.15.0 has a next-hop 0.0.0.0.

The > symbol indicates that BGP has chosen the best route based on the list of decision steps given earlier in the section "How BGP Selects a Path." BGP will pick only one best path to reach a destination, will install this path in the IP routing table, and will advertise it to other BGP peers. Notice the next-hop attribute, RTB knows about 128.213.0.0 via a next hop of 128.213.63.2, which is the EBGP next hop carried into IBGP.

It looks like none of the BGP entries have made it to the routing table. There are two problems here discussed in the following sections.