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

[Rodney Dunn]

Hey Joe,

Better late and partial than never and none. :)

CSCed78665 ICMP Echo-reply from c7507s tagged int. have corrupted PPPoE header

is now fixed and should be picked up in the next 12.4 maintenance release.

12.4(13) probably as 12.4(12) is already in testing.

I said "partial" because PPPoA will not work and they are not going
to change that. They were able to fix and test the PPPoE scenario.

Rodney



On Tue, Apr 25, 2006 at 03:35:51PM -0400, Joe Maimon wrote:
> Rodney,
> 
> My sincere appreciation for yours and your colleagues efforts on my behalf.
> 
> Thank you.
> 
> Joe
> 
> Rodney Dunn wrote:
> 
> > Joe,
> > 
> > I had a meeting with deveopment on this today. They are investigating
> > how much work it would take to get this feature combination to work
> > even though it was never intended to work on this platform.
> > 
> > Their plan is to get back with me in 1 week with a yes or no decision
> > and I'll pass it on to you.
> > 
> > I tried to convey both sides of the issue to them and I also understand
> > their position. At the end of the day it's their call to make.
> > 
> > Rodney
> > 
> > On Tue, Apr 18, 2006 at 12:01:07PM -0400, Rodney Dunn wrote:
> > 
> >>>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/
> >>>>
> >>>>
> >>>>
> > 
> >