Skip to content

Tutorial 8: DIF renumbering SDN 2016

Eduard Grasa edited this page Feb 22, 2017 · 8 revisions

Introduction

The goal of this tutorial is to demonstrate how DIF renumbering (the procedure by which addresses of IPC Processes in a DIF are changed) is both a dynamic procedure and a non-service disrupting one. In this tutorial renumbering takes place in a single DIF of about 30 IPC Processes, with the structure of the GEANT European backbone network. This scenario, demonstrated at the SDN World Congress 2016, has been setup with the demonstrator, using an IRATI image with the master branch snapshot.

Tutorial 8 scenario: DIF structure (up) and backbone DIF connectivity graph (down)

Seamless renumbering is not only useful to change a network's addressing plan without disrupting existing flows, but also to change the addresses of mobile hosts in mobile networks, as explained in section 4 of this tutorial.

1. Getting the demonstrator

The Demonstrator is command-line tool (gen.py) which allows the user to easily try and test the IRATI stack in a multi-node scenario. Each node is implemented using a light Virtual Machine (VM), run under the control of the QEMU hypervisor. All the VMs are run locally without any risk for your PC, so you don't need a dedicated machine or multiple physical machines.

To install the demonstrator you need a physical Linux machine with support for QEMU and KVM. To obtain the demonstrator, just clone its repository:

git clone https://github.com/IRATI/demonstrator.git

After that cd into the demonstrator directory.

2. Looking at the renumbering demo configuration file

Before running the scenario, we will take a look at the GEANT2 DIF renumbering demo configuration file, located at examples/geant2-renumber.conf.

eth 2000 100Mbps lisbon madrid
eth 2001 100Mbps lisbon london
eth 2002 100Mbps london dublin
eth 2003 100Mbps london paris
eth 2004 100Mbps london brussels
eth 2005 100Mbps paris madrid
eth 2006 100Mbps paris luxemburg
eth 2007 100Mbps paris bern
eth 2008 100Mbps madrid bern
eth 2009 100Mbps bern roma
eth 2010 100Mbps roma madrid
eth 2011 100Mbps brussels amsterdam
eth 2012 100Mbps roma valleta
eth 2013 100Mbps amsterdam valleta
eth 2014 100Mbps bern berlin
eth 2015 100Mbps luxemburg berlin
eth 2016 100Mbps amsterdam berlin
eth 2017 100Mbps amsterdam copenhagen
eth 2018 100Mbps berlin copenhagen
eth 2019 100Mbps copenhagen oslo
eth 2020 100Mbps oslo stockholm
eth 2021 100Mbps stockholm copenhagen
eth 2023 100Mbps copenhagen tallin
eth 2024 100Mbps tallin riga
eth 2025 100Mbps riga vilnius
eth 2026 100Mbps vilnius warsaw
eth 2027 100Mbps warsaw berlin
eth 2028 100Mbps warsaw praha
eth 2029 100Mbps berlin praha
eth 2030 100Mbps berlin viena
eth 2031 100Mbps praha viena
eth 2032 100Mbps viena budapest
eth 2034 100Mbps viena ljubljana
eth 2035 100Mbps ljubljana zagreb
eth 2036 100Mbps zagreb budapest
eth 2037 100Mbps budapest sofia
eth 2038 100Mbps viena athens
eth 2039 100Mbps sofia athens
eth 2040 100Mbps athens roma
eth 2041 100Mbps sofia bucharest
eth 2042 100Mbps bucharest budapest
eth 2043 100Mbps athens nicosia
eth 2044 100Mbps roma nicosia
eth 2045 100Mbps sofia ankara
eth 2046 100Mbps bucharest ankara
eth 2047 100Mbps berlin moscow
eth 2048 100Mbps copenhagen moscow
eth 2049 100Mbps roma viena

