IBGP Full Mesh

Full mesh of IBGP sessions has to be established between all BGP-speaking routers in the AS for proper IBGP route propagation.

The IBGP full mesh is a logical mesh of TCP sessions only; physical full mesh is not required.

© 2004 Cisco Systems, Ii

Because every router on the transit path within the AS must have routing information about all external networks that are received by any of the border routers, they must all have IBGP sessions to all border routers. This level of communication is not enough, though, because any of the internal routers could also create new BGP routing information (for example, originate a customer network). These updates must also reach all the routers within the AS. The conclusion is that all BGP routers within an AS must have IBGP sessions with every other BGP router in the AS, resulting in a full mesh of BGP sessions between BGP-speaking routers in an AS.

In the network in the example here, RTR-A must have IBGP sessions with RTR-B, RTR-C, and RTR-D in order to propagate routes that are received from AS 12 to all routers within AS 42. Similarly, RTR-D must have IBGP sessions with RTR-A, RTR-B, and RTR-C to be able to propagate routes that are received from AS 14 to all routers within AS 42.

Note The IBGP session between RTR-B and RTR-C is not strictly necessary for proper forwarding of IP packets between external destinations. It does become mandatory if RTR-B or RTR-C starts to originate BGP networks. To prevent potential future connectivity issues, it is a good practice to establish a full mesh of IBGP sessions regardless of whether they are needed at the time of network deployment or not.

The IGP that runs within AS 42 provides enough information to any BGP router within AS 42 to send IP packets to any other router in the AS. Having enough router reachability information makes it possible to establish IBGP sessions between routers even though they are not physically connected. The IBGP full mesh is a logical full mesh of TCP sessions and will run on an arbitrary physical topology.

Copyright © 2004, Cisco Systems, Inc. BGP Transit Autonomous Systems 2-15

The PDF files and any printed representation for this material are the property of Cisco Systems, Inc., for the sole use by Cisco employees for personal study. The files or printed representations may not be used in commercial training, and may not be distributed for purposes other than individual self-study.

Example

IBGP Full Mesh (Cont.)

© 2004 Cisco Systems, Inc. All rights re

© 2004 Cisco Systems, Inc. All rights re

The figure illustrates IBGP split-horizon and IBGP full-mesh principles in the sample network. R-12 is sending an update to RTR-A over an EBGP session. Updates that are received on an EBGP session should be forwarded on all other IBGP sessions, so RTR-A updates RTR-B, RTR-C, and RTR-D. All routers within AS 42 are updated directly by RTR-A.

RTR-B and RTR-C are prevented from forwarding the update that they received from RTR-A because of BGP split horizon.

RTR-D, which received the information on an IBGP session, is prevented from updating RTR-B and RTR-C because of the same split-horizon rule. But RTR-D will update R-14 over an EBGP session.

2-16 Configuring BGP on Cisco Routers (BGP) v3.1 Copyright © 2004, Cisco Systems, Inc.

The PDF files and any printed representation for this material are the property of Cisco Systems, Inc., for the sole use by Cisco employees for personal study. The files or printed representations may not be used in commercial training, and may not be distributed for purposes other than individual self-study.

Continue reading here: Differences Between EBGP and IBGP Sessions Cont

Was this article helpful?

+12 -1