Linux Advanced Routing Tutorial
For years, we used to have a plain-old ADSL in the office—fast download speeds, slow upload, high latency—all that at the cost of $1/GB. We have had so many problems with performance and reliability that after a few years of struggling, we decided to get a second upstream link—SHDSL 5M/5M symmetric link—low latency, consistent speed during the day. It's simply awesome.
Figure 1. Network Overview
However, SHDSL is expensive! Although national traffic is free of charge, international traffic is $5/GB. Compare that with ADSL at $1/GB for both national and international (Table 1).
|Speed||7M down/1M up||5M down/5M up|
|Public IP addresses||1||1 + /28|
There are clear pros and cons to both. That made me think (and I don't do that often), what if we kept ADSL for international traffic that's not that critical for us, and use SHDSL primarily for national traffic—fast and cheap?
Figure 2. Split Traffic between International and National
We also got a /28 subnet with the SHDSL to use for a DMZ, and obviously, we want all the traffic to and from the DMZ to go via the SHDSL link, regardless of whether it's national or international.
Figure 3. Traffic to/from the DMZ
For my plan to work, the company core router needs some way to tell whether a packet from a workstation in the office to an IP.AD.DR.ES in the wild open Internet is international or national and send it accordingly through ADSL or SHDSL. Routers use their routing tables for deciding the fates and paths of the packets they forward. A simple routing table for an office workstation with an address of 192.168.130.100 may look like this:
[workstation] ~ # ip route show 192.168.130.0/24 dev eth0 proto kernel scope link ↪src 192.168.130.100 default via 192.168.130.1 dev eth0
This says that all traffic to all other addresses in the 192.168.130.0/24 range is to be sent straight to the local network segment attached to interface eth0. All other traffic follows the "default" route and is handed over to the router with IP 192.168.130.1 to handle it. Let's assume we're sending a packet to 22.214.171.124, Google's public DNS server. For starters, we're trying to "ping 126.96.36.199" and are observing the traffic on the workstation's eth0 interface with tcpdump:
[workstation] ~ # tcpdump -i eth0 -n -s0 -e listening on eth0, link-type EN10MB (Ethernet), ↪capture size 65535 bytes  17:53:59.615650 00:16:17:ec:5c:6c > ff:ff:ff:ff:ff:ff, ↪ethertype ARP (0x0806), length 42: Request who-has 192.168.130.1 tell 192.168.130.100, ↪length 28  17:53:59.615775 00:14:c2:5b:4f:2c > 00:16:17:ec:5c:6c, ↪ethertype ARP (0x0806), length 60: Reply 192.168.130.1 is-at 00:14:c2:5b:4f:2c, length 46  17:53:59.615796 00:16:17:ec:5c:6c > 00:14:c2:5b:4f:2c, ↪ethertype IPv4 (0x0800), length 98: 192.168.130.100 > 188.8.131.52: ICMP echo request, ↪id 3082, seq 1, length 64
My workstation consulted the routing table for the destination IP 184.108.40.206 and realized it should send the packet to the default router 192.168.130.1. For that, it needs the router's low-level Ethernet address (also known as a MAC address), and the first packet in the above tcpdump output, marked , is doing exactly that—asking for the MAC address of IP 192.168.130.1 by "broadcasting" the request to all nodes on the network segment. The second packet, marked , is a reply—IP 192.168.130.1 is at MAC address 00:14:c2:5b:4f:2c. Finally, the PING packet can be dispatched, with the destination IP 220.127.116.11 to the router's MAC address 00:14:c2:5b:4f:2c (see the line marked ).
All good, so now we can assume our router got the packet and will forward it further toward the destination. Let's see what happens on the router.
We've got both the ADSL and the SHDSL links configured, but all traffic is, by default, sent through ADSL. The ADSL modem is at 192.168.128.254. For now, the SHDSL link 203.0.113.36/30 sits idle. Here is the routing table:
[router] ~ # ip route show  203.0.113.36/30 dev vlan-shdsl proto kernel ↪scope link src 203.0.113.38  192.168.128.0/24 dev vlan-adsl proto kernel ↪scope link src 192.168.128.1  192.168.130.0/24 dev vlan-office proto kernel ↪scope link src 192.168.130.1  default via 192.168.128.254 dev vlan-adsl
The first line  is the SHDSL link—our router's IP on that link is
203.0.113.38. The second line is the link to the ADSL modem; the third
line  is the network segment with my workstation, and finally, the fourth
line  is the default route. All packets that don't match any of the
local subnets on lines 1, 2 or 3 are sent down to the ADSL modem at
192.168.128.254 that then will forward them to the ISP 2. That's also the
fate of our packet to 18.104.22.168. Let's quickly verify what is going to
happen to it by calling
ip route get:
[router] ~ # ip route get 22.214.171.124 from 192.168.130.100 ↪iif vlan-office 126.96.36.199 from 192.168.130.100 via 192.168.128.254 dev vlan-adsl
As you can see, it will be sent "via 192.168.128.254", which is the ADSL modem. A simple way to check the full network path from my workstation to any given destination address is the traceroute command. It shows all the routers ("hops") along the way to the destination:
[workstation] ~ $ /usr/sbin/traceroute 188.8.131.52 traceroute to 184.108.40.206 (220.127.116.11), 30 hops max, ↪40 byte packets using UDP 1 gw-vlan-office.e-it.co.nz (192.168.130.1) ↪0.156 ms 0.126 ms 0.124 ms 2 gw-vlan-adsl.e-it.co.nz (192.168.128.254) ↪0.853 ms 0.831 ms 0.830 ms 3 core-adsl.isp2 (218.101.x.y) ↪11.765 ms 19.173 ms 19.066 ms 4 core-xyz.isp2 (203.98.x.y) ↪16.052 ms 15.515 ms 17.153 ms [... some more hops ...] 13 64.233.x.y (64.233.x.y) 193.826 ms 194.230 ms 194.412 ms 14 * * * 15 google-public-dns-b.google.com (18.104.22.168) ↪196.086 ms 195.909 ms 195.816 ms
As you can see, the first hop is our router 192.168.130.1. The second hop is the ADSL modem 192.168.128.254. The third hop is one of the ISP2's core routers, and so on and on, passing 11 more routers before the packet finally reaches the destination 22.214.171.124, aka google-public-dns-b.google.com.
Michal Ludvig works for Enterprise IT Ltd in New Zealand as a senior Linux engineer. He's got root access to some of the largest New Zealand corporations, but since he tends to forget his passwords, he is, in general, pretty harmless.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- Rogue Wave Software's Zend Server
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide