At 11:51 PM 8/3/2001 -0400, nrf wrote:
>OK all - well, I'd like to wrap up my original post .For those who don't
>know, I was the person who originally started this post on summarization,
>and it has apparently taken a life of its own (I cringed when I first
>started this thread because I had a feeling that it might invite a few
>hecklers, and sure enough, there they were). I apologize to all you who had
>to witness my response to them, but hey, what can I say, I hate flamers. I
>don't want to disrespect anybody, but on the other hand I really don't want
>people disrespecting me.
>
>
>So anyway, enough about that. I would like to summarize some of the pros
>and cons of summarization. Thank you for everybody who replied with
>something constructive. Here is what I got.
>
>Pros:
>1) Faster route-lookup, particularly with very large route tables (on the
>order of thousands of routes)
Generally not true, except in the specific cases of autonomous or
silicon
switching. Modern route lookup time is largely independent of the
number of routes.
When I say route lookup, I'm talking about forwarding. Routing table
update speed is significantly dependent on the number of routes (as
well as other factors).
>2) Masking of route instabilities
>3) Increased scalability of certain routing protocols (for example, the OSPF
>database size increases to the square of the number of networks without
>summarization, but increases only linearly with proper summarization)
>
>Cons
>
>1) More difficult to understand the route table - need to understand the
>true nature of subnetting (this may not be a big deal to most of us, but
>trust me it is a very big deal to some people).
>2) Suboptimal routing (granted, this may not be as big a concern as I had
>first though).
>
>
>And then of course, the applicability of summarization is very much topology
>driven (as discussed by Chuck Larrieu and Michael Williams below). One
>should, I would think, not just throw summarized networks throughout your
>enterprise willy-nilly, but do so only with an understanding of your
>network.
>
>Anything have anything (constructive) to add or change?
One compromise -- design your addressing plan hierarchically,
so if you do subsequently need to summarize, you don't need to
renumber.
>Thanks
>
>
>""Chuck Larrieu"" wrote in message
>[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> > Mike, yours is about the best message in this thread to use as a start
>point
> > for some random thoughts.
> >
> > seems to me that there are architectures and network sizes that do and do
> > not lend themselves to summarization.
> >
> > for example, in the typical small network hub and spoke setup, it's
> > questionable whether or not routing protocols are even required. static
> > routes or Cisco On Demand Routing are probably more than sufficient. yes
>the
> > books all say that static routing doesn't scale. but consider the company
> > that starts with a central site and 10 branch offices, and adds a branch
> > every six months. shared services are all at the hub. the branches don't
> > care about eachother's existence. most of us throw EIGRP onto the routers
> > and have done with it. but in truth, it is unnecessary. there isn't a lot
>of
> > work here, and this is probably good for as long as the model applies.
> >
> > in the case where a new "domain" is added into an existing network,
> > summarization can be quite useful. for example, I am working with a
>customer
> > who is setting up an RLAN as a telecommute network ( DSL at the user
side,
> > ATM at the host side )under the original design, there would have been
one
> > net for each wan link, and one net for each home user device, /30s in all
> > cases. rather than advertise hundreds of /30's we planned on
>summarization,
> > advertising only two routes into the corporate domain.
> >
> > another interesting case I came across at another customer site. EIGRP
> > everywhere in a campus environment. multiple buildings, half of which
were
> > connected via fiber and switches, the other half of which were connected
>by
> > T1's and routers. discontiguous subnets everywhere. we determined that
>there
> > were two entry points from the routed domains into the corporate network,
> > and we figured we could summarize at the classful boundary at each of
>these
> > entry points, and advertise those summaries to the appropriate domain.
> >
> > I'll have to look up my notes on the topology in this case. it made sense
>to
> > summarize at the time.
> >
> > what I am getting at is that topology can be the main driver in
>determining
> > the usefulness of summarization. since the question was asked, I am
>assuming
> > that the asker works in an environment where summarization is possible
and
> > makes sense ( except for the issue of the clueless subordinates, but
>that's
> > another story.
> >
> > good post, Mike.
> >
> > Chuck
> >
> > -----Original Message-----
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
> > Michael L. Williams
> > Sent: Thursday, August 02, 2001 5:19 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Just how important is route summarization in typical
> > [7:14734]
> >
> >
> > I guess (to flip your question around) are there any cons to using
> > summarization? You can't argue that it's extra administration is a con
> > because the basis of your argument is that the network is rather small,
so
> > using summarization where it can be used takes literally seconds to put
in
> > place, and needs no troubleshooting. So, IMHO, the pros of summarization
> > always outweighs the cons (none).
> >
> > But to deal more directly with your questions, let's start at the
smallest
> > level, 2 routers. With two routers (connected by a common network or a
> > point to point link) summarization really has no place. If you look at 3
> > routers in the following layout:
> >
> > LAN A -- R1 -- LAN B -- R2 -- LAN C -- R3 -- LAN D
> >
> > In this scenario, it's possible that the connection between R2 and R3
>could
> > fail or change, but if R2 were summarizing to R1, R1 wouldn't have to be
> > "bothered" by any difficulties on LAN C. Although the amount of CPU time
>or
> > memory on R1 that is saved in this example is neglegible, it can be said
> > that any CPU or memory that is saved is > 0. The same could be said
about
> > summarizing on the link from R2 to R3 where problems on LAN B.
Therefore,
> > the 2 seconds it took to summarize on both interfaces of R2 yields some
> > amount of CPU time and memory that is not wasted on R1 and R3, and
>therefore
> > is a good thing, no matter how small.
> >
> > I would them extend this logic to more routers..... You could even take
>the
> > time to examine different partial- or full-mesh designs, but
summarization
> > really kicks in when there are networks that are more than 1 hop away
that
> > could be affected by routing updates triggered by a given LAN or WAN
link,
> > etc...
> >
> > So again, IMHO, any benefit in CPU and memory usage is > 0 and therefore
> > makes summarization worthwhile. So my answer to the "cost-benefit" is
>that
> > there is virtually no cost yet a guaranteed benefit, so anything network
> > with more than 1 hop from any given router can benefit from
>summarization...
> >
> > I gotta say (just now re-reading your cons), 1st) suboptimal routing
> > shouldn't be a side effect of summarization. If the network is setup
> > hierarchical (sp?), then you could summarize on virtually every router
and
> > it would never yield a suboptimal path. 2nd) Pain in the posterior to
> > configure and maintain? Takes seconds to configure, and virtually no
> > maintenance. 3rd) Inability to see your whole network from any router?
> > Do you mean picking a router at random and doing a "sh ip route" and
>seeing
> > a routing entry for every router? Why would you need this ability?
>Isn't
> > the main goal of the router to know how to get to routes as opposed to
> > "seeing" the other routers?
> >
> > My 2 cents...
> >
> > Mike W.
> >
> > "nrf" wrote in message
> > news:[EMAIL PROTECTED]...
> > > Ok look. Everybody who has replied has given me examples of how large
> > > networks would benefit. Thank you for those replies. Yet, I perfectly
> > > agree that summarization is indeed quite useful for large networks.
>This
> > I
> > > have never doubted, and I specifically excluded large networks from my
> > > question.
> > >
> > > I just have doubts about whether smaller-scale networks really
benefit.
> > > Summarization seems to be a technique that really benefits larger
> > networks,
> > > but on the other hand comes with its own set of cons (suboptimal
>routing,
> > > just the pain in the posterior to configure it and maintain it,
>inability
> > to
> > > see your whole network from any router, etc.)
> > >
> > > So, let me pose my question a different way. Forget my original
>question,
> > > and let me ask everybody this. Can anybody propose a cost-benefit
> > > analysis that shows at what point do the pros of summarization outweigh
> > the
> > > cons? Surely nobody will be able to propose an exact mathematical
> > formula,
> > > so what I'm looking for is more of a design rule-of-thumb.
> > >
> > >
> > >
> > >
> > >
> > >
> > > wrote in message
> > > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> > > > I agree that route summarisation may not speed up route lookup much.
> > But
> > > > there's other far more valid reasons for doing it.
> > > > The network I work with is not ISP size in terms of routes, but it's
> > > pretty
> > > > big, with hundreds of geographically dispersed sites - without
> > > > summarisation, we'd have thousands of routes. Here's some reasons
why
> > we
> > > > summarise... mostly they would apply to smaller networks as well.
> > > > If you summarise (sensibly), you can hide route flaps from a large
>part
> > of
> > > > the network. If an ethernet segment in Bourke falls over, the router
>in
> > > > Broome really shouldn't have to care less. By summarising, you
>restrict
> > > > the number of routers that have to recalculate routes, so routers
>spend
> > > > less time thinking about how to route and more time forwarding
packets
> > > > (hopefully).
> > > > If you summarise (sensibly), you can reduce the amount of route
> > > information
> > > > in your routing tables. Forget routing lookup time - depending on
>your
> > > > routing protocol, this can substantially reduce the amount of data
>that
> > > has
> > > > to be transferred between routers (less overhead traffic), and reduce
> > the
> > > > amount of calculations the router has to do. Again - less time doing
> > (and
> > > > sending) background stuff, more time to route "real data".
> > > > If you summarise (sensibly), it's much easier to read the ip routing
> > table
> > > > - fewer pages of info to wade through :-)
> > > >
> > > > I tweaked the summarisation of our network several months ago.
> > > Previously,
> > > > we had been having occasional problems that were usually being put
>down
> > to
> > > > "OSPF recalculations" (mostly erroneously, IMO, but it was creaking
> > > > occasionally). Since summarisation was beefed up, there have been no
> > > > problems (or maybe people just decided they couldn't point the finger
>at
> > > > OSPF any more :-)
> > > >
> > > > JMcL
> > > >
> > > > ---------------------- Forwarded by Jenny Mcleod/NSO/CSDA on
>02/08/2001
> > > > 04:48 pm ---------------------------
> > > >
> > > >
> > > > "nrf" @groupstudy.com on 02/08/2001 02:42:45 pm
> > > >
> > > > Please respond to "nrf"
> > > >
> > > > Sent by: [EMAIL PROTECTED]
> > > >
> > > >
> > > >
> > > > To: [EMAIL PROTECTED]
> > > > cc:
> > > >
> > > >
> > > > Subject: Just how important is route summarization in typical
> > enterprise
> > > > [7:14601]
> > > >
> > > >
> > > > Hey all. I'm going to risk starting a flame war by asking the
> > following:
> > > >
> > > > I've been struck by just how much importance Cisco courseware places
>on
> > > > route summarization. For example, every student who goes through
> > > > CCNP-level
> > > > courseware learns about all the various kinds of summarization - OSPF
> > area
> > > > summarization, OSPF stubs, EIGRP summarization, etc. etc., and how it
> > > > reduces the size of the route table, thereby improving router
> > performance
> > > > by
> > > > speeding route lookup. It's gotten to the point that Cisco-trained
> > > > personnel treat summarization like the holy grail, and they go around
> > > > trying
> > > > to use summarization techniques wherever they can.
> > > >
> > > > Yet, I seem to recall somebody wrote a book (I believe it was
>Berkowitz)
> > > > that basically stated that the performance gains associated with
> > reducing
> > > > the route table via summarization is virtually nil in typical
>corporate
> > > > networks, because the real delays were caused simply by the
> > serialization
> > > > time of sending packets over slow WAN links (T-1 and slower). Plus,
> > with
> > > > fast-switching and its cousins (optimum switching, MLS, etc.), route
> > > lookup
> > > > isn't done all that often , so there is little lookup delay anyway.
> > And
> > > > besides, most corporate networks aren't very big - typically less
than
> > 100
> > > > route entries, so how much lookup delay could there be? So, when I
> > weigh
> > > > the cons of suboptimal routing as well as the possibility of
> > > > misconfiguration, I find it difficult to see why the typical
>enterprise
> > > > would ever really want to do summarization, as the gains are
miniscule
> > at
> > > > best.
> > > >
> > > > Note, I know full well that ISP's/NSP's and very large enterprises
> > (those
> > > > having on the order of thousands of routes) do indeed benefit
> > > substantially
> > > > from summarization. Of this I have no doubt. What I cannot see is
>why
> > > the
> > > > typical enterprise would really want to use summarization techniques.
> > > >
> > > > Anybody have any thoughts on this?
Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=14948&t=14948
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
