It is common practice in current legacy switches to allow dropping fragments if any classification is used, even tough this does "break communications".
The reasoning is that it is very likely communications would be broken anyway. Suppose you do something useful by L4 data. 1st frame gets this, the fragments do not. How likely is it that the whole stream does not "break communication" anyway? Even if communication is not "broken", the whole is probably still not what you want. If I pass traffic through a Bandwidth limiter per application, do I want to allow the sender to bypass the Mesasurent point by sending lots of fragments? Note HW based switches do not normally offer a "reassemble" option at all. Michael Orr p.s. Note that a fragment passing through a L4 classification rule can have Different results based on implementation. In some case, the classifier will Not match any fragments, knowing L4 data is not-present. In other cases, the classifier will simply look at the bits where the L4 data is supposed to be and try and match them, with pretty random results. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Srini Seetharaman Sent: Tuesday, April 26, 2011 12:35 PM To: Jojan Antony Cc: Tourrilhes, Jean; nox-dev; openflow-discuss Subject: Re: [openflow-discuss] [nox-dev] OFPC_FRAG_DROP This question is more appropriate to the openflow-discuss list copied here. Could someone that participated in the earlier spec process please comment on what the reasoning behind the OFPC_FRAG_DROP is? I see that the code is present to drop the packets in the userspace switch. So, I guess many switches do support it. It'll be great if the switch vendors comment on whether this feature is supported at this point in your switch. Thanks Srini. On Thu, Mar 17, 2011 at 5:32 PM, Jojan Antony <[email protected]> wrote: > Hi, > > I am a bit confused on the use of switch configuration flags, could > somebody throw some lights on > > OFPC_FRAG_DROP and OFPC_FRAG_MASK? > > What I could understand is, if the controller sets OFPC_FRAG_NORMAL, > the switch will treat all the fragments just like any other packet and > try to match every fragment with the flow table, and as a result, the > frgaments may not match L4 qualifiers. OFPC_FRAG_REASM will force the > switch to reassemble packets before taking decision - so the complete > flow is classified in the correct way. > > OFPC_FRAG_DROP is confusing in the sense, it will make the switch drop > all the fragmented traffic, breaking the communication! > > Thanks in advance > > Jojan > > > > Confidentiality Notice: This message and any attachments may contain > privileged and confidential information. If you have reason to believe > that you are not the intended recipient or a person responsible for > delivering this information to an intended recipient, you are hereby > notified that any review, dissemination, distribution, or copying of > this message is strictly prohibited. Please contact the sender > immediately by reply mail and destroy all copies of the original message. > _______________________________________________ > nox-dev mailing list > [email protected] > http://noxrepo.org/mailman/listinfo/nox-dev > > _______________________________________________ openflow-discuss mailing list [email protected] https://mailman.stanford.edu/mailman/listinfo/openflow-discuss _______________________________________________ openflow-discuss mailing list [email protected] https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
