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