Difference between revisions of "Bering-uClibc 5.x - User Guide - Advanced Topics - Setting Up a Network Emulator"

From bering-uClibc
Jump to: navigation, search
(Created page with '{| summary="Navigation header" width="100%" ! colspan="3" align="center" | [[Bering-uClibc 5.x - User Guide - Advanced Topics - Setting Up Universal Plug and Play|Advanced Topics…')
 
 
(One intermediate revision by the same user not shown)
Line 1: Line 1:
 
{| summary="Navigation header" width="100%"
 
{| summary="Navigation header" width="100%"
−
! colspan="3" align="center" | [[Bering-uClibc 5.x - User Guide - Advanced Topics - Setting Up Universal Plug and Play|Advanced Topics - Setting Up Universal Plug and Play]]
+
! colspan="3" align="center" | [[Bering-uClibc 5.x - User Guide - Advanced Topics - Setting Up a Network Emulator|Advanced Topics - Setting Up a Network Emulator]]
 
|-
 
|-
−
| width="20%" align="left"  | [[Bering-uClibc 5.x - User Guide - Advanced Topics - Setting Up Zeroconf Networking|Prev]]
+
| width="20%" align="left"  | [[Bering-uClibc 5.x - User Guide - Advanced Topics - Setting Up a Bridge|Prev]]
 
! width="60%" align="center" | [[Bering-uClibc 5.x - User Guide]]
 
! width="60%" align="center" | [[Bering-uClibc 5.x - User Guide]]
−
| width="20%" align="right"  | [[Bering-uClibc 5.x - User Guide - Advanced Topics - Setting Up Tor|Next]]
+
| width="20%" align="right"  | [[Bering-uClibc 5.x - User Guide - Advanced Topics - Setting Up Zeroconf Networking|Next]]
 
|}
 
|}
 
----
 
----
  
  
−
'''This material copied directly from http://leaf.sourceforge.net/doc/bucu-upnpd.html - needs to be checked/updated for Bering-uClibc 5.x!'''
+
==Introduction==
 +
[[Bering-uClibc 5.x]] includes the "netem" kernel Module which can be used in a test environment to simulate the effect of wide-area network characteristics such as high latency and packet loss.
  
