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

[Murphy McCauley]

I was responding earlier from my phone, so I didn't look at this as closely as 
I might have.  Sorry.  However, my initial suggestion -- to use the destiny 
branch -- still stands.  "git checkout destiny" (if you're using a recent 
version of git).

But this really looks like you just don't have the SSL development stuff 
installed.  I think the package is probably openssl-devel.  Do you have that 
installed, or just the plain openssl package?

-- Murphy

On Jan 12, 2012, at 1:03 PM, aurisabel fereira wrote:

> 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

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

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

[aurisabel fereira]

Thanks Zoltan,

I did it, but doesn't work.

Aurisabel

> From: zoltan.lajos@ericsson.com
> To: aurisab...@hotmail.com; nox-dev@noxrepo.org
> Date: Thu, 12 Jan 2012 22:26:49 +0100
> Subject: RE: [nox-dev] error with try to ./configure
> 
> 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] error with try to ./configure

[James McCauley]

Are you using the destiny branch?

-- Murphy
On Jan 12, 2012 1:03 PM, "aurisabel fereira"  wrote:

>  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
>
>
___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev

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

[aurisabel fereira]

I am working for fedora 16. I installed openssl and doesn't work.

Thanks

Aurisabel

Date: Thu, 12 Jan 2012 16:25:32 -0500
Subject: Re: [nox-dev] error with try to ./configure
From: aro...@clemson.edu
To: aurisab...@hotmail.com
CC: nox-dev@noxrepo.org

Probably need to install openssl. 
http://noxrepo.org/noxwiki/index.php/NOX_Installation#Dependencies
Aaron

On Thu, Jan 12, 2012 at 4:03 PM, aurisabel fereira  
wrote:





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




-- 
Aaron O. Rosen
Masters Student - Network Communication
306B Fluor Daniel



  ___
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] error with try to ./configure

[Aaron Rosen]

Probably need to install openssl.

http://noxrepo.org/noxwiki/index.php/NOX_Installation#Dependencies

Aaron

On Thu, Jan 12, 2012 at 4:03 PM, aurisabel fereira
wrote:

>  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
>
>


-- 
Aaron O. Rosen
Masters Student - Network Communication
306B Fluor Daniel
___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev

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

[aurisabel fereira]

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] Topology component and FlowVisor.

[Sergio Jiménez Feijóo]

Hi Murphy,

It worked. Now I can see the topology module working like a charm. I 
still have to fix some issues (surely related to the fact that I have to 
set up the flow-mods with the proper VLAN tag to forward the packets).


I would like to thank all of you guys for your help.

El 12/01/2012 19:12, Murphy McCauley escribió:

There have been some changes to logging.  Use -v -v.

-- Murphy

On Jan 12, 2012, at 10:10 AM, Sergio Jiménez Feijóo wrote:


Hi Aaron,

I have moved to the destiny branch and compiled everything again. The 
topology component seems to work fine (I can see "new link detected" 
messages in the log) but now I can't see the log messages of my 
application (VLOG_DBG function) despite I'm running NOX with the -v 
flag. My application isn't working properly yet but until I can see 
those log messages I won't be able to find the cause of the new problem.


In response to Ali: I Have tested my application in another testbed 
without flowvisor but I can't run it in this testbed without 
flowvisor. I can't disable FlowVisor because I'm using the OFELIA 
project infraestructure (I share the devices with other 
experimenters): 
http://www.fp7-ofelia.eu/ofelia-facility-and-islands/equipment/


Thank you.

El 12/01/2012 18:08, Aaron Rosen escribió:
If you do a packet dump at the flowvisor do you see vlan tags on 
these LLDP packets returned to you?


I'm guessing the LLDP packets that are returned to you from the 
switch (Via PACKET_IN) ) do not have VLAN tags correct? (The switch 
takes them off since this switch isn't acting as a pure of switch. 
Only this one vlan is being openflow controlled. )


This is the same reason why your controller does not need to know 
which vlan tag you are using on the switch. When the controller 
sends a LLDP packet to the switch the switch will output that packet 
on the correct port and automatically add the tag for you.


You said this was working with out flowvisor right? If you run git 
branch from the nox directory what does it say?


Aaron


2012/1/12 Sergio Jiménez Feijóo >


Hi Aaron,

My application that runs on NOX examines the packets and
forwards them keeping the same VLAN ID tag. But how does the
topology module tell the switches that they must send the LLDPs
with a certain VLAN ID tag? The topology module is independent
from my application and I can't controle it. If the topology
module sends the LLDPs packets without the proper VLAN tag they
won't be forwarded to my controller (because they won't belong
to my FlowVisor flowspace).

This is just a supposition but I think this may be the cause of
the problem.

Thank you for your help.

El 12/01/2012 16:25, Aaron Rosen escribió:

Did you do git checkout -b destiny

When the controller sends the LLDP packet it won't have a vlan
tag. Once it leaves the switch, the switch will add your tag
for you.  I don't think that's the problem.

Aaron

2012/1/12 Sergio Jiménez Feijóo mailto:jjji...@gmail.com>>

