Re: isdn (numerous questions)

From: Brian Hescock (bhescock@xxxxxxxxx)
Date: Sun Feb 04 2001 - 19:49:53 GMT-3


   
Bernard,
   Correct, I realize dms-100 requires spids, at least for legacy DDR (and
now know it also applies to dialer profiles). One would think that if the
majority of isdn switches require spids then the majority of the sample
configs would show spids being used in conjunction with dialer
profiles. Since they don't, you follow the sample configs and
don't use them. Perhaps if they put the switch-type in the sample
configs so that if I saw it was 5ess I would know why they weren't
using spids...

I've also seen sample configs with dialer maps used with dialer profiles,
particularly with ppp callback. Identical config and it isn't
working...grrrr. Just did a write-erase / reload to get rid of all of my
old configs, such as crypto configs, etc (not for bri). Perhaps that
will get rid of some of the problems / bugginess I've been seeing.

B.

On Mon, 5 Feb 2001, Bernard Dunn wrote:

> Brian,
>
> Some answers inline.
>
> On Sun, 4 Feb 2001, Brian Hescock wrote:
>
> > No problems with legacy ddr but dialer-profiles and the contradictions I'm
> > coming across are driving me crazy (4 days to go).
> >
> > - 99% of the sample configs show no spids under bri0 in the config when
> > using dialer profiles. I couldn't get it to work without adding spids
> > when using dms100. Any idea why? (might be a bug, I could see one side
> > dial and the other side keep coming up and dropping but I couldn't dial
> > from the other side at all. both sides dial fine when adding the spids so
> > it shouldn't have been a config issue).
>
> Need for spids depends on the network switch-type. dms-100 is one that
> needs spid, NI is another. Shortest way to describe it: it's the way that
> particular spec works.
>
> >
> > - one of the big advantages of dialer profiles is you don't need dialer
> > maps. But I see them used in some sample configs. When would you need to
> > use dialer maps when using dialer-profiles and why?
> >
>
> You shouldn't be using 'dialer map' statements in DP at all. What you
> might have come across is a rotary dialer situation, where the physical
> interface is seen as the rotary number, and have multiple dialer
> interfaces using that rotary number/interface to call out when
> interesting traffic comes along. It's an old method taken over by DP as we
> know it today.
>
> > - which is correct, putting ppp authentication under the physical
> > interface, the dialer interface, or both? The sample configs I've seen
> > aren't consistent at all.
> >
>
> If you have a quick scan of the CCO doc here, there is a pretty good
> explaination of authentication/binding order when using DP and ppp:
>
> http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120t
/120t5/dmencp2.htm
>
> In troubleshooting out there, we usually have 'encap ppp' on the physical
> interface, and both 'encap ppp' and 'ppp authen chap' at the dialer. Works
> all the time. But review the concept behind why we do it.
>
> Thoroughly recommend you to read the url, if not to pass the exam, at
> least to understand the binding sequence.
>
> > - a lot of sample labs I've run across asking you to configure isdn
> > so that it comes up when a directly connected interface goes down. Backup
> > interface comes to mind but that supposedly causes problems when using
> > legacy DDR, you can't use the isdn link for anything else then. So far
> > lab purposes I would assume its safest to always use dialer profiles,
> > correct? The reason I say this is you never know what you might get on
> > Day 2 and something on Day 2 could require use of the isdn link but you
> > might already be using it as a backup interface and therefore it won't
> > work for the other purpose.
> >
> > Another option I suppose would be to use dialer watch instead of backup
> > interface so we don't tie up the isdn link and we can get away with using
> > legacy ddr instead of dialer profiles.
> >
> > Brian
> >



This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:28:36 GMT-3