Mailing List Archive

Is it window clients connecting to this? If so read this:
http://www.cisco.com/en/US/tech/tk713/tk507/technologies_tech_note09186a0080093c77.shtml

The subnet mask shouldn't be an issue really...can you not route traffic
over the link after it comes up?

jd.


On Fri, Jan 22, 2010 at 4:26 PM, Aaron Seelye <aseelye-lists@eltopia.com>wrote:

> Hello,
>
> I have the following config, and for dynamic IP customers, it seems to be
> good so far (only testing one user, want to get the kinks worked out before
> fully implementing). However, we have a problem in that the subnet mask
> that's being negotiated seems to be a /8 (Old Class A default). Also, if we
> specify the IP address in Radius, the Cisco seems to ignore that in the
> Access-Reply, and continue to assign the original address it'd intended from
> its pool. Any pointers would be greatly appreciated, as the "ppp ipcp mask
> 255.255.255.255" seems to have no effect on the netmask negotiated, and no
> amount of dial turning has yielded results on the Radius-assigned IP issue.
>
> TIA,
>
> Aaron Seelye
>
>
>
> aaa new-model
> aaa authentication login default line
> aaa authentication ppp default group radius
> aaa accounting network default start-stop group radius
>
> vpdn enable
> !
> vpdn-group number
> accept-dialin
> protocol pppoe
> virtual-template 1
> !
> vc-class atm PPP7.1
> protocol pppoe
> ubr 7840
> no ilmi manage
> encapsulation aal5snap
> !
> interface ATM3/0.311 point-to-point
> description POVN
> pvc 3/11
> class-vc PPP7.1
> !
> interface Virtual-Template1
> ip unnumbered FastEthernet0/0
> ip mtu 1492
> peer default ip address pool pppoe146
> ppp authentication pap chap
> ppp ipcp mask 255.255.255.255
> !
> ip local pool pppoe146 192.168.146.1 192.168.146.254
> !
> radius-server host 192.168.131.3 auth-port 1645 acct-port 1646
> radius-server attribute 8 include-in-access-req
> radius-server attribute nas-port format d
> radius-server key 7 03035D13555B7248
>
>
> _______________________________________________
> cisco-nas mailing list
> cisco-nas@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nas
>



--
Josh Duffek
Systems Engineer, CCIE #7409, RCSP
Tredent Data Systems, Inc.
joshd@tredent.com
Desk: (805) 375-4911 ext 415
Mobile: (713) 291-2365
AIM: joshdTDS YIM:joshduffek
MSN: joshdTDS@hotmail.com
** http://support.tredent.com **

No, it's a westell dsl modem. It's giving us problems, presumably
because all of my servers are on the same /8, but I can ping
google/yahoo/whatever IPs that fall outside the /8.

-Aaron

On 1/22/2010 2:44 PM, Josh Duffek | Tredent wrote:
> Is it window clients connecting to this? If so read this:
> http://www.cisco.com/en/US/tech/tk713/tk507/technologies_tech_note09186a0080093c77.shtml
>
> The subnet mask shouldn't be an issue really...can you not route traffic
> over the link after it comes up?
>
> jd.
>
>
> On Fri, Jan 22, 2010 at 4:26 PM, Aaron Seelye <aseelye-lists@eltopia.com
> <mailto:aseelye-lists@eltopia.com>> wrote:
>
> Hello,
>
> I have the following config, and for dynamic IP customers, it seems
> to be good so far (only testing one user, want to get the kinks
> worked out before fully implementing). However, we have a problem
> in that the subnet mask that's being negotiated seems to be a /8
> (Old Class A default). Also, if we specify the IP address in
> Radius, the Cisco seems to ignore that in the Access-Reply, and
> continue to assign the original address it'd intended from its pool.
> Any pointers would be greatly appreciated, as the "ppp ipcp mask
> 255.255.255.255" seems to have no effect on the netmask negotiated,
> and no amount of dial turning has yielded results on the
> Radius-assigned IP issue.
>
> TIA,
>
> Aaron Seelye
>
>
>
> aaa new-model
> aaa authentication login default line
> aaa authentication ppp default group radius
> aaa accounting network default start-stop group radius
>
> vpdn enable
> !
> vpdn-group number
> accept-dialin
> protocol pppoe
> virtual-template 1
> !
> vc-class atm PPP7.1
> protocol pppoe
> ubr 7840
> no ilmi manage
> encapsulation aal5snap
> !
> interface ATM3/0.311 point-to-point
> description POVN
> pvc 3/11
> class-vc PPP7.1
> !
> interface Virtual-Template1
> ip unnumbered FastEthernet0/0
> ip mtu 1492
> peer default ip address pool pppoe146
> ppp authentication pap chap
> ppp ipcp mask 255.255.255.255
> !
> ip local pool pppoe146 192.168.146.1 192.168.146.254
> !
> radius-server host 192.168.131.3 auth-port 1645 acct-port 1646
> radius-server attribute 8 include-in-access-req
> radius-server attribute nas-port format d
> radius-server key 7 03035D13555B7248
>
>
> _______________________________________________
> cisco-nas mailing list
> cisco-nas@puck.nether.net <mailto:cisco-nas@puck.nether.net>
> https://puck.nether.net/mailman/listinfo/cisco-nas
>
>
>
>
> --
> Josh Duffek
> Systems Engineer, CCIE #7409, RCSP
> Tredent Data Systems, Inc.
> joshd@tredent.com <mailto:joshd@tredent.com>
> Desk: (805) 375-4911 ext 415
> Mobile: (713) 291-2365
> AIM: joshdTDS YIM:joshduffek
> MSN: joshdTDS@hotmail.com <mailto:joshdTDS@hotmail.com>
> ** http://support.tredent.com **
>
>
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 9.0.730 / Virus Database: 271.1.1/2638 - Release Date: 01/21/10 23:34:00
>
_______________________________________________
cisco-nas mailing list
cisco-nas@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nas

Ahh gotcha...

It's been awhile since I've looked at this, but...shouldn't aaa
authorization local or radius be on? I would do this:

confi t
aaa authorization network default local
end
debug aaa authen
debug aaa author
debug ppp nego
debug ip peer

and grab "sh ver | i IOS"...(just to make it small)

...And send that in, if the aaa author command doesn't fix it. Aaron can
probably answer this better then I can :)

Thanks,
Josh


On Fri, Jan 22, 2010 at 4:57 PM, Aaron Seelye <aseelye-lists@eltopia.com>wrote:

> No, it's a westell dsl modem. It's giving us problems, presumably because
> all of my servers are on the same /8, but I can ping google/yahoo/whatever
> IPs that fall outside the /8.
>
> -Aaron
>
>
> On 1/22/2010 2:44 PM, Josh Duffek | Tredent wrote:
>
>> Is it window clients connecting to this? If so read this:
>>
>> http://www.cisco.com/en/US/tech/tk713/tk507/technologies_tech_note09186a0080093c77.shtml
>>
>> The subnet mask shouldn't be an issue really...can you not route traffic
>> over the link after it comes up?
>>
>> jd.
>>
>>
>> On Fri, Jan 22, 2010 at 4:26 PM, Aaron Seelye <aseelye-lists@eltopia.com
>> <mailto:aseelye-lists@eltopia.com>> wrote:
>>
>> Hello,
>>
>> I have the following config, and for dynamic IP customers, it seems
>> to be good so far (only testing one user, want to get the kinks
>> worked out before fully implementing). However, we have a problem
>> in that the subnet mask that's being negotiated seems to be a /8
>> (Old Class A default). Also, if we specify the IP address in
>> Radius, the Cisco seems to ignore that in the Access-Reply, and
>> continue to assign the original address it'd intended from its pool.
>> Any pointers would be greatly appreciated, as the "ppp ipcp mask
>> 255.255.255.255" seems to have no effect on the netmask negotiated,
>> and no amount of dial turning has yielded results on the
>> Radius-assigned IP issue.
>>
>> TIA,
>>
>> Aaron Seelye
>>
>>
>>
>> aaa new-model
>> aaa authentication login default line
>> aaa authentication ppp default group radius
>> aaa accounting network default start-stop group radius
>>
>> vpdn enable
>> !
>> vpdn-group number
>> accept-dialin
>> protocol pppoe
>> virtual-template 1
>> !
>> vc-class atm PPP7.1
>> protocol pppoe
>> ubr 7840
>> no ilmi manage
>> encapsulation aal5snap
>> !
>> interface ATM3/0.311 point-to-point
>> description POVN
>> pvc 3/11
>> class-vc PPP7.1
>> !
>> interface Virtual-Template1
>> ip unnumbered FastEthernet0/0
>> ip mtu 1492
>> peer default ip address pool pppoe146
>> ppp authentication pap chap
>> ppp ipcp mask 255.255.255.255
>> !
>> ip local pool pppoe146 192.168.146.1 192.168.146.254
>> !
>> radius-server host 192.168.131.3 auth-port 1645 acct-port 1646
>> radius-server attribute 8 include-in-access-req
>> radius-server attribute nas-port format d
>> radius-server key 7 03035D13555B7248
>>
>>
>> _______________________________________________
>> cisco-nas mailing list
>> cisco-nas@puck.nether.net <mailto:cisco-nas@puck.nether.net>
>>
>> https://puck.nether.net/mailman/listinfo/cisco-nas
>>
>>
>>
>>
>>
>>
>>
>>
>> No virus found in this incoming message.
>> Checked by AVG - www.avg.com
>> Version: 9.0.730 / Virus Database: 271.1.1/2638 - Release Date: 01/21/10
>> 23:34:00
>>
>>