Hi Aaron,

I'm using the latest version (I think). I downloaded it
from the git repository by the command "git clone
git://noxrepo.org/nox " a few days ago.

My flowspace consists on tagging all my trafic with a
certain VLAN ID (VLAN 13). All the traffic tagged with that
VLAN ID belongs to my flowspace. Is it possible that the
topology component isn't sending the LLDP frames tagged
with the proper VLAN ID? How can I force the topology
component to send the LLDP frames tagged with a certain
VLAN ID?

Thank you.

El 12/01/2012 15:33, Aaron Rosen escribió:

P.S: Which version of nox are you running? I believe this
works fine in destiny.

Aaron

2012/1/12 Aaron Rosen mailto:aro...@clemson.edu>>

Hi,

I've encountered an issue like this before with
flowvisor and the discovery module. The easiest thing
to do is to change the lldp value in

 ./src/nox/lib/packet/ethernet.py

   #LLDP_TYPE = 0x88cc
LLDP_TYPE = new_value

then add this new_value, ether_type to your slice.

Hopefully that will do the trick.

Aaron


2012/1/12 Sergio Jiménez Feijóo mailto:jjji...@gmail.com>>

Hi guys,

I've developed a NOX aplication which needs to use
the topology component to discover the network
topology. I've tested my application in a testbed
of 6 Linksys WRT54GL running the OpenWRT Pantou
firmware (without flowvisor) and it worked like a
charm. Now I'm testing my aplication in a testbed
of 5 NEC IP8800/S3640-24T2XW (with flowvisor) and
the topology detection isn't working at all (the

Re: [nox-dev] Topology component and FlowVisor.

[Murphy McCauley]

There have been some changes to logging.  Use -v -v.

-- Murphy

On Jan 12, 2012, at 10:10 AM, Sergio Jiménez Feijóo wrote:

> Hi Aaron,
> 
> I have moved to the destiny branch and compiled everything again. The 
> topology component seems to work fine (I can see "new link detected" messages 
> in the log) but now I can't see the log messages of my application (VLOG_DBG 
> function) despite I'm running NOX with the -v flag. My application isn't 
> working properly yet but until I can see those log messages I won't be able 
> to find the cause of the new problem.
> 
> In response to Ali: I Have tested my application in another testbed without 
> flowvisor but I can't run it in this testbed without flowvisor. I can't 
> disable FlowVisor because I'm using the OFELIA project infraestructure (I 
> share the devices with other experimenters): 
> http://www.fp7-ofelia.eu/ofelia-facility-and-islands/equipment/
> 
> Thank you.
> 
> El 12/01/2012 18:08, Aaron Rosen escribió:
>> 
>> If you do a packet dump at the flowvisor do you see vlan tags on these LLDP 
>> packets returned to you?  
>> 
>> I'm guessing the LLDP packets that are returned to you from the switch (Via 
>> PACKET_IN) ) do not have VLAN tags correct? (The switch takes them off since 
>> this switch isn't acting as a pure of switch. Only this one vlan is being 
>> openflow controlled. ) 
>> 
>> This is the same reason why your controller does not need to know which vlan 
>> tag you are using on the switch. When the controller sends a LLDP packet to 
>> the switch the switch will output that packet on the correct port and 
>> automatically add the tag for you. 
>> 
>> You said this was working with out flowvisor right? If you run git branch 
>> from the nox directory what does it say? 
>> 
>> Aaron
>> 
>> 
>> 2012/1/12 Sergio Jiménez Feijóo 
>> Hi Aaron,
>> 
>> My application that runs on NOX examines the packets and forwards them 
>> keeping the same VLAN ID tag. But how does the topology module tell the 
>> switches that they must send the LLDPs with a certain VLAN ID tag? The 
>> topology module is independent from my application and I can't controle it. 
>> If the topology module sends the LLDPs packets without the proper VLAN tag 
>> they won't be forwarded to my controller (because they won't belong to my 
>> FlowVisor flowspace).
>> 
>> This is just a supposition but I think this may be the cause of the problem.
>> 
>> Thank you for your help.
>> 
>> El 12/01/2012 16:25, Aaron Rosen escribió:
>>> Did you do git checkout -b destiny 
>>> 
>>> When the controller sends the LLDP packet it won't have a vlan tag. Once it 
>>> leaves the switch, the switch will add your tag for you.  I don't think 
>>> that's the problem. 
>>> 
>>> Aaron
>>> 
>>> 2012/1/12 Sergio Jiménez Feijóo 
>>> Hi Aaron,
>>> 
>>> I'm using the latest version (I think). I downloaded it from the git 
>>> repository by the command "git clone git://noxrepo.org/nox" a few days ago.
>>> 
>>> My flowspace consists on tagging all my trafic with a certain VLAN ID (VLAN 
>>> 13). All the traffic tagged with that VLAN ID belongs to my flowspace. Is 
>>> it possible that the topology component isn't sending the LLDP frames 
>>> tagged with the proper VLAN ID? How can I force the topology component to 
>>> send the LLDP frames tagged with a certain VLAN ID?
>>> 
>>> Thank you.
>>> 
>>> El 12/01/2012 15:33, Aaron Rosen escribió:
 P.S: Which version of nox are you running? I believe this works fine in 
 destiny. 
 
 Aaron
 
 2012/1/12 Aaron Rosen 
 Hi, 
 
 I've encountered an issue like this before with flowvisor and the 
 discovery module. The easiest thing to do is to change the lldp value in 
 
  ./src/nox/lib/packet/ethernet.py 
 
