my topology like this
use static route on R1 and R2
for dlsw configuration
dlsw local peer-id 10.1.1.1
dlsw remote 0 tcp 10.2.2.2 keepalive 0 timeout 90 dynamic
dlsw bri 1
bridge 1 pro ieee
dlsw remote 0 tcp 10.1.1.1 keepalive 0 timeout 90 dynamic
and the Dlsw peer status is CONNECT now. and ISDN is flapping.
What does your ISDN configuration look like? What did you define as interesting traffic.
ip address 192.168.0.1 255.255.255.0
dialer idle-timeout 30
dialer map ip 192.168.0.2 name R2 broadcast 22222
isdn switch-type basic-net3
no cdp enable
dialer-list 1 proto ip permit
I guess the problem is " dialer idle-timeout 30", (I set to 30 seconds because I can get the result quickly, I dont need to wait for 120 seconds or others)but for dlsw, I configurate the timeout is "20" and I tried "40", still flapping.
The keepalive is 0 on the dlsw remote statement. If there is no DLSW traffic for 30 seconds the ISDN connection will be torn down. You can always increase the dialer idle-timeout. I can't see other ways around this issue.
Hope this helps,
I increased the dialer idle-timeout to 90 and to 120 and to 150, and still flapping. I got information from cisco.com, it should not be flapping, because the keepalive is set to 0
Just like BGP(run BGP between R1 and R2 over ISDN only), I post the BGP over ISDN before, no solution. because for BGP, cisco doesn't provide IOS command like "ip BGP demand-circuit", so the BGP keepalive is not been supressed.
I hate ISDN, I hope no ISDN in the market. ISDN is a trouble-maker
You are correct that this can't be done with BGP but it should certainly be possible for DLSW. I think that the reason your link keeps coming up is that some other than DLSW is causing it to do so. Make sure your dialer-list only allows traffic expected to trigger the connection. You can also use the "show dialer" command to verify what traffic is causing the connection get established.
Hope this helps,
because the topology is so simply, I use static route, no dynamic routing, so no other traffice, only dlsw.
for the ISDN, the default idle-timeout is 120s and the dlsw keepalive is 30s, and in 90s by default if no dlsw keepalive, the peer will disconnect.
so, after everything is done, dlsw peer status is "connect"(assume it takes 40s). 120s later, the ISDN is down, (40s+30s+some seconds) later, R1 send the dlsw keepalive to R2, and ISDN is up, in this 120s, isdn is up and dlsw is connected. after ISDN down again, dlsw bring it up again. again and again.
so if we set keepalive=0, it seems a good idea, because dlsw doesn't connect/disconnect by the keepalive. but in fact, it is still flapping.
I don't know how "dialer-watch" works, maybe I can get something from "dialer-watch". (no watch needed in this topology)
for the "show dialer", the dialer reason is
(source 10.1.1.1, dst 10.2.2.2), so that is dlsw
The output of the "show dialer" command seems to indicate that there is actual traffic needing the DLSW session to be up therefore causing the ISDN link to come up.
I am still thinking about the BGP.
After everything is done, IGP is ok. and ISDN is ok too with "ip ospf demand-circuit". right now, ISDN no flapping because primary link works well.
then run BGP, ISDN still no flapping because BGP traffic are on the primary link.
if the primary link is down, the ISDN will be up, and all IGP(OSPF) traffic will be on the ISDN link, if no data, then the OSPF hello will be suppressed. the ISDN is down, but we can see all routes.
at this moment, how about BGP? BGP will bring up the ISDN and ISDN flapping?
I think in real world, nobody use ISDN to backup BGP, but in lab, it is possible
Not if you don't define BGP as interesting traffic in the dialer-list. If you do though, BGP will keep the link up for as lonk as the primary link is down.