From: Arun Arumuganainar (aarumuga@hotmail.com)
Date: Thu Aug 18 2005 - 12:32:28 GMT-3
oops really sorry if I have mis-quoted .
Fragmentation support is not available at interface driver level .
Fragmentation will be done only by processor ( done as part of processes
switching ) !!!
The whole problem is Process switching subsytem will look at IP MTU and IP
packet length . Fragmentation is only done when IP Packet length is greater
than 1500. Suppose we have a 1500 byte packet and when it send to interface
for forwarding . L2 Encap will be added before it is forwarded . L2 Encap
will contain Ethernet Header MPLS Label , Vlan Tag etc .
Hence when L2 Encap is slapped it becomes too heavy for Driver and driver
drops the packet !!! In order to prevent this dropping you need to choose a
IOS version which supports mini giants at the driver level . If you do not
have the support work arounds
a) Reduce IP MTU so that packet will get fragmented b4 it is sent to the
driver
b) Configure "ip tcp adjust-mss " . This will signal to end host to reduce
the packet size !!!
This is scenario in IP . Now let us see MPLS .
MPLS uses its own subsystem for forwarding . And each interface ( physical ,
logical and subinterface ) will have tag mtu associated with it . When MPLS
packet length is greater than tag-mtu then mpls-fragmentation will be done .
Note :TAG MTU will be follow IP MTU by default . However it can be changed
manually .
If you do not want the fragmentation to occur then configure tag-mtu on the
interface/subinterface/Logical interface !!! If this is not done then packet
will be fragmented will occur even if your driver supports mini-giants !!!
When Packets will be dropped ??? When there is miss-match in tag-mtu
settings !!! When one side is configured with tag mtu say 1508( additional 2
labels ) and other side is left to default . Then Packets will get dropped
when it travels Higher MTU interface to lower MTU interface !!!
In case you want further help in setting right your configuration , pls.
send my your configuration on the both end of the satellite links .I can try
to have quick look at it and suggest you in case I come across any problems
Thanks and Regards
Arun
----- Original Message -----
From: "Jongsoo" <bstrt2004@gmail.com>
To: <swm@emanon.com>
Cc: "Jamie Caesar" <jamie.caesar@gmail.com>; <ccielab@groupstudy.com>
Sent: Thursday, August 18, 2005 8:13 PM
Subject: Re: OT: MTU adjustment for VPN MPLS over GRE
> When you said frame fragment at Layer 2, I believe you meant a
> fragmentation @ phyiscal interface that is GRE outgoing interface.
> And this is what I want becasue at least the fragmentation will be
> successful without droping packet as GRE IP OH doesn't have DF set. I
> know this will push CPU high as the other end of GRE has to
> reassemble. But I can leave with that becasue I am talking very small
> mount of BW overall here.( Satellite link is expensive...even
> cruiseship can afford around 128~384 )
>
> The problem is how I can apply this to MPLS VPN.
>
> In general, VSAT link can do BER of 10^-8, which gives frame drop rate
> for 1500 Byte to 1.2x10^-4 ( 10^-8 x 1500 x 8). It means about 99.9%
> packet successful.
> But in some heavy rainy day, it would be easily unusable...
> In fact, antenna on cruiseship is a state of art...it tracks
> geo-stationally satellite less than 0.1 degree of piting angle while
> ship is moving any direction...
>
>
> Jongsoo
>
>
> On 8/18/05, Scott Morris <swm@emanon.com> wrote:
> > 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
> > > >
> > > >
This archive was generated by hypermail 2.1.4 : Sun Sep 04 2005 - 17:01:19 GMT-3