Tag: networking

Netflow traffic monitoring on Debian

by mithrandi on Mar.06, 2010

Thanks to some trailblazing by Jonathan, I was able to set this up quickly the other day, and I thought I’d lay out the process to make it easier for anyone else trying to do the same thing.

First up, we need a netflow emitter and collector:
# aptitude install fprobe-ulog nfdump

Note that the default collector address/port in the fprobe-ulog configuration does not match the default port for nfcapd; you’ll probably want to enter “localhost:9995″ when prompted by debconf. Next, we’ll set nfcapd up by editing /etc/default/nfdump to look like this:

DAEMON_ARGS="-D -b 127.0.0.1 -l $DATA_BASE_DIR -S 1 -P $PIDFILE"
nfcapd_start=yes

We override the default DAEMON_ARGS to add some important options. -b 127.0.0.1 ensures that we only bind to localhost; -S 1 selects the year/month/day subdirectory hierarchy for the data files that get written out, which makes it easier to select a particular date range when using nfdump later.

Next, we need to add iptables rules to send traffic to ULOG so that fprobe-ulog can process it. Exactly how you accomplish this depends on what you’re using to set up your firewall rules, and what traffic you want to monitor; assuming everything, you would want rules like these:

# iptables -A INPUT -j ULOG --ulog-qthreshold 50 --ulog-cprange 48
# iptables -A FORWARD -j ULOG --ulog-qthreshold 50 --ulog-cprange 48
# iptables -A OUTPUT -j ULOG --ulog-qthreshold 50 --ulog-cprange 48

You should probably put them right at the end of the INPUT/FORWARD/OUTPUT chains, or wherever you ACCEPT traffic.

Make sure both daemons are started:
# invoke-rc.d fprobe-ulog start
# invoke-rc.d nfdump start

Now your flows are hopefully being logged. The data will only actually be written out to disk every 5 minutes, or so; grab a cup of coffee, and then try this command when you get back:

# nfdump -R /var/cache/nfdump -s port/bytes

You should get a list of the top 10 flows grouped by port, and sorted by bytes transferred. If there aren’t any results at all, make sure that your ULOG rules are actually running, by inspecting the counters in the output of iptables -nvL.

Hooray, you’re done! Read nfdump(1) for more information, including how to specify filters; you now have the ability to drill down into your traffic data in a very versatile way.

EDIT: Remove reference to lenny; I actually did this on sid.

Leave a Comment :, , more...

Dual-path routing with Quagga

by mithrandi on Mar.21, 2007

tags:

Well, I guess it took me long enough, but as promised, how I setup dual-path routing with Quagga. But first, thanks and credit to Colin and Jonathan for helping me out with this on IRC; as they had done similar work before, it was a lot easier than blazing the trail myself.

So, what the heck am I talking about? Let’s start off with a little background for those of you unfamiliar with the state of ADSL internet access in South Africa. Aside from the costs paid to the local telecommunications monopoly for the physical service provision, there is also an ISP charge for actually getting onto the internet, which includes charging for bandwidth usage (throughput). Exact pricing varies slightly between ISPs, but is mostly the same across the board, so I’ll quote prices from the ISP I use. To cut a long story short, I pay about R70 (US$9.46) per GB of international transfer (in both directions), but I can get local-only connectivity at a much cheaper rate of around R4.33 (US$0.59) per GB. This clearly makes it economically advantageous to do local transfers over a local-only account.

So, how to do it? My internet gateway, elvandar, is naturally running Debian GNU/Linux, so this can easily be setup. Please note that the following instructions are primarily designed for a Debian system, and your mileage may vary with other distributions.

  1. Configure your PPP connections appropriately.

    Make a copy of your existing /etc/peers/$PROVIDER file for the second PPP connection; you will want to change the username setting in the new file, and also remove the defaultroute setting, so that the default route will always point at the first PPP connection.. Next, add a unit 0 setting to the first file, and a unit unit 1 setting to the second (assuming you don’t already have these or similar); this ensures that the ppp0 and ppp1 devices (respectively) will always be used, rather than the order of the connections coming up determining how devices are assigned.

    For reference, my peer files are called saix and is, and I have the following stanzas in /etc/network/interfaces to bring them up:

    auto dsl
iface dsl inet ppp
    provider saix

auto dsl-is
iface dsl-is inet ppp
    provider is

  2. Install Quagga.

    # aptitude install quagga

  3. Configure Quagga.

    My configuration looks like the following:

    hostname elvandar

### TENET

# UCT-C1
ip route 196.21.0.0/19      ppp1

### IS

# ISNET-03
ip route 196.26.0.0/16      ppp1

### Verizon

# HC1-20050912
ip route 196.40.96.0/20     ppp1

# HETZNER-ZA
ip route 196.22.132.0/22    ppp1
ip route 196.22.136.0/21    ppp1

### Datapro

# GIA-BLK6
ip route 196.41.192.0/19    ppp1

    Initially I had plans to retrieve a list of local routes from public-route-server.is.co.za and use that, but I discovered that I was tweaking my routing a lot, so I decided to just stick with setting specific routes for hosts that I wanted them for.

  4. Enable the Zebra daemon.

    Edit /etc/quagga/daemons and set zebra=yes.

  5. Make sure the configuration changes take effect.

    # invoke-rc.d quagga force-reload

And there you have it. Zebra will automatically add the routes as the appropriate interface(s) come up, thus you don’t need to worry about the routes persisting across reconnections etc. (which is a good thing, since currently all ADSL connections are terminated after they have been active for 24 hours… argh!)

Leave a Comment :, , more...

Search

Loading