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 >> >> >> > >
