[pox-dev] buffer_id is None?

[Nan Zhu]

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.mccauley at gmail.com>wrote:

> On Nov 19, 2013, at 12:00 PM, Nan Zhu <zhunanmcgill at 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.mccauley at 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 <zhunanmcgill at 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
>> >
>> >
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.noxrepo.org/pipermail/pox-dev-noxrepo.org/attachments/20131119/168a057b/attachment-0002.htm>