Re: [nox-dev] dropping packets
Hi KK,
thanks for all the speedy replies. Ok I tried using packet out instead of
flow mod. I used the following code:
vigil::nox::send_openflow_packet_out(pi.datapath_id,pi.buffer_id,NULL,0,OFPP_NONE,true);
I have set no actions so that it would drop the packet. However when I use
packetdump with the NOX controller, the packets are not being dropped at
all. Here is an extract from the packet dump:
[(Intel Corporation):ae:04:c7(MICRO-STAR INTERNATIONAL CO.,
LTD.):c0:46:f2:IP]([v:4hl:5l:60t:64]TCP
cs:f7cf[192.168.1.1128.243.80.167]){5385580} seq:2438365634 ack:0 f:0x2
[(Cisco):e3:20:c3(MICRO-STAR INTERNATIONAL CO.,
LTD.):c0:46:f3:IP]([v:4hl:5l:44t:55]TCP
cs:7eb6[128.243.80.167128.243.18.33]){8053855} seq:3257958938
ack:2438365635 f:0x12
[(Intel Corporation):ae:04:c7(MICRO-STAR INTERNATIONAL CO.,
LTD.):c0:46:f2:IP]([v:4hl:5l:40t:64]TCP
cs:f7e2[192.168.1.1128.243.80.167]){5385580} seq:2438365635
ack:3257958939 f:0x10
[(Intel Corporation):ae:04:c7(MICRO-STAR INTERNATIONAL CO.,
LTD.):c0:46:f2:IP]([v:4hl:5l:158t:64]TCP
cs:f76b[192.168.1.1128.243.80.167]){5385580} seq:2438365635
ack:3257958939 f:0x18
I have also tried to use the dpctl program to manually set the flow entry.
I used the following command to add the entry:
dpctl add-flow tcp:localhost:975 nw_proto=6,tp_dst=80,actions=
Again the packets did not get dropped. When I ran dpctl dump-tables
tcp:localhost:975 to see the tables I got:
0: hash2 : wild=0x0, max=131072, active=0
lookup=67814, matched=0
1: linear : wild=0x3f, max= 100, active=1
lookup=67814, matched=3450
Where the linear matches continue to increase. Does this mean that it is
matching the flows but not dropping them?
thank-you for your continued patient help
Iain
On Jul 14 2010, kk yap wrote:
Hi Ikf,
Packet out is for sending a packet out in the switch without a
flow_mod. Take a look at the OpenFlow spec.
Regards
KK
On 14 July 2010 08:27, i...@cs.nott.ac.uk wrote:
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
Re: [nox-dev] dropping packets
Hi Murphy, Thanks for the reply. When I run nox_core without any component, it seems (did quick look on wire-shark) like all packets are going through from NEIGHBOR. At least all http packets are anyway. I am running OpenFlow 0x01. I have never used netfilter before. But I was just trying to check if the openflow hooks are being ignored/overrided by other hooks running on my system. Do you think this is what it could be? thanks in advance Iain On Jul 15 2010, James Murphy McCauley wrote: Since this hasn't been quickly resolved, I thought it might be worth seeing if this is nothing to do with your NOX code, but to do with your network configuration instead. If you run ./nox_core with no components specified, do all your packets from NEIGHBOR go through? They *should* all die, but I think this is worth checking. It's entirely possible to set up a configuration where Linux forwards them out of NOX's control. Also, I may have missed this in one of the other messages, but what OpenFlow switch are you running? ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] dropping packets
It's been a while since I've dealt with this. A first thought would be... try: cat /proc/sys/net/ipv4/ip_forward Is it 1? If so, as root: echo 0 /proc/sys/net/ipv4/ip_forward -- Murphy On Thu, 2010-07-15 at 15:56 +0100, i...@cs.nott.ac.uk wrote: Hi Murphy, Thanks for the reply. When I run nox_core without any component, it seems (did quick look on wire-shark) like all packets are going through from NEIGHBOR. At least all http packets are anyway. I am running OpenFlow 0x01. I have never used netfilter before. But I was just trying to check if the openflow hooks are being ignored/overrided by other hooks running on my system. Do you think this is what it could be? thanks in advance Iain On Jul 15 2010, James Murphy McCauley wrote: Since this hasn't been quickly resolved, I thought it might be worth seeing if this is nothing to do with your NOX code, but to do with your network configuration instead. If you run ./nox_core with no components specified, do all your packets from NEIGHBOR go through? They *should* all die, but I think this is worth checking. It's entirely possible to set up a configuration where Linux forwards them out of NOX's control. Also, I may have missed this in one of the other messages, but what OpenFlow switch are you running? ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] dropping packets
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=83200s, table_id=0, priority=65535, n_packets=3, n_bytes=222, idle_timeout=0,hard_timeout=0,tcp,in_port=1,dl_vlan=0x,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 dump command on Description: dump command on dump command off Description: dump command off ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] dropping packets
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=83200s, table_id=0, priority=65535, n_packets=3, n_bytes=222, idle_timeout=0,hard_timeout=0,tcp,in_port=1,dl_vlan=0x,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
Re: [nox-dev] dropping packets
Hi Ikf, Packet out is for sending a packet out in the switch without a flow_mod. Take a look at the OpenFlow spec. Regards KK On 14 July 2010 08:27, i...@cs.nott.ac.uk wrote: 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;
Re: [nox-dev] dropping packets
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=83200s, table_id=0, priority=65535, n_packets=3, n_bytes=222, idle_timeout=0,hard_timeout=0,tcp,in_port=1,dl_vlan=0x,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
Re: [nox-dev] dropping packets
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=83200s, table_id=0, priority=65535, n_packets=3, n_bytes=222, idle_timeout=0,hard_timeout=0,tcp,in_port=1,dl_vlan=0x,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
Re: [nox-dev] dropping packets
Hello ikf. Some months ago I was with a similar issue. I was trying to do a test droping packets. I modified the component called pyswitch.py. This is my post: *Thanks Martin. I was looking the code of pyswitch.py and I found this: # don't forward lldp packets if packet.type == ethernet.LLDP_TYPE: return CONTINUE So, if I want to drop any kind of packet is just to specify its type? Like use packet.type == ethernet.TCP_TYPE to drop packet of tcp protocol? Thank you again for help me. * And he answered: *If you want to drop packets at the controller, then yes, you can simply return CONTINUE in a packet handler after checking the type. If you'd like packets to be dropped at the switch, you should install a flow entry with no actions which matches on the packets you'd like dropped. This is preferable since you don't exhaust bandwidth to the controller for packets which will ultimately be dropped* I don't know if this will help you, but maybe you can try it. Anyway, good luck. ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] dropping packets
Hi Ricardo and ikf, Thanks for the refresh. I think ikf was trying to install the flow entry and it is not matching for some reason. But the refresh is definitely useful. Btw, I am replying just to correct a typo. You should return STOP to drop the packets, not CONTINUE. And do check nox.xml or nox.json in src/etc to ensure the order of the component being called by Packet_in_event. It is always cool to see the community chipping in. Allow me to say thanks to everyone that have done so, and hope others will help out too. THANKS. Regards KK On 12 July 2010 08:37, Ricardo Bennesby ricardo.benne...@gmail.com wrote: Hello ikf. Some months ago I was with a similar issue. I was trying to do a test droping packets. I modified the component called pyswitch.py. This is my post: Thanks Martin. I was looking the code of pyswitch.py and I found this: # don't forward lldp packets if packet.type == ethernet.LLDP_TYPE: return CONTINUE So, if I want to drop any kind of packet is just to specify its type? Like use packet.type == ethernet.TCP_TYPE to drop packet of tcp protocol? Thank you again for help me. And he answered: If you want to drop packets at the controller, then yes, you can simply return CONTINUE in a packet handler after checking the type. If you'd like packets to be dropped at the switch, you should install a flow entry with no actions which matches on the packets you'd like dropped. This is preferable since you don't exhaust bandwidth to the controller for packets which will ultimately be dropped I don't know if this will help you, but maybe you can try it. Anyway, good luck. ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] dropping packets
Hi KK. Thank you for reply. But just to have sure, in the pyswitch.py component there are originally in lines 140-149: * # don't forward lldp packets if packet.type == ethernet.LLDP_TYPE: return CONTINUE # learn MAC on incoming port do_l2_learning(dpid, inport, packet) forward_l2_packet(dpid, inport, packet, packet.arr, bufid) return CONTINUE * Doesn't it mean that the lldp packets are dropped, because no actions are specified and they are not forward? Thanks again. I agree with you when you say that the community participation is very important. If I'm wrong, please correct me. Regards. ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] dropping packets
On 12 July 2010 18:19, Ricardo Bennesby ricardo.benne...@gmail.com wrote: [ snip STOP vs. CONTINUE examples ] Doesn't it mean that the lldp packets are dropped, because no actions are specified and they are not forward? as i understand it, if the packets end up being processed at the controller (nox_core running pyswitch.py in this case), return STOP will cause them to drop, and return CONTINUE will cause them to continue to be processed and thus forwarded. installing the flow entry at the switch (datapath) causes them not to even reach the controller in future unless so directed by the flow entry's action. (i also had similar problems when setting all this up on a single machine managing a single ethernet interface, but they went away once i moved to openvswitch, albeit to be replaced by other ones which i'm still in the process of understanding :) cheers, -- Richard Mortier m...@cantab.net ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] dropping packets
Hi, Yes. return CONTINUE passes it to the next component and return STOP prevents the next component from getting it. This is true for both C/C++ components and Python components. Regards KK On 12 July 2010 10:40, Richard Mortier m...@cantab.net wrote: On 12 July 2010 18:19, Ricardo Bennesby ricardo.benne...@gmail.com wrote: [ snip STOP vs. CONTINUE examples ] Doesn't it mean that the lldp packets are dropped, because no actions are specified and they are not forward? as i understand it, if the packets end up being processed at the controller (nox_core running pyswitch.py in this case), return STOP will cause them to drop, and return CONTINUE will cause them to continue to be processed and thus forwarded. installing the flow entry at the switch (datapath) causes them not to even reach the controller in future unless so directed by the flow entry's action. (i also had similar problems when setting all this up on a single machine managing a single ethernet interface, but they went away once i moved to openvswitch, albeit to be replaced by other ones which i'm still in the process of understanding :) cheers, -- Richard Mortier m...@cantab.net ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] dropping packets
Hi KK and Richard, Thank you for the answers. I understand it better now. Regards. ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
