23

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.

Improve this question
0

7 Answers 7

Reset to default
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.

Improve this answer
2
  • 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, 2016 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, 2016 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.

Improve this answer
6
  • 1
    BGP is a Path vector protocol, which is not the same as a Distance Vector Protocol
    – Mike Pennington
    Nov 10, 2013 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, 2013 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, 2013 at 13:34
  • 2
    Which page claims BGP is not distance vector?
    – ytti
    Nov 10, 2013 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, 2013 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.

Improve this answer
3

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)

Improve this answer
0

EBGP exchanges internet (i.e. global) prefixes/routes from other Autonomous systems (EBGP peers). To reach those prefixes, someone should distribute/advertise across the internal network, IBGP comes to the rescue. IBGP advertises these global prefixes to the routers within the Autonomous System (AS). Why not IGP does the same? As IGP is quite chatty (i.e. in fact not designed for handling a large number of routes), one can say IGP is an intra-AS protocol and cares about the internal network (topology) and abstracted from external/global network, but it does have provision to leak few global prefixes in the IGP domain.

Improve this answer
0

what i think IGP we uses for reachability first than your IBGP for sharing routes . If you are not running any protocol like Static/EIGRP/OSPF for reachability . your IBGP will come up ???? answer is no if we don't have reachability to our next hop IBGP is not going to come up. Second thing IGP 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.

Improve this answer
0

Traffic in a network can be divided into 4 categories.

  1. Ingress: traffic arriving from outside the network, destined for hosts within the network.
  2. Egress: traffic originating inside the network destined for hosts outside the network.
  3. Internal: traffic where both the origin and destination are within the network
  4. Transit: traffic where both the origin and destination are outside the nework.

The IGP normally carries internal routes, so it can be used to directly route ingress and internal traffic, but what about egress and transit traffic. There are basically three choices.

  1. Use iBGP
  2. Use default routes.
  3. Redistribute external routes into your iGP.

Redistributing the whole internet routing table into your iGP will not end well. iGPs simply are not designed to deal with hundreds of thousands of routes. A combination of default routes.

If you have only one router that connects to the outside world, then you don't need iBGP. You can simply use a default route to direct egress traffic to your border router. If you have multiple routers that connect to providers then you can still use default routes, but by doing so you lose some of the advantages of multi-homing.

And once you add transit customers into the mix then those customers may well ask for BGP feeds from you. Kinda hard to provide those if the routers the customers are connectd to don't have BGP tables themselves.

That said, routers that can handle the whole internet routing table can be quite costly, so it's not uncommon to split a network into "core" and "access" sections where the core runs BGP and has the whole inernet routing table while the access portion only knows internal routes and uses default routes to pass everything else to the core. Care is needed to avoid inadverantly creating routing loops though.

Improve this answer

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.