VPN IP-Tunneling and QoS Studies of Embedded Linux Network ...

3.1 VPN Tunnel Mode TestsFigure 4. The VPN Tunnel Mode Testing Environment for IPIP, GRE and IPSEC VPNs.The testing environment in Figure 4 can be set up for the VPN Tunnel Mode operation andshared among IPIP, GRE and IPSEC VPNs. Both IPIP and GRE involve with onlyencapsulation mechanisms, whereas IPSEC also involves with data encryption (ESP) and headerauthentication (AH). The idea is to use two ELING routers/firewalls as Tunnel Servers A and B,and build up a corresponding tunnel between Tunnel Servers A and B with respect to one of thethree types of VPNs. As long as TD-A and TD-B set their default routes via Tunnel Servers A andB respectively, VLAN-A and VLAN-B can then be connected via the tunnel without being awareof the existence of VPNs.We have tried out and established the following scripts, as shown in Table 2 throughoutTable 5 for Tunnel Servers A and B in the three types of VPNs, and further details and instructionsteps can be found elsewhere [4].Table 2. IPIP-VPN Tunnel Server ScriptsTunnel Server ATunnel Server Binsmod ipipinsmod ipipip tunnel add mytun mode ipip remote \ ip tunnel add mytun mode ipip \140.126.75.2 local 140.126.75.3 ttl 255 remote 140.126.75.3 local 140.126.75.2 ttl 255ifconfig mytun 192.168.4.2ifconfig mytun 192.168.5.2route add -net 192.168.5.0/24 dev mytun route add -net 192.168.4.0/24 dev mytunroute add default gw 140.126.75.3 route add default gw 140.126.75.2Table 3. GRE-VPN Tunnel Server ScriptsTunnel Server ATunnel Server Binsmod ip_greinsmod ip_greip tunnel add mytun mode gre remote \ ip tunnel add mytun mode gre remote \140.126.75.2 local 140.126.75.3 ttl 255 140.126.75.3 local 140.126.75.2 ttl 255ifconfig mytun 192.168.4.2ifconfig mytun 192.168.5.2route add -net 192.168.5.0/24 dev mytun route add -net 192.168.4.0/24 dev mytunroute add default gw 140.126.75.3 route add default gw 140.126.75.2

Table 4.# Insert the ipsec.o kernel moduleinsmod ipsec# Tunnel configuration setuptncfg --attach --virtual ipsec0 --physical ixp0IPSEC-VPN Tunnel Server ScriptsTunnel Server Aifconfig ipsec0 140.126.75.2 broadcast 140.126.255.255 netmask 255.255.0.0# Define the Security Association rules of ipip/ESP/AH# with spi 0x100 / 0x101/ 0x102 for traffic destined at Server Bspi --ip4 –said tun0x100@140.126.75.3 --src 140.126.75.2 --dst 140.126.75.3spi --esp 3des –said esp0x101@140.126.75.3 \--enckey 0x663066306630663066306630663066306630663066301111spi --ah hmac-md5 –said ah0x102@140.126.75.3 \--authkey 0x66306630663066306630663066302222# Group spi 0x100 / 0x101/ 0x102 as a single one spi 0x100spigrp --said tun0x100@140.126.75.3 esp0x101@140.126.75.3 ah0x102@140.126.75.3# with spi 0x200 / 0x201/ 0x202 for traffic destined at Server Aspi --ip4 –said tun0x200@140.126.75.2 --src 140.126.75.3 --dst 140.126.75.2spi --esp 3des –said esp0x201@140.126.75.2 \--enckey 0x663066306630663066306630663066306630663066301111spi --ah hmac-md5 –said ah0x202@140.126.75.2 \--authkey 0x66306630663066306630663066302222# Group spi 0x200 / 0x201/ 0x202 as a single one spi 0x200spigrp --said tun0x200@140.126.75.2 esp0x201@140.126.75.2 ah0x202@140.126.75.2# Apply the Security Association ruleeroute --add --eraf inet --src 192.168.4.0/24 --dst 192.168.5.0/24 tun0x100@140.126.75.3eroute --add --eraf inet --src 192.168.5.0/24 --dst 192.168.4.0/24 tun0x200@140.126.75.2# Setup a route to VLAN-B via ipsec0route add -net 192.168.5.0 netmask 255.255.255.0 dev ipsec0 gw 140.126.75.3# Insert the ipsec.o kernel moduleinsmod ipsec# Tunnel configuration setuptncfg --attach --virtual ipsec0 --physical ixp0Tunnel Server Bifconfig ipsec0 140.126.75.3 broadcast 140.126.255.255 netmask 255.255.0.0# Define the Security Association rules of ipip/ESP/AH# with spi 0x100 / 0x101/ 0x102 for traffic destined at Server Bspi --ip4 –said tun0x100@140.126.75.3 --src 140.126.75.2 --dst 140.126.75.3spi --esp 3des –said esp0x101@140.126.75.3 \--enckey 0x663066306630663066306630663066306630663066301111spi --ah hmac-md5 –said ah0x102@140.126.75.3 \--authkey 0x66306630663066306630663066302222# Group spi 0x100 / 0x101/ 0x102 as a single one spi 0x100

Figure 6. Testing Environment of QoS Load Balancing.Figure 6 illustrates the testing environment of QoS Load Balancing, where two ELING routers areconnected with two Ethernet lines to share the load from Net-A. Conceptually this configuration isonly meaningful for routing connection backup, and one can replace the right half part with twoservers in two generic PCs respectively to achieve the load balancing of application services.4. Results and AnalysesThis section summarizes and analyzes the VPN and QoS system test results. At this point, the VPNresults are quite preliminary in the sense that the scalabilities with multiple VPN tunnel effects arestill under measurement and study, and the IPSEC performance is estimated since encryption andauthentication are involved. On the other hand, the QoS results are more mature and stable.Table 5. System Test Results of VPNs in the Tunnel Mode.VPN # of Tested Tunnels Validated Functions PerformanceIPIP 1 Encapsulation 47.7 MbpsGRE 1 Encapsulation 45.1 MbpsIPSEC 1 EncapsulationEncryption (ESP)Authentication (AH)>20Mpbs(Estimated)Table 5 summarizes the system test results of the three types of VPNs according to Figure 4. Everytype of VPN was tested successfully at least with 1 tunnel. Compared to the ELING’s UDPthroughput without any VPN tunnel which was measured to be 89 Mbps, both performances of IPIPand GRE, i.e. 47.7 Mbps and 45.1 Mbps, seem to be lower than expected. In other words theoverheads purely from encapsulation seem to be high. Further verification about these results areunder study with other traffic generator toolset. Regardless of this concern, comparison betweenGRE and IPIP does indicate that about 5.5% extra overhead is from GRE, presumably due to the factGRE is somewhat heavier and more versatile since it also supports multicasting and IPv6. Theperformance issues of IPSEC are more complicated since encryption and authentication are alsoinvolved, and only an estimate, > 20Mbps, was given.

