[nox-dev] NOX Zaku with OF 1.1 support (C++ only)

[Zoltán Lajos Kis]

Hi,

For those of you, who might be interested, I pushed a hacked version of Zaku 
with OF 1.1 support to: https://github.com/TrafficLab/nox11oflib. Basically 
NOX's OF handling has been replaced with oflib from the 1.1 soft switch 
implementation (https://github.com/TrafficLab/of11softswitch), plus a lot of 
stuff has been removed or changed to make it work.

It misses a lot of features available in Zaku, yet I believe this could be a 
good platform for anyone to start prototyping OF 1.1 ideas, until the 
"official" OF 1.1 support is ready.
If you would like to use this version and have any questions, found a bug, or 
would like to reimplement missing features, feel free to contact me.

Limitations:
- No python support
- Experimenter features (OFMP, SNAT, switch manager,... ) has been removed
- Almost all apps have been removed (discovery app is available; reimplemented 
in C++)
- oflib is in pure C, so sending/receiving OF messages involves structs and 
pointer arrays (yet this is not as inconvenient as it sounds)

Regards,
Zoltan.

___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev

Re: [nox-dev] NOX Zaku with OF 1.1 support (C++ only)

[Zoltán Lajos Kis]

Would that be the last patches here 
http://openvswitch.org/cgi-bin/gitweb.cgi?p=nox;a=shortlog;h=refs/heads/dev/destiny-fast
 ?



From: Martin Casado [mailto:cas...@nicira.com]
Sent: Wednesday, May 11, 2011 6:21 PM
To: Zoltán Lajos Kis
Cc: nox-dev@noxrepo.org
Subject: Re: [nox-dev] NOX Zaku with OF 1.1 support (C++ only)

This is great Zoltan, thanks.

Having a C++-only fork of Nox is long overdue.  There are many Nox developers 
who have expressed interest in this.  Off hand, I would suggest that we pull in 
Amin's changes (which makes Nox blazingly fast) and remove most spurious apps.

Hi,

For those of you, who might be interested, I pushed a hacked version of Zaku 
with OF 1.1 support to: https://github.com/TrafficLab/nox11oflib. Basically 
NOX's OF handling has been replaced with oflib from the 1.1 soft switch 
implementation (https://github.com/TrafficLab/of11softswitch), plus a lot of 
stuff has been removed or changed to make it work.

It misses a lot of features available in Zaku, yet I believe this could be a 
good platform for anyone to start prototyping OF 1.1 ideas, until the 
"official" OF 1.1 support is ready.
If you would like to use this version and have any questions, found a bug, or 
would like to reimplement missing features, feel free to contact me.

Limitations:
- No python support
- Experimenter features (OFMP, SNAT, switch manager,... ) has been removed
- Almost all apps have been removed (discovery app is available; reimplemented 
in C++)
- oflib is in pure C, so sending/receiving OF messages involves structs and 
pointer arrays (yet this is not as inconvenient as it sounds)

Regards,
Zoltan.



___
nox-dev mailing list
nox-dev@noxrepo.org<mailto:nox-dev@noxrepo.org>
http://noxrepo.org/mailman/listinfo/nox-dev




--
~~~
Martin Casado
Nicira Networks, Inc.
www.nicira.com<http://www.nicira.com> | 
www.openvswitch.org<http://www.openvswitch.org>
cell: 650-776-1457
~~~
___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev

Re: [nox-dev] Adding a new C component

[Zoltán Lajos Kis]

Hi,

you only need to "remake NOX" when you add a new component. Otherwise, if you 
modified the code of an already existing component, running make is enough.

Regards,
Zoltan.


From: nox-dev-boun...@noxrepo.org [nox-dev-boun...@noxrepo.org] On Behalf Of 
andrea simeoni [andreasimeon...@gmail.com]
Sent: Thursday, August 04, 2011 4:55 PM
To: nox-dev@noxrepo.org
Subject: [nox-dev] Adding a new C component

Hi guys,

I'm trying to install a new C++ component, and have the following question:

>  The routine described in 
> http://noxrepo.org/noxwiki/index.php/NOX_C/C%2B%2B_Tutorial_%28Counting_Pings%29
is only for adding a new component (as I hope), or i have to remake NOX 
each time i write some code?

THanks a lot, best regards


--
Andrea Simeoni
___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev

Re: [nox-dev] Adding a new C component

[Zoltán Lajos Kis]

Well... the usual way to build nox is to make a build directory, and build nox 
in it. So if you are following this way, you should
run configure and make from the build dir (as ../configure). If you are not 
following the way, you should. Also this might be a
"typo", but you also need to execute make after configure.




From: andrea simeoni [andreasimeon...@gmail.com]
Sent: Thursday, August 04, 2011 5:53 PM
To: Zoltán Lajos Kis
Cc: nox-dev@noxrepo.org
Subject: Re: [nox-dev] Adding a new C component

Hi Zoltan, thank you for answering,

you give me good news, but I want to explain you what happens:


I've created a new component 'countvoncount' with the following commands


cd nox/src/nox/netapps/
nox-new-c-app.py countvoncount

at this point i launch the following (in the my nox root directory)

./boot.sh
./configure.sh

however even if such commands end without errors, when launching the component 
I get that
no component description was found.

Do you have any suggestions?

Maybe the configure.sh should be launched into the build directory?
I tried it too, but get an error telling me that NOX is already configured

can you help me?



2011/8/4 Zoltán Lajos Kis 
mailto:zoltan.lajos@ericsson.com>>
Hi,

you only need to "remake NOX" when you add a new component. Otherwise, if you 
modified the code of an already existing component, running make is enough.

Regards,
Zoltan.


From: nox-dev-boun...@noxrepo.org<mailto:nox-dev-boun...@noxrepo.org> 
[nox-dev-boun...@noxrepo.org<mailto:nox-dev-boun...@noxrepo.org>] On Behalf Of 
andrea simeoni [andreasimeon...@gmail.com<mailto:andreasimeon...@gmail.com>]
Sent: Thursday, August 04, 2011 4:55 PM
To: nox-dev@noxrepo.org<mailto:nox-dev@noxrepo.org>
Subject: [nox-dev] Adding a new C component

Hi guys,

I'm trying to install a new C++ component, and have the following question:

>  The routine described in 
> http://noxrepo.org/noxwiki/index.php/NOX_C/C%2B%2B_Tutorial_%28Counting_Pings%29
   is only for adding a new component (as I hope), or i have to remake NOX each 
time i write some code?

THanks a lot, best regards


--
Andrea Simeoni



--
Andrea Simeoni
___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev

Re: [nox-dev] Compare actions?

[Zoltán Lajos Kis]

It is certainly possible to write program code that does this.
The quickest is probably to compare the types, and if they
equal, memcmp the structs.


> -Original Message-
> From: nox-dev-boun...@noxrepo.org 
> [mailto:nox-dev-boun...@noxrepo.org] On Behalf Of Masoud 
> Moshref Javadi
> Sent: Wednesday, August 10, 2011 3:10 AM
> To: nox-dev@noxrepo.org
> Subject: [nox-dev] Compare actions?
> 
> Is there any way to compare two actions to see if they are 
> the same type and have the same parameters?
> ___
> nox-dev mailing list
> nox-dev@noxrepo.org
> http://noxrepo.org/mailman/listinfo/nox-dev
> 
___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev

[nox-dev] Cooperative threading vs. blocking send

[Zoltán Lajos Kis]

Hi,

In my C++ NOX (Zaku) app I would like to make sure that a flow is installed on 
the switch. Having no better solution, I send a barrier request right after the 
flow_mod, and then wait for either an error, or a barrier reply.
For this I register the flow_mod's and barrier's xids, and then compare 
incoming events against those. See the pseudoish code below for an example.

Could someone familiar with the cooperative thread implementation in NOX tell 
me, whether it is possible that a blocking send_openflow_command() result in 
the current thread actually blocking and yielding to another one?
Particularly in this code, can it happen that sending the flow_mod completes, 
but then the second call to send blocks, yielding to another thread. Then on 
this other thread the incoming error message is received and dispatched to the 
handler method? Resulting in the error being discarded as at that time the 
PendingFlow was not even registered...

And if so, is there a way to temporarily disable this yielding, or do I better 
start making the code more complex?

Thank you,
Zoltan.


--


struct PendingFlow {
  uint32_t modXid;
  uint32_t barrierXid;
  ...
}

class Example {

  PendingFlow *pendingFlow;
  ...

  void
  Example::install_flow(ofp_flow_mod *mod) {
 ofp_header *barrier = make_barrier();

mod->header->xid = generate_xid();
barrier->xid = generate_xid();

send_openflow_command(pi.datapath_id, &mod->header, true);
send_openflow_command(pi.datapath_id, barrier, true);

pendingFlow = new PendingFlow(mod->header->xid, barrier->xid);
...
  }


  Disposition
  Example::handleError(const Event &e) {
const Error_event& err = assert_cast(e);

if (pendingFlow != NULL && pendingFlow.modXid == getErrorXid(err)) {
  delete pendingFlow; pendingFlow = NULL;
  // Process error
}
   ...
return CONTINUE;
  }

  Disposition
  Example::handleBarrier(const Event &e) {
const Barrier_reply_event& barrier = assert_cast(e);

if (pendingFlow != NULL && pendingFlow.barrierXid == 
getBarrierXid(barrier)) {
  delete pendingFlow; pendingFlow = NULL;
  // Process completion
}
..
return CONTINUE;
  }

  ...
}

___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev

Re: [nox-dev] Cooperative threading vs. blocking send

[Zoltán Lajos Kis]

I could do that, but it probably gets me into the territory of volatiles - and 
perhaps locks:

...
pendingFlow = new PendingFlow(mod->header->xid, barrier->xid);
send_openflow_command(datapath_id, &mod->header, true);
if (pendingFlow != NULL) {
send_openflow_command(datapath_id, barrier, true);
}
...

Anyway, thanks for the confirmation.

Regards,
Zoltan.



From: Murphy McCauley [mailto:jam...@nau.edu]
Sent: Monday, September 12, 2011 8:42 PM
To: Zoltán Lajos Kis
Cc: nox-dev@noxrepo.org
Subject: Re: [nox-dev] Cooperative threading vs. blocking send

I'd have to look into it to be sure, but I think the scenario you describe may 
well be possible.

However... couldn't you just put the creation/registration of the PendingFlow 
*before* sending either of the commands?

-- Murphy

On Sep 12, 2011, at 7:10 AM, Zoltán Lajos Kis wrote:

Hi,

In my C++ NOX (Zaku) app I would like to make sure that a flow is installed on 
the switch. Having no better solution, I send a barrier request right after the 
flow_mod, and then wait for either an error, or a barrier reply.
For this I register the flow_mod's and barrier's xids, and then compare 
incoming events against those. See the pseudoish code below for an example.

Could someone familiar with the cooperative thread implementation in NOX tell 
me, whether it is possible that a blocking send_openflow_command() result in 
the current thread actually blocking and yielding to another one?
Particularly in this code, can it happen that sending the flow_mod completes, 
but then the second call to send blocks, yielding to another thread. Then on 
this other thread the incoming error message is received and dispatched to the 
handler method? Resulting in the error being discarded as at that time the 
PendingFlow was not even registered...

And if so, is there a way to temporarily disable this yielding, or do I better 
start making the code more complex?

Thank you,
Zoltan.


--


struct PendingFlow {
  uint32_t modXid;
  uint32_t barrierXid;
  ...
}

class Example {

  PendingFlow *pendingFlow;
  ...

  void
  Example::install_flow(ofp_flow_mod *mod) {
 ofp_header *barrier = make_barrier();

mod->header->xid = generate_xid();
barrier->xid = generate_xid();

send_openflow_command(pi.datapath_id, &mod->header, true);
send_openflow_command(pi.datapath_id, barrier, true);

pendingFlow = new PendingFlow(mod->header->xid, barrier->xid);
...
  }


  Disposition
  Example::handleError(const Event &e) {
const Error_event& err = assert_cast(e);

if (pendingFlow != NULL && pendingFlow.modXid == getErrorXid(err)) {
  delete pendingFlow; pendingFlow = NULL;
  // Process error
}
   ...
return CONTINUE;
  }

  Disposition
  Example::handleBarrier(const Event &e) {
const Barrier_reply_event& barrier = assert_cast(e);

if (pendingFlow != NULL && pendingFlow.barrierXid == 
getBarrierXid(barrier)) {
  delete pendingFlow; pendingFlow = NULL;
  // Process completion
}
..
return CONTINUE;
  }

  ...
}

___
nox-dev mailing list
nox-dev@noxrepo.org<mailto:nox-dev@noxrepo.org>
http://noxrepo.org/mailman/listinfo/nox-dev

___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev

Re: [nox-dev] Cooperative threading vs. blocking send

[Zoltán Lajos Kis]

Well, I wasn't being over pedantic. In fact I'm setting up MPLS LSPs, which 
involves sending a number of flow entries to different switches. In this case I 
don't want to blindly install flows, as if one of them fails I would have to 
explicitly remove the successful ones (with yet another flow_mods :).

Regards,
Zoltan.


From: Murphy McCauley [mailto:jam...@nau.edu]
Sent: Tuesday, September 13, 2011 7:58 AM
To: Zoltán Lajos Kis
Cc: nox-dev@noxrepo.org
Subject: Re: [nox-dev] Cooperative threading vs. blocking send

I'd just send both commands regardless and only ever look at pendingFlow again 
in the barrier and error handlers.  I think that sidesteps the need to worry 
about synchronization.

At any rate, good luck. :)

-- Murphy

On Sep 12, 2011, at 10:44 PM, Zoltán Lajos Kis wrote:

I could do that, but it probably gets me into the territory of volatiles - and 
perhaps locks:

...
pendingFlow = new PendingFlow(mod->header->xid, barrier->xid);
send_openflow_command(datapath_id, &mod->header, true);
if (pendingFlow != NULL) {
send_openflow_command(datapath_id, barrier, true);
}
...

Anyway, thanks for the confirmation.

Regards,
Zoltan.



From: Murphy McCauley [mailto:jam...@nau.edu]
Sent: Monday, September 12, 2011 8:42 PM
To: Zoltán Lajos Kis
Cc: nox-dev@noxrepo.org<mailto:nox-dev@noxrepo.org>
Subject: Re: [nox-dev] Cooperative threading vs. blocking send

I'd have to look into it to be sure, but I think the scenario you describe may 
well be possible.

However... couldn't you just put the creation/registration of the PendingFlow 
*before* sending either of the commands?

-- Murphy

On Sep 12, 2011, at 7:10 AM, Zoltán Lajos Kis wrote:

Hi,

In my C++ NOX (Zaku) app I would like to make sure that a flow is installed on 
the switch. Having no better solution, I send a barrier request right after the 
flow_mod, and then wait for either an error, or a barrier reply.
For this I register the flow_mod's and barrier's xids, and then compare 
incoming events against those. See the pseudoish code below for an example.

Could someone familiar with the cooperative thread implementation in NOX tell 
me, whether it is possible that a blocking send_openflow_command() result in 
the current thread actually blocking and yielding to another one?
Particularly in this code, can it happen that sending the flow_mod completes, 
but then the second call to send blocks, yielding to another thread. Then on 
this other thread the incoming error message is received and dispatched to the 
handler method? Resulting in the error being discarded as at that time the 
PendingFlow was not even registered...

And if so, is there a way to temporarily disable this yielding, or do I better 
start making the code more complex?

Thank you,
Zoltan.


--


struct PendingFlow {
  uint32_t modXid;
  uint32_t barrierXid;
  ...
}

class Example {

  PendingFlow *pendingFlow;
  ...

  void
  Example::install_flow(ofp_flow_mod *mod) {
 ofp_header *barrier = make_barrier();

mod->header->xid = generate_xid();
barrier->xid = generate_xid();

send_openflow_command(pi.datapath_id, &mod->header, true);
send_openflow_command(pi.datapath_id, barrier, true);

pendingFlow = new PendingFlow(mod->header->xid, barrier->xid);
...
  }


  Disposition
  Example::handleError(const Event &e) {
const Error_event& err = assert_cast(e);

if (pendingFlow != NULL && pendingFlow.modXid == getErrorXid(err)) {
  delete pendingFlow; pendingFlow = NULL;
  // Process error
}
   ...
return CONTINUE;
  }

  Disposition
  Example::handleBarrier(const Event &e) {
const Barrier_reply_event& barrier = assert_cast(e);

if (pendingFlow != NULL && pendingFlow.barrierXid == 
getBarrierXid(barrier)) {
  delete pendingFlow; pendingFlow = NULL;
  // Process completion
}
..
return CONTINUE;
  }

  ...
}

___
nox-dev mailing list
nox-dev@noxrepo.org<mailto:nox-dev@noxrepo.org>
http://noxrepo.org/mailman/listinfo/nox-dev


___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev

Re: [nox-dev] A question about network.graph.hh

[Zoltán Lajos Kis]

Guess: the hash code from the .cc file?

http://noxrepo.org/cgi-bin/gitweb.cgi?p=nox;a=blob;f=src/lib/network_graph.cc;h=356a7f7dff66f5658a8cd7c7456dc7cceb0deac1;hb=zaku

Regards,
Zoltan.



From: nox-dev-boun...@noxrepo.org [mailto:nox-dev-boun...@noxrepo.org] On 
Behalf Of andrea simeoni
Sent: Thursday, October 06, 2011 2:28 PM
To: nox-dev@noxrepo.org
Subject: [nox-dev] A question about network.graph.hh

Hi guys,

I'm using the "hop" struct defined in the file "network-graph.hh".  I was able 
to navigate the structure, and I've well understood its recursive nature.
But I have a question: for what stands the uint64_t field in the
std::list > next_hops ?

Thank you

--
Andrea Simeoni
___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev

Re: [nox-dev] Error building dev/destiny-fast branch

[Zoltán Lajos Kis]

Seems like someone checked in a conflict marker to that file:

http://noxrepo.org/cgi-bin/gitweb.cgi?p=nox;a=blob;f=src/nox/coreapps/pyrt/context.i;h=cb8641d72feb3a1f0543e97830a2addd55d502b9;hb=dev/destiny-fast#l83

Z.


From: nox-dev-boun...@noxrepo.org [nox-dev-boun...@noxrepo.org] On Behalf Of 
Andreas Voellmy [andreas.voel...@gmail.com]
Sent: Wednesday, October 26, 2011 4:40 AM
To: nox-dev@noxrepo.org
Subject: [nox-dev] Error building dev/destiny-fast branch

Hi,

I'd like to try the destiny-fast branch (I saw it mentioned here: 
http://www.openflow.org/wk/index.php/Controller_Performance_Comparisons), so I 
did the following

git clone git://noxrepo.org/nox
cd nox
git checkout dev/destiny-fast

Is that the right way to get this branch? After that I ran
./boot.sh
mkdir build
cd build
../configure
make

and got the following error:

Making all in pyrt
make[8]: Entering directory 
`/home/av/Download/nox-destiny/nox/build/src/nox/coreapps/pyrt'
/usr/bin/swig -c++ -python  -DSWIGWORDSIZE64 
-I../../../../../src/include/openflow -I../../../../../src/nox/lib/ -outdir ./. 
-o oxidereactor_wrap.cc -module oxidereactor 
../../../../../src/nox/coreapps/pyrt/oxidereactor.i
/usr/bin/swig -c++ -python  -DSWIGWORDSIZE64 -outdir ./. -o 
deferredcallback_wrap.cc -module deferredcallback 
../../../../../src/nox/coreapps/pyrt/deferredcallback.i
/usr/bin/swig -c++ -python  -DSWIGWORDSIZE64 
-I../../../../../src/include/openflow -I../../../../../src/nox/lib/ -outdir ./. 
-o pycomponent_wrap.cc -module pycomponent 
../../../../../src/nox/coreapps/pyrt/component.i
../../../../../src/nox/coreapps/pyrt/context.i:79: Error: Syntax error in 
input(3).
make[8]: *** [pycomponent.py] Error 1

Does anyone know what went wrong and how to fix this?

Thanks,
Andreas

___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev

Re: [nox-dev] MPLS or IP_proto fields

[Zoltán Lajos Kis]

Hi,

You can match on MPLS labels natively using OpenFlow 1.1. If you stick to 
OpenFlow 1.0, you will have to use a workaround, such as the L4 ports; however 
I think using (one or two) VLAN tags, or even Ethernet addresses for this would 
be a cleaner solution (depending on your scenario).

Regards,
Zoltan.

> -Original Message-
> From: nox-dev-boun...@noxrepo.org 
> [mailto:nox-dev-boun...@noxrepo.org] On Behalf Of Giorgio Mazza
> Sent: Monday, November 28, 2011 10:09 AM
> To: 
> Subject: [nox-dev] MPLS or IP_proto fields
> 
> Hi all,
> I want to write a component that instructs the switch to 
> separate traffic based on a tag I generate packets with.
> In particular I am going to insert a MPLS tag or a new IP 
> protocol type, exploiting L4 ports as tag.
> I wanted to know if it's possible to insert a flow entry that 
> differentiate flows thanks to the MPLS tag (I know I can 
> push/pop tags, but for the moment, I only need to distinguish 
> packets based on that field).
> If that is not possible, can I use the L4 ports to 
> differentiate packets even if I use a protocol type that is 
> not TCP neither UDP?
> Thanks a lot,
> 
> Giorgio
> ___
> nox-dev mailing list
> nox-dev@noxrepo.org
> http://noxrepo.org/mailman/listinfo/nox-dev
> 
___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev

Re: [nox-dev] Linkdown Event

[Zoltán Lajos Kis]

Hi,
I think that should be an OFPT_PORT_STATUS message, with reason=OFPPR_MODIFY, 
and the attached ofp_phy_port (OF 1.0) or of_port (OF 1.1) structure would have 
the OFPPS_LINK_DOWN status flag set.

Z.


From: nox-dev-boun...@noxrepo.org [mailto:nox-dev-boun...@noxrepo.org] On 
Behalf Of Harshil Anil Kumar Shah
Sent: Thursday, December 01, 2011 11:13 AM
To: nox-dev@noxrepo.org
Subject: [nox-dev] Linkdown Event

Hi,
If physical link is down (i.e. Cable is removed), what event is generated by 
openflow. Is it the same as PORT_DOWN event?

Thanks in advance.

Regards,
Harshil Shah,
Convergence Lab, Infosys Labs
Infosys | Bangalore
Mob # : +91 97428 87966.


 CAUTION - Disclaimer *
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely
for the use of the addressee(s). If you are not the intended recipient, please
notify the sender by e-mail and delete the original message. Further, you are 
not
to copy, disclose, or distribute this e-mail or its contents to any other 
person and
any such actions are unlawful. This e-mail may contain viruses. Infosys has 
taken
every reasonable precaution to minimize this risk, but is not liable for any 
damage
you may sustain as a result of any virus in this e-mail. You should carry out 
your
own virus checks before opening the e-mail or attachment. Infosys reserves the
right to monitor and review the content of all messages sent to or from this 
e-mail
address. Messages sent to or from this e-mail address may be stored on the
Infosys e-mail system.
***INFOSYS End of Disclaimer INFOSYS***

___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev

Re: [nox-dev] Linkdown Event

[Zoltán Lajos Kis]

Given that this is a status flag, presumably the presence of it means the link 
is down, and the absence of it means the link is up.

Z.


From: Harshil Anil Kumar Shah [mailto:harshil_s...@infosys.com]
Sent: Friday, December 02, 2011 5:37 AM
To: Zoltán Lajos Kis; nox-dev@noxrepo.org
Subject: RE: Linkdown Event

Thanks Zoltan for a quick reply.

One more thing I wanted to ask is:
If I connect cable again . So is the same message going with OFPAT_PORT_STATUS 
with ofp_phy_port with different flag value.
Because I checked in openflow.h, there is flag for Down event: OFPPS_LINK_DOWN 
but for Up event, there is no such flag.


From: Zoltán Lajos Kis [mailto:zoltan.lajos@ericsson.com]
Sent: Thursday, December 01, 2011 3:48 PM
To: Harshil Anil Kumar Shah; nox-dev@noxrepo.org
Subject: RE: Linkdown Event

Hi,
I think that should be an OFPT_PORT_STATUS message, with reason=OFPPR_MODIFY, 
and the attached ofp_phy_port (OF 1.0) or of_port (OF 1.1) structure would have 
the OFPPS_LINK_DOWN status flag set.

Z.


From: nox-dev-boun...@noxrepo.org [mailto:nox-dev-boun...@noxrepo.org] On 
Behalf Of Harshil Anil Kumar Shah
Sent: Thursday, December 01, 2011 11:13 AM
To: nox-dev@noxrepo.org
Subject: [nox-dev] Linkdown Event
Hi,
If physical link is down (i.e. Cable is removed), what event is generated by 
openflow. Is it the same as PORT_DOWN event?

Thanks in advance.

Regards,
Harshil Shah,
Convergence Lab, Infosys Labs
Infosys | Bangalore
Mob # : +91 97428 87966.


 CAUTION - Disclaimer *

This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely

for the use of the addressee(s). If you are not the intended recipient, please

notify the sender by e-mail and delete the original message. Further, you are 
not

to copy, disclose, or distribute this e-mail or its contents to any other 
person and

any such actions are unlawful. This e-mail may contain viruses. Infosys has 
taken

every reasonable precaution to minimize this risk, but is not liable for any 
damage

you may sustain as a result of any virus in this e-mail. You should carry out 
your

own virus checks before opening the e-mail or attachment. Infosys reserves the

right to monitor and review the content of all messages sent to or from this 
e-mail

address. Messages sent to or from this e-mail address may be stored on the

Infosys e-mail system.

***INFOSYS End of Disclaimer INFOSYS***


___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev

Re: [nox-dev] features-reply without features-request

[Zoltán Lajos Kis]

Hi Cayle,

The below part of the NOX code should take care of features reply messages 
during the handshake. If you don't get the warning message, the reply was not 
unexpected.
http://noxrepo.org/cgi-bin/gitweb.cgi?p=nox;a=blob;f=src/builtin/nox.cc;hb=HEAD#l1116

It is usual that the initial hello and feature request from the controller are 
sent in the same TCP segment - as Murhpy suggested. You can confirm this by at 
least checking the length of the segment identified as the controller's hello 
(8 bytes vs 16 bytes).

Regards,
Zoltan.




From: nox-dev-boun...@noxrepo.org [nox-dev-boun...@noxrepo.org] On Behalf Of 
Murphy McCauley [jam...@nau.edu]
Sent: Wednesday, January 11, 2012 9:59 PM
To: Cayle Spandon
Cc: nox-dev@noxrepo.org
Subject: Re: [nox-dev] features-reply without features-request

I can't speak as to the particulars of the reference switch (you might try one 
of the OpenFlow mailing lists).

However, the spec does state that part of the handshake sequence is that the 
controller sends a features request when a connection is established.  I don't 
see this in your sequences of messages below.  NOX should do this.  Are you 
using NOX?  If so, is it possible you missed this message (remember that 
multiple OpenFlow messages can be in the same packet, so it is possible it's in 
packet #4 along with the HELLO or something -- you'll have to look at the 
detail view of the packet, not just the summary line)?

If the message really isn't there, I suppose it's possible that ofprotocol does 
this proactively, but in this case I believe your controller is out of spec.

-- Murphy

On Jan 11, 2012, at 6:00 AM, Cayle Spandon wrote:

> Are OpenFlow controllers expected to process unsolicited feature-reply 
> messages?
>
> I am running the following setup:
>
> controller - ofprotocol - ofdatapath
>
> Using wireshark I see the following sequence of messages:
>
> #1 ofprotocol -> ofdatapath : hello
> #2 ofprotocol -> controller : hello
> #3 ofdatapath -> ofprotocol : hello
> #4 controller -> ofprotocol : hello
> #5 ofprotocol -> ofdatapath : features-request
> #6 ofdatapath -> ofprotocol : features-reply
> #7 ofprotocol -> controller : features-reply
>
> This means that the controller gets a features-reply even though it
> never sent a features-request.
>
> It appears that ofprotocol originates the features-request to the
> switch (which is somewhat surprising because I thought it was supposed
> to be a dumb pass-through) and the forwards the features-reply to the
> controller.
> ___
> nox-dev mailing list
> nox-dev@noxrepo.org
> http://noxrepo.org/mailman/listinfo/nox-dev

___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev
___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev

Re: [nox-dev] error with try to ./configure

[Zoltán Lajos Kis]

Hi,

config/ax_ssl.m4 checks if you have an "ssl" library and if there is an 
MD5_Init() function exported from there.

One reason for the error could be is that you do not have the ssl installed. To 
solve that you need to install the libssl-dev library if I remember correctly.
apt-get install libssl-dev   # or the equivalent on your system.

If that did not help, then another reason I ran into is that on some systems 
the MD5_Init() function is exported from the "crypto" library.
For this you can fix the ax_ssl.m4 to also try loading crypto, by applying the 
following patch:

 AC_CHECK_LIB(ssl, MD5_Init,
- [SSL_LIBS="-lssl"; AC_SUBST(SSL_LIBS) break],
- [AC_ERROR([openssl/md5.h not found. NOX requires OpenSSL])])
+ [SSL_LIBS="-lssl"; AC_SUBST(SSL_LIBS) break],[
+ AC_CHECK_LIB(crypto, MD5_Init,
+ [SSL_LIBS="-lssl -lcrypto"; AC_SUBST(SSL_LIBS) break],
+ [AC_ERROR([MD5_Init() is not linkable. NOX requires OpenSSL])])])


Regards,
Zoltan.


From: nox-dev-boun...@noxrepo.org [nox-dev-boun...@noxrepo.org] On Behalf Of 
aurisabel fereira [aurisab...@hotmail.com]
Sent: Thursday, January 12, 2012 10:03 PM
To: nox-dev@noxrepo.org
Subject: [nox-dev] error with try to ./configure

Hi

I get this message when I execute  ./configure

"configure: error: openssl/md5.h not found. NOX requires OpenSSL"

Any idea what this error could be?

Thanks

Aurisabel
___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev

Re: [nox-dev] features-reply without features-request

[Zoltán Lajos Kis]

Hi,

The ofprotocol in the reference switch is more than just a relayer process. If 
I remember correctly it
also deals with in-band control and port status handling. For this latter 
feature it needs to know
what ports were assigned to the datapath, and might use a feature request of 
its own.

Regards,
Zoltan.

> -Original Message-
> From: nox-dev-boun...@noxrepo.org 
> [mailto:nox-dev-boun...@noxrepo.org] On Behalf Of Cayle Spandon
> Sent: Friday, January 13, 2012 1:36 PM
> To: Murphy McCauley
> Cc: nox-dev@noxrepo.org
> Subject: Re: [nox-dev] features-reply without features-request
> 
> Hi Murphy,
> 
> Thanks for the reply.
> 
> No, I am not using NOX (Yes indeed - I should have gone to 
> the OpenFlow mailing list. I will.).
> 
> This is a new controller which is still under development. I 
> am sure the controller does not send a features-request 
> (because that part has not been coded yet). So, yes, the 
> controller is "out of spec" for now.
> 
> So I am sure that the features request comes from 
> "ifprotocol" (which is not a controller, as far as I know). 
> It appears to send it "proactively" as you say, and this is 
> exactly what seemed surprising (and frankly incorrect) to me.
> 
> Also, I am using the OpenFlow dissector in wireshark, so I 
> quite sure that the list of packets is accurate in the 
> summary below (i.e. I did not miss packets because there 
> multiple OpenFlow packets in a single TCP packet).
> 
> On Wed, Jan 11, 2012 at 3:59 PM, Murphy McCauley 
>  wrote:
> > I can't speak as to the particulars of the reference switch 
> (you might try one of the OpenFlow mailing lists).
> >
> > However, the spec does state that part of the handshake 
> sequence is that the controller sends a features request when 
> a connection is established.  I don't see this in your 
> sequences of messages below.  NOX should do this.  Are you 
> using NOX?  If so, is it possible you missed this message 
> (remember that multiple OpenFlow messages can be in the same 
> packet, so it is possible it's in packet #4 along with the 
> HELLO or something -- you'll have to look at the detail view 
> of the packet, not just the summary line)?
> >
> > If the message really isn't there, I suppose it's possible 
> that ofprotocol does this proactively, but in this case I 
> believe your controller is out of spec.
> >
> > -- Murphy
> >
> > On Jan 11, 2012, at 6:00 AM, Cayle Spandon wrote:
> >
> >> Are OpenFlow controllers expected to process unsolicited 
> feature-reply messages?
> >>
> >> I am running the following setup:
> >>
> >> controller - ofprotocol - ofdatapath
> >>
> >> Using wireshark I see the following sequence of messages:
> >>
> >> #1 ofprotocol -> ofdatapath : hello
> >> #2 ofprotocol -> controller : hello
> >> #3 ofdatapath -> ofprotocol : hello
> >> #4 controller -> ofprotocol : hello
> >> #5 ofprotocol -> ofdatapath : features-request
> >> #6 ofdatapath -> ofprotocol : features-reply
> >> #7 ofprotocol -> controller : features-reply
> >>
> >> This means that the controller gets a features-reply even 
> though it 
> >> never sent a features-request.
> >>
> >> It appears that ofprotocol originates the features-request to the 
> >> switch (which is somewhat surprising because I thought it was 
> >> supposed to be a dumb pass-through) and the forwards the 
> >> features-reply to the controller.
> >> ___
> >> nox-dev mailing list
> >> nox-dev@noxrepo.org
> >> http://noxrepo.org/mailman/listinfo/nox-dev
> >
> ___
> nox-dev mailing list
> nox-dev@noxrepo.org
> http://noxrepo.org/mailman/listinfo/nox-dev
> 
___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev