Whenever you create a BGP neighbor adjacency, the IP address specified in the update-source command of one router must match the IP address specified in the neighbor command in the other.
I went in and labbed this up and found that if you use the loopback address in both neighor commands on both routers, and you don’t include the update-source command on either router, a peering will not appear. However, if you use the update-source command on one of the two routers, they are able to “see” each other and the peering does take place. But remember, the peering will take place with the physical interface of one of the routers, which is not best practice, so it’s always best to use the loopback, and use the update-source command on both devices.
Ok, so if I understand, the reason we don’t see a neighborship is that both routers are expecting BGP TCP SYN from the loopback IP and when we configure one with the update-source command the other router will respond with TCP SYN ACK but it will then use it physical IP to make the BGP establishment. Correct?
My query is that will two IBGP neighbors (which are 2-3 hops way) form neighbor ship with each other even if no IGP route is present. I want to understand what will be state of neighbor ship.
I understood that they will be able to share routes only if IGP/static routes are present.
In order for two iBGP routers to form a neighborship, there must be IP connectivity between the interfaces taking part in the neighborship. In other words, you should be able to ping the IP address of one router from the other. This can be achieved either using static routing, or using an IGP. If routing between these IPs is not established, then no iBGP peering can exist.
If the iBGP routers are directly connected, then there is no issue of routing between them, because they are both on the same subnet, therefore the directly connected networks appear in the routing table, and connectivity is ensured. But if the routers are 2 or more hops away, IP connectivity must be established by either an IGP or static routing. Otherwise, no peering takes place, and no routes can be exchanged.
Remember than in a single AS, all iBGP routers must form a full mesh of neighbourships in order for iBGP to function correctly.
Hello Guys, @ReneMolenaar@lagapidis
I had a query. What if we have a large backbone with 100s of P routers & use IBGP full mesh. What problems can we face other than load on CPU , managing/configuring lots of IBGP peers & Cost of deployment.
Hello,
As I understand, one of the reasons of we need iBGP ; due to any of IGP protocols can not handle too much internet routes in their database while BGP can do. But what about RIB and FIB or CEF tables. Do they handle that much route in their tables?
Thanks in advance
A good way of examining what problems you might face with an extensively large full mesh iBGP network, we can take a look at the mechanisms used to make such a situation viable. These include BGP Peer Groups, BGP Route Reflectors, and BGP Confederations.
Peer groups are used to reduce the complication of the actual configuration, and to reduce the number of individual updates to be prepared and sent out, saving on both CPU cycles, as well as bandwidth usage.
Route reflectors eliminate the need for full mesh connectivity, reducing the number of peerings, thus making configuration and management simpler, making more efficient use of network bandwidth, and reducing the burden on CPU and memory.
Confederations also reduce the number of iBGP peerings, thus reducing complexity, CPU, memory, and network bandwidth.
I think you essentially covered the problems faced with extensively large iBGP full mesh networks, except maybe for the efficiency of network usage.
Yes, BGP in general is used in order to route traffic between Autonomous Systems (AS). iBGP shares routes within each AS while eBGP shares routes between AS’es. BGP is designed to deal with the large routing tables associated with routing on the Internet. IGPs are not able to handle such routing, as they were not designed for it.
Now you must keep in mind that routing protocols and the features that you describe (RIB, FIB, CEF) are not the same thing. Routing protocols define algorithms and methods of communication between routers to share routes between them. The RIB, FIB, and CEF are data structures and processes within a router that are used by all routing protocols to achieve their function. So the RIB, FIB, and CEF work with routing protocols to get the job done.
You can find out more about these data structures/processes in the following
Hi Team,
Should you use Lo interfaces only with iBGP or with eBGP as well?
With iBGP you can use IGP’s as you have demonstrated, but does that leave you with static routes in eBGP?
Hi,
Just doing some labbing between iBGP and eBGP.
I have configured lo’s between the ibgp peers and distributed the networks between them using an IGP.
Is it correct to then advertise the networks learned in the IGP into BGP so the eBGP peer can then see it? I have attached a picture to hopefully clear what I am trying to say up.
As I could see that R1 had no idea how to get back, verified this by debugging the packets and could not see any reaching R1 and also when trying to ping 192.168.2.5 I got no response.
Remember that BGP’s primary function is to share prefixes between AS’es while IGPs are used to share prefixes within an AS. Now if you have a prefix within an AS that you want devices in other AS’es to have access to, then this is the prefix that you should advertise to iBGP, which will in turn advertise it to other AS’es via eBGP. If you have prefixes that you don’t want other AS’es to access, then you don’t need to advertise them to BGP.
So the criteria to use is “do I want a host in another AS to access my prefix?” If so, then advertise them, if not, then don’t.
Thank you for clearing that up for me. But the one question I have left is, what is the recommended approach to advertise loopback interfaces between two routers participating in eBGP and using loopback interfaces as the update source? From what I understand, in this case IGP’s are not recommended as they are interior protocols… does that leave just static routing?
When you say “this is the prefix that you should advertise to iBGP”, do you mean for example, R3 learning about 1.1.1.1 in my example, would then advertise that network as a BGP network statement rather than am IGP statement?
Also is the way that I have advertised routes in my diagram the correct way of thinking?
I think the answer to my question is, the way to do it is to create that static route between eBGP peers to point to the loopback address via the next hop ?
Then in each peer, even though the other router is advertising the loopback address / network to the peer. The on said peer the static route will take precedence and therefore in ‘show ip bgp’ the route learned via BGP will have a rib failure… at least that is what I am experiencing.
R1 should have a loopback interface with an IP address of 1.1.1.1/24. This is not included in the configuration, but I will let Rene know to add it. Rene does state in the lesson that:
In our scenario, AS1 has a loopback interface with network 1.1.1.0 /24 and AS3 wants to reach this network.
I believe this should be R1 has a loopback…. I will let Rene know to make the changes. In the meantime, if you create a loopback interface on R1 with an IP address of 1.1.1.1 your configuration should work and will match the results of the lesson.
