- A virtual community of network engineers
 Home  BookStore  StudyNotes  Links  Archives  StudyRooms  HelpWanted  Discounts  Login
Re: OT- MTU issues (with addition) posted 11/09/2003
[Chronological Index] [Thread Index] [Top] [Date Prev][Date Next] [Thread Prev][Thread Next]

At 10:54 PM -0500 11/8/03, Messina, John V wrote:
We have a situation with an ISP that's a little strange.

In medicine, there's a distinction between symptoms and signs. A symptom is something subjective reported to the patient "I feel hot," where a sign is something objective "Temperature is 103 degrees F". In your writeup, you are talking about symptoms presented by applications. Drop back and use diagnostic tools to find the signs.

We are
multihomed with 2 T1's to 2 ISP's for a long time. We are trying to add
a third ISP via an Ethernet handoff and are running into fragmentation
issues. The layout for the new ISP is this


So whenever we plug the firewall into the 3550 and eliminate the other 2
ISP's from the equation and use only this Ethernet ISP

OK. Stop at this point. Don't worry, for now, if you can run Internet applications. Start with extended ping and traceroute.

[I don't have a router next to me, but I thought traceroute, as well as ping, had a length option. A couple of CCO notes says no. If there is a length option on traceroute, or if you have another non-Cisco traceroute, use that and forget what I see as pings]

While you initially may ping without DF set, you probably want to set it as you localize the problem.

Let's redraw your picture a little. I really need to know if some of the L2/L3 capable devices are using L3, and if they are on different subnets

MYFirewall [address] ====[802.3?]====>
[inboundAddress] my3550 [outboundAddress] ====[802.1q]=====>
[inboundAddress] ISP-1a-3550 [outboundAddress] ====Fiber ring*======>
[inboundAddress] ISP-__-3550 [outboundAddress] =======?=============>
[inboundAddress] ISP-__-2948 [outboundAddress] =======?=============>
[inboundAddress] ISP-__-12000 [outboundAddress] =======?=============>

Several notes/questions:

? What medium (including crossover cable)
* What kind of fiber ring? FDDI? POS?
__ what ISP, or router # within ISP?

Ping to some distant endpoint, starting with about 500 bytes, and see if you can reach that endpoint. When you get around 1500, and get a failure, walk up on it slowly (e.g., 1484, 1492, 1500, 1502, 1518) so you can look for undocumented tunnels.

Once you find a length at which extended ping fails, ideally use an extended traceroute with that length through the system. If you don't have such a traceroute, than start pinging with the critical length until you find a failure (I hope) or get to the end.

If you do get to the end, consider whether or not the fragmentation problem might be in the return path. If you can get to a machine on the internet that can send pings/traceroute to you, repeat the process in the reverse direction.

 most users and
servers cannot browse the internet

And traffic inbound does not work.

Does that include inbound traffic you know is short, such as a normal ping response? If so, I'd start thinking of an access list, or even a QoS statement that classifies by length, or a really crazy WFQ.

You can telnet to my web servers on
port 80 but you cannot view it in IE. Similarly you can telnet to the MS
terminal servers on 3389 but cannot connect via an RDP client.

RDP? I'm not a Microsoft person.

We have gone outside the firewall to eliminate it as a source. We have plugged in a 3640 to do all routing instead of the 3550 and enabled path mtu discovery since the 3550 does not support it ( if it does let me know) We have enableb jumbo packet support with the sys mtu 1546 command on the 3550. We are using a dot1Q trunk between our 3550 and the ISP for the purposes of video conferencing on their ring. We have clients on the ring so this ISP just allows certain vlans over certain trunks. To me at least this points to an MTU issue along the way somewhere because fragmentation is definitely occurring.

We have asked the ISP to enable jumbo packet support on the switches in
the path but they have not done this yet. We have tried all different
combinations of MTU changes on servers and pmtud disabling.

Again, don't just make changes to options. Find out where the problem appears under the present conditions. You may be hitting a tunnel no one has told you about--I'd think of that before a fragmentation problem based on default MTU.

Only if you can traceroute/ping everywhere should you start changing things.

I am curious if anyone has any theories on how to resolve this.

Thanks for any suggestions

Please help support GroupStudy by purchasing your study materials from:

Subscription information may be found at: