From: ccie2be (ccie2be@nyc.rr.com)
Date: Sat Nov 15 2003 - 11:22:07 GMT-3
Does a ping work from the calling side? If not, why?
What you can do is the following. (Assume R1 is the calling side and R2 is
the called side)
1) on the calling side, make sure the ping brings up the circuit. If you're
using isdn, do a show isdn status on both sides to confirm that layer 1 and
2 are up. If the output of the show command doesn't confirm l1 and l2 up
status, you have make sure you're using the correct isdn switch type and
correct spids. Also, make sure the isdn switch and routers are in agreement
about which telephone numbers are used for which router. (I once got it
backwards and it was a bitch to figure out.) If it brings up the circuit,
but the ping doesn't get any response, do a show dialer and look to see that
"Dialer state data link layer up" and "Connected to <remote tele #>". If
you don't see this, go to 2.
2) on the called side, make sure the ping from R1 brought up the interface
on R2. If it didn't, the ping never reached R2. That means R1 is
misconfigured. Check on R1 your dial map, your dial-list and dial group
statements. Also, if you're using dialer interfaces, check that your dialer
int includes a dialer pool # and your physical interface is a member of that
pool. Also, if you're using ppp, do a debug ppp nego to see whether both
LCP and NCP come up. If they both come up, you know that the ppp nego was
successful.
3) If the ping from R1 brings up the interface on R2, but the ping isn't
successful, you need to check some other stuff. Make sure both interfaces
on either side of the link are in the same subnet. Make sure the same type
of encap is used ( PPP & HDLC don't mix). If you're using PPP
authentication, do a debug PPP authen. If authentication is the problem,
check the username and passwords on each side - they're both case sensitive.
Better yet, don't do authentication at this point. 1st make sure a ping
works before enabling authen.
4) If none of these things correct the problem, do a debug ip packet on R2
and do the ping from R1 again . If the output of the debug says
"unroutable", that means R2 doesn't know where to send the ping echo reply
to. Also, on R2, do a show dialer map. If you want R2 to only receive
calls, R2 shouldn't have any dialer map statements or dialer string
statements, so that when R1 pings R2, you should see that R2 created a
"Dynamic dialer map".
DDR and ISDN can get fairly complicated pretty quickly with all the options
that are available. The best way to get comfortable with it is to 1)
understand what's taking place at each layer 2) getting used to using the
various show and debug commands related to dialing and 3) practicing alot
and often. I find that after a while I forget many of the details, but by
knowing and understanding what's going on at each layer, I'm able to get
back up to speed fairly quickly.
Also, there are many excellent sources of info on this topic. Personally, I
think Caslow's book, Cisco Certification, has the best, most logical
presentation of this material, but there are several other very good sources
as well. Check out Solie's Practical Studies and Bill Burton's Remote
Access for Cisco Networks. Also, check out Cisco's web site.
HTH, dt
----- Original Message -----
From: "Mac" <lmac0303@hotmail.com>
To: <ccielab@groupstudy.com>
Sent: Saturday, November 15, 2003 6:38 AM
Subject: One way dailing
> Hi, Group,
> When I am required to dial one way only, do I need to configure dial map
on
> the dialled side, do I need to configure dail-list as well? As I remember,
> dial-list is used to define the interesting traffic to make calls. So when
one
> way calling is required, defining interesting traffic and configuring dial
map
> would not be necessary. Am I correct? Thank you very much.
>
> ++++
> MAC
> ++++
>
> _______________________________________________________________________
> 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 Dec 12 2003 - 12:29:12 GMT-3