#LLDP_TYPE = 0x88cc
 LLDP_TYPE = new_value
 
 then add this new_value, ether_type to your slice. 
 
 Hopefully that will do the trick. 
 
 Aaron
 
 
 2012/1/12 Sergio Jiménez Feijóo 
 Hi guys,
 
 I've developed a NOX aplication which needs to use the topology component 
 to discover the network topology. I've tested my application in a testbed 
 of 6 Linksys WRT54GL running the OpenWRT Pantou firmware (without 
 flowvisor) and it worked like a charm. Now I'm testing my aplication in a 
 testbed of 5 NEC IP8800/S3640-24T2XW (with flowvisor) and the topology 
 detection isn't working at all (the data struct is empty).
 
 Since OpenFlow allows an application to run in different devices I've 
 discarded the fact of using new switches as the cause of the error. 
 Therefore I think flowvisor is causing the topology component not to run 
 properly. Is this possible? Have you experienced any problems with 
 flowvisor and NOX?
 
 Thank you.
 
 http://homestore.cisco.eu/store/ciscoeu/en_IE/pd/productID.241269400
 http://www.openflow.org/wk/index.php/Pantou_:_OpenFlow_1.0_for_OpenWRT
 http://yub

Re: [nox-dev] Topology component and FlowVisor.

[Sergio Jiménez Feijóo]

Hi Aaron,

I have moved to the destiny branch and compiled everything again. The 
topology component seems to work fine (I can see "new link detected" 
messages in the log) but now I can't see the log messages of my 
application (VLOG_DBG function) despite I'm running NOX with the -v 
flag. My application isn't working properly yet but until I can see 
those log messages I won't be able to find the cause of the new problem.


In response to Ali: I Have tested my application in another testbed 
without flowvisor but I can't run it in this testbed without flowvisor. 
I can't disable FlowVisor because I'm using the OFELIA project 
infraestructure (I share the devices with other experimenters): 
http://www.fp7-ofelia.eu/ofelia-facility-and-islands/equipment/


Thank you.

El 12/01/2012 18:08, Aaron Rosen escribió:
If you do a packet dump at the flowvisor do you see vlan tags on these 
LLDP packets returned to you?


I'm guessing the LLDP packets that are returned to you from the switch 
(Via PACKET_IN) ) do not have VLAN tags correct? (The switch takes 
them off since this switch isn't acting as a pure of switch. Only this 
one vlan is being openflow controlled. )


This is the same reason why your controller does not need to know 
which vlan tag you are using on the switch. When the controller sends 
a LLDP packet to the switch the switch will output that packet on the 
correct port and automatically add the tag for you.


You said this was working with out flowvisor right? If you run git 
branch from the nox directory what does it say?


Aaron


2012/1/12 Sergio Jiménez Feijóo >


Hi Aaron,

My application that runs on NOX examines the packets and forwards
them keeping the same VLAN ID tag. But how does the topology
module tell the switches that they must send the LLDPs with a
certain VLAN ID tag? The topology module is independent from my
application and I can't controle it. If the topology module sends
the LLDPs packets without the proper VLAN tag they won't be
forwarded to my controller (because they won't belong to my
FlowVisor flowspace).

This is just a supposition but I think this may be the cause of
the problem.

Thank you for your help.

El 12/01/2012 16:25, Aaron Rosen escribió:

Did you do git checkout -b destiny

When the controller sends the LLDP packet it won't have a vlan
tag. Once it leaves the switch, the switch will add your tag for
you.  I don't think that's the problem.

Aaron

2012/1/12 Sergio Jiménez Feijóo mailto:jjji...@gmail.com>>

Hi Aaron,

I'm using the latest version (I think). I downloaded it from
the git repository by the command "git clone
git://noxrepo.org/nox " a few days ago.

My flowspace consists on tagging all my trafic with a certain
VLAN ID (VLAN 13). All the traffic tagged with that VLAN ID
belongs to my flowspace. Is it possible that the topology
component isn't sending the LLDP frames tagged with the
proper VLAN ID? How can I force the topology component to
send the LLDP frames tagged with a certain VLAN ID?

Thank you.

El 12/01/2012 15:33, Aaron Rosen escribió:

P.S: Which version of nox are you running? I believe this
works fine in destiny.

Aaron

2012/1/12 Aaron Rosen mailto:aro...@clemson.edu>>

Hi,

I've encountered an issue like this before with
flowvisor and the discovery module. The easiest thing to
do is to change the lldp value in

 ./src/nox/lib/packet/ethernet.py

   #LLDP_TYPE = 0x88cc