# DIF renumber  
dif renumber lisbon 2000 2001
dif renumber madrid 2000 2005
dif renumber london 2001 2002 2003 2004
dif renumber dublin 2002
dif renumber paris 2003 2005 2006 2007
dif renumber brussels 2004 2011
dif renumber luxemburg 2006 2015
dif renumber bern 2007 2008 2009 2014
dif renumber roma 2009 2010 2012 2040 2044 2049
dif renumber amsterdam 2011 2013 2016 2017
dif renumber valleta 2012 2013
dif renumber berlin 2014 2015 2016 2018 2027 2029 2030 2047
dif renumber copenhagen 2017 2018 2019 2021 2023 2048
dif renumber oslo 2019 2020
dif renumber stockholm 2020 2021
dif renumber tallin 2023 2024
dif renumber riga 2024 2025
dif renumber vilnius 2025 2026
dif renumber warsaw 2026 2027 2028
dif renumber praha 2028 2029 2031
dif renumber viena 2030 2031 2032 2034 2038
dif renumber budapest 2032 2036 2037 2042
dif renumber athens 2038 2039 2040 2043
dif renumber ljubljana 2034 2035
dif renumber zagreb 2035 2036
dif renumber sofia 2037 2039 2041 2045
dif renumber bucharest 2041 2042 2046
dif renumber nicosia 2043 2044
dif renumber ankara 2045 2046
dif renumber moscow 2047 2048

#Policies

#address-change
policy renumber * namespace-manager address-change useNewTimeout=20001 deprecateOldTimeout=80001 changePeriod=120001 addressRange=100
policy renumber * routing link-state objectMaximumAge=10000 waitUntilReadCDAP=5001 waitUntilError=5001 waitUntilPDUFTComputation=103 waitUntilFSODBPropagation=101 waitUntilAgeIncrement=997 waitUntilDeprecateAddress=20001 routingAlgorithm=Dijkstra

3. Generating the configuration files for each machine and demonstrator scripts

Go back to the main demonstrator folder, and type the following command:

./gen.py -g -m 512 -e full-mesh --vhost -f virtio-net-pci -c examples/geant2-renumber.conf

This will generate a number of configuration files and two scripts: up.sh and down.sh. In this case we are using VMs with 512 MBs of RAM, you can run smaller machines. We are also telling the script to enroll all IPCPs to each other (full-mesh option) as long as they have connectivity via an N-1 DIF. The text output after running this script should be the following one:

You want to run a lot of nodes, so it's better if I give each node some time to boot (since the boot is CPU-intensive)
I am going to enroll bucharest to DIF renumber against neighbor budapest, through lower DIF 2042
I am going to enroll bucharest to DIF renumber against neighbor sofia, through lower DIF 2041
I am going to enroll madrid to DIF renumber against neighbor paris, through lower DIF 2005
I am going to enroll praha to DIF renumber against neighbor viena, through lower DIF 2031
I am going to enroll praha to DIF renumber against neighbor warsaw, through lower DIF 2028
I am going to enroll london to DIF renumber against neighbor paris, through lower DIF 2003
I am going to enroll lisbon to DIF renumber against neighbor madrid, through lower DIF 2000
I am going to enroll lisbon to DIF renumber against neighbor london, through lower DIF 2001
I am going to enroll amsterdam to DIF renumber against neighbor copenhagen, through lower DIF 2017
I am going to enroll amsterdam to DIF renumber against neighbor berlin, through lower DIF 2016
I am going to enroll amsterdam to DIF renumber against neighbor brussels, through lower DIF 2011
I am going to enroll amsterdam to DIF renumber against neighbor valleta, through lower DIF 2013
I am going to enroll copenhagen to DIF renumber against neighbor oslo, through lower DIF 2019
I am going to enroll copenhagen to DIF renumber against neighbor tallin, through lower DIF 2023
I am going to enroll copenhagen to DIF renumber against neighbor moscow, through lower DIF 2048
I am going to enroll copenhagen to DIF renumber against neighbor stockholm, through lower DIF 2021
I am going to enroll vilnius to DIF renumber against neighbor warsaw, through lower DIF 2026
I am going to enroll bern to DIF renumber against neighbor roma, through lower DIF 2009
I am going to enroll bern to DIF renumber against neighbor paris, through lower DIF 2007
I am going to enroll oslo to DIF renumber against neighbor stockholm, through lower DIF 2020
I am going to enroll riga to DIF renumber against neighbor tallin, through lower DIF 2024
I am going to enroll riga to DIF renumber against neighbor vilnius, through lower DIF 2025
I am going to enroll athens to DIF renumber against neighbor nicosia, through lower DIF 2043
I am going to enroll athens to DIF renumber against neighbor roma, through lower DIF 2040
I am going to enroll athens to DIF renumber against neighbor sofia, through lower DIF 2039
I am going to enroll athens to DIF renumber against neighbor viena, through lower DIF 2038
I am going to enroll ljubljana to DIF renumber against neighbor viena, through lower DIF 2034
I am going to enroll ljubljana to DIF renumber against neighbor zagreb, through lower DIF 2035
I am going to enroll nicosia to DIF renumber against neighbor roma, through lower DIF 2044
I am going to enroll luxemburg to DIF renumber against neighbor paris, through lower DIF 2006
I am going to enroll ankara to DIF renumber against neighbor bucharest, through lower DIF 2046
I am going to enroll ankara to DIF renumber against neighbor sofia, through lower DIF 2045
I am going to enroll berlin to DIF renumber against neighbor warsaw, through lower DIF 2027
I am going to enroll berlin to DIF renumber against neighbor copenhagen, through lower DIF 2018
I am going to enroll berlin to DIF renumber against neighbor viena, through lower DIF 2030
I am going to enroll berlin to DIF renumber against neighbor luxemburg, through lower DIF 2015
I am going to enroll berlin to DIF renumber against neighbor bern, through lower DIF 2014
I am going to enroll berlin to DIF renumber against neighbor moscow, through lower DIF 2047
I am going to enroll berlin to DIF renumber against neighbor praha, through lower DIF 2029
I am going to enroll brussels to DIF renumber against neighbor london, through lower DIF 2004
I am going to enroll budapest to DIF renumber against neighbor sofia, through lower DIF 2037
I am going to enroll budapest to DIF renumber against neighbor zagreb, through lower DIF 2036
I am going to enroll budapest to DIF renumber against neighbor viena, through lower DIF 2032
I am going to enroll dublin to DIF renumber against neighbor london, through lower DIF 2002
I am going to enroll roma to DIF renumber against neighbor valleta, through lower DIF 2012

4. Running the scenario

Just execute the up.sh script. This will create all required software bridges and virtual Ethernet interfaces in the hosts, create the VMs, copy the configuration files to each machine, run RINA and trigger enrollments. Since this scenario is quite large it may take something in the 5-10 minutes region for the up.sh script to finalize.

5. Verifying that renumbering is taking place at the DIF

The demo is configured in a way that each IPC Process in the GEANT DIF changes its address randomly once every [30-60] seconds. The way to see that this is actually happening is to check the IPC Process Daemon log files in any of the nodes. Within the demonstrator folder, we will access the Berlin node.

./access.sh berlin
Accessing buildroot VM berlin
Warning: Permanently added '[localhost]:2226' (ECDSA) to the list of known hosts.
# tail -f /var/log/renumber.4.IPCP-1.log 
181(1487610540)#ipcp[9].routing-ps-link-state (INFO): Computed new Next Hop and PDU Forwarding Tables
181(1487610540)#ipcp[9].routing-ps-link-state (INFO): Dest. addresses: 1700; ; QoS-id: 0; Next hops: 1700; ; 
181(1487610540)#ipcp[9].routing-ps-link-state (INFO): Dest. addresses: 4200; ; QoS-id: 0; Next hops: 1700; ; 
181(1487610540)#ipcp[9].routing-ps-link-state (INFO): Dest. addresses: 2200; ; QoS-id: 0; Next hops: 1700; ; 
181(1487610540)#ipcp[9].routing-ps-link-state (INFO): Dest. addresses: 2500; ; QoS-id: 0; Next hops: 2500; ; 
181(1487610540)#ipcp[9].routing-ps-link-state (INFO): Dest. addresses: 2600; ; QoS-id: 0; Next hops: 3000; ; 
181(1487610540)#ipcp[9].routing-ps-link-state (INFO): Dest. addresses: 2900; ; QoS-id: 0; Next hops: 3000; ; 
181(1487610540)#ipcp[9].routing-ps-link-state (INFO): Dest. addresses: 2700; ; QoS-id: 0; Next hops: 3000; ; 
181(1487610540)#ipcp[9].routing-ps-link-state (INFO): Dest. addresses: 3100; ; QoS-id: 0; Next hops: 3000; ; 
181(1487610540)#ipcp[9].routing-ps-link-state (INFO): Dest. addresses: 2800; ; QoS-id: 0; Next hops: 4300; ; 
181(1487610540)#ipcp[9].routing-ps-link-state (INFO): Dest. addresses: 4300; ; QoS-id: 0; Next hops: 4300; ; 
181(1487610540)#ipcp[9].routing-ps-link-state (INFO): Dest. addresses: 4600; ; QoS-id: 0; Next hops: 4300; ; 
181(1487610540)#ipcp[9].routing-ps-link-state (INFO): Dest. addresses: 3500; ; QoS-id: 0; Next hops: 3000; ; 
181(1487610540)#ipcp[9].routing-ps-link-state (INFO): Dest. addresses: 3000; ; QoS-id: 0; Next hops: 3000; ; 
181(1487610540)#ipcp[9].routing-ps-link-state (INFO): Dest. addresses: 3200; ; QoS-id: 0; Next hops: 3200; ; 
181(1487610540)#ipcp[9].routing-ps-link-state (INFO): Dest. addresses: 3300; ; QoS-id: 0; Next hops: 2100; ; 
181(1487610540)#ipcp[9].routing-ps-link-state (INFO): Dest. addresses: 3800; ; QoS-id: 0; Next hops: 2100; ; 
181(1487610540)#ipcp[9].routing-ps-link-state (INFO): Dest. addresses: 1900; ; QoS-id: 0; Next hops: 4300; ; 
181(1487610540)#ipcp[9].routing-ps-link-state (INFO): Dest. addresses: 3400; ; QoS-id: 0; Next hops: 2500; ; 
181(1487610540)#ipcp[9].routing-ps-link-state (INFO): Dest. addresses: 4000; ; QoS-id: 0; Next hops: 2500; ; 
181(1487610540)#ipcp[9].routing-ps-link-state (INFO): Dest. addresses: 2100; ; QoS-id: 0; Next hops: 2100; ; 
181(1487610540)#ipcp[9].routing-ps-link-state (INFO): Dest. addresses: 1800; ; QoS-id: 0; Next hops: 4300; ; 
181(1487610540)#ipcp[9].routing-ps-link-state (INFO): Dest. addresses: 3900; ; QoS-id: 0; Next hops: 4300; ; 
181(1487610540)#ipcp[9].routing-ps-link-state (INFO): Dest. addresses: 2300; ; QoS-id: 0; Next hops: 4300; ; 
181(1487610540)#ipcp[9].routing-ps-link-state (INFO): Dest. addresses: 3600; ; QoS-id: 0; Next hops: 3600; ; 
181(1487610540)#ipcp[9].routing-ps-link-state (INFO): Dest. addresses: 4500; ; QoS-id: 0; Next hops: 4500; ; 
181(1487610540)#ipcp[9].routing-ps-link-state (INFO): Dest. addresses: 3700; ; QoS-id: 0; Next hops: 2500; ; 
181(1487610540)#ipcp[9].routing-ps-link-state (INFO): Dest. addresses: 4100; ; QoS-id: 0; Next hops: 2500; ; 
181(1487610540)#ipcp[9].routing-ps-link-state (INFO): Dest. addresses: 4400; ; QoS-id: 0; Next hops: 4500; ; 
181(1487610540)#ipcp[9].routing-ps-link-state (INFO): Dest. addresses: 2400; ; QoS-id: 0; Next hops: 4300; ; 

We should see that the forwarding table is periodically being recomputed (every time there is an address change event in a DIF).

6. Creating the flows depicted in the figure

Now we will use rina-echo-time to setup a number of flows and check that no data is lost even when renumbering is performed so often as in this scenario. We can access the VMs individually using the access.sh script, but it is more convenient to automate the setup of rina-echo-time servers and clients via a script. This script leverages byobu to open a number of terminals in the same screen.

#!/bin/bash

SESSION=ARCFIRE-renumber

# -2: forces 256 colors, 
byobu-tmux -2 new-session -d -s $SESSION

byobu-tmux rename-window -t $SESSION:0 'RIGA and LISBON'
byobu-tmux split-window  -h
byobu-tmux select-pane -t 0
byobu-tmux send-keys "ssh root@92.168.1.2" C-m
byobu-tmux send-keys "cd /home/i2cat/edu/demonstrator" C-m
byobu-tmux send-keys "./access.sh riga" C-m
byobu-tmux send-keys "rina-echo-time -l --server-api 1" C-m

byobu-tmux select-pane -t 1
byobu-tmux send-keys "ssh root@192.168.1.2" C-m
byobu-tmux send-keys "cd /home/i2cat/edu/demonstrator" C-m
byobu-tmux send-keys "./access.sh lisbon" C-m
byobu-tmux send-keys "rina-echo-time --client-api 1 --server-api 1 -w 2 -c 100000" C-m

