I have a site with a BRI using dialer interfaces with "dialer-list 1 protocol ip permit" to define interesting traffic & a static pointing to the dialer.
Using debug dialer packets I can see that a ping to the ip address of the remote end is listed as interesting, but the BRI is never activated.
When I the debug dialer events, nothing is listed, so it is not even trying to bring up the interface.
Debug isdn q921 shows that the physical is OK (and we can dial in no problem) but debug isdn q931 shows no activity again.
Thanks for any ideas ??
Solved! Go to Solution.
I guess if you show us your config somebody will find the prob..
btw, do you have "dialer-group 1" in youd dialer interface, in order to match the dialer with the dialer-list ?
Is there a route to the remote IP address via the dialer, either explicitly as a static, or implicitly because it is in the same (sub)network as the dialer profile?
Did you remember to put your physical interfaces in the dialer pool (dialer pool member n) and set the dialer profile to use this pool (dialer pool n)? Did you put "dialer-group" command in the dialer profile? And finally, do you have a dialer string in the profile?
You are correct that the debug to look at is "debug dialer events"; if you don't see anything on that, then really nothing else will happen.
Sorry, I should have doen that first - I'm convinced this is not a config problem though - it is the same as the other side which works (with minor differences obviously!) Anyway, here it is :-
description ** local number is XXXXXXX **
no ip address
dialer pool-member 1
isdn switch-type basic-net3
no cdp enable
description temp for testing 13/08/03
ip address XXX.XXX.XXX.XXX 255.255.255.252
no ip split-horizon
dialer pool 1
dialer remote-name rtr_cmb_agrikon
dialer idle-timeout 180
dialer string XXXXXXXXX
no cdp enable
ppp authentication chap
ip route YYY.YYY.YYY.YYY 255.255.255.255 Dialer2
dialer-list 1 protocol ip permit
Debug dialer packets :-
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 220.127.116.11, timeout is 2 seconds:
*Mar 1 02:46:09.927: Di1 DDR: ip (s=xxxxxxxx, d=xxxxxxxx), 255 bytes, outgoing interesting (ip PERMIT)
*Mar 1 02:46:09.935: Di1 DDR: ip (s=xxxxxxx, d=xxxxxxx), 42 bytes, outgoing interesting (ip PERMIT)
*Mar 1 02:46:09.947: Di1 DDR: ip (s=xxxxxxxx, d=xxxxxxxxx), 141 bytes, outgoing interesting (ip PERMIT)
*Mar 1 02:46:09.947: Di1 DDR: ip (s=xxxxxxxx, d=xxxxxxx), 42 bytes, outgoing interesting (ip PERMIT)
*Mar 1 02:46:09.947: Di2 DDR: ip (s=xxxxxxx, d=xxxxx), 100 bytes, outgoing interesting (ip PERMIT). <<<< this one is relevant
*Mar 1 02:46:11.939: Di1 DDR: ip (s=xxxxxxx, d=xxxxxxx), 579 bytes, outgoing interesting (ip PERMIT)
Rest of debugs produce no output.
Can't see why it doesn't dial. However, I do notice that you don't have "encapsulation ppp" and "ppp authentication chap" on the BRI - I think you may have to put that on both the physical and logical interfaces.
Putting "encapsulation ppp" and "ppp authentication chap" on the BRI makes no difference.
Also, forgot to mention, the ISDN works from the opposite direction, so the connection (PPP in particular) is working - the symptoms are that nothing further happens after 'interesting' packets are recieved.
There is a static route to the far end (And one pointing bakc on the far end), the dialer interface is in the correct dial pool and has a dialer group pointing to a list permiting IP any.
The only thing I can think of is that the ISDN line has not been configured to place outbound calls.
try getting the following:-
then these debugs:-
debug isdn q931
debug dialer packet
post the output and let's have a look.
the show ver is :-
Cisco Internetwork Operating System Software
IOS (tm) C1700 Software (C1700-Y-M), Version 12.2(4)YA2, EARLY DEPLOYMENT RELEASE SOFTWARE (fc1)
Synched to technology version 12.2(5.4)T
TAC Support: http://www.cisco.com/tac
Copyright (c) 1986-2002 by cisco Systems, Inc.
Compiled Thu 11-Apr-02 21:54 by ealyon
Image text-base: 0x80008124, data-base: 0x807976DC
ROM: System Bootstrap, Version 12.2(7r)XM1, RELEASE SOFTWARE (fc1)
ROM: C1700 Software (C1700-Y-M), Version 12.2(4)YA2, EARLY DEPLOYMENT RELEASE SOFTWARE (fc1)
rtr_cmb_tiszabau uptime is 1 day, 5 hours, 46 minutes
System returned to ROM by power-on
System image file is "flash:c1700-y-mz.122-4.YA2.bin"
cisco 1721 (MPC860P) processor (revision 0x100) with 29492K/3276K bytes of memory.
Processor board ID FOC07040DPE (703224912), with hardware revision 0000
MPC860P processor: part number 5, mask 2
X.25 software, Version 3.0.0.
Basic Rate ISDN software, Version 1.1.
1 FastEthernet/IEEE 802.3 interface(s)
1 Serial(sync/async) network interface(s)
1 ISDN Basic Rate interface(s)
32K bytes of non-volatile configuration memory.
16384K bytes of processor board System flash (Read/Write)
Configuration register is 0x2102
The debug dialer packets is listed above, dialer & isdn q931 do not produce any output, so I guess things are no getting that far.
One diffence that I have noticed is that on the side that will not dial out has "hdlctype=HDLC-TRUNK"
rtr_cmb_tiszabau#sh isdn stat
Global ISDN Switchtype = basic-net3
ISDN BRI0 interface
dsl 0, interface ISDN Switchtype = basic-net3
Layer 1 Status:
Layer 2 Status:
TEI = 83, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED
Layer 3 Status:
1 Active Layer 3 Call(s)
CCB:callid=20, sapi=0, ces=1, B-chan=1, calltype=DATA, hdlctype=HDLC-TRUNK
Active dsl 0 CCBs = 1
The Free Channel Mask: 0x80000002
Number of L2 Discards = 0, L2 Session ID = 34
Anyone any idea of the relevance of this - I cannot find any reference on the Cisco web site.
forgot to mention.. switch on debug isdn q931 first. and try this on the router:-
isdn call int bri0 xxxxxxxxx
xxxxxxx is any land line phone number
check the debugs, and see if the bri trys to call...
the command can be:-
isdn test call int bri0 xxxxxxxxxx
depends on the IOS...
Yep, the isdn call at least triggers a q931 response.
Is this the output you would expect - not sure that the number is correct - they have different international dial codes in Hungary, also tried 0031 to and got same reply.
Many thanks for your help,
rtr_cmb_tiszabau#isdn call int bri0 000312xxxx
*Mar 2 06:35:25.024: BR0 DDR: Attempting to dial 00031204876403
*Mar 2 06:35:25.044: ISDN BR0: TX -> STATUS_ENQ pd = 8 callref = 0x81
*Mar 2 06:35:25.044: Cause i = 0x80E4 - Invalid information element contents
*Mar 2 06:35:25.064: ISDN BR0: TX -> SETUP pd = 8 callref = 0x04
*Mar 2 06:35:25.064: Bearer Capability i = 0x8890
*Mar 2 06:35:25.064: Channel ID i = 0x83
*Mar 2 06:35:25.064: Called Party Number i = 0x80, '00031204876403', Plan:Unknown, Type:Unknown
*Mar 2 06:35:25.136: ISDN BR0: RX <- STATUS pd = 8 callref = 0x01
*Mar 2 06:35:25.136: Cause i = 0x829E - Response to STATUS ENQUIRY or number unassigned
*Mar 2 06:35:25.136: Call State i = 0x0A
*Mar 2 06:35:25.140: ISDN BR0: TX -> STATUS pd = 8 callref = 0x81
*Mar 2 06:35:25.140: Cause i = 0x80E408 - Invalid information element contents
*Mar 2 06:35:25.140: Call State i = 0x0A
*Mar 2 06:35:25.320: ISDN BR0: RX <- SETUP_ACK pd = 8 callref = 0x84
*Mar 2 06:35:25.320: Channel ID i = 0x8A
*Mar 2 06:35:25.340: ISDN BR0: RX <- DISCONNECT pd = 8 callref = 0x84
*Mar 2 06:35:25.340: Cause i = 0x8283 - No route to destination
*Mar 2 06:35:25.344: BRI0: wait for isdn carrier timeout, call id=0x8004
*Mar 2 06:35:25.348: ISDN BR0: TX -> RELEASE pd = 8 callref = 0x04
*Mar 2 06:35:25.348: Cause i = 0x8083 - No route to destination
*Mar 2 06:35:25.432: ISDN BR0: RX <- RELEASE_COMP pd = 8 callref = 0x84
no problem with the isdn calling out then.. it is a bug..
upgrade to latest 12.2T train.. should cure it!!
Glad to help!