Hi Eduard,
Turns out I’m an idiot. I completely forgot to enroll the DIFs…
This is the result now:
root@multi1:/home/koen# rina-echo-time -c 100 -d kpnInternet.DIF
4740(1467799362)#librina.logs (DBG): New log level: INFO
4740(1467799362)#librina.nl-manager (INFO): Netlink socket connected to local
port 4740
Flow allocation time = 30.263 ms
SDU size = 20, seq = 0, RTT = 2.1318 ms
SDU size = 20, seq = 1, RTT = 1.5517 ms
SDU size = 20, seq = 2, RTT = 6.8258 ms
SDU size = 20, seq = 3, RTT = 1.578 ms
SDU size = 20, seq = 4, RTT = 20.289 ms
^C
root@multi1:/home/koen# rina-echo-time -c 100 -d ziggoInternet.DIF
4917(1467799371)#librina.logs (DBG): New log level: INFO
4917(1467799371)#librina.nl-manager (INFO): Netlink socket connected to local
port 4917
Flow allocation time = 12.541 ms
SDU size = 20, seq = 0, RTT = 7.1706 ms
SDU size = 20, seq = 1, RTT = 3.7255 ms
^C
Thanks for all the help! :-)
Cheers,
Koen
On 05 Jul 2016, at 19:35, Eduard Grasa Gras <eduard.grasa@xxxxxxxxx> wrote:
Now its a different problem, flow allocation failed. Could you attach the log
of the ipc process ?
Cheers,
Eduard
El 5/7/2016 17:28, "Koen Veelenturf" <koen.veelenturf@xxxxxx
<mailto:koen.veelenturf@xxxxxx>> escribió:
Dear Eduard,
I’m afraid that after recompiling the whole stack (pristine-1.5), it still
doesn’t work. Might it have something to do with the fact that in my
topology, in principle node 3 is also multi homed in a way?
On my node 1 I still get:
<node1client>
root@multi1:/home/koen# rina-echo-time -c 100 -d kpnInternet.DIF
2845(1467731596)#librina.logs (DBG): New log level: INFO
2845(1467731596)#librina.nl <http://librina.nl/>-manager (INFO): Netlink
socket connected to local port 2845
2845(1467731596)#rina-echo-time (ERR): Failed to allocate a flow
2845(1467731596)#rina-echo-time (ERR): Problems creating flow, exiting
</node1client>
<ipcm.log>
839(1467731596)#librina.nl <http://librina.nl/>-manager (DBG): NL msg RX.
Fam: 21; Opcode: 44_APP_ALLOC_FLOW_REQ; Sport: 2845; Dport: 1; Seqnum:
1467731597; Request; SIPCP: 0; DIPCP: 0
839(1467731596)#librina.core (DBG): Added event of type
0_FLOW_ALLOCATION_REQUESTED and sequence number 1467731597 to events queue
839(1467731596)#ipcm (DBG): Got event of type 0_FLOW_ALLOCATION_REQUESTED and
sequence number 1467731597
839(1467731596)#librina.nl <http://librina.nl/>-manager (DBG): NL msg TX.
Fam: 21; Opcode: 11_IPCM_ALLOC_FLOW_REQ; Sport: 1; Dport: 873; Seqnum: 15;
Request; SIPCP: 0; DIPCP: 5
839(1467731596)#ipcm.flow-alloc (INFO)[flow_allocation_requested_local]: IPC
process kpnInternet.1.IPCP:1:: requested to allocate flow between
rina.apps.echotime.client:1:: and rina.apps.echotime.server:1::
839(1467731596)#librina.nl <http://librina.nl/>-manager (DBG): NL msg RX.
Fam: 21; Opcode: 13_IPCM_ALLOC_FLOW_REQ_RES; Sport: 873; Dport: 1; Seqnum:
15; Response; SIPCP: 5; DIPCP: 0
839(1467731596)#librina.core (DBG): Added event of type
26_IPCM_ALLOCATE_FLOW_RESULT and sequence number 15 to events queue
839(1467731596)#ipcm (DBG): Got event of type 26_IPCM_ALLOCATE_FLOW_RESULT
and sequence number 15
839(1467731596)#ipcm.flow-alloc
(INFO)[ipcm_allocate_flow_request_result_handler]: Informing IPC process
kpnInternet.1.IPCP:1:: about flow allocation from application
rina.apps.echotime.client:1:: to application rina.apps.echotime.server:1:: in
DIF kpnInternet.DIF::: [success = 0, port-id = 1]
839(1467731596)#librina.ipc-manager (DBG): ApplicationManager::flowAllocated
called
839(1467731596)#librina.nl <http://librina.nl/>-manager (DBG): NL msg TX.
Fam: 21; Opcode: 45_APP_ALLOC_FLOW_REQ_RES; Sport: 1; Dport: 2845; Seqnum:
1467731597; Response; SIPCP: 0; DIPCP: 0
839(1467731596)#ipcm.flow-alloc
(INFO)[ipcm_allocate_flow_request_result_handler]: Applications
rina.apps.echotime.client:1:: and rina.apps.echotime.server:1:: informed
about flow allocation result
839(1467731598)#librina.nl <http://librina.nl/>-manager (DBG): NL msg RX.
Fam: 21; Opcode: 27_SOCK_CLOSED_NOT; Sport: 0; Dport: 1; Seqnum: 0;
Notification; SIPCP: 0; DIPCP: 0
839(1467731598)#librina.core (DBG): NL socket at port 2845 is closed
839(1467731598)#librina.core (DBG): Added event of type
22_OS_PROCESS_FINALIZED and sequence number 0 to events queue
839(1467731598)#ipcm (DBG): Got event of type 22_OS_PROCESS_FINALIZED and
sequence number 0
839(1467731598)#ipcm.app (INFO)[os_process_finalized_handler]: Application
rina.apps.echotime.client:1::terminated
</ipcm.log>
Cheers,
Koen
On 29 Jun 2016, at 10:02, Eduard Grasa Gras <eduard.grasa@xxxxxxxxx
<mailto:eduard.grasa@xxxxxxxxx>> wrote:
Hi Koen,
Works well for me, attached log in [1], let's see what is the output for
Vincenzo's tests. Could you try to rebuild librina, rinad and rina-tools and
try again? I recall we had this error a month ago or so when the librina API
was slightly updated, but the fix for rina-tools is already merged in
pristine-1.5.
Cheers,
Eduard
[1]
--- Server output (after a few tests) ----
root@e2-edu-vm3:/usr/local/irati/bin# ./rina-echo-time -l -d
"normal.DIF;vpn.DIF"
81055(1467186958)#librina.logs (DBG): New log level: INFO
81055(1467186958)#librina.nl <http://librina.nl/>-manager (INFO): Netlink
socket connected to local port 81055
81055(1467186958)#rina-echo-time (INFO): Application registered in DIF
normal.DIF
81055(1467186958)#rina-echo-time (INFO): Application registered in DIF
vpn.DIF
81055(1467186975)#rina-echo-app (INFO): New flow allocated [port-id = 2]
81055(1467186984)#rina-echo-app (INFO): Flow torn down remotely [port-id = 2]
81055(1467187019)#rina-echo-app (INFO): New flow allocated [port-id = 2]
81055(1467187022)#rina-echo-app (INFO): Flow torn down remotely [port-id = 2]
81055(1467187075)#rina-echo-app (INFO): New flow allocated [port-id = 2]
81055(1467187078)#rina-echo-app (INFO): Flow torn down remotely [port-id = 2]
81055(1467187092)#rina-echo-app (INFO): New flow allocated [port-id = 2]
81055(1467187191)#rina-echo-app (INFO): Flow torn down remotely [port-id = 2]
---- Client output (one test)----
root@e2-edu-vm2:/usr/local/irati/bin# ./rina-echo-time -c 100 -d "normal.DIF"
10962(1467194293)#librina.logs (DBG): New log level: INFO
10962(1467194293)#librina.nl <http://librina.nl/>-manager (INFO): Netlink
socket connected to local port 10962
Flow allocation time = 2.6873 ms
SDU size = 20, seq = 0, RTT = 0.20095 ms
SDU size = 20, seq = 1, RTT = 0.37911 ms
SDU size = 20, seq = 2, RTT = 0.30415 ms
SDU size = 20, seq = 3, RTT = 0.49273 ms
SDU size = 20, seq = 4, RTT = 0.34944 ms
SDU size = 20, seq = 5, RTT = 0.32797 ms
SDU size = 20, seq = 6, RTT = 0.45667 ms
SDU size = 20, seq = 7, RTT = 0.33276 ms
SDU size = 20, seq = 8, RTT = 0.33324 ms
SDU size = 20, seq = 9, RTT = 0.4748 ms
SDU size = 20, seq = 10, RTT = 0.34935 ms
SDU size = 20, seq = 11, RTT = 0.37401 ms
SDU size = 20, seq = 12, RTT = 0.39813 ms
SDU size = 20, seq = 13, RTT = 0.33543 ms
SDU size = 20, seq = 14, RTT = 0.33919 ms
SDU size = 20, seq = 15, RTT = 0.3594 ms
SDU size = 20, seq = 16, RTT = 0.35599 ms
SDU size = 20, seq = 17, RTT = 0.33916 ms
2016-06-28 19:45 GMT+02:00 Koen Veelenturf <koen.veelenturf@xxxxxx
<mailto:koen.veelenturf@xxxxxx>>:
Dear Eduard,
Thanks for your patch. Registration of the server is looking good. The
application gets registered to the two DIFs.
When trying to ping from my multi homed client, I get the following result:
<resultClient>
root@vm1:/home/koen# rina-echo-time -c 100 -d “providerA.DIF"
14645(1467135308)#librina.logs (DBG): New log level: INFO
14645(1467135308)#librina.nl <http://librina.nl/>-manager (INFO): Netlink
socket connected to local port 14645
Flow allocation time = 9.4695 ms
14645(1467135308)#rina-echo-time (WARN): Timeout waiting for reply, SDU
considered lost
14645(1467135308)#rina-echo-time (WARN): Timeout waiting for reply, SDU
considered lost
[…]
14645(1467135308)#rina-echo-time (WARN): Timeout waiting for reply, SDU
considered lost
14645(1467135308)#rina-echo-time (WARN): Timeout waiting for reply, SDU
considered lost
SDU size = 20, seq = 45, RTT = 0.47775 ms [bad response]
SDU size = 20, seq = 46, RTT = 0.12941 ms [bad response]
[…]
SDU size = 20, seq = 49, RTT = 0.13129 ms [bad response]
SDU size = 20, seq = 50, RTT = 0.12984 ms [bad response]
[…]
</resultClient>
These are the messages from the server point-of-view:
<resultServer>
root@vm5:/home/koen# rina-echo-time -l -d “providerA.DIF;providerB.DIF"
10021(1467135231)#librina.logs (DBG): New log level: INFO
10021(1467135231)#librina.nl <http://librina.nl/>-manager (INFO): Netlink
socket connected to local port 10021
10021(1467135231)#rina-echo-time (INFO): Application registered in DIF
providerA.DIF
10021(1467135231)#rina-echo-time (INFO): Application registered in DIF
providerB.DIF
10021(1467135235)#rina-echo-app (INFO): New flow allocated [port-id = 4]
</resultServer>
If I try to ping over the other DIF, I get the same result.
Am I doing something wrong or might there be a little issue with the
echo-client?
If you need more information I’m glad to be of help.
Cheers,
Koen
On 28 Jun 2016, at 18:25, Eduard Grasa Gras <eduard.grasa@xxxxxxxxx
<mailto:eduard.grasa@xxxxxxxxx>> wrote:
Ok,
I've issued a pull request, if you can test directly from my repo/branch it
will be great.
https://github.com/IRATI/stack/pull/967 ;
<https://github.com/IRATI/stack/pull/967>
Cheers,
Eduard
2016-06-28 10:32 GMT+02:00 Koen Veelenturf <koen.veelenturf@xxxxxx
<mailto:koen.veelenturf@xxxxxx>>:
Daar Eduard,
Thank you, I'd be able to test it tomorrow afternoon or on Thursday.
Cheers,
Koen Veelenturf
----- Bericht beantwoorden -----
Van: "Eduard Grasa Gras" <eduard.grasa@xxxxxxxxx
<mailto:eduard.grasa@xxxxxxxxx>>
Aan: <irati@xxxxxxxxxxxxx <mailto:irati@xxxxxxxxxxxxx>>
Onderwerp: [irati] Re: RINA and multihoming
Datum: di, jun. 28, 2016 10:28
Hi Koen,
I'll be providing a fix this morning, will you be able to test it?
Cheers,
Eduard
2016-06-24 10:47 GMT+02:00 Koen Veelenturf <koen.veelenturf@xxxxxx
<mailto:koen.veelenturf@xxxxxx>>:
Hi Vincenzo,
I’m gonna be very cheeky here.
Is it something you could program relatively quickly? I’m afraid that when
I have to do it myself, that I will screw it up many times… :)
Cheers,
Koen
On 24 Jun 2016, at 09:36, Vincenzo Maffione <v.maffione@xxxxxxxxx
<mailto:v.maffione@xxxxxxxxx>> wrote:
You have to do that, but you also have to do what is done in
rina-tools/src/common/application.cc <http://application.cc/> -->
Application::applicationRegister()
for the second DIF.
Cheers,
Vincenzo
2016-06-23 16:19 GMT+02:00 Koen Veelenturf <koen.veelenturf@xxxxxx
<mailto:koen.veelenturf@xxxxxx>>:
Dear Vincenzo,
Thanks for your reply.
Would that simply be adding another block of this but then with -D and
adding the variables in et_server.cc?
(main.cc <http://main.cc/> @ rina-echo-time)
TCLAP::ValueArg<string> dif_arg("d",
"dif-to-register-at",
"The name of the DIF to
register at (empty means 'any DIF')",
false,
"",
"string”);
Or do I need to change more?
I’m not a star in programming, so I need a little push in the right
direction. :)
Cheers,
Koen
On 23 Jun 2016, at 12:22, Vincenzo Maffione <v.maffione@xxxxxxxxx
<mailto:v.maffione@xxxxxxxxx>> wrote:
Hi Koen,
As Eduard suggests, you could simply modify the rina-echo-time
application to support an additional "-D" argument to specify a second
DIF to register to (in server mode).
Then in the code you should call the register_to_specific_dif() routine a
second time (to process the -D argument).
Even better, we could extend the implementation of the "-d" argument to
accept an arbitrary number of DIF names, an call
register_to_specific_dif() in a loop, so that the application gets
registered in all the specified DIFs. This would be a generalization of
(ii).
Cheers,
Vincenzo
2016-06-23 11:53 GMT+02:00 Koen Veelenturf <koen.veelenturf@xxxxxx
<mailto:koen.veelenturf@xxxxxx>>:
Dear Eduard,
Thanks you for your and your colleague’s answers.
It would be nice to have support for multiple registrations, but I’m not
sure how much coding that would require.
Could you give an indication how much work it would need? For my project
I’ve limited time, so if it takes weeks, then I’m afraid I will not have
the time to finish it before my deadlines.
Cheers,
Koen
On 23 Jun 2016, at 09:58, Eduard Grasa Gras <eduard.grasa@xxxxxxxxx
<mailto:eduard.grasa@xxxxxxxxx>> wrote:
Hi Koen,
The answer is yes and no. The implementation supports multiple
registrations, the problem is that our current applications don't
exploit this capability. The current rina-echo-time and rina-tgen
registration options are to i) register to 'any DIF' -> chosen by the
IPCM looking at da.map; or ii) to register in a single DIF specified by
the app. We could add this third option if it is needed (you could also
add it yourself if you wanted to contribute, we could show you what you
need to modify).
Cheers,
Eduard
2016-06-22 14:48 GMT+02:00 Koen Veelenturf <koen.veelenturf@xxxxxx
<mailto:koen.veelenturf@xxxxxx>>:
Hi Eduard,
Thanks for you quick reply.
I meant if it was possible to register an application (in this case the
rina.apps.echotime.server) to two DIFs at the same time, making the
server application reachable through two connections at the same time.
Cheers,
Koen
On 22 Jun 2016, at 14:45, Eduard Grasa Gras <eduard.grasa@xxxxxxxxx
<mailto:eduard.grasa@xxxxxxxxx>> wrote:
Hi Koen,
Answers inline!
2016-06-22 14:15 GMT+02:00 Koen Veelenturf <koen.veelenturf@xxxxxx
<mailto:koen.veelenturf@xxxxxx>>:
Dear Eduard,
I found that the Demonstrator automagically creates the mapping, but my
own VMs with the compiled stack didn’t. That solved my issue, thank you.
One question though, do I understand correctly that the mapping for
applications is done statically (for now)?
Yes, it is done statically for now, until there is a proper
implementation of the DIF allocator. The H2020 ARCFIRE project is going
to look at this issue (http://ict-arcfire.eu ;<http://ict-arcfire.eu/>).
Is it possible at this moment to make the applications reachable from
for instance two connections at the same time?
You mean make an application register to more than one DIF? Or allow
the same "server" application to have more than one "client" within the
same DIF?
Cheers,
Eduard
Cheers,
Koen
On 22 Jun 2016, at 13:20, Eduard Grasa Gras <eduard.grasa@xxxxxxxxx
<mailto:eduard.grasa@xxxxxxxxx>> wrote:
Dear Koen,
I think that you are just missing a little piece, the application to
DIF mappings. Since you have multiple DIFs to choose from, when the
client requests a flow to a destination application the IPCM needs to
know somehow which DIF to choose. In RINA the component that has this
information is the DIF allocator.
The DIF allocator is not really implemented in the stack, it is just
reduced to a configuration file with a static directory of destination
application name to DIF mappings. The file is located at <IRATI
installation path>/etc/da.map (must be called da.map). You can edit it
anytime, the IPCM will detect it and reload the mappings. Here is an
example:
{
"applicationToDIFMappings" : [ {
"encodedAppName" : "traffic.generator.server-1--",
"difName" : "vpn1.DIF"
}, {
"encodedAppName" : "server.ioq3-0--",
"difName" : "vpn1.DIF"
}, {
"encodedAppName" : "rina.apps.echotime.server-1--",
"difName" : "vpn1.DIF"
}, {
"encodedAppName" : "rina.apps.manager-1--",
"difName" : "NMS.DIF"
}]
}
So you just need to edit the file with the proper mappings. It works
both for flow allocation and application registration (in case the
application to be registered doesn't specify a DIF).
Cheers,
Eduard
2016-06-22 12:51 GMT+02:00 Koen Veelenturf <koen.veelenturf@xxxxxx
<mailto:koen.veelenturf@xxxxxx>>:
Dear all,
I’m currently doing a research project for my master on RINA and
multihoming.
I’ve been playing around with the IRATI demonstrator and also built by
own VMs with the IRATI stack.
I’ve built this network topology and created a couple of DIFs to
represent two different ISPs.
These are the DIFs I currently have:
- Node1 - Node4: “Provider A Access DIF”
- Node1 - Node2: “Provider B Access DIF”
- Node4 - Node3: “Provider A Regional DIF”
- Node2 - Node3: “Provider B Regional DIF”
- Node3 - Node5: “Upstream DIF”
And between Node1 and Node5 I’ve created DIFs for “Internet ProviderA
DIF” and “Internet ProviderB DIF” which spans over the corresponding
access and regional DIFs.
I was able to successfully enroll the DIFS using the IPCM console and
was able to run a RINA echo time server on node 5, while specifying
the DIF it should register on.
However, I was not able to run the client. I just the following
commands for server and client:
server: rina-echo-time -d providerAInternet.DIF -l
client: rina-echo-time -d providerAInternet.DIF -c 100
<mulithometopo-network-rep.png>
Running the client results in the following error message in the
ipcm.log file:
<logfile>
793(1466590549)#librina.nl <http://librina.nl/>-manager (DBG): NL msg
RX. Fam: 21; Opcode: 44_APP_ALLOC_FLOW_REQ; Sport: 8172; Dport: 1;
Seqnum: 1466590550; Request; SIPCP: 0; DIPCP: 0
793(1466590549)#librina.core (DBG): Added event of type
0_FLOW_ALLOCATION_REQUESTED and sequence number 1466590550 to events
queue
793(1466590549)#ipcm (DBG): Got event of type
0_FLOW_ALLOCATION_REQUESTED and sequence number 1466590550
793(1466590549)#ipcm.flow-alloc
(ERR)[flow_allocation_requested_local]: Error: Cannot find an IPC
process to serve flow allocation request (local-app =
rina.apps.echotime.client:1::, remote-app =
rina.apps.echotime.server:1::
793(1466590549)#librina.ipc-manager (DBG):
ApplicationManager::flowAllocated called
793(1466590549)#librina.nl <http://librina.nl/>-manager (DBG): NL msg
TX. Fam: 21; Opcode: 45_APP_ALLOC_FLOW_REQ_RES; Sport: 1; Dport: 8172;
Seqnum: 1466590550; Response; SIPCP: 0; DIPCP: 0
793(1466590549)#ipcm.flow-alloc
(INFO)[application_flow_allocation_failed_notify]: Flow allocation
between rina.apps.echotime.client:1:: and
rina.apps.echotime.server:1:: failed: applications informed
793(1466590551)#librina.nl <http://librina.nl/>-manager (DBG): NL msg
RX. Fam: 21; Opcode: 27_SOCK_CLOSED_NOT; Sport: 0; Dport: 1; Seqnum:
0; Notification; SIPCP: 0; DIPCP: 0
793(1466590551)#librina.core (DBG): NL socket at port 8172 is closed
793(1466590551)#librina.core (DBG): Added event of type
22_OS_PROCESS_FINALIZED and sequence number 0 to events queue
793(1466590551)#ipcm (DBG): Got event of type 22_OS_PROCESS_FINALIZED
and sequence number 0
793(1466590551)#ipcm.app (INFO)[os_process_finalized_handler]:
Application rina.apps.echotime.client:1::terminated
</logfile>
What I’m trying to do should in theory be possible right? Am I doing
something wrong or might there be a problem with the stack?
Please let me know if there’s more information needed.
Kind regards,
Koen Veelenturf
--
Vincenzo Maffione
--
Vincenzo Maffione
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail
