Thanks for the clarification.
On Tue, Oct 29, 2013 at 8:31 PM, Murphy McCauley
wrote:
> On Oct 29, 2013, at 5:23 PM, Sulabh Bista wrote:
>
> Thanks Murphy. That helped.
>
> I noticed (with the dpctl show command in Mininet CLI) that two switches
> s1 and r1 have the same DPID. Should DPID be un
On Oct 29, 2013, at 5:23 PM, Sulabh Bista wrote:
> Thanks Murphy. That helped.
>
> I noticed (with the dpctl show command in Mininet CLI) that two switches s1
> and r1 have the same DPID. Should DPID be unique or is this behaviour ok?
Nope, not okay. They're supposed to be unique and it says
Thanks Murphy. That helped.
I noticed (with the dpctl show command in Mininet CLI) that two switches s1
and r1 have the same DPID. Should DPID be unique or is this behaviour ok?
I checked the source where dpid is being generated automatically and it
shows that the dpid is derived from the number
I don't think that switch name is communicated in a particularly direct way
over OpenFlow. That is, I don't think it's set as one of the fields in the
switch stats or anything. However, you can take advantage of the fact that
this name is used as the name of the "internal" port on the switch,
Hello:
I wanted to know if we can fetch the name assigned to an OVSwitch in
Mininet in POX. I am listening to PacketIn event and found noting relating
to the switch name in the 'event' object.
I am new to all of this. Sorry if my question sounds too dumb.
Regards,
Sulabh Bista
Hello,
I have tried my best, I reinstalled pox again and upgrade OVS an reinstall it
also twice to be sure!!
I am facing runtimerror netmask is not CIDR compatible. However,
pox/lib/addresses.py is thrown this error.
I do not know what to do else to solve this issue.
Any help is appreciated
B
Hello,
Thank you for helpful comments
I tried with openflow.nicira
The message is removed, but I think my problem is in _handle _connectionup
function because nothing is arrived to handle_packetin function. I wrote a
print and log statements inside packetin function but I did not get any output
Timers are independent, so what you are seeing is the expected behavior.
How is your "X" factoring into the example? It appears they should continue
forever... unless you have something (not shown) which cancels them. If so,
that's pretty much the answer to your question: to get them to be seq
