Simon Leine writes: > In many cases there are technical reasons that can explain why features > don't coexist well. For example regarding NAT and NDE on the PFC3: > They > both use the same hardware Netfow table, but it has to be managed > somewhat differently, as Gerd mentioned. It would probably be possible > to make them coexist, but that would require work (coding, testing > etc).
Right. Except that the documentation explicitly mentions caveats with NDE and Hardware Assisted NAT including flowmask restrictions and a known bug with fragmented packets. I think it' reasonable to assume if the documentation for the specific hardware mentions configuring them but warning about known caveats, you would think they work together except for the caveats. The only reason I can think of the reason for documenting the caveats is that it used to work, but some change broke it. If it never worked, there would be no reasons for caveats, rather just a mention that it isn't supported. It took 3 weeks with TAC including a network sniffer trace file to prove to the tech it didn't work. When he escalated it to backline BU engineering, he found out it wasn't supported. It isn't even well known within Cisco. I really don't think a consultant or TME would have found this limitation either. The whole purpose of this thread is just to have it documented in the nsp archives/google, not to start an argument. As far as configuring in a lab, that would be nice, but we hardly have the time for that including setting up a test netflow collector and sending through test data, just to confirm a feature that Cisco market literature advertises. It would be nice to spend the time setting up RFP and test labs to verify vendor claims, but there is no way I can spend the resources to do such at the firm where I work. My time is devoted to actual implantation (we are a algorithmic trading firm). I am sure there are some good consultants out there, but ones that understand market data issues well and the network designs that support them are few and far between. The equipment we put in place at the NYSE colo has worked perfectly as far as delivering packets (iBGP, multicast, layer2/3 switching, and hardware assisted nat). The monitoring that netflow would provide would be very valuable, but isn't a show stopper. At some point, you just have to do your best and go with what you have. I've got 20+ years of cisco experience including a lot of hands on with Sup1A, Sup2, Sup32, Sup720, etc, and this is the first time I've run into a feature limitation with not so much as a caveat or hint of possible limitations. _______________________________________________ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
