Connecting two Mininet networks with GRE tunnel – Part 2

Update: Find another post about how I used Linux GRE tunnels to do the same.

—-

This is a followup to an older post about connecting two MiniNet sessions with a GRE tunnel. I’ve made up some new scripts to help test the functionality plus I’ll provide a little more information on checking if the GRE tunnel is actually registered. The one problem I have run into a few times using Open vSwitch was trying to get the GRE tunnel interface on each switch to register with the controller. If it doesn’t register, then you aren’t going to see any traffic flow across. For this example, both MiniNet sessions will connect to a remote controller. This will also help show if the GRE registered.

The following in the MiniNet python script that you will run on the your first VM.

#!/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 emptyNet():

    NODE2_IP='192.168.56.103'
    CONTROLLER_IP='192.168.56.103'

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

    net.addController( 'c0',
                      controller=RemoteController,
                      ip=CONTROLLER_IP,
                      port=6633)

    h1 = net.addHost( 'h1', ip='10.0.0.1' )
    h2 = net.addHost( 'h2', ip='10.0.0.2' )
    s1 = net.addSwitch( 's1' )
    net.addLink( h1, s1 )
    net.addLink( h2, s1 )
    net.start()

    # Configure the GRE tunnel
    s1.cmd('ovs-vsctl add-port s1 s1-gre1 -- set interface s1-gre1 type=gre options:remote_ip='+NODE2_IP)
    s1.cmdPrint('ovs-vsctl show')

    CLI( net )
    net.stop()

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

This next MiniNet python script will be run on another VM.

#!/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 emptyNet():

    NODE1_IP='192.168.56.102'
    CONTROLLER_IP='192.168.56.103'

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

    net.addController( 'c0',
                      controller=RemoteController,
                      ip=CONTROLLER_IP,
                      port=6633)

    h3 = net.addHost( 'h3', ip='10.0.0.3' )
    h4 = net.addHost( 'h4', ip='10.0.0.4' )
    s2 = net.addSwitch( 's2' )
    net.addLink( h3, s2 )
    net.addLink( h4, s2 )
    net.start()

    # Configure the GRE tunnel
    s2.cmd('ovs-vsctl add-port s2 s2-gre1 -- set interface s2-gre1 type=gre options:remote_ip='+NODE1_IP)
    s2.cmdPrint('ovs-vsctl show')

    CLI( net )
    net.stop()

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

You will need to modify the scripts to set the IP addresses at the top to the appropriate values for your environment. Once the scripts are ready, we’ll start them up. Don’t worry about the message about not being able to contact the controller. We’ll start it up after. Also, I’ve configured the scripts to automatically create the GRE tunnel to the other MiniNets.

On VM1.

mininet@mininet21:~$ sudo ./greTest-1.py
Unable to contact the remote controller at 192.168.56.103:6633
*** Configuring hosts
h1 h2
*** Starting controller
*** Starting 1 switches
s1
*** s1 : ('ovs-vsctl show',)
007a537b-9138-4ee9-b0dd-77182c3b4cea
    Bridge "s1"
        Controller "tcp:192.168.56.103:6633"
        fail_mode: secure
        Port "s1-eth1"
            Interface "s1-eth1"
        Port "s1-eth2"
            Interface "s1-eth2"
        Port "s1-gre1"
            Interface "s1-gre1"
                type: gre
                options: {remote_ip="192.168.56.103"}
        Port "s1"
            Interface "s1"
                type: internal
    ovs_version: "1.4.0+build0"
*** Starting CLI:
mininet>

On VM2:

mininet@mininet21:~$ sudo ./greTest-2.py
*** Configuring hosts
h3 h4
*** Starting controller
*** Starting 1 switches
s2
*** s2 : ('ovs-vsctl show',)
ef39063c-46be-44e3-b89c-faaf7ffcf351
    Bridge "s2"
        Controller "tcp:192.168.56.103:6633"
        fail_mode: secure
        Port "s2-gre1"
            Interface "s2-gre1"
                type: gre
                options: {remote_ip="192.168.56.102"}
        Port "s2-eth1"
            Interface "s2-eth1"
        Port "s2-eth2"
            Interface "s2-eth2"
        Port "s2"
            Interface "s2"
                type: internal
    ovs_version: "1.4.0+build0"
*** Starting CLI:
mininet>

Now start the controller. For this test, I’m just going to use the OpenFlow reference controller.

mininet@mininet21:~$ controller -v ptcp:6633

The above will start printing a lot of messages as soon at the switches start connecting to the controller. But here is where you want to watch closely as the switches register. You want to look for the following message.

