[cisco-nas] PPPOE w/ Radius specified IP & subnet mask problems
Josh Duffek | Tredent
joshd at tredent.com
Fri Jan 22 20:26:22 EST 2010
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 at 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 at eltopia.com
>> <mailto:aseelye-lists at 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 at eltopia.com <mailto:aseelye-lists at eltopia.com>
>> <mailto:aseelye-lists at eltopia.com
>> <mailto:aseelye-lists at 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 at eltopia.com <mailto:aseelye-lists at eltopia.com>
>> <mailto:aseelye-lists at eltopia.com
>> <mailto:aseelye-lists at eltopia.com>>
>> <mailto:aseelye-lists at eltopia.com <mailto:
>> aseelye-lists at eltopia.com>
>> <mailto:aseelye-lists at eltopia.com
>> <mailto:aseelye-lists at 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 at puck.nether.net <mailto:cisco-nas at puck.nether.net>
>> <mailto:cisco-nas at puck.nether.net
>> <mailto:cisco-nas at puck.nether.net>>
>> <mailto:cisco-nas at puck.nether.net <mailto:
>> cisco-nas at puck.nether.net>
>> <mailto:cisco-nas at puck.nether.net
>> <mailto:cisco-nas at 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
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-nas/attachments/20100122/1a7304eb/attachment-0001.html>
More information about the cisco-nas
mailing list