Subject: (usr-tc) framed-netmask vs. framed-route

From: Mark Thornton <[email-masked]>
Date: Fri, 23 Jun 2000 01:32:43 +0000

I have always set up my routed connections on my TCH's by assigning the
framed-address and framed-netmask from my radius server (VopRadius) and it
has worked great. I am adding a Cisco router to the mix for ADSL aggregation
and have been working on getting that configured. In the process of doing so
I noted that on a Cisco it appears I should use the framed-route attribute
in order to set up the route for the connection (ne mention of using
framed-netmask). I know the Hiperarc's will automatically create a route for
each connection and distribute it via rip or ospf. Is this how I have
avoided needing to deal with the framed-route attribute before now? Is there
any benefit to including the framed-route in the radius response to the NAS?

Thanks for your assistance,

Mark Thornton
San Marcos Internet, Inc.
512-393-5300

-
 To unsubscribe to usr-tc, send an email to "[email-masked]"
 with "unsubscribe usr-tc" in the body of the message.
 For information on digests or retrieving files and old messages send
 "help" to the same address.  Do not use quotes in your message.

---

From: Jeff Mcadams <[email-masked]>
Date: Fri, 23 Jun 2000 15:50:22 +0000

Also sprach Mark Thornton
>I have always set up my routed connections 

I assume by this you are referring connections over PPP to a network
with a network of routable IP addresses rather than just an individual
computer at the end of the PPP link.

>on my TCH's by assigning the framed-address and framed-netmask from my
>radius server (VopRadius) and it has worked great. I am adding a Cisco
>router to the mix for ADSL aggregation and have been working on getting
>that configured. In the process of doing so I noted that on a Cisco it
>appears I should use the framed-route attribute in order to set up the
>route for the connection (ne mention of using framed-netmask). I know
>the Hiperarc's will automatically create a route for each connection
>and distribute it via rip or ospf. Is this how I have avoided needing
>to deal with the framed-route attribute before now? Is there any
>benefit to including the framed-route in the radius response to the
>NAS?

Basically, this is two different ways of accomplishing almost the same
thing.

Let me see if I can explain how this all works using my home network as
an example...

My RADIUS user's file entry is as follows:

jeffm   Authentication-Type = Unix-PW
        Service-Type = Framed
        Port-Limit = 2
        Idle-Timeout = 0
        Framed-Routing = None
        Framed-IP-Netmask = 255.255.255.255
        Login-Service = Telnet
        Session-Timeout = 0
        Framed-IP-Address = 204.255.229.145
        Login-IP-Host = 0.0.0.0
        Framed-Route = "204.255.229.144/28 0.0.0.0 1"
        Framed-Compression = Van-Jacobson-TCP-IP
        Framed-Protocol = PPP
        Login-TCP-Port = 23

So, you'll see from that, that my IP address assigned to my home netgear
router is the first useable address from the Framed-Route that is
assigned to it.

When the Arcs get this RADIUS response, they put two routes in their
routing table (yes, this is somewhat inefficient, but we have other
reasons for doing this), the first network it puts in the routing table
is 204.255.229.145/32...this comes from the Framed-IP-Address and
Framed-IP-Netmask, the destination for this route is the interface that
I'm connected on, so it just sends it out the PPP connection.  This is
the IP address assigned to my netgear router.  The second route is
204.255.229.144/28, with a next-hop of 204.255.229.145, basically, this
sends the rest of that block of 16 addresses to the IP address of
204.255.229.145, which, again, is the IP address of my netgear router at
the other end of the PPP link.  (FYI, the netgear router uses PPP
unnumbered on the PPP link, so that IP address is actually assigned to
the ethernet interface on the netgear and it "borrows" that IP address
for the PPP negotiation...this isn't terribly relevant here though)

The same effect could be achieved by setting the Framed-IP-Address to
204.255.229.145, and the Framed-IP-Netmask to 255.255.255.240.  The only
difference is that the Arcs would then only set up a single route
204.255.229.145/28 with a next-hop of the interface.  The netgear would
handle it the same way and the routing would basically work the same way
(just with one less route lookup in the Arc when the destination IP
address is anything within that block other than 204.255.229.145)

I'm not sure what documentation or whatever you're looking at in the
Cisco, but the functioning of these parameters *should* be largely the
same (of course, we *should* also be getting better support from 3Com,
but we see that things don't always happen the way they should ;).
Anyway...*hopefully* my explanation above has given you an idea of how
those three attributes interact (at least in the Arc).  Let me know if
that has helped or not.

Sorry so long...wanted to get a good explanation on how these things
worked, so you can hopefully better figure out what you need to do given
your situation.
-- 
Jeff McAdams                            Email: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

-

---

From: Mark Thornton <[email-masked]>
Date: Wed, 28 Jun 2000 18:52:33 +0000

I am having a problem where any static ip address I assign to a client gets
the wrong netmask. The same thing happens if they get the ip address from
the TCH. It is probably a result of my assigned ip range 63.90.208.0 -
63.90.223.0, but it always comes up as a class a network. Does this cause
problems, or should I ignore it?

Mark Thornton

----- Original Message -----
From: Jeff Mcadams <[email-masked]>
To: <[email-masked]>
Sent: Friday, June 23, 2000 8:45 AM
Subject: Re: (usr-tc) framed-netmask vs. framed-route

-

---

From: Jeff Mcadams <[email-masked]>
Date: Wed, 28 Jun 2000 19:55:13 +0000

>I am having a problem where any static ip address I assign to a client
>gets the wrong netmask. The same thing happens if they get the ip
>address from the TCH. It is probably a result of my assigned ip range
>63.90.208.0 - 63.90.223.0, but it always comes up as a class a network.
>Does this cause problems, or should I ignore it?

In the old classful concept of things, yeah, 63.x.x.x would be a Class A
(a /8 in current parlance).  So, if you're dealing with things that only
understand old school classes, yeah, you're going to have this problem
(either it will be handled as a host route for the individual IP
address, or as a /8 network).  This will be the problem if you're using
RIPv1, or, if you're not specifying a netmask on things when you're
setting up the IP address, it will likely default to /8.  How is this
being assigned?  Is the netmask specified in the method that you're
using to assign it?  <voice="Bones from Star Trek">Good God, we need
details, man!</voice>  :)
-- 
Jeff McAdams                            Email: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

-

---

From: Mark Thornton <[email-masked]>
Date: Wed, 28 Jun 2000 20:17:00 +0000

An example client is Win98. When we check the assigned address and netmask
with winipcfg it shows the netmask to be 255.0.0.0 everytime. I have tried
assigning from the pool, and a static ip and both give the same result. I
have noticed the same behaviour on Netgear routers that claim to support
RipV2 which would imply classless routing support. I have looked at the ppp
negotiation and don't see where the netmask is negotiated with a client
device, ever. Am I missing something?

Mark Thornton

----- Original Message -----
From: Jeff Mcadams <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, June 28, 2000 12:51 PM
Subject: Re: (usr-tc) framed-netmask vs. framed-route

-

---

From: Jeff Mcadams <[email-masked]>
Date: Wed, 28 Jun 2000 20:33:24 +0000

>An example client is Win98. When we check the assigned address and
>netmask with winipcfg it shows the netmask to be 255.0.0.0 everytime. I
>have tried assigning from the pool, and a static ip and both give the
>same result. I have noticed the same behaviour on Netgear routers that
>claim to support RipV2 which would imply classless routing support. I
>have looked at the ppp negotiation and don't see where the netmask is
>negotiated with a client device, ever. Am I missing something?

Ah...client side of the PPP negotiation...

There is no mechanism in PPP to negotiate netmask, so the client side
has to sorta guess.  Here's the issue though...since you're dealing with
"point to point" protocol...there's only two systems on it, there's
really no reason to use any netmask other than /32 (other than
brain-dead software that doesn't understand how to use host routes on a
link).

I have no clue how to configure windows to handle this without major
brain-damage, but rest assured, its really not your TC config that's
causing it.
-- 
Jeff McAdams                            Email: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

-