Re: MTU Issues

Hi Mike

Sometimes troubleshooting an MTU issue can be tricky as it may involve a
long path that may also include proxys and traffic manipulators (as I call
it)

I would suggest to preform the following:

1) preform a tracepath to find what is the maximum MTU in your path
2) take a tcpdump from originator the DF is not set on the IP header.
3) verify that in your path there is no node that may alter the DF bit

Good Luck

On Tue, Oct 6, 2009 at 10:26 PM, mike arnold <haynessmith70_at_gmail.com>wrote:

> When a customer is trying to send larger MTU size the next hop to
> core notifies him icmp: 10.X.X.X unreachable need to frag (mtu 1492) but
> not my core nor my DS notifies him.
>
> On Wed, Oct 7, 2009 at 12:16 AM, mike arnold <haynessmith70_at_gmail.com
> >wrote:
>
> > Bryan ,
> >
> > If am pinging through a computer how i can send a larger MTU though if am
> > having a packet capture (wireshark),The problem is not with the ping the
> > ping success rate is 100% on MTU till 1492 but when i do with 1493 the
> > success rate is 0% even though the DF bit is not set.
> >
> > The customer says that the next hop to core that means ISP/PE is
> intimating
> > him icmp: 10.X.X.X unreachable need to frag (mtu 1492) . But not my
> > core nor my DS.WHY????
> >
> > On Tue, Oct 6, 2009 at 11:48 PM, Bryan Bartik <bbartik_at_ipexpert.com
> >wrote:
> >
> >> Yes, well the Fragmentation needed is a subset of the destination
> >> unreachable so you are right. Nevertheless it seems like an MTU issue.
> >> Whether you are using RR's or not shouldn't matter. Do you have a
> computer
> >> that you can send pings from while running a capture? It shouldn't be
> too
> >> hard.
> >>
> >>
> >> On Tue, Oct 6, 2009 at 1:40 PM, mike arnold
> <haynessmith70_at_gmail.com>wrote:
> >>
> >>>
> >>> Helllo,
> >>> Though i have a RR connected to my core and RR is peering MPBGP with
> core
> >>> and DS,but since my DS and core are directly connected so it does'nt
> make
> >>> such difference for presence of ip next-hopself command on core as my
> all
> >>> loopback are advertised in IGP (OSPF,)
> >>>
> >>> One thing to highlight mine core and DS is 10gig X2 module,
> >>>
> >>> Any more hints from any body,it's a strange issue for me,what else i
> can
> >>> do here.
> >>>
> >>>
> >>>
> >>> On Tue, Oct 6, 2009 at 11:21 PM, mike arnold
> <haynessmith70_at_gmail.com>wrote:
> >>>
> >>>> i dont have packet capture,this message i won't be getting on my
> >>>> telnet session.i have read on internet i shld receive this
> >>>> message.
> >>>>
> >>>> Customer complaints that TCP files transfered from B to A with MTU
> 1500
> >>>> has no problem but from A to B it can't above 1492. He says that the
> problem
> >>>> is with the customer carrier not with the backbone carrier.
> >>>>
> >>>> How the above para can be possible,traffic is passsing through the
> same
> >>>> interface as such what it is passing from to A to B
> >>>>
> >>>> On Tue, Oct 6, 2009 at 11:10 PM, Bryan Bartik
> <bbartik_at_ipexpert.com>wrote:
> >>>>
> >>>>> You won't get a Destination Unreachable, you will get a Fragmentation
> >>>>> Needed and Don't Fragment Bit Set. Did you get a packet capture? Who
> is
> >>>>> sending you the message?
> >>>>>
> >>>>>
> >>>>> On Tue, Oct 6, 2009 at 1:01 PM, mike arnold
> <haynessmith70_at_gmail.com>wrote:
> >>>>>
> >>>>>> Hello Dear,
> >>>>>>
> >>>>>> Yes it is a straight ethernet,and i have not changed anything on
> >>>>>> interface configs on DS/PE facing to customer A,it is default to
> >>>>>> 1500,customer is complaining that he can't transfer TCP files larger
> than
> >>>>>> 1492 from A----B. But he says that he is able to transfer TCP
> files
> from
> >>>>>> B----A with larger size than 1492. He says that there is no problem
> with
> >>>>>> backbone carrier but with the customer carrier.
> >>>>>>
> >>>>>> When i do a extended ping from mine DS/PE to customer B with a DF
> bit
> >>>>>> set the ping sucess is 0% for larger MTU also i dont recieve any
> error
> >>>>>> saying ICMP destination unreacheable messages,
> >>>>>>
> >>>>>> Generally when a MTU is high and DF is set the intermediate
> >>>>>> router send a notification ICMP destination unreacheable
> messages,but
> in my
> >>>>>> case no feedback except success rate.
> >>>>>>
> >>>>>> On Tue, Oct 6, 2009 at 10:36 PM, Bryan Bartik <
> bbartik_at_ipexpert.com
> >>>>>> > wrote:
> >>>>>>
> >>>>>>> Well make sure it raised on ALL the core links. Is the link between
> >>>>>>> the CE and PE straight Ethernet? 1500 should be fine there.
> >>>>>>>
> >>>>>>>
> >>>>>>> On Tue, Oct 6, 2009 at 12:32 PM, mike arnold <
> >>>>>>> haynessmith70_at_gmail.com> wrote:
> >>>>>>>
> >>>>>>>> Hello,
> >>>>>>>>
> >>>>>>>> The link on distribution PE facing to customer A is default to MTU
> >>>>>>>> 1500,on distribution to core it is mpls mtu 1524 and SVI on core
> facing to
> >>>>>>>> ISP is default to 1500 on ethernet.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Tue, Oct 6, 2009 at 10:15 PM, Bryan Bartik <
> bbartik_at_ipexpert.com
> >>>>>>>> > wrote:
> >>>>>>>>
> >>>>>>>>> Did you raise the MTU on the other links?
> >>>>>>>>>
> >>>>>>>>> On Tue, Oct 6, 2009 at 12:02 PM, mike arnold <
> >>>>>>>>> haynessmith70_at_gmail.com> wrote:
> >>>>>>>>>
> >>>>>>>>>> Hello Dear's
> >>>>>>>>>>
> >>>>>>>>>> Topology:
> >>>>>>>>>>
> >>>>>>>>>> Its a Carrier Supporting Carrier Scenario.
> >>>>>>>>>>
> >>>>>>>>>> A------DS/PE---CORE/P---ISP/PE--P---ISP/PE------B
> >>>>>>>>>>
> >>>>>>>>>> AS per above topology,am not able to transfer files with MTU
> frame
> >>>>>>>>>> size
> >>>>>>>>>> above 1492 though the MTU configured on interface is 1500.The
> >>>>>>>>>> interface on
> >>>>>>>>>> which customer A is connected MTU is default to 1500.The link
> >>>>>>>>>> between
> >>>>>>>>>> DS/PE---CR/PE is mpls enabled i have configured the MTU size to
> >>>>>>>>>> 1524 to
> >>>>>>>>>> carry labels of MPLS as recommended by cisco.
> >>>>>>>>>>
> >>>>>>>>>> When i do extnded ping from DS/PE above MTU size of 1492 with
> even
> >>>>>>>>>> DF bit
> >>>>>>>>>> not set am not able to ping customer end (B),
> >>>>>>>>>>
> >>>>>>>>>> AND also i tried with DF bit set am not able to recieve any
> >>>>>>>>>> notifications
> >>>>>>>>>> ICMP destination unreacheable messages.
> >>>>>>>>>>
> >>>>>>>>>> The file transfer from customer B with packet size above 1492
> are
> >>>>>>>>>> received
> >>>>>>>>>> by customer A but when the connection are initiated through
> >>>>>>>>>> customer A they
> >>>>>>>>>> are not.
> >>>>>>>>>>
> >>>>>>>>>> Within an enterprise it works with larger MTU size when tried to
> >>>>>>>>>> ping from
> >>>>>>>>>> Distribution loopback to core loopback.How can i troubleshoot it
> >>>>>>>>>> is a
> >>>>>>>>>> problem through my end or from the ISP.
> >>>>>>>>>>
> >>>>>>>>>> The link between core and ISP is back to back VRF connected via
> a
> >>>>>>>>>> layer 2
> >>>>>>>>>> trunk.The ISP is creating a sub-interfaces on his 3800 router
> with
> >>>>>>>>>> encapsulation and vlan number.AND on Core am creating a SVI with
> a
> >>>>>>>>>> same vlan
> >>>>>>>>>> number and ip address within the subnet.
> >>>>>>>>>>
> >>>>>>>>>> Each customer VRF for exampl:(Customer A) is associated with SVI
> >>>>>>>>>> virtual
> >>>>>>>>>> interface on 6500(core)and traffic is passed to customer B.On
> SVI
> >>>>>>>>>> the MTU is
> >>>>>>>>>> default to 1500.
> >>>>>>>>>>
> >>>>>>>>>> BGP is routing protocol between CORE nd ISP.
> >>>>>>>>>>
> >>>>>>>>>> ON 3800 router (ISP End)
> >>>>>>>>>> int gig0/0
> >>>>>>>>>> no shut
> >>>>>>>>>> no ip add
> >>>>>>>>>>
> >>>>>>>>>> int gig0/0.1
> >>>>>>>>>> no shut
> >>>>>>>>>> encapsulation dot1q 50
> >>>>>>>>>> ip vrf forwarding XX
> >>>>>>>>>> ip add 10.10.10.1 255.255.255.254
> >>>>>>>>>>
> >>>>>>>>>> ON MY END (CORE)
> >>>>>>>>>> int gig5/1
> >>>>>>>>>> switchport trunk encapsulation dot1q
> >>>>>>>>>> switch mode trunk
> >>>>>>>>>>
> >>>>>>>>>> int vlan 50
> >>>>>>>>>> ip vrf forwarding customer A
> >>>>>>>>>> ip add 10.10.10.2 255.255.255.254.
> >>>>>>>>>>
> >>>>>>>>>> Thanks
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Blogs and organic groups at http://www.ccie.net
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> _______________________________________________________________________
> >>>>>>>>>> Subscription information may be found at:
> >>>>>>>>>> http://www.groupstudy.com/list/CCIELab.html
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>> Bryan Bartik
> >>>>>>>>> CCIE #23707 (R&S), CCNP
> >>>>>>>>> Sr. Support Engineer - IPexpert, Inc.
> >>>>>>>>> URL: http://www.IPexpert.com <http://www.ipexpert.com/> <
> http://www.ipexpert.com/>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> Bryan Bartik
> >>>>>>> CCIE #23707 (R&S), CCNP
> >>>>>>> Sr. Support Engineer - IPexpert, Inc.
> >>>>>>> URL: http://www.IPexpert.com <http://www.ipexpert.com/> <
> http://www.ipexpert.com/>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Bryan Bartik
> >>>>> CCIE #23707 (R&S), CCNP
> >>>>> Sr. Support Engineer - IPexpert, Inc.
> >>>>> URL: http://www.IPexpert.com <http://www.ipexpert.com/> <
> http://www.ipexpert.com/>
> >>>>>
> >>>>
> >>>>
> >>>
> >>
> >>
> >> --
> >> Bryan Bartik
> >> CCIE #23707 (R&S), CCNP
> >> Sr. Support Engineer - IPexpert, Inc.
> >> URL: http://www.IPexpert.com <http://www.ipexpert.com/> <
> http://www.ipexpert.com/>
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
>
>
>
>
>

-- 
Shiran Guez
MCSE CCNP NCE1 JNCIA-ER CCIE #20572
http://cciep3.blogspot.com
http://www.linkedin.com/in/cciep3
http://twitter.com/cciep3
Blogs and organic groups at http://www.ccie.net