John,
It does need it. You need the dialer-group command under the interface even
if you don't define any interesting traffic in order for the router to send
traffic over the link. If you don't have a dialer-group defined you'll get
an encapsulation failed when you do a debug ip packet. I know this doesn't
make sense from what the Cisco documentation says.
Brian Dennis
CCIE #2210 (R&S)(ISP/Dial)
CCSI #98640
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
> Jaeheon Yoo
> Sent: Tuesday, May 01, 2001 3:25 PM
> To: [EMAIL PROTECTED]
> Subject: Re: ISDN BRI up but does not ping [7:2712]
>
>
> Hi, Jim
>
> My understanding is dialer-group statement does NOT block any packets
> while the connection is established up.
>
> What it does is;
>
> 1. define interesting traffic to initiate the call
> 2. reset the idle timers when interesting traffic is pass through
> established connection.
>
> Please correct me if I'm wrong.
>
> Regards,
> Jaeheon
>
>
> On 1 May 2001 18:14:48 -0400, [EMAIL PROTECTED] ("Jim Brown")
> wrote:
>
> >I scanned the message and noticed the configs at the bottom.
> >
> >You only applied a dialer-group on the dialing end. My testing and
> >observation determined that you need a dialer-group statement on
> the remote
> >end also.
> >
> >If you do not define any interesting traffic for the remote end
> it will not
> >send any packets back to the host that initiated the call.
> >
> >I always assumed you only needed to define interesting traffic
> to initiate a
> >call, so why would I need the dialer-group statement on the remote end?
> >
> >When initially goofing around with ISDN I noticed this behavior.
> I could not
> >find it documented anywhere. I just assumed if the connection is
> up why do I
> >need to define interesting traffic for the remote end. This
> drove me crazy
> >for a few hours.
> >
> >List, please correct me if I'm crazy. I noticed this behavior
> with 12.0 IOS.
> >
> >-----Original Message-----
> >From: Jaeheon Yoo [mailto:[EMAIL PROTECTED]]
> >Sent: Tuesday, May 01, 2001 3:57 PM
> >To: [EMAIL PROTECTED]
> >Subject: Re: ISDN BRI up but does not ping [7:2712]
> >
> >
> >Hi, Shoaib.
> >
> >First of all, you have to check if the ping packet is ever received by
> >the remote end, is it possible to "debug ip packet" at the remote end?
> >If it's not possible, check it at the center site with this.
> >
> >access-list 110 permit ip 130.1.1.0 0.0.0.255 130.1.1.0 0.0.0.255
> >debug ip packet detail 110
> >
> >If it's ever really sent to the remote end, then check if your isdn
> >interface of the remote end has any access-lists configured, which may
> >block return ping(echo reply) or any policy routing on that matter.
> >
> >From your post, I have found nothing wrong with ISDN configuration.
> >But one thing is missing at the remote end, you have to add
> >dialer-group command to reset idle timer when interesting packets are
> >passed. But I guess this is not directly related to your current
> >problem.
> >
> >Please let me know how you solved the problem, if it's done.
> >
> >Regards,
> >Jaeheon
> >
> >On 1 May 2001 14:43:19 -0400, [EMAIL PROTECTED] ("Shoaib Waqar")
> >wrote:
> >
> >>I have traced the route as well, the data is not
> >>passing across the ISDN link.
> >>
> >>I also have used extended ping, but it does not ping.
> >>
> >>Shoaib
> >>
> >>--- Albert Lu wrote:
> >>> Do you know whether data is going across the link at
> >>> all?
> >>>
> >>> Try a trace to the other side, and see what route
> >>> the packet takes.
> >>>
> >>>
> >>> Albert
> >>>
> >>> > -----Original Message-----
> >>> > From: Shoaib Waqar [mailto:[EMAIL PROTECTED]]
> >>> > Sent: Tuesday, 1 May 2001 10:15
> >>> > To: Albert lu
> >>> > Cc: [EMAIL PROTECTED]
> >>> > Subject: RE: ISDN BRI up but does not ping
> >>> [7:2712]
> >>> >
> >>> >
> >>> > Yes i also have used an access-list to prevent
> >>> eigrp
> >>> > to initiate call, and it dials on a ping event, as
> >>> > shown by the 'deb dialer events'
> >>> >
> >>> > shoaib
> >>> >
> >>> >
> >>> > --- Albert Lu wrote:
> >>> > > Try using debug dialer events to see if the
> >>> dialing
> >>> > > actually takes place
> >>> > > when you ping. If the dialer doesn't come up,
> >>> then
> >>> > > it could be a dialer
> >>> > > problem. If it does come up, and dialing fails,
> >>> then
> >>> > > it could be an isdn
> >>> > > problem.
> >>> > >
> >>> > > Albert
> >>> > >
> >>> > > > -----Original Message-----
> >>> > > > From: Shoaib Waqar
> >>> [mailto:[EMAIL PROTECTED]]
> >>> > > > Sent: Tuesday, 1 May 2001 9:54
> >>> > > > To: Albert lu
> >>> > > > Cc: [EMAIL PROTECTED]
> >>> > > > Subject: RE: ISDN BRI up but does not ping
> >>> > > [7:2712]
> >>> > > >
> >>> > > >
> >>> > > > I have tried dialer profiles, legacy DDR with
> >>> > > dialer
> >>> > > > mao statement and with floating static route
> >>> too,
> >>> > > but
> >>> > > > still same result, could not ping the
> >>> neighbor.
> >>> > > > Offcourse there is a dialer-list statement to
> >>> > > initiate
> >>> > > > call:
> >>> > > >
> >>> > > > dialer-list 1 protocol ip permit
> >>> > > >
> >>> > > > Shoaib
> >>> > > >
> >>> > > >
> >>> > > >
> >>> > > > --- Albert Lu wrote:
> >>> > > > > I personally think that using dialer
> >>> profiles
> >>> > > are
> >>> > > > > better than hard coding
> >>> > > > > the interface. It is also true that there is
> >>> no
> >>> > > > > dialer-list command to dial
> >>> > > > > for interesting traffic, and you don't have
> >>> a
> >>> > > route
> >>> > > > > to use the bri interface
> >>> > > > > so it wouldn't know when to dial.
> >>> > > > >
> >>> > > > > Wouldn't you need a dialer map command for
> >>> > > > > interfaces, rather than specify
> >>> > > > > dialer string?
> >>> > > > >
> >>> > > > > Albert
> >>> > > > >
> >>> > > > > > -----Original Message-----
> >>> > > > > > From: [EMAIL PROTECTED]
> >>> > > > > [mailto:[EMAIL PROTECTED]]On Behalf Of
> >>> > > > > > Shoaib Waqar
> >>> > > > > > Sent: Tuesday, 1 May 2001 6:15
> >>> > > > > > To: [EMAIL PROTECTED]
> >>> > > > > > Subject: ISDN BRI up but does not ping
> >>> > > [7:2712]
> >>> > > > > >
> >>> > > > > >
> >>> > > > > > I am getting trouble in ISDN bri link. I
> >>> have
> >>> > > a
> >>> > > > > > Central site Router 3640 with 12.1.8
> >>> IP/IPX
> >>> > > plus
> >>> > > > > IOS.
> >>> > > > > > the route has 4 port BRI module. The
> >>> remote
> >>> > > site
> >>> > > > > is
> >>> > > > > > having 2503, all u know that it has 1 port
> >>> > > BRI.
> >>> > > > > remote
> >>> > > > > > site is running 11.2.1 version of IOS. The
> >>> > > call is
> >>> > > > > > placed using simple DDR commands as:
> >>> > > > > >
> >>> > > > > > Cisco 3640 Router
> >>> > > > > > =================
> >>> > > > > > Int bri 2/0
> >>> > > > > > ip add 130.1.1.1 255.255.255.0
> >>> > > > > > encap ppp
> >>> > > > > > dialer idle-timeout 300
> >>> > > > > > dialer fast-idle 300
> >>> > > > > > dialer string xxxxxxxx
> >>> > > > > > dialer-group 1
> >>> > > > > >
> >>> > > > > > Remote site (2503):
> >>> > > > > > ===================
> >>> > > > > >
> >>> > > > > > Int bri 0
> >>> > > > > > ip add 130.1.1.2 255.255.255.0
> >>> > > > > > encap ppp
> >>> > > > > > dialer idle-timeout 300
> >>> > > > > > dialer fast-idle 300
> >>> > > > > >
> >>> > > > > > In this scenario, a/c to customer need,
> >>> the
> >>> > > > > central
> >>> > > > > > site is placing call.When the call has
> >>> placed,
> >>> > > and
> >>> > > > > we
> >>> > > > > > see the debug output, it shows all the
> >>> debug
> >>> > > of
> >>> > > > > ppp
> >>> > > > > > negotiations and ISDN events as correct,
> >>> with
> >>> > > the
> >>> > > > > > install route at the end. When i run 'show
> >>> > > isdn
> >>> > > > > > status' it shows me all layers up with one
> >>> > > active
> >>> > > > > > layer 3 call also. Also 'show isdn active'
> >>> > > gives
> >>> > > > > me
> >>> > > > > > successful call to remote site. So nothing
> >>> > > seems
> >>> > > > > to be
> >>> > > > > > wrong with config. THE problem is that
> >>> after
> >>> > > > > > connectivity when i try to ping from
> >>> central
> >>> > > site
> >>> > > > > the
> >>> > > > > > remote site ip address, it times out. I
> >>> took
> >>> > > the
> >>> > > > > 'show
> >>> > > > > > ip route', and it gives me only connected
> >>> > > routes
> >>> > > > > but
> >>> > > > > > dont show me the remote LAN network
> >>> address of
> >>> > > > > each
> >>> > > > > > site which it should give as i m running
> >>> EIGRP
> >>> > > at
> >>> > > > > both
> >>> > > > > > sites. The primary link is working
> >>> correctly
> >>> > > as i
> >>> > > > > have
> >>> > > > > > an SCPC 128K link between the two sites as
> >>> > > well
> >>> > > > > and
> >>> > > > > > showing correct routes. The switch type in
> >>> > > > > pakistan
> >>> > > > > > normally we use is basic-net3 (SIEMENS
> >>> > > switch).
> >>> > > > > Can
> >>> > > > > > anyone plzz help me, where is the issue??
> >>> i
> >>> > > have
> >>> > > > > tried
> >>> > > > > > everything, dialer profiles and all. but
> >>> > > nothing
> >>> > > > > seems
> >>> > > > > > to be working, i cant ping the other side
> >>> thru
> >>> > > > > BRI.
> >>> > > > > >
> >>>
> >>=== message truncated ===
> >>
> >>
> >>__________________________________________________
> >>Do You Yahoo!?
> >>Yahoo! Auctions - buy the things you want at great prices
> >>http://auctions.yahoo.com/
> >>FAQ, list archives, and subscription info:
> >http://www.groupstudy.com/list/cisco.html
> >>Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
> >FAQ, list archives, and subscription info:
> >http://www.groupstudy.com/list/cisco.html
> >Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
> >FAQ, list archives, and subscription info:
> http://www.groupstudy.com/list/cisco.html
> >Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
> FAQ, list archives, and subscription info:
http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=2828&t=2712
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
