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 <jjji...@gmail.com
<mailto:jjji...@gmail.com>>
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 <jjji...@gmail.com
<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 <http://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 <aro...@clemson.edu
<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 <jjji...@gmail.com
<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 <mailto: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 <mailto: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 <mailto: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 <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
