Hi,
Thanks for the reply. It makes a lot of sense. So just to reiterate, I am
running nox_core with packetdump on. When my component is running, only one
http packet arrives because I am using flow_mod. This causes my rule to be
installed on the datapath therefore the rest of the matching flow packets
bypass my controller.
So the flow rule is installed on the switch, however the associated action
(no action i.e. drop packet) is not being executed. We know this because
when wire shark monitors the network (not the control channel) we see the
http packets are not dropped.
Without the flow_mod, each new packet will not be matched and thus
sent up. Can you check if there is any packet_out sent too?
Sorry for my ignorance but I don't quite understand what you mean by
packet_out here. How would I check this?
Regards
Iain
On Jul 14 2010, kk yap wrote:
Hi Ikf,
I am assuming you are running wireshark on the control channel. Then
the following behavior is correct:
> From the packet dumps it appears that the packets are being dropped,
> because after the first http packet in "Dump command on" no others
> arrive. However in "Dump command off" you can see others.
With the flow_mod, the switch will match the subsequent packets and
none of them will hit the controller anymore. They are just being
forwarded.
Without the flow_mod, each new packet will not be matched and thus
sent up. Can you check if there is any packet_out sent too?
I do not quite comprehend the rest, so I will refrain from commenting.
Regards
KK
On 14 July 2010 06:33, <i...@cs.nott.ac.uk> wrote:
> Hi,
>
> Sorry for the late reply. I better explain my set-up first. I am
> connected to the university of Nottingham by my main computer named
> Zeus. Zeus has two interfaces. One connected to the university network
> its IP is 128.243.18.33. The other interface is connected to my other
> computer (NEIGHBOR). The interface on Zeus has IP 192.168.1.2 . The
> interface of NEIGHBOR has IP 192.168.1.1 .
>
> Zeus acts as a gateway to the Internet/Uni Network for NEIGHBOR. I am
> running NOX and openflow on Zeus. So I have run two tests with NOX
> using packetdump. First the prior mentioned component is run normally.
> Second I comment out send_openflow_command so no flow command is being
> sent.
>
> I have cut and pasted the relevant information from the packet dump
> into the two attached files. "Dump command on" is when the command is
> being sent and vice versa for "Dump command off".
>
> From the packet dumps it appears that the packets are being dropped,
> because after the first http packet in "Dump command on" no others
> arrive. However in "Dump command off" you can see others.
>
> However even when I run the component normally, NEIGHBOR still gets
> the http file. I have also run wireshark, while the command is on and I
> can see multiple HTTP packets to and from NEIGHBOR. Any ideas?
>
> Thanks in advance
> Iain
>
> PS the attached files are just standard text files
>
> On Jul 12 2010, kk yap wrote:
>
>> Hi Iain,
>>
>> Would you might looking at the control traffic dump to let us know if
>> you keeping receiving more packet-in after inserting the flow rule?
>>
>> Also, is there any reason not to set the vlan_pcp?
>>
>> Regards
>> KK
>>
>> On 12 July 2010 07:20, <i...@cs.nott.ac.uk> wrote:
>> > Hi guys,
>> >
>> > I don't think I made it clear in the previous post. The code in the
>> > > previous post only gets called when the flow is identified as
>> > HTTP. > Then I am trying to block that particular flow. I know it
>> > would make > more sense to write general rule and send the command
>> > from the install > method. I am just doing this initially to see if
>> > I can get any packets > dropped.
>> >
>> > Thanks Again
>> > Iain
>> >
>> > On Jul 12 2010, i...@cs.nott.ac.uk wrote:
>> >
>> >> Hi Everyone,
>> >>
>> >> I am running NOX and openflow on the same machine. I am coding the
>> >> >> NOX controller in C++. I am trying to write code to selectively
>> >> drop >> packets. For a quick test I tried to write code that would
>> >> drop HTTP >> (i.e. tcp dst port 80) packets.
>> >>
>> >> The code correctly identifies the HTTP packet and it calls the >>
>> >> send_openflow_command with no action. However the packets are not
>> >> >> getting dropped. Below is initialisation of the openflow mod >>
>> >> structure. Which is sent in the command.
>> >>
>> >> // setup the header ofm.header.version = OFP_VERSION;
>> >> >> ofm.header.type = OFPT_FLOW_MOD; ofm.header.length
>> >> >> = >>
>> >> htons(sizeof ofm); // no extended action data
>> >>
>> >> // match the flow - therefore no wild-cards! >>
>> >> ofm.match.wildcards = htonl(0); ofm.match.in_port = >>
>> >> htons(flow.in_port); ofm.match.dl_vlan = flow.dl_vlan;
>> >> >> memcpy(ofm.match.dl_src,flow.dl_src.octet,sizeof
>> >> ofm.match.dl_src); >>
>> >> memcpy(ofm.match.dl_dst,flow.dl_dst.octet,sizeof >>
>> >> ofm.match.dl_dst); ofm.match.dl_type = flow.dl_type; >>
>> >> ofm.match.nw_src = flow.nw_src; ofm.match.nw_dst = >>
>> >> flow.nw_dst; ofm.match.nw_proto = flow.nw_proto; >>
>> >> ofm.match.tp_src = flow.tp_src; ofm.match.tp_dst = >>
>> >> flow.tp_dst;
>> >>
>> >> // add an entry - initalise entry housekeeping variables
>> >> (see
>> >> >> page 28 of OF spec) ofm.command = htons(OFPFC_ADD);
>> >> >> >>
>> >> ofm.buffer_id = htonl(packetid); ofm.idle_timeout = >>
>> >> htons(OFP_FLOW_PERMANENT); ofm.hard_timeout = >>
>> >> htons(OFP_FLOW_PERMANENT);
>> >>
>> >> ofm.priority = htons(OFP_DEFAULT_PRIORITY);
>> >> ofm.flags = OFPFF_CHECK_OVERLAP;
>> >>
>> >> When I run dpctl dump-flows on the switch I get >>
>> >> cookie=14431522174269325312, duration_sec=15s, >>
>> >> duration_nsec=832000000s, table_id=0, priority=65535, n_packets=3,
>> >> >> n_bytes=222, >>
>> >>
>> >> idle_timeout=0,hard_timeout=0,tcp,in_port=1,dl_vlan=0xffff,dl_vlan_pcp=0x00,dl_src=00:07:e9:ae:04:c7,dl_dst=00:13:d3:c0:46:f2,nw_src=192.168.1.1,nw_dst=91.189.88.31,nw_tos=0x00,tp_src=58891,tp_dst=80,actions=
>> >>
>> >>
>> >> Any ideas on what I am doing wrong?
>> >>
>> >> thanks in advance
>> >> Iain
>> >>
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> nox-dev mailing list
>> >> nox-dev@noxrepo.org
>> >> http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
>> >>
>> >
>> > _______________________________________________
>> > nox-dev mailing list
>> > nox-dev@noxrepo.org
>> > http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
>> >
>
_______________________________________________
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
