[c-nsp] Problem with ISDN backup (stuck CCBs in 12.3(11)T?)
Josh Duffek
consultantjd16 at ridemetro.org
Mon Nov 8 10:26:43 EST 2004
Defaults to two minutes.
josh duffek network engineer
consultantjd16 at ridemetro.org
> -----Original Message-----
> From: Stork, D.H. (Duncan) [mailto:d.h.stork at minlnv.nl]
> Sent: Monday, November 08, 2004 9:26 AM
> To: 'cisco-nsp at puck.nether.net'
> Cc: Josh Duffek
> Subject: RE: [c-nsp] Problem with ISDN backup (stuck CCBs in
12.3(11)T?)
>
> 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