LLDP_TYPE = new_value

then add this new_value, ether_type to your slice.

Hopefully that will do the trick.

Aaron


2012/1/12 Sergio Jiménez Feijóo mailto:jjji...@gmail.com>>

Hi guys,

I've developed a NOX aplication which needs to use
the topology component to discover the network
topology. I've tested my application in a testbed of
6 Linksys WRT54GL running the OpenWRT Pantou
firmware (without flowvisor) and it worked like a
charm. Now I'm testing my aplication in a testbed of
5 NEC IP8800/S3640-24T2XW (with flowvisor) and the
topology detection isn't working at all (the data
struct is empty).

Since OpenFlow allows an application to run in
different devices I've discarded the fact of using
new switches as the cause of the error. Therefore I
think flowvisor is causing the topology component
not to run properly. Is this possible? Have you
experienced any problems with flowvisor and NOX?

Thank you.

Re: [nox-dev] Topology component and FlowVisor.

[Ali Al-Shabibi]

Hi Sergio,

Could you try to run your application without flowvisor. I find it strange that 
flowvisor would be causing a problem here, even though it treats lldp packets 
rather awkwardly. 

That said, if your setup works without flowvisor then we can definitely say 
that flowvisor is at fault and we can investigate further.

--
Ali Al-Shabibi

On 12 janv. 2012, at 04:24, Sergio Jiménez Feijóo  wrote:

> Hi guys,
> 
> I've developed a NOX aplication which needs to use the topology component to 
> discover the network topology. I've tested my application in a testbed of 6 
> Linksys WRT54GL running the OpenWRT Pantou firmware (without flowvisor) and 
> it worked like a charm. Now I'm testing my aplication in a testbed of 5 NEC 
> IP8800/S3640-24T2XW (with flowvisor) and the topology detection isn't working 
> at all (the data struct is empty).
> 
> Since OpenFlow allows an application to run in different devices I've 
> discarded the fact of using new switches as the cause of the error. Therefore 
> I think flowvisor is causing the topology component not to run properly. Is 
> this possible? Have you experienced any problems with flowvisor and NOX?
> 
> Thank you.
> 
> http://homestore.cisco.eu/store/ciscoeu/en_IE/pd/productID.241269400
> http://www.openflow.org/wk/index.php/Pantou_:_OpenFlow_1.0_for_OpenWRT
> http://yuba.stanford.edu/foswiki/bin/view/OpenFlow/Deployment/Vendor/NEC
> 
> ___
> 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] Topology component and FlowVisor.

[Aaron Rosen]

If you do a packet dump at the flowvisor do you see vlan tags on these LLDP
packets returned to you?

I'm guessing the LLDP packets that are returned to you from the switch (Via
PACKET_IN) ) do not have VLAN tags correct? (The switch takes them off
since this switch isn't acting as a pure of switch. Only this one vlan is
being openflow controlled. )

This is the same reason why your controller does not need to know which
vlan tag you are using on the switch. When the controller sends a LLDP
packet to the switch the switch will output that packet on the correct port
and automatically add the tag for you.

You said this was working with out flowvisor right? If you run git branch
from the nox directory what does it say?

Aaron


2012/1/12 Sergio Jiménez Feijóo 

>  Hi Aaron,
>
> My application that runs on NOX examines the packets and forwards them
> keeping the same VLAN ID tag. But how does the topology module tell the
> switches that they must send the LLDPs with a certain VLAN ID tag? The
> topology module is independent from my application and I can't controle it.
> If the topology module sends the LLDPs packets without the proper VLAN tag
> they won't be forwarded to my controller (because they won't belong to my
> FlowVisor flowspace).
>
> This is just a supposition but I think this may be the cause of the
> problem.
>
> Thank you for your help.
>
> El 12/01/2012 16:25, Aaron Rosen escribió:
>
> Did you do git checkout -b destiny
>
>  When the controller sends the LLDP packet it won't have a vlan tag. Once
> it leaves the switch, the switch will add your tag for you.  I don't think
> that's the problem.
>
>  Aaron
>
> 2012/1/12 Sergio Jiménez Feijóo 
>
>>  Hi Aaron,
>>
>> I'm using the latest version (I think). I downloaded it from the git
>> repository by the command "git clone git://noxrepo.org/nox" a few days
>> ago.
>>
>> My flowspace consists on tagging all my trafic with a certain VLAN ID
>> (VLAN 13). All the traffic tagged with that VLAN ID belongs to my
>> flowspace. Is it possible that the topology component isn't sending the
>> LLDP frames tagged with the proper VLAN ID? How can I force the topology
>> component to send the LLDP frames tagged with a certain VLAN ID?
>>
>> Thank you.
>>
>> El 12/01/2012 15:33, Aaron Rosen escribió:
>>
>> P.S: Which version of nox are you running? I believe this works fine in
>> destiny.
>>
>> Aaron
>>
>> 2012/1/12 Aaron Rosen 
>>
>>> Hi,
>>>
>>>  I've encountered an issue like this before with flowvisor and the
>>> discovery module. The easiest thing to do is to change the lldp value in
>>>
>>>   ./src/nox/lib/packet/ethernet.py
>>>
>>> #LLDP_TYPE = 0x88cc
>>>  LLDP_TYPE = new_value
>>>
>>>  then add this new_value, ether_type to your slice.
>>>
>>>  Hopefully that will do the trick.
>>>
>>>  Aaron
>>>
>>>
>>> 2012/1/12 Sergio Jiménez Feijóo 
>>>
 Hi guys,

 I've developed a NOX aplication which needs to use the topology
 component to discover the network topology. I've tested my application in a
 testbed of 6 Linksys WRT54GL running the OpenWRT Pantou firmware (without
 flowvisor) and it worked like a charm. Now I'm testing my aplication in a
 testbed of 5 NEC IP8800/S3640-24T2XW (with flowvisor) and the topology
 detection isn't working at all (the data struct is empty).

 Since OpenFlow allows an application to run in different devices I've
 discarded the fact of using new switches as the cause of the error.
 Therefore I think flowvisor is causing the topology component not to run
 properly. Is this possible? Have you experienced any problems with
 flowvisor and NOX?

 Thank you.

 http://homestore.cisco.eu/store/ciscoeu/en_IE/pd/productID.241269400
 http://www.openflow.org/wk/index.php/Pantou_:_OpenFlow_1.0_for_OpenWRT
 http://yuba.stanford.edu/foswiki/bin/view/OpenFlow/Deployment/Vendor/NEC

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

