From: James.Irwin@xxxxxxxxxxxxx
Date: Wed Mar 06 2002 - 13:32:33 GMT-3
Hello,
Did you ever find a solution to this problem?
Is ospf demand-circuit just not a good choice to use with Dialer Profile?
I can get everything to work fine with Legacy DDR.
Same configurations under dialer profile causes link flapping with no
solution addressed so far in these postings or in Solie's, Doyle's, or
Caslow's books.
I have been looking at it and trying to make it work for 2 days now - no
luck.
I can make the link stop flapping, but then no routing updates can pass over
the bri when the primary Serial interface goes down - defeats the purpose of
demand-circuit. Does not provide for full connectivity when the serial
fails.
Facts:
There are no topology changes causing the link to come up.
The interesting traffic is generated by ospf trying to form an adjacency
over the bri.
If configured as a point-to-point link, a static neighbor adjacency cannot
be configured - multicast is sent attempting to form adjacency, bringing up
the link.
If configured as nbma with neighbor defined under the ospf process - the
link comes up with a unicast message to the neighbor.
Any one who has specifically solved this one, please advise.
thanks,
Jim
-----Original Message-----
From: Katson PN Yeung [mailto:kyeung@hkcix.com]
Sent: Wednesday, February 20, 2002 3:50 AM
To: ccielab@groupstudy.com
Subject: trouble with dialer profile + multilink PPP + demand-circuit
Dear all,
I have problem making my ISDN backup to work without flapping. How to make
dialer-profile with ip ospf-demand circult to work with multilink PPP???
Hm... or what I have countered is a bug of IOS??
Scenario:
I have 2 routers:
R5----s0----R6
| |
|---isdn----|
R5 use dialer profile to call R6, with ip ospf demand-circuit
R6 use legacy DDR config.
R5 bring up 2nd B-channel if load exceed 50%.
R5 enabled PPP chap callin.
IP:
R5 S1: 140.4.99.1/24
R5 Dialer1: 140.4.56.1/30
R6 S1: 140.4.99.2/24
R6 BRI0: 140.4.56.2/30
Single OSPF area. No redistribution. All router running IOS 12.1.12a.
Problem:
Once the isdn idle-timeout expires, R5 drop the call, and then R5
immediately trigger the ISDN link by s=140.4.56.1, d=224.0.0.5 traffic.
No matter how hard I try, it is still flap, unless I use legacy DDR instead
of dialer profile at R5, or put away the PPP multilink.
- Here is the partial config at R5:
interface BRI0
no ip address
encapsulation ppp
no ip route-cache
no ip mroute-cache
dialer pool-member 2
isdn switch-type basic-net3
no peer default ip address
no fair-queue
no cdp enable
ppp authentication chap callin
ppp multilink
!
interface Dialer1
ip address 140.4.56.1 255.255.255.252
encapsulation ppp
no ip route-cache
ip ospf hello-interval 5
ip ospf demand-circuit
no ip mroute-cache
dialer pool 2
dialer remote-name caller2
dialer idle-timeout 45
dialer string 12345678
dialer load-threshold 128 either
dialer-group 1
no peer neighbor-route
no peer default ip address
no fair-queue
pulse-time 0
no cdp enable
ppp authentication chap callin
ppp chap hostname cisco
ppp chap password 7 14141B180F0B7F
ppp multilink
!
!
access-list 1 permit any
dialer-list 1 protocol ip list 1
- Here is the show ip ospf interface:
Dialer1 is up, line protocol is up
Internet Address 140.4.56.1/30, Area 1
Process ID 100, Router ID 140.4.5.1, Network Type POINT_TO_POINT, Cost:
1562
Configured as demand circuit.
Run as demand circuit.
DoNotAge LSA allowed.
Transmit Delay is 1 sec, State POINT_TO_POINT,
Timer intervals configured, Hello 5, Dead 20, Wait 20, Retransmit 5
Hello due in 00:00:04
Index 1/1, flood queue length 0
Next 0x0(0)/0x0(0)
Last flood scan length is 1, maximum is 1
Last flood scan time is 0 msec, maximum is 0 msec
Neighbor Count is 1, Adjacent neighbor count is 1
Adjacent with neighbor 140.4.6.1 (Hello suppressed)
Suppress hello for 1 neighbor(s)
- Here is the debug line:
*Feb 7 09:46:03: BR0:1 DDR: disconnecting call
*Feb 7 09:46:04: Di1 DDR: ip (s=140.4.56.1, d=224.0.0.5), 132 bytes,
outgoing interesting (list 1)
*Feb 7 09:46:04: BR0 DDR: rotor dialout [priority]
*Feb 7 09:46:04: BR0 DDR: Dialing cause ip (s=140.4.56.1, d=224.0.0.5)
*Feb 7 09:46:04: BR0 DDR: Attempting to dial 12345678
*Feb 7 09:46:04: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1,
changed state to down
*Feb 7 09:46:04: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up
*Feb 7 09:46:04: %DIALER-6-BIND: Interface BR0:1 bound to profile Di1
*Feb 7 09:46:05: Di1 DDR: dialer protocol up
*Feb 7 09:46:06: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1,
changed state to up
*Feb 7 09:46:08: Di1 DDR: ip (s=140.4.56.1, d=224.0.0.5), 132 bytes,
outgoing interesting (list 1)
*Feb 7 09:46:09: Di1 DDR: ip (s=140.4.56.1, d=224.0.0.5), 132 bytes,
outgoing interesting (list 1)
*Feb 7 09:46:10: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to
12345678 R6
*Feb 7 09:46:54: Di1 DDR: idle timeout
*Feb 7 09:46:54: Di1 DDR: disconnecting call
*Feb 7 09:46:54: BR0 DDR: has total 0 call(s), dial_out 0, dial_in 0
*Feb 7 09:46:54: %DIALER-6-UNBIND: Interface BR0:1 unbound from profile Di1
*Feb 7 09:46:54: BR0:1 DDR: disconnecting call
*Feb 7 09:46:54: %ISDN-6-DISCONNECT: Interface BRI0:1 disconnected from
24388468 R6, call lasted 50 seconds
*Feb 7 09:46:55: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down
*Feb 7 09:46:55: BR0:1 DDR: disconnecting call
*Feb 7 09:46:55: Di1 DDR: ip (s=140.4.56.1, d=224.0.0.5), 132 bytes,
outgoing interesting (list 1)
*Feb 7 09:46:55: BR0 DDR: rotor dialout [priority]
*Feb 7 09:46:55: BR0 DDR: Dialing cause ip (s=140.4.56.1, d=224.0.0.5)
*Feb 7 09:46:55: BR0 DDR: Attempting to dial 12345678
*Feb 7 09:46:55: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1,
changed state to down
*Feb 7 09:46:56: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up
*Feb 7 09:46:56: %DIALER-6-BIND: Interface BR0:1 bound to profile Di1
*Feb 7 09:46:56: Di1 DDR: dialer protocol up
*Feb 7 09:46:57: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1,
changed state to up
*Feb 7 09:47:02: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to
12345678 R6
!@#@!#!@#!@#@!!@#@!#! 14 days to go.
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:56:55 GMT-3