Thus spake Christian Meutes (christ...@errxtx.net) on Fri, Dec 21, 2018 at
02:41:23PM +0100:
> Depending on your requirements and scale - but I read you want history -
> it's probably less a demand on CPU or network resources, but more on IOPS.
>
> If you cache all results before writing to
Depending on your requirements and scale - but I read you want history -
it's probably less a demand on CPU or network resources, but more on IOPS.
If you cache all results before writing to disk, then it's not much of a
problem, but by just going "let's use RRD/MRTG for this" your IOPS could
Hi,
The link is not the only component to fail - routers and routing protocols all
contribute at least as much.
If your customers would have redundant connections,
you also would like to look at convergence times.
So a measurement end to end by a probe in the customers network could give
you a
YMMV... but most of the CPE routers I've seen lately have icmp turned
off by default, so you'll be messing with settings in the customer
router. Do you provide the router? Also agree with Baldur, 2
minutes... is more than likely the customer router rebooting itself or
something like that. If
On Sun, 16 Dec 2018 at 17:59, Stephen Satchell wrote:
> A standard ping packet, with no IP options or additional payload, is 64
> bytes or 512 bits. If an application wants to make an accurate
> round-trip-delay measurement, it can insert the output of a microsecond
> clock, and compare that
On 12/16/18 12:07 AM, Saku Ytti wrote:
> On Sun, 16 Dec 2018 at 00:48, Stephen Satchell wrote:
>
>> The 1500 bits are for each ping. So 1000 hosts would be 1,500,000 bits
>
> Why? Why did you choose 1500b(it) ping, instead of minimum size or
> 1500B(ytes) IP packets?
>
> Minimum: 672kbps
>
On Sun, 16 Dec 2018 at 00:48, Stephen Satchell wrote:
> The 1500 bits are for each ping. So 1000 hosts would be 1,500,000 bits
Why? Why did you choose 1500b(it) ping, instead of minimum size or
1500B(ytes) IP packets?
Minimum: 672kbps
1500B: 12.16Mbps
--
++ytti
Hi
Customers do not usually complain about 2 minutes of downtime unless it is
a repeating event. We will therefore offer such customers to put their line
on monitor mode, which means we will add them to smokeping. You could also
start the ping once a second thing, which would be no problem if it
On 12/15/18 12:03 PM, Saku Ytti wrote:
> On Sat, 15 Dec 2018 at 18:52, Stephen Satchell wrote:
>
>> Short answer: about 1500 bits of bandwidth, and the CPU loading on the
>
> I can't parse this.
>
> 1000 hosts at 1 pps would be 672kbps on ethernetII encapulation with
> minimum size frames.
>
On Sat, 15 Dec 2018 12:20:01 -0700, Raymond Burkholder said:
> Another aspect is congestion. Large uploads or downloads can cause
> packet loss (including dropping the pings with which you are testing).
> Therefore management packets such as these could be marked and
> processed, on your side
I have a Nagios installation running on a PIII with maybe 512 MB of RAM.
I ping a couple hundred devices 5 times per minute and have an alarm threshold
of no response for 3 minutes which sends an e-mail.
The same device also checks about 900 services among those 200 devices mostly
every minute
On Sat, 15 Dec 2018 at 18:52, Stephen Satchell wrote:
> Short answer: about 1500 bits of bandwidth, and the CPU loading on the
I can't parse this.
1000 hosts at 1 pps would be 672kbps on ethernetII encapulation with
minimum size frames.
--
++ytti
On 2018-12-15 11:32 a.m., Colton Conor wrote:
The problem I am trying to solve is to accurately be able to tell a
customer if their home internet connection was up or down. Example,
customer calls in and says my internet was down for 2 minutes
yesterday. We need to be able to verify that
Is RADIUS accounting an option here?
Dave
On Sat, 15 Dec 2018 at 18:32, Colton Conor wrote:
> The problem I am trying to solve is to accurately be able to tell a
> customer if their home internet connection was up or down. Example,
> customer calls in and says my internet was down for 2
I think the guys in the NOC will add a customer CPE to Solarwinds monitoring
and just have it continually run pings, and set up an alert so that we know as
soon as the ping stop the alerts go to email or whererver
Aaron
> On Dec 15, 2018, at 12:32 PM, Colton Conor wrote:
>
> The problem I am
The problem I am trying to solve is to accurately be able to tell a
customer if their home internet connection was up or down. Example,
customer calls in and says my internet was down for 2 minutes yesterday. We
need to be able to verify that their internet connection was indeed down.
Right now
In one of my client's company, we use LibreNMS. It is normally used to
get SNMP data but we also have it configured to ping our more "high
touch" cients routers. In that case we can record performance such as
latency and packet loss. It will generate graphs that we can pass on to
the client.
On 15/Dec/18 19:37, Baldur Norddahl wrote:
>
>
> BFD is the hardware solution.
Don't remind me that Juniper currently don't support BFD in hardware for
IS-IS- or OSPFv3-signaled IPv6 routing :-(.
Mark.
You could configure BFD to send out a SNMP alert when three packets have
been missed on a 50 ms cycle. Or instantly if the interface charges state
to down. This way you would know that they are down within 150 ms.
BFD is the hardware solution. A Linux box that has to ping 1000 addresses
per
On 12/15/18 7:48 AM, Colton Conor wrote:
> How much compute and network resources does it take for a NMS to:
>
> 1. ICMP ping a device every second
> 2. Record these results.
> 3. Report an alarm after so many seconds of missed pings.
>
> We are looking for a system to in near real-time monitor
How much compute and network resources does it take for a NMS to:
1. ICMP ping a device every second
2. Record these results.
3. Report an alarm after so many seconds of missed pings.
We are looking for a system to in near real-time monitor if an end
customers router is up or down. SNMP I assume
21 matches
Mail list logo
