Cisco ACE and MTU modification

Unanswered Question
Jun 6th, 2008
User Badges:
  • Silver, 250 points or more

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.



Attachment: 
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Gilles Dufour Sat, 06/07/2008 - 19:15
User Badges:
  • Cisco Employee,

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.

cisco24x7 Sun, 06/08/2008 - 04:59
User Badges:
  • Silver, 250 points or more

Gilles,


Thanks for the info. I will provide an update

tomorrow.


I already disable tcp normalization with

"no norm" but the problem still persists.






ggalteroo Fri, 05/28/2010 - 15:07
User Badges:

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

Gilles Dufour Tue, 06/01/2010 - 00:45
User Badges:
  • Cisco Employee,

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

ggalteroo Tue, 06/01/2010 - 17:10
User Badges:

Thanks!

When loadbalanced, it worked just fine. I was able to reach jumbo.


Thanks again.

Guido

Actions

This Discussion