DLSw & IP CEF

[deanyoung]

Hi,

I am running IP CEF on a 2621XM router. The router has 2 x 960Kbps lines connecting to a data center. The line utilization never exceeds 80% utilization, but I keep on getting WAN_BUSY on the data center router (7513 with CIP).

The 7513 runs IOS 12.1(18) and the 2621XM runs IOS 12.2(16B).

The following IP CEF commnads have been configured on the 2621:

ip cef accounting load-balance-hash

interface Serial0/0

ip load-sharing per-packet

interface Serial0/1

ip load-sharing per-packet

Data Center router output:

Router2#sh dls p ip 10.176.1.137

Peers: state pkts_rx pkts_tx type drops ckts TCP uptime

TCP 10.176.1.137 WAN_BUSY 85481 532069 conf 0 48 36 03:07:16

Router2#sh dls p ip 10.176.1.137

Peers: state pkts_rx pkts_tx type drops ckts TCP uptime

TCP 10.176.1.137 WAN_BUSY 85486 532069 conf 0 48 10 03:07:16

Router2#sh dls p ip 10.176.1.137

Peers: state pkts_rx pkts_tx type drops ckts TCP uptime

TCP 10.176.1.137 WAN_BUSY 85488 532192 conf 0 48 108 03:07:17

Router2#sh dls p ip 10.176.1.137

Peers: state pkts_rx pkts_tx type drops ckts TCP uptime

TCP 10.176.1.137 WAN_BUSY 85491 532192 conf 0 48 66 03:07:17

Router2#sh dls p ip 10.176.1.137

Peers: state pkts_rx pkts_tx type drops ckts TCP uptime

TCP 10.176.1.137 WAN_BUSY 85493 532192 conf 0 48 50 03:07:17

Router2#sh dls p ip 10.176.1.137

Peers: state pkts_rx pkts_tx type drops ckts TCP uptime

TCP 10.176.1.137 WAN_BUSY 85493 532192 conf 0 48 37 03:07:18

Router2#sh dls p ip 10.176.1.137

Peers: state pkts_rx pkts_tx type drops ckts TCP uptime

TCP 10.176.1.137 WAN_BUSY 85497 532192 conf 0 48 4 03:07:18

Router2#sh dls p ip 10.176.1.137

Peers: state pkts_rx pkts_tx type drops ckts TCP uptime

TCP 10.176.1.137 WAN_BUSY 85500 532355 conf 0 48 134 03:07:18

Router2#sh dls p ip 10.176.1.137

Peers: state pkts_rx pkts_tx type drops ckts TCP uptime

TCP 10.176.1.137 WAN_BUSY 85500 532355 conf 0 48 111 03:07:19

Router2#sh dls p ip 10.176.1.137

Peers: state pkts_rx pkts_tx type drops ckts TCP uptime

TCP 10.176.1.137 WAN_BUSY 85504 532355 conf 0 48 96 03:07:19

Router2#sh dls p ip 10.176.1.137

Peers: state pkts_rx pkts_tx type drops ckts TCP uptime

TCP 10.176.1.137 WAN_BUSY 85504 532355 conf 0 48 63 03:07:19

Router2#sh dls p ip 10.176.1.137

Peers: state pkts_rx pkts_tx type drops ckts TCP uptime

TCP 10.176.1.137 WAN_BUSY 85509 532355 conf 0 48 7 03:07:20

Regards

Dean

[mbinzer]

Hi,

WAN_BUSY means that you have a certain amount of packets in the tcp queue of the dlsw peer.

By default the tcp queue is 200 packets. If you reach 50% of the queue depth the peer goes to WAN_BUSY. You get out of WAN_BUSY when you go below 25% of the queue depth with the actual number of queueud packets.

WAN_BUSY is flow control for dlsw, once you are in that state the router that has a peer in this status will send RNR's to all local llc2 or sdlc resources to throttle them back since he can not send over that peer.

So the question's are:

Do you have congestion on the tcp link between the two dlsw peers?

Does the peer in WAN_BUSY get out of it and continue after a little bit of time?

What you might want to check to start with.

show tcp

for the dlsw peer connection in question on both routers. Look for out of order, retransmissions ect. Also check the tcp mss. Assuming that you have a WAN with mtu 1500 and you use loopback interfaces as local peers, than your tcp mss should be 1460. If it is 536 you need to enable

ip tcp path mtu discovery

on both routers and recycle the tcp seesion. A smaller than optimal tcp mss is a performance hit.

A

show dlsw cir detail

for the circuits over this connection also gives you information about the per circuit flow control which may happen. Ther are counters for Flow op showing Half and Reset

operators. It is always send/received.

If you get any of those than you also have an issue with a per dlsw circuit flow control and it needs to be understood why those are generated.

Start with looking at the tcp sessinos of the two peer routers.

thanks...

Matthias

[deanyoung]

Hi Matthias,

Thanks for the information. I did change the MTU discovery previously and am making use of an mtu of 1460.

What I did discover is that I only get WAN_BUSY on the DLSw peers to branches that have 2 access-links connected to them.

I make use of OSPF and to see if the dual paths are the problem I implemented static routes between the 2 locations. I will see if this resolved the problem.

Regards

Dean