[nsp] NPE-G1

[Warren Kumari, PhD, CCIE# 9190]

Actually, I tested both the NSE-100 and the NPE-G100. For pure speed, 
the NSE-100 (with the right code on it and under the right conditions) 
was really fast. Unfortunately the right conditions meant making sure 
that you ONLY used things that were PXF accelerated! In a purely static 
environment with thing tuned just so, we managed to get fairly close to 
the quotes 3.5Mpps (by purely static I mean no routing protocols and 
not touching the console / logging in / breathing). If the PXF complex 
crashed (not uncommon!) or you changed anything that made the box 
unable to use the PXF for forwarding, the performance dropped to 
200,000-300,000pps. Unfortunately, finding out what is PXF accelerated 
and what is not is not always easy. Eg.

Example1:
class-map match-all MatchDSCPACL
   match access-group name MatchDSCP
!
ip access-list extended MatchDSCP
  permit ip any any dscp ef
!

Example2:

class-map match-all MatchDSCP
   match  dscp ef

Example 1 is PXF accelerated, but Example 2 is not. (The Example 2 does 
the same thing as Example 1, but in the version of code that I tested, 
matching on DSCP in the class map instead of matching on an ACL that 
matches on DSCP means that the CPU needs to touch the packets). If you 
use Example 1, the PXF will do all of the QoS quite happily, but at 
high packet rates the PXF sends so many statistics records that the CPU 
becomes overwhelmed. (We had the PXF running at around 30-40% 
utilization, but the processor hit 100% and then the box died - I have 
heard that his issue is being addressed and statistics will be 
aggregated by the PXF before being handed to the CPU).

There are some other weird things with the NSE-100, for example, IOS 
upgrades. The PXF is actually implmented in an FPGA and the PXF code is 
bundled with the IOS. If you upgrade IOS, it needs to upgrade the 
FPGAs, which is a really time-consuming operation (something like 15 
minutes) during which time the device is not forwarding. If you lose 
power / the device crashes during the FPGA upgrade they can become 
corrupt, requiring an RMA.

There were many other just weird things like commands suddenly not 
working, ACLs not matching correctly until a reload. Another thing that 
annoys me about the 7304 is that in order to install second routing 
engine you loose 2 slots, so you have have a single NPE device with 4 
slots of a fully redundant box with 2 slots...

Warren.

On Jan 29, 2004, at 11:32 PM, Andrew Fort wrote:

> Warren Kumari wrote:
>
>> Hi,
>>
>> I think you may be speaking about the NPE-G100, not the NPE-G1. The 
>> 7304 takes the NPE-G100 and the 7206 takes the NPE-G1 (with has the 
>> I/O controller built in!).  I have had some very bad experiences with 
>> the 7304, mainly in lab tests (with the box under high load applying 
>> or removing an ACL would have no effect), but also some crashes in 
>> production.
>
>
> Although you're implying it, were your bad experiences with 7304 with 
> NSE-100, or with NPE-G100?   In the (limited) testing I've been 
> involved with (on both cards), the NSE-100 card underimpressed, while 
> the NPE-G100 showed stable in comparison, certainly in terms of 'pure 
> routing' performance (i.e., no tunneling or associated encapsulation). 
>  I didn't perform the test you did, though :).  This mirrors 7200 
> NSE-1 (and C10k5) experiences I've had.  It would seem that the PXF 
> platforms require very intensive testing of the target environment, 
> moreso than usual.
>
>
>
>
>
> _______________________________________________
> 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/
>
>
-- 
American Non-Sequitur Society;
we don't make sense, but we do like pizza!