<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Message</TITLE>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2800.1528" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=314100918-20022006><FONT face=Arial color=#0000ff size=2>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.</FONT></SPAN></DIV><!-- Converted from text/rtf format -->
<P><SPAN lang=en-us><FONT face=Arial size=2>Diane Turley</FONT></SPAN> <BR><SPAN
lang=en-us><FONT face=Arial size=2>Sr. Network Engineer</FONT></SPAN> <BR><SPAN
lang=en-us><FONT face=Arial size=2>Xspedius Communications Co.</FONT></SPAN>
<BR><SPAN lang=en-us><FONT face=Arial size=2>636-625-7178</FONT></SPAN> </P>
<BLOCKQUOTE style="MARGIN-RIGHT: 0px">
<DIV></DIV>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left><FONT
face=Tahoma size=2>-----Original Message-----<BR><B>From:</B>
owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] <B>On Behalf Of </B>Brent
A O'Keeffe<BR><B>Sent:</B> Monday, February 20, 2006 7:57 AM<BR><B>To:</B> Jon
Lewis<BR><B>Cc:</B> Jon R. Kibler; nanog@merit.net<BR><B>Subject:</B> Re:
MLPPP over MPLS<BR><BR></FONT></DIV><BR><FONT face=sans-serif size=2>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.</FONT>
<BR><BR><FONT face=sans-serif size=2>Brent</FONT> <BR><BR><BR>
<TABLE width="100%">
<TBODY>
<TR vAlign=top>
<TD width="40%"><FONT face=sans-serif size=1><B>Jon Lewis
<jlewis@lewis.org></B> </FONT><BR><FONT face=sans-serif
size=1>Sent by: owner-nanog@merit.edu</FONT>
<P><FONT face=sans-serif size=1>02/17/2006 03:38 PM</FONT> </P>
<TD width="59%">
<TABLE width="100%">
<TBODY>
<TR vAlign=top>
<TD>
<DIV align=right><FONT face=sans-serif size=1>To</FONT></DIV>
<TD><FONT face=sans-serif size=1>"Jon R. Kibler"
<Jon.Kibler@aset.com></FONT>
<TR vAlign=top>
<TD>
<DIV align=right><FONT face=sans-serif size=1>cc</FONT></DIV>
<TD><FONT face=sans-serif size=1>nanog@merit.net</FONT>
<TR vAlign=top>
<TD>
<DIV align=right><FONT face=sans-serif size=1>Subject</FONT></DIV>
<TD><FONT face=sans-serif size=1>Re: MLPPP over
MPLS</FONT></TR></TBODY></TABLE><BR>
<TABLE>
<TBODY>
<TR vAlign=top>
<TD>
<TD></TR></TBODY></TABLE><BR></TR></TBODY></TABLE><BR><BR><BR><FONT
size=2><TT><BR>On Fri, 17 Feb 2006, Jon R. Kibler wrote:<BR><BR>> We have a
customer that is implementing an MPLS network that will have 2 <BR>> to 6
T1 feeds at some locations that will be using MLPPP for channel <BR>>
bonding. This is a telco provided network that will be customer
managed.<BR><BR>It's not clear from your message, but I'm assuming the MLPPP
will be from <BR>PE to CE and that the MPLS you speak of is MPLS VPN. If
that's the case, <BR>on the customer end, it's just a MLPPP, and on your end,
it's an MLPPP <BR>with an "ip vrf forwarding foo" statement. It's
probably more than the <BR>average CCNA can handle (but so are MLPPP, MPLS,
and most day to day IOS <BR>config work). Anyone who actually uses IOS
on a regular basis (as opposed <BR>to someone who crammed for an exam and
knows squat) should have no trouble <BR>with it.<BR><BR>> The customer is
being told by their router vendor that an MLPPP/MPLS <BR>> network is 'too
complex' to be managed by anyone except for the router <BR>> vendor's VARs
or the telco. They indicated that it would be impossible <BR>> for the
customer's router vendor certified network person to come up to <BR>> speed
on MLPPP/MPLS configurations and manage such a network -- that it <BR>>
takes years to adequately learn how to manage that type of network <BR>>
configuration.<BR><BR>I think someone may be confusing "providing MPLS
service" with "buying <BR>MPLS service". A customer buying MPLS VPN
service never sees any of the <BR>MPLS tags or messes with MPLS/tag-switching
commands. There is no added <BR>complexity...or at least there doesn't
need to be any.<BR><BR>>
==================================================<BR>> Filtered by:
TRUSTEM.COM's Email Filtering Service<BR>> http://www.trustem.com/<BR>>
No Spam. No Viruses. Just Good Clean Email.<BR><BR><BR>Virus-free, because I
say it is...and I run Pine on Linux
:)<BR><BR>----------------------------------------------------------------------<BR> Jon
Lewis | I
route<BR> Senior Network Engineer | therefore you
are<BR> Atlantic Net
|<BR>_________ http://www.lewis.org/~jlewis/pgp for PGP public
key_________<BR></TT></FONT><BR></BLOCKQUOTE></BODY></HTML>