Just was going to write back, authorization fixed the IP address
portion. Still working on the netmask problem though, it doesn't seem
to be taking the value over radius like it does now for the IP itself.
Regarding the debug, there's quite a bit there, should I look for/reply
with something in particular?

-Aaron

On 1/22/2010 3:37 PM, Josh Duffek | Tredent wrote:
> Ahh gotcha...
>
> It's been awhile since I've looked at this, but...shouldn't aaa
> authorization local or radius be on? I would do this:
>
> confi t
> aaa authorization network default local
> end
> debug aaa authen
> debug aaa author
> debug ppp nego
> debug ip peer
>
> and grab "sh ver | i IOS"...(just to make it small)
>
> ...And send that in, if the aaa author command doesn't fix it. Aaron
> can probably answer this better then I can :)
>
> Thanks,
> Josh
>
>
> On Fri, Jan 22, 2010 at 4:57 PM, Aaron Seelye <aseelye-lists@eltopia.com
> <mailto:aseelye-lists@eltopia.com>> wrote:
>
> No, it's a westell dsl modem. It's giving us problems, presumably
> because all of my servers are on the same /8, but I can ping
> google/yahoo/whatever IPs that fall outside the /8.
>
> -Aaron
>
>
> On 1/22/2010 2:44 PM, Josh Duffek | Tredent wrote:
>
> Is it window clients connecting to this? If so read this:
> http://www.cisco.com/en/US/tech/tk713/tk507/technologies_tech_note09186a0080093c77.shtml
>
> The subnet mask shouldn't be an issue really...can you not route
> traffic
> over the link after it comes up?
>
> jd.
>
>
> On Fri, Jan 22, 2010 at 4:26 PM, Aaron Seelye
> <aseelye-lists@eltopia.com <mailto:aseelye-lists@eltopia.com>
> <mailto:aseelye-lists@eltopia.com
> <mailto:aseelye-lists@eltopia.com>>> wrote:
>
> Hello,
>
> I have the following config, and for dynamic IP customers,
> it seems
> to be good so far (only testing one user, want to get the kinks
> worked out before fully implementing). However, we have a
> problem
> in that the subnet mask that's being negotiated seems to be a /8
> (Old Class A default). Also, if we specify the IP address in
> Radius, the Cisco seems to ignore that in the Access-Reply, and
> continue to assign the original address it'd intended from
> its pool.
> Any pointers would be greatly appreciated, as the "ppp
> ipcp mask
> 255.255.255.255" seems to have no effect on the netmask
> negotiated,
> and no amount of dial turning has yielded results on the
> Radius-assigned IP issue.
>
> TIA,
>
> Aaron Seelye
>
>
>
> aaa new-model
> aaa authentication login default line
> aaa authentication ppp default group radius
> aaa accounting network default start-stop group radius
>
> vpdn enable
> !
> vpdn-group number
> accept-dialin
> protocol pppoe
> virtual-template 1
> !
> vc-class atm PPP7.1
> protocol pppoe
> ubr 7840
> no ilmi manage
> encapsulation aal5snap
> !
> interface ATM3/0.311 point-to-point
> description POVN
> pvc 3/11
> class-vc PPP7.1
> !
> interface Virtual-Template1
> ip unnumbered FastEthernet0/0
> ip mtu 1492
> peer default ip address pool pppoe146
> ppp authentication pap chap
> ppp ipcp mask 255.255.255.255
> !
> ip local pool pppoe146 192.168.146.1 192.168.146.254
> !
> radius-server host 192.168.131.3 auth-port 1645 acct-port 1646
> radius-server attribute 8 include-in-access-req
> radius-server attribute nas-port format d
> radius-server key 7 03035D13555B7248
>
>
> _______________________________________________
> cisco-nas mailing list
> cisco-nas@puck.nether.net <mailto:cisco-nas@puck.nether.net>
> <mailto:cisco-nas@puck.nether.net
> <mailto:cisco-nas@puck.nether.net>>
>
> https://puck.nether.net/mailman/listinfo/cisco-nas
>
>
>
>
>
>
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com <http://www.avg.com>
> Version: 9.0.730 / Virus Database: 271.1.1/2638 - Release Date:
> 01/21/10 23:34:00
>
>
>
>
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 9.0.730 / Virus Database: 271.1.1/2638 - Release Date: 01/21/10 23:34:00
>
_______________________________________________
cisco-nas mailing list
cisco-nas@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nas

I guess you don't need the aaa authen debugs, and only really care about the
tail end of debug ppp nego(ncp and beyond)....but add "debug radius". I
think the more debugs the better :)

jd.


On Fri, Jan 22, 2010 at 5:58 PM, Aaron Seelye <aseelye-lists@eltopia.com>wrote:

> Just was going to write back, authorization fixed the IP address portion.
> Still working on the netmask problem though, it doesn't seem to be taking
> the value over radius like it does now for the IP itself. Regarding the
> debug, there's quite a bit there, should I look for/reply with something in
> particular?
>
> -Aaron
>
>
> On 1/22/2010 3:37 PM, Josh Duffek | Tredent wrote:
>
>> Ahh gotcha...
>>
>> It's been awhile since I've looked at this, but...shouldn't aaa
>> authorization local or radius be on? I would do this:
>>
>> confi t
>> aaa authorization network default local
>> end
>> debug aaa authen
>> debug aaa author
>> debug ppp nego
>> debug ip peer
>>
>> and grab "sh ver | i IOS"...(just to make it small)
>>
>> ...And send that in, if the aaa author command doesn't fix it. Aaron
>> can probably answer this better then I can :)
>>
>> Thanks,
>> Josh
>>
>>
>> On Fri, Jan 22, 2010 at 4:57 PM, Aaron Seelye <aseelye-lists@eltopia.com
>> <mailto:aseelye-lists@eltopia.com>> wrote:
>>
>> No, it's a westell dsl modem. It's giving us problems, presumably
>> because all of my servers are on the same /8, but I can ping
>> google/yahoo/whatever IPs that fall outside the /8.
>>
>> -Aaron
>>
>>
>> On 1/22/2010 2:44 PM, Josh Duffek | Tredent wrote:
>>
>> Is it window clients connecting to this? If so read this:
>>
>> http://www.cisco.com/en/US/tech/tk713/tk507/technologies_tech_note09186a0080093c77.shtml
>>
>> The subnet mask shouldn't be an issue really...can you not route
>> traffic
>> over the link after it comes up?
>>
>> jd.
>>
>>
>> On Fri, Jan 22, 2010 at 4:26 PM, Aaron Seelye
>> <aseelye-lists@eltopia.com <mailto:aseelye-lists@eltopia.com>
>> <mailto:aseelye-lists@eltopia.com
>> <mailto:aseelye-lists@eltopia.com>>> wrote:
>>
>> Hello,
>>
>> I have the following config, and for dynamic IP customers,
>> it seems
>> to be good so far (only testing one user, want to get the kinks
>> worked out before fully implementing). However, we have a
>> problem
>> in that the subnet mask that's being negotiated seems to be a
>> /8
>> (Old Class A default). Also, if we specify the IP address in
>> Radius, the Cisco seems to ignore that in the Access-Reply, and
>> continue to assign the original address it'd intended from
>> its pool.
>> Any pointers would be greatly appreciated, as the "ppp
>> ipcp mask
>> 255.255.255.255" seems to have no effect on the netmask
>> negotiated,
>> and no amount of dial turning has yielded results on the
>> Radius-assigned IP issue.
>>
>> TIA,
>>
>> Aaron Seelye
>>
>>
>>
>> aaa new-model
>> aaa authentication login default line
>> aaa authentication ppp default group radius
>> aaa accounting network default start-stop group radius
>>
>> vpdn enable
>> !
>> vpdn-group number
>> accept-dialin
>> protocol pppoe
>> virtual-template 1
>> !
>> vc-class atm PPP7.1
>> protocol pppoe
>> ubr 7840
>> no ilmi manage
>> encapsulation aal5snap
>> !
>> interface ATM3/0.311 point-to-point
>> description POVN
>> pvc 3/11
>> class-vc PPP7.1
>> !
>> interface Virtual-Template1
>> ip unnumbered FastEthernet0/0
>> ip mtu 1492
>> peer default ip address pool pppoe146
>> ppp authentication pap chap
>> ppp ipcp mask 255.255.255.255
>> !
>> ip local pool pppoe146 192.168.146.1 192.168.146.254
>> !
>> radius-server host 192.168.131.3 auth-port 1645 acct-port 1646
>> radius-server attribute 8 include-in-access-req
>> radius-server attribute nas-port format d
>> radius-server key 7 03035D13555B7248
>>
>>
>> _______________________________________________
>> cisco-nas mailing list
>> cisco-nas@puck.nether.net <mailto:cisco-nas@puck.nether.net>
>> <mailto:cisco-nas@puck.nether.net
>> <mailto:cisco-nas@puck.nether.net>>
>>
>> https://puck.nether.net/mailman/listinfo/cisco-nas
>>
>>
>>
>>
>>
>>
>>
>>
>> No virus found in this incoming message.
>> Checked by AVG - www.avg.com <http://www.avg.com>
>>
>> Version: 9.0.730 / Virus Database: 271.1.1/2638 - Release Date:
>> 01/21/10 23:34:00
>>
>>
>>
>>
>>
>>
>> No virus found in this incoming message.
>> Checked by AVG - www.avg.com
>> Version: 9.0.730 / Virus Database: 271.1.1/2638 - Release Date: 01/21/10
>> 23:34:00
>>
>>

