Regarding Use of IGP in BGP networks

[ncnaveen_arasu]

Hi,

Could anyone please explain why we use IGP,IBGP and EBGP in a same Network topology.

What is the use of running IGP in BGP topology.

Synchronization rule in BGP says never use or advertise a route learned from IBGP unless same route is learned from IGP.

Why its so and how it is beneficial.

Please explain, am confused a lot.

Thanks 

Naveen

[Joseph Nelson]

Let's take this in parts:

Could anyone please explain why we use IGP,IBGP and EBGP in a same Network topology.

Depends on the network in terms of scope ( i.e. Internet connected vs internal only vs carrier), scale ( number of routers and number or routes), and administrative preference ( strict separation of routing domains). You couldn't literally write a book to answer this question ( and many smart people have). The short run is if you have a small network ( less than 10-20 routers) and a few hundred routes-- just run an IGP...especially if that network isn't connected to the internet. Event if that network is connected to the internet, running BGP is largely driven by whether you take full/partial routes--some carriers make you run BGP ( even for a default, even though static routing works just fine). Still, in the case of MPLS-VPN (L3VPN), you need to run BGP as a PE-CE protocol so that the carrier knows about your organizations routes. 

What is the use of running IGP in BGP topology.

Also related to the answer above. But more to the point, you need IGP so that BGP can establish a session. Remember, BGP is TCP based and for two peers to talk, they need a way to get to the remote peer...there's where the IGP comes in. Typically, you advertise the link and loopback IP addresses into the IGP-- this way a remote peer that is several hops away from me knows how to get to me and vice versa.

Synchronization rule in BGP says never use or advertise a route learned from IBGP unless same route is learned from IGP.

I've yet to see the case where people turn BGP synchronization on. This is largely because in a carrier environment, I don't have or need this restriction. This is due to the fact that in a carrier environment, BGP is being used to transport reachability information ( routes ) around the network. My BGP routing domain may have customer routes ( L3VPN /L2VPN) or transit routes ( from other ASes)-- none of which need to be in the IGP routing information base ( RIB ).

BGP Synch could be useful in some failover scenarios. Imagine you have a topo like this A<->B<->C. Imagine that Router B is your router and its learning routes via IGP from Router C. You may want Router B to only tell Router A about routes downstream from Router C if and only if Router B actually can get to the routes downstream from Router C. BGP Synch to the rescue. Again, you have to take scope into context: If I'm Amazon, with a Global network, I'd much rather have Router B blackhole the traffic ( because Router C is down) then to have to wait for the Global internet to reconverge because Router B stopped announcing the routes to Router A ( due to synch rule). Some people would differ on this preference.

Really really great questions. Keep them coming!

Joe

Rate if Helpful!

[ncnaveen_arasu]

Hi Joe,

Thanks for your wonderful explanation.

  All Network segments or prefix used in BGP enabled router should be advertised in IGP or only the selected prefix needs to be advertised in IBGP /EBGP Is there any specific standard for this.

If we dont have a fill mesh IBGP topology and if we have not enabled synchronization, will it not create routing loops. or if we have not advertise the prefix in IGP but enabled enabled BGP for that prefix with no sync enabled will it cause problem ?

And without IGP  BGP will not run as it does not estalish TCP sessions right.

Please explain.

Regards,

Naveen

[Joseph Nelson]

All Network segments or prefix used in BGP enabled router should be advertised in IGP or only the selected prefix needs to be advertised in IBGP /EBGP Is there any specific standard for this.

There's no standard that I know of, there might be best-practice RFCs out there, however. It just depends on what you are doing. In general, however, within the same Autonomous System (AS), there's rarely a need to have link/loopback address space in both the IGP and iBGP as the IGP will always be used for forwarding. The duplicate route that exist in the BGP table will only be communicated to BGP peers. 

You may need to have link/loopback address space when both IGP and eBGP is used and then only in specific scenarios. One example would be Inter-AS  Option C for supporting MPLS-VPNs across carrier networks. Its beyond the scope of this thread, but basically, a PE on one AS needs to know the loopback address of a PE  in another AS. The protocol being used between the two carriers is BGP so you may find the link/loopback addresses of PEs that exists in both ASes in the BGP table that is shared _between_ ASes.

Again it depends on your application and the goals you want to achieve.

If we dont have a full mesh IBGP topology and if we have not enabled synchronization, will it create routing loops?

At the BGP protocol level, no. This is because iBGP requires peers to learn about the prefix directly from the originating router ( which implies a direct BGP session). Whatever prefix that _would_ be learned from a non-iBGP peer is not shared among iBGP peers so you don't have a logical loop to deal with.

From a forwarding perspective, also no. Imagine that you redistributed an IGP-learned prefix into BGP. With IGP synch enabled, BGP will not announce the route until the IGP has accepted the route. If IGP no longer uses the route for forwarding, then the route doesn't exist in BGP either ( thus no logical loop).

That doesn't mean that you can't have a forwarding loop just that it wouldn't be caused by the conditions of partial iBGP mesh with no synchronization. You could still have a forwarding loop even when you have synch enabled. Even without redistribution, if the IGP decides to install a route in its RIB BGP will announce the route if its covered by a "network" statement. When that happens if other iBGP peers decide that this BGP peer is the best path the traffic will arrive at this BGP peer. When the traffic arrives, the forwarding decision will be determined by what is is the routing table of this peer which could lead to a forwarding loop. Note that this peer will not forward based on BGP and it may not forward based on IGP ( e.g. a static route configured on this local peer)

... or if we have not advertise the prefix in IGP but enabled enabled BGP for that prefix with no sync enabled will it cause problem ?

The route has to exist in the routing table in order for BGP to announce it. If it the IGP didn't put it into the routing table, how did it get there? Whether there is a forwarding loop depends on the source of the route (i.e. eBGP peer or static route). An easy way to see this happen is in the A<->B<->C topology. Suppose that router B summarizes the prefixes that exist downstream from Router C...suppose router B then tells router A about the summary only. Suppose Router A tells router B about a default route. In this scenario the prefixes are known to router A via BGP. What happens when Router C goes down? A routing loop.

So the purpose of the synch requirement is really to avoid the case where you blackhole traffic between ASes on the principle that you trust the IGP more than you trust the routing table. Remember the routing table could get a prefix in there via a static route where as the IGP should learn ( and remove) the prefix dynamically.

Take a look at the below BGP case study which is could provide more insight into the proper use of BGP synch:

http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/26634-bgp-toc.html#synch

And without IGP  BGP will not run as it does not estalish TCP sessions right.

No. All you need for BGP session establishment is reachability to the remote peer. So you could use a static route to each the remote peer.

Hope that helps

Joe

**Rate if helpful**