Category Archives: Networking

PPPoE Server HOWTO for MikroTik RouterOS 2.9

If you wish to run a PPPoE server, MikroTik RouterOS provides a convenient way to set one up in a few minutes (with built-in traffic shaping feature too!). Previously I used Fedora Core for my PPPoE servers, but I couldn’t find a working solution to keep ghost PPPoE sessions from bogging down my Linux server. I tried MikroTik DOM with RouterOS to replace my Linux-powered PPPoE servers, so far the results are very good.

Below is a mini guide that may be able to help you get your PPPoE server running in a few minutes using RouterOS.

First, make sure that your RouterOS server’s WAN connectivity has been properly configured. Remember that you need at least 2 network interface cards (NICs). This guide assumes that both NICs are ethernet — ether1 and ether2. If you haven’t set anything up on the new system, let me help you with the checklist: (based on my experience, the following issues are the most common)

  • Make sure that the Internet-facing NIC has an IP address assigned on it and the default gateway is set (/ip route add gateway=…)
  • If NAT is used, ensure that src-nat/masquerade firewall rule has been added (/ip firewall nat …) and it is working properly

Once you have verified the server’s connectivity, create a PPP profile (/ppp profile add name=”pppoe-profile” local-address=10.1.1.1 dns-server=… rate-limit=128k/128k). Every user account that uses this profile will get 128Kbps upload and download limit. If you wish to have different types of accounts (for example some customers pay for 256Kbps), create a new PPP profile (change the rate-limit attribute).

Next, create a user account assigned to the new PPP profile (/ppp secret add name=”andryan” password=”test” service=pppoe profile=”pppoe-profile” remote-address=10.1.1.2). When this user logs in successfully, this user gets assigned 10.1.1.2. To dynamically assign IP addresses, there is an example here.

Finally, create a PPPoE server instance (/interface pppoe-server server add service-name=”pppoe1″ interface=ether2 one-session-per-host=yes default-profile=”pppoe-profile”) and enable it. Now your RouterOS PPPoE server is ready to answer PPPoE requests and authenticate your PPPoE clients. 🙂

Good luck!

References:
http://www.mikrotik.com/testdocs/ros/2.9/interface/pppoe.php

ETHTOOL_OPTS to configure ethernet cards

I was going to write about ETHTOOL_OPTS a couple of months ago, but unfortunately I’m a forgetful person.

If you use Fedora Core (or some Fedora-driven distributions) which uses ifcfg-DEVNAME files in /etc/sysconfig/network-scripts/ and you wish to alter your ethernet cards’ default configuration, ETHTOOL_OPTS is basically all you need! Look no further, no need to add anything in rc.local or write your own rc scripts just to force your ethernet cards to a certain configuration (be it 100Mbps full duplex or 10Mbps half duplex). Simply add this line to your ifcfg file, e.g. for eth0, edit /etc/sysconfig/network-scripts/ifcfg-eth0 and append:

ETHTOOL_OPTS=”speed 100 duplex full autoneg off”

To put this change into effect, do service network restart.

Use mii-tool to verify whether the ethernet cards apply the new configuration.

References:
http://www.redhat.com/archives/broadcom-list/2003-December/msg00002.html

MikroTik RouterOS — BGP

I have always wanted to learn about BGP. This time I got the honor chance to implement BGP for an ISP. This ISP has its own AS number and a /21 IP address block. This BGP setup is pretty simple because I’m only using 1 PC (with 3 ethernet cards and a MikroTik’s level 4 DOM) to interconnect with an Internet Exchange (IX) — NiCE — and a transit ISP (another transit will be added soon).

In MikroTik RouterOS version 2.9.42, BGP features are available for level 3 and above. You also need to enable routing-test package if you want more flexibility (BGP filtering features). The routing package, as of this version, only allows basic BGP features. I’m sure this will change later when they release RouterOS v3. Once you have enabled routing-test package, you will see new options (Routing – Filters in winbox, or /routing filters on CLI). This is very important when you have to peer with 2 or more ASes (specifically an IX and a transit which is not interested in getting IX’s routes for obvious reasons).

Since I have never configured BGP before, I caused a major problem when routes from each peer goes to another peer when they shouldn’t! I didn’t place any filter for BGP advertisements my BGP router sends to its peers. My transit ISP received the IX’s routes and the IX received full Internet routes feed my BGP router gets from the transit ISP. BGP is an exterior distance-vector routing protocol, it picks its best path by comparing the AS path lengths of every route it has. Advertising the whole Internet BGP feed to the local IX caused other ISPs’ routers participating in the IX to discover a shorter path of international routes going via my BGP router so the routers chose this new shorter path instead and outgoing traffic of these ISPs started to flow via my transit ISP! On the other hand, advertising IX routes to my transit was not a big problem since the path will be farther for their customers anyway, having to go via my BGP router first (that’s one AS further for the transit ISP’s customers to reach the IX routes, so BGP will not select it).

