[c-nsp] Problem with ISDN backup

Mon Nov 8 16:19:42 EST 2004

this is usually self-inflicted and if like most isdn backup solutions tghe
back-off amd delay timers for isdn are using
defaults. HUGE problem if you expect the pri and backups to sync correctly.
will never happen if you allow the isdn
protocol to for its default wait period. it is for all intents 'ignores' the
pri until a configurable period of time
has elapsed prior to handing control back to primary interface. check
allowable config options. dont like the scenario 
in general as debugging is messy if carrier  gets involved as throwing loops
up and forgetting to bring them down
doenst help and if the pri links are using BGP or other state tracking
protocol it gets penalized. it all backups...uphill.

you are causing the 'flap'. 

you are gonna have to play with this architecture to get it right for your
environment.

~piranha

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net]On Behalf Of piestaga
Sent: Sunday, November 07, 2004 3:10 PM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] Problem with ISDN backup

Hi,

on several different mailing lists I found the similar problem description,
but nowhere I could found the reason of that incorrect behaviour of ISDN
backup connection.

Well, the main problem is that the ISDN backup connnection works fine,
untill the primary link is up again. 

For some reason ,the BRI interface stays in some 'strange' state which make
it imposibe to dial-out again, when the primary link will go down second
time.

For test purpose I used Cisco 1751 router and 12.3(11)T equipped with
WIC-1B-S/T card.

The primary links (that the ISDN connection should backup) are two GRE
tunnels inside the VRF.

Both GRE uses OSPF for maintaining the connection to remote sites (first GRE
acts as primary tunnel whereas the second one works as the redundant one).

So, when primary GRE for some reason goes down, the redundant one should
takes its place. But when second one also goes down (assuming that the
primary still stays down) then the backup ISDN connection should come into
the game 

ISDN Dialer use static entries to route the backup traffic and it should
dial out to LAC server which basis on that that PPP session should establish
a L2TP tunnels to LNS server.

(text omitted)
!
interface Tunnel1                     /primary tunnel/
 ip vrf forwarding vpn
 ip address 3.3.3.2 255.255.255.252
 tunnel source Vlan10
 tunnel destination 111.111.111.111
!
interface Tunnel2                     /redundant tunnel/
 bandwidth 4
 ip vrf forwarding vpn
 ip address 3.3.3.6 255.255.255.252
 tunnel source Vlan10
 tunnel destination 112.112.112.112
!
interface BRI0/0
 no ip address
 encapsulation ppp
 dialer pool-member 1
 isdn switch-type basic-net3
!
interface FastEthernet1/1
 switchport access vlan 10
 no ip address
!
interface FastEthernet1/2
 switchport access vlan 20
 no ip address
!
interface FastEthernet1/3
 switchport access vlan 20
 no ip address
!
interface FastEthernet1/4
 switchport access vlan 20
 no ip address
!
interface Vlan10                                      

 ip address 10.10.10.2 255.255.255.0
 ip nat outside
!
interface Vlan20
 ip address 20.20.20.1 255.255.255.0
 ip nat inside
!
interface Dialer1
 ip vrf forwarding vpn
 ip address 3.3.3.10 255.255.255.252
 encapsulation ppp
 dialer pool 1
 dialer remote-name LAC
 dialer string 1234567
 dialer watch-group 1
 dialer-group 1
 ppp authentication pap callin
 ppp pap sent-username backup password 0 backup
!
router ospf 333 vrf vpn            /both GRE tunnels uses OSPF to get the
network 99.99.99.99/
 log-adjacency-changes
 redistribute connected metric 10 subnets
 network 3.3.3.0 0.0.0.7 area 0
!
ip route vrf vpn 99.99.99.99 255.255.255.255 Dialer1 200    / Dialer
interface uses static to 99.99.99.99/
!
dialer watch-list 1 ip 99.99.99.99 255.255.255.255 vrf vpn    /watched
address/
******************************
END

The call scenario looks like that:

1.	Both primary links goes down
2.	Dialer sees the interesting traffic to watched network and brings
the interface up
3.	primary linki s up again, then the dialer goes down
4.	then the primary links goes down again
5.	Dialer is unable to dial out..... 

... debug output shows that both B channels are busy (what is strange PSTN
sees no busy channels) !!!

show isdn status : 

Global ISDN Switchtype = basic-net3
ISDN BRI0/0 interface
        dsl 0, interface ISDN Switchtype = basic-net3
    Layer 1 Status:
        ACTIVE
    Layer 2 Status:
        Layer 2 NOT Activated
    Layer 3 Status:
        0 Active Layer 3 Call(s)
        CCB:callid=8097, sapi=0, ces=1, B-chan=1, calltype=DATA,
hdlctype=HDLC-TRUNK
        CCB:callid=8098, sapi=0, ces=1, B-chan=2, calltype=DATA,
hdlctype=HDLC-TRUNK
    Active dsl 0 CCBs = 2
    The Free Channel Mask:  0x80000000
    Total Allocated ISDN CCBs = 2

debug dialer:

Neighbor Down: Interface down or detached
 DDR: Dialer Watch: watch-group = 1
 DDR:        network 99.99.99.99/255.255.255.255 DOWN,
 DDR:        primary DOWN
 DDR: Dialer Watch: Dial Reason: Primary of group 1 DOWN
 DDR: Dialer Watch: watch-group = 1,
 DDR: Dialer Watch: No free dialer on Di1

The only thing that I can make is to shutdown and un-shutdown the BRI
interface.

That clears the state and ISDN can again be used for backup.

Afrer the BRI status is cleared, everything works fine.
In such cases the: debug dialer displays the following output:

 I believe someone got such problems before and will be able to help, why
the B channels remains "up" even the backup connection is no longer
required.

Regards
piestaga

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/