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