[c-nsp] Cisco MultiLink PPP

[Lawrence Wong]

On the topic of 12.0S, do you know if the access list
numbering feature will be ported back to 12.0S? One
main reason why we used 12.2S on our 7505 is because
the access list numbering feature allows us to edit
our ACLs on the fly if need be.

--- Rodney Dunn <rodunn at cisco.com> wrote:
> I've worked through a lot of those bugs on the 75xx
> and we did have some bad ones.
> 
> All the ones I know of have been fixed in later
> 12.0S 
> code and latest 12.2 and 12.3 mainline
> code.
> 
> You were most likely hitting:
> 
> CSCed29590
> Multilink PPP link flap causes output frozen for
> member link
> 
> which was the worst one.
> 
> I've seen lots of large customers running dMLP on
> a 75xx running stable for over a year.
> 
> My recommendation would be 12.0(27)S4 or 12.3(13).
> 
> What I find is most people don't have the box setup
> properly to be running in fully distributed mode so
> the
> bundles are distributed and/or their VIPs don't have
> the
> CPU power to handle the bundles.
> 
> 
> Rodney
> 
> 
> CSCeg28064
> Internally found moderate defect: Assigned (R)
> cbus complex results in incorrect multilink state
> 
> CSCeb31029
> Internally found moderate defect: Resolved (R)
> Output rates incorrect on dMLP/dMFR/dLFI interfaces
> under congestion
> 
> CSCee69493
> Externally found moderate defect: Resolved (R)
> dMLP fails if control is given to IOS MLPPP
> 
> CSCin36465 Watchdog crashed because of MLPPP
> 
> CSCin47712 txacc loss after OIR
> 
> CSCec00268 Input drops and * throttles on PPP
> multilink interface
> 
> CSCea59948 Output stuck on a T3 Port Adaptor
> 
> CSCec87815
> Multilink buffer header leak on a VIP with an ATM PA
> installed
> 
> CSCed29590
> Multilink PPP link flap causes output frozen for
> member link
> 
> CSCin55432
> Internally found moderate defect: Resolved (R)
> Spurious memory access at vipmlp_change_primary
> 
> 
> On Thu, Mar 24, 2005 at 06:01:48AM -0800, David
> Barak wrote:
> > 
> > --- Lawrence Wong <lawrencewong72 at yahoo.com>
> wrote:
> > <questions regarding MLPPP>
> > 
> > Cisco MLPPP mostly works, but there are a couple
> of
> > really bad gotchas.  My experience with it is
> watching
> > it NOT work on 75xx series routers.  More
> accurately,
> > it would work, but when a T1 would bounce and
> recover,
> > a show command would cause the router to reload. 
> That
> > was not resolved as of last October (when I left
> the
> > company which had the case open).
> > 
> > My overall impression is that MLPPP is relatively
> > flaky.  I could recommend MLFR for point-to-point
> > circuits, but that can be kind of flaky too (lots
> of
> > problems in initial code releases), although I've
> now
> > got some customers using this, and it's working
> most
> > of the time.
> > 
> > Do you own both ends of the circuit?
> > 
> > -David Barak
> > need Geek Rock?  Try The Franchise!
> > http://www.listentothefranchise.com
> > 
> > 
> > 		
> > __________________________________ 
> > Do you Yahoo!? 
> > Make Yahoo! your home page 
> > http://www.yahoo.com/r/hs
> > _______________________________________________
> > cisco-nsp mailing list  cisco-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at
> http://puck.nether.net/pipermail/cisco-nsp/
> 


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/