cshanyee
Joined: 01 Feb 2006
Posts: 1
|
 Posted:
Wed Feb 01, 2006 8:55 am Post subject:
DF Bit |
|
|
Hi All,
I've some queries on DF bit. We got 2 sites office, HQ and Offsite. Both are connected via 768K IP VPN link (Megapop) from our ISP. All traffic from our Offsite office will have to go through this link to access the servers at HQ end. Recently, our Offsite Office having some problem accessing to Application A but no problem to all other applications like email, internet, and so on. Application A is hosted at our vendor's end.
There is no problem accessing Application A from our HQ. To access to Application A from Offsite Office, the traffic will go through 768K link to reach our HQ. From there the traffic will be routed to a firewall (HQ) which is connected to Application A's router at vendor's end.
We reported the problem to our vendor, and here is their comment:
-------------------------------------------------------------------------------
After knowing that you are using Megapop with Tunnel settings and their MTU size, we have configured our Cisco router (that connects to your
firewall) to set all IP Packets coming from Application A Router Server, the "DF" bit (Don't Fragment Bit) to 0. Since then and so far, the connection is successful.
Explanation:
Don't Fragment Bit (DF) in the IP Packet set to 1 tells the routers on the way (when it is transvered from one end to the other) that this packet cannot be fragmented and must be transmitted as a whole.
Now the problem that we suspect is due to your Router's Megapop tunnel. When transmitting a packet via the Tunnel, there will be overheads added on top of the existing packet (24 Bytes for GRE tunnel). If an existing packet is 1500bytes, another 24 bytes - the overhead - will need to be added. So the new packet size is 1500 + 24 = 1524 bytes.
However, your Maximum Transmission Unit (MTU) for the tunnel interface is
1514 bytes only. And with the Don't Fragment bit set to 1 (which means cannot fragment the packet), the router will drop all the large size packets. And most of the time, Windows Server set the DF bit to 1. In this case, our Application Router Server set the DF bit to 1, and when passed through your Router Megapop tunnel, the large size packets are being dropped.
It could be dropped at your router, or it could be dropped at the ISP megapop infrastructure.
Therefore on our Router, before leaving to your site we have cleared this DF bit to 0 by using Routing Policy (i.e. to tell other routers that u can fragment the packets). And after clearing it, the connection @ Offsite was successful.
---------------------------------------------------------------------------------
The vendor requested us to change the DF bit at our router to 0. All along we have been running with this configuration without any problem till that day. What will be the impact to our other applications after we change the DF bit to 0. Will there be any downtime??
Below is our tunnel interface:
HQ:
Tunnel0 is up, line protocol is up
Hardware is Tunnel
Internet address is 172.19.203.105/30
MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec,
reliability 255/255, txload 192/255, rxload 36/255
Encapsulation TUNNEL, loopback not set
Keepalive set (10 sec), retries 3
Tunnel source 172.20.200.202 (FastEthernet0/1), destination 172.21.200.202
Tunnel protocol/transport GRE/IP
Key disabled, sequencing disabled
Checksumming of packets disabled
Tunnel TTL 255
Fast tunneling enabled
Tunnel transmit bandwidth 8000 (kbps)
Tunnel receive bandwidth 8000 (kbps)
Last input 00:59:58, output 00:00:01, output hang never
Last clearing of "show interface" counters 01:16:58
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 27
Queueing strategy: fifo
Output queue: 0/0 (size/max)
5 minute input rate 5000 bits/sec, 4 packets/sec
5 minute output rate 58000 bits/sec, 6 packets/sec
38741 packets input, 7116808 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
55732 packets output, 30822649 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 output buffer failures, 0 output buffers swapped out
Offsite:
Tunnel0 is up, line protocol is up
Hardware is Tunnel
Internet address is 172.19.203.106/30
MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec,
reliability 255/255, txload 226/255, rxload 251/255
Encapsulation TUNNEL, loopback not set
Keepalive set (10 sec), retries 3
Tunnel source 172.21.200.202 (FastEthernet0/0), destination 172.20.200.202
Tunnel protocol/transport GRE/IP, key disabled, sequencing disabled
Tunnel TTL 255
Checksumming of packets disabled, fast tunneling enabled
Last input 00:00:00, output 00:00:00, output hang never
Last clearing of "show interface" counters 01:19:05
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 32
Queueing strategy: fifo
Output queue: 0/0 (size/max)
5 minute input rate 60000 bits/sec, 9 packets/sec
5 minute output rate 8000 bits/sec, 7 packets/sec
56890 packets input, 31427806 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
39758 packets output, 7319331 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 output buffer failures, 0 output buffers swapped out
I just want to make sure that the problem does not lie at our end. Appreciate if someone could help.
Thanks & regards
SY |
|
FAQ
Memberlist
Register
Profile
Log in to check your private messages
Log in
