22

Can anyone explain why we need iBGP for the routes when we have the IGP protocols (OSPF, RIP) for internal communication within the AS?

I have read a lot of articles and books, but I could not find the answer.

26

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.

  • Not sure if I understand this part: 'iBGP is required unless you're willing to redistribute all the routes you've learned via eBGP'. If we have two border eBGP routers, router A won't know the routes router B has learned, or vice versa. They need to exchange the information somehow and this is normally done using iBGP. How would you use eBGP for this? I'm not sure how eBGP could make A and B both aware of the routes the other router has learned. – user4205580 Jun 30 '16 at 12:42
  • The statement you're referring to assumes that you have some non-eBGP speakers. Assuming you can't just live with default routes to your eBGP upstreams, at this point you can either: A) redistribute eBGP prefixes into your IGP (usually a bad idea), or B) use iBGP. My answer spends most of the time explaining why iBGP is useful. – Mike Pennington Jun 30 '16 at 22:59
10

IGP usually is OSPF or ISIS which are link-state based, this gives us all the information of the network, everyone knows network from everyone's point-of-view, which allows for very interesting convergence options and traffic engineering options.

BGP is essentially distance-vector, it knows very limited view on the network at whole. BGP handles very well filtering and modifying routing information.

Link-state protocol is quite expensive compared to distance-vector, it would be quite problematic to scale it to INET DFZ size.

So reason why we have both, is because inside one specific network, we have sufficiently low-complexity to handle it with link-state protocol, which allows us to gain all the advantages of high degree of knowledge of network.
But as it does not scale to Internet size, we need some other network to connect these many link-state islands.

You could inside your own network carry all prefixes (including customer) in your IGP, but it will negatively impact IGP performance, while all the convergence and TE advantages can be gained by just carrying loopback addresses of core routers. Adding customer prefixes to IGP only hurts your network performance by making IGP unnecessarily complex.

  • 1
    BGP is a Path vector protocol, which is not the same as a Distance Vector Protocol – Mike Pennington Nov 10 '13 at 13:03
  • 3
    Path vector is essentially specific case of distance vector. It's important to realize that they are very similar in complexity and cost while link-state is completely different. From Sam Halabi's and Danny McPhersons's BGP book, page 98 'This section wouldn't be complete without mentioning that BGP falls into the distance vector gategory' – ytti Nov 10 '13 at 13:11
  • 2
    Path vector is similar but still a different algorithm. You can read more about this in Danny McPherson and Russ White's book, Practical BGP, published in 2004. mobile link – Mike Pennington Nov 10 '13 at 13:34
  • 2
    Which page claims BGP is not distance vector? – ytti Nov 10 '13 at 13:41
  • 2
    AS path is distance-vector. Yes you can manipulate path selections optionally with other parameters as well. So Sam and Danny put it being path vector in addition of being distance vector, I completely share their view on the matter. It might be fun way to consume pint to argue about the matter, but hardly constructive. – ytti Nov 10 '13 at 15:25
7

One reason I've seen quite often is clarity: all routes are carried within one routing protocol (BGP), IS-IS, OSPF or RIP is only used for adjacency. As a result there is no need to redistribute routes from one routing protocol to another.

2

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)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.