From: Messina, John V (john@crimsoncti.com)
Date: Sun Nov 09 2003 - 16:27:20 GMT-3
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