Which is exactly what you are doing when you inject nailed routes into bgp.
So, why do you need IGP such as OSPF again?
Alex
To carry the bgp next-hops around the network? You could add in statics
for every next-hop on every router, but this kind of configuration is
complex and prone to errors such as loops in relatively minor cases.
statically routing every next-hop "does not scale". Not to mention
that many of us like the "compare igp metric" portion of the BGP decision
tree.
Having had the displeasure of having to deal with a network which had
static routes as its sole igp, I'ld never want to see _that_ again.
Thankfully, we managed to merely migrate the customers off that network,
rather than even try to pull apart the twisty maze of static routes.
> Which is exactly what you are doing when you inject nailed routes into bgp.
>
> So, why do you need IGP such as OSPF again?
>
> Alex
To carry the bgp next-hops around the network? You could add in statics
for every next-hop on every router, but this kind of configuration is
complex and prone to errors such as loops in relatively minor cases.
statically routing every next-hop "does not scale". Not to mention
that many of us like the "compare igp metric" portion of the BGP decision
tree.
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.
Having had the displeasure of having to deal with a network which had
static routes as its sole igp, I'ld never want to see _that_ again.
Thankfully, we managed to merely migrate the customers off that network,
rather than even try to pull apart the twisty maze of static routes.
So how does this provide equivalent functionality to "compare igp
metric"? I think there are a lot of folks out there who might like
to do the whole nearest-exit thing. 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.
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.
Links and loopbacks => IGP
Everything else => BGP
But then, nobody ever accused any two engineers of having the same
personal preferences...
> 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.
Routers that learn a route over IBGP need to know where the next hop
address for route from other AS points to. Since this can't be a loopback
address and you typically don't run an IGP on subnets between border
routers in your AS and a remote AS, you need to either set next-hop-self
on all IBGP sessions or redistribute connected in your IGP.