Ok, here it is, quite a bit there. You can see in the radius debug that
both IP and netmask are specified, but for some reason the netmask isn't
applied. I've tried setting the ppp ipcp mask to reject, request, hard
set, and off, nothing changes, same /8 mask.

-Aaron

17w0d: Vi1 PPP: Phase is AUTHENTICATING, by this end [0 sess, 1 load]
17w0d: Vi1 PAP: I AUTH-REQ id 1 len 21 from "pppoemarin"
17w0d: Vi1 PPP: Phase is FORWARDING [0 sess, 1 load]
17w0d: Vi1 PPP: Phase is AUTHENTICATING [0 sess, 1 load]
17w0d: Vi1 PAP: Authenticating peer pppoemarin
17w0d: Vi1: Pools to search : pppoe146
17w0d: Vi1: Pool pppoe146 returned address = 192.168.146.1
17w0d: RADIUS: ustruct sharecount=2
17w0d: Radius: radius_port_info() success=1 radius_nas_port=17
17w0d: RADIUS: Initial Transmit Virtual-Access1 id 79
192.168.131.3:1645, Access-Request, len 86
17w0d: Attribute 4 6 413D3CF4
17w0d: Attribute 5 6 3003000B
17w0d: Attribute 61 6 00000005
17w0d: Attribute 1 12 7070706F
17w0d: Attribute 2 18 45E60F83
17w0d: Attribute 6 6 00000002
17w0d: Attribute 7 6 00000001
17w0d: Attribute 8 6 45299201
17w0d: RADIUS: Received from id 79 192.168.131.3:1645, Access-Accept, len 69
17w0d: Attribute 6 6 00000002
17w0d: Attribute 7 6 00000001
17w0d: Attribute 8 6 45299264
17w0d: Attribute 9 6 FFFFFFFF
17w0d: Attribute 13 6 00000001
17w0d: Attribute 26 13 00003A8C0807334D
17w0d: Attribute 25 6 32383635
17w0d: RADIUS: saved authorization data for user 62B51648 at 62ADC438
17w0d: RADIUS: unrecognized Vendor code 14988
17w0d: Vi1 PAP: O AUTH-ACK id 1 len 5
17w0d: Vi1 PPP: Phase is UP [0 sess, 1 load]
17w0d: RADIUS: Authorize IP address 192.168.146.100
17w0d: RADIUS: unrecognized Vendor code 14988
17w0d: Vi1 IPCP: O CONFREQ [Closed] id 1 len 26
17w0d: Vi1 IPCP: CompressType VJ 15 slots (0x0206002D0F00)
17w0d: Vi1 IPCP: VSO Netmask 0.0.0.0 (0x000A00000C0100000000)
17w0d: Vi1 IPCP: Address 65.61.60.244 (0x0306413D3CF4)
17w0d: Vi1 IPCP: O CONFREQ [REQsent] id 2 len 26
17w0d: Vi1 IPCP: CompressType VJ 15 slots (0x0206002D0F00)
17w0d: Vi1 IPCP: VSO Netmask 0.0.0.0 (0x000A00000C0100000000)
17w0d: Vi1 IPCP: Address 65.61.60.244 (0x0306413D3CF4)
17w0d: Vi1 IPCP: I CONFREQ [REQsent] id 156 len 22
17w0d: Vi1 IPCP: Address 0.0.0.0 (0x030600000000)
17w0d: Vi1 IPCP: PrimaryDNS 0.0.0.0 (0x810600000000)
17w0d: Vi1 IPCP: SecondaryDNS 0.0.0.0 (0x830600000000)
17w0d: Vi1 AAA/AUTHOR/IPCP: Start. Her address 0.0.0.0, we want
192.168.146.1
17w0d: Vi1 set_ip_peer(4): new address
17w0d: ip_free_pool: Vi1: address = 192.168.146.1 (2)192.168.146.100
17w0d: Vi1 AAA/AUTHOR/IPCP: Done. Her address 0.0.0.0, we want
192.168.146.100
17w0d: Vi1 IPCP: O CONFNAK [REQsent] id 156 len 22
17w0d: Vi1 IPCP: Address 192.168.146.100 (0x030645299264)
17w0d: Vi1 IPCP: PrimaryDNS 192.168.131.3 (0x810645298303)
17w0d: Vi1 IPCP: SecondaryDNS 192.168.131.4 (0x830645298304)
17w0d: RADIUS: ustruct sharecount=3
17w0d: Radius: radius_port_info() success=1 radius_nas_port=17
17w0d: RADIUS: Sent class "2865" at 62ADC477 from user 62B51648
17w0d: RADIUS: Initial Transmit Virtual-Access1 id 80
192.168.131.3:1646, Accounting-Request, len 107
17w0d: Attribute 4 6 413D3CF4
17w0d: Attribute 5 6 3003000B
17w0d: Attribute 61 6 00000005
17w0d: Attribute 1 12 7070706F
17w0d: Attribute 40 6 00000001
17w0d: Attribute 25 6 32383635
17w0d: Attribute 45 6 00000001
17w0d: Attribute 6 6 00000002
17w0d: Attribute 44 21 3/0/0/3.11_00000017
17w0d: Attribute 7 6 00000001
17w0d: Attribute 41 6 00000000
17w0d: Vi1 IPCP: I CONFREJ [REQsent] id 1 len 20
17w0d: Vi1 IPCP: CompressType VJ 15 slots (0x0206002D0F00)
17w0d: Vi1 IPCP: VSO Netmask 0.0.0.0 (0x000A00000C0100000000)
17w0d: Vi1 IPCP: ID 1 didn't match 2, discarding packet
17w0d: Vi1 IPCP: I CONFREJ [REQsent] id 2 len 20
17w0d: Vi1 IPCP: CompressType VJ 15 slots (0x0206002D0F00)
17w0d: Vi1 IPCP: VSO Netmask 0.0.0.0 (0x000A00000C0100000000)
17w0d: Vi1 IPCP: O CONFREQ [REQsent] id 3 len 16
17w0d: Vi1 IPCP: SubnetMask 0.0.0.0 (0x900600000000)
17w0d: Vi1 IPCP: Address 65.61.60.244 (0x0306413D3CF4)
17w0d: Vi1 IPCP: I CONFREQ [REQsent] id 157 len 22
17w0d: Vi1 IPCP: Address 192.168.146.100 (0x030645299264)
17w0d: Vi1 IPCP: PrimaryDNS 192.168.131.3 (0x810645298303)
17w0d: Vi1 IPCP: SecondaryDNS 192.168.131.4 (0x830645298304)
17w0d: Vi1 AAA/AUTHOR/IPCP: Start. Her address 192.168.146.100, we want
192.168.146.100
17w0d: Vi1 set_ip_peer(4): new address 192.168.146.100
17w0d: Vi1 AAA/AUTHOR/IPCP: Done. Her address 192.168.146.100, we want
192.168.146.100
17w0d: Vi1 IPCP: O CONFACK [REQsent] id 157 len 22
17w0d: Vi1 IPCP: Address 192.168.146.100 (0x030645299264)
17w0d: Vi1 IPCP: PrimaryDNS 192.168.131.3 (0x810645298303)
17w0d: Vi1 IPCP: SecondaryDNS 192.168.131.4 (0x830645298304)
17w0d: Vi1 IPCP: I CONFREJ [ACKsent] id 3 len 10
17w0d: Vi1 IPCP: SubnetMask 0.0.0.0 (0x900600000000)
17w0d: Vi1 IPCP: O CONFREQ [ACKsent] id 4 len 10
17w0d: Vi1 IPCP: Address 65.61.60.244 (0x0306413D3CF4)
17w0d: Vi1 IPCP: I CONFACK [ACKsent] id 4 len 10
17w0d: Vi1 IPCP: Address 65.61.60.244 (0x0306413D3CF4)
17w0d: Vi1 IPCP: State is Open
17w0d: RADIUS: Received from id 80 192.168.131.3:1646,
Accounting-response, len 20
17w0d: Vi1 IPCP: Install route to 192.168.146.100
17w0d: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1,
changed state to up


