From: Jongsoo (bstrt2004@gmail.com)
Date: Fri Aug 19 2005 - 17:08:23 GMT-3
Scott and Arun
Between Satellite HUB and cruiseship vsat, we are using some special
TDMA equipment, something called iDirect Hub and Netmodem. It is Hub
and Spoke topology whereNetmodem is installed in VSAT side(
cruiseship) and iDirect Hub is installed in main teleport with a big
size of antenna. iDirect HUB and Netmodem runs 802.Q over satellite
using satellite dishes. Netmodem connects customer router via 802.Q
trunk.
iDirect HUB also connects our MPLS "PE" via 802.Q trunk.
The problem is that we can have any dedicated lease connection such as
T1 or E1 from PE to Core router in Miami. The only thing we can have
is pulblic internet.
This is because main teleport is located in very isolated area...
Thus, we like to establish 1) GRE between our Core A and PE A and 2)
run MPLS inside of GRE.
Core A GRE----GRE PE A--802.Q---iDirect Hub--satellite---Netmodem--802.Q-CE
As soon as we got MPLS to our Core A, we can easily send to multple
cruiseline HQ via our existing MPLS VPN connection...
Basically, in this way, our customer, cruiseline HQ can have L3 VPN connection.
Also, we are coverting from exsiting Frame-relay connection to this MPLS VPN.
I will try to post real configuation some time next week.
Thanks
Jonsoo
On 8/18/05, Scott Morris <swm@emanon.com> wrote:
> Ok... So, build it out from the GRE standpoint. Make sure you have a
> functional GRE network. Then place MPLS on top of it. As Arun has
> mentioned as well, you'll have the "ip mtu" command as well as the
> "tag-switching mtu" command that can go on physical and logical interfaces.
> The tunnel would be your logical interface here.
>
> At this point, the GRE will belong on the "P" side of things which seems to
> me what you want to have happen. Are you considering the cruise ship to be
> your PE in this model, or the CE? If it's CE, then you won't be running
> MPLS over the vsat/tunnel most likely.
>
> Does that make the thought process flow better? Once that occurs, then it
> simply ecomes an exercise in manipulating MTU sizes to get what we want.
> Being a logical interface, to my knowledge, there's no real limit on what we
> can or can't do with MTU size in general. It defaults to 1500 on a tunnel
> just because that's normal thinking.
>
> Scott
>
> -----Original Message-----
> From: Jongsoo [mailto:bstrt2004@gmail.com]
> Sent: Thursday, August 18, 2005 10:43 AM
> To: swm@emanon.com
> Cc: Jamie Caesar; ccielab@groupstudy.com
> 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_note0918
> > 6a0080
> > > 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