[AusNOG] Cisco 6500 with Sup 720 3BXL - Good routing platform ??

[Lincoln Dale]

On 20/09/2010, at 2:26 PM, Dobbins, Roland wrote:

> 
> On Sep 20, 2010, at 11:16 AM, Jason Bailey wrote:
> 
>> However here in Australia ISPs have successfully used them for Netflow based billing for years.
> 
> I doubt that very seriously.  sh mls netflow table-contention will likely show a different side of things.
> 
> Also note that the NetFlow they generate isn't useful from a security perspective due to the limited mls table size, lack of packet-based sampling for control of flow generation (i.e., sampled NetFlow), lack of a logical OR of all TCP flags seen within a flow, and lack of accounting for dropped traffic.

sure, EARL8, software-based routers (e.g. c7200), programmable-h/w routers (GSR odd-numbered engines, ASR1K) can do all of the above, EARL7/7.5-based C6K cannot, but whether they are showstoppers depends on your application.
clearly if the intent is to send the netflow export records at an Arbor product, yes, its less useful information.  but just because its not perfect doesn't mean one need throw it out.

> 
>> An outright "not up to snuff for production use" isn't accurate. They 
>> route/switch packets/frames perfectly well.
> 
> I content that 6500/7600 with current hardware isn't a useful edge platform on any network of any size due to its NetFlow issues,

i'd content that Netflow is generally "good enough" if used within its limits.  clearly doing accounting on something that may be overflowing is not ideal.  but its still potentially useful information provided by it.
one can scale the Netflow tables through use of DFCs.

> uRPF issues,

certainly there are some uRPF quirks (global strict vs loose), but again those can be worked with in general.
again, EARL8 based platforms (e.g. N7K and coming to a C6K soon) have more 'flexibility' here.

> and ACL construction issues.

i'd content that historic challenges with ACLs are a thing of the past.  while its not the default, enabling OAL is definitely best practice and mitigates most of the issues.
<http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/acl.html#wp1090858>
(why its not the default is because we cannot change defaults.  but with NX-OS it is the default)

>  Many years of experience in dealing with countless problems caused by these deficiencies, both hands-on in networks for which I was responsible as well as working with SPs making use of these platforms in their own networks, have led me to this conclusion.

sure - just as the internet has evolved and the needs of the networks have, so have the products/technologies - within the limits of what the silicon supports.
what i'm eternally fascinated about is how the same silicon - 7 years on - is still deployable.
same cannot be said of many products/technologies!


cheers,

lincoln.