[cisco-nas] PPPOE w/ Radius specified IP & subnet mask problems
Aaron Seelye
aseelye-lists at eltopia.com
Fri Jan 22 19:11:38 EST 2010
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
>
More information about the cisco-nas
mailing list