cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1361
Views
0
Helpful
1
Replies

CLNS over GRE

epeeler
Level 1
Level 1

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

1 Reply 1

Adrian Coto
Level 1
Level 1

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