<br>
== Page info ==
This page is created to address issues with TCP performance through the FWSM. Specifically the effects of Selective ACK (SACK) in conjunction with TCP Sequence Number Randomization.
== Troubleshooting ==
Packet captures taken simultaneously from both sides of the FWSM are required to properly identify how the FWSM is affecting traffic flow. Ideally, the captures will be taken by spanning the ingress and egress vlans. Alternatively, captures can be run directly on the client and server.
== Defining the Problem ==
How does Selective ACK work? Normally TCP packets will be sent in order. Assume the diagram below represents the TCP segments and each segment has 10 bytes of data. So Segment 1 would have bytes 1-10, Segment 2 would have bytes 11-20, and ACK 1 Acknowledges bytes 1-10, ACK 2 Acknowledges bytes 11-20, etc.
'''SEQ''' |---1---||---2---||---3---||---4---||---5---|
'''ACK''' <font color="blue">|1------||2------||3------||4------||5------|</font>
But what happens when packets are out of order? Take the following example:
'''SEQ''' |---1---||---3---||---4---||---5---|'''<font color="red">|---2---|</font>'''
Normally, the client will Acknowledge the last byte of data received from the server. This means that the ACK number will be the Sequence number of the next data packet the client expects to receive. Notice that packet #2 was sent out of order above. Without SACK, the ACKs will most likely be sent by the OS like so:
'''SEQ''' |---1---||---3---||---4---||---5---||---2---|
'''ACK''' <font color="blue">|1------|</font>'''<font color="red">|2------||2------||2------|</font>'''<font color="blue">|5------|</font>
In many cases, when the server receives these ACKs, it will begin retransmitting data it thinks may have been lost. So when it receives the second ACK for #2, it will begin resending data at that point and send segments 2,3,4, and 5 a second time. The client will then receive all the data AGAIN even though it is not necessary.
When using SACK, the client can ACK for a specific range of data. This allows the server to only retransmit was hasn't been received.
<br>
'''SEQ''' |---1---||---3---||---4---||---5---||---2---|
'''ACK''' <font color="blue">|1------||3------||4------|</font>'''<font color="red">|2------|</font>'''<font color="blue">|5------|</font>
<br>
In this case, the server may choose to retransmit segment 2.
== Fixing the problem ==
The issue is most likely due to the Selective ACK. By default, the FWSM does not remove the SACK option from TCP streams. We do, however, randomize TCP Sequence numbers. This is fine so long as you do not experiencing any packet loss or out-of-order packets. When the sender needs to resend data that has been selectively ACKed, the FWSM does not translate the sequence numbers properly and data can be slowed or even stopped.
To remedy this, you have two options.
=== Option 1 ===
Leave Selective-ACK enabled and disable tcp sequence number randomization. Example
access-list no_tcp_seq_rand_acl permit tcp x.x.x.0 255.255.255.0 y.y.y.0 255.255.255.0
!
class-map no_tcp_seq_rand_class
match access-list no_tcp_seq_rand_acl
!
policy-map global_policy
class no_tcp_seq_rand_class
set connection advanced-options tcp-state-bypass
=== Option 2 ===
Strip the SACK flag from TCP flows through the FWSM. Example:
no sysopt connection tcp sack-permitted
*Note: this command was added in versions: 3.1(12)/3.2(8)/4.0(3).
== Additional Details ==
[[Category:FWSM]] [[Category:Brquinn]] [[Category:Troubleshooting]]