−
==Overview of UPnP==
+
The netem project page is [http://www.linuxfoundation.org/collaborate/workgroups/networking/netem here] and contains simple usage instructions and FAQs.
−
''Universal Plug and Play'' is intended to automate the installation and configuration of a small network as much as possible. This means that UPnP capable devices can join and leave a network without any effort of a network administrator.
+
There is also a PDF file with a useful conference paper from 2005 [http://developer.osdl.org/shemminger/netem/LCA2005_paper.pdf here].
  
−
The <code class="filename">upnpd.lrp</code> Package provides ''Internet Gateway Device'' services to the network. It is a port of the [http://linux-igd.sourceforge.net/ linux-igd project] and [http://upnp.sourceforge.net/ UPnP SDK project] to the LEAF environment. The firewall will advertise itself as an ''Internet Gateway''to all UPnP control points (clients). The clients can query the firewall to learn more about its status (bandwidth, traffic statistics), but one of the most useful features is the ability for client applications to request NAT/firewall traversal.
+
In summary, <tt>netem</tt> is an advanced network traffic Queueing Discipline (<tt>qdisc</tt>) for the Linux kernel, just like <tt>pfifo_fast</tt> or <tt>tbf</tt>. Like the other qdiscs it acts on packets ''sent'' by a particular network interface, in this case providing options to:
 +
* Delay packets, to simulate network latency
 +
** In addition to a simple fixed delay there are advanced options to apply a variable delay to better emulate real-world network conditions
 +
* Drop packets, to simulate packet loss
 +
* Duplicate and re-order packets
 +
* Corrupt packets
 +
While netem itself does not apply rate control (e.g. to simulate a low-bandwidth link) it can be used in conjunction with other qdiscs which do that.
  
−
While many common applications running on the Internet are simple client requests which are NAT and firewall friendly (e.g. http), some applications require the host behind the NAT/firewall device to receive inbound sessions. Common examples of this include ''direct connect'' features for instant messaging/multimedia conferencing (e.g. AIM, MSN, Y! Messenger). Other examples include peer-to-peer applications like Bittorrent and Gnutella. In each of these cases, the clients act as temporary servers, but these clients may be desktop machines that are assigned dynamic addresses and use dynamic port assignment. Hand configured <code class="code">DNAT</code> and <code class="code">FORWARD</code> rules on the firewall don't work well in such an environment.
+
Since netem is implemented as a qdisc, a [[LEAF]] machine with netem installed can be deployed in a variety of different network topologies. For example:
 +
* As a transparent Bridge, connected between a client PC and its upstream network connection, where it has the effect of emulating a Wide Area Network link between the client PC and the rest of the network
 +
* As part of a Router / Firewall installation
  
−
For more information on UPnP, search the Intel and Microsoft websites for descriptions of UPnP. Alcatel has provided a [http://www.speedtouch.nl/docs/AppNotes/AppNote_UPnP.pdf good overview] of the internals of the UPnP protocol and how it works with their SOHO routers, the basic concepts are similar and can be used to understand this implementation.
+
This guide uses the Bridge deployment model as an example, using netem along with tbf to emulate a high-latency and low-bandwidth WAN link.
  
−
'''Warning:''' The Universal Plug-n-Play IGD protocol assumes that the devices on the inside of your firewall are trusted, -and- that there is only one exterior interface that requires NAT traversal. This is the common case in small offices and homes. Most SOHO routers shipped today support UPnP because it is such a useful feature. However, a malicious or compromised control point (client on your internal network) can potentially open up a hole in your firewall from the Internet to any port on any machine on your internal network. Additionally, this particular implementation has not undergone rigorous security testing and may be vulnerable to buffer overflows, allowing a malicious control point to gain unauthorized access to the firewall. It is imperative that only trusted hosts be allowed to interact with the UPnP services running on the firewall.
+
==Software Installation==
 +
===Packages===
 +
There is currently (as of Bering-uClibc 5.0-alpha) no specific Package for netem, although consideration is being given to creating one which includes the "distribution" <code class="filename">.dist</code> data files from the <code class="filename">iproute2</code> source Package.
  
−
This implementation of UPnP IGD services assumes that there is a single UPnP client network (internal network) and a single external (Internet) connection. While it will run on a multi-port firewall, only one internal interface should be allowed to interact with the UPnP daemon. If you wish to use this on a firewall with multiple interfaces with different security policies, it is your responsibility to insure that your firewall policy does not allow a UPnP client on one interface to open up a hole in your firewall to a host on another interface.
+
Use of netem does however require installation of the <code class="filename">tc.lrp</code> Package, for the '''tc''' command, and deployment of a Bridge requires <code class="filename">bridge.lrp</code>.
  
−
==Firewalling UPnP==
+
===Kernel Module===
−
The UPnP server does not require, and should not be allowed any access to or from any network other than the internal client network. For UPnP to operate, your firewall must allow the following:
+
Use of netem requires that kernel module file <code class="filename">sch_netem.ko.gz</code> is available in directory <code class="filename">/lib/modules/</code>.
 +
This file should be extracted from <code class="filename">modules.tgz</code> (its full path within that tar archive is <code class="filename">kernel/net/sched/sch_netem.ko.gz</code>).
  
−
{| summary="Firewall passthroughs" border="1"
 
−
|-
 
−
! align="left" | Protocol/Port
 
−
! align="left" | Destination
 
−
! align="left" | Remarks
 
−
|-
 
−
| align="left" | UDP 1900
 
−
| align="left" | fw to/from local
 
−
| align="left" | SSDP announcements
 
−
|-
 
−
| align="left" | TCP 49152
 
−
| align="left" | fw from local
 
−
| align="left" | HTTP/XML mini-server
 
−
|-
 
−
| align="left" | TCP <span class="emphasis">''any port''</span>
 
−
| align="left" | fw to local
 
−
| align="left" | HTTP/XML queries of other UPnP devices
 
−
|-
 
−
| align="left" | UDP <span class="emphasis">''any port''</span>
 
−
| align="left" | fw to local
 
−
| align="left" | respond to remote SSDP requests
 
−
|}
 
−
 
−
Additionally, both UPnP on the router and on your control-point clients generate SSDP packets which are multicast to 239.255.255.250. Both also send and listen to IGMP join messages on 224.0.0.22. You must have a route covering these multicast groups pointing towards your internal network or the announcements will be sent towards your default route, which is almost always not what you want. The UPnP wrapper scripts provided in this package will set up a multicast route for you, or you can specify what you want in <code class="filename">/etc/default/upnpd</code>.
 
−
 
−
When a client requests NAT traversal, rules will be created in the <code class="code">forwardUPnP</code> <code class="code">FORWARDING</code> table and UPnP <code class="code">PREROUTING</code> table. This is not the default behavior for UPnP -- it normally writes directly to <code class="code">FORWARDING</code> and <code class="code">PREROUTING</code>.
 
−
 
−
'''Important:''' If you are not integrating with [http://www.shorewall.net/ Shorewall] as described in this document, you will want to change the configuration in <code class="filename">/etc/upnpd.conf</code>.
 
−
 
−
==Installation==
 
−
* load the <code class="filename">upnpd.lrp</code> Package
 
−
* edit <code class="filename">/etc/default/upnpd</code> to specify your external and internal network interfaces and to disable/modify multicast route generation
 
−
* edit <code class="filename">/etc/upnpd.conf</code> to describe your bandwidth available upstream and downstream (optional)
 
−
* install and configure <code class="filename">shorwall.lrp</code> if you have not already done so (Shorewall is suggested, not required)
 
−
 
−
==Shorewall integration==
 
−
Proper integration with your firewall policy can be a complex matter requiring local thought. This example should be reviewed for your local conditions and is a good starting place.
 
−
 
−
Shorewall uses the <code class="filename">ipt_owner.o</code> kernel Module for UPnP support. <code class="filename">ipt_owner.o</code> can be found in the Bering-uClibc kernel Modules tarball. Add it to <code class="filename">/lib/modules</code> and make sure it is loaded in <code class="filename">/etc/modules</code> at system startup. If you see an error message when Shorewall runs trying to add an iptables rule with the <code class="code">--cmd-owner</code> option, <code class="filename">ipt_owner.o</code> is not loaded.
 
−
 
−
Specify in <code class="filename">/etc/shorewall/interfaces</code> which interface is your upstream interface (your Internet interface) which will receive inbound connection requests after UPnP has authorized them. Add the "upnp" option to that interface.
 
−
 
−
Example:
 
−
net  ppp0  -    upnp,tcpflags,blacklist,routefilter,norfc1918,nosmurfs
 
−
 
−
Apply the UPnP specific rules in your shorewall rules file. In this example, <span class="emphasis">''loc''</span> is your internal network zone where UPnP clients are located, <span class="emphasis">''net''</span> is the upstream network (Internet):
 
  
−
forwardUPnP    net    loc  # dynamic rules inserted here
+
'''To be continued...'''
−
allowinUPnP    loc    fw  # allow from control points
+
−
allowoutUPnP    fw      loc  # allow communication to control points
+
  
  
 
----
 
----
 
{| summary="Navigation footer" width="100%"
 
{| summary="Navigation footer" width="100%"
−
| width="40%" align="left"  | [[Bering-uClibc 5.x - User Guide - Advanced Topics - Setting Up Zeroconf Networking|Prev]]
+
| width="40%" align="left"  | [[Bering-uClibc 5.x - User Guide - Advanced Topics - Setting Up a Bridge|Prev]]
 
| width="20%" align="center" | [[Bering-uClibc 5.x - User Guide - Advanced Topics|Up]]
 
| width="20%" align="center" | [[Bering-uClibc 5.x - User Guide - Advanced Topics|Up]]
−
| width="40%" align="right"  | [[Bering-uClibc 5.x - User Guide - Advanced Topics - Setting Up Tor|Next]]
+
| width="40%" align="right"  | [[Bering-uClibc 5.x - User Guide - Advanced Topics - Setting Up Zeroconf Networking|Next]]
 
|}
 
|}
  
 
[[Category:Bering-uClibc 5.x]]
 
[[Category:Bering-uClibc 5.x]]
 
[[Category:User Guide]]
 
[[Category:User Guide]]

Latest revision as of 12:04, 27 October 2012

Advanced Topics - Setting Up a Network Emulator
Prev Bering-uClibc 5.x - User Guide Next


Introduction

Bering-uClibc 5.x includes the "netem" kernel Module which can be used in a test environment to simulate the effect of wide-area network characteristics such as high latency and packet loss.

The netem project page is here and contains simple usage instructions and FAQs. There is also a PDF file with a useful conference paper from 2005 here.

In summary, netem is an advanced network traffic Queueing Discipline (qdisc) for the Linux kernel, just like pfifo_fast or tbf. Like the other qdiscs it acts on packets sent by a particular network interface, in this case providing options to:

  • Delay packets, to simulate network latency
    • In addition to a simple fixed delay there are advanced options to apply a variable delay to better emulate real-world network conditions
  • Drop packets, to simulate packet loss
  • Duplicate and re-order packets
  • Corrupt packets

While netem itself does not apply rate control (e.g. to simulate a low-bandwidth link) it can be used in conjunction with other qdiscs which do that.

Since netem is implemented as a qdisc, a LEAF machine with netem installed can be deployed in a variety of different network topologies. For example:

  • As a transparent Bridge, connected between a client PC and its upstream network connection, where it has the effect of emulating a Wide Area Network link between the client PC and the rest of the network
  • As part of a Router / Firewall installation

This guide uses the Bridge deployment model as an example, using netem along with tbf to emulate a high-latency and low-bandwidth WAN link.

Software Installation

Packages

There is currently (as of Bering-uClibc 5.0-alpha) no specific Package for netem, although consideration is being given to creating one which includes the "distribution" .dist data files from the iproute2 source Package.

Use of netem does however require installation of the tc.lrp Package, for the tc command, and deployment of a Bridge requires bridge.lrp.

Kernel Module

Use of netem requires that kernel module file sch_netem.ko.gz is available in directory /lib/modules/. This file should be extracted from modules.tgz (its full path within that tar archive is kernel/net/sched/sch_netem.ko.gz).


To be continued...


Prev Up Next
Retrieved from "http://bering-uclibc.zetam.org/index.php?title=Bering-uClibc_5.x_-_User_Guide_-_Advanced_Topics_-_Setting_Up_a_Network_Emulator&oldid=1408"