Using iBGP and an IGP - Where is the cross over point?

[jwbensley]

Where is the cross over point of using an IGP and iBGP?

I recently came across a service provider network where the IGP was ISIS. The only IPs from each router being advertised into ISIS where the loop backs and core link interface addresses. This is roughly only 5~ IPs per router. All other IPs on each router where advertised internally via iBGP (as this is a service provider network this is an extra 30+ IPs per router for the connected customers).

I asked "Why aren't all IPs of each router advertised internally via the IGP (ISIS)?, surely this is quicker for reconvergence? Also, it has no affect on eBGP annoucements to connected AS's because only the supernets are advertised?"

The reponse was "As more routes are added into ISIS convergence will become slower so using iBGP doesn't really have that much effect here".

This makes perfect sense to me, but I assumed this was only the case when you are advertising thousands of routes internally, not a couple hundred as was the case here.

Can anyone ellaborate on this design choice for me please. What are the pros & cons etc?

[In this scenario eBGP pulls the full BGP table in to the RIB on all edge routers which is then advertised via iBGP to all non-edge routes, so all devices have a full table, plus all internal customer prefixes are in the main BGP RIB as explained (except for loop backs and infrastructure links which are in the ISIS database)]

[Sudeep Valengattil · Accepted solution]

Hi,

Below are some of the reasons which I thought off

1. The link state protocols are CPU intensive, and if you are going to advertise all customer facing interfaces into it, the database becomes huge and its not recommended.

2. More over customer facing interfaces has higher chances of flaps and adding these into IGP is not the right way.

3. These are IPs which are actually assigned to a customer and should not be treated as a Internal range.

4. With the separation of core and edge routing into two routing protocols, your network core becomes more stable, as the edge problems cannot disrupt the core.

5. You should never carry your customers' routes in your core routing protocol, as customer's internal problems could quickly affect the stability of your own network.

6. BGP was designed to be a robust, conservative routing protocol able to carry hundreds of thousands of IP prefixes. It was never meant to be a fast-converging protocol

7. You should always use BGP on top of a modern, fast-converging Interior Routing Protocol (IGP), for example OSPF or IS-IS. In such a design, the IGP provides optimum paths through the network core and BGP provides edge-to-edge routing across these paths.

Regards,

Sudeep

[Giuseppe Larosa]

Hello jwbensley,

in addition to Sudeep's post.

If MPLS is in use or it is going to be used, service related IP subnets are advertised in iBGP because in this way MPLS LSPs are used based on BGP next-hop, that is by recursion the service destination is routed via the BGP next-hop that is the loopback address of the remote PE node, that becomes the destination to be looked for in the MPLS forwarding table (recursion).

In any case, it is considered best practice to use the IGP only for the infrastructure (reachability of loopbacks) and to use iBGP to advertise all service or customer related routes.

Hope to help

Giuseppe

[jwbensley]

Hi Giuseppe,

A great additional point! Many providers are using MPLS now so this is a crucial point.

Thank you!

[jwbensley]

Hi Sudeep,

Thanks for some great points that I had completely overlook.

Many thanks!