(usr-tc) framed-netmask vs. framed-route
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 "majordomo@xmission.com" 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.
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: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
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 San Marcos Internet, Inc. 512-393-5300 ----- Original Message ----- From: Jeff Mcadams <jeffm@iglou.com> To: <usr-tc@lists.xmission.com> Sent: Friday, June 23, 2000 8:45 AM Subject: Re: (usr-tc) framed-netmask vs. framed-route
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: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
Also sprach Mark Thornton
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: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
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 San Marcos Internet, Inc. 512-393-5300 ----- Original Message ----- From: Jeff Mcadams <jeffm@iglou.com> To: <usr-tc@lists.xmission.com> Sent: Wednesday, June 28, 2000 12:51 PM Subject: Re: (usr-tc) framed-netmask vs. framed-route
Also sprach Mark Thornton
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: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
Also sprach Mark Thornton
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: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
participants (2)
-
Jeff Mcadams -
Mark Thornton