Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

mGRE packet drops

I have an mGRE tunnel configured between 6504 switches ( running IOS12.2(18)SXF7). The two switchs are at remote sites with an IPSec tunnel connecting the 2 sites.

My issue is that I am seeing Output drops on the Tunnel interface, which is usually associated with failed network connection or data transfers. While the load level on the interface looks to be pretty minimal. This looks to be leading to lost connections during large data transfers and application connections that tend to send large data packets.

I have tried setting the MTU size to 1400 on the Tunnel interface and the next hop equipment just in case it is an issue with GRE tunnel packet fragmentation but it has not seems to make a difference. I have also increased teh Hold-Queue with out any affect.

This only seems to be a problem with connections that are sending large data packets.

The interfaces\ports used for the link between the switch and the IPSec tunnel device are set to be routeed ports (as opposed to switch ports).

The Tunnel interface config is below, this is the hub mGRE interface:

interface Tunnel1

description Test

ip address 172.23.254.1 255.255.255.0

no ip redirects

ip mtu 1400

ip flow ingress

ip nhrp authentication test

ip nhrp map multicast dynamic

ip nhrp network-id 123

ip nhrp holdtime 600

ip route-cache flow

no ip split-horizon eigrp 123

load-interval 30

tunnel source GigabitEthernet5/1

tunnel mode gre multipoint

tunnel key 123

hold-queue 500 out

end

Show Interface for the Tunnel interface:

Tunnel1 is up, line protocol is up

Hardware is Tunnel

Description: Test

Internet address is 172.25.254.1/24

MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec,

reliability 255/255, txload 113/255, rxload 1/255

Encapsulation TUNNEL, loopback not set

Keepalive not set

Tunnel source 172.25.242.5 (GigabitEthernet5/1), fastswitch TTL 255

Tunnel protocol/transport multi-GRE/IP, key 0x313, sequencing disabled

Checksumming of packets disabled, fast tunneling enabled

Last input 00:00:01, output 00:00:00, output hang never

Last clearing of "show interface" counters 00:20:27

Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 115

Queueing strategy: fifo

Output queue: 0/500 (size/max)

30 second input rate 0 bits/sec, 0 packets/sec

30 second output rate 4000 bits/sec, 3 packets/sec

L2 Switched: ucast: 0 pkt, 0 bytes - mcast: 0 pkt, 0 bytes

L3 in Switched: ucast: 0 pkt, 0 bytes - mcast: 0 pkt, 0 bytes mcast

L3 out Switched: ucast: 0 pkt, 0 bytes mcast: 0 pkt, 0 bytes

555 packets input, 72176 bytes, 0 no buffer

Received 0 broadcasts (332 IP multicasts)

0 runts, 0 giants, 0 throttles

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

3481 packets output, 935513 bytes, 0 underruns

0 output errors, 0 collisions, 0 interface resets

0 output buffer failures, 0 output buffers swapped out

2 REPLIES
Anonymous
N/A

Re: mGRE packet drops

The default MTU on a mgre interface is 1472. Each GRE tunnel must have a unique set of tunnel source, tunnel destination and either no tunnel key or a tunnel key.

GRE tunnels are dropping traffic, whenever CEF is enabled. Customer is disabling CEF as workaround, but router can't handle the load, so disabling CEF turns it into a performance issue.

http://www.cisco.com/en/US/docs/ios/12_4/interface/configuration/guide/inb_tun.html#wp1078007

Blue

Re: mGRE packet drops

Mike:

Youve already posted this question on another thread. It is not recommended that you do that, since it causes confusion and mitigates the usefulness of the board.

That other thread is just as active, if not more, than this one.

http://forums.cisco.com/eforum/servlet/NetProf?page=netprof&forum=Network%20Infrastructure&topic=WAN%2C%20Routing%20and%20Switching&topicID=.ee71a06&fromOutline=&CommCmd=MB%3Fcmd%3Ddisplay_location%26location%3D.2cc045b4

Thanks

Victor

122
Views
0
Helpful
2
Replies