DLSW and priority

[jabouaf]

Hello,

I have some questions regarding the TCP sessions managed by DLSW.

A customer is using DLSW with priority between two routers.

He's also using sap-priority-list.

The high priority telnet session (2065) isn't used by SNA traffic regarding the sap-priority-list (for this remote router).

(Others remotes DLSW-peers use the high priority telnet session)

sap-priority-list 1 medium ssap 4 dsap 4

sap-priority-list 1 low ssap F0 dsap F0

dlsw bridge-group 14 sap-priority 1

1) Can someone confirm that the 4 TCP sessions are linked together: i.e. that if TCP(2065) is dropped the 3 others fall down too?

2) Which one of the 4 TCP sessions is used to send TCP-keepalive packets for the 4 of them ?

TCP 2065 ?

3) Is the TCP-keepalive timer link to the release ?

regarding the sap-priority-list there should be no SNA traffic on TCP(2065) on this one, and there is only a keepalive sent every one or every two hours (see with a sniffer) !

Would someone thinks that could be a bug ?

4) Regarding the use of a promiscous definition, does someone know the delay to send DLSW-TCP-keepalive ?

the peers with static and promicous definition seem to have differents timers. Can someone confirm that ?

Regards,

[jishi]

1) Depends on how you config the queueing on the interface for DLSw peer connection, normally it's the WAN interface.

"sap-priority" and "dlsw priority" are just for mapping the saps to the TCP ports for the L2 traffic coming into the DLSw router, after the traffic being encapsulated into TCP packets, how do you want to prioritize the TCP traffic will depend on the queueing on the "outgoing" WAN interface.

2) I saw in the trace, DLSw uses 2065 for sending keepalives.

3) Never heard of the keepalives are linked to releases.

DLSw keepalive is used by the DLSw peers. As long as there is user traffic flowing between DLSw peers, no matter is between port 1981, 1982, 1983 or 2065, the keepalive will not be sent. Only no dlsw traffic flowing at all, the keepalive will be sent every 30s.

Are you saying there is no dlsw traffic at all and the default keepalive timer not been changed, you only saw the keepalive once every 1 or 2 hours? The peer really should be dropped.

4) DLSw keepalive should not have anything to do static and promicous definition. These definitions are only for "initiating" the TCP session, not for "keeping" the session.

If you have further question, can you please post your config, the platform and the level of IOS you are running, I can try in my lab.

Thanks

Jing

[jabouaf]

Hello Jing,

Thank you for your responses .Most of them confirm what I think but I was not sure.. In this customer situation, I think that most traffic isn't end in TCP high but in the medium and normal ones.

But I still have to check some configuration part.

Using a very old router (DLSW promiscous definition) in a small lab (no SNA nor netbios traffic at all)

I saw that some time to time the delay to send keepalive request isn't always 30s, but this is in a lab without the hardware/release configuration as my customer.

And for political reason I do have to open a case.

There is some time to time TCP(DLSW) sessions drop. and I wanted to check some idear before opening it.

Do you have access to TAC case information ?

Best Regards,

Jean-david

[jishi]

Hi Jean-David,

You can do "deb dlsw peer" and "deb tcp trans" on both dlsw routers. They will help on finding out why the peer was dropping. If you have the WAN sniffer trace, that will be the best.

If you need to open a case, please attach the show tech from both dlsw routers, the debugs or the sniffer trace which have the problem captured to the case, and you can put my name there, I will pickup the case.

Thanks

Jing

[jabouaf]

Hello Jing,

Thank you for offering to have a look at my case. But

I already opened the case yesterday.

I really do appreciate your suggestion.

It is handled by Stanislav.

If you want to have a look too at the sniffer traces, then you can send me a mail so I could response with the case number.

The customer hasn't yet done any debug, but I think there is some think in the sniffers traces.

Best Regards.

Jean-david

jean-david.abouaf@arche.fr