> Has anybody mentioned the benefits of ISIS as an IGP to them.
Link-state protocols are evil, and when they break, they *really* break.
I still do not see a compeling argument for not using BGP as your IGP.
Alex
iBGP is only one half of an IGP. It is the "where to go" half.
You still need some other igp (isis, ospf, rip, static routes, etc) for
the "how to get there" half.
Most large providers carry next-hops (loopbacks, border /30 (or /31), etc)
around in either isis or ospf, and carry the remainder in iBGP.
The reason?
With link-state, one interface flap can mean doing SPF on every route.
If "every route" is only a couple hundred, rather than 100K, you fare
better when circuits are flapping. At that point, comparing the precomputed
metric amongst 100k routes is (imho) rather trivial, especially when
"igp metric" is a few steps down the decision tree.
In all practicality, you need to haul, at least, eBGP routes around in iBGP,
you need some kind of other igp to jumpstart iBGP, and is advised that this
other igp have some concept of metric or cost to be able to give BGP
some hints. Whether you choose to make your non-BGP igp lean and mean
(disabling synchronization, with the attendant caveats) or fat and happy
(and suffer the consequences during repeated link state changes), is up
to the reader, but you still really need two igps.
With link-state, one interface flap can mean doing SPF on every route.
Only if you learned every one of your routes from different neighbor.
If you have two exits and 100000 routes, you calculate twice and
apply the results to the prefixes.
Note that this does not apply to a proprietary, "hybrid", semi-link
state protocol marketed with name "EIGRP" where all routes need
per-prefix calculation. (OSPF and IS-IS work fine)
> > Has anybody mentioned the benefits of ISIS as an IGP to them.
>
> Link-state protocols are evil, and when they break, they *really* break.
> I still do not see a compeling argument for not using BGP as your IGP.
Convergence time?
> Alex
iBGP is only one half of an IGP. It is the "where to go" half.
You still need some other igp (isis, ospf, rip, static routes, etc) for
the "how to get there" half.
Most large providers carry next-hops (loopbacks, border /30 (or /31), etc)
around in either isis or ospf, and carry the remainder in iBGP.
The reason?
With link-state, one interface flap can mean doing SPF on every route.
If "every route" is only a couple hundred, rather than 100K, you fare
As you say disable synchronization and try and control the physical reach of
your igp by some mechanism.. areas, summaries, ASes etc
> Link-state protocols are evil, and when they break, they *really* break.
> I still do not see a compeling argument for not using BGP as your IGP.
>
> Alex
iBGP is only one half of an IGP. It is the "where to go" half.
You still need some other igp (isis, ospf, rip, static routes, etc) for
the "how to get there" half.
Most large providers carry next-hops (loopbacks, border /30 (or /31), etc)
around in either isis or ospf, and carry the remainder in iBGP.
The reason?
With link-state, one interface flap can mean doing SPF on every route.
If "every route" is only a couple hundred, rather than 100K, you fare
better when circuits are flapping. At that point, comparing the precomputed
metric amongst 100k routes is (imho) rather trivial, especially when
"igp metric" is a few steps down the decision tree.
In all practicality, you need to haul, at least, eBGP routes around in iBGP,
you need some kind of other igp to jumpstart iBGP, and is advised that this
other igp have some concept of metric or cost to be able to give BGP
some hints. Whether you choose to make your non-BGP igp lean and mean
(disabling synchronization, with the attendant caveats) or fat and happy
(and suffer the consequences during repeated link state changes), is up
to the reader, but you still really need two igps.
Rubbish.
Every interface that you have has a connected route or static route. Those
routes are distributed into your favourite BROKEN[1] IGP. There is no need
to do that. Originate that route as a BGP route with set-igp-community
route-map on itm if you want to do something only with routes that are
internal to your network. Your customers wont care about convergence of BGP
if your network does not break due to the funky IGP implementations.
Alex
[1] Any protocol that allows a non-affected path to be taken out of service
by an affected path is BROKEN BY DESIGN. Any network that requires a
protocol, which is broken by deisgn to function, is a badly designed
network.
>
> > > Has anybody mentioned the benefits of ISIS as an IGP to them.
> >
> > Link-state protocols are evil, and when they break, they *really* break.
> > I still do not see a compeling argument for not using BGP as your IGP.
Convergence time?
What is better - relatively long convergence time on affected routes or a
problem on unaffected route?
Ask your customers. They do not care if someone else is having a problem.
They care that they dont.
> With link-state, one interface flap can mean doing SPF on every route.
> If "every route" is only a couple hundred, rather than 100K, you fare
As you say disable synchronization and try and control the physical reach of
your igp by some mechanism.. areas, summaries, ASes etc
Which is exactly what you are doing when you inject nailed routes into bgp.
>
> >
> > > > Has anybody mentioned the benefits of ISIS as an IGP to them.
> > >
> > > Link-state protocols are evil, and when they break, they *really* break.
> > > I still do not see a compeling argument for not using BGP as your IGP.
>
> Convergence time?
What is better - relatively long convergence time on affected routes or a
problem on unaffected route?
Ask your customers. They do not care if someone else is having a problem.
They care that they dont.
Do you run a decent sized network? Convergence time in the order of that taken
by BGP is not acceptable, things go crazy when traffic pours in and theres no
routes to carry it.
Other example, what about static dialup users, they dial up and wait a few
minutes whilst their route is installed throughout BGP??
> > With link-state, one interface flap can mean doing SPF on every route.
> > If "every route" is only a couple hundred, rather than 100K, you fare
>
> As you say disable synchronization and try and control the physical reach of
> your igp by some mechanism.. areas, summaries, ASes etc
Which is exactly what you are doing when you inject nailed routes into bgp.
No its not? I'm suggesting some level of order can help control the number of
routers required to reconverge a network, I dont see the comparison with
inserting routes in BGP which is how the routes get in not how they converge.
> > >
> > > > > Has anybody mentioned the benefits of ISIS as an IGP to them.
> > > >
> > > > Link-state protocols are evil, and when they break, they *really* break.
> > > > I still do not see a compeling argument for not using BGP as your IGP.
> >
> > Convergence time?
>
> What is better - relatively long convergence time on affected routes or a
> problem on unaffected route?
>
> Ask your customers. They do not care if someone else is having a problem.
> They care that they dont.
Do you run a decent sized network?
No, I have never touched a router in my life.
Convergence time in the order of that taken by BGP is not acceptable,
things go crazy when traffic pours in and theres no routes to carry it.
This is a great blanked statement. What is convergence time?
Other example, what about static dialup users, they dial up and wait a few
minutes whilst their route is installed throughout BGP??
That is why their route is *nailed* via BGP to the router that *always*
provide connectivity to them. If they have to move, BGP injectors are your
friends. Takes seconds.
> > > With link-state, one interface flap can mean doing SPF on every route.
> > > If "every route" is only a couple hundred, rather than 100K, you fare
> >
> > As you say disable synchronization and try and control the physical reach of
> > your igp by some mechanism.. areas, summaries, ASes etc
>
> Which is exactly what you are doing when you inject nailed routes into bgp.
No its not? I'm suggesting some level of order can help control the number of
routers required to reconverge a network, I dont see the comparison with
inserting routes in BGP which is how the routes get in not how they converge.
If you dont have a network wide meltdown due to IGP failure you wont need to
wait for entire network to come up. It is timing of discrete events. Isn't
math grand.
> > > >
> > > > > > Has anybody mentioned the benefits of ISIS as an IGP to them.
> > > > >
> > > > > Link-state protocols are evil, and when they break, they *really* break.
> > > > > I still do not see a compeling argument for not using BGP as your IGP.
> > >
> > > Convergence time?
> >
> > What is better - relatively long convergence time on affected routes or a
> > problem on unaffected route?
> >
> > Ask your customers. They do not care if someone else is having a problem.
> > They care that they dont.
>
> Do you run a decent sized network?
No, I have never touched a router in my life.
Possibly..
> Convergence time in the order of that taken by BGP is not acceptable,
> things go crazy when traffic pours in and theres no routes to carry it.
This is a great blanked statement. What is convergence time?
The time from when traffic starts hitting down interfaces or null to when it
starts going again. Preferably without the rest of the network needing to know
about it and suffer meltdown.
> Other example, what about static dialup users, they dial up and wait a few
> minutes whilst their route is installed throughout BGP??
That is why their route is *nailed* via BGP to the router that *always*
provide connectivity to them. If they have to move, BGP injectors are your
friends. Takes seconds.
See previous comment about network size - theres no such thing as always in
dialup with multiple geographic PoPs.
> > > > With link-state, one interface flap can mean doing SPF on every route.
> > > > If "every route" is only a couple hundred, rather than 100K, you fare
> > >
> > > As you say disable synchronization and try and control the physical reach of
> > > your igp by some mechanism.. areas, summaries, ASes etc
> >
> > Which is exactly what you are doing when you inject nailed routes into bgp.
>
> No its not? I'm suggesting some level of order can help control the number of
> routers required to reconverge a network, I dont see the comparison with
> inserting routes in BGP which is how the routes get in not how they converge.
If you dont have a network wide meltdown due to IGP failure you wont need to
wait for entire network to come up. It is timing of discrete events. Isn't
math grand.
Reconvergence after a single link failing is hardly failure/meltdown?
> > > problem on unaffected route?
> > >
> > > Ask your customers. They do not care if someone else is having a problem.
> > > They care that they dont.
> >
> > Do you run a decent sized network?
>
> No, I have never touched a router in my life.
Possibly..
> > Convergence time in the order of that taken by BGP is not acceptable,
> > things go crazy when traffic pours in and theres no routes to carry it.
>
> This is a great blanked statement. What is convergence time?
The time from when traffic starts hitting down interfaces or null to when it
starts going again. Preferably without the rest of the network needing to know
about it and suffer meltdown.
How many seconds does it take your network to meltdown from traffic?
> > Other example, what about static dialup users, they dial up and wait a few
> > minutes whilst their route is installed throughout BGP??
>
> That is why their route is *nailed* via BGP to the router that *always*
> provide connectivity to them. If they have to move, BGP injectors are your
> friends. Takes seconds.
See previous comment about network size - theres no such thing as always in
dialup with multiple geographic PoPs.
Route-injection is your friend.
bgp-push and avi-bgp are your friends.
> > > > > With link-state, one interface flap can mean doing SPF on every route.
> > > > > If "every route" is only a couple hundred, rather than 100K, you fare
> > > >
> > > > As you say disable synchronization and try and control the physical reach of
> > > > your igp by some mechanism.. areas, summaries, ASes etc
> > >
> > > Which is exactly what you are doing when you inject nailed routes into bgp.
> >
> > No its not? I'm suggesting some level of order can help control the number of
> > routers required to reconverge a network, I dont see the comparison with
> > inserting routes in BGP which is how the routes get in not how they converge.
>
> If you dont have a network wide meltdown due to IGP failure you wont need to
> wait for entire network to come up. It is timing of discrete events. Isn't
> math grand.
Reconvergence after a single link failing is hardly failure/meltdown?
How many SECONDS does it take to for your network to meltdown from normal
traffic level?
Alex ran a decent sized network back when there were a lot of Crisco bugs
which managed to wipe out entire networks running OSPF. Now admittidly I
havn't seen one of these in a while (according to UU they've been shifting
their focus to ISIS bugs which wipe out entire networks :P), but we are
all a product of our past experiences.
Experience is a good thing, but it can also be limiting. Things change,
and sometimes being burned by experience can prevent us from trying things
which may have a different outcome now. That is why humans get old and
die, so new people can make fresh mistakes, and fresh discoveries.
Otherwise we'd still be thinking the world was flat, the sun revolves
around the earth, and man could never travel faster than 20mph. Just
remember that computers change a lot faster than the human lifespan (and
no I'm not encouraging anyone to bump off Alex :P), so even Cisco might
manage to get one right.
Trusting your IGP is a judgement call, but if you ever find yourself in a
situation where you really can't trust it, you can look back on Alex's
post and find a fairly reasonable way to run a network without it. I
suggest we all take it as such and move on, 'cause otherwise this debate
will go on until someone DOES die (and not necessarily old age :P).
