The MPLS-OPS Archive

Cell Relay Retreat>MPLS-OPS Archive>month:2001-Oct> msg00168



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

Re: RES: Problems w/ MTU

  • From: Robert Raszuk <raszuk@cisco.com>
  • Date: Fri, 19 Oct 2001 20:46:47 +0200
  • CC: "'Alan Hannan'" <alan@routingloop.com>, mpls-ops@mplsrc.com
  • Organization: Signature: http://www.employees.org/~raszuk/sig/
  • Resent-Date: Fri, 19 Oct 2001 16:37:47 -0400
  • To: "Loureiro, Rodrigo - (Bra)" <rodrigo.loureiro@attla.com>


<MPLS@UU.NET removed>

The most likely you need to tell PE1 to fragment by configuring it :).
Try to set "tag mtu 1500" on your POS int of PE1.

R.

> "Loureiro, Rodrigo - (Bra)" wrote:
> 
> Hi Alan,
> 
> Thanks for response.
> 
> I´m not sure that PE routers will fragment the packets. The real proof
> of this is that the maximum ICMP packet that i could transfer between
> PE1 and PE2, without set the DF bit, was a 1506 bytes packet (1510
> maximum feasible ethernet frame minus 4 label bytes). If fragmentation
> were being done in the PE1 POS, i should be able to ping PE2 with any
> packet length, once POS is configured with a 1500 bytes MTU. Also, i
> enabled a debug and i could see that packets greater than 1500 bytes
> were not being fragmented.
> 
> My doubt is: PE1 wants to send an IP packet to PE2, and this packet is
> being generated by PE1. Once PE1 has an entry for PE2 in its LFIB,
> should it respect the IP MTU and fragment the packet prior to label
> it, or should it ignore the IP MTU, as P routers do w/ pure label
> switching ?
> 
> Regards,
> --
> 
> Rodrigo
> 
> -----Mensagem original-----
> De: Alan Hannan [mailto:alan@routingloop.com]
> Enviada em: sexta-feira, 19 de outubro de 2001 13:00
> Para: Loureiro, Rodrigo - (Bra)
> Cc: mpls@UU.NET; mpls-ops@mplsrc.com
> Assunto: Re: Problems w/ MTU
> 
>   This is a known issue, operationally.
> 
>   You must set the MTU of your Layer 3 transmittal driver to be small
>   enough to allow needed Label Stacking.  I believe we set the MTU of
>   much ethernet to 1490 or so to allow this, which also wreaks
>   cosmetic habit with certain syslog-alarm-happy boxes...
> 
>   In practice, most POS MTUs are 4470, not 1500, FWIW.
> 
>   The router should fragment, and it will, but the switch will drop.
> 
>   -alan
> 
> Thus spake Loureiro, Rodrigo - (Bra) (rodrigo.loureiro@attla.com)
>  on or about Fri, Oct 19, 2001 at 02:32:59PM -0300:
> > Hi all,
> >
> > I am investigating a problem with packet forwarding/switching in a
> MPLS
> > scope regarding maximum transfer unit, and i would like to share my
> doubts
> > with you.
> >
> > Imagine a four routers setup: PE1, P1, P2 and PE2. PE1 is connected
> to P1
> > via POS, P1 is connected to P2 via ATM and P2 is connected to PE2
> via a
> > FastEthernet cross-connection. Imagine also that POS interface is
> configured
> > with a 1500 bytes MTU, ATM with 4470 bytes and FastEthernet with
> 1500 bytes
> > (consider this hardware is capable to generate Ethernet frames up to
> 1510
> > bytes of payload for labeling purposes).
> >
> > Now, consider that PE1 and PE2 has a MP-BGP session directly between
> them.
> > Considering that BGP is capable to generate messages up to 4096
> bytes (RFC
> > 1771), we should guarantee that packets greater than 1500 bytes sent
> from
> > PE1 toward PE2 are being fragmented. Instead of this, the packets
> will be
> > discarded in the FastEthernet connection between P2 and PE2, once
> MPLS will
> > not  fragment the packets.
> >
> > I made a test with ICMP from PE1 to PE2, generating packets greater
> than
> > 1500 bytes, and i could see that packets were not being fragmented
> by PE1.
> > So, one question arises: What should be the correct behavior for IP
> packets
> > originated inside the router toward another router in a MPLS
> environment:
> > should it follow the interface MTU and fragment the packet or should
> it
> > ignore it and label switch the packet regardless of its lengh ?
> >
> >
> > Regards,
> > --
> >
> > Rodrigo Loureiro
> > AT&T LA - Network Engineer

-------
The MPLS-OPS Mailing List
Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
Archive: http://www.mplsrc.com/mpls-ops_archive.shtml