Internal BGP (Border Gateway Protocol) explained

I cannot use packet tracer for IBGP confgiuration do we have alternative

Hello Dinesh

It is true that Packet Tracer does not support iBGP. However, you can use several other options. Some of the most popular are GNS3, which is free, or VIRL, which is Cisco’s emulator, which has a subscription cost. You can find out more about these at the following lesson:

Note that the content says that GNS3 doesn’t support switching, but this has since changed. But for iBGP, you’re all set with

I hope this has been helpful!


1 Like

Hi Rene

A quick question…Let us assume R1 and R25 are two routers within an AS trying to establish iBGP via their loopbacks, they already have connectivity via IGP and next-hop-self, update-source is configured as well. If the TTL value of BGP packet is 1, How do those routers become peers when they are multiple hops away? Is it because the BGP packet is encapsulated into underlying OSPF/MPLS protocol header?

Thank you

Hello Sai

iBGP peers don’t have a limitation as to the number of hops they are away from each other. The TTL for BGP packets sent between iBGP peers is always set to the maximum, just like any other IP packets. The only prerequisite for iBGP peering is that there is a routable path between BGP peers.

This limitation however does exist for eBGP. If you have two eBGP routers and you want to have them peer using a loopback as the update-source, then peering will not occur unless the eBGP multihop feature is used. You can find out more information about this at the eBGP multihop lesson.

I hope this has been helpful!



Hi Rene,

I have a question. Why actually we need OSPF here and why alone iBGP is not enough. We are already configuring IBGP between all 3 routers in the same AS. So not able to understand the role of OSPF here? Is it only because R2 and R4 not connected. If yes, why? Whether OSPF would be required if there is direct connection between R2 and R4?

Hello Maruti

This is a good question, and is important in order to understand the relationship between IGPs and BGP. Think about it this way. BGP is used to route traffic between AS’es while IGPs are used to route traffic within AS’es.

Now the next question that usually comes up is “since we’re using iBGP within an AS, why configure OSPF as well?”. Actually, iBGP within an AS is not used to route the traffic within the AS, but is used to share internal routes with the BGP routers on the edge of the AS so that they can advertise them with other BGP routers in other AS’es via eBGP.

So in order for iBGP to share these routes with all iBGP routers within an AS, routing capabilities between all BGP enabled routers within the AS via an IGP must be established.

Remember that an IGP is always better to use within an AS rather than BGP. You can find out more about why at the following post:

I hope this has been helpful!



Hi Rene / Laz and Team,

I am trying to recreate this in GNS3 LAB and came with an issue. While creating the IBGP between R2 and R4, please explain why we need update-source command. Because without it I am unable to make the neighborship.

In my lab, i cannot make the IBGP peer without the update-source command. Here is my config:

adding the diagram and

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to, timeout is 2 seconds:
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms
R2#show ip bgp summar
BGP router identifier, local AS number 1
BGP table version is 4, main routing table version 4
1 network entries using 140 bytes of memory
1 path entries using 76 bytes of memory
1/1 BGP path/bestpath attribute entries using 136 bytes of memory
1 BGP AS-PATH entries using 24 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 376 total bytes of memory
BGP activity 2/1 prefixes, 2/1 paths, scan interval 60 secs

Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd         4            1       0       0        1    0    0 00:11:26 Idle    4            2      30      29        4    0    0 00:22:56        1
R2#show runn | sec bgp
ipv6 multicast rpf use-bgp
router bgp 1
 bgp log-neighbor-changes
 neighbor remote-as 1
 neighbor remote-as 2


R4#show ip bgp summar
BGP router identifier, local AS number 1
BGP table version is 1, main routing table version 1

Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd         4            1       0       0        1    0    0 00:12:57 Idle    4            3      18      17        1    0    0 00:12:57        0
R4#show runn | sec bgp
ipv6 multicast rpf use-bgp
router bgp 1
 bgp log-neighbor-changes
 neighbor remote-as 1
 neighbor remote-as 3
R4#show ip int brief | i up
Ethernet0/0      YES manual up                    up      
Ethernet0/2      YES manual up                    up      
Loopback0             YES manual up                    up


Hello Justin

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.

I hope this has been helpful!


Hello Laz,

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?

Hello Justin

Yes, that is correct!


Hello @lagapides,

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.

Hello Tejas

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.

Yes, this is exactly correct.

I hope this has been helpful!


@lagapides thank you for quickly resolving my query. Its super clear now

1 Like

Hello Guys,
@ReneMolenaar @lagapides
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.


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

Hello Tejas

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.

I hope this has been helpful!


Hello Ike

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

I hope this has been helpful!


Hi Lazaros,
Thank you very much for the explanation and referring lessons. It’s much more clear now.

1 Like

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?

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 I got no response.