Rubbish again.
*Every* interface that you bring up has a connected route. You redistribute those routes into IGP. You redistgribute statics from that router into IGP. Nail those routes into bgp and set internal community on it.
network xxx.yyy.zzz.www mask ppp.hhh.ooo.lll route-map set-igp-community.
So how does this provide equivalent functionality to "compare igp metric"?
First of all, did we agree by now that there is no scalability issue or do we need to go over this again?
I think there are a lot of folks out there who might like to do the whole nearest-exit thing.
set metric +1 is your friend.
Even if you went to the trouble of setting up route-maps to your heart's content and managed to get each router to prefer paths from the nearest exit router, it wouldn't do you much good when a link failure turns that "nearest" into "furthest" but the iBGP session stays up.
You metric would be appropriately affected. next-hop-self and confederations are your friends.
I think maybe the word "need" is being taken a little too seriously here. No, you don't NEED a separate IGP to make BGP work. But then again, you don't NEED a lot of things to make a network go in its most basic form. However, without some of those "unnecessary" things you might not find it to perform quite to your liking either. For my network, I'd much rather deal with some extra SPF calculations than slow convergence and playing route map games to get things like nearest-exit working.
There are no route-map games. You can basically have the same route-map on all internal links. Of course it requires to be able to construct logical "if then" trees, as well as know some fundamental algebra.
Links and loopbacks => IGP Everything else => BGP
IGP trouble -> entire network down with hundreds of otherwise unaffected customers experiencing connectivity problems and getting hard earned $$ back, sending yet another network into ochapter 11.
But then, nobody ever accused any two engineers of having the same personal preferences...
-c
--