Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Help with mtu issue with ipsec gre tunnel

Status
Not open for further replies.

loveroots

Technical User
Jul 16, 2002
115
0
0
US
Dear expert I am having a problem with mtu. spoke is setup with an ipsec gre tunnel using ospf. User are not able to access the internet or internal application. user are able to ping to the internet, ping to internal ip's. I all had configured ip nut 1300 under the tunnel interface and ip tcp adjust-mss 1300 under lan interface ofice had work for afew hrs but went back down. Any idea what to try will help
 
User are not able to access the internet or internal application. user are able to ping to the internet, ping to internal ip's."

Post a config of the suspect router please.

Also, "ip tcp adjust-mss" is max segment size, which would be 40 bytes off from MTU. For example---ip tcp adjust-mss 1452 is equal to MTU of 1492, so ip tcp adjust-mss 1300 is equal to MTU of 1340. Change the "ip tcp adjust-mss" to 1260 and see what happens.

/
 
I all had configured ip nut 1300 under the tunnel interface and ip tcp adjust-mss 1300 under lan interface ofice had work for afew hrs but went back down."

If the users were working for several hours across this tunnel then its unlikly to be an MTU issue, as that wont change without operator intervention.

How do the remote users access the Internet, across the tunnel, or a local breakout?

If your running OSPF across the tunnel, is the adjacency up? If not, remember the MTU on the OSPF interfaces has to match otherwise OSPF will not establish.

You can find out the MTU of you link by using ping -f -l <size> as shown here:

ping 10.1.2.2 -f -l 1400

Pinging 10.1.2.2 with 1400 bytes of data:

Reply from 10.1.2.2: bytes=1400 time=77ms TTL=242
Reply from 10.1.2.2: bytes=1400 time=73ms TTL=242
Ping statistics for 10.1.2.2:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 70ms, Maximum = 77ms, Average = 72ms

C:\Documents and Settings\andyco>ping 10.1.2.2 -f -l 1500

Pinging 10.1.2.2 with 1500 bytes of data:

Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.

Adjust the size vlaue in the ping and when you start getting the fragment message you have reached your MTU size.


 
Yes---or an extended ping with the df bit set from the router...

It still could be MTU...as a matter of fact, I started to post what you typed, but erased it pending loveroots' implementation of my last suggestion. I suspect that it is not MTU, but who knows what "it worked for several hours..." means, i.e. did they go to different websites that did NOT need to be refreshed, were they only doing FTP, VPN apps, etc., etc.etc...

I could presume that things did NOT work UNTIL the MTU was adjusted, and that is ALL that was done, and things started working. We will see...

/
 
Thanks all I was able to get this resolve using all the steps provided. Once I decrease ip mtu on tunnel interface and remove tcp adjust-mss from lan interface. users came back.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top