[cisco-nas] PPPOE w/ Radius specified IP & subnet mask problems

Aaron Seelye aseelye-lists at eltopia.com
Mon Jan 25 15:16:49 EST 2010


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 at eltopia.com
> <mailto: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 <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 at eltopia.com <mailto:aseelye-lists at eltopia.com>
>         <mailto: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>>
>         <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:
>
>                     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>>>
>         <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
>         <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>>>
>         <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
>         <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>
>         <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
>


More information about the cisco-nas mailing list