• F4_308883
  • 1.2MB
  • rar
  • 0
  • VIP专享
  • 0
  • 2022-04-13 01:48
BASIC MULTICAST FORWARDING PLUGIN FOR OLSRD by Erik Tromp (erik.tromp@nl.thalesgroup.com, erik_tromp@hotmail.com) Version 1.5.3 1. Introduction --------------- The Basic Multicast Forwarding Plugin floods IP-multicast and IP-local-broadcast traffic over an OLSRD network. It uses the Multi-Point Relays (MPRs) as identified by the OLSR protocol to optimize the flooding of multicast and local broadcast packets to all the hosts in the network. To prevent broadcast storms, a history of packets is kept; only packets that have not been seen in the past 3-6 seconds are forwarded. 2. How to build and install --------------------------- Download the olsr-bmf-v1.5.3.tar.gz file and save it into your OLSRD base install directory. Change directory (cd) to your OLSRD base install directory. At the command prompt, type: tar -zxvf ./olsr-bmf-v1.5.3.tar.gz then type: make build_all followed by: make install_all Next, turn on the possibility to create a tuntap interface (see also /usr/src/linux/Documentation/networking/tuntap.txt): mkdir /dev/net # if it doesn't exist already mknod /dev/net/tun c 10 200 Set permissions, e.g.: chmod 0700 /dev/net/tun To configure BMF in OLSR, you must edit the file /etc/olsrd.conf to load the BMF plugin. For example, add the following lines: LoadPlugin "olsrd_bmf.so.1.5.3" { # No PlParam entries required for basic operation } 3. How to run ------------- After building and installing OLSRD with the BMF plugin, run the olsrd daemon by entering at the shell prompt: olsrd Look at the output; it should list the BMF plugin, e.g.: ---------- LOADING LIBRARY olsrd_bmf.so.1.5.3 ---------- OLSRD Basic Multicast Forwarding (BMF) plugin 1.5.3 (Feb 24 2008 17:58:02) (C) Thales Communications Huizen, Netherlands Erik Tromp (eriktromp@users.sourceforge.net) Checking plugin interface version: 5 - OK Trying to fetch plugin init function: OK Trying to fetch parameter table and it's size... Sending parameters... "NonOlsrIf"/"eth0"... NonOlsrIf: OK Running plugin_init function... OLSRD Basic Multicast Forwarding (BMF) plugin: opened 5 sockets ---------- LIBRARY olsrd_bmf.so.1.5.3 LOADED ---------- 4. How to check if it works --------------------------- Enter the following command on the command prompt: ping All OLSR-BMF hosts in the OLSR network should respond. For example, assume we have three hosts, with IP addresses, and On host we enter the following ping command: root@IsdbServer:~# ping PING ( 56(84) bytes of data. 64 bytes from icmp_seq=1 ttl=64 time=0.511 ms 64 bytes from icmp_seq=1 ttl=64 time=4.67 ms (DUP!) 64 bytes from icmp_seq=1 ttl=63 time=10.7 ms (DUP!) 64 bytes from icmp_seq=2 ttl=64 time=0.076 ms 64 bytes from icmp_seq=2 ttl=64 time=1.23 ms (DUP!) 64 bytes from icmp_seq=2 ttl=63 time=1.23 ms (DUP!) 64 bytes from icmp_seq=3 ttl=64 time=0.059 ms 64 bytes from icmp_seq=3 ttl=64 time=2.94 ms (DUP!) 64 bytes from icmp_seq=3 ttl=63 time=5.62 ms (DUP!) 64 bytes from icmp_seq=4 ttl=64 time=0.158 ms 64 bytes from icmp_seq=4 ttl=64 time=1.14 ms (DUP!) 64 bytes from icmp_seq=4 ttl=63 time=1.16 ms (DUP!) We can see the response from the originating host ( (it is normal behaviour for hosts sending multicast packets to receive their own packets). We can also see the responses by the other hosts (correctly seen as DUPlicates by ping). Note: when using an older version of ping than the standard from iputils-20020927, as found in most current Linux distributions, you may want to test BMF by specifying the output interface to the ping command: ping -I bmf0 Older versions of 'ping' (e.g. as found in iputils-20020124) may bind to the autoselected source address, which may be incorrect. Since BMF re-uses one of the existing IP addresses for the "bmf0" network interface, the older-version ping command may 'autobind' to the wrong interface. See also the note in the iputils-20020927/RELNOTES file: "* Mads Martin J�rgensen <mmj@suse.de>: ping should not bind to autoselected source address, it used to work when routing changes. Return classic behaviour, option -B is added to enforce binding." 5. How does it work ------------------- In the IP header there is room for only two IP-addresses: * the destination IP address (in our case either a multicast IP-address, or a local broadcast address e.g., and * the source IP address (the originator). For optimized flooding, however, we need more information. Let's assume we are the BMF process on one host. We will need to know which host forwarded the IP packet to us. Since OLSR keeps track of which hosts select our host as MPR (see the olsr_lookup_mprs_set(...) function), we can determine if the host that forwarded the packet, has selected us as MPR. If so, we must also forward the packet, changing the 'forwarded-by' IP-address to that of us. If not, we do not forward the packet. Because we need more information than fits in a normal IP-header, the original packets are encapsulated into a new IP packet. Encapsulated packets are transported in UDP, port 50698. The source address of the encapsulation packet is set to the address of the forwarder instead of the originator. Of course, the payload of the encapsulation packet is the original IP packet. For an exact specification of the encapsulation format, refer to paragraph 10 below. For local reception, each received encapsulated packets is unpacked and passed into a tuntap interface which is specially created for this purpose. There are other flooding solutions available that do not use encapsulation. The problem with these solutions is that they cannot prevent duplicates of forwarded packets to enter the IP stack. For example, if a host is receiving flooded (unencapsulated, native IP) packets via two MPR hosts, there is no way to stop the reception of the packets coming in via the second MPR host. To prevent this, BMF uses a combination of encapsulated flooding and local reception via a tuntap interface. Here is in short how the flooding works (see also the BmfEncapsulatedPacketReceived(...) function; details with respect to the forwarding towards non-OLSR enabled hosts are omitted): On all OLSR-enabled interfaces, setup reception of packets on UDP port 50698. Upon reception of such a packet: If the received packet was sent by myself, drop it. If the packet was recently seen, drop it. Unpack the encapsulated packet and send a copy to myself via the TunTap interface. If I am an MPR for the host that forwarded the packet to me, forward the packet to all OLSR-enabled interfaces *including* the interface on which it was received. 6. Advanced configuration ------------------------- All configuration of BMF is done via the "LoadPlugin" section in the /etc/olsrd.conf file. The following gives an overview of all plugin parameters that can be configured: LoadPlugin "olsrd_bmf.so.1.5.3" { # Specify the name of the BMF network interface. # Defaults to "bmf0". PlParam "BmfInterface" "mybmf0" # Specify the IP address and mask for the BMF network interface. # By default, the IP address of the first OLSR interface is copied. # The default prefix length is 32. PlParam "BmfInterfaceIp" "" # Enable or disable the flooding of local broadcast packets # (e.g. packets with IP destination Either "yes" # or "no". Defaults to "yes". PlParam "DoLocalBroadcast" "no" # Enable or disable the capturing packets on the OLSR-enabled # interfaces (in promiscuous mode). Either "yes" or "no". Defaults # t
    • C++ Primer
      C++经典教程,其内容是C++大师Stanley B. Lippman丰富的实践经验和C++标准委员会原负责人Josée Lajoie对C++标准深入理解的完美结合,已经帮助全球无数程序员学会了C++。 对C++基本概念和技术全面而且权威的阐述,对...
    • c++课件
    • C++ PRrimer
      本书是久负盛名的C++经典教程,其内容是C++大师Stanley B. Lippman丰富的实践经验和C++标准委员会原负责人Josée Lajoie对C++标准深入理解的完美结合,已经帮助全球无数程序员学会了C++。本版对前一版进行了彻底的...
    • C++
    • C++ primer
      本文档具有C++ primer 以及 C++ primer 标准答案各一份,内容清晰充实!希望与热爱C++的学友们一起同舟共济,努力学习!
    • c++information
    • c++yuyanbiancheng
    • effective C++
    • C++ Primer
    • C++ Primer
      本书是久负盛名的C++经典教程引,其内容是C++大师Stanley B. Lippman丰富的实践经验和C++标准委员会原负责人Josée Lajoie对C++标准深入理解的完美结合,已经帮助全球无数程序员学会了C++