Jan 20 21:24:10|00009|vconn|DBG|tcp:192.168.56.102:41173: received: features_reply (xid=0x9ba82531): ver:0x1, dpid:1
n_tables:255, n_buffers:256
features: capabilities:0xc7, actions:0xfff
 1(s1-eth1): addr:ca:06:71:62:79:85, config: 0, state:0
     current:    10GB-FD COPPER
 2(s1-eth2): addr:72:89:9d:be:6f:1f, config: 0, state:0
     current:    10GB-FD COPPER
 3(s1-gre1): addr:fe:d4:30:b3:b9:e0, config: 0, state:0
 LOCAL(s1): addr:9a:a3:5c:e3:01:40, config: 0x1, state:0x1

Jan 20 21:24:11|00017|vconn|DBG|tcp:192.168.56.103:36309: received: features_reply (xid=0x9a4c5b0d): ver:0x1, dpid:2
n_tables:255, n_buffers:256
features: capabilities:0xc7, actions:0xfff
 1(s2-eth1): addr:72:52:76:ea:d6:90, config: 0, state:0
     current:    10GB-FD COPPER
 2(s2-eth2): addr:d2:80:1b:4b:89:43, config: 0, state:0
     current:    10GB-FD COPPER
 3(s2-gre1): addr:6e:ad:4b:5c:e6:be, config: 0, state:0
 LOCAL(s2): addr:ae:49:99:96:c7:4e, config: 0x1, state:0x1

The above two messages that got printed out are what is important. Make sure you see your GRE interface listed for each switch. If it isn’t there, then something is wrong with your configuration or with the Open vSwitch that you have installed. If all looks good, then the last step is to verify with some traffic.

In MiniNet on VM1:

mininet> h1 ping -c 1 10.0.0.3
PING 10.0.0.3 (10.0.0.3) 56(84) bytes of data.
64 bytes from 10.0.0.3: icmp_req=1 ttl=64 time=0.613 ms

--- 10.0.0.3 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.613/0.613/0.613/0.000 ms

There you go. I sent a ping from h1 on VM1 to h3 on VM2 over the GRE tunnel. In the above example I use the reference controller. You can use whatever controller you wish and it might give you more details on the interfaces and connection. Just update the CONTROLLER_IP with the IP address where your controller is running.

Hope these new scripts and extra info help you in your journey.

This post ‘Connecting two Mininet networks with GRE tunnel – Part 2’ first appeared on https://gregorygee.wordpress.com/.

Advertisements

9 Responses to Connecting two Mininet networks with GRE tunnel – Part 2

  1. Pingback: Connecting two Mininet networks with GRE tunnel | Tech and Trains

  2. ashish says:

    Hi Gregory Gee. I tried to implement GRE tunneling using OVS. I set up two VM on Virtua Box. In each of the VM started mininet with two hosts by sudo mn –mac. I do not know how to set the IP address of the VMs to a specific address. Can you help me with that?

    • Gregory Gee says:

      If you are talking about setting the IP address of the VirtualBox VM, that depends on the OS that you are running. Nothing specific about Mininet here. You should be able to just use the IP addresses that got assigned to the VM already.

      • ashish says:

        Hi Greogery. I am having two Ubuntu VMs on virtual box on my windows host machine. Before trying to see GRE tunnel, I tried to ping the one VM from the other and even that is not functioning. I set the network adapter as Internal Network as shown in the YouTube video

        Do you think this is the right way to start? I think the rest of my configuration and flow commands are correct.

      • Gregory Gee says:

        Yes, setting up Internal Network is fine. You just need to set the static IPs.

        On VM#1, edit /etc/network/interfaces and add the following lines.
        auto eth1
        iface eth1 inet static
        address 10.0.0.100
        netmask 255.255.255.0
        gateway 10.0.0.1

        On VM#2, edit /etc/network/interfaces and add the following lines.
        auto eth1
        iface eth1 inet static
        address 10.0.0.101
        netmask 255.255.255.0
        gateway 10.0.0.1

        Now just reboot each. Eth1 on both VMs should have an IP address now.

      • ashish says:

        Dear Gregory,

        Thank you for your response. It worked. I have a doubt in mininet. if I have a host named h1, how can I set static mac table for h1. is it like the following?

        h1.setARP(“10.0.0.3″,”00:00:00:00:00:03”)

      • ashish says:

        Dear Gregory,

        While searching on the internet for the ovsdb-server errors, I found you also had exactly the same error as I have now.

        ovsdb-server : I/O error : /etc/openvswitch/conf.db : failed to lock lockfile

        How did you fix this error.

  3. GB says:

    Hi Gregory
    I have a question :) which type of network adapter do I should choose in each vm? NAT, internal, etc?
    Is it possible to use NAT?
    Thanks in advance

    • Gregory Gee says:

      NAT Network or internal might work if they are on same host PC. I was just using normal bridging when I tested. I can’t see NAT working since each VM needs to be able to address each other.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: