[69226] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: MLPPP Follow Up - How we fixed the problem

daemon@ATHENA.MIT.EDU (Mark E. Mallett)
Wed Mar 31 16:12:45 2004

From: "Mark E. Mallett" <mem@mv.mv.com>
Date: Wed, 31 Mar 2004 16:12:08 -0500
To: "Richard J. Sears" <rsears@adnc.com>
Cc: nanog list <nanog@merit.edu>
Mail-Followup-To: "Richard J. Sears" <rsears@adnc.com>,
	nanog list <nanog@merit.edu>
In-Reply-To: <20040330123240.4CDB.RSEARS@adnc.com>
Errors-To: owner-nanog-outgoing@merit.edu


On Tue, Mar 30, 2004 at 12:36:37PM -0800, Richard J. Sears wrote:
> I asked the group some time ago about some problems we were seeing with
> MLPPP on our Cisco 7513s. 

  ...
> 
> ip route X.X.X.X 255.255.255.252 Serial1/0/0/13:0
> ip route X.X.X.X 255.255.255.252 Serial2/1/0/14:0
> 
> 
> The only problem that we ran into was that we had to use the Serial designator
> of the interface in our route statement otherwise it will not work (or
> at least it did not for us).
> 
> Since converting our customers (all MLPPP customers) to ip load-sharing
> per-packet - we have had no further problems.


FWIW I have also observed that it is necessary to specify the
interface when doing per-packet load balancing across multiple PVCs,
e.g. as when doing load balancing across multiple DSL circuits.  I
believe I mentioned this a while ago, but in a thread on a different
topic.  That solution was the result of grasping at straws:  it seems
that the router ought to be able to intuit the interface from the
target address, but apparently can not.  

mm

home help back first fref pref prev next nref lref last post