[c-nsp] Yet another "wont fix because its on the 7500"

[Rodney Dunn]

> Understandably, however, I am quite dissapointed with the answer received.

We are still trying to see what can be done. I'm just trying to make
it understood that some things on the surface would appear to be "just
a simple change" and that's not always the case.

> 
> I suppose this means that contrary to an outsiders assumption, this is a 
> deal more than a five line fix, or even hack.

That's exactly right.

> 
> I am quite happy testing the unsupported features for you guys, I seem 
> to do that every now and then anyways. I dont see how it would pose any 
> problem if its unsupported and works as opposed to it being unsupported 
> and doesnt work.

We'd much prefer unsupported and it work for sure or either not configurable.

> 
> I suppose a public appeal for all those that would like to be able to 
> have pppoe intefaces in a vrf with mpls (7500) to make themselves heard 
> is in order.

On record for that platform there have been two customer request ever
attached to that bug. So it's not amazing that work was never done to fix
it by adding the new feature functionality. The other customer was moving
their BB agg connections to a 72xx anyway so it ended there.

> 
> Even though pppoe is not distributed, you can easily do 250-500 users on 
> each rsp4, if everything else is being distributed.

No argument there. But again, it's still not recommended.

> 
> Note that I have long since lost hope for
> 
> - DCEF support turned on per subinteface

Never happen most likely. Same as for disabling dCEF on a per LC basis.

> - DCEF PPPoE as per L2TP and GRE (if those are in, how difficult is it 
> to do pppoe?)

The 75xx is not taking on new features for the most par.

> 
> The main conclusion is that the only thing the 7500 is usefull for is T1 
> aggregation and maybe a little dot1q.

Depends on the customer network. 

> 
> Joe
> 
> 
> 
> Rodney Dunn wrote:
> 
> > Joe,
> > 
> > It just so happens the TAC engineer that has this case sits beside
> > me. I'd been working with him on this to try and get a clear message
> > from the BU's. This is one of the main problems with the 75xx.
> > 
> > You can configure about every feature in IOS on it but they
> > are not all tested/supported due to it's distributed switching
> > architecture. This is one such feature combination.
> > 
> > We have passed the information to the PM's of the MPLS and
> > 75xx BU and it's their decision to make if they will dedicate
> > the time/resources to rewrite and set up testbeds to verify this
> > feature combination. Given only one or two customers have ever
> > asked for this on the 75xx it will probably not get added.
> > 
> > It's more than just fixing the switching vector to handle the
> > rewrites in the MPLS path. For us to claim support we have to
> > add it in testbeds to it's constantly tested and that is a business
> > decision by the BU's. The TAC engineer was trying very hard to get
> > the right answer for you even though it wasn't the answer you (or
> > us either for that matter) we were hoping to get.
> > 
> > I'm still trying to see if we can get it to work in the code without
> > a lot of extra work but it's not looking too good.
> > 
> > We can take this offline.
> > 
> > Rodney
> > 
> > 
> > On Mon, Apr 17, 2006 at 05:03:43PM -0400, Joe Maimon wrote:
> > 
> >>CSCed78665 Title: ICMP Echo-reply from c7507s tagged int. have corrupted 
> >>PPPoE header
> >>
> >>Took over six months for TAC to come back and say
> >>
> >>Since 7500 isnt targetted as broadband aggregation, its perfectly 
> >>acceptable that packets from tagged interfaces cant output properly to 
> >>pppox interfaces.
> >>
> >>This is crap.
> >>_______________________________________________
> >>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/
> > 
> > 
> >