From: Jongsoo (bstrt2004@gmail.com)
Date: Thu Aug 18 2005 - 11:43:25 GMT-3
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
> > >
> > > ______________________________________________________________________
> > > _ 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