From: Arun Arumuganainar (aarumuga@hotmail.com)
Date: Thu Aug 18 2005 - 07:06:55 GMT-3
Hi Jongsoo ,
I think this discussion revolves around mini giants .
So what is Mini Giants !!!
Maximum size of packet that can go in Fast ethernet = 1518 = 1500 Max IP
Pack size + 18Bytes Ether net header .
However in some but very common cases nowadays , the packet size would be
slightly more than 1518 !!! Some examples are given below !!!
1) Vlan Tagged frame = 1500 IP + 18 Ethernet + 4 Byte Vlan tag = 1522
2) MPLS VPN Packet = 1500IP + 8Byte ( 2 Label stack for MPLS VPN ) + 18 Byte
Ethernet = 1526
3) L2TP Packet = 1500 IP + 40Byte +18Byte ethernet = 1558bytes
The list endless including PPPoE , GRE , MPLS-TE , QinQ , ISL Trunk etc etc
!!! In general any Layer 2 packet over 1518 byte and below 1600 in length is
termed as mini-giants or tiny giant !!!
So whats the real problem with this tiny giants ???? Traditionally all
Ethernet standards says any frame with size over 1518 will have to be
fragmented . And all the applications are built and written to suit this
frame size ( IP-MTU = 1500 ) !!! Pls. note : This limitation is not physical
limitation of media but ethernet standards impose it !!
However with advances in technology we went on adding headers in the middle
of the network as described above which the end-hosts are not aware off
..this leads to legitimate increase in packet size leading to fragmentation
However fragmentation is undesirable one, since packets will be processes
switched during fragmentation . You will not believe !!! One large FTP
download can bring down a SOHO router with in minutes !!!
To over come this people came up with idea called mini-giant support for
ethernet drivers . When turned on Ethernet driver will not fragment mini
giant packets ( Size <1600 )!!!
For some platforms mini giant configuration is automatic ( enabled by
default & can not be turned off ) eg: IOS based router platforms ...!!!For
some platforms it can be manually configured ( using mtu <value> command) .
Eg: Cat switches
Note : For Cat switch default Max-Ether-Frame-Frame size = 1524 and can be
changed using mtu command .
Note : Low end Cisco platforms like 800 routers do not support mini giants .
However you can avoid collateral damages of Minigiants using a feature
called "ip tcp adjust-mss " . When this is turned on it spoofs the syn
packet and changes the MSS value to lower value . It will safe guard all the
TCP application from fragmentation problems ".
Spciale case with MPLS :-
===================
Pls. Note that in all the above cases IP MTU is intact . Changes happens
only in the Ethernet frame size . In case IP Packet length is greater that
1500 packets will fragmented eventhough overall ethernet frame is less than
1600 ( Its considered not a Mini-giant ) !!! In such a case fragmentation is
done by IP subsystem and not ethernet driver !!!
Similar case is there with MPLS . In the event MPLS packet size ( IP Packet
+ MPLS header alone ) exceeds 1500 then also there will be problems . This
is because MPLS uses a TAG-MTU . By default tag-Mtu follows IP MTU ( Default
= 1500 ) . Hence when we slap two labels toa 1500byte IP packet , the
length becomes 1508 and hence MPLS will fragment it !!! To avoid this we
will have to configure " mpls tag-mtu <value> " .
Some calculation : In plain MPLS it should 1504 , for VPN it should be 1508
, for CSC or InterAS VPN with RR it should 1512 ( 3 Labels ) and so on !!!
So these are the general guidelines for tweaking the MTU .
Non MPLS Case !!!
----------------------
Plat forms that supports Minigiants :
~~~~~~~~~~~~~~~~~~~~~~~~~
a) Cat Switches : change MTU to appropriate values .
b) IOS based routers : do nothing !!! Things will work fine .
Platforms ( IOS Versions) that does not support Mini-giants
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
a) Reduce the IP MTU on the edge router to appropriate values ( 1500 -
no of bytes of Headers that will Added . For ex : For L2TP it should 1460 )
This will result in fragmentation!!! But packets will not be dropped !!!
b) Configure "ip tcp adjust-mss " to appropriate values ( Use similar
calculation as u used above ) ..This will signal to end host that it will
have reduce its mtu ...Hence there is no question of fragmentation at all
Note : You can employ either a or b . While resorting b we assume non-tcp
application like UDP ICMP etc !!! does not send large packets for longer
Duration of time.
MPLS Case !!!
~~~~~~~~~~~
In addition to NON-MPLS work around change mpls tag-mtu as well .
Hope this helps.
Thanks and Regards
Arun
----- Original Message -----
From: "Scott Morris" <swm@emanon.com>
To: "'Jongsoo'" <bstrt2004@gmail.com>
Cc: "'Jamie Caesar'" <jamie.caesar@gmail.com>; <ccielab@groupstudy.com>
Sent: Thursday, August 18, 2005 12:22 PM
Subject: RE: OT: MTU adjustment for VPN MPLS over GRE
> Technically though, if you do "ip mtu 1500" inside your GRE tunnel, you
may
> find that frame fragment at Layer 2. Watch that.
>
> Have you considered ipip (ip-in-ip) tunneling instead to make your MPLS
> stuff work? That may help you sort the sanity of the MTU sizes to plan
for
> as well.
>
> How good are your VSAT links at handling jumbo frames?
>
> Sounds like an interesting project though! And one that would require
lots
> of testing from the endpoints! (cruise ships)
>
> Scott
>
> -----Original Message-----
> From: Jongsoo [mailto:bstrt2004@gmail.com]
> Sent: Wednesday, August 17, 2005 7:05 PM
> To: swm@emanon.com
> Cc: Jamie Caesar; ccielab@groupstudy.com
> Subject: Re: OT: MTU adjustment for VPN MPLS over GRE
>
> Jamie
>
> Thanks for the info. I already read it. It is really good explanation for
> regular IP packet inside GRE...
>
>
> Scott
>
> Thanks for some direction.
>
> Yeah, this should be a good discussion overall for many folks. In my
search
> on study group, I didn't have much of luck on this topic...
>
> I believe most MPLS-converting network will go through this MTU adjusting
> "fun".( I did in my previous company with Junipers). Now I am working for
a
> company who provide VPN and Internet service to cruise line via satellite.
> In this case, network is based cisco router ( good for a new CCIE ???) and
I
> am the service provider so that I can control the number of tag and the
> number of MPLS tag is 2 ( 1 for VPN and 1 for Label
> switching) as we are only using MPLS for VPN service.
>
> The solution I am looking for is how to make "MPLS VPN inside of GRE"
work.
>
>
> After internal discussion, we agree the correct command should be
> "tag-switching MTU 1508" under tunnel interface.
> But it is not working( In fact, we did every possible size of MTU with no
> luck)...one of engineer opened the case with cisco.
>
>
> One thing confusing me is how GRE tunnel interface calculates the size
> of IP datagram. Doesn't it include GRE IP OH or not, which is my big
> question.
> I sort of believe it doesn't include GRE IP OH ( 24 Byte = 20 IP and 4
> GRE) when a tunnel interface compare the size( TL) of IP datagram with
> configured MTU in order to make a decison to fragment or not.
>
> Supporting proof is that "IP MTU 1500" under tunnel interface works
> fine for common application of "IP packet inside of GRE". If GRE
> include its own OH when calculating the size of IP datagram, "IP MTU
> 1500" shouldn't work because the size of IP datagram should be 1524...
>
>
> Thanks
>
>
> Jongsoo
>
>
> On 8/17/05, Scott Morris <swm@emanon.com> wrote:
> > That is good to realize the general problems involved with MTU, and the
> fact
> > that you'll need to do some tweaking to handle the different values that
> > you'll run across with GRE tunnels, but MPLS VPNs add on to this.
> >
> > And part of the problem is that there's no pat answer to it. While we
> know
> > that GRE adds a fixed length to the packet size, so do MPLS tags. Those
> are
> > 4-bytes per tag. And how many stacked tags you will have will depend on
> > your provider or providerS involved in your network, and most likely
they
> > aren't going to divulge this information to you.
> >
> > You can always use extended ping to help you play around a bit with your
> > testing. Use the varying frame size and DF bit enabled to see how big
you
> > can actually pass through the cloud. And go from there. There's a
decent
> > article on Cisco's site dealing with this more from an LSP standpoint,
but
> > in the show commands you can see some of the variety depending on what
you
> > are looking at and where you are looking at it from.
> >
> > http://www.cisco.com/warp/public/105/troubleshoot_mpls_vpn.html
> >
> > If your provider has adjusted their network to allow jumbo frames (or
baby
> > jumbo frames) where larger things caused by MPLS (tag-switching MTU)
don't
> > cause fragmentation, then things may be ok. But it requires some work
on
> > the underlying architecture to give you 1500 bytes end-to-end.
> >
> > By picking the 1508 you did, are you running MPLS inside the GRE? Or
are
> > you running GRE over MPLS and want to run your IP routing stuff inside
the
> > GRE?
> > If the latter is the case (which I'd expect), then you need to do what
the
> > original link below talked about for the GRE MTU issues. As a customer,
> you
> > SHOULD not (note: means you may) need to deal with reduced MTU from
MPLS.
> > If you are responsible for the MPLS portion, look at the tag-switching
mtu
> > command instead of the ip-mtu command sets.
> >
> > HTH,
> >
> > Scott
> >
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> > Jamie Caesar
> > Sent: Wednesday, August 17, 2005 12:14 PM
> > To: Jongsoo
> > Cc: ccielab@groupstudy.com
> > Subject: Re: OT: MTU adjustment for VPN MPLS over GRE
> >
> > There may be something useful in this article. It contains a few
options
> on
> > how to handle MTU issues with GRE tunnel interfaces:
> >
> >
>
http://www.cisco.com/en/US/tech/tk827/tk369/technologies_tech_note09186a0080
> > 093f1f.shtml
> >
> > Jamie
> >
> > On 8/16/05, Jongsoo <bstrt2004@gmail.com> wrote:
> > > I thought about this again and here is my thought ( maybe a wrong
> > thought!!!).
> > >
> > > The problem is how to deal IP packets w/ MTU1500 and DF set over MPLS
> > > and over GRE.
> > >
> > > Since the GRE-tunnel outgoing physical interface has MTU 1500, no
> > > matter what packet has to be fragmented.
> > > And I have two interfaces, GRE tunnel and physical interfaces that can
> > > fragment IP packet. Obviously, the problematic incoming IP packet to
> > > GRE tunnel has MTU1500 and DF set so that tunnel interface can not
> > > fragment due to DF set.
> > > I can fake the size MTU of GRE tunnel to meet the biggest szie of IP
> > > packet, which will make GRE IP packets to be generated without
> > > fragmentation. And when this large GRE IP packet goes out to the real
> > > physical interface, it will be fragmented because it is larger than
> > > MTU of physical interface and GRE IP OH doesn't have DF set.
> > >
> > > Anyway I think perhaps the correct MTU size for tunnel interface is
> > > 1532 = 24 ( IP OH + GRE OH) + 8 ( 2 MPLS tags since it is MPLS VPN) +
> > > 1500 ( ip packet)
> > >
> > > Basically, this MTU size of 1532 under tunnel interface will make IP
> > > packet( 1500 DF set) to be fragmented not in tunnel but in outgoing
> > > physical interface.
> > >
> > > Any thought on this?
> > >
> > >
> > > Jongsoo
> > > CCIE 14539
> > >
> > >
> > > On 8/16/05, jon kim <bstrt2004@gmail.com> wrote:
> > > > Group
> > > >
> > > > I transmit MPLS VPN traffic over GRE tunnel over public internet and
> > > > am having some issue, which looks like MTU issue.
> > > >
> > > > I made IP MTU 1508 ( 1500 + 2 MPLS tags) but no luck.
> > > >
> > > > I am sure soemone did this before and will appreciate any tip about
> > > > VPN MPLS over GRE .
> > > >
> > > >
> > > >
> > > > Thanks
> > > >
> > > > Jongsoo Kim
> > >
> > > ______________________________________________________________________
> > > _ Subscription information may be found at:
> > > http://www.groupstudy.com/list/CCIELab.html
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Sun Sep 04 2005 - 17:01:19 GMT-3