On 1/22/2010 4:03 PM, Josh Duffek | Tredent wrote:
> I guess you don't need the aaa authen debugs, and only really care about
> the tail end of debug ppp nego(ncp and beyond)....but add "debug
> radius". I think the more debugs the better :)
>
> jd.
>
>
> On Fri, Jan 22, 2010 at 5:58 PM, Aaron Seelye <aseelye-lists@eltopia.com
> <mailto:aseelye-lists@eltopia.com>> wrote:
>
> Just was going to write back, authorization fixed the IP address
> portion. Still working on the netmask problem though, it doesn't
> seem to be taking the value over radius like it does now for the IP
> itself. Regarding the debug, there's quite a bit there, should I
> look for/reply with something in particular?
>
> -Aaron
>
>
> On 1/22/2010 3:37 PM, Josh Duffek | Tredent wrote:
>
> Ahh gotcha...
>
> It's been awhile since I've looked at this, but...shouldn't aaa
> authorization local or radius be on? I would do this:
>
> confi t
> aaa authorization network default local
> end
> debug aaa authen
> debug aaa author
> debug ppp nego
> debug ip peer
>
> and grab "sh ver | i IOS"...(just to make it small)
>
> ...And send that in, if the aaa author command doesn't fix it.
> Aaron
> can probably answer this better then I can :)
>
> Thanks,
> Josh
>
>
> On Fri, Jan 22, 2010 at 4:57 PM, Aaron Seelye
> <aseelye-lists@eltopia.com <mailto:aseelye-lists@eltopia.com>
> <mailto:aseelye-lists@eltopia.com
> <mailto:aseelye-lists@eltopia.com>>> wrote:
>
> No, it's a westell dsl modem. It's giving us problems,
> presumably
> because all of my servers are on the same /8, but I can ping
> google/yahoo/whatever IPs that fall outside the /8.
>
> -Aaron
>
>
> On 1/22/2010 2:44 PM, Josh Duffek | Tredent wrote:
>
> Is it window clients connecting to this? If so read this:
> http://www.cisco.com/en/US/tech/tk713/tk507/technologies_tech_note09186a0080093c77.shtml
>
> The subnet mask shouldn't be an issue really...can you
> not route
> traffic
> over the link after it comes up?
>
> jd.
>
>
> On Fri, Jan 22, 2010 at 4:26 PM, Aaron Seelye
> <aseelye-lists@eltopia.com <mailto:aseelye-lists@eltopia.com>
> <mailto:aseelye-lists@eltopia.com
> <mailto:aseelye-lists@eltopia.com>>
> <mailto:aseelye-lists@eltopia.com <mailto:aseelye-lists@eltopia.com>
> <mailto:aseelye-lists@eltopia.com
> <mailto:aseelye-lists@eltopia.com>>>> wrote:
>
> Hello,
>
> I have the following config, and for dynamic IP
> customers,
> it seems
> to be good so far (only testing one user, want to
> get the kinks
> worked out before fully implementing). However, we
> have a
> problem
> in that the subnet mask that's being negotiated
> seems to be a /8
> (Old Class A default). Also, if we specify the IP
> address in
> Radius, the Cisco seems to ignore that in the
> Access-Reply, and
> continue to assign the original address it'd
> intended from
> its pool.
> Any pointers would be greatly appreciated, as the "ppp
> ipcp mask
> 255.255.255.255" seems to have no effect on the netmask
> negotiated,
> and no amount of dial turning has yielded results on the
> Radius-assigned IP issue.
>
> TIA,
>
> Aaron Seelye
>
>
>
> aaa new-model
> aaa authentication login default line
> aaa authentication ppp default group radius
> aaa accounting network default start-stop group radius
>
> vpdn enable
> !
> vpdn-group number
> accept-dialin
> protocol pppoe
> virtual-template 1
> !
> vc-class atm PPP7.1
> protocol pppoe
> ubr 7840
> no ilmi manage
> encapsulation aal5snap
> !
> interface ATM3/0.311 point-to-point
> description POVN
> pvc 3/11
> class-vc PPP7.1
> !
> interface Virtual-Template1
> ip unnumbered FastEthernet0/0
> ip mtu 1492
> peer default ip address pool pppoe146
> ppp authentication pap chap
> ppp ipcp mask 255.255.255.255
> !
> ip local pool pppoe146 192.168.146.1 192.168.146.254
> !
> radius-server host 192.168.131.3 auth-port 1645
> acct-port 1646
> radius-server attribute 8 include-in-access-req
> radius-server attribute nas-port format d
> radius-server key 7 03035D13555B7248
>
>
> _______________________________________________
> cisco-nas mailing list
> cisco-nas@puck.nether.net <mailto:cisco-nas@puck.nether.net>
> <mailto:cisco-nas@puck.nether.net
> <mailto:cisco-nas@puck.nether.net>>
> <mailto:cisco-nas@puck.nether.net <mailto:cisco-nas@puck.nether.net>
> <mailto:cisco-nas@puck.nether.net
> <mailto:cisco-nas@puck.nether.net>>>
>
> https://puck.nether.net/mailman/listinfo/cisco-nas
>
>
>
>
>
>
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com <http://www.avg.com>
> <http://www.avg.com>
>
> Version: 9.0.730 / Virus Database: 271.1.1/2638 -
> Release Date:
> 01/21/10 23:34:00
>
>
>
>
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com <http://www.avg.com>
> Version: 9.0.730 / Virus Database: 271.1.1/2638 - Release Date:
> 01/21/10 23:34:00
>
>
>
>
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 9.0.730 / Virus Database: 271.1.1/2638 - Release Date: 01/21/10 23:34:00
>
_______________________________________________
cisco-nas mailing list
cisco-nas@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nas

Check this out:

17w0d: Vi1 IPCP: I CONFREJ [REQsent] id 1 len 20
17w0d: Vi1 IPCP: CompressType VJ 15 slots (0x0206002D0F00)
17w0d: Vi1 IPCP: VSO Netmask 0.0.0.0 (0x000A00000C0100000000)
17w0d: Vi1 IPCP: ID 1 didn't match 2, discarding packet

So the peer, the westell modem, is rejecting our subnet mask
CONF(iguration)REQ(uest). "We" tried...but it isn't having it.

For all I know there is some "force peer mask" knob thingie in IOS these
days, maybe to where if the peer doesn't agree we don't allow them to
connect....just a thought....but I'm not sure if there is anything you can
do on your side to fix this.

Can you get into that westell? What version/model is it? Maybe we can
google up the manual and see if there is a setting in it that will allow it
to accept our mask negotiation...?

jd.


On Fri, Jan 22, 2010 at 6:11 PM, Aaron Seelye <aseelye-lists@eltopia.com>wrote:

> Ok, here it is, quite a bit there. You can see in the radius debug that
> both IP and netmask are specified, but for some reason the netmask isn't
> applied. I've tried setting the ppp ipcp mask to reject, request, hard set,
> and off, nothing changes, same /8 mask.
>
> -Aaron
>
> 17w0d: Vi1 PPP: Phase is AUTHENTICATING, by this end [0 sess, 1 load]
> 17w0d: Vi1 PAP: I AUTH-REQ id 1 len 21 from "pppoemarin"
> 17w0d: Vi1 PPP: Phase is FORWARDING [0 sess, 1 load]
> 17w0d: Vi1 PPP: Phase is AUTHENTICATING [0 sess, 1 load]
> 17w0d: Vi1 PAP: Authenticating peer pppoemarin
> 17w0d: Vi1: Pools to search : pppoe146
> 17w0d: Vi1: Pool pppoe146 returned address = 192.168.146.1
> 17w0d: RADIUS: ustruct sharecount=2
> 17w0d: Radius: radius_port_info() success=1 radius_nas_port=17
> 17w0d: RADIUS: Initial Transmit Virtual-Access1 id 79 192.168.131.3:1645,
> Access-Request, len 86
> 17w0d: Attribute 4 6 413D3CF4
> 17w0d: Attribute 5 6 3003000B
> 17w0d: Attribute 61 6 00000005
> 17w0d: Attribute 1 12 7070706F
> 17w0d: Attribute 2 18 45E60F83
> 17w0d: Attribute 6 6 00000002
> 17w0d: Attribute 7 6 00000001
> 17w0d: Attribute 8 6 45299201
> 17w0d: RADIUS: Received from id 79 192.168.131.3:1645, Access-Accept, len
> 69
> 17w0d: Attribute 6 6 00000002
> 17w0d: Attribute 7 6 00000001
> 17w0d: Attribute 8 6 45299264
> 17w0d: Attribute 9 6 FFFFFFFF
> 17w0d: Attribute 13 6 00000001
> 17w0d: Attribute 26 13 00003A8C0807334D
> 17w0d: Attribute 25 6 32383635
> 17w0d: RADIUS: saved authorization data for user 62B51648 at 62ADC438
> 17w0d: RADIUS: unrecognized Vendor code 14988
> 17w0d: Vi1 PAP: O AUTH-ACK id 1 len 5
> 17w0d: Vi1 PPP: Phase is UP [0 sess, 1 load]
> 17w0d: RADIUS: Authorize IP address 192.168.146.100
> 17w0d: RADIUS: unrecognized Vendor code 14988
> 17w0d: Vi1 IPCP: O CONFREQ [Closed] id 1 len 26
> 17w0d: Vi1 IPCP: CompressType VJ 15 slots (0x0206002D0F00)
> 17w0d: Vi1 IPCP: VSO Netmask 0.0.0.0 (0x000A00000C0100000000)
> 17w0d: Vi1 IPCP: Address 65.61.60.244 (0x0306413D3CF4)
> 17w0d: Vi1 IPCP: O CONFREQ [REQsent] id 2 len 26
> 17w0d: Vi1 IPCP: CompressType VJ 15 slots (0x0206002D0F00)
> 17w0d: Vi1 IPCP: VSO Netmask 0.0.0.0 (0x000A00000C0100000000)
> 17w0d: Vi1 IPCP: Address 65.61.60.244 (0x0306413D3CF4)
> 17w0d: Vi1 IPCP: I CONFREQ [REQsent] id 156 len 22
> 17w0d: Vi1 IPCP: Address 0.0.0.0 (0x030600000000)
> 17w0d: Vi1 IPCP: PrimaryDNS 0.0.0.0 (0x810600000000)
> 17w0d: Vi1 IPCP: SecondaryDNS 0.0.0.0 (0x830600000000)
> 17w0d: Vi1 AAA/AUTHOR/IPCP: Start. Her address 0.0.0.0, we want
> 192.168.146.1
> 17w0d: Vi1 set_ip_peer(4): new address
> 17w0d: ip_free_pool: Vi1: address = 192.168.146.1 (2)192.168.146.100
> 17w0d: Vi1 AAA/AUTHOR/IPCP: Done. Her address 0.0.0.0, we want
> 192.168.146.100
> 17w0d: Vi1 IPCP: O CONFNAK [REQsent] id 156 len 22
> 17w0d: Vi1 IPCP: Address 192.168.146.100 (0x030645299264)
> 17w0d: Vi1 IPCP: PrimaryDNS 192.168.131.3 (0x810645298303)
> 17w0d: Vi1 IPCP: SecondaryDNS 192.168.131.4 (0x830645298304)
> 17w0d: RADIUS: ustruct sharecount=3
> 17w0d: Radius: radius_port_info() success=1 radius_nas_port=17
> 17w0d: RADIUS: Sent class "2865" at 62ADC477 from user 62B51648
> 17w0d: RADIUS: Initial Transmit Virtual-Access1 id 80 192.168.131.3:1646,
> Accounting-Request, len 107
> 17w0d: Attribute 4 6 413D3CF4
> 17w0d: Attribute 5 6 3003000B
> 17w0d: Attribute 61 6 00000005
> 17w0d: Attribute 1 12 7070706F
> 17w0d: Attribute 40 6 00000001
> 17w0d: Attribute 25 6 32383635
> 17w0d: Attribute 45 6 00000001
> 17w0d: Attribute 6 6 00000002
> 17w0d: Attribute 44 21 3/0/0/3.11_00000017
> 17w0d: Attribute 7 6 00000001
> 17w0d: Attribute 41 6 00000000
> 17w0d: Vi1 IPCP: I CONFREJ [REQsent] id 1 len 20
> 17w0d: Vi1 IPCP: CompressType VJ 15 slots (0x0206002D0F00)
> 17w0d: Vi1 IPCP: VSO Netmask 0.0.0.0 (0x000A00000C0100000000)
> 17w0d: Vi1 IPCP: ID 1 didn't match 2, discarding packet
> 17w0d: Vi1 IPCP: I CONFREJ [REQsent] id 2 len 20
> 17w0d: Vi1 IPCP: CompressType VJ 15 slots (0x0206002D0F00)
> 17w0d: Vi1 IPCP: VSO Netmask 0.0.0.0 (0x000A00000C0100000000)
> 17w0d: Vi1 IPCP: O CONFREQ [REQsent] id 3 len 16
> 17w0d: Vi1 IPCP: SubnetMask 0.0.0.0 (0x900600000000)
> 17w0d: Vi1 IPCP: Address 65.61.60.244 (0x0306413D3CF4)
> 17w0d: Vi1 IPCP: I CONFREQ [REQsent] id 157 len 22
> 17w0d: Vi1 IPCP: Address 192.168.146.100 (0x030645299264)
> 17w0d: Vi1 IPCP: PrimaryDNS 192.168.131.3 (0x810645298303)
> 17w0d: Vi1 IPCP: SecondaryDNS 192.168.131.4 (0x830645298304)
> 17w0d: Vi1 AAA/AUTHOR/IPCP: Start. Her address 192.168.146.100, we want
> 192.168.146.100
> 17w0d: Vi1 set_ip_peer(4): new address 192.168.146.100
> 17w0d: Vi1 AAA/AUTHOR/IPCP: Done. Her address 192.168.146.100, we want
> 192.168.146.100
> 17w0d: Vi1 IPCP: O CONFACK [REQsent] id 157 len 22
> 17w0d: Vi1 IPCP: Address 192.168.146.100 (0x030645299264)
> 17w0d: Vi1 IPCP: PrimaryDNS 192.168.131.3 (0x810645298303)
> 17w0d: Vi1 IPCP: SecondaryDNS 192.168.131.4 (0x830645298304)
> 17w0d: Vi1 IPCP: I CONFREJ [ACKsent] id 3 len 10
> 17w0d: Vi1 IPCP: SubnetMask 0.0.0.0 (0x900600000000)
> 17w0d: Vi1 IPCP: O CONFREQ [ACKsent] id 4 len 10
> 17w0d: Vi1 IPCP: Address 65.61.60.244 (0x0306413D3CF4)
> 17w0d: Vi1 IPCP: I CONFACK [ACKsent] id 4 len 10
> 17w0d: Vi1 IPCP: Address 65.61.60.244 (0x0306413D3CF4)
> 17w0d: Vi1 IPCP: State is Open
> 17w0d: RADIUS: Received from id 80 192.168.131.3:1646,
> Accounting-response, len 20
> 17w0d: Vi1 IPCP: Install route to 192.168.146.100
> 17w0d: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1,
> changed state to up
>
>
>
> On 1/22/2010 4:03 PM, Josh Duffek | Tredent wrote:
>
>> I guess you don't need the aaa authen debugs, and only really care about
>> the tail end of debug ppp nego(ncp and beyond)....but add "debug
>> radius". I think the more debugs the better :)
>>
>> jd.
>>
>>
>> On Fri, Jan 22, 2010 at 5:58 PM, Aaron Seelye <aseelye-lists@eltopia.com
>> <mailto:aseelye-lists@eltopia.com>> wrote:
>>
>> Just was going to write back, authorization fixed the IP address
>> portion. Still working on the netmask problem though, it doesn't
>> seem to be taking the value over radius like it does now for the IP
>> itself. Regarding the debug, there's quite a bit there, should I
>> look for/reply with something in particular?
>>
>> -Aaron
>>
>>
>> On 1/22/2010 3:37 PM, Josh Duffek | Tredent wrote:
>>
>> Ahh gotcha...
>>
>> It's been awhile since I've looked at this, but...shouldn't aaa
>> authorization local or radius be on? I would do this:
>>
>> confi t
>> aaa authorization network default local
>> end
>> debug aaa authen
>> debug aaa author
>> debug ppp nego
>> debug ip peer
>>
>> and grab "sh ver | i IOS"...(just to make it small)
>>
>> ...And send that in, if the aaa author command doesn't fix it.
>> Aaron
>> can probably answer this better then I can :)
>>
>> Thanks,
>> Josh
>>
>>
>> On Fri, Jan 22, 2010 at 4:57 PM, Aaron Seelye
>> <aseelye-lists@eltopia.com <mailto:aseelye-lists@eltopia.com>
>> <mailto:aseelye-lists@eltopia.com
>> <mailto:aseelye-lists@eltopia.com>>> wrote:
>>
>> No, it's a westell dsl modem. It's giving us problems,
>> presumably
>> because all of my servers are on the same /8, but I can ping
>> google/yahoo/whatever IPs that fall outside the /8.
>>
>> -Aaron
>>
>>
>> On 1/22/2010 2:44 PM, Josh Duffek | Tredent wrote:
>>
>> Is it window clients connecting to this? If so read this:
>>
>> http://www.cisco.com/en/US/tech/tk713/tk507/technologies_tech_note09186a0080093c77.shtml
>>
>> The subnet mask shouldn't be an issue really...can you
>> not route
>> traffic
>> over the link after it comes up?
>>
>> jd.
>>
>>
>> On Fri, Jan 22, 2010 at 4:26 PM, Aaron Seelye
>> <aseelye-lists@eltopia.com <mailto:aseelye-lists@eltopia.com>
>> <mailto:aseelye-lists@eltopia.com
>> <mailto:aseelye-lists@eltopia.com>>
>> <mailto:aseelye-lists@eltopia.com <mailto:
>> aseelye-lists@eltopia.com>
>> <mailto:aseelye-lists@eltopia.com
>> <mailto:aseelye-lists@eltopia.com>>>> wrote:
>>
>> Hello,
>>
>> I have the following config, and for dynamic IP
>> customers,
>> it seems
>> to be good so far (only testing one user, want to
>> get the kinks
>> worked out before fully implementing). However, we
>> have a
>> problem
>> in that the subnet mask that's being negotiated
>> seems to be a /8
>> (Old Class A default). Also, if we specify the IP
>> address in
>> Radius, the Cisco seems to ignore that in the
>> Access-Reply, and
>> continue to assign the original address it'd
>> intended from
>> its pool.
>> Any pointers would be greatly appreciated, as the
>> "ppp
>> ipcp mask
>> 255.255.255.255" seems to have no effect on the netmask
>> negotiated,
>> and no amount of dial turning has yielded results on
>> the
>> Radius-assigned IP issue.
>>
>> TIA,
>>
>> Aaron Seelye
>>
>>
>>
>> aaa new-model
>> aaa authentication login default line
>> aaa authentication ppp default group radius
>> aaa accounting network default start-stop group radius
>>
>> vpdn enable
>> !
>> vpdn-group number
>> accept-dialin
>> protocol pppoe
>> virtual-template 1
>> !
>> vc-class atm PPP7.1
>> protocol pppoe
>> ubr 7840
>> no ilmi manage
>> encapsulation aal5snap
>> !
>> interface ATM3/0.311 point-to-point
>> description POVN
>> pvc 3/11
>> class-vc PPP7.1
>> !
>> interface Virtual-Template1
>> ip unnumbered FastEthernet0/0
>> ip mtu 1492
>> peer default ip address pool pppoe146
>> ppp authentication pap chap
>> ppp ipcp mask 255.255.255.255
>> !
>> ip local pool pppoe146 192.168.146.1 192.168.146.254
>> !
>> radius-server host 192.168.131.3 auth-port 1645
>> acct-port 1646
>> radius-server attribute 8 include-in-access-req
>> radius-server attribute nas-port format d
>> radius-server key 7 03035D13555B7248
>>
>>
>> _______________________________________________
>> cisco-nas mailing list
>> cisco-nas@puck.nether.net <mailto:cisco-nas@puck.nether.net>
>> <mailto:cisco-nas@puck.nether.net
>> <mailto:cisco-nas@puck.nether.net>>
>> <mailto:cisco-nas@puck.nether.net <mailto:
>> cisco-nas@puck.nether.net>
>> <mailto:cisco-nas@puck.nether.net
>> <mailto:cisco-nas@puck.nether.net>>>
>>
>> https://puck.nether.net/mailman/listinfo/cisco-nas
>>
>>
>>
>>
>>
>>
>>
>>
>> No virus found in this incoming message.
>> Checked by AVG - www.avg.com <http://www.avg.com>
>> <http://www.avg.com>
>>
>> Version: 9.0.730 / Virus Database: 271.1.1/2638 -
>> Release Date:
>> 01/21/10 23:34:00
>>
>>
>>
>>
>>
>>
>> No virus found in this incoming message.
>> Checked by AVG - www.avg.com <http://www.avg.com>
>> Version: 9.0.730 / Virus Database: 271.1.1/2638 - Release Date:
>> 01/21/10 23:34:00
>>
>>
>>
>>
>>
>>
>> No virus found in this incoming message.
>> Checked by AVG - www.avg.com
>> Version: 9.0.730 / Virus Database: 271.1.1/2638 - Release Date: 01/21/10
>> 23:34:00
>>
>>

