From: Lord, Chris (chris.lord@lorien.co.uk)
Date: Mon May 24 2004 - 14:15:21 GMT-3
I have to go with ccie2be and Brian on this having just tested the whole lot:
You don't need the name parameter unless using ppp callback or not using ppp chap hostname, etc (I didn't have auth configured in my case by the way and I agree - always check operation without auth and then add it later!)
I should have realised the core of all this which is you need L2-L3 mapping. Without the dial string on one end I did in fact get encapsulation errors, duh!!
I'm using IOS 12.2(13) and traffic will pass without having dialer-group configured on one end.
I think I have it clear now. Thx for the contributions.
C.
-----Original Message-----
From: ccie2be [mailto:ccie2be@nyc.rr.com]
Sent: Monday, May 24, 2004 5:55 PM
To: Richard Dumoulin; Beernink.William; Lord, Chris;
ccielab@groupstudy.com
Subject: Re: ISDN Basics
Richard,
I have to respectfully disagree with you. Based on my understanding, the
name option of the dialer map command is only required in one situation;
ppp callback. If ppp callback isn't configured, all other isdn dial
scenario's should work fine, even though most examples show the name option
being used.
Even if you're using chap or pap authen, it will work without the name
option included in the dialer map command. Of course, you'll need to define
the name using other commands such as username --- password --- or ppp chap
hostname or something else.
Based on the info provided in the original question, I would also think that
authen wasn't the issue because Chris said the circuit came up. I suppose
it's possible that, in reality, the circuit didn't really come up but it
just seemed that way because Chris noticed the rtr dialing but didnt' notice
the other end rejecting the call.
And, I would suggest to Chris that before configuring any authen, he should
first make sure he can ping across the circuit so that he knows for sure
that authen isn't an issue.
HTH
----- Original Message -----
From: "Richard Dumoulin" <richard.dumoulin@vanco.es>
To: "Beernink.William" <william.beernink@siemens.com>; "Lord, Chris"
<chris.lord@lorien.co.uk>; <ccielab@groupstudy.com>
Sent: Monday, May 24, 2004 12:06 PM
Subject: RE: ISDN Basics
> Yes, normally this is because the name of the other end router was not
> configured on the dialer map,
>
> --Richard
>
> -----Original Message-----
> From: Beernink.William [mailto:william.beernink@siemens.com]
> Sent: lunes, 24 de mayo de 2004 17:59
> To: Lord, Chris; ccielab@groupstudy.com
> Subject: RE: ISDN Basics
>
>
> Hi Chris,
>
> Another option would be using a dialer rotary group on the remote site. To
> your problem about not getting an answer on your ping, there is most
likely
> a problem with authentication.
>
> regards William
>
> -----Original Message-----
> From: Lord, Chris [mailto:chris.lord@lorien.co.uk]
> Sent: maandag 24 mei 2004 17:25
> To: ccielab@groupstudy.com
> Subject: ISDN Basics
>
>
> Hi,
>
> I would be greatful if anyone could assist me with a very basic ISDN
query.
> If a task specifies that a call should only be initiated by one end of the
> link, I'm trying to sort out exactly what options are available to satisfy
> this.
>
> I'm only aware of two ways. One is to omit the "dialer-group" from one end
> so no interesting traffic is specified and the other is to remove the dial
> string from the "dialer map" statement at one end so it can't physically
> dial out. Are there any other obvious techniques.
>
> Also, assuming I have a "dialer-list 1 proto ip permit" and "dialer-gr 1"
at
> both ends but I omit the dial string from one of the "dialer map"
> statements, the link comes up in one direction as desired but ping won't
> work even though the link is up. Why is this?
>
> Thanks,
>
> Chris
>
>
> **********************************************************************
> The information contained in this email is confidential and is intended
for
> the recipient only. If you have received it in error, please notify us
> immediately by reply email and then delete it from your system. Please do
> not copy it or use it for any purposes, or disclose its contents to any
> other person or store or copy this information in any medium. The views
> contained in this email are those of the author and not necessarily those
of
> Lorien plc.
>
> Thank you for your co-operation.
> **********************************************************************
>
> _______________________________________________________________________
> Please help support GroupStudy by purchasing your study materials from:
> http://shop.groupstudy.com
>
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
> _______________________________________________________________________
> Please help support GroupStudy by purchasing your study materials from:
> http://shop.groupstudy.com
>
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
> _______________________________________________________________________
> Please help support GroupStudy by purchasing your study materials from:
> http://shop.groupstudy.com
>
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Wed Jun 02 2004 - 11:12:16 GMT-3