Need help again - isdn backup

[bockri]

Hi

This time, four new questions:

1) In almost every config example with bri-interfaces, the dialer in-band command is set under the dialer int., but when i read about it, i find that this is only to be used if there is no bri/pri int. with a separate D-channel, so the dialer in-band takes 16bps from the two B-channels to get bandwidth for the signaling. So with a bri with dialer profiles calling a router with pri-int, should i use dialer in-band or not?

2) See this output from debug q931, i can't get bri1/0 to call out properly, (using the isdn call int bri1/0 21319608 command). Can someone see of this debug why it isn't working?

Mar 6 14:29:55: %ISDN-6-LAYER2UP: Layer 2 for Interface BR1/0, TEI 74 changed to up

Mar 6 14:29:55: ISDN BR1/0: TX -> SETUP pd = 8 callref = 0x62

Mar 6 14:29:55: Bearer Capability i = 0x8890

Mar 6 14:29:55: Channel ID i = 0x83

Mar 6 14:29:55: Called Party Number i = 0x80, '21319608'

Mar 6 14:29:56: ISDN BR1/0: RX <- CALL_PROC pd = 8 callref = 0xE2

Mar 6 14:29:56: Channel ID i = 0x89

Mar 6 14:29:57: ISDN BR1/0: RX <- DISCONNECT pd = 8 callref = 0xE2

Mar 6 14:29:57: Cause i = 0x8A8180 - Unallocated/unassigned number

Mar 6 14:29:57: ISDN BR1/0: TX -> RELEASE pd = 8 callref = 0x62

Mar 6 14:29:57: Cause i = 0x8081 - Unallocated/unassigned number

Mar 6 14:29:57: ISDN BR1/0: RX <- RELEASE_COMP pd = 8 callref = 0xE2

Mar 6 14:30:13: %ISDN-6-LAYER2DOWN: Layer 2 for Interface BR1/0, TEI 74 changed to down

3) The calling router calls out on the bri1/1 interface, the dialer interface has the dialer string.. and the dialer remote-name command + global username..password.. command. On the central router there is the username ... password ... command, beside this there is no dialer remote name and no dialer maps with ip addresss and name specified. Still it's working fine, why? I tried to remove the username...password ..command on both routers and the dialeing went ok anyway, isn't thieese commends necessary?

4)When i try to make another call while the first call made with the isdn call comm., still is up(to get both the channel go up) i get this debug output:

Mar 6 14:23:00: ISDN BR1/1: Event: Syncing Discards: L2 Discards 9, L2D_Task Counter 8

What does it mean? (i have set the dialer threshold to 1)

Many question to ansver here, puh...but differnt failures keep comming up, so i'd be really grateful for some comments. Kristine

[velimirmkd]

I'll try to help you from what I know:

1) There is difference between Dialer (dialer in-band) and dialer interface. Basicly all the routing is done on the dialer. An interface doesn't necessary have to be dialer. For example async interfaces are not dialers by default, bri's are dialers by default. By specifying dialer in-band on an interface you say that that interface will be dialer (will do the dialing and the rest).

Dialer interface as you probably know is just a logical interface which difines some things about certain connection (number , user...) So you may have multiple dialer interfaces defined for various connections and have only one physical interface that will carry all this different connection settings applied to it by the dialer interface.

The B channel of the ISDN is used for signaling, and it consists of 16k. I'm not sure if dialer takes over those 16k but I woldn' bet on it.

So if you are connecting to PRI through physical interface only (no dialer interface) you have to specify dialer in-band. If you have dialer interface then you specify that dialer interface is dialer in-band, and make the physical interface member of the same group as the dialer interface.

2)just put dialer string with the number to call and it should work. Also you can debug the dialer to se all the dialing and connection establisment.

3) What kind of authentication are you using. If it is CHAP then you have to specify remote-name and the rest. If it is PAP you just specify ppp pap sent-username .... If on the central site you have specified ppp authentication CHAP PAP that means that first CHAP authen will be tried and if fails then PAP. Also if you have RADIUS or TACACS server on the central site and on the recieving router you configure aaa autehntication local it will try to authenticate with the RAD/TAC and if it fails then it will try the local user base on the router.

Anyway dialing, connecting and authenticating are all different things that occure one after the other.

4) it seems like you have synchronization problem we need more info on that

Hope this helps

Velimir

[velimirmkd]

Hi, Kristine

First of all, NEVER post complete configs on the forums. Especially not the entries with the username and the ip addresses, now anyone with some more knowledge of Cisco can get into your router, at least into exec mode. So in future for your security dont post configs with hostname, username, or ip address, nor the SNMP comunity.

Now lets talk about the configs.

From what I can see you have the remore router connected to 193.217.255.22 via serial line. When it fails (goes down) you want the remote router via two BRI interfaces to dial into the central routers primary. First of all I would use dialer pool on the central site and I would assign addreses to the remote router when it dials for bakup.

For example:

interface Dialer1

ip unnumbered FastEthernet1/0

no ip directed-broadcast

encapsulation ppp

dialer in-band

dialer-group 1

peer default ip address pool setup_pool

ppp authentication pap chap ms-chap

!

ip local pool setup_pool 1.1.1.1 1.1.1.6

Second if you want both BRI's to dial out together into the centrals pri, you'll have to put them in multilink-group and the dialer on the remote site in the same multilink-group too. Plus put ppp multilink on each BRI to make them use both D channels. You can configure the multilink in several ways. One way is to have it bring both interfaces up once triggered, another is to have it bring additional interface up when certain treshold is achieved. Do some reading on multilink if you want to use it.

Last. Back up interface works only on interesting traffic. This means that you'll need interesting traffic from within the network to trigger the back up interface to dial. This is pain when you have certain services on the net that need to be accessed from the outside, and since you have to interesting traffic from the inside you cant access the sevices from the outside. To correct this use dialer-watch as backup strategy. There is lots of info about the dialer watch on Cisco and it works fine after 12.0(7) I think... Dialer watch is usefull since it does not depend on interesting traffic.

Also make an access list that will prevent the routing hellos (ospf, eigrp) to keep the backup link up, even when the primary is up. This is done by defining this traffic as uninteresting in your dialer.

Lots of info

Hope it helps

Velimir

[mljohnson]

1. Dialer in-band is used for Legacy DDR; it need not be configured under a native ISDN interface (it is there by default), and it need be configured on a dialer or other physical interface if you want to dial out using a dialer string or a dialer map. It need NOT be configured on a dialer profile (which is also a dialer interface), since dialer profiles and Legacy DDR are two separate solutions.

2. Confirm that the number you are dialing is correct; the carrier is unable to deliver the call to 21319608.

3. You need to differentiate (with dialer profiles) between actual dialing, binding (where the called router finds a dialer profile to bind to), and authentication (which should ultimately occur to allow the call). On the central router, if you only have one dialer profile then we will bind automaticaly. Otherwise, we will try to bind based on the calling number ("dialer caller") or the authenticated name ("dialer remote-name", only if authentication is enabled on the incoming physical interface). We will dialout as long as the routing table forwards packets to the dialer interface, the packets are interesting, and we have a dialer string.

4. The ISDN debug can be ignored; there are layer2 packets that are being discarded.

Hopefully this will help you to understand dialer profiles and the binding rules:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fdial_c/fnsprt5/dcdiprof.htm