Hello Carl,
the iBGP full mesh issue is normally solved using BGP Route Reflectors servers and for very big service providers by using also BGP confederations.
so iBGP can be used without scalability issues usually in service provider environments and also in big enterprise environment after introduction of MPLS services like L3 VPN
BGP RR technical details:
A BGP RR is allowed to reflect iBGP advertisements between its own clients and to non-clients.
To perform reflection in a safe way the BGP RR adds two BGP attributes to the advertisement it reflects:
Originator ID = BGP router-id of the client that has originated the advertisement
Cluster-list = it contains the cluster-id of the local RR that by default is equal to RR device BGP router-id.
It is updated at each reflection and provides the reflection history/ internal path. So it may be formed by multiple items with IPv4 format.
BGP configuration has to be changed only on RR side using command
neighbor x.x.x.x route-reflector-client
Only a full mesh between RR devices is needed instead of having a full mesh of all devices. This greatly reduces the number of required iBGP sessions as a device can receive advertisements originated by a router with which it has no direct iBGP session via RRs.
Without BGP RRs or BGP confederations iBGP would be a problem as you noted as the number of required BGP sessions is N *(N-1)/2 where N is the number of routers. ( with N=100 it would mean 4950 BGP sessions that cannot be supported by a single router)
Hope to help
Giuseppe
