[cisco-nas] RE: [c-nsp] Problem with ISDN backup (stuck CCBs in 12.3(11)T?)

[Josh Duffek]

[adding in cisco-nas]

Inline.

> 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.


Sh int?  Sh isdn stat?


> 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


Well you have a floating static route AND dialer watch configured...I
guess I would remove the dialer watch config and see how it works
without...coule be a DW bug or something...not sure yet.




> 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.

Ok...so I'm guessing you are running into a "stuck CCB" type bug.
CCB=call control block IIRC.  When you have a call up on a B channel you
get a CCB...when the call drops the CCB should be "cleared".



 
> 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.
> 

I'd hop on the bug toolkit and search under ISDN for "CCB" in your
version...might actually give you a valid bug and a version that should
be good.  That or just for a test you could try 12.2(newest)T or talk to
TAC.

Maybe someone from nas can respond with some more clue.

Thanks,
Josh