In OpenFlow 1.0, an unmatched packet is sent to the controller. This is described on page 2 of the OpenFlow 1.0 specification.
-- Murphy On Oct 24, 2013, at 5:33 PM, durga <c.vijaya.du...@gmail.com> wrote: > Thanks again Murphy. > So ofp_match typically creates a filter for further packets to 'match' > against. > if incase a match is not created , then by default, the switch drops the > 'msg' from controller ..is it? or does it matching all the packets when > there is no match ? > > I am thinking on terms of ACLs > > Cheers! > Durga > > > > On Fri, Oct 25, 2013 at 8:07 AM, Murphy McCauley <murphy.mccau...@gmail.com> > wrote: > > On Oct 24, 2013, at 12:16 PM, durga <c.vijaya.du...@gmail.com> wrote: > >> hmm.. ok , in l2_learning.py code, why did we 'match' msg with the parsed >> packet?? >> >> >> >> >> >> msg = of.ofp_flow_mod() >> >> >> >> >> msg.match = of.ofp_match.from_packet(packet, event.port) >> >> >> >> >> >> >> >> I thought ofp_match() is used only for comparison . But the debug above >> shows that, ofp_match() not only compares but also updates 'msg' packet with >> details in the parsed packet . Is it so?? > > When you add a table entry, you give an ofp_match which specifies which > traffic that table entry applies to. In some cases, it's easy enough to > construct this by hand. However, one common case is that a switch has sent > the controller a packet because there was no matching table entry, and the > controller now wants to create a table entry for subsequent packets in this > same flow. That's what from_packet() does -- you give it a packet, and it > creates an ofp_match which is as narrow as possible to match subsequent > packets in the same flow. This is a common pattern for "reactive" style > controllers which need fine-grained control. > > Hope that sheds some light. > > -- Murphy > >> On Fri, Oct 25, 2013 at 5:34 AM, Murphy McCauley <murphy.mccau...@gmail.com> >> wrote: >> I'm afraid I don't follow the issue. Maybe you can post more code and try >> to further explain what you think is happening vs. what you think *should* >> be happening? >> >> -- Murphy >> >> On Oct 23, 2013, at 7:13 PM, durga <c.vijaya.du...@gmail.com> wrote: >> >>> Hello All, >>> >>> Just needed a confirmation on my understanding about match statement, all >>> the official resources mention as to matching/creating a match and the best >>> way to create a match from an existing packet is as below. >>> my_match = ofp_match.from_packet(packet, in_port) >>> >>> Now , as I debug , looks like match is actually used to compare and update >>> the new packet with the details provided in the original packet and not >>> just compare >>> >>> is this correct? >>> >>> >>> >>> >>> DEBUG:l2_switching_v4:ofp_flow_mod >>> header: >>> version: 1 >>> type: 14 (OFPT_FLOW_MOD) >>> length: 72 >>> xid: 12 >>> match: >>> wildcards: >>> nw_tos|tp_dst|dl_dst|dl_src|in_port|dl_vlan_pcp|nw_proto|dl_vlan|tp_src|dl_type|nw_src(/0)|nw_dst(/0) >>> (1110000010000011111111 = 3820ff) >>> cookie: 0 >>> command: 0 >>> idle_timeout: 0 >>> hard_timeout: 0 >>> priority: 32768 >>> buffer_id: None >>> out_port: 65535 >>> flags: 0 >>> actions: >>> >>> debug after ofp_flow_mod().match = ofp_match.from_packet(packet, in_port) >>> >>> DEBUG:l2_switching_v4:ofp_flow_mod >>> header: >>> version: 1 >>> type: 14 (OFPT_FLOW_MOD) >>> length: 80 >>> xid: 12 >>> match: >>> wildcards: nw_tos|tp_dst|tp_src (1000000000000011000000 = 2000c0) >>> in_port: 2 >>> dl_src: 00:00:00:00:00:02 >>> dl_dst: 00:00:00:00:00:01 >>> dl_vlan: 65535 >>> dl_vlan_pcp: 0 >>> dl_type: 0x806 >>> nw_proto: 2 >>> nw_src: 10.0.0.2 >>> nw_dst: 10.0.0.1 >>> cookie: 0 >>> command: 0 >>> idle_timeout: 0 >>> hard_timeout: 0 >>> priority: 32768 >>> buffer_id: None >>> out_port: 65535 >>> flags: 0 >>> actions: >>> type: 0 >>> len: 8 >>> port: 1 >>> max_len: 65535 >>> Cheers! >>> Durga >>> >> >> > >