>>>
>>>
>>>
>>>   --
>>> Aaron O. Rosen
>>> Masters Student - Network Communication
>>> 306B Fluor Daniel
>>>
>>>
>>>
>>
>>
>> --
>> Aaron O. Rosen
>> Masters Student - Network Communication
>> 306B Fluor Daniel
>>
>>
>>
>>
>> ___
>> nox-dev mailing list
>> nox-dev@noxrepo.org
>> http://noxrepo.org/mailman/listinfo/nox-dev
>>
>>
>
>
>  --
> Aaron O. Rosen
> Masters Student - Network Communication
> 306B Fluor Daniel
>
>
>
>
> ___
> nox-dev mailing list
> nox-dev@noxrepo.org
> http://noxrepo.org/mailman/listinfo/nox-dev
>
>


-- 
Aaron O. Rosen
Masters Student - Network Communication
306B Fluor Daniel
___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev

Re: [nox-dev] Topology component and FlowVisor.

[Sergio Jiménez Feijóo]

Hi Aaron,

My application that runs on NOX examines the packets and forwards them 
keeping the same VLAN ID tag. But how does the topology module tell the 
switches that they must send the LLDPs with a certain VLAN ID tag? The 
topology module is independent from my application and I can't controle 
it. If the topology module sends the LLDPs packets without the proper 
VLAN tag they won't be forwarded to my controller (because they won't 
belong to my FlowVisor flowspace).


This is just a supposition but I think this may be the cause of the problem.

Thank you for your help.

El 12/01/2012 16:25, Aaron Rosen escribió:

Did you do git checkout -b destiny

When the controller sends the LLDP packet it won't have a vlan tag. 
Once it leaves the switch, the switch will add your tag for you.  I 
don't think that's the problem.


Aaron

2012/1/12 Sergio Jiménez Feijóo >


Hi Aaron,

I'm using the latest version (I think). I downloaded it from the
git repository by the command "git clone git://noxrepo.org/nox
" a few days ago.

My flowspace consists on tagging all my trafic with a certain VLAN
ID (VLAN 13). All the traffic tagged with that VLAN ID belongs to
my flowspace. Is it possible that the topology component isn't
sending the LLDP frames tagged with the proper VLAN ID? How can I
force the topology component to send the LLDP frames tagged with a
certain VLAN ID?

Thank you.

El 12/01/2012 15:33, Aaron Rosen escribió:

P.S: Which version of nox are you running? I believe this works
fine in destiny.

Aaron

2012/1/12 Aaron Rosen mailto:aro...@clemson.edu>>

Hi,

I've encountered an issue like this before with flowvisor and
the discovery module. The easiest thing to do is to change
the lldp value in

 ./src/nox/lib/packet/ethernet.py

   #LLDP_TYPE = 0x88cc
LLDP_TYPE = new_value

then add this new_value, ether_type to your slice.

Hopefully that will do the trick.

Aaron


2012/1/12 Sergio Jiménez Feijóo mailto:jjji...@gmail.com>>

Hi guys,

I've developed a NOX aplication which needs to use the
topology component to discover the network topology. I've
tested my application in a testbed of 6 Linksys WRT54GL
running the OpenWRT Pantou firmware (without flowvisor)
and it worked like a charm. Now I'm testing my aplication
in a testbed of 5 NEC IP8800/S3640-24T2XW (with
flowvisor) and the topology detection isn't working at
all (the data struct is empty).

Since OpenFlow allows an application to run in different
devices I've discarded the fact of using new switches as
the cause of the error. Therefore I think flowvisor is
causing the topology component not to run properly. Is
this possible? Have you experienced any problems with
flowvisor and NOX?