byobu-tmux new-window -t $SESSION:1 -n 'DUBLIN and ANKARA'
byobu-tmux split-window  -h
byobu-tmux select-pane -t 0
byobu-tmux send-keys "ssh root@192.168.1.2" C-m
byobu-tmux send-keys "cd /home/i2cat/edu/demonstrator" C-m
byobu-tmux send-keys "./access.sh dublin" C-m
byobu-tmux send-keys "rina-echo-time -l --server-api 2" C-m

byobu-tmux select-pane -t 1
byobu-tmux send-keys "ssh root@192.168.1.2" C-m
byobu-tmux send-keys "cd /home/i2cat/edu/demonstrator" C-m
byobu-tmux send-keys "./access.sh ankara" C-m
byobu-tmux send-keys "rina-echo-time --client-api 2 --server-api 2 -w 2 -c 100000" C-m

byobu-tmux new-window -t $SESSION:2 -n 'VALLETTA and OSLO'
byobu-tmux split-window  -h
byobu-tmux select-pane -t 0
byobu-tmux send-keys "ssh root@192.168.1.2" C-m
byobu-tmux send-keys "cd /home/i2cat/edu/demonstrator" C-m
byobu-tmux send-keys "./access.sh valleta" C-m
byobu-tmux send-keys "rina-echo-time -l --server-api 3" C-m

byobu-tmux select-pane -t 1
byobu-tmux send-keys "ssh root@192.168.1.2" C-m
byobu-tmux send-keys "cd /home/i2cat/edu/demonstrator" C-m
byobu-tmux send-keys "./access.sh oslo" C-m
byobu-tmux send-keys "rina-echo-time --client-api 3 --server-api 3 -w 2 -c 100000" C-m

byobu-tmux new-window -t $SESSION:3 -n 'BRUSSELS and NICOSIA'
byobu-tmux split-window  -h
byobu-tmux select-pane -t 0
byobu-tmux send-keys "ssh root@192.168.1.2" C-m
byobu-tmux send-keys "cd /home/i2cat/edu/demonstrator" C-m
byobu-tmux send-keys "./access.sh brussels" C-m
byobu-tmux send-keys "rina-echo-time -l --server-api 4" C-m

byobu-tmux select-pane -t 1
byobu-tmux send-keys "ssh root@192.168.1.2" C-m
byobu-tmux send-keys "cd /home/i2cat/edu/demonstrator" C-m
byobu-tmux send-keys "./access.sh nicosia" C-m
byobu-tmux send-keys "rina-echo-time --client-api 4 --server-api 4 -w 2 -c 100000" C-m

byobu-tmux select-window -t $SESSION:0
byobu-tmux -2 attach-session -t $SESSION

If everything goes well you should see a terminal splitted in two, with four tabs at the bottom. You can move from tab to tab by pressing 'F3'. Each tab shows a rina-echo-time server and a client sending the server an Echo request every 2 ms (each client will send 100000 Echo requests and then stop).

Screenshot of terminals configured by the script

7. Tearing down the scenario

To stop the VMs and destroy any virtual interfaces and software bridges create by up.sh, we just need to execute the down.sh script from the main demonstrator folder. If we also want to clean up all the config files generated for the scenario (to be able to generate files for other ones, for example), we just need to call the clean.sh script.

Clone this wiki locally