MLPPP over MPLS

Mon Feb 20 18:10:21 UTC 2006

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 
Sr. Network Engineer 
Xspedius Communications Co. 
636-625-7178 

	-----Original Message-----
	From: owner-nanog at merit.edu [mailto:owner-nanog at 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 at merit.net
	Subject: Re: MLPPP over MPLS

	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. 

	Brent 

Jon Lewis <jlewis at lewis.org> 
Sent by: owner-nanog at merit.edu 

02/17/2006 03:38 PM 

To
"Jon R. Kibler" <Jon.Kibler at aset.com> 
cc
nanog at merit.net 
Subject
Re: MLPPP over MPLS

	On Fri, 17 Feb 2006, Jon R. Kibler wrote:

	> We have a customer that is implementing an MPLS network that
will have 2 
	> to 6 T1 feeds at some locations that will be using MLPPP for
channel 
	> bonding. This is a telco provided network that will be
customer managed.

	It's not clear from your message, but I'm assuming the MLPPP
will be from 
	PE to CE and that the MPLS you speak of is MPLS VPN.  If that's
the case, 
	on the customer end, it's just a MLPPP, and on your end, it's an
MLPPP 
	with an "ip vrf forwarding foo" statement.  It's probably more
than the 
	average CCNA can handle (but so are MLPPP, MPLS, and most day to
day IOS 
	config work).  Anyone who actually uses IOS on a regular basis
(as opposed 
	to someone who crammed for an exam and knows squat) should have
no trouble 
	with it.

	> The customer is being told by their router vendor that an
MLPPP/MPLS 
	> network is 'too complex' to be managed by anyone except for
the router 
	> vendor's VARs or the telco. They indicated that it would be
impossible 
	> for the customer's router vendor certified network person to
come up to 
	> speed on MLPPP/MPLS configurations and manage such a network
-- that it 
	> takes years to adequately learn how to manage that type of
network 
	> configuration.

	I think someone may be confusing "providing MPLS service" with
"buying 
	MPLS service".  A customer buying MPLS VPN service never sees
any of the 
	MPLS tags or messes with MPLS/tag-switching commands.  There is
no added 
	complexity...or at least there doesn't need to be any.

	> ==================================================
	> Filtered by: TRUSTEM.COM's Email Filtering Service
	> http://www.trustem.com/
	> No Spam. No Viruses. Just Good Clean Email.

	Virus-free, because I say it is...and I run Pine on Linux :)

----------------------------------------------------------------------
	 Jon Lewis                   |  I route
	 Senior Network Engineer     |  therefore you are
	 Atlantic Net                |
	_________ http://www.lewis.org/~jlewis/pgp for PGP public
key_________

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20060220/84d33932/attachment.html>