Hi,

On Fri, Jan 22, 2010 at 04:11:38PM -0800, Aaron Seelye wrote:
> Ok, here it is, quite a bit there. You can see in the radius debug that
> both IP and netmask are specified, but for some reason the netmask isn't
> applied. I've tried setting the ppp ipcp mask to reject, request, hard
> set, and off, nothing changes, same /8 mask.

Basic PPP IPCP isn't negotiating a netmask at all. It's just "this is my
IP address, this is your address".

(And even if it did, it would not change anything - so what would the
remote end do with a /8 netmask? "sent the packet over the link in
question". Well. Which is exactly what is needed to get the packet
to you - "send the packet over the link"...)

Something weird is going on in this Westell device.

gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany gert@greenie.muc.de
fax: +49-89-35655025 gert@net.informatik.tu-muenchen.de

The netmask is not a standard part of IPCP, but a Cisco
extension, and afaik is used only by Cisco CPE. Which would
explain why the non-Cisco CPE is ignoring it.

This is documented here: http://www.cisco.com/en/US/docs/ios/12_1t/12_1t5/feature/guide/dtpppsub.html .

The idea of the netmask btw is for CPE that is serving
up a chunk of address space ... so the central router
tells the CPE what chunk of space it got, then the CPE
can serve that up as a DHCP pool. That's the idea.

Aaron

--------------------------------------------------------------------------

On 1/23/2010 10:51 AM, gert@greenie.muc.de (Gert Doering) wrote:
> Hi,
>
> On Fri, Jan 22, 2010 at 04:11:38PM -0800, Aaron Seelye wrote:
>> Ok, here it is, quite a bit there. You can see in the radius debug that
>> both IP and netmask are specified, but for some reason the netmask isn't
>> applied. I've tried setting the ppp ipcp mask to reject, request, hard
>> set, and off, nothing changes, same /8 mask.
>
> Basic PPP IPCP isn't negotiating a netmask at all. It's just "this is my
> IP address, this is your address".
>
> (And even if it did, it would not change anything - so what would the
> remote end do with a /8 netmask? "sent the packet over the link in
> question". Well. Which is exactly what is needed to get the packet
> to you - "send the packet over the link"...)
>
> Something weird is going on in this Westell device.
>
> gert
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> cisco-nas mailing list
> cisco-nas@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nas
_______________________________________________
cisco-nas mailing list
cisco-nas@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nas

Ok, after putting the DSL modem in bridge mode and putting a PC behind
it worked great. As a side note, at some point in the testing, the guy
on the other end of the DSL link had changed out the modem with an
Encore ENDSL-AR, which seems to be having the problem. Firmare upgrade
didn't work, but as we have it working just fine with a PC and the DSL
in bridge mode, I'd consider this case closed.

Much thanks to Josh and everyone else who responded with ideas!

-Aaron

