Re: OSPF multi-level hierarchy: Necessary at all?
Tony Li <tony1@home.net> wrote:
I suspect that the main driver is not the amount of routing information in the gross sense, but the scalability of the protocol as the number of nodes increases.
There's a better solution: decrease the number of nodes by replacing clusters with bigger boxes. This has an additional advantage of reducing number of hops (and, consequently, latency variance). K.I.S.S. rulez :) --vadim PS. Using DUAL or DASM instead of SPF helps, too -- these algorithms tend to eliminate updates which "do not matter" unlike SPF-based algorithms which have to inform everyone about local topology changes.
At 03:33 PM 05/27/1999 -0700, Vadim Antonov wrote:
Tony Li <tony1@home.net> wrote:
I suspect that the main driver is not the amount of routing information in the gross sense, but the scalability of the protocol as the number of nodes increases.
There's a better solution: decrease the number of nodes by replacing clusters with bigger boxes. This has an additional advantage of reducing number of hops (and, consequently, latency variance).
K.I.S.S. rulez :)
--vadim
Side question: At what point do we stop aggregating customers onto a single box? The technology exists now to have hundreds if not thousands of customers on a signle box, but, Do we want that many? -Steve
Anyway, do you aggregate the customers to the single box, or do not, 2 level hierarchy scheme (backbone + AREA for big nodes) is quite satisfacted. Another problem - how do you flood small updates. For example, if we here allocate dial-up addresses from the central cache, amd I inject this host addresses into the network. Through, both methods (OSPF or IBGP) works fine for the middle-size dialup pop's, and I don't think you need to do it instead of using local address-pools in case of large dialup pop's. Alex. On Fri, 28 May 1999, Steve Meuse wrote:
Date: Fri, 28 May 1999 02:58:52 -0400 From: Steve Meuse <smeuse@bbnplanet.com> To: Vadim Antonov <avg@kotovnik.com> Cc: nanog@merit.edu Subject: Re: OSPF multi-level hierarch: side question
At 03:33 PM 05/27/1999 -0700, Vadim Antonov wrote:
Tony Li <tony1@home.net> wrote:
I suspect that the main driver is not the amount of routing information in the gross sense, but the scalability of the protocol as the number of nodes increases.
There's a better solution: decrease the number of nodes by replacing clusters with bigger boxes. This has an additional advantage of reducing number of hops (and, consequently, latency variance).
K.I.S.S. rulez :)
--vadim
Side question:
At what point do we stop aggregating customers onto a single box? The technology exists now to have hundreds if not thousands of customers on a signle box, but, Do we want that many?
-Steve
Aleksei Roudnev, Network Operations Center, Relcom, Moscow (+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 230-41-41, N 13729 (pager) (+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)
On Fri, May 28, 1999 at 01:24:09PM +0400, Alex P. Rudnev wrote:
Another problem - how do you flood small updates. For example, if we here allocate dial-up addresses from the central cache, amd I inject this host addresses into the network.
Although our network is not yet large enough to run into scaling issues, this is exactly our problem. Our OSPF is relatively stable except for two things, both on our dialup pools: o Host level routes appearing from wandering static-ips o Wandering networks from dial-on-demand networks. We have more than one physical dialin POP, so summarization can't take place on the netblocks that these items are allocated from. As these users connect and disconnect this generates most of our churn in our OSPF. Any suggestions on solving this churn issue?
Alex.
-- Jeffrey Haas elezar@pfrc.org "Normal" is a local phenomenon.
Although our network is not yet large enough to run into scaling issues, this is exactly our problem. Our OSPF is relatively stable except for two things, both on our dialup pools: o Host level routes appearing from wandering static-ips o Wandering networks from dial-on-demand networks.
We have more than one physical dialin POP, so summarization can't take place on the netblocks that these items are allocated from. As these users connect and disconnect this generates most of our churn in our OSPF.
Any suggestions on solving this churn issue?
As has been said before: If address allocation fails to match the topology, then you must exchange more routing information. The only ways to address this are to either change the point of aggregation (e.g. merge your POP's address space, containing the churn to these two POPs) or to disallow the migration of addresses between POPs. TANSTAAFL (There Ain't No Such Thing As A Free Lunch) Tony
participants (5)
-
Alex P. Rudnev -
Jeffrey Haas -
Steve Meuse -
Tony Li -
Vadim Antonov