From: Carlos G Mendioroz (tron@huapi.ba.ar)
Date: Fri Aug 13 2004 - 10:39:32 GMT-3
Yes, that was it!
R5 is using the calling number to "know" who is calling.
Once I set R4 to send calling number, everything started to work.
Amazing ... the number of things happening behind scenes that we don't
know.
Carlos G Mendioroz wrote:
> Brian,
> I don't have access to the POD now, but I have an idea of what could
> make the difference: your ISDN setup is sending caller-id, and I guess
> R5 is using that to make the mapping. My ISDN switch is not (unless you
> program the caller to send it). I'll try this and I'll let you know.
>
>
> Brian Dennis wrote:
>
>> Carlos,
>> I haven't followed this whole thread so forgive me for jumping
>> in the middle but I lab'ed this up and it works without any problems.
>> See below:
>>
>> R4:
>> username ROUTER5 password 0 CISCO
>> !
>> interface BRI0/0
>> ip address 132.1.45.4 255.255.255.0
>> encapsulation ppp
>> dialer map ip 132.1.45.5 name ROUTER5 class CALLBACK broadcast 5272035
>> isdn switch-type basic-ni
>> isdn spid1 5272034
>> ppp callback accept
>> ppp authentication chap
>> ppp chap hostname ROUTER4
>> !
>> map-class dialer CALLBACK
>> dialer callback-server username
>>
>> R5:
>> username ROUTER4 password 0 CISCO
>> !
>> interface BRI0/0
>> ip address 132.1.45.5 255.255.255.0
>> encapsulation ppp
>> dialer map ip 132.1.45.4 name ROUTER4 broadcast 5272034
>> dialer-group 1
>> isdn switch-type basic-ni
>> isdn spid1 5272035
>> ppp callback request
>> ppp chap hostname ROUTER5
>> !
>> dialer-list 1 protocol ip permit
>> Verification:
>>
>> Rack3R5#show debug
>> PPP:
>> PPP protocol negotiation debugging is on
>>
>> Rack3R5#ping 132.1.45.4 repeat 2
>>
>> Type escape sequence to abort.
>> Sending 2, 100-byte ICMP Echos to 132.1.45.4, timeout is 2 seconds:
>> ..
>> Success rate is 0 percent (0/2)
>> Rack3R5#
>> %LINK-3-UPDOWN: Interface BRI0/0:1, changed state to up
>> BR0/0:1 PPP: Using dialer call direction
>> BR0/0:1 PPP: Treating connection as a callout
>> BR0/0:1 PPP: Phase is ESTABLISHING, Active Open
>> BR0/0:1 PPP: No remote authentication for call-out
>> BR0/0:1 LCP: O CONFREQ [Closed] id 3 len 13
>> BR0/0:1 LCP: MagicNumber 0x108CEAC2 (0x0506108CEAC2)
>> BR0/0:1 LCP: Callback 0 (0x0D0300)
>> BR0/0:1 LCP: I CONFREQ [REQsent] id 3 len 15
>> BR0/0:1 LCP: AuthProto CHAP (0x0305C22305)
>> BR0/0:1 LCP: MagicNumber 0x03C2B18B (0x050603C2B18B)
>> BR0/0:1 LCP: O CONFACK [REQsent] id 3 len 15
>> BR0/0:1 LCP: AuthProto CHAP (0x0305C22305)
>> BR0/0:1 LCP: MagicNumber 0x03C2B18B (0x050603C2B18B)
>> BR0/0:1 LCP: I CONFACK [ACKsent] id 3 len 13t
>> BR0/0:1 LCP: MagicNumber 0x108CEAC2 (0x0506108CEAC2)
>> BR0/0:1 LCP: Callback 0 (0x0D0300)
>> BR0/0:1 LCP: State is Open
>> BR0/0:1 PPP: Phase is AUTHENTICATING, by the peer
>> BR0/0:1 CHAP: I CHALLENGE id 3 len 28 from "ROUTER4"
>> BR0/0:1 CHAP: Using hostname from interface CHAP
>> BR0/0:1 CHAP: Using password from AAA
>> BR0/0:1 CHAP: O RESPONSE id 3 len 28 from "ROUTER5"
>> BR0/0:1 CHAP: I SUCCESS id 3 len 4
>> BR0/0:1 PPP: Phase is FORWARDING, Attempting Forward
>> BR0/0:1 PPP: Phase is ESTABLISHING, Finish LCP
>> %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0/0:1, changed state
>> to up
>> %ISDN-6-CONNECT: Interface BRI0/0:1 is now connected to 5272034
>> %ISDN-6-DISCONNECT: Interface BRI0/0:1 disconnected from 5272034 , call
>> lasted 1 seconds
>> %LINK-3-UPDOWN: Interface BRI0/0:1, changed state to down
>> BR0/0:1 PPP: Sending Acct Event[Down] id[4]
>> BR0/0:1 PPP: Phase is TERMINATING
>> BR0/0:1 LCP: State is Closed
>> BR0/0:1 PPP: Phase is DOWN
>> %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0/0:1, changed state
>> to down
>> %LINK-3-UPDOWN: Interface BRI0/0:1, changed state to up
>> BR0/0:1 PPP: Using dialer call direction
>> BR0/0:1 PPP: Treating connection as a callin
>> BR0/0:1 PPP: Phase is ESTABLISHING, Passive Open
>> BR0/0:1 LCP: State is Listen
>> BR0/0:1 LCP: I CONFREQ [Listen] id 4 len 15
>> BR0/0:1 LCP: AuthProto CHAP (0x0305C22305)
>> BR0/0:1 LCP: MagicNumber 0x03C2FF70 (0x050603C2FF70)
>> BR0/0:1 PPP: No remote authentication for call-in
>> BR0/0:1 LCP: O CONFREQ [Listen] id 4 len 10
>> BR0/0:1 LCP: MagicNumber 0x108D38B7 (0x0506108D38B7)
>> BR0/0:1 LCP: O CONFACK [Listen] id 4 len 15
>> BR0/0:1 LCP: AuthProto CHAP (0x0305C22305)
>> BR0/0:1 LCP: MagicNumber 0x03C2FF70 (0x050603C2FF70)
>> BR0/0:1 LCP: I CONFACK [ACKsent] id 4 len 10
>> BR0/0:1 LCP: MagicNumber 0x108D38B7 (0x0506108D38B7)
>> BR0/0:1 LCP: State is Open
>> BR0/0:1 PPP: Phase is AUTHENTICATING, by the peer
>> BR0/0:1 CHAP: I CHALLENGE id 4 len 28 from "ROUTER4"
>> BR0/0:1 CHAP: Using hostname from interface CHAP
>> BR0/0:1 CHAP: Using password from AAA
>> BR0/0:1 CHAP: O RESPONSE id 4 len 28 from "ROUTER5"
>> BR0/0:1 CHAP: I SUCCESS id 4 len 4
>> BR0/0:1 PPP: Phase is FORWARDING, Attempting Forward
>> BR0/0:1 PPP: Queue IPCP code[1] id[1]
>> BR0/0:1 PPP: Queue CDPCP code[1] id[1]
>> BR0/0:1 PPP: Phase is ESTABLISHING, Finish LCP
>> BR0/0:1 PPP: Phase is UP
>> BR0/0:1 IPCP: O CONFREQ [Closed] id 1 len 10
>> BR0/0:1 IPCP: Address 132.1.45.5 (0x030684012D05)
>> BR0/0:1 CDPCP: O CONFREQ [Closed] id 1 len 4
>> BR0/0:1 PPP: Process pending packets
>> BR0/0:1 IPCP: Redirect packet to BR0/0:1
>> BR0/0:1 IPCP: I CONFREQ [REQsent] id 1 len 10
>> BR0/0:1 IPCP: Address 132.1.45.4 (0x030684012D04)
>> BR0/0:1 IPCP: O CONFACK [REQsent] id 1 len 10
>> BR0/0:1 IPCP: Address 132.1.45.4 (0x030684012D04)
>> BR0/0:1 CDPCP: Redirect packet to BR0/0:1
>> BR0/0:1 CDPCP: I CONFREQ [REQsent] id 1 len 4
>> BR0/0:1 CDPCP: O CONFACK [REQsent] id 1 len 4
>> BR0/0:1 IPCP: I CONFACK [ACKsent] id 1 len 10
>> BR0/0:1 IPCP: Address 132.1.45.5 (0x030684012D05)
>> BR0/0:1 IPCP: State is Open
>> BR0/0:1 CDPCP: I CONFACK [ACKsent] id 1 len 4
>> BR0/0:1 CDPCP: State is Open
>> BR0/0 IPCP: Install route to 132.1.45.4
>> BR0/0:1 IPCP: Add link info for cef entry 132.1.45.4
>> %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0/0:1, changed state
>> to up
>> %ISDN-6-CONNECT: Interface BRI0/0:1 is now connected to 5272034 ROUTER4
>>
>> Rack3R5#
>> Rack3R5# show isdn active
>> ------------------------------------------------------------------------
>> --------
>> ISDN ACTIVE CALLS
>> ------------------------------------------------------------------------
>> --------
>> Call Calling Called Remote Seconds Seconds Seconds
>> Charges
>> Type Number Number Name Used Left Idle
>> Units/Currency
>> ------------------------------------------------------------------------
>> --------
>> In 5272034 5272035 ROUTER4 37 82 37
>>
>> ------------------------------------------------------------------------
>> --------
>>
>> Rack3R5#ping 132.1.45.4 repeat 2
>>
>> Type escape sequence to abort.
>> Sending 2, 100-byte ICMP Echos to 132.1.45.4, timeout is 2 seconds:
>> !!
>> Success rate is 100 percent (2/2), round-trip min/avg/max = 32/34/36 ms
>> Rack3R5#
>>
>>
>> Brian Dennis, CCIE #2210 (R&S/ISP-Dial/Security)
>> bdennis@internetworkexpert.com
>> Internetwork Expert, Inc.
>> http://www.InternetworkExpert.com
>> Toll Free: 877-224-8987
>> Direct: 775-745-6404 (Outside the US and Canada)
>>
>>
>> -----Original Message-----
>> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
>> Carlos G Mendioroz
>> Sent: Thursday, August 12, 2004 3:21 PM
>> To: ccielab@groupstudy.com
>> Subject: Callback w/o authentication (was: ISIS over ISDN , IEWB Lab2)
>>
>> I've reproduced a problem others seem to have encountered.
>>
>> IEWB Lab2 ISDN setup asks for one side of the ISDN link (R4-R5) not to
>> authenticate ever the other party.
>> This is solved by not using ppp authentication at R5.
>>
>> Then it asks for R4 to callback (and R4 is not allowed to initiate calls
>> by itself, only as callback service).
>>
>> This works fine, sort of, until the call back call reaches R5.
>> Now R5 has no idea who is calling in (because it is not allowed to
>> authenticate the other peer) and so it can not install L2-L3 mappings in
>>
>> the received call. It actually says "connected to unknown".
>> R5 has some indication of who is calling (because R4 IS authenticating
>> R5 and chap is being used) but this is R4's word for it and R5 does good
>>
>> in not taking that into account.
>>
>> So what's the answer ?
>> It seems to me that previous posters have given up researching what
>> was going on. I've seen the questions... but no answer.
>>
>> Is there any way out ?
>
>
-- Carlos G Mendioroz <tron@huapi.ba.ar>
This archive was generated by hypermail 2.1.4 : Fri Sep 03 2004 - 07:02:43 GMT-3