I would have to disagree somwwhat with the last poster.

IGPs such as OSPF are fairly processor intensive .

The reason you would not use IBGP to perform an IGP function is:

- BGP was never designed for an IGP function. As such, you will not get rapid convergence with BGP. Protocols like OSPF and EIGRP will get you sub-second convergence these days.

- In general, you would set up iBGP peering using loopback addresses. In the absence of an IGP, how would you propagate these loopback addresses ?

Paresh

I believe that there are a couple of other aspects to consider about the question of IGP vs IBGP:

- BGP does not carry any information about the topology of the network. Within your AS you probably want to choose routes with some consideration of the topology. Whether it is RIP with hop count, or OSPF with cost (based on bandwidth) or EIGRP metric (based on bandwidth and delay) the IGP attempts to choose the best path based on some characteristics of the topology of the network. BGP does not do this.

- BGP seeks to identify the single best path to a destination and does not (in general) do equal path load sharing. Within your AS you probably would like to do load sharing which all the IGPs will do.

- the loop avoidance mechanism of BGP is to look at the AS numbers in the AS path. This is effective between ASes but is not very effective within an AS. The IGPs have more effective mechanisms for avoiding or detecting loops.

HTH

Rick

thanks for your response.

<>

so, if i understand it correctly, by definition, the next hop info from eBGP is carried into iBGP. And u r saying that iBGP may not have a route to reach the next hop and one needs to use either static or IGP to get there?

thanks again...

thanks again

Major reasons for running IGP internally:

1. Enables iBGP peers to discover the route to the peer's BGP interface (e.g. Loopback). BGP interface addresses CANNOT be learned from BGP itself. This is in violation of the BGP design. That's where IGP comes in (IGP = dynamic OR static routing. Anything other than BGP). If BGP learns its neighbor's address via BGP, peering will establish for a couple of minutes, and then torn down again, with an error message. This is called BGP race condition.

2. In a network with multiple internal (non-BGP) routers, you don't need to enable BGP on those (if you do, it'll unnecessarily complicate your iBGP topology). Just leave 'em running whatever IGP you already have (or planning to have), and only run BGP on the "external" routers. OSPF would be a good option as an IGP, if you haven't got one.

To address the issue of eBGP next-hop being carried into iBGP, simply configure neighbor next-hop-self on your eBGP router (only required with iBGP neighbors).

HTH.