06-06-2008 06:02 PM
Can someone help me out here?
I have an ACE operating in Layer-3 mode, behind a Checkpoint firewall.
I've attached a network diagram as well. All my hosts are Redhat
Linux Enterprise Server version 3
From Linux_1, I can sFTP and scp upload/download files with Linux_2
without any issues.
From Linux_1 console I can upload files via sFTP and scp to Linux_3,
which is behind the Cisco ACE. However, from Linux_1 console, I can
NOT download files via sFTP and scp from Linux_3.
From Linux_2 console I can upload files via sFTP and scp to Linux_3,
which is behind the Cisco ACE. However, from Linux_2 console, I can
NOT download files via sFTP and scp from Linux_3.
The only way for it to work, from Linux_1 and Linux_2 consoles, to
download files from Linux_3, is to modify the MTU on either Linux_1,
Linux_2 or Linux_3 MTU to something less than 1496. Anything
above 1496 will break down the download.
I know ACE causes this issue because if I replaced ACE with either
F5 BigIP or Citrix netscaler, the issue goes away.
Is there a workaround for this on the ACE without modifying the MTU?
Thanks in advance.
06-07-2008 07:15 PM
I would suggest to take a sniffer trace on src and dst at the same time and see what is going on.
I don't think the MTU is involved here.
But the MSS could be.
You can do a 'show np 1 me-stats "-snorm"' and see if there is any drop.
switch/Admin# sho np 1 me-stats "-snorm -v" | i xce
[Drops] fp TCP exceeded MSS: 0 0
switch/Admin#
You could try to disable tcp normalization on every interface with the command 'no norm'.
But normalization is there to detect anomalies. A sniffer trace should be the first step to identify the problem.
Gilles.
06-08-2008 04:59 AM
Gilles,
Thanks for the info. I will provide an update
tomorrow.
I already disable tcp normalization with
"no norm" but the problem still persists.
05-28-2010 03:07 PM
Hello
I’m stepping it since I believe I have a MTU-related problem.
I’m running ACE version A2(3.1) and I’m not able to ping the interface beyond the default MTU size of 1500. The ping is sourced on a VLAN interface lying on a Cat6500 Sup720. There is no wiring. Only the two logical interfaces.
The interface from 6500 is like:
interface Vlan20
mtu 9216
ip address 10.30.2.250 255.255.255.0
end
The interface from ACE is like:
interface vlan 20
ip address 10.30.2.251 255.255.255.0
mtu 9216
no normalization
fragment chain 7
fragment min-mtu 28
fragment timeout 3
no icmp-guard
service-policy input JUMBO
no shutdown
parameter-map type connection JUMBO
set tcp mss min 0 max 9216
exceed-mss allow
policy-map multi-match JUMBO
class JUMBO
connection advanced-options JUMBO
I realize that some of the parameter-map settings won’t apply to icmp. Fragments were just another try. No change with default values.
Is this of any help? I’m not positive the increase of this value is related to MTU.
ACE-Lab/Admin# show np 1 me-stats "-sdrop -v" | in "DROP: RX Interface miss:"
DROP: RX Interface miss: 1310
ACE-Lab/Admin# show np 2 me-stats "-sdrop -v" | in "DROP: RX Interface miss:"
DROP: RX Interface miss: 1469
The ACE is pretty much idle and so is the 6500.
A ping from the 6500 shows:
R_BSAS_MAI316_6500#ping 10.30.2.251 repeat 1 size 1600
Type escape sequence to abort.
Sending 1, 1600-byte ICMP Echos to 10.30.2.251, timeout is 2 seconds:
.
Success rate is 0 percent (0/1)
A capture on ACE shows:
ACE-Lab/Admin# capture ICMP start
ACE-Lab/Admin# 20:33:31.236548 0:6:d6:35:a4:0 0:1d:45:f8:f2:5d 0800 1614: 10.30.2.250 > 10.30.2.251: icmp: echo request (ttl 255, id 559, len 1600)
The ACL ruling the capture is as follows:
access-list ICMP line 8 extended permit icmp any host 10.30.2.250
access-list ICMP line 16 extended permit icmp host 10.30.2.250 any
Another try:
R_BSAS_MAI316_6500#ping 10.30.2.251 repeat 1 size 1500
Type escape sequence to abort.
Sending 1, 1500-byte ICMP Echos to 10.30.2.251, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 1/1/1 ms
R_BSAS_MAI316_6500#ping 10.30.2.251 repeat 1 size 1600
Type escape sequence to abort.
Sending 1, 1600-byte ICMP Echos to 10.30.2.251, timeout is 2 seconds:
.
Success rate is 0 percent (0/1)
R_BSAS_MAI316_6500#ping 10.30.2.251 repeat 1 size 9216
Type escape sequence to abort.
Sending 1, 9216-byte ICMP Echos to 10.30.2.251, timeout is 2 seconds:
.
Success rate is 0 percent (0/1)
R_BSAS_MAI316_6500#ping 10.30.2.251 repeat 1 size 9500
Type escape sequence to abort.
Sending 1, 9500-byte ICMP Echos to 10.30.2.251, timeout is 2 seconds:
.
Success rate is 0 percent (0/1)
On ACE:
21:06:31.854939 0:6:d6:35:a4:0 0:1d:45:f8:f2:5d 0800 1514: 10.30.2.250 > 10.30.2.251: icmp: echo request (ttl 255, id 619, len 1500)
21:06:31.855418 0:1d:45:f8:f2:5d 0:6:d6:35:a4:0 0800 1514: 10.30.2.251 > 10.30.2.250: icmp: echo reply (ttl 128, id 9241, len 1500, bad cksum 9985!)
21:06:35.717979 0:6:d6:35:a4:0 0:1d:45:f8:f2:5d 0800 1614: 10.30.2.250 > 10.30.2.251: icmp: echo request (ttl 255, id 620, len 1600)
21:06:42.525308 0:6:d6:35:a4:0 0:1d:45:f8:f2:5d 0800 9230: 10.30.2.250 > 10.30.2.251: icmp: echo request (ttl 255, id 621, len 9216)
21:06:46.742456 0:6:d6:35:a4:0 0:1d:45:f8:f2:5d 0800 9514: 10.30.2.250 > 10.30.2.251: icmp: echo request (ttl 255, id 622, len 9500, bad cksum 5b62!)
There is no response from ACE whenever MTU is bigger than 1500. I’m hitting the VLAN interface but the VIP behaves the same way.
I’m hoping to set bigger MTUs in order to shortly support DNSSEC.
The 6500 works as expected.
interface Vlan20
mtu 9216
ip address 10.30.2.250 255.255.255.0
end
R_BSAS_MAI316_6500#ping 10.30.2.250 size 10000 df-bit
Type escape sequence to abort.
Sending 5, 10000-byte ICMP Echos to 10.30.2.250, timeout is 2 seconds:
Packet sent with the DF bit set
.....
Success rate is 0 percent (0/5)
R_BSAS_MAI316_6500#ping 10.30.2.250 size 10000
Type escape sequence to abort.
Sending 5, 10000-byte ICMP Echos to 10.30.2.250, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/7/8 ms
R_BSAS_MAI316_6500#ping 10.30.2.250 size 9000 df-bit
Type escape sequence to abort.
Sending 5, 9000-byte ICMP Echos to 10.30.2.250, timeout is 2 seconds:
Packet sent with the DF bit set
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/4 ms
Any ideas?
Thanks a lot!
Guido
06-01-2010 12:45 AM
Pings are handled differently onj ACE. It's not loadbalanced and instead it sent directly to the control plane.
Therefore, testing ping with a size greater than MTU is meaningless.
Ping should just be used to see if the box is alive.
Moreover, to protect the control plane I believe we drop large ping packets.
(I would have to doublecheck)
Gilles
06-01-2010 05:10 PM
Thanks!
When loadbalanced, it worked just fine. I was able to reach jumbo.
Thanks again.
Guido
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: