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

[Joe Maimon]

Rodney,

Thanks for the news.

PPPoE should be enough.

Thanks for all your efforts,

Joe

Rodney Dunn wrote:

> 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/
>>>>>>
>>>>>>
>>>>>>
>>>
> 
>