Hi, Murphy, 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....
Now, I broadcast them to every hosts, I do not receive None buf_id anymore, and all hosts ping with each other Thank you very much Best, Nan On Tue, Nov 19, 2013 at 3:14 PM, Murphy McCauley <murphy.mccau...@gmail.com>wrote: > On Nov 19, 2013, at 12:00 PM, Nan Zhu <zhunanmcg...@gmail.com> wrote: > > Hi, Murphy, > > I think I have send packet_out for every packet_in.... > > 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? > > > 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...). > > 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)? > > 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? > > > 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. > > -- Murphy > > On Tue, Nov 19, 2013 at 2:04 PM, Murphy McCauley < > murphy.mccau...@gmail.com> wrote: > >> I'm aware of two possibilities. >> >> 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). >> >> 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. >> >> 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. >> >> -- Murphy >> >> On Nov 19, 2013, at 6:08 AM, Nan Zhu <zhunanmcg...@gmail.com> wrote: >> >> > Hi, all >> > >> > I'm developing some controller with POX, >> > >> > 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? >> > >> > Anyone had this problem before? obviously it is caused by my >> controller, I used other code to test, this type of packet never appear >> > >> > What can be the reason of that? >> > >> > Best, >> > >> > Nan >> > >> > >> >> > >