From: Bernard Dunn (dunn@xxxxxxxxx)
Date: Sun Feb 04 2001 - 20:30:22 GMT-3
Brian and all,
Another thing we've noticed in the field, is that when you change ddr
parameters, the interface tends to be 'sticky', that is, if you change a
dialer statement, it's best practice to shutdown the interfaces first,
change the parameters/statements, and then 'no shutdown' the
interface. Reinitializes everything.
Regards
Bernard.
On Sun, 4 Feb 2001, Brian Hescock wrote:
> 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/12
0t/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