Table 6.Sample Configuration Test Results of QoS Bandwidth Division for UDP Uploading.CBQ or HTB qdisc basedManager LimitStaff LimitTotal LimitBandwidth Division30 Mbps20Mbps50 MbpsTransmitted UDP Flow Rate 50 Mbps 50 Mbps 100 MbpsAchieved Bandwidth 30.0 Mbps 19.9 Mbps 49.9 MbpsValid ? Valid Valid ValidPercent Error (Error) 0.0 % (0.0 Mbps) 0.5% (0.1 Mbps) 0.2% (0.1 Mbps)Table 6 gives the sample configuration test results of QoS bandwidth division via CBQ or HTB qdiscfor UDP uploading according to Figure 5. The bandwidth division is valid and precise for bothManager and Staff with total error rate around 0.2% (i.e. 0.1 Mbps) for a total bandwidth limit at 50Mbps. Other tests with different total limits were also tested, and the results are similar. Due to sometechnical reason, multiple iperf clients can not collocate on one PC where resource competitionhappens. Therefore we conducted FTP tests for the downloading case. Limited by the slow I/O ofhard disks of Test Devices, the total limit was taken to be 5 Mbps, and (3 Mbps, 2 Mbps) were thedivided bandwidths for Manager and Staff respectively. Similar conclusion holds for the FTP caseexcept that the error rate increases to 4% (i.e. 0.2 Mbps).Finally,the QoS load balancing was tested according to Figure 6. The results are as expected.If the two ELING routers are connected and shared by two Ethernet lines, each line gets about 50%of the total incoming traffic load. If shared by three Ethernet lines, each line gets about one third ofthe total traffic load.5. Summary and OutlookThis research aims at implementing VPN and QoS functions for the SnapGear Linux based networkgateways on top of the Intel XScale IXP-425 network processor based EVB. We have conducted awide range of tests both in VPN and QoS.For VPN, we have been able to successfully establish at least one tunnel for each case of IPIP,GRE and IPSEC VPNs, although the performance results are only preliminary, the differencebetween GRE and IPIP seems to reasonable. More careful performance measurement experimentsare being designed to verify the performance issues including precise performance measurement ofIPSEC. According to a desktop report of IPSEC, if one takes that only 30% of the pure routingperformance can survive from the desktop experience of IPSEC, one can estimate the convolutedeffect should be around ~ 24 Mbps or at least > 20 Mbps, taking all the IPSEC operations such asencapsulation, data encryption and authentication into account. More tests are under measurement.As for QoS based bandwidth division and load balancing, we have more mature and stableresults. In the case of bandwidth division, the network bandwidth can be divided quite precisely froma few Mbps to tens of Mbps with error rate from 4% (for 5 Mbps) to 0.2% (for 50 Mbps), both forthe downloading and uploading cases. One interesting point worth noting is that the error rate seems

to increase with the bandwidth, which seems contrary to the common expectation. However, theabsolute value of this error somewhat maintains at constant level, then it may be safe to interpret thiserror as a constant overhead by qdisc algorithms such as CBQ and HTB. Whether this is true or notwill need more finely segmented experiments over the measured bandwidth range. We will pursuealong this track soon.Finally in the case of load balancing, the test results were successful and as expected for twoor three Ethernet lines. Conceptually, one can extend this study case to another one where the righthalf part of Figure 6 can be replaced with two PCs, each running with the same network service suchas the FTP or Web servers, and load sharing between two network services can then be achieved.However, the performance benchmarking of web servers is another issue, as suggested by SpecWeb96 and SpecWeb 99 etc., and the performance benchmarking of FTP is more disk-speed specific. Wewill try to develop some study cases along this direction too.References[1] W.P. Lai, Requirement Specification Document of 2004 NSC Open Source Project, NSC93-2218-E-163-001.[2] W.P. Lai, Project Execution Plan Document of 2004 NSC Open Source Project, NSC93-2218-E-163-001.[3] W.P. Lai, System Design Document of 2004 NSC Open Source Project, NSC93-2218-E-163-001.[4] W.P. Lai, System Testing Document of 2004 NSC Open Source Project, NSC93-2218-E-163-001.[5] For SnapGear Linux, please see: http://www.snapgear.org.[6] For Intel IXP-425, please see: http://dwdm.cis.nctu.edu.tw/project/WiMax_Gateway/NP425.htm.[7] For Netfilter and iptables, please see: http://www.netfilter.org.[8] For GRE, please see: http://lartc.org/howto/lartc.tunnel.gre.html.[9] For FreeS/WAN, please see: http://www.freeswan.org.[10] For CBQ, please see: http://www.icir.org/floyd/cbq.html or http://lartc.org.[11] For HTB, please see: http://luxik.cdi.cz/~devik/qos/htb or http://lartc.org.[12] For TEQL, please see: http://www.sangoma.com/linux/linux-teql.htm or http://lartc.org.