Buy or Renew
Buy or Renew
Cisco + Splunk: It’s a new day for your data. Learn more.
 
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
cancel
Start a conversation
2699
Views
0
Helpful
5
Replies

Cisco ACE and MTU modification

cisco24x7
Level 6
Level 6

‎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.

Labels:
Preview file
15 KB
0 Helpful
5 Replies 5

Gilles Dufour
Cisco Employee
Cisco Employee

‎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.

0 Helpful

cisco24x7
Level 6
Level 6
In response to Gilles Dufour

‎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.

0 Helpful

ggalteroo
Level 1
Level 1
In response to cisco24x7

‎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

0 Helpful

Gilles Dufour
Cisco Employee
Cisco Employee
In response to ggalteroo

‎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

0 Helpful

ggalteroo
Level 1
Level 1
In response to Gilles Dufour

‎06-01-2010 05:10 PM

Thanks!

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

Thanks again.

Guido

0 Helpful
Getting Started

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:

Customers Also Viewed These Support Documents