New week new question.
Some days or even weeks I’m struggling with the need and function of iBGP in addition to eBGP.
Let’s assume, that all ASs use OSPF as their IGP. So the protocol has to operate only in the domain of its AS. Every Router is OSPF capable and has a Links State Database (LSB) with the complete view over the network. Based upon this LSB the routing algorithm determines least cost path to every other router in the same AS und puts the prefixes and interfaces in the forwarding table.
And now let’s delve into the functionality of iBGP.
I’ve attached a Photo of a little setup of only two ASs. Is the following chronological sequence right?:
• Router RT1 in AS2 sends reachability information about AS2s subnets via its eBGP session to its Peer RT2 in AS1
• RT2 puts this subnet (140.140.1.0/24) in its forwarding table with the interface on which it receives the advert
• RT2 advertises this subnet to all of its iBGP peers
• RT4 receives RT2s advert and would like to put the new subnet (140.140.1.0/24) into its forwarding table, but it must first determine the best path to get to subnet 150.150.150.0/30
• After running the routing algorithm RT4 can store for example the interface 192.168.1.2 and next hop router RT2 together with new subnet 140.140.1.0 in its forwarding table
TNX
Jan
Hi Jan,
Your list looks good except for the last step. You might want to check the next hop in RT4’s routing table 
In your topology, there is no need to run iBGP within AS1. You only need iBGP when your AS is a transit AS.
After all, there’s only one exit path in AS1 (RT2) so there is no need for all routers to know specific entries. A default route in OSPF advertised on RT2 could do the job.
Here’s an example of a transit AS when iBGP is required:
https://networklessons.com/bgp/internal-bgp-border-gateway-protocol-explained/
Hope this helps!
Rene
Thanks for your quick answer.
Ah ok I think the next hop should be the IP address of RT2s interface 192.168.1.1
Yeah I know, I already watched nearly everything I found about BGP on youtube and on your site here, except some videos which have gone too deep in really configuring the routers. I’m in the step of understanding…
You are right, I showed to stub ASs, that was for simplicity and cause my whiteboard is only 120cm 
actually they should be transit ASs.
Next step, the need of iBGP:
One Reason I figured out while reading https://books.google.de/books?id=IM-Y2W0RIF0C&lpg=PP1&hl=de&pg=PA247#v=onepage&q&f=false is that if an eBGP peer (RT1) would exchange information about its subnets to a neighbouring eBGP peer (RT2) and vice versa and let OSPF redistribute this information, the Links State Database would get incredible huge.
Beside this violates the rule that OSPF should only operate within its AS the performance would get poor.
But in networks everybody lies. I lie to other ASs about the paths I can reach for policy reasons.
Why can’t eBGP lie?
My Idea was the following (consider pdf file):
• An AS counts as one hop if I determine the least cost path from one AS to any other subnet in any AS
• I don’t think (at present) that iBGP is necessary
• Why can’t AS2 pretend to have another topology it really has
• AS2 will lie about its topology and pretend to consist of only one router RT1 which all the subnets directly attached to him (hop count = 0)
• RT1 will advertise its routes over the eBGP session to RT2
• RT2 will install this router and all of its attached links into its Link State Database (what he normally wouldn’t do)
Done.
The default behaviour of the internet would be the same, every subnet into AS2 counts 1 hop from AS1 and they would still do.
//test edit
Hi Jan,
About the next hop, take a look at “next hop self”. I also included an example what the default next hop is when you advertise something from eBGP to iBGP:
https://networklessons.com/bgp/bgp-next-hop-self/
About iBGP…let’s look again at this example:
https://networklessons.com/bgp/internal-bgp-border-gateway-protocol-explained/
As a transit AS we have the problem that R3 doesn’t know what to do when it receives a packet with an unknown destination. Instead of iBGP there are a lot of different methods how you could solve it:
- Redistribute prefixes on R2 from eBGP into OSPF (and vice versa).
- Redistribute prefixes on R4 from eBGP info OSPF (and vice versa).
- You could configure a GRE tunnel between R2/R4 and use the IP addresses in the tunnel as the next hops.
Redistribution would allow R3 to learn any external prefix. Using tunneling would ensure that R3 never sees an external prefix.
Once we are looking at full Internet routing tables, it’s another story. A full Internet routing table has close to 600K entries. You can find a lot of discussions how much prefixes OSPF can handle but an entire Internet routing table is a bit too much That’s why iBGP is a better alternative…
Rene
actually they should be transit ASs.