04-16-2013 01:53 PM - edited 03-04-2019 07:37 PM
I'm having an issue with clns being tunneled over GRE.
Connectivity is there and I can see the clns neighbor over the Tunnel interface. The testers at the remote site
are reporting that they are able to transfer small files from their server to the network elements here
but larger files are failing. Files of 400 bytes pass but the 200K files are failing.
When I do a clns ping between my tunnel router and the remote end, any packet sizes greater than 1415 are having
a success rate in the 30% range. Packet sizes of 1415 or lower are 100% successful.
This seems like an MTU issue to me but I'm not sure the best way to solve it. I'm not a CLNS expert by any means.
Do I need to have them adjust the mtu size at their nodes?
interface Tunnel0
bandwidth 1536
no ip address
no ip route-cache
======================================
Tunnel0 is up, line protocol is up
Hardware is Tunnel
Description: Tunnel to Richardson Planning Joe Peters -- Deepak
MTU 17912 bytes, BW 1536 Kbit/sec, DLY 50000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation TUNNEL, loopback not set
Keepalive not set
Tunnel source x.x.x.x (FastEthernet0/1), destination x.x.x.x
Tunnel Subblocks:
src-track:
Tunnel0 source tracking subblock associated with FastEthernet0/1
Set of tunnels with source FastEthernet0/1, 1 member (includes iterators), on interface <OK>
Tunnel protocol/transport GRE/IP
Key disabled, Order sequence numbers 258877/4652319 (tx/rx)
Checksumming of packets disabled
Tunnel TTL 255, Fast tunneling disabled
Tunnel transport MTU 1472 bytes
Tunnel transmit bandwidth 8000 (kbps)
Tunnel receive bandwidth 8000 (kbps)
Last input 00:00:05, output 00:00:02, output hang never
Last clearing of "show interface" counters 5d03h
Input queue: 0/75/2046/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/0 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
83902 packets input, 9303766 bytes, 0 no buffer
Received 0 broadcasts (0 IP multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
129873 packets output, 91287366 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 unknown protocol drops
0 output buffer failures, 0 output buffers swapped out
clns router isis ROUTERNAME
tunnel source FastEthernet0/1
tunnel destination x.x.x.x
tunnel sequence-datagrams
tarp enable
04-17-2013 05:19 PM
Hello Epeeler
Several ideas:
Different packet sizes may get different treatment from the network. (Some old QoS methods, Packet buffer starvation...)
I think it is a good idea to test at IP level if there are transit problems for some packet sizes (large ping tests from tunnel IP source to tunnel IP destination with DF bit set, with different packet sizes). Which is the end to end IP MTU?
Is the packet delivery consistent across different hours? days?
I think it is a good idea to chech the IOS version of your routers. Are there any open caveats related to CLNS, GRE, GRE Packet Fragmentation and Reassembly...?
I think it is a good idea to standarize the CLNS MTU accross the network, including LAN and WAN links.
It is also a good idea to avoid the fragmentation of GRE encapsulated packets. This will require IP MTU > CLNS MTU, and may not be possible on all cases.
Selecting a CLNS MTU is not trivial. Different application may have different behavior. Check with application owner for specific MTU requirements. Lab testing is key. Test, Test, Test....
Regards,
Adrian
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide