Linux Advanced Routing Tutorial
National vs. International Traffic
Google's public DNS server B is clearly an off-shore international destination. However, one of the root DNS servers, namely f.root-servers.net with IP 18.104.22.168, is present here in New Zealand. At the moment, the traceroute to f.root-servers.net still shows the ADSL path:
[workstation] ~ $ /usr/sbin/traceroute f.root-servers.net traceroute to f.root-servers.net (22.214.171.124), 30 hops max, ↪40 byte packets using UDP 1 gw-vlan-office.e-it.co.nz (192.168.130.1) ↪0.175 ms 0.126 ms 0.125 ms 2 gw-vlan-adsl.e-it.co.nz (192.168.128.254) ↪0.861 ms 0.840 ms 0.825 ms 3 core-adsl.isp2 (218.101.x.y) 22.456 ms 22.298 ms 23.501 ms 4 isp2.ape.net.nz (192.203.154.x) 21.035 ms 20.928 ms 21.268 ms 5 isc2.ape.net.nz (192.203.154.y) 20.689 ms 21.724 ms 24.187 ms 6 f.root-servers.net (126.96.36.199) 26.680 ms 26.059 ms 25.427 ms
This is clearly national traffic, and it should go out via the SHDSL link as per our plan. We can do that manually and set the appropriate route on our core router:
[router] ~ # ip route add 188.8.131.52 via 203.0.113.37 ↪dev vlan-shdsl
A side note about NAT'ing: we also need to translate (or "masquerade" or NAT) the office address range 192.168.130.0/24 to our SHDSL public IP 203.0.113.38. If we didn't, the packet's source IP would be 192.168.130.100, and the replies would never find their way back to my workstation, as this address range is not routable in the public Internet. Discussing firewalls and NATs is out of scope of this article, but to get you going, here's the simplest magic command:
[router] ~ # iptables -t nat -A POSTROUTING -s 192.168.128.0/20 ↪-o vlan-shdsl -j DNAT --to 203.0.113.38
All packets with a source address from the 192.168.128.0/20 range leaving through the interface vlan-shdsl will get the source rewritten to 203.0.113.38. We didn't need to set up any masquerading for the ADSL path, because there the ADSL router NATs all our outgoing traffic.
Now, let's check the new network path:
[workstation] ~ $ /usr/sbin/traceroute f.root-servers.net traceroute to f.root-servers.net (184.108.40.206), 30 hops max, ↪40 byte packets using UDP 1 gw-vlan-office.e-it.co.nz (192.168.130.1) ↪0.190 ms 0.129 ms 0.125 ms 2 rt-shdsl.isp1 (203.0.113.37) 2.676 ms 2.599 ms 2.632 ms 3 rt3.isp1 (121.98.ab.cd) 2.715 ms 2.680 ms 2.591 ms 4 isc2.ape.net.nz (192.203.154.z) 2.919 ms 3.033 ms 3.088 ms 5 f.root-servers.net (220.127.116.11) 3.007 ms 2.670 ms 2.864 ms
That's lot better. The first hop remains the same, that's my workstation's router, but the second hop is no longer the ADSL modem. Instead, it's the SHDSL ISP1's core router. It also clearly shows the latency improvement—from 26ms over ADSL to 3ms over SHDSL.
Let's remove the manual route again to avoid any confusion down the road and query the routing table:
[router] ~ # ip route get 18.104.22.168 from ↪192.168.130.100 iif vlan-office 22.214.171.124 from 192.168.130.100 via 203.0.113.37 ↪dev vlan-shdsl # SHDSL [router] ~ # ip route delete 126.96.36.199 via 203.0.113.37 ↪dev vlan-shdsl [router] ~ # ip route get 188.8.131.52 from ↪192.168.130.100 iif vlan-office 184.108.40.206 from 192.168.130.100 via 192.168.128.254 ↪dev vlan-adsl # ADSL
So all we need now is a list of all national IP addresses, put them in the routing table, and we're done. But how? Manually? Even in a small country like New Zealand there are hundreds of local IP addresses and prefixes, and the list is dynamic and changes daily. There is no way such a list could be managed manually. We need a better tool.
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.
Fast/Flexible Linux OS Recovery
On Demand Now
In this live one-hour webinar, learn how to enhance your existing backup strategies for complete disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible full-system recovery solution for UNIX and Linux systems.
Join Linux Journal's Shawn Powers and David Huffman, President/CEO, Storix, Inc.
Free to Linux Journal readers.Register Now!
- Google's Abacus Project: It's All about Trust
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- Seeing Red and Getting Sleep
- Back to Backups
- Secure Desktops with Qubes: Introduction
- Fancy Tricks for Changing Numeric Base
- Working with Command Arguments
- Secure Desktops with Qubes: Installation
- Linux Mint 18
- CentOS 6.8 Released
Until recently, IBM’s Power Platform was looked upon as being the system that hosted IBM’s flavor of UNIX and proprietary operating system called IBM i. These servers often are found in medium-size businesses running ERP, CRM and financials for on-premise customers. By enabling the Power platform to run the Linux OS, IBM now has positioned Power to be the platform of choice for those already running Linux that are facing scalability issues, especially customers looking at analytics, big data or cloud computing.
￼Running Linux on IBM’s Power hardware offers some obvious benefits, including improved processing speed and memory bandwidth, inherent security, and simpler deployment and management. But if you look beyond the impressive architecture, you’ll also find an open ecosystem that has given rise to a strong, innovative community, as well as an inventory of system and network management applications that really help leverage the benefits offered by running Linux on Power.Get the Guide