Thank you.

http://homestore.cisco.eu/store/ciscoeu/en_IE/pd/productID.241269400

http://www.openflow.org/wk/index.php/Pantou_:_OpenFlow_1.0_for_OpenWRT

http://yuba.stanford.edu/foswiki/bin/view/OpenFlow/Deployment/Vendor/NEC

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




-- 
Aaron O. Rosen

Masters Student - Network Communication
306B Fluor Daniel





-- 
Aaron O. Rosen

Masters Student - Network Communication
306B Fluor Daniel





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




--
Aaron O. Rosen
Masters Student - Network Communication
306B Fluor Daniel




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

Re: [nox-dev] Topology component and FlowVisor.

[Aaron Rosen]

Did you do git checkout -b destiny

When the controller sends the LLDP packet it won't have a vlan tag. Once it
leaves the switch, the switch will add your tag for you.  I don't think
that's the problem.

Aaron

2012/1/12 Sergio Jiménez Feijóo 

>  Hi Aaron,
>
> I'm using the latest version (I think). I downloaded it from the git
> repository by the command "git clone git://noxrepo.org/nox" a few days
> ago.
>
> My flowspace consists on tagging all my trafic with a certain VLAN ID
> (VLAN 13). All the traffic tagged with that VLAN ID belongs to my
> flowspace. Is it possible that the topology component isn't sending the
> LLDP frames tagged with the proper VLAN ID? How can I force the topology
> component to send the LLDP frames tagged with a certain VLAN ID?
>
> Thank you.
>
> El 12/01/2012 15:33, Aaron Rosen escribió:
>
> P.S: Which version of nox are you running? I believe this works fine in
> destiny.
>
> Aaron
>
> 2012/1/12 Aaron Rosen 
>
>> Hi,
>>
>>  I've encountered an issue like this before with flowvisor and the
>> discovery module. The easiest thing to do is to change the lldp value in
>>
>>   ./src/nox/lib/packet/ethernet.py
>>
>> #LLDP_TYPE = 0x88cc
>>  LLDP_TYPE = new_value
>>
>>  then add this new_value, ether_type to your slice.
>>
>>  Hopefully that will do the trick.
>>
>>  Aaron
>>
>>
>> 2012/1/12 Sergio Jiménez Feijóo 
>>
>>> Hi guys,
>>>
>>> I've developed a NOX aplication which needs to use the topology
>>> component to discover the network topology. I've tested my application in a
>>> testbed of 6 Linksys WRT54GL running the OpenWRT Pantou firmware (without
>>> flowvisor) and it worked like a charm. Now I'm testing my aplication in a
>>> testbed of 5 NEC IP8800/S3640-24T2XW (with flowvisor) and the topology
>>> detection isn't working at all (the data struct is empty).
>>>
>>> Since OpenFlow allows an application to run in different devices I've
>>> discarded the fact of using new switches as the cause of the error.
>>> Therefore I think flowvisor is causing the topology component not to run
>>> properly. Is this possible? Have you experienced any problems with
>>> flowvisor and NOX?
>>>
>>> Thank you.
>>>
>>> http://homestore.cisco.eu/store/ciscoeu/en_IE/pd/productID.241269400
>>> http://www.openflow.org/wk/index.php/Pantou_:_OpenFlow_1.0_for_OpenWRT
>>> http://yuba.stanford.edu/foswiki/bin/view/OpenFlow/Deployment/Vendor/NEC
>>>
>>> ___
>>> nox-dev mailing list
>>> nox-dev@noxrepo.org
>>> http://noxrepo.org/mailman/listinfo/nox-dev
>>>
>>
>>
>>
>>   --
>> Aaron O. Rosen
>> Masters Student - Network Communication
>> 306B Fluor Daniel
>>
>>
>>
>
>
> --
> Aaron O. Rosen
> Masters Student - Network Communication
> 306B Fluor Daniel
>
>
>
>
> ___
> nox-dev mailing list
> nox-dev@noxrepo.org
> http://noxrepo.org/mailman/listinfo/nox-dev
>
>


-- 
Aaron O. Rosen
Masters Student - Network Communication
306B Fluor Daniel
___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev

Re: [nox-dev] Topology component and FlowVisor.

[Sergio Jiménez Feijóo]

Hi Aaron,

I'm using the latest version (I think). I downloaded it from the git 
repository by the command "git clone git://noxrepo.org/nox" a few days ago.


My flowspace consists on tagging all my trafic with a certain VLAN ID 
(VLAN 13). All the traffic tagged with that VLAN ID belongs to my 
flowspace. Is it possible that the topology component isn't sending the 
LLDP frames tagged with the proper VLAN ID? How can I force the topology 
component to send the LLDP frames tagged with a certain VLAN ID?


Thank you.

El 12/01/2012 15:33, Aaron Rosen escribió:
P.S: Which version of nox are you running? I believe this works fine 
in destiny.


Aaron

2012/1/12 Aaron Rosen mailto:aro...@clemson.edu>>

Hi,

I've encountered an issue like this before with flowvisor and the
discovery module. The easiest thing to do is to change the lldp
value in

 ./src/nox/lib/packet/ethernet.py

   #LLDP_TYPE = 0x88cc
LLDP_TYPE = new_value

then add this new_value, ether_type to your slice.

Hopefully that will do the trick.

Aaron


2012/1/12 Sergio Jiménez Feijóo mailto:jjji...@gmail.com>>

Hi guys,

I've developed a NOX aplication which needs to use the
topology component to discover the network topology. I've
tested my application in a testbed of 6 Linksys WRT54GL
running the OpenWRT Pantou firmware (without flowvisor) and it
worked like a charm. Now I'm testing my aplication in a
testbed of 5 NEC IP8800/S3640-24T2XW (with flowvisor) and the
topology detection isn't working at all (the data struct is
empty).

Since OpenFlow allows an application to run in different
devices I've discarded the fact of using new switches as the
cause of the error. Therefore I think flowvisor is causing the
topology component not to run properly. Is this possible? Have
you experienced any problems with flowvisor and NOX?

Thank you.

http://homestore.cisco.eu/store/ciscoeu/en_IE/pd/productID.241269400
http://www.openflow.org/wk/index.php/Pantou_:_OpenFlow_1.0_for_OpenWRT
http://yuba.stanford.edu/foswiki/bin/view/OpenFlow/Deployment/Vendor/NEC

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




-- 
Aaron O. Rosen

Masters Student - Network Communication
306B Fluor Daniel





--
Aaron O. Rosen
Masters Student - Network Communication
306B Fluor Daniel




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

Re: [nox-dev] Measuring delay of links between switches

[Bernd Wittefeld]

Hi Kyriakos,
yes I know of the propagation delays of the control channels. I thought 
of measuring these by simple ICMP Echo Requests and extracting the RTT 
from that. Assuming that we have symmetric channels, I can get an 
estimate of these delays and use them in the delay calculation.
The processing time on the switches should be a part of the overall 
delay in my opinion, as the packets travelling through the network must 
also take this time to be processed.
The question now is: which way is the best to implement this: patching 
the discovery module, as the infrastructure for periodical packets on 
every link is already there, or writing an own component which can be 
rather complex as there are some details that cannot be solved easily in 
my opinion.
The LLDP packets are filtered out and processed. A similar concept would 
be needed in this component. Then is the question: what type of packets 
would be used and how would they be sent through the network?
Maybe creating a simple packet with the dst IP of the controller and an 
action on the dst switch to forward the whole packet to the controller 
would work as long as the flows being installed do not interfere with 
the "normal" switch processing.


Best regards
Bernd

On 11.01.2012 23:42, Kyriakos Zarifis wrote:

Hi Bernd,

this sounds like an interesting idea to me, and something that could 
be proven useful.
One concern is that in the trip from the controller to switch A, 
switch B and back to the controller, you have the propagation delay of 
the control channels, the propagation delay between A<->B, but also 
the processing delay on the switches.
So some caution should be taken there in order to make sure that the 
processing delay on the switches is minimized, in order to get the 
best possible estimate of the delay of the link A<->B.
Also I would imagine that, say, if there was no other traffic, buffers 
were all empty etc, even then different switches would perform a bit 
differently, so that's another factor that would influence the 
estimation, though it's probably negligible.



On Wed, Jan 11, 2012 at 7:33 AM, Bernd Wittefeld 
mailto:s9bew...@stud.uni-saarland.de>> 
wrote:


Hi,
I am currently working on a component that needs a lot of
statistical information about the current network state.
In fact, I need the packet lLoss rate and the delay of single
links between OpenFlow-switches.
The PLR can be computed quite easily from the statistics that the
switch gives me (tx_packets and rx_packets of switches that are
connected via a link), but the delay turns out to be a problem.
I have the following idea:

I might use the discovery module and install an organizationally
specific TLV that simply carries a timestamp and with every
received LLDP packet, I can measure the time it takes for a packet
to travel from controller to switchA to switchB and back to the
controller. The links from the controller to the switches can be
measured easily, so I can get a rough estimate of the Delay on the
link (we don't talk about accuracy in the first place here :))
The discovery module can then deliver the delay for a specific
link via an API function.

What do you think? Is this feasible? Is this way ok or do I abuse
the LLDP protocol?

If it's ok, the implementation might be relatively straight
forward, adding a class to nox.lib.packet.lldp for my tlv and add
a parser, then modify the discovery module and I should be fine?!

If yes, do you have any other suggestions on how to implement
this? I also thought about a custom component that builds a packet
containing a timestamp and sends it out every switch port that is
connected to another switch and install an Action on the target
switch to forward that packet back to the controller. I don't know
if this is feasible and would work in the first place (addressing
and type of the packet carrying the timestamp for example would be
a problem).

Or am I completely wrong here? Is there anything that gives me
this information?

What do you think? I'm open for suggestions :)

Thanks in advance!

Bernd
___
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] Topology component and FlowVisor.

