From: Ahmed Mustafa (ahmed.mustafa@sbcglobal.net)
Date: Tue Feb 24 2004 - 02:27:20 GMT-3
Brian,
Ofcourse any suggestions from you always help. If I am taking a lab, and
don't see any trick wording about what apporach to take, then I will simply
define DN in mapping commands, and Dialer String at both ends, and if the
lab asks that only one end should only able to be call then I will just
simple not use the dialer-list/dialer-group command at that specific end.
Just to let you know that even in 12.2 code, I am not able to ping if one
end is omitted with DN or Dialer string command.
For example,
If I want r1 to intiate a call to r2, and not vice versa, and then define
DN/Dialer string at r1 only. I will see that that the Bri 0:1 channel went
up, but the ping sessions will be unsuccessful. But if I take the approach
in the solution guide you mentioned then I can successfully ping from r1 to
r2 after initiating a call.
Regards,
Ahmed
----- Original Message -----
From: "Brian McGahan" <bmcgahan@internetworkexpert.com>
To: "'Ahmed Mustafa'" <ahmed.mustafa@sbcglobal.net>;
<ccielab@groupstudy.com>
Sent: Monday, February 23, 2004 9:30 AM
Subject: RE: Internetwork Expert Lab 2 Task 4.1 - 4.3
> Ahmed,
>
> There was a bug in ISDN code 12.1 and prior where traffic could not
> be encapsulated unless there was a dialer-group applied to the interface.
> This is not to say that the dialer-list even need be assigned. The best
way
> to have the router not initiate a call is to omit the dialer-group
> dialer-list configuration.
>
> If you have a dialer map without a phone number or omit the dialer
> string, and you have interesting traffic defined, do a debug dialer and
you
> can see that the router is actually trying to initiate a call, but gets an
> error back that there is no number to call.
>
> In the case of the lab I would take either as acceptable. Keep in
> mind that the dialer-map is not used to initiate a call, but instead used
> for layer 3 to layer 2 resolutions. When doing legacy you should
configure
> a dialer map regardless in order to obtain layer 3 to layer 2 resolution,
> but of course there are even exceptions to this rule :)
>
>
> HTH,
>
> Brian McGahan, CCIE #8593
> bmcgahan@internetworkexpert.com
>
> Internetwork Expert, Inc.
> http://www.InternetworkExpert.com
> Toll Free: 877-224-8987 x 705
> Outside US: 775-826-4344 x 705
>
>
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> > Ahmed Mustafa
> > Sent: Sunday, February 22, 2004 2:50 AM
> > To: ccielab@groupstudy.com
> > Subject: Internetwork Expert Lab 2 Task 4.1 - 4.3
> >
> > Hello Folks,
> >
> > Can anyone explain the following:
> >
> > Task 4.3) R4 should not be allowed to initiate an ISDN Call.
> >
> > 1) The common practice according to the other sources are
> >
> > Don't use the dialer string command for Dialer profiles, and
> > Don't use the DN in dialer map command for legacy DDR
> >
> > However, in a solution guide,
> >
> > DN was used on R4 in a mapping command. However, the dialer-list along
> > with
> > dialer-group command was omitted. I know for a fact that without the
> > dialer-list/dialer-group command, ISDN will never be able to initiate a
> > call.
> > What will be the best approach, especially if one is taking a real CCIE
> > lab.
> >
> > 2) The broadcast command was omitted. Mainly broadcast command is
> > required to
> > allow routing protocols to be able to send/receive updates.
Technically,
> > I
> > would have used broadcast keyword since the requirement was to allow
> > routing
> > protocol update. It was actually added on later tasks with clns-is
> > though. I
> > just want to be thorough while doing my tasks since no partial credit is
> > awarded.
> >
> > Regards,
> >
> > Ahmed
> >
> > _______________________________________________________________________
> > 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 : Fri Mar 05 2004 - 07:13:56 GMT-3