This thread lead to some questions on my part - I discovered we basically
completely ignore Framed-Netmask. Don't bother using it.
>Ok...why is the Framed-Route necessary? Why doesn't the pm realize that
>the netmask of 255.255.255.0 implies that there's a Class C on the other
>side (so it should advertise such with RIP)?
There is a lot involved, it ended up being a very long three way discussion
with the top engineers. It gets into the guts of how routing works and I'm
not even going to attept to regurgitate it here - short form, if we did
this we'd break a lot of people badly.
>More generally, the "Framed-Netmask" SHOULD be sufficient to handle
>subnets that happen to be smaller than a Class C, as well. As I see it,
>the "Framed-Netmask" must apply either to the LAN containing the pm
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. 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.
>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.
>pm's, and it's a pain to configure these things in each pm that should be
>handled by RADIUS. What is the *RIGHT* way to do this?
By the RFCs, you shouldn't be doing this at all. With our workaround sneak
you can do it with the Netmask Table.
The long run answer is VLSM, CIDR, and OSPF.
-MZ
-- Livingston Enterprises Technical Support Phone: 800-458-9966 FAX: 510-426-8951 support@livingston.com <http://www.livingston.com/> 6920 Koll Center Parkway #220, Pleasanton, CA 94566