• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

Commonly used MTU on ATM interface?

Mucman

Diamond Member
Just curious... ours is 4470, but a customer complained about their streaming media breaking because ours is
set higher than 1500.
 
Spidey07, I know absolutely nothing about ATM 🙁

c7204-vxr#show int atm1/0
ATM1/0 is up, line protocol is up
Hardware is ENHANCED ATM PA
MTU 4470 bytes, sub MTU 4470, BW 149760 Kbit, DLY 80 usec,
reliability 255/255, txload 17/255, rxload 3/255
Encapsulation ATM, loopback not set
Keepalive not supported
Encapsulation(s): AAL5
4096 maximum active VCs, 1 current VCCs
VC idle disconnect time: 300 seconds
0 carrier transitions
Last input 00:00:00, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/100/53503 (size/max/drops/flushes); Total output drops: 7390932
Queueing strategy: Per VC Queueing
5 minute input rate 1908000 bits/sec, 1067 packets/sec
5 minute output rate 9994000 bits/sec, 1540 packets/sec
761974208 packets input, 1349889598 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
1123001004 packets output, 382049616 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 output buffer failures, 0 output buffers swapped out
c7204-vxr#
 
Well, our ATM interfaces all use an MTU of 4470 as well ... and yea, ATM cells are 53 bytes (48 byte payload), but the MTU is not on an "ATM interface", rather it is on the endpoint of an ATM vcc. So ... MTU is not really applied at the interface level for ATM, but rather at the vcc level, and then only for AALs that require an MTU (i.e. AALs that carry data). Assuming he's using AAL5, there is an MTU.

Edit - According to rfc 1626, IPoATM+AAL5 MTU is supposed to be 9180.
Edit 2 - Cisco uses a default value of 4470 to match up with FDDI and HSSI MTUs to avoid fragmentation.

randal
 
Ahh... thanks. I showed your post to my boss and he explained a bit to me. I understand that the MTU data is encapsulated over the ATM connection, and the MTU isn't a part of ATM itself.
 
ATM interface MTUs should be 9180 unless you have some specific reason to do otherwise, see the RFC.
In the darkness of time, Cisco picked 4470 (long story) for their interfaces and for backwards compatibility they keep that as the default. Therefore, both ends of the line need to be explicitly configured for 9180.

>but a customer complained about their streaming media breaking because ours is set higher than 1500.

Teach your customers about path MTU discovery. I assume that your customer's application originates on ATM and ends up somewhere else, and they're complaining because the packets end up coming in fragmented? Because if all you're doing is being the middle and the ends are both 1500, then there's no good reason why your MTU being higher should matter.

I'm very sympathetic to arguments that the 'net would be a happier place if everyone just used 1500 as their MTU. But (a) that's bad for high-speed (ca. gigabit) performance and (b) that's already way out of touch with today's operational reality, where PPPoE and IPsec and serial links are all over the place.
 
Back
Top