ARP request

ARP requests are never forwarded to reach the end host in IP-routed networks. [original post]

“There will never be an ARP request from “the internet” asking about the address for one of your hosts. IP addresses are used for end-to-end routing. Hardware addresses are used only for single hops. So if some host on the internet sends a ping, every router along the way will look at the destination IP address, consult its routing table for the next hop (IP address) in the right direction, and send the packet to the next hop host or router. To do that very last step (forward the packet to the next hop), the router needs to know the hardware address of the next hop. But it does not need to know the hardware address of the destination host. This means that arp requests are never forwarded. They are only generated for IP addresses that are directly attached to the router that is sending the request. So no router except yours will ever send an arp request for the hosts that are serviced by your router.”

ARP request for address 0.0.0.0 means that each host which receives the request must reply. [original post]

“The address ‘0.0.0.0’ is the ‘any’ address. That means, ‘any’ host should answer that request.”

Compiling error of hping: “DBYTE_ORDER_(BIG|LITTLE)_ENDIAN”

Taken from the original post.
Symptom:

[root@localhost hping3]#./configure

bytesex.h:22:3: error: #error can not find the byte order for this architecture, fix bytesex.h

In file included from rapd.c:11:
 ars.h:190:2: error: #error "Please, edit Makefile and add -DBYTE_ORDER_(BIG|LITTLE)_ENDIAN"
 ars.h:254:2: error: #error "Please, edit Makefile and add -DBYTE_ORDER_(BIG|LITTLE)_ENDIAN"
 ars.h:323:2: error: #error "Please, edit Makefile and add -DBYTE_ORDER_(BIG|LITTLE)_ENDIAN"
 In file included from ars.h:20,
 from split.c:11:
 bytesex.h:22:3: error: #error can not find the byte order for this architecture, fix bytesex.h
 In file included from split.c:11:
 ars.h:190:2: error: #error "Please, edit Makefile and add -DBYTE_ORDER_(BIG|LITTLE)_ENDIAN"
 ars.h:254:2: error: #error "Please, edit Makefile and add -DBYTE_ORDER_(BIG|LITTLE)_ENDIAN"
 ars.h:323:2: error: #error "Please, edit Makefile and add -DBYTE_ORDER_(BIG|LITTLE)_ENDIAN"
 now you can try `make'

To resolve:

Since this was a x86_64 architecture, and it was not in the bytesex.h you just need to add in a line as below  and ./configure again.
[root@localhost hping3-20051105]# cat bytesex.h
/* Original code from the Linux C library */

/* Copyright (C) 2000,2001 Salvatore Sanfilippo

 * This code is under the original GNU C library license (GPL) */

/* $Id: bytesex.h,v 1.1.1.1 2003/08/31 17:23:48 antirez Exp $ */

#ifndef ARS_BYTESEX_H
#define ARS_BYTESEX_H

#if     defined(__i386__) \
        || defined(__alpha__) \
        || defined(__x86_64__) \
        || (defined(__mips__) && (defined(MIPSEL) || defined (__MIPSEL__)))
#define BYTE_ORDER_LITTLE_ENDIAN

#elif   defined(__mc68000__) \
        || defined (__sparc__) \
        || defined (__sparc) \
        || defined (__PPC__) \
        || defined (__BIG_ENDIAN__) \
        || (defined(__mips__) && (defined(MIPSEB) || defined (__MIPSEB__)))

#define BYTE_ORDER_BIG_ENDIAN

#else

# error can not find the byte order for this architecture, fix bytesex.h

#endif


#endif /* ARS_BYTESEX_H */

How to connect OpenFlow switches to multiple controllers (Mininet)

Original post is here.

#!/usr/bin/python

from mininet.net import Mininet
from mininet.node import Controller, RemoteController
from mininet.cli import CLI
from mininet.log import setLogLevel, info

def myNet():


    #OpenDayLight controller
    ODL_CONTROLLER_IP='10.0.0.4'

    #Floodlight controller
    FL_CONTROLLER_IP='10.0.0.5'

    net = Mininet( topo=None, build=False)

    # Create nodes
    h1 = net.addHost( 'h1', mac='01:00:00:00:01:00', ip='192.168.0.1/24' )
    h2 = net.addHost( 'h2', mac='01:00:00:00:02:00', ip='192.168.0.2/24' )

    # Create switches
    s1 = net.addSwitch( 's1', listenPort=6634, mac='00:00:00:00:00:01' )
    s2 = net.addSwitch( 's2', listenPort=6634, mac='00:00:00:00:00:02' )

    print "*** Creating links"
    net.addLink(h1, s1, )
    net.addLink(h2, s2, )   
    net.addLink(s1, s2, )  

    # Add Controllers
    odl_ctrl = net.addController( 'c0', controller=RemoteController, ip=ODL_CONTROLLER_IP, port=6633)

    fl_ctrl = net.addController( 'c1', controller=RemoteController, ip=FL_CONTROLLER_IP, port=6633)


    net.build()

    # Connect each switch to a different controller
    s1.start( [odl_ctrl] )
    s2.start( [fl_ctrl] )

    s1.cmdPrint('ovs-vsctl show')

    CLI( net )
    net.stop()

if __name__ == '__main__':
    setLogLevel( 'info' )
    myNet()

NETIF_F_NETNS_LOCAL

Original post here.

NETIF_F_NETNS_LOCAL a flag to indicate
a network device is local to a single network namespace and
should never be moved.  Useful for pseudo devices that we
need an instance in each network namespace (like the loopback
device) and for any device we find that cannot handle multiple
network namespaces so we may trap them in the initial network
namespace.

 

Linux Kernel Network Namespace (NETNS)

Original post here.

“So what are network namespaces? Generally speaking, an installation of Linux shares a single set of network interfaces and routing table entries. You can modify the routing table entries using policy routing (here’s an introduction I wrote and here’s a write-up on a potential use case for policy routing), but that doesn’t fundamentally change the fact that the set of network interfaces and routing tables/entries are shared across the entire OS. Network namespaces change that fundamental assumption. With network namespaces, you can have different and separate instances of network interfaces and routing tables that operate independent of each other.”