DLSW peer takes 20 min. to establish..Please Help !!!

abekeris · ‎05-23-2004

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"

abekeris · ‎05-23-2004

Sorry, I forget to attach the configuration !!!!

jolmo · ‎05-23-2004

Why do you configure remote-peer as "passive"?

I'd configure remote-peer without 'passive' option and see what happens.

HTH

mbinzer · ‎05-24-2004

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

abekeris · ‎05-24-2004

No NAT/VPN is between the tho routers, only a Frame Relay link.

Attached are the files with the debug and the show TCP and show dls cap.

Thanks,

jolmo · ‎05-24-2004

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

mbinzer · ‎05-25-2004

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

abekeris · ‎05-25-2004

Hi, thanks for your help....here is the debug ip tcp driver" and the "debug ip tcp transactions"

It looks like the Cisco router sends the rst. This only happend when the local-peer is not configured as promiscuous.

Thanks,

Algis

abekeris · ‎05-25-2004

more debug's....

mbinzer · ‎05-26-2004

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

jonathanstevens · ‎05-26-2004

I've seen very similar stuff with NAT in between, is there any in your setup?

jonathanstevens · ‎05-26-2004

I've seen very similar stuff with NAT in between, is there any in your setup?

abekeris · ‎05-30-2004

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...

jishi · ‎05-30-2004

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

abekeris · ‎05-30-2004

here is the debug....