As of version 1.1.0 of the SSFNet BGP-4 package, there is support for Internal BGP (IBGP). This eliminates the previous restriction which required that an autonomous system contain no more than one router running BGP. Internal BGP is a sub-protocol, in a sense, of BGP itself, and runs between internal neighbors. It is used to distribute the externally-learned routes among BGP routers in the same AS, keeping them consistent with each other. Internal BGP functions very similarly to the primary use of BGP (which is often referred to as External BGP), though there are some differences.

For one, any internally received Update messages may not be forwarded (this is to prevent internal routing loops). It implies that there must be a full mesh of peering sessions among all internal BGP routers in an AS. Following is an example network which uses Internal BGP. Refer to the ibgp and forwarding3 validation tests in the distribution for further examples.

Network ibgp90: This topology consists of 31 autonomous systems (contained by dashed lines). A central backbone composed of five BGP routers is the primary AS for transit traffic. Each router in the backbone connects to a cluster of smaller ASs. Each of these five clusters is identical, containing six ASs: a transit AS with four BGP routers, a transit AS with two BGP routers, and four stub ASs, with one, one, three, and six routers, respectively. Realistically, a stub AS has no need for more than one BGP router. However, they are added here to exercise Internal BGP. [ PostScript version for printing ]

A network using route reflection

Because the full mesh requirement for IBGP can be cumbersome, and an extension to BGP called route reflection has been proposed to ease the burden. As with IBGP, route reflection is implemented as of version 1.1.0 of the SSFNet BGP-4 package. Below is an example network that takes advantage of route reflection. For further information, refer to the SSFNet BGP documentation and to the reflection validation test in the distribution.

Network rr9: This topology consists of four autonomous systems. Three are trivial one-router ASs, while the fourth contains six BGP routers and is using Internal BGP with route reflection. Three route reflection clusters are defined (dotted lines), which pair route reflectors (RR1, RR2, and RR3) with clients (C1, C2, and C3). A route reflector is a specially designated BGP router which "reflects" internally received Update messages (thus bending the BGP rule which disallows such forwarding) to and/or from its clients, which are just "regular" BGP routers. It is acceptable to have a cluster with multiple route reflectors, or without clients. [ PostScript version for printing ]