Thursday 8 November 2018

BGP Series 3: Need for iBGP when we have OSPF

Need of iBGP communication for the routes, when we have the IGP protocols (OSPF, RIP) for internal communication?:

  • Scalability: Imagine that you're receiving 500,000 EBGP routes in more than one location, 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. (Also, if we redistribute the BGP tables into IGP, due to huge processing/flooding requirements of IGP can cause major outages)
  • Enforce boundaries of trust / control: BGP has many more knobs than IGPs for controlling what you advertise and receive.
  • Flexible tools: 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).

iBGP isn't really used for internal routing, it is used by all your eBGP routers to share their routes.

Ex: If you are peering with 3 other network, you want all your eBGP routers to know the routes received by the other ones so they can propagate that information to the peers if necessary/needed (opening thus the possibility of your peer using transit through you)

In Short:

Inside an autonomous system, we will run both iBGP and IGP. For routing within that AS, only IGP is used since routes for all the networks will be available in IGP table itself. But, if we have to communicate with an IP address in another AS, the host will not know the route. In that case, iBGP will have the routes sent from the other eBGP peers, so that the host will have BGP route to the remote peer. Also, iBGP is used to redistribute the IGP routes onto BGP for other informing eBGP peers.

No comments:

Post a Comment