02-02-2004 12:15 AM - edited 03-02-2019 01:17 PM
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 doesnt work. I have changed the ip MTU on the tunnel interfaces from 1500 to 1532, but that didnt work, I even made the ip mtu smaller but that didnt also work, who can give me advise. I have changed the DF bit but that didnt have any result.
What Im 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
Solved! Go to Solution.
02-05-2004 11:49 AM
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
02-03-2004 12:49 AM
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.
02-03-2004 07:26 AM
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
02-04-2004 11:12 PM
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?
02-05-2004 11:49 AM
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
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