[c-nsp] Netflow on SUP720-3BXL

[Andreas Bourges]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

On Sunday 15 March 2009 17:46:52 Andy BIERLAIR wrote:
> This is a critical environment and I cannot afford the downtime and
> possible side effects with a new IOS I haven't tested so far.

I understand - quite a few threads related to SXH bugs appeared on the list, 
but most of them seem to be fixed in SXH3 if I remember correctly...

> The mission I would like to achieve is not accounting for customers (would
> be nice to have though), but more an analysis tool that shows me how much
> traffic I am exchanging with a certain ASN, so that we can decide if direct
> peering with that ASN instead of paying transit to reach it makes sense or
> not.

What about setting the mls flow mask to destination-source? Should reduce the 
generated flows significantly - at least for HTTP traffic I would suspect...

http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SXF/native/configuration/guide/netflow.html#wp1057334

> So if for instance the Ops of ASN xxxx contact us to ask for peering on a
> public exchange, we look it up in our stats and if we see that the average
> traffic with ASN xxxx is 75 MBIT/s, we will probably peer. Right now I can
> only guess how much we exchange, so I need a more accurate solution and I
> was hoping that netflow is the key.

I think NetFlow _is_ the key - it's just an odd hardware limitation that hits 
you there ;-)

Regards,

Andy


>
> -
> Andy
>
> -----Original Message-----
> From: Andreas Bourges [mailto:andy-lists at bourges.de]
> Sent: 15 March 2009 17:18
> To: cisco-nsp at puck.nether.net
> Cc: Andy BIERLAIR
> Subject: Re: [c-nsp] Netflow on SUP720-3BXL
>
> - gpg control packet
> Hi,
>
> On Sunday 15 March 2009 15:45:30 Andy BIERLAIR wrote:
> > I'm trying to run netflow on one of our Cisco core routers (SUP720-3BXL
> > with SXF15a), but I think I am hitting some limitations because of this:
> >
> >   mls aging fast time 5 threshold 32
> >   mls aging long 300
> >   mls aging normal 60
> >
> > Then I have this enabled on all border interfaces/vlans (peering /
> > transit / other core routers) that are of interest for my stats:
> >
> >   ip route-cache flow
>
> This command only affects packets processed by the MSFC - so at least with
> your IOS it doesn't matter if you configured it on all interfaces or only
> on
>
> some. Once MLS NDE is activated, it exports all observed flows regardless
> of
>
> the "ip route cache flow" command...
>
> You could upgrade to an IOS >= SXH, which lets you enable mls nde on a per
> interface basis - this would (depending on your setup) reduce the amount of
> created flow entries (I suspect...).
>
> > I have heard that more agressive aging might help, but I expect the
> > router's traffic and pps to increase dramatically, so I'll be hitting the
> > roof over and over again.
> >
> > I wouldn't mind analyzing only every 10th or 100th flow (sampling), which
> > seems to be a common practice, but will it help?
>
> This won't help on 65K/76K, since they only support "flow-sampling" - which
> means all flows are created in the tcam but not all of them are exported to
> the collector (to reduce export load and collector load).
>
> > What is the common netflow setup without additional DFCs for a busy
>
> router?
>
> Since you are already equipped with Sup720-3BXL the one thing that can help
> is
> to set the mls aging timers more aggressive, I suppose.
> If (and I'm not sure about that) per-interface mls nde reduces the created
> flows in the tcam, an upgrade to SXH could help, too...
> Another thing would be to set the flow-mask to something different than
> "full"
> - which gives you less information but produces less flows, too. Depends
> on
> your needs.
>
> Regards,
>
> Andy

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkm9QysACgkQRrny/uOBVy4fZACgsEvjjL0lHtnuDDHWDz4ZdlOl
ytkAnRgLZdD+G2BvZBGdU5HNNMDgNnE4
=8H6C
-----END PGP SIGNATURE-----