Our discussion so far has exclusively concerned routing information exchanges between ASes through BGP speakers. In fact, BGP is also used to set up peer (neighbor) connections between two BGP speakers within an AS, known as internal BGP (IBGP) speakers. The question is why such an arrangement is needed and in what scenarios. Before we delve into this, we clarify a curiosity that remains: how does a BGP speaker find out whether it is communicating with an external peer BGP speaker or an internal peer BGP speaker? This can be determined by comparing the AS number communicated in the OPEN message by its peer BGP with that of its own internal value; if it matches, then this neighbor is an IBGP speaker, and if it does not, then it is an EBGP speaker.
To consider why IBGP is needed and for what types of scenarios, we begin with an illus- tration consisting of four ASes as shown in Figure 8.5. Here, AS64777, AS64999, and AS65222 are referred to as stub ASes since they each of them has one BGP speaker as an outlet. We start with AS64777. There are three IP prefixes in this AS: N1, N2, and N3. To route user traffic from
F I G U R E 8.5 External BGP and internal BGP example.
one of them to another one within AS64777, an interior gateway protocol is sufficient to deter- mine routing. Similarly, the internal routing scenario is handled within the other ASes as well.
We assume that AS64777 uses OSPF within its domain. What about inter-AS? For example, how does R7 in AS64888 learn about network N1, and conversely, R1 in AS64777 learn about network N7? Note that neither R1 nor R7 is a BGP speaker; they are interior routers within their respective ASes. One possible way is that BGP speaker R2 learns about N5 from AS64888 and then communicates this information through OSPF protocol to routers R1 and R3. Thus, R2 can learn about all external IP prefix networks from its neighboring AS and communi- cate to R1 and R3 through OSPF. The difficulty is that this immediately creates a scalability problem at routers R1 and R3 since they will need to maintain link state database entries for such external IP prefixes and compute the shortest paths to all such IP prefixes. Furthermore, if router R3 were to populate the external IP prefixes to each internal router, it defeats the purpose of BGP. In any case, while theoretically possible, BGP speaker R2 in AS64777 does not inform other interior routers within AS64777 about external IP prefixes about which it has learned. Instead, BGP speaker R2 becomes the default gateway for all external IP prefixes;
a common way to configure in a stub AS; routers R1 and R3 do not need to maintain routing table entries for external IP prefixes, thus reducing the routing table size at R1 and R3 as well.
The above discussion gives the impression that the border BGP speaker such as R2 is the stopping point for external IP prefixes it has learned from its neighboring AS, i.e., through incoming BGP messages. This is, however, true only if the AS is a stub AS with only a single BGP speaker to its neighboring AS; in fact, this is the case with R2. This situation, however, no longer holds when we consider AS64888. If BGP speaker R4 were to stop distributing IP pre- fixes N1 and N2 it has learned from BGP speaker R2, then the third AS, AS64999, would have no way of knowing that N1 and N2 actually exist. Thus, a mechanism is needed so that an AS that has connectivity to multiple ASs through multiple BGP speakers such as AS64999 can communicate information about network reachability. This is where an internal BGP session is required between two BGP speakers within an AS so that network reachability information can be exchanged. In our example, such an internal BGP session is required between BGP speakers R4 and R5 so that R4 can learn about IP prefixes N8, N9, and N10 while R5 can learn about IP prefixes N1, N2, and N3. That is, an important BGP rule is as follows:
Rule 1: A BGP speaker can advertise IP prefixes it has learned from an EBGP speaker to a neigh- boring IBGP speaker; similarly, a BGP speaker can advertise IP prefixes it has learned from an IBGP speaker to an EBGP speaker.
Note that due to the second part of Rule 1, it is acceptable for R4 to advertise to R2 in AS64777 about IP prefix N7, which is part of AS64888.
While internal BGP works very much the same way as external BGP, there is an important difference. Consider network N6 in AS64888; within this AS, BGP speaker R4 learns about it internally through OSPF from internal router R6; similarly, BGP speaker R5 also learns about N6 from R6. Should R4 and R5, both IBGP speakers, advertise N6 to each other through the IBGP session? The answer is no. That is, a second important rule is as follows:
Rule 2: An IBGP speaker cannot advertise IP prefixes it has learned from an IBGP speaker to another neighboring IBGP speaker.
The primary reason for this rule requires some explanation. The AS number is prepended only when an advertised IP prefix crosses an AS boundary (Example 8.2). Recall that a BGP speaker prevents looping by checking if its own AS number is on the path for any network reachability received from another BGP speaker. When the communication is within an AS, and since the AS number is not prepended in this scenario, looping is possible! This mandates the need for Rule 2. Furthermore, the routers within an AS are supposed to handle internal routing through the interior gateway protocol for all its internal IP prefixes; this is not the role of an IBGP.
There is, however, an important implication of Rule 2 in regard to external IP prefixes when there are more than two IBGP speakers in an AS. To understand this issue, consider again AS64888. Due to Rule 1, BGP speaker R4 will learn about N1, N2, and N3 from EBGP speaker R2 and let IBGP speaker R5 know so that R5 can communicate this information to AS64999. Also, by Rule 1, BGP speaker R4 will also learn about N11, N12, N13 located in AS65222 from IBGP speaker R6 and let AS64777 know about existence of N11, N12, and N13.
However, due to Rule 2, R4 cannot inform IBGP speaker R5 about N11, N12, N13. How then would AS64999 know about N11, N12, N13? As a consequence of Rule 2, AS64999 would not know unless that is also an IBGP session between IBGP speakers R5 and R6. That is, if there are more than two IBGP speakers in an AS, there must be an IBGP session between each pair of IBGP speakers; thus, this leads to the case of full-mesh IBGP connectivity. This certainly raises the scalability issue, which is discussed later in Section 8.8.
To summarize, IBGP is required whenever an AS has multiple EBGP speakers. Certainly, a stub AS that has only a single BGP speaker does not need to consider IBGP. The basic mech- anism for IBGP and EBGP is the same as long as the two rules discussed above are addressed properly. Note that IBGP is a situation in which the third approach for initial configuration, mentioned earlier in Section 8.4, is often used for connecting two IBGP speakers. IBGP speak- ers are also configured using loopback addressing for ease of configuration manageability. In this case, the interior gateway protocol is used for routing BGP-related data from one IBGP speaker to reach the other IBGP speaker.