<div dir="ltr">Hi, Murphy, <div><br></div><div>It turns out that I didn't handle the packets sent to multicast address properly...like those IPV6 multicast packets. I sent them to some strange places....</div><div><br>
</div><div>Now, I broadcast them to every hosts, I do not receive None buf_id anymore, and all hosts ping with each other</div><div><br></div><div>Thank you very much</div><div><br></div><div>Best,</div><div><br></div><div>
Nan</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Nov 19, 2013 at 3:14 PM, Murphy McCauley <span dir="ltr"><<a href="mailto:murphy.mccauley@gmail.com" target="_blank">murphy.mccauley@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div class="im">On Nov 19, 2013, at 12:00 PM, Nan Zhu <<a href="mailto:zhunanmcgill@gmail.com" target="_blank">zhunanmcgill@gmail.com</a>> wrote:<br>
</div><div><div class="im"><br><blockquote type="cite"><div dir="ltr">Hi, Murphy, <div><br></div><div>I think I have send packet_out for every packet_in....</div><div><br></div><div>I just added more statements to print out logs, it shows that a lot of IPV6 multicast packets going through my network ...will that overwhelm the buffer? </div>
</div></blockquote><div><br></div></div><div>Possibly. Especially if your network has loops. It's very easy for multicast/broadcast to result in large amounts of replication which will easily consume all your buffers (and bandwidth and CPU...).</div>
<div><br></div><div>Are you dealing with large amounts of packet-ins? It's possible that the controller and control channel simply can't keep up. If you don't *want* all these packet-ins (that is, you're not doing anything useful with them), then it would make sense to install table entries which kill the packets at the switch instead of sending them to the controller. If they *are* all important to you, then you might want to consider whether your design scales well... relying on packets being sent to the controller will likely always result in a bottleneck at some point. Using a faster controller framework (e.g., NOX) can help, but the problem is fundamental. More generally, is there any way you could have installed table entries rather than seeing the packets at the controller (shift towards proactive on the proactive/reactive continuum)?</div>
<div class="im"><br><blockquote type="cite"><div dir="ltr">
<div>For the second possibility, do you mean I set the limitation to a smaller value so that every packet would be buffered? can you give some hint on doing this?</div></div></blockquote><div><br></div></div><div>This depends on where the packets are coming from. If you're installing table entries with output actions that send to the controller, the output action's max_len attribute controls it. If they're being sent to the controller because they missed the table, core.openflow.miss_send_len controls it.</div>
<span class="HOEnZb"><font color="#888888"><div><br></div><div>-- Murphy</div></font></span><div class="im"><div><br></div><blockquote type="cite"><div class="gmail_extra"><div class="gmail_quote">On Tue, Nov 19, 2013 at 2:04 PM, Murphy McCauley <span dir="ltr"><<a href="mailto:murphy.mccauley@gmail.com" target="_blank">murphy.mccauley@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'm aware of two possibilities.<br>
<br>
The first is that your switch is out of buffer space/IDs. This can happen particularly if you are ignoring packet-ins in your controller. You may be better off sending a packet-out that references the buffer_id but has no actions; this way the switch will deallocate the buffer (various examples in POX do this; e.g., l2_learning, I believe).<br>
<br>
The second is that there's always a size limit of how much of a packet the switch will send to the controller. There's a single limit for packets which miss the table entirely, and every send-to-controller action has its own limit. If a packet is larger than this limit, the controller buffers the packet locally and sends a truncated version to the controller. However, if the packet is smaller than the limit, I believe OVS will simply send the entire packet to the controller *and not buffer it*. In POX, the "maximum length" for output actions to send to the controller is the full size of the packet, but you can set it to be smaller.<br>
<br>
I'll also note that POX's packet_out and flow_mod have special cases to make it easier to deal with the fact that you may have either case (a buffer ID or a full packet). The flow_mod one in particular isn't always ideal, but they work a lot of the time.<br>
<span><font color="#888888"><br>
-- Murphy<br>
</font></span><div><div><br>
On Nov 19, 2013, at 6:08 AM, Nan Zhu <<a href="mailto:zhunanmcgill@gmail.com" target="_blank">zhunanmcgill@gmail.com</a>> wrote:<br>
<br>
> Hi, all<br>
><br>
> I'm developing some controller with POX,<br>
><br>
> When I test it with mininet (--switch ovsk), I found that I will receive some packet_in which has a buffer_id with the value of None?<br>
><br>
> Anyone had this problem before? obviously it is caused by my controller, I used other code to test, this type of packet never appear<br>
><br>
> What can be the reason of that?<br>
><br>
> Best,<br>
><br>
> Nan<br>
><br>
><br>
<br>
</div></div></blockquote></div><br></div>
</blockquote></div></div><br></div></blockquote></div><br></div>