The Perl Net::Netmask module is also worth checking out. It may not be
better at aggregation but it does have other functions that could be
helpful. I use the shortest match address lookup functions of Net::Netmask
very heavily and have reproduced them in a R / C++ package.
Jon
On Thu, Oct 1, 202
This is what I have done using R:
https://github.com/meekj/netblockr
I still use similar tools in Perl with Net::Netmask
Jon
On Fri, Oct 2, 2020 at 11:50 AM Royce Williams
wrote:
> The recent thread on CIDR aggregation cleanup scripts reminds me that I'm
> looking for a similarly efficient im
A note on using a Raspberry Pi as a NTP server. In my limited home lab
testing the RPi server had enough instability that Internet time sources
were always preferred by my workstation after ntpd had been running for a
while. Presumably this was due to the RPi's clock frequency drifting. At
some poi
Another way to get on their block list is to have a lot of users behind a
single NAT or proxy IP address. In my experience they blocked single IPs.
The first time it was easy to explain that there were 30,000 users behind
the single address and get the block cleared. After that it became more
diffi
On Mon, Jul 16, 2018 at 2:00 PM Chris Gross
wrote:
> I'm curious what people here have found as a good standard for providing
> solid speedtest results to customers. All our techs have Dell laptops of
> various models, but we always hit 100% CPU when doing a Ookla speedtest for
> a server we have
I have the "opposite problem". I use iperf to test WAN and VPN
throughput and packet loss, but find that the sending Linux system
starts out with the expected MTU / MSS but then ramps up the packet
size to way beyond 1500. The result is that network equipment must
fragment the packets. On higher ba
On Thu, Aug 22, 2013 at 1:06 PM, Stefan wrote:
> I've been toying with Live distros (CD, then USB) for many years, in
> support of security toolsets, to which I kept adding my own stuff, or
> customizing existing components.
>
> I am now trying to "build" a network toolset LiveCD/USB, but this ti
On Thu, Aug 22, 2013 at 9:17 PM, Christopher X. Candreva
wrote:
> On Thu, 22 Aug 2013, Stefan wrote:
>
> > a completely different purpose: I would like to put it in the hands of
> all
> > remote offices we have on our network, and use it to have local systems
> > boot out of it, and help us then r
On Fri, Apr 9, 2010 at 5:57 PM, Christopher Morrow
wrote:
> On Fri, Apr 9, 2010 at 2:09 PM, William Duck wrote:
>> http://code.google.com/p/capirca/
>> Developed internally at Google, this system is designed to utilize
>> common definitions of networks and services and high-level policy
>>
One of the ways that I have tormented WAN vendors over the years is
with a plot of RTT vs. great circle distance between the end points of
a circuit. Most RTTs usually sit at some constant offset above that
Physics limit straight line. Circuits taking a less than ideal have
their RTT far above the
mon ( http://mon.wiki.kernel.org/index.php/Main_Page )
comes with traceroute.monitor
It keeps a state file of current routes and logs only changes. You can
specify equivalent hops, hops to ignore, StopAt addresses, and
UnexpectedHops.
Since it is part of mon, it is easy to alert on a route change
I use iperf with packet capture on both sides, then analyze the packet
capture for per-second throughput and re-transmits. I usually do 10
TCP streams for 30 seconds.
Note that on GigE with significant RTTs (5-15 ms) some TCP tuning is
needed to deal with the bandwidth delay product. It is also po
We use iperf running off of a bootable Linux CD
with a 2.4 Kernel and can push 960 to 980 Mbps
with no drops or errors on any pair of PCs with
Gig interfaces we have tried so far.
We usually 10 TCP streams, or tune the TCP stack
and use a single stream.
We also capture the traffic on both sides,
My Solaris 10 boxes are all happy (and did not reboot). I monitor NTP
on a number
of devices, including one router. The router was off by one second for
a while, but
is OK after an hour. Everything else was fine immediately.
In 2005, our CDMA clock got the leap second between 15:08 and 15:38
EST c
A visual comparison of my Sprint phone and xclock with second hand on a
synchronized workstation suggests that they have not yet implemented the
leap second.
Our single CDMA NTP clock did handle the leap second at the correct moment.
However, that CDMA clock is West of Philadelphia and I am in New
I have had the same problem and solved it with a rare (even then)
100BT Only hub. I still have at least one stashed away.
For years though, I have been using bonding on Linux to combine multiple
tap streams. We also use hardware aggregators for the higher volume
applications.
Jon
On Thu, Jul 31,
I have a "DNSaudit" program that takes libpcap (wireshark/tcpdump)
files. Originally its purpose was to identify AnswersWithoutQuestions,
and QuestionsWithoutAnswers when we were having some routing issues
causing answers to return via a different ISP.
Later I added statistics for response time by
There is a wealth of information in Ubiquti's forums:
http://ubnt.com/forum/
Jon
On Thu, Mar 4, 2010 at 1:44 PM, Todd Mueller wrote:
> Anyone have any real-world experience with Ubiquti's MIMO PTP equipment?
> We're looking to shoot data at distances of a few hundred feet up to 2-3
> miles. Re
Avocent / Cyclades boxes have ACL capability (they run Linux) and can
be used with EV-DO/GSM modems. They may not be the lowest cost
solution, but there is a central management system and a wide range of
serial interface units from single port to at least 32 ports.
Jon
Full disclosure: I was a mem
I use both EndRun Technologies and the "Garmin 18x LVC + old PC" solution.
I am currently seeing 8+ satellites out a North facing window almost
all of the time with the Garmin. The window method may not work if the
window is coated with a metallic layer (common in newer buildings).
Also, be carefu
On Sun, Feb 13, 2011 at 11:36 AM, Nick Hilliard wrote:
> On 13/02/2011 15:30, Joe Hamelin wrote:
>
>> day. I remember days spent hunting down ring-no-answers in a 400 POTS
>> line hunt group.
>>
>
> It was much easier to detect those by looking for strange port connectivity
> patterns in the log
21 matches
Mail list logo