On 1/22/2010 5:26 PM, Josh Duffek | Tredent wrote:
> Check this out:
>
> 17w0d: Vi1 IPCP: I CONFREJ [REQsent] id 1 len 20
> 17w0d: Vi1 IPCP: CompressType VJ 15 slots (0x0206002D0F00)
> 17w0d: Vi1 IPCP: VSO Netmask 0.0.0.0 (0x000A00000C0100000000)
> 17w0d: Vi1 IPCP: ID 1 didn't match 2, discarding packet
>
> So the peer, the westell modem, is rejecting our subnet mask
> CONF(iguration)REQ(uest). "We" tried...but it isn't having it.
>
> For all I know there is some "force peer mask" knob thingie in IOS these
> days, maybe to where if the peer doesn't agree we don't allow them to
> connect....just a thought....but I'm not sure if there is anything you
> can do on your side to fix this.
>
> Can you get into that westell? What version/model is it? Maybe we can
> google up the manual and see if there is a setting in it that will allow
> it to accept our mask negotiation...?
>
> jd.
>
>
> On Fri, Jan 22, 2010 at 6:11 PM, Aaron Seelye <aseelye-lists@eltopia.com
> <mailto:aseelye-lists@eltopia.com>> wrote:
>
> Ok, here it is, quite a bit there. You can see in the radius debug
> that both IP and netmask are specified, but for some reason the
> netmask isn't applied. I've tried setting the ppp ipcp mask to
> reject, request, hard set, and off, nothing changes, same /8 mask.
>
> -Aaron
>
> 17w0d: Vi1 PPP: Phase is AUTHENTICATING, by this end [0 sess, 1 load]
> 17w0d: Vi1 PAP: I AUTH-REQ id 1 len 21 from "pppoemarin"
> 17w0d: Vi1 PPP: Phase is FORWARDING [0 sess, 1 load]
> 17w0d: Vi1 PPP: Phase is AUTHENTICATING [0 sess, 1 load]
> 17w0d: Vi1 PAP: Authenticating peer pppoemarin
> 17w0d: Vi1: Pools to search : pppoe146
> 17w0d: Vi1: Pool pppoe146 returned address = 192.168.146.1
> 17w0d: RADIUS: ustruct sharecount=2
> 17w0d: Radius: radius_port_info() success=1 radius_nas_port=17
> 17w0d: RADIUS: Initial Transmit Virtual-Access1 id 79
> 192.168.131.3:1645 <http://192.168.131.3:1645>, Access-Request, len 86
> 17w0d: Attribute 4 6 413D3CF4
> 17w0d: Attribute 5 6 3003000B
> 17w0d: Attribute 61 6 00000005
> 17w0d: Attribute 1 12 7070706F
> 17w0d: Attribute 2 18 45E60F83
> 17w0d: Attribute 6 6 00000002
> 17w0d: Attribute 7 6 00000001
> 17w0d: Attribute 8 6 45299201
> 17w0d: RADIUS: Received from id 79 192.168.131.3:1645
> <http://192.168.131.3:1645>, Access-Accept, len 69
> 17w0d: Attribute 6 6 00000002
> 17w0d: Attribute 7 6 00000001
> 17w0d: Attribute 8 6 45299264
> 17w0d: Attribute 9 6 FFFFFFFF
> 17w0d: Attribute 13 6 00000001
> 17w0d: Attribute 26 13 00003A8C0807334D
> 17w0d: Attribute 25 6 32383635
> 17w0d: RADIUS: saved authorization data for user 62B51648 at 62ADC438
> 17w0d: RADIUS: unrecognized Vendor code 14988
> 17w0d: Vi1 PAP: O AUTH-ACK id 1 len 5
> 17w0d: Vi1 PPP: Phase is UP [0 sess, 1 load]
> 17w0d: RADIUS: Authorize IP address 192.168.146.100
> 17w0d: RADIUS: unrecognized Vendor code 14988
> 17w0d: Vi1 IPCP: O CONFREQ [Closed] id 1 len 26
> 17w0d: Vi1 IPCP: CompressType VJ 15 slots (0x0206002D0F00)
> 17w0d: Vi1 IPCP: VSO Netmask 0.0.0.0 (0x000A00000C0100000000)
> 17w0d: Vi1 IPCP: Address 65.61.60.244 (0x0306413D3CF4)
> 17w0d: Vi1 IPCP: O CONFREQ [REQsent] id 2 len 26
> 17w0d: Vi1 IPCP: CompressType VJ 15 slots (0x0206002D0F00)
> 17w0d: Vi1 IPCP: VSO Netmask 0.0.0.0 (0x000A00000C0100000000)
> 17w0d: Vi1 IPCP: Address 65.61.60.244 (0x0306413D3CF4)
> 17w0d: Vi1 IPCP: I CONFREQ [REQsent] id 156 len 22
> 17w0d: Vi1 IPCP: Address 0.0.0.0 (0x030600000000)
> 17w0d: Vi1 IPCP: PrimaryDNS 0.0.0.0 (0x810600000000)
> 17w0d: Vi1 IPCP: SecondaryDNS 0.0.0.0 (0x830600000000)
> 17w0d: Vi1 AAA/AUTHOR/IPCP: Start. Her address 0.0.0.0, we want
> 192.168.146.1
> 17w0d: Vi1 set_ip_peer(4): new address
> 17w0d: ip_free_pool: Vi1: address = 192.168.146.1 (2)192.168.146.100
> 17w0d: Vi1 AAA/AUTHOR/IPCP: Done. Her address 0.0.0.0, we want
> 192.168.146.100
> 17w0d: Vi1 IPCP: O CONFNAK [REQsent] id 156 len 22
> 17w0d: Vi1 IPCP: Address 192.168.146.100 (0x030645299264)
> 17w0d: Vi1 IPCP: PrimaryDNS 192.168.131.3 (0x810645298303)
> 17w0d: Vi1 IPCP: SecondaryDNS 192.168.131.4 (0x830645298304)
> 17w0d: RADIUS: ustruct sharecount=3
> 17w0d: Radius: radius_port_info() success=1 radius_nas_port=17
> 17w0d: RADIUS: Sent class "2865" at 62ADC477 from user 62B51648
> 17w0d: RADIUS: Initial Transmit Virtual-Access1 id 80
> 192.168.131.3:1646 <http://192.168.131.3:1646>, Accounting-Request,
> len 107
> 17w0d: Attribute 4 6 413D3CF4
> 17w0d: Attribute 5 6 3003000B
> 17w0d: Attribute 61 6 00000005
> 17w0d: Attribute 1 12 7070706F
> 17w0d: Attribute 40 6 00000001
> 17w0d: Attribute 25 6 32383635
> 17w0d: Attribute 45 6 00000001
> 17w0d: Attribute 6 6 00000002
> 17w0d: Attribute 44 21 3/0/0/3.11_00000017
> 17w0d: Attribute 7 6 00000001
> 17w0d: Attribute 41 6 00000000
> 17w0d: Vi1 IPCP: I CONFREJ [REQsent] id 1 len 20
> 17w0d: Vi1 IPCP: CompressType VJ 15 slots (0x0206002D0F00)
> 17w0d: Vi1 IPCP: VSO Netmask 0.0.0.0 (0x000A00000C0100000000)
> 17w0d: Vi1 IPCP: ID 1 didn't match 2, discarding packet
> 17w0d: Vi1 IPCP: I CONFREJ [REQsent] id 2 len 20
> 17w0d: Vi1 IPCP: CompressType VJ 15 slots (0x0206002D0F00)
> 17w0d: Vi1 IPCP: VSO Netmask 0.0.0.0 (0x000A00000C0100000000)
> 17w0d: Vi1 IPCP: O CONFREQ [REQsent] id 3 len 16
> 17w0d: Vi1 IPCP: SubnetMask 0.0.0.0 (0x900600000000)
> 17w0d: Vi1 IPCP: Address 65.61.60.244 (0x0306413D3CF4)
> 17w0d: Vi1 IPCP: I CONFREQ [REQsent] id 157 len 22
> 17w0d: Vi1 IPCP: Address 192.168.146.100 (0x030645299264)
> 17w0d: Vi1 IPCP: PrimaryDNS 192.168.131.3 (0x810645298303)
> 17w0d: Vi1 IPCP: SecondaryDNS 192.168.131.4 (0x830645298304)
> 17w0d: Vi1 AAA/AUTHOR/IPCP: Start. Her address 192.168.146.100, we
> want 192.168.146.100
> 17w0d: Vi1 set_ip_peer(4): new address 192.168.146.100
> 17w0d: Vi1 AAA/AUTHOR/IPCP: Done. Her address 192.168.146.100, we
> want 192.168.146.100
> 17w0d: Vi1 IPCP: O CONFACK [REQsent] id 157 len 22
> 17w0d: Vi1 IPCP: Address 192.168.146.100 (0x030645299264)
> 17w0d: Vi1 IPCP: PrimaryDNS 192.168.131.3 (0x810645298303)
> 17w0d: Vi1 IPCP: SecondaryDNS 192.168.131.4 (0x830645298304)
> 17w0d: Vi1 IPCP: I CONFREJ [ACKsent] id 3 len 10
> 17w0d: Vi1 IPCP: SubnetMask 0.0.0.0 (0x900600000000)
> 17w0d: Vi1 IPCP: O CONFREQ [ACKsent] id 4 len 10
> 17w0d: Vi1 IPCP: Address 65.61.60.244 (0x0306413D3CF4)
> 17w0d: Vi1 IPCP: I CONFACK [ACKsent] id 4 len 10
> 17w0d: Vi1 IPCP: Address 65.61.60.244 (0x0306413D3CF4)
> 17w0d: Vi1 IPCP: State is Open
> 17w0d: RADIUS: Received from id 80 192.168.131.3:1646
> <http://192.168.131.3:1646>, Accounting-response, len 20
> 17w0d: Vi1 IPCP: Install route to 192.168.146.100
> 17w0d: %LINEPROTO-5-UPDOWN: Line protocol on Interface
> Virtual-Access1, changed state to up
>
>
>
> On 1/22/2010 4:03 PM, Josh Duffek | Tredent wrote:
>
> I guess you don't need the aaa authen debugs, and only really
> care about
> the tail end of debug ppp nego(ncp and beyond)....but add "debug
> radius". I think the more debugs the better :)
>
> jd.
>
>
> On Fri, Jan 22, 2010 at 5:58 PM, Aaron Seelye
> <aseelye-lists@eltopia.com <mailto:aseelye-lists@eltopia.com>
> <mailto:aseelye-lists@eltopia.com
> <mailto:aseelye-lists@eltopia.com>>> wrote:
>
> Just was going to write back, authorization fixed the IP address
> portion. Still working on the netmask problem though, it
> doesn't
> seem to be taking the value over radius like it does now for
> the IP
> itself. Regarding the debug, there's quite a bit there, should I
> look for/reply with something in particular?
>
> -Aaron
>
>
> On 1/22/2010 3:37 PM, Josh Duffek | Tredent wrote:
>
> Ahh gotcha...
>
> It's been awhile since I've looked at this,
> but...shouldn't aaa
> authorization local or radius be on? I would do this:
>
> confi t
> aaa authorization network default local
> end
> debug aaa authen
> debug aaa author
> debug ppp nego
> debug ip peer
>
> and grab "sh ver | i IOS"...(just to make it small)
>
> ...And send that in, if the aaa author command doesn't
> fix it.
> Aaron
> can probably answer this better then I can :)
>
> Thanks,
> Josh
>
>
> On Fri, Jan 22, 2010 at 4:57 PM, Aaron Seelye
> <aseelye-lists@eltopia.com <mailto:aseelye-lists@eltopia.com>
> <mailto:aseelye-lists@eltopia.com
> <mailto:aseelye-lists@eltopia.com>>
> <mailto:aseelye-lists@eltopia.com <mailto:aseelye-lists@eltopia.com>
> <mailto:aseelye-lists@eltopia.com
> <mailto:aseelye-lists@eltopia.com>>>> wrote:
>
> No, it's a westell dsl modem. It's giving us problems,
> presumably
> because all of my servers are on the same /8, but I
> can ping
> google/yahoo/whatever IPs that fall outside the /8.
>
> -Aaron
>
>
> On 1/22/2010 2:44 PM, Josh Duffek | Tredent wrote:
>
> Is it window clients connecting to this? If so
> read this:
> http://www.cisco.com/en/US/tech/tk713/tk507/technologies_tech_note09186a0080093c77.shtml
>
> The subnet mask shouldn't be an issue
> really...can you
> not route
> traffic
> over the link after it comes up?
>
> jd.
>
>
> On Fri, Jan 22, 2010 at 4:26 PM, Aaron Seelye
> <aseelye-lists@eltopia.com <mailto:aseelye-lists@eltopia.com>
> <mailto:aseelye-lists@eltopia.com
> <mailto:aseelye-lists@eltopia.com>>
> <mailto:aseelye-lists@eltopia.com <mailto:aseelye-lists@eltopia.com>
> <mailto:aseelye-lists@eltopia.com
> <mailto:aseelye-lists@eltopia.com>>>
> <mailto:aseelye-lists@eltopia.com
> <mailto:aseelye-lists@eltopia.com>
> <mailto:aseelye-lists@eltopia.com
> <mailto:aseelye-lists@eltopia.com>>
> <mailto:aseelye-lists@eltopia.com <mailto:aseelye-lists@eltopia.com>
> <mailto:aseelye-lists@eltopia.com
> <mailto:aseelye-lists@eltopia.com>>>>> wrote:
>
> Hello,
>
> I have the following config, and for dynamic IP
> customers,
> it seems
> to be good so far (only testing one user,
> want to
> get the kinks
> worked out before fully implementing).
> However, we
> have a
> problem
> in that the subnet mask that's being negotiated
> seems to be a /8
> (Old Class A default). Also, if we specify
> the IP
> address in
> Radius, the Cisco seems to ignore that in the
> Access-Reply, and
> continue to assign the original address it'd
> intended from
> its pool.
> Any pointers would be greatly appreciated,
> as the "ppp
> ipcp mask
> 255.255.255.255" seems to have no effect on
> the netmask
> negotiated,
> and no amount of dial turning has yielded
> results on the
> Radius-assigned IP issue.
>
> TIA,
>
> Aaron Seelye
>
>
>
> aaa new-model
> aaa authentication login default line
> aaa authentication ppp default group radius
> aaa accounting network default start-stop
> group radius
>
> vpdn enable
> !
> vpdn-group number
> accept-dialin
> protocol pppoe
> virtual-template 1
> !
> vc-class atm PPP7.1
> protocol pppoe
> ubr 7840
> no ilmi manage
> encapsulation aal5snap
> !
> interface ATM3/0.311 point-to-point
> description POVN
> pvc 3/11
> class-vc PPP7.1
> !
> interface Virtual-Template1
> ip unnumbered FastEthernet0/0
> ip mtu 1492
> peer default ip address pool pppoe146
> ppp authentication pap chap
> ppp ipcp mask 255.255.255.255
> !
> ip local pool pppoe146 192.168.146.1
> 192.168.146.254
> !
> radius-server host 192.168.131.3 auth-port 1645
> acct-port 1646
> radius-server attribute 8 include-in-access-req
> radius-server attribute nas-port format d
> radius-server key 7 03035D13555B7248
>
>
> _______________________________________________
> cisco-nas mailing list
> cisco-nas@puck.nether.net <mailto:cisco-nas@puck.nether.net>
> <mailto:cisco-nas@puck.nether.net
> <mailto:cisco-nas@puck.nether.net>>
> <mailto:cisco-nas@puck.nether.net <mailto:cisco-nas@puck.nether.net>
> <mailto:cisco-nas@puck.nether.net
> <mailto:cisco-nas@puck.nether.net>>>
> <mailto:cisco-nas@puck.nether.net
> <mailto:cisco-nas@puck.nether.net>
> <mailto:cisco-nas@puck.nether.net
> <mailto:cisco-nas@puck.nether.net>>
> <mailto:cisco-nas@puck.nether.net <mailto:cisco-nas@puck.nether.net>
> <mailto:cisco-nas@puck.nether.net
> <mailto:cisco-nas@puck.nether.net>>>>
>
> https://puck.nether.net/mailman/listinfo/cisco-nas
>
>
>
>
>
>
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> <http://www.avg.com> <http://www.avg.com>
> <http://www.avg.com>
>
> Version: 9.0.730 / Virus Database: 271.1.1/2638 -
> Release Date:
> 01/21/10 23:34:00
>
>
>
>
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com <http://www.avg.com>
> <http://www.avg.com>
> Version: 9.0.730 / Virus Database: 271.1.1/2638 -
> Release Date:
> 01/21/10 23:34:00
>
>
>
>
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com <http://www.avg.com>
> Version: 9.0.730 / Virus Database: 271.1.1/2638 - Release Date:
> 01/21/10 23:34:00
>
>
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 9.0.730 / Virus Database: 271.1.1/2638 - Release Date: 01/21/10 23:34:00
>
_______________________________________________
cisco-nas mailing list
cisco-nas@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nas