[88799] in North American Network Operators' Group
RE: MLPPP over MPLS
daemon@ATHENA.MIT.EDU (Peering)
Mon Feb 20 13:10:50 2006
Date: Mon, 20 Feb 2006 13:10:21 -0500
From: "Peering" <Peering@xspedius.com>
To: "Brent A O'Keeffe" <bokeeffe@csc.com>
Cc: <nanog@merit.net>
Errors-To: owner-nanog@merit.edu
This is a multi-part message in MIME format.
------_=_NextPart_001_01C63648.E9E0ECE9
Content-Type: text/plain;
charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
I've been told by Juniper that the MTU negotiation problem was fixed in
the 7.x versions. We're upgrading soon, so I hope to find out for
myself.
Diane Turley=20
Sr. Network Engineer=20
Xspedius Communications Co.=20
636-625-7178=20
-----Original Message-----
From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On
Behalf Of Brent A O'Keeffe
Sent: Monday, February 20, 2006 7:57 AM
To: Jon Lewis
Cc: Jon R. Kibler; nanog@merit.net
Subject: Re: MLPPP over MPLS
=09
=09
It may also be worth noting that if the provider is running
Juniper and not Cisco, there are fragmentation issues with certain
versions of Juniper code. The MLPPP session cannot agree on an MTU and
usually stop somewhere around 100 bytes if they do. The workaround is
to implement "ppp multilink fragment disable" on the Cisco Multilink
interface.=20
=09
Brent=20
=09
=09
=09
Jon Lewis <jlewis@lewis.org>=20
Sent by: owner-nanog@merit.edu=20
02/17/2006 03:38 PM=20
To
"Jon R. Kibler" <Jon.Kibler@aset.com>=20
cc
nanog@merit.net=20
Subject
Re: MLPPP over MPLS
=09
=09
On Fri, 17 Feb 2006, Jon R. Kibler wrote:
=09
> We have a customer that is implementing an MPLS network that
will have 2=20
> to 6 T1 feeds at some locations that will be using MLPPP for
channel=20
> bonding. This is a telco provided network that will be
customer managed.
=09
It's not clear from your message, but I'm assuming the MLPPP
will be from=20
PE to CE and that the MPLS you speak of is MPLS VPN. If that's
the case,=20
on the customer end, it's just a MLPPP, and on your end, it's an
MLPPP=20
with an "ip vrf forwarding foo" statement. It's probably more
than the=20
average CCNA can handle (but so are MLPPP, MPLS, and most day to
day IOS=20
config work). Anyone who actually uses IOS on a regular basis
(as opposed=20
to someone who crammed for an exam and knows squat) should have
no trouble=20
with it.
=09
> The customer is being told by their router vendor that an
MLPPP/MPLS=20
> network is 'too complex' to be managed by anyone except for
the router=20
> vendor's VARs or the telco. They indicated that it would be
impossible=20
> for the customer's router vendor certified network person to
come up to=20
> speed on MLPPP/MPLS configurations and manage such a network
-- that it=20
> takes years to adequately learn how to manage that type of
network=20
> configuration.
=09
I think someone may be confusing "providing MPLS service" with
"buying=20
MPLS service". A customer buying MPLS VPN service never sees
any of the=20
MPLS tags or messes with MPLS/tag-switching commands. There is
no added=20
complexity...or at least there doesn't need to be any.
=09
> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> Filtered by: TRUSTEM.COM's Email Filtering Service
> http://www.trustem.com/
> No Spam. No Viruses. Just Good Clean Email.
=09
=09
Virus-free, because I say it is...and I run Pine on Linux :)
=09
=09
----------------------------------------------------------------------
Jon Lewis | I route
Senior Network Engineer | therefore you are
Atlantic Net |
_________ http://www.lewis.org/~jlewis/pgp for PGP public
key_________
=09
=09
------_=_NextPart_001_01C63648.E9E0ECE9
Content-Type: text/html;
charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Message</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1528" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D314100918-20022006><FONT face=3DArial color=3D#0000ff =
size=3D2>I've=20
been told by Juniper that the MTU negotiation problem was fixed in the =
7.x=20
versions. We're upgrading soon, so I hope to find out for=20
myself.</FONT></SPAN></DIV><!-- Converted from text/rtf format -->
<P><SPAN lang=3Den-us><FONT face=3DArial size=3D2>Diane =
Turley</FONT></SPAN> <BR><SPAN=20
lang=3Den-us><FONT face=3DArial size=3D2>Sr. Network =
Engineer</FONT></SPAN> <BR><SPAN=20
lang=3Den-us><FONT face=3DArial size=3D2>Xspedius Communications =
Co.</FONT></SPAN>=20
<BR><SPAN lang=3Den-us><FONT face=3DArial =
size=3D2>636-625-7178</FONT></SPAN> </P>
<BLOCKQUOTE style=3D"MARGIN-RIGHT: 0px">
<DIV></DIV>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20
owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] <B>On Behalf Of =
</B>Brent=20
A O'Keeffe<BR><B>Sent:</B> Monday, February 20, 2006 7:57 =
AM<BR><B>To:</B> Jon=20
Lewis<BR><B>Cc:</B> Jon R. Kibler; nanog@merit.net<BR><B>Subject:</B> =
Re:=20
MLPPP over MPLS<BR><BR></FONT></DIV><BR><FONT face=3Dsans-serif =
size=3D2>It may=20
also be worth noting that if the provider is running Juniper and not =
Cisco,=20
there are fragmentation issues with certain versions of Juniper code.=20
The MLPPP session cannot agree on an MTU and usually stop =
somewhere=20
around 100 bytes if they do. The workaround is to implement "ppp =
multilink fragment disable" on the Cisco Multilink interface.</FONT>=20
<BR><BR><FONT face=3Dsans-serif size=3D2>Brent</FONT> <BR><BR><BR>
<TABLE width=3D"100%">
<TBODY>
<TR vAlign=3Dtop>
<TD width=3D"40%"><FONT face=3Dsans-serif size=3D1><B>Jon Lewis=20
<jlewis@lewis.org></B> </FONT><BR><FONT face=3Dsans-serif=20
size=3D1>Sent by: owner-nanog@merit.edu</FONT>=20
<P><FONT face=3Dsans-serif size=3D1>02/17/2006 03:38 PM</FONT> =
</P>
<TD width=3D"59%">
<TABLE width=3D"100%">
<TBODY>
<TR vAlign=3Dtop>
<TD>
<DIV align=3Dright><FONT face=3Dsans-serif =
size=3D1>To</FONT></DIV>
<TD><FONT face=3Dsans-serif size=3D1>"Jon R. Kibler"=20
<Jon.Kibler@aset.com></FONT>=20
<TR vAlign=3Dtop>
<TD>
<DIV align=3Dright><FONT face=3Dsans-serif =
size=3D1>cc</FONT></DIV>
<TD><FONT face=3Dsans-serif size=3D1>nanog@merit.net</FONT>=20
<TR vAlign=3Dtop>
<TD>
<DIV align=3Dright><FONT face=3Dsans-serif =
size=3D1>Subject</FONT></DIV>
<TD><FONT face=3Dsans-serif size=3D1>Re: MLPPP over=20
MPLS</FONT></TR></TBODY></TABLE><BR>
<TABLE>
<TBODY>
<TR vAlign=3Dtop>
<TD>
=
<TD></TR></TBODY></TABLE><BR></TR></TBODY></TABLE><BR><BR><BR><FONT=20
size=3D2><TT><BR>On Fri, 17 Feb 2006, Jon R. Kibler wrote:<BR><BR>> =
We have a=20
customer that is implementing an MPLS network that will have 2 =
<BR>> to 6=20
T1 feeds at some locations that will be using MLPPP for channel =
<BR>>=20
bonding. This is a telco provided network that will be customer=20
managed.<BR><BR>It's not clear from your message, but I'm assuming the =
MLPPP=20
will be from <BR>PE to CE and that the MPLS you speak of is MPLS VPN. =
If=20
that's the case, <BR>on the customer end, it's just a MLPPP, and on =
your end,=20
it's an MLPPP <BR>with an "ip vrf forwarding foo" statement. =
It's=20
probably more than the <BR>average CCNA can handle (but so are MLPPP, =
MPLS,=20
and most day to day IOS <BR>config work). Anyone who actually =
uses IOS=20
on a regular basis (as opposed <BR>to someone who crammed for an exam =
and=20
knows squat) should have no trouble <BR>with it.<BR><BR>> The =
customer is=20
being told by their router vendor that an MLPPP/MPLS <BR>> network =
is 'too=20
complex' to be managed by anyone except for the router <BR>> =
vendor's VARs=20
or the telco. They indicated that it would be impossible <BR>> for =
the=20
customer's router vendor certified network person to come up to =
<BR>> speed=20
on MLPPP/MPLS configurations and manage such a network -- that it =
<BR>>=20
takes years to adequately learn how to manage that type of network =
<BR>>=20
configuration.<BR><BR>I think someone may be confusing "providing MPLS =
service" with "buying <BR>MPLS service". A customer buying MPLS =
VPN=20
service never sees any of the <BR>MPLS tags or messes with =
MPLS/tag-switching=20
commands. There is no added <BR>complexity...or at least there =
doesn't=20
need to be any.<BR><BR>>=20
=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
<BR>> Filtered by:=20
TRUSTEM.COM's Email Filtering Service<BR>> =
http://www.trustem.com/<BR>>=20
No Spam. No Viruses. Just Good Clean Email.<BR><BR><BR>Virus-free, =
because I=20
say it is...and I run Pine on Linux=20
=
:)<BR><BR>---------------------------------------------------------------=
-------<BR> Jon=20
Lewis | =
I=20
route<BR> Senior Network Engineer | therefore =
you=20
are<BR> Atlantic Net =
=20
|<BR>_________ http://www.lewis.org/~jlewis/pgp for PGP public=20
key_________<BR></TT></FONT><BR></BLOCKQUOTE></BODY></HTML>
------_=_NextPart_001_01C63648.E9E0ECE9--
