cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3545
Views
6
Helpful
4
Replies

GRE tunnel and MTU size

mijff
Level 1
Level 1

Hi,

I configured two 1710 routers for transparent bridging in a trunk (802.1q) link. The routers are connected with a tunnel, which also part of the bridge. For packets below 1468 bytes a ping between both end points works fine. A ping with bytes larger as 1468 bytes doesn’t work. I have changed the ip MTU on the tunnel interfaces from 1500 to 1532, but that didn’t work, I even made the ip mtu smaller but that didn’t also work, who can give me advise. I have changed the DF bit but that didn’t have any result.

What I’m I doing wrong? who can give me some tips?

Regards,

Michiel

SWITCH

| (802.1q trunk)

|

| (bridge interface)

ROUTER

: (bridge interface)

:

: (bridge interface)

ROUTER

| (bridge interface)

|

| (802.1q trunk)

SWITCH

---------------------------------------------

version 12.2

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname Router1

!

logging queue-limit 100

!

memory-size iomem 25

ip subnet-zero

!

!

no ip domain lookup

!

ip audit notify log

ip audit po max-events 100

!

interface Loopback0

no ip address

no ip mroute-cache

!

interface Tunnel0

no ip address

tunnel source FastEthernet0

tunnel destination 192.168.1.248

bridge-group 1

!

interface Ethernet0

no ip address

no ip mroute-cache

half-duplex

bridge-group 1

!

interface FastEthernet0

ip address 192.168.0.248 255.255.255.0

no ip mroute-cache

speed auto

!

ip classless

ip route 192.168.1.0 255.255.255.0 192.168.0.253

no ip http server

no ip http secure-server

!

bridge 1 protocol ieee

!

line con 0

line aux 0

line vty 0 4

exec-timeout 15 0

password cisco

login

!

end

version 12.2

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname Router2

!

logging queue-limit 100

enable secret xxxxxx

!

memory-size iomem 25

ip subnet-zero

no ip routing

!

!

no ip domain lookup

!

ip audit notify log

ip audit po max-events 100

!

interface Loopback0

no ip address

no ip route-cache

no ip mroute-cache

!

interface Tunnel0

no ip address

ip access-group 101 out

tunnel source FastEthernet0

tunnel destination 192.168.0.248

bridge-group 1

!

interface Ethernet0

no ip address

no ip route-cache

no ip mroute-cache

half-duplex

bridge-group 1

!

interface FastEthernet0

ip address 192.168.1.248 255.255.255.0

no ip route-cache

no ip mroute-cache

speed auto

!

ip classless

ip route 192.168.0.0 255.255.255.0 192.168.1.253

no ip http server

no ip http secure-server

!

bridge 1 protocol ieee

!

line con 0

line aux 0

line vty 0 4

exec-timeout 15 0

password xxx

login

!

end

1 Accepted Solution

Accepted Solutions

The only way to verify the status of the DF-bit is to use a packet analyzer. I would not be surprised if it is on because the default behaviour for a tunnel is to fragment frames.

The IP mtu you have set is just known to the router, end hosts have no way to detect this except perhaps through icmp. When you get the end nodes to use an IP mtu of 1430, it should work.

The fact that you are bridging means that you lose an extra 18 bytes for the mac-header plus 4 due to the dot1q tag.

When you route across the tunnel, the mac-header is not sent with the datagram. Besides, you also save out the broadcast packets so this is a slightly more efficient method.

Regards,

Leo

View solution in original post

4 Replies 4

sun816
Level 1
Level 1

I don't certain ,but the tunnel interface is based on the physical interface,so if you also change mtu on physical int traffic flows by , may be it will works.

lgijssel
Level 9
Level 9

You will not be able to set an MTU to any value beyond 1500. The switch will allow for the extra 4 bytes from the dot1Q encapsulation to be transmitted but that is it.

Normally, this will not be a problem as the IP datagrams will be fragmented. Only traffic with the DF-bit set will be discarded if the datagram is larger than your MTU.

To solve this, you should set the IP mtu to a value that fits through the tunnel. Hence you should reduce the MTU, not enlarge it.

Remember that the MTU is the payload of an ethernet packet, IP MTU is the payload of an IP datagram. This is typically 20 bytes less than the ethernet MTU.

From your config, I deduced that you are using a GRE tunnel. This adds 8 bytes to the overhead.

The dot1Q encapsulation counts up to four extra bytes. So 1500 -(20+8+4) = 1468 bytes.

As you are bridging, this is the maximum datagram size for your tunnel.

The IP MTU for traffic that needs to traverse the tunnel will then be 1468 - (18 +20) = 1430 bytes.

Regards,

Leo

thanks for your comment,

I have changed the IP MTU on the tunnel interface to 1430 bytes and even to 1400 bytes. But when I do a ping larger as 1468 bytes the pings will not be replied. Because I do a default ping in dos, the DF bit is not set.

question: Is it possible that the IP MTU on the tunnel interface is not used, because I'm bridging and not routing?

The only way to verify the status of the DF-bit is to use a packet analyzer. I would not be surprised if it is on because the default behaviour for a tunnel is to fragment frames.

The IP mtu you have set is just known to the router, end hosts have no way to detect this except perhaps through icmp. When you get the end nodes to use an IP mtu of 1430, it should work.

The fact that you are bridging means that you lose an extra 18 bytes for the mac-header plus 4 due to the dot1q tag.

When you route across the tunnel, the mac-header is not sent with the datagram. Besides, you also save out the broadcast packets so this is a slightly more efficient method.

Regards,

Leo

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: