5 static IP addresses that I wish I could use

Rory:

Background:

As a small software development company we host many the applications that we develop in our lab on in house servers. Many of these applications require large databases and high bandwidth that would make off site hosting or collocation cost prohibitive. Recently we bought five additional static IP addresses from our Internet Service Provider to host our growing number of websites / applications.

We knew that we could use those five IP addresses to host other applications and websites, but for now, we want to host all of the websites on one server. This post will outline the ins and outs of setting up this type of system.

The Modem: At this point we have five IP addresses and one Ethernet wire coming out of the modem.	The Router / Firewall: We need a device that will be able to route all of the IPs to a single location. We want to serve five websites (all on port 80) and protect our server from the internet.	The server: Our web server has a single network card and is running Windows 2003 server.

Starting out we thought we needed an off the shelf router, but we knew that the cheap Linksys router we were currently using would only allow us to assign it one external IP address. After hours of searching we figured out that the ability to assign multiple external IP addresses to a router is call multi-NAT. After more searching and a few calls we also figured out that it was virtually impossible to tell whether a router was capable of multi-NAT. Since a commercial router would break our equipment budget, we started evaluating Smoothwall Linux. Smoothwall is a Linux based firewall that is fully configurable (including multi-NAT).

Setup:

1. Configure the Windows Ethernet card with your five corresponding internal IPs.
(Network - Local Area Network Connection - TCP/IP - Properties) I will assign two addresses for the following example.



2. Install 3 NIC cards into the PC that will become the Smoothwall firewall.

3. Burn Smoothwall installation to a CD and install on the firewall PC.

3. Boot firewall and login as root to setup forwarding of the red interface packets coming in on port 80 to the correct internal IP of the server. Edit the /etc/rc.d/firewall.up to forward the correct packets. Assuming that I want to forward web server requests coming into the firewall's red interface to the green interface, add the following lines to the end of the firewall.up file:

# Add external IPs to the red interface (eth2)
/sbin/ifconfig eth2:19 128.49.41.19 broadcast 128.49.41.255 netmask 255.255.255.0
/sbin/ifconfig eth2:20 128.49.41.20 broadcast 128.49.41.255 netmask 255.255.255.0

# Route RED to GREEN
/sbin/iptables -I PREROUTING -t nat -d 128.49.41.19 -j DNAT --to-destination 192.168.1.19
/sbin/iptables -I PREROUTING -t nat -d 128.49.41.20 -j DNAT --to-destination 192.168.1.20

# Change all web server responses from GREEN to RED
/sbin/iptables -I POSTROUTING -t nat -o $RED_DEV -p tcp -s 192.168.1.19 -j SNAT --to-source 128.49.41.19
/sbin/iptables -I POSTROUTING -t nat -o $RED_DEV -p tcp -s 192.168.1.20 -j SNAT --to-source 128.49.41.20

# Allow port 80 traffic to pass through firewall
/sbin/iptables -I FORWARD -d 192.168.1.19 -i $RED_DEV -o $GREEN_DEV -p tcp --dport 80 -j ACCEPT
/sbin/iptables -I FORWARD -d 192.168.1.20 -i $RED_DEV -o $GREEN_DEV -p tcp --dport 80 -j ACCEPT

Conclusion:

After many attempts to configure the firewall through the web admin, even after adding the MODS for Full Firewall Control and Mutliple IP Addresses I found that configuring the firewall manually was the simplest way to get it working.

References:

http://community.smoothwall.org/forum/viewtopic.php?t=11446
http://community.smoothwall.org/forum/viewtopic.php?t=4820
http://www.smoothwall.org/
http://pigtail.net/LRP/broadcast.html

The Jumbo Ethernet Frames "Standard"

Jim:

Recently, I've been using Xilinx reference design Xapp902 as the basis for a (relatively) high speed Ethernet data transfer project. Xapp902 targets Xilinx's ML403 Evaluation Platform; the platform features the Virtex 4 FX12 device (an embedded Power PC 405 core). (jargon off)

In an attempt to conserve CPU cycles and increase data throughput, I began looking for information on Jumbo Frame implementations.


Brief Background

Data in a Local Area Network is organized hierarchically. An Ethernet or 802.2 Frame is the lowest level of data organization. And while the two are compatible, an Ethernet Frame is not the same thing as an 802.2 Frame.

Eventually, the maximum Ethernet Frame size standardized to 1518 bytes:

- 6 bytes for the destination MAC address
- 6 bytes for the source MAC address
- 2 bytes for length or type information (this is the key difference between Ethernet & 802.2)
- 1500 bytes (maximum) for data
- 4 bytes for a CRC checksum on the Ethernet Frame

At the hardware level, (the MAC and PHY layers), dedicated hardware components are responsible for transmission, reception, and error detection in these frames; however, the System CPU is generally responsible for orchestrating data handling once an entire packet becomes available.

This scheme was fine in the days of 10 Mbit/sec Ethernet, but as network speeds increase, the CPU has less & less time for orchestration, and spends an increasingly higher percentage of its time just handling network traffic. At Gigabit Ethernet speeds, packets arrive 100 times faster than they did with the old 10 Mbit/sec protocol... Enter the Jumbo Frame.

The Jumbo Frame

This problem was recognized years ago. In response, engineers proposed tweaking the meaning of the length/type field in the Ethernet/802.2 frame. They proposed letting the length/type field contain data for Frames > 1500 bytes.

By increasing the Frame size (to approx. 9 KBytes), the network processing burden on the CPU could be reduced proportionately. Makes sense, doesn't it? The problem was that there was already too much networking infrastructure in place by then, and Jumbo Frames were largely incompatible with that infrastructure. Consequently, the Jumbo Frame proposal was rejected.

But, that didn't stop Jumbo Frames from being implemented in systems; they've just been declared as proprietary. A proprietary non-standard standard. Oh boy.

I'm not sure how many non-standard implementations there are out there; in the Xilinx Ethernet device driver code I've seen, there are some values that can be changed in the MAC hardware to allow receipt & transmission of Jumbo Frames. But it looks as if the length/type field must be used to indicate Frame size.

Of course, the resulting packets would non-standard, which means that they could be rejected by other devices on the network. Not good if I need to move data through switches and routers.

Given the hassles described above, I've decided to stick with regular 1518 byte Frames; but, I would like to know if and how other devices and systems are handling Jumbo Frames. Do they just "flip the Jumbo hardware switch" and assume that the length/type field represents the Frame size?

My understanding is that Jumbo Frames are part of the Gigabit Ethernet standard, but I haven't seen anything documenting this.