From: Packet Man (ccie2b@hotmail.com)
Date: Fri Mar 19 2004 - 20:08:35 GMT-3
OK. So. if I understand you and the CR correctly, here's the major (only?)
difference between new method (ISDN test) and old method (ping). To use
ping to test the config and circuit, you must first define interesting
traffic and, of course, associate that dialer-list with a dialer-group among
the other basic config requirements.
With new method, you test config without that and thereby limit your
troubleshooting to less variables: telephone #, encap, and switch type -
althought for switch-type, I always do a show isdn status right after
specifying the switch type to make sure layer 1 is OK.
And, to end the test and take down the circuit, use the other command - isdn
test call disconnect interface bri all. Correct?
BTW, will the dialer idle-timeout work to end the call when begun with the
isdn test command?
Thanks, PM
>From: <alsontra@hotmail.com>
>To: "Packet Man" <ccie2b@hotmail.com>,<ccielab@groupstudy.com>
>Subject: Re: Lab Tips - ISDN
>Date: Fri, 19 Mar 2004 16:48:36 -0800
>
>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....
>
>http://www.cisco.com/en/US/products/sw/iosswrel/ps1835/products_command_reference_chapter09186a008007ffda.html#1142244
>
>and
>
>http://www.cisco.com/en/US/products/sw/iosswrel/ps5187/products_command_reference_chapter09186a008017d8f6.html#1169631
>
>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