Internal BGP and external BGP are the two different peering types. Internal is peering between speakers of the same AS and external is peering between different AS. In regards to both of these peering types, there are some rules in the configuration we have to follow and there are also some extra configurations we may have to do.
Something called BGP synchronization comes into play here (or doesn't). By default it's turned off. What BGP sync does, is tell the router that it can't advertise anything in BGP, unless the route exists in the routing table through IGP.
With iBGP things are quite simple as long as the rule of full mesh peering is followed. First off, why is full mesh required? BGP has a loop protection mechanism that states no advertisement can have it's own AS in the AS_PATH attribute, as that'd mean it's already been through this AS before. In iBGP we only have one AS and every advertisement would be coming from the same AS. So the iBGP peers can receive advertisements from their configured "directly" connected neighbors, but they will not forward this advertisement further. This is called BGP Split Horizon.
Full mesh hinders scalability a bit because it requires every router to be configured with every other neighbor. The topology below has 4 routers, requiring 3 neighbor statements on every router, total of 12.
That's not too bad, but add 2 more routers and now every router has 5 neighbor statements, with 6 routers totaling 30 commands.
But, of course, we have a solution for this. Route reflectors and confederations. A route reflector acts as a "master" in the BGP mesh. Its job is to inform every BGP speaker about the other speakers. This way, only the route reflector has to be configured with every neighbor, while the other routers (clients) just need the reflector. You can also have redundant route reflectors. In that case, every client has to be configured with both masters and both masters have to be configured with all the clients.
While full mesh is required for iBGP, it doesn't mean every router in the network has to participate in BGP. It just means every router that does participate in the same BGP AS have to connect. What comes into play here is the TTL. BGP uses hop counts as Time To Live and eBGP has a 1 hop TTL, but iBGP has 255. A TTL at 255 more or less means you're unrestricted in how your routed network looks.
Starting with a small topology for the configurations
R1 is the route reflector and R2 doesn't participate in BGP. I'm going to use loopback interfaces to peer with. The following configuration will not work correctly, but it is to illustrate how BGP behaves.
**Notes about the configuration**
I have used a peer-group in my configuration. The peer-group is a locally significant configuration where you can apply the same parameters you'd usually have with a neighbor statement. But if you have a lot of neighbors it can save plenty of command lines. On my clients it may have been excessive to use, but if I decide to add another reflector, then I just need one line of configuration.
I have used the loopback interfaces to peer with. The reason for this is, in iBGP it may be desirable to have a connection with the BGP router, even if the physical link goes down. In my setup it won't matter, because I don't have any redundant links. But if I did, the OSPF would reroute the peering interface. Why we'd want this and risk potential longer paths for our traffic is a topic much down the road. There are some clear use cases for this, like MPLS l3 VPN. Along with the loopback interface I also need an extra command update-source loopback0. The update source command tells the router to use the loopback interface for BGP transmission. If this command isn't used, no neighbor will establish. Technically, I only need this command on one side, but the router with the update source command will ALWAYS be the TCP client, because that is the only router capable of initiating the contact. Save yourself and use the update source both places to start with, though. Use the show ip bgp neighbor and scroll some down to find this:
As stated in the introduction post, the TCP server will use port 179 and the client will be the random port.
Time for verification of how it works. When using the route reflector we get our full mesh configuration, but with much easier management. What does R4 know, though?
R4 only has knowledge of the reflector, it doesn't share a connection with R3. So to validate that R4 and R3 can share BGP advertisements, I'll create a network on R4 and advertise that.
Great, advertisement works. But, this won't be able to ping or send traffic between the 192.168 network. R2 doesn't participate in BGP and we haven't advertised the network in our IGP. Once it reaches R2, the packet is dropped, because there is no routing entry in R2's table. It's so basic, yet it can fool us because the network is right there in the routing table. Having synchronization turned off is what allows this. If I use synchronization in BGP, this route would not be advertised like this. On R1, the routes will be received as advertisements from R3 and R4 (I added an extra network on R3), but they will not be installed in the routing table and they will not be advertised further.
The routes are there, but they are missing the ">" mark, which indicates that they are used to route with.
A traceroute showing the failure happening once it reaches R2.
**What are the fixes?**
I can add R2 to the BGP process. That way it'll get the 192.168 network advertisement and it'll know how to route the packets. The other solution is to advertise the 192.168 into OSPF. The latter is likely more desirable. Having the IGP know all the networks underneath BGP is not an issue. We'd have that without BGP as well. BGP is just an extra feature that provides a lot of functionality in regards to new peering ways with the ISP and it provides us with the most lovely MPLS L3 VPN in our datacenter.
Confederation is not something I will get into here, but it's basically a segmentation with sub-AS. You take some of the routers and put them into a confederation group, where they will have to peer in full mesh. Then there are one or more routers acting as a bridge between the sub-AS domains.
I had planned to put eBGP and iBGP into the same post, but it looks like it'll be a bit too much.