Fortunately I was able to spot the error immediately and placed BGP routing filters to include only my /21 IP block in the advertisements my BGP router sends to both the IX and transit. I also added an incoming BGP filter to discard a default route my transit IP includes in its BGP feed. This default route is not required since I get full BGP feed that is unfiltered.

Useful links:
http://www.mikrotik.com/testdocs/ros/2.9/routing/bgp.php
http://www.mikrotik.com/testdocs/ros/2.9/routing/filter.php
http://wiki.mikrotik.com/wiki/BGP_Case_Studies_1 — Route filters examples
http://wiki.mikrotik.com/wiki/Using_scope_and_target-scope_attributes — Important! Make sure that BGP neighbors are reachable via static routes for dynamic routes to be active (in the case of multihop BGP neighbors)
http://wiki.mikrotik.com/wiki/BGP_soft_reconfiguration_alternatives_in_RouterOS
Cisco’s BGP Reference

Layer Four Traceroute (lft)

I’m a big fan of tcptraceroute. It’s a very useful tool for network administrators (in addition to the traditional traceroute). I had tcptraceroute installed on my MacBook via MacPorts, but later it stopped working (“libnet_write failed? Attempted to write 40 bytes, only wrote -1” error message) due to libnet compatibility problem. I couldn’t find a fix to that problem so I searched for a similar tool to replace tcptraceroute for my MacBook. I found lft on Google. Apparently lft is more flexible and advanced than tcptraceroute. What makes lft even better than tcptraceroute? lft is included in Fedora Extras! Since I use Fedora Core for my servers, this is much better than having to use third-party repository (e.g. dries, dag, etc.)

Normally, I use the following syntax for lft:

lft -C -z -n -E -S google.com

Real-time Linux bandwidth monitor

There are so many Linux bandwidth monitoring software available out there. Many of these software are just showing the current upload and download speed of each network interface, pretty much similar to iptraf‘s “General interface statistics”. I was looking for something that plots TUI graphs. I found nload after spending a few minutes on Google. It doesn’t produce pretty graphs like rrdtool, but at least it does what I need.

UPDATE: I just noticed that ifstatus is similar to nload. ifstatus is capable of producing colored TUI graphs.

ipt_account HOWTO for Fedora Core 6

For the last few days I have been looking for a bandwidth monitoring tool that is more efficient, accurate, and complete than IPFM. I found so many bandwidth monitoring tools (bandwidthd, ipband, darkstat, and a few others) on Google but couldn’t find one that fits what I want. In fact, IPFM suits me better than the others.

While I was reading iptables’ man page, I accidentally came across ‘account’ under ‘MATCH EXTENSIONS’. After reading the brief description and example, I got excited! This iptables match extension provides exactly what I need! With the flexibility of iptables’ rules plus the account match extension, this has to be the best solution for my new bandwidth monitoring system. There is one problem though. Fedora Core doesn’t have it. 🙁

With some experience I got from installing ipp2p by hand, I started trying to make this iptables match extension work on my Fedora Core 6 server. First, I used Google to locate ipt_account’s website. Then I used Google to search for some install guides on ipt_account but couldn’t find any, so I went through its website and found something.

Since I have prepared my system with kernel & iptables source tree, rpmbuild, etc. (basically everything required to build ipp2p modules), I will not go over the “ingredients” again. Sorry!

Download the kernel and iptables patches from this page. Patch the kernel tree:

  • cd /usr/src/redhat/BUILD/kernel-2.6.19/linux-2.6.19.i386/
  • patch -p1 < path_to_kernel_patch

You should see the following:

patching file include/linux/netfilter_ipv4/ipt_account.h
patching file net/ipv4/netfilter/ipt_account.c
patching file net/ipv4/netfilter/Kconfig
patching file net/ipv4/netfilter/Makefile

OK, now the kernel tree is patched. Now do make oldconfig. You will be asked:

account match support (IP_NF_MATCH_ACCOUNT) [N/m/?] (NEW)