[Aaron Rosen]

P.S: Which version of nox are you running? I believe this works fine in
destiny.

Aaron

2012/1/12 Aaron Rosen 

> Hi,
>
> I've encountered an issue like this before with flowvisor and the
> discovery module. The easiest thing to do is to change the lldp value in
>
>  ./src/nox/lib/packet/ethernet.py
>
>#LLDP_TYPE = 0x88cc
> LLDP_TYPE = new_value
>
> then add this new_value, ether_type to your slice.
>
> Hopefully that will do the trick.
>
> Aaron
>
>
> 2012/1/12 Sergio Jiménez Feijóo 
>
>> Hi guys,
>>
>> I've developed a NOX aplication which needs to use the topology component
>> to discover the network topology. I've tested my application in a testbed
>> of 6 Linksys WRT54GL running the OpenWRT Pantou firmware (without
>> flowvisor) and it worked like a charm. Now I'm testing my aplication in a
>> testbed of 5 NEC IP8800/S3640-24T2XW (with flowvisor) and the topology
>> detection isn't working at all (the data struct is empty).
>>
>> Since OpenFlow allows an application to run in different devices I've
>> discarded the fact of using new switches as the cause of the error.
>> Therefore I think flowvisor is causing the topology component not to run
>> properly. Is this possible? Have you experienced any problems with
>> flowvisor and NOX?
>>
>> Thank you.
>>
>> http://homestore.cisco.eu/**store/ciscoeu/en_IE/pd/**productID.241269400
>> http://www.openflow.org/wk/**index.php/Pantou_:_OpenFlow_1.**
>> 0_for_OpenWRT
>> http://yuba.stanford.edu/**foswiki/bin/view/OpenFlow/**
>> Deployment/Vendor/NEC
>>
>> __**_
>> nox-dev mailing list
>> nox-dev@noxrepo.org
>> http://noxrepo.org/mailman/**listinfo/nox-dev
>>
>
>
>
> --
> Aaron O. Rosen
> Masters Student - Network Communication
> 306B Fluor Daniel
>
>
>


-- 
Aaron O. Rosen
Masters Student - Network Communication
306B Fluor Daniel
___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev

Re: [nox-dev] Topology component and FlowVisor.

[Aaron Rosen]

Hi,

I've encountered an issue like this before with flowvisor and the discovery
module. The easiest thing to do is to change the lldp value in

 ./src/nox/lib/packet/ethernet.py

   #LLDP_TYPE = 0x88cc
LLDP_TYPE = new_value

then add this new_value, ether_type to your slice.

Hopefully that will do the trick.

Aaron


2012/1/12 Sergio Jiménez Feijóo 

> Hi guys,
>
> I've developed a NOX aplication which needs to use the topology component
> to discover the network topology. I've tested my application in a testbed
> of 6 Linksys WRT54GL running the OpenWRT Pantou firmware (without
> flowvisor) and it worked like a charm. Now I'm testing my aplication in a
> testbed of 5 NEC IP8800/S3640-24T2XW (with flowvisor) and the topology
> detection isn't working at all (the data struct is empty).
>
> Since OpenFlow allows an application to run in different devices I've
> discarded the fact of using new switches as the cause of the error.
> Therefore I think flowvisor is causing the topology component not to run
> properly. Is this possible? Have you experienced any problems with
> flowvisor and NOX?
>
> Thank you.
>
> http://homestore.cisco.eu/**store/ciscoeu/en_IE/pd/**productID.241269400
> http://www.openflow.org/wk/**index.php/Pantou_:_OpenFlow_1.**0_for_OpenWRT
> http://yuba.stanford.edu/**foswiki/bin/view/OpenFlow/**
> Deployment/Vendor/NEC
>
> __**_
> nox-dev mailing list
> nox-dev@noxrepo.org
> http://noxrepo.org/mailman/**listinfo/nox-dev
>



-- 
Aaron O. Rosen
Masters Student - Network Communication
306B Fluor Daniel
___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev

[nox-dev] Topology component and FlowVisor.

[Sergio Jiménez Feijóo]

Hi guys,

I've developed a NOX aplication which needs to use the topology 
component to discover the network topology. I've tested my application 
in a testbed of 6 Linksys WRT54GL running the OpenWRT Pantou firmware 
(without flowvisor) and it worked like a charm. Now I'm testing my 
aplication in a testbed of 5 NEC IP8800/S3640-24T2XW (with flowvisor) 
and the topology detection isn't working at all (the data struct is empty).


Since OpenFlow allows an application to run in different devices I've 
discarded the fact of using new switches as the cause of the error. 
Therefore I think flowvisor is causing the topology component not to run 
properly. Is this possible? Have you experienced any problems with 
flowvisor and NOX?


Thank you.

http://homestore.cisco.eu/store/ciscoeu/en_IE/pd/productID.241269400
http://www.openflow.org/wk/index.php/Pantou_:_OpenFlow_1.0_for_OpenWRT
http://yuba.stanford.edu/foswiki/bin/view/OpenFlow/Deployment/Vendor/NEC

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