05-23-2004 04:40 PM
I have configured a Cisco 7304 with DLSW and the remote peer is not a Cisco router. When the local peer in the Cisco is not configured as promiscuous, it takes about 20min to 1h30min for the peers to get connected.
If the local peer is configured as promiscous, it works good, but we dont want to use this configuration becasuse we want to control the connections on each router.
What can I do in order to solve this problem ?
Attached is the router configuration and the output of a "debug dlsw peers"
05-23-2004 04:45 PM
05-23-2004 11:39 PM
Why do you configure remote-peer as "passive"?
I'd configure remote-peer without 'passive' option and see what happens.
HTH
05-24-2004 04:45 AM
Hi,
can you provide a
debug dlsw peer
from the cisco router while it attempts to bring up the peer?
Also please provide a
show tcp
show dlsw cap
from the cisco router when the peer is up and running.
Is there any NAT/VPN inbetween the two dlsw routers?
thanks..
Matthias
05-24-2004 08:46 PM
05-24-2004 11:19 PM
Looking at your config I've seen there is no 'dlsw bridge-group' command configured at your router. I think you should configure it.
Also I've seen you are running IOS 12.2. There are a couple of bugs regarding to DLSW (TCP connection issues) which affects to some releases of IOS 12.2. Ckeck following to see if your IOS ver is affected:
http://www.cisco.com/en/US/products/sw/iosswrel/ps1831/products_field_notice09186a00800c8254.shtml
HTH
05-25-2004 06:11 AM
Hi,
based on the debug dlsw peer:
00:02:00: DLSw: START-TPFSM (peer 172.25.252.254(2065)): event:ADMIN-OPEN CONNECTION state:DISCONN
00:02:00: DLSw: dtp_action_a() attempting to connect peer 172.25.252.254(2065)
00:02:00: DLSw: END-TPFSM (peer 172.25.252.254(2065)): state:DISCONN->WAIT_WR
00:02:00: DLSw: Async Open Callback 172.25.252.254(2065) -> 11004
00:02:00: DLSw: START-TPFSM (peer 172.25.252.254(2065)): event:TCP-WR PIPE OPENED state:WAIT_WR
00:02:00: DLSw: dtp_action_f() start read open timer for peer 172.25.252.254(2065)
00:02:00: DLSw: END-TPFSM (peer 172.25.252.254(2065)): state:WAIT_WR->WAIT_RD
00:02:00: DLSw: passive open 172.25.252.254(2067) -> 2065
00:02:00: DLSw: START-TPFSM (peer 172.25.252.254(2065)): event:TCP-RD PIPE OPENED state:WAIT_RD
00:02:00: DLSw: dtp_action_g() read pipe opened for peer 172.25.252.254(2065)
00:02:00: DLSw: CapExId Msg sent to peer 172.25.252.254(2065)
00:02:00: DLSw: END-TPFSM (peer 172.25.252.254(2065)): state:WAIT_RD->WAIT_CAP
00:02:00: DLSw: START-TPFSM (peer 172.25.252.254(2065)): event:SSP-CAP MSG RCVD state:WAIT_CAP
00:02:00: DLSw: dtp_action_j() cap msg rcvd from peer 172.25.252.254(2065)
00:02:00: DLSw: Recv CapExId Msg from peer 172.25.252.254(2065)
00:02:00: DLSw: Pos CapExResp sent to peer 172.25.252.254(2065)
00:02:00: DLSw: END-TPFSM (peer 172.25.252.254(2065)): state:WAIT_CAP->WAIT_CAP
00:02:00: DLSw: START-TPFSM (peer 172.25.252.254(2065)): event:SSP-CAP MSG RCVD state:WAIT_CAP
00:02:00: DLSw: dtp_action_j() cap msg rcvd from peer 172.25.252.254(2065)
00:02:0
Torrejon0#0: DLSw: Recv CapExPosRsp Msg from peer 172.25.252.254(2065)
00:02:00: DLSw: END-TPFSM (peer 172.25.252.254(2065)): state:WAIT_CAP->WAIT_CAP
00:02:00: DLSw: Processing delayed event:SSP-CAP EXCHANGED - prev state:WAIT_CAP
00:02:00: DLSw: START-TPFSM (peer 172.25.252.254(2065)): event:SSP-CAP EXCHANGED state:WAIT_CAP
00:02:00: DLSw: dtp_action_k() cap xchged for peer 172.25.252.254(2065)
00:02:00: DLSw: closing read pipe tcp connection for peer 172.25.252.254(2065)
00:02:00: DLSw: END-TPFSM (peer 172.25.252.254(2065)): state:WAIT_CAP->PCONN_WT
00:02:00: DLSw: Processing delayed event:TCP-PEER CONNECTED - prev state:PCONN_WT
00:02:00: DLSw: START-TPFSM (peer 172.25.252.254(2065)): event:TCP-PEER CONNECTED state:PCONN_WT
00:02:00: DLSw: dtp_action_m() peer connected for peer 172.25.252.254(2065)
00:02:00: DLSw: END-TPFSM (peer 172.25.252.254(2065)): state:PCONN_WT->CONNECT
at this point the dlsw peer is in state CONNECTED
However you always get a tcp rst or fin right afterwards. Tcp tells dlsw to disconnect the peer.
This can have two potential sources.
The tcp stack on this router or the tcp stack on the remote router has closed the session.
00:02:00: DLSw: dlsw_tcpd_fini() for peer 172.25.252.254(2065)
00:02:00: DLSw: tcp fini closing connection for peer 172.25.252.254(2065)
00:02:00: DLSw: START-TPFSM (peer 172.25.252.254(2065)): event:ADMIN-CLOSE CONNECTION state:CONNECT
00:02:00: DLSw: dtp_action_b() close connection for peer 172.25.252.254(2065)
00:02:00: DLSw: END-TPFSM (peer 172.25.252.254(2065)): state:CONNECT->DISCONN
so the question really is where does the tcp rst come from? Who is closing the tcp connection?
This sequence repeats itself over and over again until it finally stays up.
You can do a
debug ip tcp driver
debug ip tcp transaction
this will show you if you get a disconnect or if this router is sending one. However you have to be a bit carefull with the debugging if you have a lot of tcp activity going on in this router.
Alternative is to take a sniffer trace on the WAN and find out who is sending the tcp reset/fin in that case.
thanks...
Matthias
05-25-2004 02:36 PM
05-25-2004 03:32 PM
05-26-2004 04:44 AM
Hi,
the tool limits the response to 4k. I have attached a file with the detailed response.
I belive the remote router is in failure. Based on your tcp debugging you see that the cisco router sends a RST, which is the closing of the second tcp pipe. Based on dlsw version 1, RFC 1795, that is what it is supposed to do if both routers agree on using a single tcp pipe, what they do in this case.
Than the one with the numerical hihger ip address has to close its tcp session on the local port 2065.
That is what the cisco does and right after that we receive a rst for the remaining session from the other end which kills the peer.
Please see the attached file for details.
thanks...
Matthias
05-26-2004 11:59 PM
I've seen very similar stuff with NAT in between, is there any in your setup?
05-26-2004 11:59 PM
I've seen very similar stuff with NAT in between, is there any in your setup?
05-30-2004 01:37 AM
No, there's no nat between the two routers.
I've seen something courius....I've changed the IP of the local peer in the Cisco Router to a lower address. Before that, they used DLSW v1, after that they use DLSW v2, why can it be possible ?
What do I hve to do now ? I'm concern about to fix my problem...
05-30-2004 07:16 AM
When the cisco router initiates the dlsw tcp session, the source TCP port number starts with 11000, and it's incrementing for every retry. Is it possible on the other router for some reason, it doesn't like certain port number, after a period of time retry, the TCP port changed to an acceptable number, the connection won't be RST. A similar debug to Cisco "debug tcp trans" from other router will help.
Thanks
Jing
05-30-2004 09:29 AM
here is the debug....
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide