[c-nsp] Problem with ISDN backup (stuck CCBs in 12.3(11)T?)
Stork, D.H. (Duncan)
d.h.stork at minlnv.nl
Mon Nov 8 10:25:32 EST 2004
Hi,
Did you try to configure an idle-timeout on the dialer?
dialer idle-timeout <seconds>
I couldn't find it on your config...
With kind regards,
Duncan Stork
-----Oorspronkelijk bericht-----
Van: Josh Duffek [mailto:consultantjd16 at ridemetro.org]
Verzonden: maandag 8 november 2004 15:51
Aan: piestaga; cisco-nsp at puck.nether.net
CC: cisco-nas at puck.nether.net
Onderwerp: RE: [c-nsp] Problem with ISDN backup (stuck CCBs in
12.3(11)T?)
[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
_______________________________________________
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/
More information about the cisco-nsp
mailing list