One other thought: Keep in mind that the added 24-byte GRE header has
consequences for both sides of the session. If either the client or the
server tries to send 1500-byte packets, the additional GRE header may
result in a need for fragmentation, which can't happen if the DF bit is set.
So your coworkers may be telling you that the ICMP dest unreachable (frag
needed but DF bit set) messages aren't getting filtered, but they may be
only looking at it from the point of view of just the client or just the
server.
If worse comes to worst, you can manually decrease the MTU at the clients
and the servers. Also, if your tunnel is going over links that support
large MTUs (> than 1524), you can increase the tunnel MTU. (That isn't
usually the case, though.)
One last thought, make sure you aren't barking up the wrong tree
altogether. Perhaps the fact that you aren't seeing ICMP dest unreachable
messages is a good thing. That part is working. Something else is broken.
Do you use encryption, IPSec, or anything else fragile on that tunnel??
Ok, that's enough rambling. &;-)
Priscilla
At 10:55 AM 10/25/00, Priscilla Oppenheimer wrote:
>Well, this does sound kind of strange and I think you are probably on the
>right track, suspecting that ICMPs are being filtered.
>
>One question, and I apologize if it is silly:
>
>Are you sure you are looking for the right ICMP message back? It sounded
>like perhaps you expected to see a message that clearly told the
>workstation to decrease the packet size and try it again. The message back
>from the router won't be quite than unambiguous.
>
>It will be an ICMP Destination Unreachable (Type = 3)
>Fragmentation needed, but don't-fragment bit set (Code = 4)
>
>Contrary to what someone else said, it won't be a Time Exceeded (Type 11)
>Fragment reassembly time exceeded (Code 1)
>
>That would be used on packets that _did_ get fragmented, in the case where
>a fragment is delayed or lost, as you probably know.
>
>Good luck! Please keep us posted on what you learn.
>
>Priscilla
>
>At 02:01 PM 10/23/00, Donohue, Steve wrote:
>>This message is in MIME format. Since your mail reader does not understand
>>this format, some or all of this message may not be legible.
>>
>>------_=_NextPart_001_01C03D1B.502CC79C
>>Content-Type: text/plain;
>> charset=iso-8859-1
>>Content-Transfer-Encoding: 7bit
>>
>>Good Afternoon All,
>>
>>I am currently trying to resolve an issue where we are having trouble
>>sending data across a tunnel running GRE encryption. With this encryption
>>employed the MTU size allowed is decreased to 1476. When we attempt to send
>>traffic (email, ftp, etc...) through the tunnel, we are finding that it does
>>not work.
>>
>>My sniffer trace is showing that the frames being sent are setting the DF
>>bit, which I would expect. I would then expect that if the router is unable
>>to send the packet, it would drop it and return an ICMP message back to the
>>source telling it to decrease the packet size and try it again. I am not
>>seeing any of these messages.
>>
>>We are running HSRP on the ethernet interfaces that connect to my LAN. I
>>believe we are running a 12.0 IOS release, although I am not sure of the
>>actual version.
>>
>>Does anyone have any ideas why this might be happening? I am trying to
>>resolve this issue while having no CLI access to the routers. I have been
>>informed by the controlling body that there are no access lists prohibiting
>>ICMP messages from being sent, and there are no firewall rules in place that
>>would be dropping the ICMP messages.
>>
>>Any and all explanations of possible causes/resolutions would be
>>appreciated.
>>
>>Steve D.
>>
>>
>>------_=_NextPart_001_01C03D1B.502CC79C
>>Content-Type: text/html;
>> charset=iso-8859-1
>>Content-Transfer-Encoding: 7bit
>>
>><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
>>Good Afternoon All,
>>
>>I am currently trying to resolve an issue where we are having trouble
>>sending data across a tunnel running GRE encryption. With this
>>encryption employed the MTU size allowed is decreased to 1476. When we
>>attempt to send traffic (email, ftp, etc...) through the tunnel, we are
>>finding that it does not work.
>>
>>My sniffer trace is showing that the frames being sent are setting the DF
>>bit, which I would expect. I would then expect that if the router is
>>unable to send the packet, it would drop it and return an ICMP message
>>back to the source telling it to decrease the packet size and try it
>>again. I am not seeing any of these messages.
>>
>>We are running HSRP on the ethernet interfaces that connect to my LAN. I
>>believe we are running a 12.0 IOS release, although I am not sure of the
>>actual version.
>>
>>Does anyone have any ideas why this might be happening? I am trying to
>>resolve this issue while having no CLI access to the routers. I have
>>been informed by the controlling body that there are no access lists
>>prohibiting ICMP messages from being sent, and there are no firewall
>>rules in place that would be dropping the ICMP messages.
>>
>>Any and all explanations of possible causes/resolutions would be appreciated.
>>
>>Steve D.
>>
>>
>>------_=_NextPart_001_01C03D1B.502CC79C--
>>
>>_________________________________
>>FAQ, list archives, and subscription info:
>>http://www.groupstudy.com/list/cisco.html
>>Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
>
>
>________________________
>
>Priscilla Oppenheimer
>http://www.priscilla.com
>
>_________________________________
>FAQ, list archives, and subscription info:
>http://www.groupstudy.com/list/cisco.html
>Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
________________________
Priscilla Oppenheimer
http://www.priscilla.com
_________________________________
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
