news@m2xenix.psg.com (Randy Bush) (03/20/91)
We have a metronet here in the Portland area, RAINet. We are using SLIP (often
with PC-Route), and most sites have multiple hosts on a local ether.
With one exception (a private C), we are all sharing a single class C using a
subnet mask of 0xf8. As each of the SLIP links must be a subnet, we're chewing
up our class C rather quickly. So, we seek advice on how to best regroup and
reorganize.
We have read the paper by Tsuchiya, "On the Assignment of Subnet Numbers",
which describes a scheme for managing a net in which subnet masks differ in
length. But are confused by the following question. If all the neighbors of a
router have a subnet mask <= n bits, how does this router send to a distant
site whose subnet mask is > n bits. To elaborate (thanks to Alan Batie):
Suppose you have Subnets A (1001), B (010), C (110), D (001) and E (1000).
A <-> B <-> C <-> D <-> E
All three of C's interfaces (link to B, link to D and local network
interface) have a subnet mask of 11100000. My theory is that C will
send all packets for subnet addresses 100 to E, except for packets for
a host "10010000", which won't exist, because that is A's "this network"
address.
To be fair, he does say that you need support for varying subnet masks,
and specifically mentions OSPF, which does propagate the subnet mask as
well as the address.
In general, we are unsure whether the varied software (PC-Route, SysV/386,
Xenix, NeXT, VMS/TGV) in RAINet will be able to handle varying subnet masks.
We also have another concern. As many of the inter-site links are or will be
V.32 or so, we are worried that RIP will eat up bandwidth.
Some of the alternatives we see are:
o get a class B and subnet with a mask of 0xfff0, with SLIP links still
eating up a subnet apiece,
o get a class B and subnet with a mask of 0xff00, but keep the current
class C for the SLIP links using a subnet mask of 0xfc,
o each site get its own class C (even if they have but two hosts), and use
the current C for the SLIP links using a subnet mask of 0xfc, thereby
creating a gawdawful lot of underutilized class Cs,
o get n class Cs, where n is, for example, sites/5, and clump multiple sites
in each C according to physical topology in order to cut down RIP use of
the small bandwidth, and
o we're sure there are others.
We presume that we're missing something obvious, that others have gone before
us, and so await your sagely advice.
--
Randy Bush / news@psg.com / ..!uunet!m2xenix!news kwe@bu-it.bu.edu (Kent England) (03/22/91)
> From: news@m2xenix.psg.com (Randy Bush) > Newsgroups: comp.protocols.tcp-ip > Subject: Help designing address allocation in a metronet > Date: 20 Mar 91 15:06:15 GMT > > We have read the paper by Tsuchiya, "On the Assignment of Subnet Numbers", > which describes a scheme for managing a net in which subnet masks differ in > length. But are confused by the following question. If all the neighbors of a > router have a subnet mask <= n bits, how does this router send to a distant > site whose subnet mask is > n bits. > ... The router only has to worry about variable subnet masks for the subnetted net that it participates in. For distant nets it uses the netmask that it derives from the net class. Within the variably subnetted net, the router must have the mask for each route. This is most easily gotten from the routing protocol and most easily stored in the routing table. > In general, we are unsure whether the varied software (PC-Route, SysV/386, > Xenix, NeXT, VMS/TGV) in RAINet will be able to handle varying subnet masks. > They will all have to support OSPF or some other protocol with variable length subnet support or else don't vary the subnet mask length. (Try gated.) > We also have another concern. As many of the inter-site links are or will be > V.32 or so, we are worried that RIP will eat up bandwidth. > Another argument for OSPF, which is link state and not distance vector. Milo Medin has documentary evidence of reduced routing bandwidth in the NASA internet to prove that link state is better in this regard. The way most people do this sort of thing is to have one network for the WAN and each site has its own independent network space. Is Class C big enough for RAINnet itself? Set the subnet mask all the way down to two nodes per subnet. That's two bits for the host part, 0 and 3 are reserved, 1 and 2 are the endpoints of the link. Make every subnet in the RAINnet net the same length. Every host or router not directly on RAINnet simply routes to the netmasked route. That should work and it won't waste subnet space. If the mask size is constant you don't need OSPF. If you are passing around all RIP routes, try judicious use of default routes. Prefer dynamic default via RIP. If that isn't good enough then try OSPF or some other link state algorithm to reduce traffic levels. --Kent
tsuchiya@THUMPER.BELLCORE.COM (Paul Tsuchiya) (03/22/91)
> Another argument for OSPF, which is link state and not > distance vector. Milo Medin has documentary evidence of reduced > routing bandwidth in the NASA internet to prove that link state is > better in this regard. > Sorry Kent. I know this is a REAL nit, but you hit on one of my pet peeves. The advantage of OSPF over RIP in the case of link utilization is not that OSPF is link-state and RIP is distance-vector, but that OSPF is event-driven and RIP is periodic. One can perfectly well design a distance-vector routing protocol (BGP for instance) that is event-driven and therefore doesn't over-utilize link bandwidth. CA*net is running BGP over 56kbps links, and advertising ALL 2000+ network numbers, and is not having problem (except for spikes when a router configures because the whole routing table gets dumped). That being said, I think that link-state does have advantages over distance-vector (like ease of debugging because the whole topology map is right there in every node), but distance-vector also has certain advantages over link-state, like dealing with hierarchies because you don't have the mapping real topology into logical topology problem that results in things like pseudo-nodes. Lecture over :-) PT NAADP (National Association for the Advancement of Distance-vector Protocols)
medin@NSIPO.NASA.GOV ("Milo S. Medin", NASA ARC NSI Project Office) (03/23/91)
Kent, ... The router only has to worry about variable subnet masks for the subnetted net that it participates in. For distant nets it uses the netmask that it derives from the net class. Within the variably subnetted net, the router must have the mask for each route. This is most easily gotten from the routing protocol and most easily stored in the routing table. This isn't quite true. There is no requirement that I know of that subnets have to be connected. In fact, inside an OSPF routing domain, things can be configured to work quite well in this way (we actually take advantage of this for a couple of unique situations). Since the router doesn't know that all subnets are connected , it shouldn't make assumptions about the class of routes. In fact, OSPF is designed without any hardwiring of Class A, B, or C routes in it at all; it's just mask and match. Router vendors should not make distinctions between net and subnet routes in their routing table data structures. There is no need to do it this way. Routing on best match is the really preferred way to go. It's more flexible and doesn't need be any slower... ... They will all have to support OSPF or some other protocol with variable length subnet support or else don't vary the subnet mask length. (Try gated.) If you don't support variable length masks, I wouldn't consider you a compliant OSPF router. The RENO code can support variable length masks, and I think Jeff Honig will take advantage of this when porting the UMD OSPF code to gated... People need to understand that variable length subnets are a real solution to user's problems, and they ought to be firmly supported. Don't let your vendor hedge on this! ... Another argument for OSPF, which is link state and not distance vector. Milo Medin has documentary evidence of reduced routing bandwidth in the NASA internet to prove that link state is better in this regard. In the normal case, you are only flooding deltas, not the full routing table. Jeff Burgan (also from NASA) gave a very nice summary of operational experience with OSPF at the last IETF, not just in NSI but also BARRNET and OARNet, and it's clear that OSPF is a big win here. Additionally, John Moy has calculated that in steady state, OSPF could support passing around ~2000 external net routes on a 9.6 Kbps link using only about 5% of the link bandwidth. If routers are being attacked and destroyed and routing is having to converge to new paths, then this figure will go up, but it's piles better than the utilization of the old style DV protocols in use in various places today. The way most people do this sort of thing is to have one network for the WAN and each site has its own independent network space. Is Class C big enough for RAINnet itself? Set the subnet mask all the way down to two nodes per subnet. That's two bits for the host part, 0 and 3 are reserved, 1 and 2 are the endpoints of the link. Make every subnet in the RAINnet net the same length. Every host or router not directly on RAINnet simply routes to the netmasked route. That should work and it won't waste subnet space. If the mask size is constant you don't need OSPF. If you are passing around all RIP routes, try judicious use of default routes. Prefer dynamic default via RIP. If that isn't good enough then try OSPF or some other link state algorithm to reduce traffic levels. KA9Q supports variable length masks, so I don't think this is that big of a problem. Who knows, it may even support OSPF one day. Thanks, Milo " OSPF: Ask for it by name. Accept no substitutes. " PS Usual disclaimers apply...
brian@telebit.com (Brian Lloyd) (04/14/91)
GAK! You certainly can eat up a lot of address space using SLIP links. The problem is inherent in the "an IP address per interface" and in the "everybody in a (sub)net must share the same (sub)net number" concepts. In spite of the fact that it violates tradition and the router requirements RFC, we chose not to assign a unique IP address to each interface in the Telebit NetBlazer dial-up router. The SLIP or PPP links do not need their own unique IP address and, in fact, all interfaces are allowed to share the same IP address. This GREATLY reduces the number of (sub)nets required to build a network. The trick that we use is to use an interface name in the routing table rather than the gateway address to determine which interface to use. We count on the fact that in a point-to-point SLIP or PPP connetion there can be only one destination for a packet that is shoved into one end of a link. Therefore we really do not care what the IP address is on either end of the link. We trust that the remote peer will behave in a router-like manner and forward the packet along the way toward its ultimate destination. Bottom line is that it works and doesn't eat up address space. -- Brian Lloyd, WB6RQN Telebit Corporation Network Systems Architect 1315 Chesapeake Terrace brian@napa.telebit.com Sunnyvale, CA 94089-1100 voice (408) 745-3103 FAX (408) 734-3333
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (04/18/91)
The current 4.3BSD routed (maybe tahoe, certainly reno) allows you to put more than 1 interface on the same IP host number. That is, SLIP works fine for us, with the ethernet interface and the point-to-point SLIP interface using the same network/host number. There are a few improvements to routed that can be made to improve things in this situation, but they're fairly obvious. Vernon Schryver, vjs@sgi.com