[30306] in North American Network Operators' Group
Re: Netflow Type 7 (was RE: bw usage?)
daemon@ATHENA.MIT.EDU (Dana Hudes)
Wed Jul 26 12:28:59 2000
Message-ID: <003f01bff71e$4ec24fa0$3d5cdcd1@hudes.org>
From: "Dana Hudes" <dhudes@hudes.org>
To: <rdobbins@netmore.net>, <nanog@merit.edu>
Date: Wed, 26 Jul 2000 12:26:52 -0400
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Errors-To: owner-nanog-outgoing@merit.edu
Usually you don't want type 7, you want type 5. Let cflowd et al have =
the full data. Type 7 the router has done aggregation for you. Good for =
reducing
overall data rate to the flow capture system but bad for seeing what's =
going on in your network.
----- Original Message -----=20
From: <rdobbins@netmore.net>
To: <nanog@merit.edu>
Sent: Wednesday, July 26, 2000 12:11 PM
Subject: Netflow Type 7 (was RE: bw usage?)
>=20
>=20
> Does anyone know of a tool like Cflowd which will capture Netflow Type =
7
> stats? The only one I know of is the commercial product from Cisco; =
any
> advice would be greatly appreciated.
>=20
> -----------------------------------------------------------
> Roland Dobbins <rdobbins@netmore.net> // 818.535.5024 voice
> =20
>=20
> -----Original Message-----
> From: Alex [mailto:alex@nac.net]
> Sent: Wednesday, July 26, 2000 8:23 AM
> To: David M. Ramsey
> Cc: nanog@merit.edu
> Subject: Re: bw usage?
>=20
>=20
>=20
>=20
>=20
>=20
> On Wed, 26 Jul 2000, David M. Ramsey wrote:
>=20
> > For now I've cobbled together some crude software to regularly=20
> > read SNMP port byte in/out counters from our switches, stashing=20
> > the deltas in a DB for later reporting/analysis.
>=20
> We do about the same thing, but we store absolute byte counts, =
relative
> byte counts from the last measurement, and figure the kb/s; we also =
store
> AdminStatus and OperStatus for SLA purposes.=20
>=20
>=20
> > I'm concerned that the data is misleading, though, in that it will
> > include LAN broadcast traffic. Also, customers end up paying=20
> > for other bandwidth that they did not want or induce, like network=20
> > scans, etc. (tough luck?).
>=20
> Exactly, tough. If they use the bandwidth, then they should pay for =
the
> bandwidth.
>=20
>=20
> > We've considered implementing unique customer VLANS to separate
> > customer broadcast domains, but it seems like that'd be a pain,
> > would eat up IP addresses, and possibly tax our routers with all of
> > the ISL/VLAN stuff?
>=20
> We do that; it's unwise to have everyone on the same VLAN, as some =
others
> have demonstrated.
>=20
>=20
