Hi,
I am working on discovery,spanning-tree and l2_multi module, and found that
the link_event, which raised by the discovery module, has 2 handlers in
spanning_tree and l2_multi respectively. I want to do some changes for
core.openflow_discovery.adjacency in spanning_tree module, after the
changi
Hi,
Sorry, I just got the answer from POX wiki page. Sorry for my last junk
mail.
--
Thanks
Tim
e)
> install the table entry themselves.
>
> As for what caused this... I think l2_multi predates discovery having the
> option to install a table entry.
>
> Here's an untested patch which maybe is an improvement on the state of
> affairs?
>
> -- Murphy
>
>
>
Hi,
I found in the discovery module, the controller will install a flow for the
LLDP packet to every switch, however, in the l2_multi module, the
controller will clear all flows when there is a link event for
re-calculating the path , which means the flow installed from discovery
module will only
Hi,
There isn't any command you can enable that.
Based on my understanding, you could do the binding for the ports on the
switch, but from controller standpoint view the binding ports should be one
logical port. The round-robin you can do on controller is based on the flow.
I implemented the rou
Sorry to bother you. I should search archive firstly. Thanks for your
patient reply.
On Fri, Dec 26, 2014 at 1:01 PM Murphy McCauley
wrote:
> Yes, and it has been discussed before. I've added the answer to the POX
> FAQ.
>
> -- Murphy
>
> On Dec 26, 2014, at 8:16 AM, tim
Hi,
I'm working on discovery module, and found that the LLDP destination MAC
address is not the standard. Is there any particular reason to use
NDP_MULTICAST as the destination MAC address?
--
Thanks
Tim
ameter spec_frags=True.
>
> -- Murphy
>
> On Oct 26, 2014, at 12:06 PM, tim huang wrote:
>
> Hi,
>
> After I tested, I found that the packet needs to be fragmented will
> cause _handle_PacketIn in l2_multi continually being called. And the packet
> of the parameter &
Cauley
wrote:
> Dump the control traffic using openflow.debug and then take a look at it,
> e.g., with the OpenFlow dissector for Wireshark. That may shed some light.
>
> You also might try enabling fragment reassembly by sending an
> OFPT_SET_CONFIG.
>
> -- Murphy
>
> On Oct 23,
lot. I do love the concept of pox than other similar
controller,like Ryu. Can anybody give me some clue about this problem?
On Fri, Oct 24, 2014 at 12:25 AM, tim huang wrote:
> Hi,
>
> I find the situation is more interesting than I thought. At beginning,
> it's just caused by the frag
Hi,
I find the situation is more interesting than I thought. At beginning, it's
just caused by the fragmentation,I can't ping with any fragmentation.
however, when I tried several times. I found something new. I can ping
successfully with large size packet, it that's the first flow between 2
switc
t; difference.
>
> Around line 384 of l2_multi.py, there's the line:
> match = of.ofp_match.from_packet(packet)
>
> Comment it out and do a simpler match. Like...
> match = of.ofp_match(dl_dst = packet.dst)
>
> -- Murphy
>
> On Oct 19, 2014, at 5:45 PM, Tim Hua
levant errors or
> log messages, etc.?
>
> -- Murphy
>
> On Oct 19, 2014, at 4:35 PM, Tim Huang wrote:
>
>> Hi,
>>
>> I am modifying the pox code to perform some kind of load balancing on the
>> controller. However, I found that the maximum ping packet
Hi,
I am modifying the pox code to perform some kind of load balancing on the
controller. However, I found that the maximum ping packet size that pox can
handle is around 1500 bytes which is too small for my test case, then I tried
other controllers like Ryu, Opendaylight, and they don’t have t
14 matches
Mail list logo
