From: asadovnikov (asadovnikov@comcast.net)
Date: Mon Nov 10 2003 - 00:22:07 GMT-3
John,
Both Howard and I recommended some strategies on finding exact segment where
the full size packets get dropped. You really need to find it so it can be
fixed. I would not be surprised if it does have something to do with
trunking, but question "where it is?" I think is the most important. Again,
do traceroute, and then try to ping each hop, first with small packet, then
with larger packet, then with full size packet and find where it stops.
Best regards,
Alexei
P.S. Some stations use different conventions of what the size of the ping
is. You will safe yourself some time if you always use IOS routers to ping.
BTW I think your "ISP C" is the same one I use, and I do not have such an
issue.
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Messina, John V
Sent: Sunday, November 09, 2003 2:27 PM
To: Howard C. Berkowitz; ccielab@groupstudy.com
Subject: RE: OT- MTU issues (with addition)
Ok so now if I am peering with only ISP A AND ISP B I can ping my vlan 1
interface with 1500 no problem.
So I switched back to only peering with ISP C and I can ping my vlan 1
interface with 1468 but not with anything higher. both from the same place
on quests network who is not one of my ISP's. doing the same thing from
sprints network I get the same results . 1468 works but 1469 and above does
not. This was from workstations.
From routers I get the same result with or without the df bit set.
Im still thinking this is am mtu issue as a result of the dot1q overhead but
I am open to other theories.
Layout
http://area100.com/isp/isp.htm
-----Original Message-----
From: Howard C. Berkowitz [mailto:hcb@gettcomm.com]
Sent: Sunday, November 09, 2003 11:36 AM
To: Messina, John V; Howard C. Berkowitz; ccielab@groupstudy.com
Subject: RE: OT- MTU issues (with addition)
At 11:15 AM -0500 11/9/03, Messina, John V wrote:
>
>
>so ISP A and ISP B are out of the picture. I am no longer peering and
>the ser int's are shut down. They work fine when up.
>
>Now I am peering with ISP C. I have 2 peers to them peer A between my
>int vlan 122 and their 2848 and peer b between my loopback 0 and their
>12000. They have required it to be done this way.
Is there a problem there?
>So they are sending me a
>default route and a route to the default route.
>Everything between my3550 and ISP C's 2948 is layer 2. The transport is
>actually being provided by a third party who owns the ring.
>Unfortunately I have little details on the info from that transport but
>I have been trying to get more.
>
>
>>From inside I can ping to everywhere successfully and traceroute. The
>path's are correct. From outside in, from every route server on the
>internet I could find the trace back to my network is correct and
>successful as is name resolution. So I am satisfied that DNS, BGP is
>correct. So from the outside in you can telnet to www.mydomainname.com
>80 and you will hit my web server. My firewall sees the traffic and the
>web server logs the connection. Once any larger traffic is sent it
>doesn't work.
>
>I have done pings with different packet sizes and that's when problems
>occur. With and without DF set.
Could you give more detail on where, and with what size and DF
settings, the problems are occurring? Do you have a host that could
log into the Internet at some distant point and do pings/traceroutes
with size & DF variations?
>
>
>
>
>-----Original Message-----
>From: Howard C. Berkowitz [mailto:hcb@gettcomm.com]
>Sent: Sunday, November 09, 2003 9:11 AM
>To: ccielab@groupstudy.com
>Subject: Re: OT- MTU issues (with addition)
>
>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
>>
>>MYFirewall>>my3550>dot1Q>isp3550>>ISPfiberRing>>ISP3550>ISP2948>>ISP12
0
>0
>>0>>internet
>>
>>
>>
>>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:
> >http://shop.groupstudy.com
>>
>>Subscription information may be found at:
>>http://www.groupstudy.com/list/CCIELab.html
>
>_______________________________________________________________________
>Please help support GroupStudy by purchasing your study materials from:
>http://shop.groupstudy.com
>
>Subscription information may be found at:
>http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Fri Dec 12 2003 - 12:29:09 GMT-3