> Once upon a time Michael C. Nerone shaped the electrons to say...
> >> Framed-Netmask = 255.255.255.0,
>
> This thread lead to some questions on my part - I discovered we basically
> completely ignore Framed-Netmask. Don't bother using it.
Oh. (Too bad there's no "surpised & confused" smiley)
> Doesn't apply to anything it turns out.
>
> >"Framed-Netmask=255.255.255.240" should be enough for the pm to realize
> >that the route it should advertise is
> >
> > a.b.c.17/255.255.255.240 -> pm1, for hosts a.b.c.16-a.b.c.31
>
> You *can't* advertise that, RIP does not support subnet routes.
Yikes...didn't know that. Good to know.
> Once we add VLSM maybe, but not now. This is what the Netmaks Table is
> a work around for, and why you need to make netmask table entries in all
> of your Livingstn boxes. It is a hack work around, we collapse to a
> 'host route' which other Livingston's with the approprate mask will
> expand back into a subnet route. But you can only broadcastr host
> routes and network routes, not subnet routes.
These strikes me as a VERY incompatible workaround. The vast majority of
us are not used Livingston routers, so our routers never know about your
"fix." And even if they WERE Livingston, what about the computers
themselves. The purpose of all the TS's, routers, etc. is to service the
computers. Will every packet from one of those boxes bound for the
outside subnet have to bounce off of a (Livingston) router in order to
find its way to the pm? Major waste of bandwidth. It seems the only
computers that would not suffer from this are Livingston computers.
Oh - wait -- they don't make any! I would almost prefer that a subnet
route be expanded to a bunch of host routes - almost - at least it would
work.
Ok...would THIS work? : (I know it would if the pm's were more
transparent, and would act like an invisible filtering bridge) Assign an
address from my LAN's class C (x.x.x.x) to the dialup-machine, which will
be a router. Then just set static routes everywhere on my LAN that say
the remote guy's subnet (y.y.y.16/255.255.255.240) should be routed
through x.x.x.x. The reason I don't think this works right now is that
the x.x.x.x must be the NEXT HOP, but since the pm's advertise
"route add x.x.x.x the.pms.own.address," x.x.x.x is now 2 hops away. Can
the pm be made to just be a bridge, and not advertise ANY route, yet still
pick up packets bound through for the subnet and pass them through?
If the user had a dedicated line, this problem would be easy. But I've
got quite a few who want only want dial-up, on-demand LAN connectivity,
and I don't want to waste a line and, more importantly, a port on each of
them. I need them to be able to dialup, and everything work no matter
which pm they dial into.
> >in RADIUS. This works fine for a full class C; BUT: For the 16-ip subnet
> >above, where do we put the netmask???? Well, the netmask table of
> >course--IN THE PM's. Notice the "'s". This has to be put in the netmask
> >table for every single PM?!?!? What happened to the nice centralized
> >RADIUS attributes, etc?
>
> You can't do it in RADIUS because it is a hack, we are basically sneaking
> around behind RIP's back. The netmask table was created due to user
> demand, wishing to violate RIP. The real solution is still in the future.
> ...
> The long run answer is VLSM, CIDR, and OSPF.
CIDR and OSPF have not become standard (or even available, to my
knowledge) fare in TS's. I guess that means every time this need has
arisen in the past, you had no choice but to dedicate an interface on a
router. This application seems obvious, SOMEONE must have implemented a
less expensive solution. After all this time, nobody's bothered to make a
RIP+ standard or something that covers this HUGE shortcoming in RIP?
Subnetting is not a brand new concept.
Michael Nerone | Internet Direct, Inc. | http://www.txdirect.net
nerone@txdirect.net | 722-B Isom Rd. | Please direct all queries
| San Antonio, TX 78216 | to sales@txdirect.net.
| Voice: (210)308-9800 | Direct all tech questions
| Fax: (210)308-9240 | to support@txdirect.net
Opinions herein are my own and may not reflect those of my employer.