Hi, (Sorry for the spamm).
Could you please give me an answer about this problem? Because I could really use this action with in_port in my setup. Best, Clément On 15 April 2015 at 11:30, Clément Rault <[email protected]> wrote: > What I refer to is what is explained here : > > http://git.openvswitch.org/cgi-bin/gitweb.cgi?p=openvswitch;a=blob_plain;f=FAQ;hb=HEAD > > in the question > > "Q: I added a flow to send packets out the ingress port, like this: > ovs-ofctl add-flow br0 in_port=2,actions=2 > but OVS drops the packets instead." > > Best, > Clément > > > On 14 April 2015 at 17:20, Clément Rault <[email protected]> wrote: >> Thanks for your answer. >> >> I am using OVS yes. >> >> I tried to debug it using ovs-appctl: >> >> ubuntu@sdnhubvm:~[08:13]$ sudo ovs-appctl bridge/dump-flows s1 >> duration=58s, n_packets=5, n_bytes=490, >> priority=3,ip,nw_dst=11.0.0.1,actions=output:1 >> duration=58s, n_packets=14, n_bytes=1372, >> priority=1,ip,nw_dst=11.0.0.2,actions=group:1 >> duration=58s, n_packets=5, n_bytes=502, >> priority=2,ip,dl_vlan=1,nw_dst=11.0.0.2,actions=group:2 >> duration=58s, n_packets=3, n_bytes=306, >> priority=4,ip,dl_vlan=1,nw_dst=11.0.0.1,actions=pop_vlan,output:1 >> table_id=254, duration=63s, n_packets=0, n_bytes=0, priority=1,actions=drop >> table_id=254, duration=63s, n_packets=0, n_bytes=0, >> priority=0,reg0=0x3,actions=drop >> table_id=254, duration=63s, n_packets=0, n_bytes=0, >> priority=0,reg0=0x1,actions=controller(reason=no_match) >> table_id=254, duration=63s, n_packets=19, n_bytes=1518, >> priority=0,reg0=0x2,actions=drop >> table_id=254, duration=63s, n_packets=0, n_bytes=0, >> priority=2,recirc_id=0,actions=resubmit(,0) >> >> and these are the only lines where I see a drop action and I guess these >> rules are put automatically for the packets that are not matched by any >> other rule. >> >> >> >> Concerning the packets that I try to to send back from the port where they >> came I read online that it is actually the default behaviour of OVS to drop >> a packet if you specify the same port number as inport and outport. The way >> to overcome that is to specify in_port (instead of the port number). >> >> (from the OF spec 1.3.4: " Required: IN PORT: Represents the packet ingress >> port. Can be used only as an output port, send the packet out through its >> ingress port." in section 4.5 reserved ports). >> >> But I can't manage to make it work with Ryu. >> >> I tried both >> >> curl -X POST -d '{ # group for dst 11.0.0.1 >> from inport 3 >> "dpid": 2, >> "type": "SELECT", >> "group_id": 1, >> "buckets": [ >> { >> "weight": 5, >> "watch_port": 2, >> "actions": [ >> { >> "type": "OUTPUT", >> "port": 2 >> } >> ] >> }, >> { >> "weight": 5, >> "watch_port": 3, >> "actions": [ >> { >> "type": "IN_PORT", >> } >> ] >> } >> >> ] >> }' http://localhost:8080/stats/groupentry/add >> >> and >> >> curl -X POST -d '{ # group for dst 11.0.0.1 >> from inport 2 >> "dpid": 3, >> "type": "SELECT", >> "group_id": 1, >> "buckets": [ >> { >> "weight": 5, >> "watch_port": 2, >> "actions": [ >> { >> "type": "OUTPUT", >> "port": IN_PORT >> } >> ] >> }, >> { >> "weight": 5, >> "watch_port": 3, >> "actions": [ >> { >> "type": "OUTPUT", >> "port": 3 >> } >> ] >> } >> >> ] >> }' http://localhost:8080/stats/groupentry/add >> >> But in my both cases I am getting an error. >> >> Can you please tell how it can be done with ryu? >> >> Best, >> Clément >> >> On 13 April 2015 at 09:54, YAMAMOTO Takashi <[email protected]> wrote: >>> >>> there are various places for OVS to drop packets. (are you using OVS?) >>> >>> you might want to try "ovs-appctl bridge/dump-flows bridge-name" >>> to see n_bytes/n_packets for internal flows. >>> >>> YAMAMOTO Takashi >>> >>> > Hi, >>> > >>> > I am trying to develop inband mechanisms for fast reaction to failures >>> > and I am experiencing a very high packet loss. >>> > >>> > "--- 11.0.0.2 ping statistics --- >>> > 573 packets transmitted, 13 received, 97% packet loss, time 574650ms >>> > rtt min/avg/max/mdev = 1.259/2.291/5.683/1.140 ms" >>> > >>> > which is probably due to the fact that some of my packets get in a >>> > infinite (or not infinite but very long) loop (even though it >>> > shouldn't happen) but I would like to >>> > understand why and where they get dropped. >>> > >>> > And therefore I would like to know if there is a way to check if a >>> > switch (I am using mininet) is dropping packets? >>> > >>> > Because I didn't put any rule to drop them and I am not decrementing >>> > the ttl so it cannot from that... >>> > >>> > What is the default behaviour/scenario for a switch to decide to >>> > drop a packet? >>> > >>> > Could it be because sometimes I am sending the packet back to the port >>> > where the packet came from? >>> > >>> > Best, >>> > Climent >>> > >>> > >>> > ------------------------------------------------------------------------------ >>> > BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT >>> > Develop your own process in accordance with the BPMN 2 standard >>> > Learn Process modeling best practices with Bonita BPM through live >>> > exercises >>> > http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- >>> > event?utm_ >>> > source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF >>> > _______________________________________________ >>> > Ryu-devel mailing list >>> > [email protected] >>> > https://lists.sourceforge.net/lists/listinfo/ryu-devel >> >> ------------------------------------------------------------------------------ BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF _______________________________________________ Ryu-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ryu-devel
