neighbor command must be reachable without using an IGP, which can be accomplished by pointing at an address that is reachable through a directly connected network or by using static routes to that IP address.

Content 6.2 EBGP and IBGP 6.2.3 Establishing a Connection Between Internal BGP Neighbors When BGP runs between routers within the same autonomous system, it is called IBGP. IBGP exchanges BGP information so that all BGP speakers have the same BGP routing information about outside autonomous systems. Routers running IBGP do not have to be directly connected to each other as long as they can reach each other so that TCP handshaking can be performed to set up the BGP neighbor relationships. The IBGP neighbor can be reached by a directly connected network, static routes, or by the internal routing protocol. Because multiple paths generally exist within an autonomous system to reach the other IBGP routers, a loopback address is usually used in the BGP neighbor command to establish the IBGP sessions. For example, when multiple routers in an autonomous system are running BGP, they exchange BGP routing updates with one another. In Figure , routers A, C, and D learn the paths to the external autonomous systems from their respective EBGP neighbors (routers Z, Y, and X). If the link between routers D and Y goes down, router D must learn new routes to the external autonomous systems. Other BGP routers within AS 65500 that were using router D to get to external networks must also be informed that the path through router D is not available. Those BGP routers within AS 65500 need to have the alternate paths through routers A and C in their BGP forwarding database. You must set up IBGP sessions between all BGP routers in AS 65500 so that each router within the autonomous system learns about paths to the external networks via IBGP.

Content 6.2 EBGP and IBGP 6.2.4 Synchronization Within an Autonomous System BGP was originally intended to run along the borders of an autonomous system with the routers in the middle of the autonomous system ignorant of the details of BGP (hence the name Border Gateway Protocol). A transit autonomous system, such as the one in Figure , is an autonomous system that routes traffic from one external autonomous system to another external autonomous system. Typically, transit autonomous systems are ISPs. All routers in a transit autonomous system must have complete knowledge of external routes. Theoretically, one way to achieve this goal is to redistribute BGP routes into an IGP at the edge routers. However, there are problems associated with this approach. Since the current Internet routing table is very large, redistributing all the BGP routes into an IGP is not a scalable method for the interior routers within an autonomous system to learn about the external networks. Another method that you can use is to run IBGP within the autonomous system. By definition, the default behavior of BGP requires that it must be synchronized with the IGP before BGP may advertise transit routes to external autonomous systems. The BGP synchronization rule states that a BGP router should not advertise to external neighbors destinations, learned from IBGP neighbors, unless those destinations are also known via an IGP. If a router knows about these destinations via an IGP, it assumes that the route has already been propagated inside the autonomous system, and internal reachability is ensured.

Content 6.2 EBGP and IBGP 6.2.5 IBGP in a Nontransit Autonomous System A nontransit autonomous system, such as an organization that is multihoming with two ISPs, does not pass routes between the ISPs. However, the BGP routers within the autonomous system still require knowledge of all BGP routes passed to the autonomous system to make proper routing decisions. BGP does not work in the same manner as IGPs. Because the designers of BGP could not guarantee that an autonomous system would run BGP on all routers, a method had to be developed to ensure that IBGP speakers could pass updates to one another while ensuring that no routing loops would exist. To avoid routing loops within an autonomous system, BGP specifies that routes learned through IBGP are never propagated to other IBGP peers. The neighbor command enables BGP updates between BGP speakers. By default, each BGP speaker is assumed to have a neighbor statement for all other IBGP speakers in the autonomous system, which is known as full mesh IBGP. Routers do not have to be directly connected to be fully meshed. If the sending IBGP neighbor is not fully meshed with each IBGP router, the routers that are not peering with this router have different IP routing tables from the routers that are peering with it. The inconsistent routing tables can cause routing loops or routing black holes, because the default assumption by all routers running BGP within an autonomous system is that each BGP router is exchanging IBGP information directly with all other BGP routers in the autonomous system. If all IBGP neighbors are fully meshed, when a change is received from an external autonomous system, the BGP router for the local autonomous system is responsible for informing all other IBGP neighbors of the change. IBGP neighbors that receive this update do not send it to any other IBGP neighbor, because they assume that the sending IBGP neighbor is fully meshed with all other IBGP speakers and has sent each IBGP neighbor the update. Example: IBGP Partial Mesh
Figure displays the IBGP update behavior in a partially meshed neighbor environment. Router B receives a BGP update from router A. Router B has two IBGP neighbors, routers C and D, but does not have an IBGP neighbor relationship with router E. Routers C and D learn about networks that are added or withdrawn behind router B. Even if routers C and D have IBGP neighbor sessions with router E, they assume that the autonomous system is fully meshed for IBGP and do not replicate the update and send it to router E. Sending an IBGP update to router E is the responsibility of router B, because it is the router with first-hand knowledge of the networks in and beyond AS 65101. Router E does not learn of any networks through router B and does not use router B to reach any networks in AS 65101 or other autonomous systems behind AS 65101.

Example: IBGP Full Mesh
Figure displays a fully meshed IBGP. When router B receives an update from router A, it updates all three of its IBGP peers: routers C, D, and E. The IGP routes the TCP segment containing the BGP update from router A to router E because the routers are not directly connected. The update is sent once to each neighbor and not duplicated by any other IBGP neighbor, which reduces unnecessary traffic. In fully meshed IBGP, each router assumes that every other internal router has a neighbor statement that points to each IBGP neighbor.

TCP and Full Mesh
TCP was selected as the transport layer for BGP because it can move large volumes of data reliably. With the very large Internet routing table constantly changing, TCP was determined to be the best solution for windowing and reliability, as opposed to developing a BGP one-for-one windowing capability like OSPF or EIGRP. Because each IBGP router needs to send routes to all the other IBGP neighbors in the same autonomous system (so that they all have a complete picture of the routes sent to the autonomous system), they must use fully meshed BGP (TCP) sessions. Remember, BGP uses TCP to ensure the reliable delivery of packets, therefore, they cannot broadcast or multicast their routes to other IBGP neighbors. When all routers running BGP in an autonomous system are fully meshed and have the same database as a result of a consistent routing policy, they can apply the same path selection formula. The path selection results are therefore uniform across the autonomous system, which ensures no routing loops and a consistent policy for exiting and entering the autonomous system.

Content 6.2 EBGP and IBGP