MLPPP Problem with Cisco 7513

Anton L. Kapela kapela at mwdt.com
Wed Jan 7 18:20:54 UTC 2004


Richard J. Sears said:

> We have changed multilink bundles, tried different types of switching
> and route caching, turning on and off fragmentation - the only thing

[snip]

> dCEF is enable on both
> routers, however the problem remains the same even after disable dCEF.

Your last line, I think, is rather interesting.

I have a 7513 with essentially the same hardware as you (ct3, fe's, etc) and
was recently doing testing with red/wred. I had read the notes about dCEF
and how this changes/limits some of what one can do with red/wred; as with
dCEF enabled, the queueing happens on the VIP instead of the RSP.

During testing, I setup a wred config on several interfaces and everything
worked fine -- while using standard CEF. Later on, I enabled dCEF and began
to test (d)wred. I found the limitations on parameters were a killjoy, so I
tried backing out of dCEF/dwred.

Interestingly, I couldn't back out. Even if I negated all the wred commands
and disabled dCEF, the 'sh int' would still report the VIP was doing all the
work. After more attempts and various ideas, I just reloaded the damn thing
-- it came back up with, as I had hoped, the VIP no long doing wred, but
rather the RSP.

So, I wonder whether or not the mlppp instability isn't due to some obscure
or yet undiscovered dCEF bug and also if when you disable dCEF, it's not
really getting disabled. Maybe disable dCEF -- then reload? It may also help
to get more familiar with the forwarding path data takes in this scenario;
I'm not familiar with cisco's mlppp enough to know if all the encapsulation
and multi-link work happens rsp side or vip side.

> Cisco Internetwork Operating System Software
> IOS (tm) VIP Software (SVIP-DW-M), Version 12.2(13)T5,  RELEASE SOFTWARE

Also, instead of following 12.2, maybe try the 12.0(S) train, if you're not
needing specific features in 12.2. I've surveyed several other folks
recently about which version they run; 12.0 S-line seems to be the
least-hated and more-stable train. It sounds like (at this point) it'd be
worth trying just about anything to get the mlppp links stable. <G>

--Tk




More information about the NANOG mailing list