ISP / Hosting Company Needs...

Hello,

1.1 In each sensor manual you can find detailed information about how to add sensors and what are the requirements

1.2 Can you please explain in few more details what you mean with "exportable"?

1.3 Please have a look at this video tutorial regarding the bandwidth monitoring with Flows and Packet Sniffing.

Please have a look at this video tutorial regarding the SNMP Custom sensor.

2.0-2.3 This is possible using a Packet Sniffer sensor or Flow sensors. For more details please have a look at this article.

Hi Jochen,

I'm aware of the sniffing sensors, and i have configures many SPAN and RSPAN sessions for the police, etc however, please keep in mind the following:

1. We will be pushing around 60 Gb/s of traffic at any given time over the network.

2. All this traffic will be Exiting our network over an etherchannel between our Core and Distribution.

3. We do not really want to monitor the edge because we will be a transit system.

4. We want to monitor the traffic once its in our core network.

Network scenario.

Router A: This router handles all the BGP, ISP, Peering and the etherchannel to the Distribution of our network Router B: This router handles all the L3 functionality and has as its ONLY exit, the etherchannel to Router A. The Router B will Always send all its traffic out to Router A, and will receive all the incoming traffic from Router A as well.

Given this situation, we cant expect to SPAN or RSPAN that about of traffic (60Gb/s) at least. I would like to know what would you advise on this particular scenario.

If you need a network diagrram, i can create one and provide a link to it, if it makes things easier. Again, thanks for your time.

Ezequiel

Hello Foster,

Using netflow (or sflow, jflow, ipfix) for traffic analysis will work fine in a 10G environment but it´s not build to analyse 60gb/s traffic. However, the netflow sensors and the packet sniffer sensor work differently: they don't send out queries. Rather, they passively wait for the flow data or the traffic to arrive, and then analyse it.

For netflow, since you can define a sampling rate, you can configure the switches to send less netflow data, if it turns out to be a problem in an 10G network. So flow sensors are also fine with 10G.

However, the packet sniffer is a special case: it receives a copy of *every* packet, so it is possible to overload a PRTG server by sending it too much traffic. The PRTG server (or the machine with the remote probe) has to not only receive and processes every packet on its NIC - it also needs to evaluate the contents of the packet to create the results for the sensor, which creates a heavy load on the server.

Paessler simply doesn't focus on in-line deep-level packet inspection -- it's just not a feature that we offer. The PRTG packet sniffer was never meant as a competitor for packet inspection tools. Rather, it's meant for customers who want information similar to netflow but who don't have netflow available. For this reason, we also don't test our packet sniffer at 10G.