mtinka at globaltransit
Nov 10, 2009, 10:46 PM
Post #26 of 26
(33 views)
Permalink
|
On Wednesday 11 November 2009 05:13:40 am Richard A
Steenbergen wrote:
> <arguing with the teacher hat>
:-).
> I have nothing against advocating that you design your
> network to scale from the very beginning, and (without
> trying to channel Vijay Gill here) IMHO if oyu don't
> design your netwrok to scale then in all likelihood it
> WON'T scale.
Agree.
> But there is also a point where you start
> making more trouble for yourself than you save, and may
> actually inhibit your growth by adding unnecessary
> additional complexity.
Also agree, e.g., it is possible to build too much
redundancy that just ends up being complex, it is possible
to have too many upstream service providers that your eBGP
routing policy becomes too complicated and fails to work as
expected, e.t.c.
We say, "Scale, but KISS".
> Smart network engineering is about
> knowing the network you are trying to build, and figuring
> out where that magic line is so you don't cross it.
Also agree.
Again, we don't say "Scale for scaling's sake", on the
assumption that it is possible for those learning to
misunderstand the message and think scaling = complexity,
and that complexity may be justified by the need to scale.
Unfortunately, without getting into the full details about
the workshops we give, I can understand why you may think we
may be advocating for "blind scaling", for lack of a better
term. But on the contrary, our messages are very specific to
areas where scaling is important, without adding undue
complexity, and keeping things as simple as they should be.
So yes, in principle, agree here also.
> I think your argument applies perfectly to situations
> like "but I only have a few hundred /30s between my 10
> 3560s, why can't I just redistribute connected/static
> into my IGP and call it a day".
:-), not at all, actually.
We NEVER advocate for any customer prefixes (including /30
point-to-points) to be anywhere near the IGP.
We also NEVER advocate for any kind of redistribution
(although we realize a lot of folks tend to trade-off when
it comes to this, mostly due to mind-set, laziness, e.t.c.).
I once gave a workshop where the entire class agreed that
redistribution isn't necessarily a good thing when done
blindly and with laziness as an unconscious motive. We all
agreed that if it was possible, avoid it, unless you really
know what you're doing, e.g., l3vpn's for PE-CE routing,
redistribution controlled with route-maps, e.t.c. Then what
happens, one of the attendees goes back and actually
continues to redistribute all Connected and Static entries
without prejudice because when he joined the trade, it was
engrained in him either by books, mentors, vendor marketing,
e.t.c. - as instructors, we can also only go so far :-\.
> Yes you COULD, but if you
> grow your network by even a very small amount you'll
> start to bump the CAM limits on your stackable switches,
> and thus you should probably engineer your network to
> scale past that limit from the very beginning.
Agree - of course, there are dynamics that cannot be
captured during workshops, e.g., will you use regular
routers at the edge or TCAM-limited so-called Layer 3
switches instead; to run with your example, Richard.
Like you say, there is no magic solution. Our message, while
specific, is also generalized in many areas; scale as long
as you keep simplicity in mind, but adapt to your individual
environments and make your own decisions because no two
networks have the same "pocket-depth", nor do they have the
same topology.
So yes, in principle, agree here also.
> Taking the
> time to design a system with only loopbacks into IGP +
> iBGP loopback peering and redistribution of other routes
> into BGP may be more time consuming than just slapping a
> redist into your IGP, but it will save you more time in
> the end.
But this is exactly what our workshops advocate. Nowhere do
we say you should do anything else :-). IGP only for
infrastructure + Loopbacks. iBGP for all customer prefixes.
Is our message.
But you do get some folk who've heard this for the first
time at the workshop and fail to comprehend why an IGP is
not used for "all internal" routing entries. So they'll
gladly do the workshop with you, as well as the labs, but go
back home and continue to bloat their IGP. Again, as
instructors, we can only go so far.
So yes, agree here also (is it getting old, hehe?).
> On the other hand, what level of scale do you need before
> IGP areas actually start to pay off, and make it worth
> the added complexity and other issues you will impose
> (inter-area TE problems, etc)? You'd need to take your 10
> routers to what? 100? 1000? 10000? At what point does
> your newly expanded network look absolutely nothing like
> your original network, to the point that nothing you
> decided about your 10 router network has any bearing on
> your new network? If you're really designing some massive
> dial network with the potential for 10000 pops, or the
> next IBM Global Services network, you may have a
> legitimate reason for needing the IGP areas. But if
> you're building a more concentrated network there just
> may never be a situation where there is any benefit no
> matter how big you grow (i.e. I don't think Level 3 has
> any need for them :P).
Again, I agree - that's why I mentioned, in my previous post
to you, that our message on "Scale as early as possible (in
correspondence with your individual environment and with
simplicity at heart)", transcends just IGP routing; there's
a lot more to it that will influence the choices the
operators that attend our workshops will make. We look at
the issues holistically, not individually, and hope that the
attendees make the most reasonable design decision based on
the "most neutral" information provided, e.g.:
- Solve the iBGP mesh problem with route reflectors or
confederations. Route reflectors are simpler than
confederations, but there have been corner cases where
confederations have been desirable. Because those corner
cases are few and far between, and we think simplicity in
this case is trumps "corner case", we recommend the use
route reflectors.
- We get attendees asking what model of XR 12000 series or
CRS-1 is better for their core just because the Cisco
product positioning says so, or which model in the
T-series range is better just because Juniper product
positioning says so. Our advice is neutral, "Don't drink
the marketing cool aid. Many networks have 7200-VXR's or
M7i's as core, because that's all they've ever needed in
their plans - and they work".
- Static routing in a 5-router network will work well, but
just because it is small, doesn't mean you should wait
until you explode to 100 routers before you consider
moving to dynamic routing, especially if router and
network resources are not an issue. Here, we're
recommending to scale early because we assume the network
might either grow, or become too complex to manage as the
number of routing entries increases, or both.
- RFD (Route Flap Dampening) has a specific solution to
solve. But given that router control planes are getting
faster, global connectivity is getting more stable with
more sub-sea and terrestrial connectivity coming online,
e.t.c., many networks realize that the troubles RFD
causes may not be worth the perceived benefits. So, if
you have to deploy it, think about what it means to your
business/network - if it were I (the instructor), I
wouldn't for A, B, C, D reasons.
Our goal is not to simply say, "Take our word for it, it's
the rule". Our goal is to foster open and unrestricted
thinking, with some basic guidelines, of course.
So yes, in principle, agree here also.
> There is no right answer for
> everyone, your network may look very different from mine,
> etc.
Agree, based on my arguments above. We try to provide
fundamental principles with basic guidelines, not rules.
The idea is knowledge transfer, not technology transfer.
To analogize, "It is wrong to kill someone, but just because
we haven't explicitly mentioned that stabbing them without
causing them death is equally as wrong, doesn't mean we're
sanctioning it - learn to think beyond the marketing/snazzy
slides/RFC's/vendor-centric fora/news media/standards bodies
meetings, e.t.c.".
> We can both make arguments for simplistic theories
> like "you should always design to scale" vs "keep it
> simple stupid"...
I know this is just an example you're giving, but to nit-
pick, there's no reason why you can't scale and maintain
simplicity at the same time - and I'm sure you agree also
that you can scale while maintaining simplicity, depending
on the situation at hand. But my actual comment on this one
is, some ideologies compliment each other, they are not
always necessarily presented (to be considered) in contrast.
But in general, ...
> until we're blue in the face, but at the
> end of the day this is an engineering question to which
> there is no one correct answer.
... I take your point, and I agree, again, per my arguments
above.
> </arguing with the teacher hat>
I guess the issue here was that you may not be familiar with
the kinds of workshops we run, so it may not be unreasonable
to assume we're teaching "scalability" for its own "sake".
In fact, to illustrate the kind of confusion we put our
attendees through, on the one hand, we say, "Aggregate your
eBGP announcements as much as possible, and where you can,
aggregate your iBGP announcements just as much". On the
other, we say, "Route summarization in a link state IGP
helps scale the network, but it may break optimal routing,
so in this case, we trade-off scalability for optimality".
Attendees get very confused about why we "selectively"
scale, and the devil is in the details, as I'm sure you can
appreciate. However, those that manage to understand the
tactics we use to open up their minds, then ask, "But
doesn't the use of Route Leaking in IS-IS moot the need for
multiple levels on the basis of building a multi-level IS-IS
network just for scaling? So then what is the point of
having multiple levels in IS-IS in the first place?" When we
hear questions like these, we know we have reached success
:-).
There's tons of other cases, but this is the general idea.
We encourage workshops given by other operators, because
there's nothing like it when compared to reading vendor
certification material, reading RFC spec's, reading vendor
product marketing data sheets, or attending classes given by
individuals that have learned how IP networks work, but have
never run a network.
> Did I mention I got a lot of D's in class from arguing
> with the teacher?
+1 :-).
Cheers,
Mark.
|
signature.asc
