[c-nsp] Problems with PPP Auth on Cisco 857 / 887V in DenverCenturyLink (Qwest.net) - ANYONE FROM QWEST.NET?

[Chad Burnham]

HI,

About two weeks ago we started seeing PPP auth issues on just a few of our Cisco 887V (VDSL2), and 857 (ADSL2+) locations in Denver, CO with CenturyLink (Qwest.net) as our ISP - we run Site to Site VPNs on this platform - for years.  IOS PPP debugs yield an ISP driven PPP authentication method move from PAP to CHAP during maintenance window(s).  Moving from PAP to CHAP on the dialer 0 interface fixed one site on the 887V platform.  Similar config has not fixed the 857.  36 hours later and a very deep dive with TAC has yielded no success.  Essentially we see failures on the PPP session with no real reason code other than the carrier has changed something (see below).  I have other ADSL2+ (fiber fed/PPPoE) sites in Denver continuing to working fine on PAP.

Is there anyone on this list from CenturlyLink/Qwest.net that may be able to assist TAC and I offline and help determine with what was changed on the backend so we can match in IOS on our Cisco's?  Since the Cisco's are "3rd party" - I am getting stonewalled on support.  I been told by our CenturyLink service manger that the Radius servers were moved from 1G to 10G connections very recently.  He is aware that others are having this exact problem and CenturyLink NOC is upset as no communications from the internal Auth group making the changes.
FYI, Using a ZyXEL5000PK unit will yield a PPP auth success on this current problem circuit.  Hard to debug/show the config on ZyZEL unit to see what is missing in IOS to match.

Thanks for any help on this one.  The prolonged outage is killing me....

Chad Burnham
University of Denver

Debug:

I was not able to find any recent issue regarding PPP negotiation with Juniper devices. Basically the problem seems to be authentication after all but on the Telco side.

Vi1 CHAP: I CHALLENGE id 210 len 33 from "JUNOS"

- We negotiated CHAP with the DSL Agg device during LCP, therefore we receive an incoming CHAP CHALLENGE packet from "JUNOS" device.

Vi1 CHAP: Using hostname from interface CHAP
Vi1 CHAP: Using password from interface CHAP
Vi1 CHAP: O RESPONSE id 210 len 47 from "odatuniversityof at qwest.net<mailto:odatuniversityof at qwest.net>"

- Router sends its credentials configured under Dialer interface via RESPONSE packet.

Vi1 CHAP: I FAILURE id 210 len 4

- DSL Agg device receives our credentials, checks their internal database (or redirects it to a RADIUS server), for some reason they do not "like" them hence it sends a FAILURE message.

Vi1 LCP: I TERMREQ [Open] id 212 len 4

- Due to the authentication problem DSL Agg device sends a TERMREQ (termination request) packet to drop the session.

Vi1 LCP: O TERMACK [Open] id 212 len 4

- CISCO router will ACK this via TERMACK message.

Basically credentials are not matching what ISP has configured on their side, this is case sensitive therefore an incorrect letter under the user/pass might cause this issue, password could be different now, or basically this user does not exist in the "JUNOS" device (or Radius server where JUNOS redirects all AAA information).

----

[cid:image001.jpg at 01CCFDC8.CA7D7D50]























.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20120309/093bdc96/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 13136 bytes
Desc: image001.jpg
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20120309/093bdc96/attachment-0001.jpg>