From: alsontra@hotmail.com
Date: Fri Mar 19 2004 - 21:48:36 GMT-3
The ISDN test command allows you to make a call without the use of
access-lists to define interesting traffic. Define the basic ISDN configs
on both routers and issue the command . Lab it up. I would imagine that
these commands are pivital to a successful lab. You can thank IE for that
one....
and
Alsontra-
----- Original Message -----
From: "Packet Man" <ccie2b@hotmail.com>
To: <alsontra@hotmail.com>; <ccielab@groupstudy.com>
Sent: Friday, March 19, 2004 2:37 PM
Subject: Re: Lab Tips - ISDN
> Hey Alsontra,
>
> That's a GREAT tip. I wasn't even aware of those commands. sounds like
they can be very useful. But, what the difference and benefit between using
this method and using the old method (pinging the remote BRI interface)?
>
>
> >From: <alsontra@hotmail.com>
> >To: "Packet Man" <ccie2b@hotmail.com>,<ccielab@groupstudy.com>
> >Subject: Re: Lab Tips - ISDN
> >Date: Fri, 19 Mar 2004 16:19:41 -0800
> >
> >ISDN:TIP
> >
> >1.After making your initial ISDN configs, use the "isdn test call
interface
> >bri (DN#)" command to verify that your interface working properly.
> > Also, use the "isdn test call disconnect interface bri all" instead of
> >"clear int bri 0/0". The latter command can cause problems with the isdn
> >switch that may cause you problem later on.
> >2. If your using dialer interfaces make sure to use either ppp or dialer
> >caller to identify the calling party(by name or number).
> >
> >Shootin from the hip here, so forgive the typos...
> >
> >Alsontra-
> >
> >
> >
> >----- Original Message -----
> >From: "Packet Man" <ccie2b@hotmail.com>
> >To: <ccielab@groupstudy.com>
> >Sent: Thursday, March 18, 2004 1:58 PM
> >Subject: Lab Tips
> >
> >
> > > Hi all,
> > >
> > > I've created a "Lab Tips" file of small items - factoids, reminders,
> > > suggestions, etc, I tend to forget. This is something I can refer to
> > > constantly when I'm doing practice labs or just have a few minutes to
> >spare.
> > >
> > > Here's a snippet from my Tips file.
> > >
> > > BGP
> > > Hard code router-id
> > > Don't use loopbacks for ibgp peering unless explicitly required
> > > Look for nei ... next-hop-self requirement especially on F/R hub and
> > > ethernets
> > > Disable bgp client to client reflection when clients are fully meshed
> > > Turn off auto-sum & sync unless explicitly required
> > > Reset BGP sessions using hard reset rather than soft reset.
> > > Know how to config nei xxxx local-as in combo with RR.
> > > Know all ways to config dampening
> > >
> > > I'm sharing this with GS because I suspect many candidates might also
have
> > > something like this. And, I thought that with all the great brain
power
> > > among GS subscribers we could all help each other by adding tips to
such a
> > > file.
> > >
> > > Here's my definition of what makes for a good tip.
> > >
> > > 1) A tip may not in any way violate the NDA
> > > 2) A good tip should be something that might be easily forgotten
because
> > > it's not that often encountered or somehow different from the
ordinary.
> >For
> > > example, when configuring ISIS over frame relay, don't forget to
enter
> >the
> > > "fram map clns <dlci> broadcast" statement. For me, this is a good
tip
> > > because I personally don't practice ISIS that often and I seem to
almost
> > > always forget that command.
> > >
> > > 3) A good tip must be short and clear because the whole idea behind
this
> > > file is to provide a quick reminder of various networking facts that
can
> > > come in handy during the actual lab.
> > >
> > > 4) A good tip must should not waste time going into the "why" of the
fact
> >or
> > > all the various permutations. For that, anyone interested can
research
> >the
> > > "why" of the fact on their own.
> > >
> > > 5) A good tip for one person might not be at all useful to someone
else.
> >We
> > > each tend to remember and forget different things. But, for example,
over
> > > time the BGP tips section may include 30 items and while I doubt all
30
> > > items will be useful to all people, I'm sure that 5 or 10 or 15 of the
> >tips
> > > will be useful to many people - just that it won't be the same 5 or 10
or
> >15
> > > tips.
> > >
> > > 6) A good tip must be potentially relevant to a ccie R&S candidate.
> > > Therefore, I ask that Off Topic comments be submitted elsewhere -
Let's
> >keep
> > > posts with the subject "Lab Tips" focus on just that.
> > >
> > > It's my hope that over time, with the input of a lots of people here,
this
> > > lab tips file will grow to include tips that cover every topic
potentially
> > > on the R&S lab exam. And, that as a result, we can each add the most
> > > personally valuable tips from this group effort to our own lab tips
file.
> > >
> > > Right now, my tips file has no entries for voice. So, I'd like to
start
> >off
> > > by asking people to submit their voice config tips. Of course, tips on
any
> > > potential lab are also welcomed.
> > >
> > > Here are some other potential tips topics I hope people feel free to
> >submit
> > > tips to.
> > >
> > > Redistribution
> > >
> > > ATM
> > >
> > > 3550
> > >
> > > OSPF
> > >
> > > NAT
> > >
> > > HSRP
> > >
> > > F/R
> > >
> > > ISDN
> > >
> > > QOS
> > >
> > > Multicast
> > >
> > > NTP
> > >
> > > Voice
> > >
> > > Eigrp
> > >
> > > Please add your tip under the appropriate heading and send back to GS.
> > >
> > > Hope this helps lots of people.
> > >
> > > Packet Man
> > >
> > > _________________________________________________________________
> > > MSN Toolbar provides one-click access to Hotmail from any Web page
FREE
> > > download! http://clk.atdmt.com/AVE/go/onm00200413ave/direct/01/
> > >
> > > ______________________________________________________________________
_
> > > 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 : Thu Apr 01 2004 - 08:15:38 GMT-3