<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri","sans-serif";
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal>HI,<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>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.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><b>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</b>? Since the Cisco’s are “3<sup>rd</sup> 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.<o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal>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.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Thanks for any help on this one. The prolonged outage is killing me….<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Chad Burnham<o:p></o:p></p><p class=MsoNormal>University of Denver<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Debug:<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>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.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>Vi1 CHAP: I CHALLENGE id 210 len 33 from "JUNOS"<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>- We negotiated CHAP with the DSL Agg device during LCP, therefore we receive an incoming CHAP CHALLENGE packet from "JUNOS" device.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>Vi1 CHAP: Using hostname from interface CHAP<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>Vi1 CHAP: Using password from interface CHAP<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>Vi1 CHAP: O RESPONSE id 210 len 47 from "<a href="mailto:odatuniversityof@qwest.net">odatuniversityof@qwest.net</a>"<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>- Router sends its credentials configured under Dialer interface via RESPONSE packet.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>Vi1 <span style='color:#0070C0'>CHAP</span>: I FAILURE id 210 len 4<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>- 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.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>Vi1 <span style='color:#0070C0'>LCP</span>: I TERMREQ [Open] id 212 len 4<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>- Due to the authentication problem DSL Agg device sends a TERMREQ (termination request) packet to drop the session.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>Vi1 <span style='color:#0070C0'>LCP</span>: O TERMACK [Open] id 212 len 4<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>- CISCO router will ACK this via TERMACK message.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'><o:p> </o:p></span></p><p class=MsoNormal style='text-align:justify'><span style='font-size:10.0pt;font-family:"Courier New"'>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).<o:p></o:p></span></p><p class=MsoNormal style='text-align:justify'><span style='font-size:10.0pt;font-family:"Courier New"'><o:p> </o:p></span></p><p class=MsoNormal>----<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><a name="Chad_Burnham"><img border=0 width=250 height=150 id="_x0000_i1025" src="cid:image001.jpg@01CCFDC8.CA7D7D50"></a><o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p></div></body></html>
<BR>
.