Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!uunet!mcsun!unido!rsp!tom From: tom@rsp.UUCP (Thomas Ruf) Newsgroups: comp.sys.novell Subject: Re: Encapulation of Novell IPX packets over TPC/IP networks? Message-ID: <1046@rsp.UUCP> Date: 8 Jan 91 10:34:27 GMT References: <1044@rsp.UUCP> <11090002@acf3.NYU.EDU> <19477@netcom.UUCP> <2546@excelan.COM> Distribution: comp Organization: RSP Datensysteme, W-Germany Lines: 33 forster@dustbin.cisco.com (Jim Forster) writes: >This is one of the scaling problems -- manual configuration. Not too bad >for a handful of tunneling routers, but even if the limit of 20 were boosted, >its not a good solution for a large network. The manual configuration could easily be avoided by adding redundant configuration servers. >I think Brian's got it, but to be more specific about the problems, run the >numbers: if there are 20 tunneling routers, then every 30 seconds each >sends a RIP update to all the others, by sending 19 separate packets >accross the IP net. And it also receives 19 packets. So the 1 RIP packet >per 30 seconds turned into about 20 every 30 seconds, or almost 1 per >second. And the IP net sees about 12 per second (20*20/30). >Stated another way, this is an N**2 (N-squared) solution, which is not good. It's only N**2 if all the routers are neighbors of each other. By building a tree shaped hierachy of routers, it can be reduced to N - at the cost of additional hops in some paths. But Jim is right: our IPX/IP tunneling doesn't scale well - that's the reason we felt a limit of 20 peers *per router* would be appropriate. Meanwhile we increased this limit from 20 to 120 - due to customers requirements. However, when we designed the IPX/IP tunneling, we decided to keep it as simple as possible - if *IPX* doesn't scale well, why should the tunnel ? Thomas -- Thomas Ruf tom@rsp.de Schneider & Koch GmbH Schneider & Koch, Inc {uunet,mcvax}!unido!rsp!tom Germany Palo Alto