topic Re: Bug within the fwsm? in Network Security

Bug within the fwsm?

pd.politiet.no — Mon, 11 Mar 2019 16:36:35 GMT

I have this problem with slow performance one way copying files from one server to another.

Iperf also shows this performance.

Server1 is connected to a 3560 giga-port in vlan 670, and there is a 1 gig trunk to a 6509.

The 6509 is configured with vrf and fwsm, and this is connected to another 6509 with at 10 gig trunk.

In this last 6509 the other server is connected in vlan 650.

Vlan 650 and 670 belongs to different vrf's, and needs to go thru the fwsm.

One way shows nice perfomance (iperf shows 800-900Mbit/s), but the other way is about half the performance.

There is big and difficult configuration on the switches or the fwsm.

Why does it behave like this?

The accessports are configured auto/auto and has 1000/full, the trunks is a dot1q trunks and the fwsm is permitting ip any any.

Could there be a bug in the fwsm (or is it related to the switches)?

Could it be some buffer problem in the fwsm? The configuration of the fwsm is rather plain allowing any-any ip.

server1(vlan650/vrf storage)-3560-6509-fwsm-6509-server2(vlan 670/vrf client)

The first 6509 has the fwsm installed.

Oh.. having the servers in the same VRF's og VLAN does not give this reduction in performance one way. Doing this makes good performance.

Geir

Re: Bug within the fwsm?

Kureli Sankar — Sat, 21 Nov 2009 04:31:40 GMT

Pls. check this article if your server specification matches.

 
Turn off TCP Chimney by using the Netsh.exe tool by following these steps:

1. Click Start, click Run, type cmd, and then click OK.

2. At the command prompt, type Netsh int ip set chimney DISABLED, and then press ENTER.

If you want to read further information about this issue, you can consult the following
link from Microsoft Technet:


http://support.microsoft.com/?kbid=912222

Also, pls. take a look at this defect CSCsj56795 here: http://tools.cisco.com/Support/BugToolKit/ 
and upgrade the code to the latest inerim and implement the fix

sysopt np completion-unit

test the file copy again.

Re: Bug within the fwsm?

pd.politiet.no — Tue, 08 Dec 2009 14:27:44 GMT

>Turn off TCP Chimney

The Windows server 2008 R2 Enterprise does not have this command. So I cannot disabled tcp chimney. Unless there is another command to use.

>upgrade the code to the latest inerim and implement the fix
The fwsm has been upgraded to the latest release and the "sysopt np completion-unit" has been implemented.

Status is that there is no differense in the file copy. One way throughput is ok, the otherway the throughput is a litle over half the speed.

So in other word, no changes.

Geir

Re: Bug within the fwsm?

Kureli Sankar — Tue, 08 Dec 2009 23:02:25 GMT

If you have smartnet I suggest that you open a TAC case. We need to collect captures and see.

Do you know if SACK is negotiated by the host? If so, you can disable that by the keyword "noramdomseq" in the tail end of the static line and see if that works.

-KS

Re: Bug within the fwsm?

pd.politiet.no — Wed, 09 Dec 2009 08:58:40 GMT

SACK is negogotiated between the hosts.

What you mean with the norandomseq is putting it at the end of the nat-line? like this:

nat (inside) 0 access-list inside_exeption norandomseq

The config on the fwsm is for the moment very simple. It allows all trafikk between the different interfaces and doesn't do any NAT.

But as for the cisco information of this command, it says not use this option unless you have another firewall inline. I only have traffic traffic traversing the fwsm in the 6509.

Geir

Re: Bug within the fwsm?

Kureli Sankar — Thu, 10 Dec 2009 16:13:10 GMT

I don't believe the norandomseq takes effect in the nat exemption line.

Pls. add identity static and add the keyword in the end. Clear local for the two involved IP addresses and try the flow again.

-KS