I've an architecture in which remote site flows (ex: 1701, 1721) are collected by a central LNS.
The LNS can renegociate the PPP session on mismatch and it's my case when doing Multilink (NAS are 3COM)
The soucy is when the re-negociation occurs. The LNS is configured to accept chap and pap (in this order).
My remote site is configured to negotiate only pap as the NAS is configured with it ("ppp authentication pap" on the dialer).
When the LNS renegociates the PPP session, it's first trying "CHAP", but the remote site isntead of sending a "CONFNACK -- Authentication CHAP" to make the LNS switches on PAP, it's sending a "CONFACK -- CHAP"....so the LNS sends a chap challenge and the remote site is blocked (as it's configured only for PAP) and no connexion occurs.
Having tested it on 1701 (3 IOS), 1721 and 3725, all these remote site "modem-router" have the same behavior. They send a "CONFACK" instead of "CONFNACK"
Having tested on other equipment (bintech), their behavior is OK, they send a CONFNACK, the LNS switches on PAP and the connexion is done.
Does anybody having an idea on the reason of these behavior ?
Basically, "ppp authentication" command determines what we insist the peer authenticate with us. So with "ppp authen pap" on dialer routers, it does not mean that we would not recognize chap coming into us from the other side at all. We sure will. So what you need in your situation is "ppp chap refuse" in addition to "ppp authen pap" on the dialer routers.
We are pleased to announce availability of Beta software for 16.6.3. 16.6.3 will be the second rebuild on the 16.6 release train targeted towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are looking for early feedback from custome...