This is a simple, quick-and-dirty, copy/paste guide to install a great software, pmacct, on a fresh Ubuntu 14.04.1 LTS (Trusty Tahr) setup. I’ll use this simple setup as the basis for other related posts I plan to publish soon.
Tl;dr: pmacct is a suite of tools to collect, filter and aggregate IP accounting data, which works with live traffic (libpcap), NetFlow v1/v5/v7/v8/v9, IPFIX, sFlow and ULOG.
A blog post is not enough to show the great features and possibilities that this tool offers, so I really recommend whoever may be interested to read author’s documentation on the official web site.
On a next post I plan to show some ideas to deploy pmacct together with ElasticSearch and Kibana, in order to build useful dashboards full of graphs. Add my RSS feed to your reader or follow me on Twitter to stay updated!
EDIT: the Integration of pmacct with ElasticSearch and Kibana post has been published.
Let’s start from a really simple setup here. Read more …
It seems that, under certain conditions, GMail reports failed SPF checks for messages fetched via POP3 from other mail servers.
I noticed this behaviour on messages received, for example, by mail servers where an internal relay is used, like the following message sent from PayPal (which uses an hard-fail policy):
Received-SPF: fail (google.com: domain of email@example.com does not
designate A.B.C.D as permitted sender) client-ip=A.B.C.D;
Received: by 10.64.225.172 with POP3 ...
X-Gmail-Fetch-Info: MYSELF@MYDOMAIN.TLD 3 pop3.MYDOMAIN.TLD
Received: from server1.MYPROVIDER.TLD (A.B.C.D)
by server2.MYPROVIDER.TLD with SMTP; ...
Received: from outbound.emea.e.paypal.com (22.214.171.124)
by mx1.MYPROVIDER.TLD with SMTP; ...
From: "PayPal" <firstname.lastname@example.org>
Read more …
Yesterday RIPE Labs announced a new test to measure propagation of longer than /24 IPv4 prefixes. The scope of these prefixes is to allow small allocations from the 23.128/10 net block that ARIN reserved to facilitate IPv6 deployment, but it could be impaired by filters and routing policies commonly deployed all around the net.
While looking forward to the RIPE results I couldn’t help glancing at the current situation as seen by a bunch of RIPE Atlas probes, so I performed some small tests on my own. Read more …
I released a small Python script which reads results from RIPE Atlas traceroute measurements and shows Autonomous Systems traversed by probes to reach the target: ripeatlastracepath.
UPDATE: the version of RIPE Atlas Tracepath that this post refers to is outdated. A new, totally rewritten version has been released.
The old version of this tool has been moved in the GitHub old_style branch
It uses a library that I wrote to cache RIPEstat results about IP addresses details (ASN, prefix, …), in order to improve performance and to avoid a flood of requests: ipdetailscache.
More details can be found on my GitHub profile page.
A demo can be found here. It can’t be used to process other measurements, it only shows results from measurement ID 1674977, a traceroute from 50 probes all over the world toward www.ripe.net. You can drag&drop ASes to build the layout that best describes your scenario and, once done, you can “save” the graph for later usage. In this demo the “Load graph” button gives a preset of JSON data representing the example graph below:
These scripts are not so elegant, but do the job! 😉 They are on GitHub.com, feel free to use/edit/fork/improve them as you whish!
The number of IPv4 prefixes in the global BGP table is approaching the limit of many Cisco products, such as 7600/6500 RSP720/Sup720 and some ASR1000, which may hold a maximum of ~500K routes in their FIB (the Forwarding Information Base, where only best paths are stored).
These routers can usually handle a bigger load of prefixes, they can also be used to receive the full BGP table from many upstream providers concurrently, but they can’t manage more than 500/512K entries in their RIB or FIB.
Read more …