Can anyone explain me what is the need of IBGP communication for the routes, when we have the IGP protocols (OSPF, RIP) for internal communication?
Scalability1: Imagine that you're receiving 500,000 EBGP routes in more than one location2, and you need to influence the per route exit point in your AS. BGP can handle many more routes than IGP protocols. Thus, iBGP is required unless you're willing to redistribute all the routes you've learned via eBGP
Enforce boundaries of trust / control: BGP has more ways to filter peers than IGPs (for controlling what you advertise and receive).
Flexible data structures (somewhat related to the previous bullet): BGP communities, BGP Extended communities, local-pref, etc... these make BGP an attractive way to implement custom routing policies within your own autonomous system (by using iBGP).
As with everything there are trade offs; the scalability, control, and flexibility you get from iBGP means that it's a slower converging protocol than IGPs (in general).
End Notes:
1 Scalability:
- You use BGP because you don't want to carry your entire internet routing table in your IGP (i.e. in my case, OSPF)...
- OSPF was not designed to handle many thousands of routes in internet BGP tables... if you try to use OSPF for this purpose, it will break your network. Using the example of OSPF, the LSA processing / flooding requirements from 500,000 routes uses too many resources in your routers. Name any other IGP (EIGRP, RIPv1/2, IS-IS, IGRP) and the same story is true.
- There have been some notorious instances where a Tier-1 ISP accidentally redistributed their BGP table into their IGP (even when the internet table was a small fraction of its current size) and it caused major outages. Countermeasures have now been implemented in IGP protocols (like this one for OSPF in IOS) to prevent redistribution from BGP into OSPF from causing a major outage.
2 iBGP routing example:
To understand why you might want iBGP, consider this routing entry to 4.2.2.2...
R2>sh ip bgp 4.2.2.2
BGP routing table entry for 4.0.0.0/9, version 3146
Paths: (32 available, best #7, table Default-IP-Routing-Table)
... <!-- extra BGP RIB entries deleted -->
7660 2516 3356, (aggregated by 3356 4.69.130.4)
203.181.248.168 from 203.181.248.168 (203.181.248.168)
Origin IGP, localpref 100, valid, internal, atomic-aggregate
Community: 2516:1030
3356, (aggregated by 3356 4.69.130.6)
4.69.184.193 from 4.69.184.193 (4.69.184.193)
Origin IGP, metric 0, localpref 100, valid, internal, atomic-aggregate, best
Community: 3356:0 3356:3 3356:100 3356:123 3356:575 3356:2012
... <!-- extra BGP RIB entries deleted -->
There are 32 paths to consider... In this case, BGP chose to go to 4.0.0.0/9 via 4.69.184.193 (notice the best under the RIB entry). In this case, BGP chose this because this route has the shortest AS Path list. However, not all routes will be preferred via AS3356 (attached to R1). Some may be preferred out R3 (via AS7660). iBGP gives you the ability to know (at R2) which way to go to take the shortest BGP path.
BGP route to 4.0.0.0/9 via
NH: 4.69.184.193 [Path: 3356]
-------->
eBGP w/ AS3356 }{ iBGP inside AS64000 }{ eBGP w/ AS7660
S1/0 S1/2 S2/1 S2/3 S3/2 S3/0
Peered w/ AS3356 +------+ +------+ +------+ Peered w/ AS7660
4.69.184.193 <------| R1 |---------| R2 |--------| R3 |-----> 203.181.248.168
+------+ +------+ +------+
| S2/0
|
^
^
| Ingress packet to 4.2.2.2
|
R1, R2 and R3 are fully-iBGP meshed. When iBGP advertises a route, the next-hop remains unchanged. This means I need to carry the subnet for 4.69.184.193 in OSPF...
R2>sh ip route 4.69.184.193
Routing entry for 4.69.184.192/30
Known via "ospf 100", distance 110, metric 65536, type intra area
Last update from 192.0.2.109 on GigabitEthernet3/1, 1w0d ago
Routing Descriptor Blocks:
* 192.0.2.109, from 192.0.2.3, 1w0d ago, via Serial2/1
Route metric is 65536, traffic share count is 1
R2>
Thus when a packet for 4.2.2.2 arrives at R2, R2 sends it out Serial2/1 because that's where iBGP tells us the next-hop is.
Maybe I missed something, but I'm not sure why you can't subnet your network to get a few /32s and /31s.
It seems that you have 12.0.0.0/26 available for further subnetting?
I would allocate public /32s for loopbacks and advertise them into IGP.
Links between routers are p2p, so I would address them with public /31s.
iBGP sessions should survive link failure, so I would source them from loopbacks.
It's not a good idea to use private IP addresses on transit links, because it can cause problems, e.g. break PMTUD.
Best Answer
As I can understand from your typed text, you/customer want to advertise ibgp routes from his MPLS over eBGP.It is possible and you can do this via Inter-as option C solution 2 with controlled redistribution (or PBR to VPN solution).