From: Jason Cash (cash2001@swbell.net)
Date: Sun Jun 08 2003 - 00:01:52 GMT-3
I had not gotten a response to this, but I assume the correct answer is to
use the 'callin' option.
-----Original Message-----
From: Daniel Cisco Group Study [mailto:danielcgs@imc.net.au]
Sent: Friday, June 06, 2003 7:34 PM
To: Jason Cash; Brian Dennis
Cc: ccielab@groupstudy.com
Anyone had any luck on this one?
Daniel
I've looked into the config guides and reference guides (even 12.3), and I
can't find documentation for the "ppp auth chap callout | callback"
commands... The only one that is documented is the "callin" option (plus
some others)...
Can someone else locate doco on these commands?
Are these unsupported commands? And hence, we should avoid using them (at
least for the lab exam) ?
If so, I would say that the only answer to the question is by making use of
the "callin" option on R2.
Daniel
-----Original Message-----
From: Jason Cash [mailto:cash2001@swbell.net]
Sent: Saturday, 31 May 2003 00:16
To: 'Brian Dennis'
Cc: ccielab@groupstudy.com
Subject: RE: ISDN PPP authentication
To answer your first email. IPE section 22 - ISDN task reads:
Config ISDN between R2 and R5. PPP multilink and PPP Chap auth must be
enables. Config ISDN parameters on R2 to only accept calls requesting
callback. Bring up a second link when capacity inbound or outbound exceeds
50%. Config R2 to authenticate R5 only when R5 calls R2. Config ISDN on R5
to request callback from R2.
Here is the entire 'deb ppp auth' from R2 configured as:
interface BRI0
ip address 110.99.25.2 255.255.255.192
encapsulation ppp
ip ospf cost 9999
ip ospf demand-circuit
dialer callback-secure
dialer map ip 110.99.25.5 name r5 class cback broadcast 8358662
dialer load-threshold 128 either
dialer-group 1
isdn switch-type basic-ni
isdn spid1 0835866101
isdn spid2 0835866301
no peer neighbor-route
no cdp enable
ppp callback accept
ppp authentication chap callback
ppp multilink
================================================
r2#clear log
Clear logging buffer [confirm]
r2#deb ppp auth
PPP authentication debugging is on
r2#
2d14h: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up
2d14h: BR0:1 PPP: Treating connection as a callin
2d14h: BR0:1 CHAP: I CHALLENGE id 67 len 23 from "r5"
2d14h: BR0:1 CHAP: O RESPONSE id 67 len 23 from "r2"
2d14h: BR0:1 CHAP: I SUCCESS id 67 len 4
2d14h: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to 8358662 r5
2d14h: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down
2d14h: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up
2d14h: BR0:1 PPP: Treating connection as a callout
2d14h: BR0:1 CHAP: O CHALLENGE id 38 len 23 from "r2"
2d14h: BR0:1 CHAP: I CHALLENGE id 68 len 23 from "r5"
2d14h: BR0:1 CHAP: O RESPONSE id 68 len 23 from "r2"
2d14h: BR0:1 CHAP: I SUCCESS id 68 len 4
2d14h: BR0:1 CHAP: I RESPONSE id 38 len 23 from "r5"
2d14h: BR0:1 CHAP: O SUCCESS id 38 len 4
2d14h: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to up
2d14h: Vi1 PPP: Treating connection as a callout
2d14h: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1, changed state
to up
2d14h: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1,
changed state to up
-----Original Message-----
From: Brian Dennis [mailto:brian@labforge.com]
Sent: Thursday, May 29, 2003 7:39 PM
To: 'Jason Cash'; ccielab@groupstudy.com
Did R5 actually not request callback or was R2 not able to call R5 back.
Normally callback is based on the username and if there isn't
authentication then how is the callback server going to know who to
callback.
Send the whole output from "debug ppp neg" from R2 if you can.
Brian Dennis, CCIE #2210 (R&S/ISP-Dial/Security)
-----Original Message-----
From: Jason Cash [mailto:cash2001@swbell.net]
Sent: Thursday, May 29, 2003 5:31 PM
To: 'Brian Dennis'; ccielab@groupstudy.com
Subject: RE: ISDN PPP authentication
Good point, but then R5 did not request a callback:
R5
2d00h: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up
2d00h: BR0:1 PPP: Treating connection as a callout
2d00h: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to up
2d00h: Vi1 PPP: Treating connection as a callout
2d00h: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1, changed
state
to up
2d00h: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1,
changed state to up
2d00h: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to 8358661 r2
In looking at the solutions for this, which part is incorrect? Should
R5
not have the 'ppp auth chap' or is R2 configured wrong. In other words,
to
accomplish the task, how shiuld the two be configured?
By the way, this is IPE Section 22 - ISDN
-----Original Message-----
From: Brian Dennis [mailto:brian@labforge.com]
Sent: Thursday, May 29, 2003 6:07 PM
To: 'Jason Cash'; ccielab@groupstudy.com
You added the "ppp authentication chap" command which isn't a default.
The default is to be authenticated but not authenticate. If you don't
want to be authenticated then use the "ppp chap|pap refuse" command.
Try removing the "ppp authentication chap" command from R5 and see what
happens.
Brian Dennis, CCIE #2210 (R&S/ISP-Dial/Security)
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Jason Cash
Sent: Thursday, May 29, 2003 1:44 PM
To: 'Brian Dennis'; ccielab@groupstudy.com
Subject: RE: ISDN PPP authentication
Being that it isn't stated how R5 should be treated in regard to
authentication, I left it at it's default, which it to challenge
correct?
All that was instructed was for R2 to authenticate R5 ONLY when R5 calls
R2.
I would think that 'ppp authentication callin' would accomplish this.
How does the provided solution solve the task? Wouldn't 'ppp
authentication
callback' on R2 only have R2 authenticate R5 when R5 calls R2 on
callback?
Maybe I am confusing this but is there a document that will explain
this?
-----Original Message-----
From: Brian Dennis [mailto:brian@labforge.com]
Sent: Thursday, May 29, 2003 2:30 PM
To: 'Jason Cash'; ccielab@groupstudy.com
Jason,
Why do you have R5 authenticating R2? The task doesn't ask for R5 to
authenticate R2. Was that in another part of the practice lab?
Brian Dennis, CCIE #2210 (R&S/ISP-Dial/Security)
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Jason Cash
Sent: Thursday, May 29, 2003 10:44 AM
To: ccielab@groupstudy.com
Subject: ISDN PPP authentication
I am trying to complete a task that instructs:
Config R2 to authenticate R5 only when R5 calls R2.
The solution has R2 configured with:
R2
interface BRI0
ip address 110.99.25.2 255.255.255.192
encapsulation ppp
dialer callback-secure
ppp callback accept
ppp authentication chap callback
R5
interface BRI0
ip address 110.99.25.5 255.255.255.192
encapsulation ppp
ppp callback request
ppp authentication chap
In doing a debug PPP auth. Here is what I get: (Just for clarification,
an
"I" means incoming and "O" is outbound correct)
with 'ppp auth chap callback'
R2
%LINK-3-UPDOWN: Interface BRI0:1, changed state to up
BR0:1 PPP: Treating connection as a callin
BR0:1 CHAP: I CHALLENGE id 45 len 23 from "r5"
BR0:1 CHAP: O RESPONSE id 45 len 23 from "r2"
BR0:1 CHAP: I SUCCESS id 45 len 4
%ISDN-6-CONNECT: Interface BRI0:1 is now connected to 8358662 r5
%LINK-3-UPDOWN: Interface BRI0:1, changed state to down
%LINK-3-UPDOWN: Interface BRI0:1, changed state to up
BR0:1 PPP: Treating connection as a callout
BR0:1 CHAP: I CHALLENGE id 46 len 23 from "r5"
BR0:1 CHAP: O RESPONSE id 46 len 23 from "r2"
BR0:1 CHAP: I SUCCESS id 46 len 4
%LINK-3-UPDOWN: Interface Virtual-Access1, changed state to up
Vi1 PPP: Treating connection as a callout
%LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1, changed state to
up
%LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed
state to up
%ISDN-6-CONNECT: Interface BRI0:1 is now connected to 8358662 r5
R5
%LINK-3-UPDOWN: Interface BRI0:1, changed state to up
BR0:1 PPP: Treating connection as a callout
BR0:1 CHAP: O CHALLENGE id 45 len 23 from "r5"
BR0:1 CHAP: I RESPONSE id 45 len 23 from "r2"
BR0:1 CHAP: O SUCCESS id 45 len 4
%ISDN-6-CONNECT: Interface BRI0:1 is now connected to 8358661 r2
%LINK-3-UPDOWN: Interface BRI0:1, changed state to down
%LINK-3-UPDOWN: Interface BRI0:1, changed state to up
BR0:1 PPP: Treating connection as a callin
BR0:1 CHAP: O CHALLENGE id 46 len 23 from "r5"
BR0:1 CHAP: I RESPONSE id 46 len 23 from "r2"
BR0:1 CHAP: O SUCCESS id 46 len 4
%LINK-3-UPDOWN: Interface Virtual-Access1, changed state to up
Vi1 PPP: Treating connection as a callin
%LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1, changed state to
up
%LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed
state to up
%ISDN-6-CONNECT: Interface BRI0:1 is now connected to 8358661 r2
As you can see, with the 'callback' option on R2, R5 is challenging R2
which
responds. R2 then calls R5 back and is challenged by R5 AGAIN. (Do you
see
my confusion?) It appears that with the 'callback' on R2, R2 is not
doing
any challenging, which would make sense as it is waiting for a callback
from
R5 to challenge. This will never happen as R2 is the callback server.
-------------------------------------------------
with 'ppp auth chap callin'
Here is router 2:
BR0:1 PPP: Treating connection as a callin
BR0:1 CHAP: O CHALLENGE id 27 len 23 from "r2"
BR0:1 CHAP: I CHALLENGE id 43 len 23 from "r5"
BR0:1 CHAP: Waiting for peer to authenticate first
BR0:1 CHAP: I RESPONSE id 27 len 23 from "r5"
BR0:1 CHAP: O SUCCESS id 27 len 4
BR0:1 CHAP: Processing saved Challenge, id 43
BR0:1 CHAP: O RESPONSE id 43 len 23 from "r2"
BR0:1 CHAP: I SUCCESS id 43 len 4
%ISDN-6-CONNECT: Interface BRI0:1 is now connected to 8358662 r5
%LINK-3-UPDOWN: Interface BRI0:1, changed state to down
%LINK-3-UPDOWN: Interface BRI0:1, changed state to up
BR0:1 PPP: Treating connection as a callout
BR0:1 CHAP: I CHALLENGE id 44 len 23 from "r5"
BR0:1 CHAP: O RESPONSE id 44 len 23 from "r2"
BR0:1 CHAP: I SUCCESS id 44 len 4
%LINK-3-UPDOWN: Interface Virtual-Access1, changed state to up
Vi1 PPP: Treating connection as a callout
%LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1, changed state to
up
%LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed
state to up
%ISDN-6-CONNECT: Interface BRI0:1 is now connected to 8358662 r5
Here is R5
%LINK-3-UPDOWN: Interface BRI0:1, changed state to up
BR0:1 PPP: Treating connection as a callout
BR0:1 CHAP: O CHALLENGE id 43 len 23 from "r5"
BR0:1 CHAP: I CHALLENGE id 27 len 23 from "r2"
BR0:1 CHAP: O RESPONSE id 27 len 23 from "r5"
BR0:1 CHAP: I SUCCESS id 27 len 4
BR0:1 CHAP: I RESPONSE id 43 len 23 from "r2"
BR0:1 CHAP: O SUCCESS id 43 len 4
%ISDN-6-CONNECT: Interface BRI0:1 is now connected to 8358661 r2
%LINK-3-UPDOWN: Interface BRI0:1, changed state to down
%LINK-3-UPDOWN: Interface BRI0:1, changed state to up
BR0:1 PPP: Treating connection as a callin
BR0:1 CHAP: O CHALLENGE id 44 len 23 from "r5"
BR0:1 CHAP: I RESPONSE id 44 len 23 from "r2"
BR0:1 CHAP: O SUCCESS id 44 len 4
%LINK-3-UPDOWN: Interface Virtual-Access1, changed state to up
Vi1 PPP: Treating connection as a callin
%LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1, changed state to
up
%LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed
state to up
%ISDN-6-CONNECT: Interface BRI0:1 is now connected to 8358661 r2
With the 'callin' option, R2 immediately challenges R5 (which is what is
instructed) then calls back and gets challenged by R5.
Am I interpretting this correctly?
**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.
This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.
www.mimesweeper.com
**********************************************************************
**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.
This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.
www.mimesweeper.com
**********************************************************************
This archive was generated by hypermail 2.1.4 : Fri Jul 04 2003 - 11:10:54 GMT-3