Since this will be a kernel module, hit m. Once the process has finished, do make scripts/kconfig/ (if you haven’t previously during ipp2p module build process). Create a temporary directory somewhere (e.g. /tmp/ipt). Copy /usr/src/redhat/BUILD/kernel-2.6.19/linux-2.6.19.i386/net/ipv4/netfilter/ipt_account.c into that directory and create a file named Makefile. Paste the following into Makefile:

obj-m := ipt_account.o
KDIR := /usr/src/redhat/BUILD/kernel-2.6.19/linux-2.6.19.i386/
PWD := $(shell pwd)
default:
$(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules

Make sure that there is a tab before $(MAKE). Save the file and execute make. If the compile process goes well, there will be a file named ipt_account.ko in the directory. Load the module by using insmod. Check lsmod to see the newly loaded module.

If you have got this far, that means your kernel now supports ipt_account. Now we will add ipt_account extension for iptables. To see if your iptables has ipt_account support, do iptables -m account. If it prints out something like “Couldn’t load match `account’: …”, that means there is no iptables account extension yet.

Let’s patch iptables source tree:

  • cd /usr/src/redhat/BUILD/iptables-1.3.5
  • patch -p1 < path_to_iptables_patch

Expect the following:

patching file extensions/libipt_account.c

Open extensions/Makefile, on line 8, add account before ah. Then compile the ipt_account’s extension:

cc -O2 -Wall -Wunused -I/usr/src/redhat/BUILD/kernel-2.6.19/linux-2.6.19.i386/include -Iinclude/ -DIPTABLES_VERSION=\”1.3.5\” -fPIC -o extensions/libipt_account_sh.o -c extensions/libipt_account.c
cc -shared -o extensions/libipt_account.so extensions/libipt_account_sh.o

Copy extensions/libipt_account.so to /lib/iptables and verify the extension: iptables -m account. That’s it! Pretty easy, eh? 🙂

Read this page to test the new iptables account match extension. Enjoy!

ipp2p HOWTO for Fedora Core 6

While this post is titled “for Fedora Core 6”, it may be applicable to previous versions of Fedora Core. I tested this on Fedora Core 4 too, but some steps are different.
Note: This guide uses iptables-1.3.5-1.2.1 and kernel-2.6.19-1.2895.fc6.

First, grab ipp2p-0.8.2.tar.gz or the latest version if there’s any. Extract the tarball and make sure you have iptables and the currently installed kernel’s SRPMs installed. To proceed, I recommend rpm-build to be installed (simply use yum to install, i.e. yum install rpm-build). Next, install both SRPMs using the following command: rpm -ivh file.rpm. If you get “error: cannot create %sourcedir /usr/src/redhat/SOURCES” message, you can create the required directory: mkdir -p /usr/src/redhat. Also, rpm-building the kernel source requires redhat-rpm-config and unifdef to be installed.
Now that the “ingredients” are ready, let’s start doing the fun part..

Go to /usr/src/redhat/SPECS and do rpmbuild -bp iptables.spec, this will prepare the iptables’ source tree to match with the currently installed iptables binaries’ source. Do the same for the kernel, rpmbuild -bp kernel-2.6.spec. The newly patched source tree can be found inside /usr/src/redhat/BUILD directory.

Grab symvers-2.6.19-1.2895.fc6.gz from /boot, gunzip and rename it as Module.symvers, then move it to the kernel’s source directory (/usr/src/redhat/BUILD/kernel-2.6.19/linux-2.6.19-i386). Go into that directory, make sure that existing kernel config (.config) exists, then do: make scripts/kconfig/.
Note: If you can’t find symvers file in /boot, install kernel-devel package and you will find Module.symvers in /usr/src/kernels//.

Next, return to the ipp2p source directory and do two modifications.

Add:

KERNEL_SRC=/usr/src/redhat/BUILD/kernel-2.6.19/linux-2.6.19.i386

before

KERNEL_SRC ?= $(firstword $(wildcard …

Add:

IPTABLES_SRC = /usr/src/redhat/BUILD/iptables-1.3.5

before

ifeq ($(IPTABLES_SRC),)

Save the changes and do make.

If it compiles successfully, then ipt_ipp2p.ko and libipt_ipp2p.so should be in the directory now.
Copy libipt_ipp2p.so to /lib/iptables. To verify whether this iptables module works, do iptables -m ipp2p -h.
In case you get the following: iptables v1.3.8: Couldn’t load match `ipp2p’, don’t worry. Have a look at this solution and simply recompile the modules.

There are two ways to load the ipp2p kernel module, insmod ipt_ipp2p.ko or copy ipt_ipp2p.ko to /lib/modules/2.6.19-1.2895.fc6/kernel/net/ipv4/netfilter and do depmod -a.