[ovs-discuss] Query about universal OVS rules
Hi, I've been working on offloading the openflow rules. I observed that whenever I add a universal rule, all the traffic hitting that universal rule will create multiple flows(less than the number of different traffic flows generated by the transmitter) in hardware along with bitmasking. I want to ask, is there any configuration which will create an equal number of flows to the number of flows generated by the transmitter and not some flows with bitmasking? Thanks, Farhan ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Query wrt IPAM outside OVN
On Wed, Mar 2, 2022 at 2:44 PM Jaspal Singh Dhillon wrote: > > Hello again, > > Can you please assist with my query, to refresh: > > Is it possible for OVS/OVN to learn MAC-IP bindings in a network, where the > IPAM is done outside of OVN (basically external IPAM) ? > We are exploring options to achieve it and one way is to snoop packets and > update CMS directly. > But if this is a solved problem in OVS community, can you please suggest how > to go on about it. > OVN supports FDB learning provided the logical switch port has addresses set to "unknown". But it only stores the MAC-logical port information and not IP. Please check this - https://github.com/ovn-org/ovn/blob/main/ovn-sb.ovsschema#L524 and https://github.com/ovn-org/ovn/blob/main/ovn-sb.xml#L4511 To answer your question, I don't think OVN supports MAC-IP learning the way you are expecting. We do have another table - MAC Binding in Southbound database, but that is learnt in the router pipeline. You can check that out here - https://github.com/ovn-org/ovn/blob/main/ovn-sb.xml#L3365 Thanks Numan > Thanks, > Jaspal > > > From: discuss on behalf of Jaspal Singh > Dhillon > Sent: Wednesday, February 16, 2022 10:31 PM > To: ovs-discuss@openvswitch.org > Cc: Avignan Chatterjee > Subject: [ovs-discuss] Query wrt IPAM outside OVN > > Hello, > > Is it possible for OVS/OVN to learn MAC-IP bindings in a network, where the > IPAM is done outside of OVN (basically external IPAM) ? > We are exploring options to achieve it and one way is to snoop packets and > update CMS directly. > But if this is a solved problem in OVS community, can you please suggest how > to go on about it. > > Thanks, > Jaspal > ___ > discuss mailing list > disc...@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Query wrt IPAM outside OVN
Hello again, Can you please assist with my query, to refresh: Is it possible for OVS/OVN to learn MAC-IP bindings in a network, where the IPAM is done outside of OVN (basically external IPAM) ? We are exploring options to achieve it and one way is to snoop packets and update CMS directly. But if this is a solved problem in OVS community, can you please suggest how to go on about it. Thanks, Jaspal From: discuss on behalf of Jaspal Singh Dhillon Sent: Wednesday, February 16, 2022 10:31 PM To: ovs-discuss@openvswitch.org Cc: Avignan Chatterjee Subject: [ovs-discuss] Query wrt IPAM outside OVN Hello, Is it possible for OVS/OVN to learn MAC-IP bindings in a network, where the IPAM is done outside of OVN (basically external IPAM) ? We are exploring options to achieve it and one way is to snoop packets and update CMS directly. But if this is a solved problem in OVS community, can you please suggest how to go on about it. Thanks, Jaspal ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
[ovs-discuss] Query wrt IPAM outside OVN
Hello, Is it possible for OVS/OVN to learn MAC-IP bindings in a network, where the IPAM is done outside of OVN (basically external IPAM) ? We are exploring options to achieve it and one way is to snoop packets and update CMS directly. But if this is a solved problem in OVS community, can you please suggest how to go on about it. Thanks, Jaspal ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
[ovs-discuss] query on using promiscuous mode dpdk application with ovs
I have a DPDK forwarding application which runs in promiscuous mode copying packets from both of its ports to the other port, it also spoofs source mac addresses while forwarding, i.e. it never uses its source mac address.Currently this runs on bare metal Linux on physical ports connected to real switches. I want to run this in a VM now. 1. Can I run this DPDK application on a VM with the non-DPDK version of openvswitch ?2. I want openvswitch to pass this all the traffic received on the physical port and other virtual ports hosted on the ovs switch, destined to the spoofed source mac addresses sent by this vm and no other address. (This is how the application works on the real switch). How do I configure ovs to do this ? I could achieve this with sr-iov, the only problem is it gets all the addresses from the physical and virtual ports and not just the spoofed mac addresses it forwards. ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
[ovs-discuss] Query Regarding Creating OVS-DPDK Bond With vhost-user-client (virtual)interface
Hi Team, Is it possible to add two ovs vhost-user-client port to ovs dpdk bond interface and then to bridge ? Does OVS DPDK BOND support vhost-user-client ports or only physical interface ? as Command to create a Bond, but i am not sure if i can use/pass vhost-user-client/vhost-user ? ovs-vsctl add-bond br0 dpdkbond p0 p1 \ -- set Interface p0 type=dpdk options:dpdk-devargs=:01:00.0 \ -- set Interface p1 type=dpdk options:dpdk-devargs=:01:00.1 Regards ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
[ovs-discuss] Query Regarding OVS BOND with Flow Stickiness
Hi All, I have a specific use case where I need to use OVS Bond to distribute traffic across ports with flow stickiness . Currently I can see only 3 modes are available [active-backup, balance-slb, balance-tcp]. Is there any way in OVS by which I can configure a bond to send traffic across nics with flow stickiness ( say src IP ) . For example Client Namespace(2srcP)--OVS_Bridge--BOND--PORT0 --PORT1 Traffic coming from client namespace with 2 different source IP addresses, now I want the packet from first SRC IP should go to lets say PORT0 and from second src IP should go to PORT1. Best Regards Puneet ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
[ovs-discuss] Query
Hi, I am a research scholar. I want to know if I can implement VPLS architecture with SDN in OVS. If yes, please suggest the method in brief. Kindly help. Regards ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Query related to invalid_ttl support
On Mon, Sep 09, 2019 at 10:25:02PM +0530, bindiya Kurle wrote:
> Hi ,
> I was going through the code when ttl =0 and action is set as dec_ttl
> for ex: TTL of the packet is 1 and rule in ovs is ,
> ovs-ofctl add-flow vnf-net0 "table=1,in_port=1 actions=dec_ttl,output:2"
> from the 2.11 code.
> for this case it calls
> for (i = 0; i < ids->n_controllers; i++) {
> xlate_controller_action(ctx, UINT16_MAX, OFPR_INVALID_TTL,
> ids->cnt_ids[i], UINT32_MAX, NULL, 0);
> this in turn calls,
> put_controller_user_action
>
> This in turn will create user-space action. I am not getting where in the
> code, it is generating message towards controller for invalid ttl.
The userspace action sends a Netlink message to userspace, which in turn
gets classified in classify_upcall() in ofproto-dpif-upcall.c as a
CONTROLLER_UPCALL, which gets handled in process_upcall() by appending
to the async message queue, which run() in ofproto-dpif.c eventually
processes via connmgr_send_async_msg().
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
[ovs-discuss] Query related to invalid_ttl support
Hi ,
I was going through the code when ttl =0 and action is set as dec_ttl
for ex: TTL of the packet is 1 and rule in ovs is ,
ovs-ofctl add-flow vnf-net0 "table=1,in_port=1 actions=dec_ttl,output:2"
from the 2.11 code.
for this case it calls
for (i = 0; i < ids->n_controllers; i++) {
xlate_controller_action(ctx, UINT16_MAX, OFPR_INVALID_TTL,
ids->cnt_ids[i], UINT32_MAX, NULL, 0);
this in turn calls,
put_controller_user_action
This in turn will create user-space action. I am not getting where in the
code, it is generating message towards controller for invalid ttl.
If anyone has idea on this?
regards,
Bindiya
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Query on DEC_ttl action implementation in datapath
Thanks. Is there any forum where i can discuss the design for same? Regards, Bindiya On Thu, Aug 29, 2019 at 1:22 AM Justin Pettit wrote: > I understand. This has been discussed previously on the mailing list. > You are welcome to submit a patch upstream to provide that capability, but > I suspect you will get some resistance--especially from the Linux kernel > community. > > --Justin > > > > On Aug 27, 2019, at 11:25 PM, bindiya Kurle > wrote: > > > > Hi Justin, > > > > Thanks for the clarification. I agree to your point ,but consider a > use-case if I have routing decision only based on destination ip then as > per current implementation, ovs will add 2 flows (in data path)for packets > coming from different source and if the TTL happens to be different for > them .This will reduce number of flows that can be supported with ovs. If > decrement TTL was done in kernel ,it would have ended in adding one flow > only. > > > > Regards, > > Bindiya > > > > Regards, > > Bindiya > > > > On Tue, Aug 27, 2019 at 9:48 PM Justin Pettit wrote: > > I think it was considered cleaner from an ABI perspective, since it > doesn't require another action, since "set" was already supported. In > practice, I don't think it's a problem, since usually a TTL decrement is > associated with a routing decision, and TTLs tend to be fairly static > between two hosts. > > > > --Justin > > > > > > > On Aug 27, 2019, at 1:11 AM, bindiya Kurle > wrote: > > > > > > hi , > > > I have a question related to dec_ttl action implemented in datapath. > > > when dec_ttl action is configured in OVS following action get added > in datapath. > > > > > > recirc_id(0),in_port(2),eth(),eth_type(0x0800),ipv4(ttl=64,frag=no), > packets:3, bytes:294, used:0.068s, actions:set(ipv4(ttl=63)),3, > > > > > > if packet comes with different TTL on same port then one more action > get added in datapath. > > > for ex: > > > recirc_id(0),in_port(2),eth(),eth_type(0x0800),ipv4(ttl=9,frag=no), > packets:3, bytes:294, used:0.068s, actions:set(ipv4(ttl=8)),3, > > > > > > Could someone please explain why dec_ttl is implemeted as a set > action rather than dec_ttl action. > > > > > > > > > I mean , why for different ttl one more rule get added rather than > just adding it as following as done in userspace > > > > > > recirc_id(0),in_port(3),eth(),eth_type(0x0800),ipv4(frag=no), > packets:3, bytes:294, used:0.737s, actions:dec_ttl,2 > > > > > > Regards, > > > Bindiya > > > ___ > > > discuss mailing list > > > disc...@openvswitch.org > > > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss > > > > ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Query on DEC_ttl action implementation in datapath
I understand. This has been discussed previously on the mailing list. You are welcome to submit a patch upstream to provide that capability, but I suspect you will get some resistance--especially from the Linux kernel community. --Justin > On Aug 27, 2019, at 11:25 PM, bindiya Kurle wrote: > > Hi Justin, > > Thanks for the clarification. I agree to your point ,but consider a use-case > if I have routing decision only based on destination ip then as per current > implementation, ovs will add 2 flows (in data path)for packets coming from > different source and if the TTL happens to be different for them .This will > reduce number of flows that can be supported with ovs. If decrement TTL was > done in kernel ,it would have ended in adding one flow only. > > Regards, > Bindiya > > Regards, > Bindiya > > On Tue, Aug 27, 2019 at 9:48 PM Justin Pettit wrote: > I think it was considered cleaner from an ABI perspective, since it doesn't > require another action, since "set" was already supported. In practice, I > don't think it's a problem, since usually a TTL decrement is associated with > a routing decision, and TTLs tend to be fairly static between two hosts. > > --Justin > > > > On Aug 27, 2019, at 1:11 AM, bindiya Kurle wrote: > > > > hi , > > I have a question related to dec_ttl action implemented in datapath. > > when dec_ttl action is configured in OVS following action get added in > > datapath. > > > > recirc_id(0),in_port(2),eth(),eth_type(0x0800),ipv4(ttl=64,frag=no), > > packets:3, bytes:294, used:0.068s, actions:set(ipv4(ttl=63)),3, > > > > if packet comes with different TTL on same port then one more action get > > added in datapath. > > for ex: > > recirc_id(0),in_port(2),eth(),eth_type(0x0800),ipv4(ttl=9,frag=no), > > packets:3, bytes:294, used:0.068s, actions:set(ipv4(ttl=8)),3, > > > > Could someone please explain why dec_ttl is implemeted as a set action > > rather than dec_ttl action. > > > > > > I mean , why for different ttl one more rule get added rather than just > > adding it as following as done in userspace > > > > recirc_id(0),in_port(3),eth(),eth_type(0x0800),ipv4(frag=no), packets:3, > > bytes:294, used:0.737s, actions:dec_ttl,2 > > > > Regards, > > Bindiya > > ___ > > discuss mailing list > > disc...@openvswitch.org > > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss > ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Query on DEC_ttl action implementation in datapath
Hi Justin, Thanks for the clarification. I agree to your point ,but consider a use-case if I have routing decision only based on destination ip then as per current implementation, ovs will add 2 flows (in data path)for packets coming from different source and if the TTL happens to be different for them .This will reduce number of flows that can be supported with ovs. If decrement TTL was done in kernel ,it would have ended in adding one flow only. Regards, Bindiya Regards, Bindiya On Tue, Aug 27, 2019 at 9:48 PM Justin Pettit wrote: > I think it was considered cleaner from an ABI perspective, since it > doesn't require another action, since "set" was already supported. In > practice, I don't think it's a problem, since usually a TTL decrement is > associated with a routing decision, and TTLs tend to be fairly static > between two hosts. > > --Justin > > > > On Aug 27, 2019, at 1:11 AM, bindiya Kurle > wrote: > > > > hi , > > I have a question related to dec_ttl action implemented in datapath. > > when dec_ttl action is configured in OVS following action get added in > datapath. > > > > recirc_id(0),in_port(2),eth(),eth_type(0x0800),ipv4(ttl=64,frag=no), > packets:3, bytes:294, used:0.068s, actions:set(ipv4(ttl=63)),3, > > > > if packet comes with different TTL on same port then one more action get > added in datapath. > > for ex: > > recirc_id(0),in_port(2),eth(),eth_type(0x0800),ipv4(ttl=9,frag=no), > packets:3, bytes:294, used:0.068s, actions:set(ipv4(ttl=8)),3, > > > > Could someone please explain why dec_ttl is implemeted as a set action > rather than dec_ttl action. > > > > > > I mean , why for different ttl one more rule get added rather than just > adding it as following as done in userspace > > > > recirc_id(0),in_port(3),eth(),eth_type(0x0800),ipv4(frag=no), packets:3, > bytes:294, used:0.737s, actions:dec_ttl,2 > > > > Regards, > > Bindiya > > ___ > > discuss mailing list > > disc...@openvswitch.org > > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss > > ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Query on DEC_ttl action implementation in datapath
I think it was considered cleaner from an ABI perspective, since it doesn't require another action, since "set" was already supported. In practice, I don't think it's a problem, since usually a TTL decrement is associated with a routing decision, and TTLs tend to be fairly static between two hosts. --Justin > On Aug 27, 2019, at 1:11 AM, bindiya Kurle wrote: > > hi , > I have a question related to dec_ttl action implemented in datapath. > when dec_ttl action is configured in OVS following action get added in > datapath. > > recirc_id(0),in_port(2),eth(),eth_type(0x0800),ipv4(ttl=64,frag=no), > packets:3, bytes:294, used:0.068s, actions:set(ipv4(ttl=63)),3, > > if packet comes with different TTL on same port then one more action get > added in datapath. > for ex: > recirc_id(0),in_port(2),eth(),eth_type(0x0800),ipv4(ttl=9,frag=no), > packets:3, bytes:294, used:0.068s, actions:set(ipv4(ttl=8)),3, > > Could someone please explain why dec_ttl is implemeted as a set action > rather than dec_ttl action. > > > I mean , why for different ttl one more rule get added rather than just > adding it as following as done in userspace > > recirc_id(0),in_port(3),eth(),eth_type(0x0800),ipv4(frag=no), packets:3, > bytes:294, used:0.737s, actions:dec_ttl,2 > > Regards, > Bindiya > ___ > discuss mailing list > disc...@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
[ovs-discuss] Query on DEC_ttl action implementation in datapath
hi , I have a question related to dec_ttl action implemented in datapath. when dec_ttl action is configured in OVS following action get added in datapath. recirc_id(0),in_port(2),eth(),eth_type(0x0800),ipv4(ttl=64,frag=no), packets:3, bytes:294, used:0.068s, actions:set(ipv4(ttl=63)),3, if packet comes with different TTL on same port then one more action get added in datapath. for ex: recirc_id(0),in_port(2),eth(),eth_type(0x0800),ipv4(ttl=9,frag=no), packets:3, bytes:294, used:0.068s, actions:set(ipv4(ttl=8)),3, Could someone please explain why dec_ttl is implemeted as a set action rather than dec_ttl action. I mean , why for different ttl one more rule get added rather than just adding it as following as done in userspace recirc_id(0),in_port(3),eth(),eth_type(0x0800),ipv4(frag=no), packets:3, bytes:294, used:0.737s, actions:dec_ttl,2 Regards, Bindiya ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
[ovs-discuss] Query regarding adding queue on port in OpenFlow switch
Hi, Is there any way to play with the size of the queue that we can inplement on the port of the OpenFlow switch by given command. Because in the given command we are not specifying the size of queue buffer. ovs-vsctl -- set port eth0 qos=@newqos -- --id=@newqos create qos type=linux-htb other-config:max-rate=100 queues:0=@newqueue -- --id=@newqueue create queue other-config:min-rate=100 other-config:max-rate=100 It may be a stupid question also but if it is please help me to understand the right concept. Thanks and regards Tanmay Jain ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Query regarding packet_in reason sent from OvS for “Table-miss” rule.
On Tue, Apr 24, 2018 at 04:48:19AM +, Rohith Basavaraja wrote: > Hi, > > Currently in OvS if we hit "Table-miss" rules (associated with Controller > action) then we send > PACKET_IN message to controller with reason as OFPR_NO_MATCH. > > “Table-miss” rule is one whose priority is 0 and its catch all rule. > > But if we hit same "Table-miss" rule after executing group entry we will send > the reason as > OFPR_ACTION (for OF1.3 and below) and OFPR_GROUP (for OF1.4 and above). > > This is because once we execute group entry we set ctx->in_group and later > when we hit the > "Table-miss" rule, Since ctx->in_group is set we send reason as OFPR_ACTION > (for OF1.3) and > OFPR_GROUP (for OF1.4 and above). > > Since in the packet_in message we are sending the table-id of the > corresponding “Table-miss” rule > Shouldn’t we send the reason for packet-in as OFPR_NO_MATCH ( the reason > appropriate to the > Corresponding rule?) > > For eg: for the following pipeline we will send the reason as OFPR_ACTION > even if we hit > The “Table-miss” rule. > > cookie=0x800, duration=761.189s, table=0, n_packets=1401, n_bytes=67954, > priority=4,in_port=9,vlan_tci=0x/0x1fff > actions=write_metadata:0x678700/0xff01,goto_table:17 > > cookie=0x681, duration=768.848s, table=17, n_packets=1418, n_bytes=68776, > priority=10,metadata=0x678700/0xff00 > actions=write_metadata:0xe0678700/0xfffe,goto_table:60 > > cookie=0x680, duration=24944.312s, table=60, n_packets=58244, > n_bytes=2519520, priority=0 actions=resubmit(,17) > cookie=0x804, duration=785.733s, table=17, n_packets=1450, n_bytes=69724, > priority=10,metadata=0xe0678700/0xff00 > actions=write_metadata:0x67871d4d00/0xfffe,goto_table:43 > > cookie=0x822002d, duration=24960.795s, table=43, n_packets=53097, > n_bytes=2230074, priority=100,arp,arp_op=1 actions=group:6000 > group_id=6000,type=all,bucket=actions=CONTROLLER:65535,bucket=actions=resubmit(,48),bucket=actions=resubmit(,81) > > cookie=0x850, duration=24977.323s, table=48, n_packets=58309, > n_bytes=2522634, priority=0 actions=resubmit(,49),resubmit(,50) > > cookie=0x805, duration=24984.679s, table=50, n_packets=6, n_bytes=264, > priority=0 > actions=CONTROLLER:65535,learn(table=49,hard_timeout=10,priority=0,cookie=0x860,NXM_OF_ETH_SRC[],load:0x1->NXM_NX_REG4[0..7]),goto_table:51 > (Note that Table50 entry is a “Table-miss” rule). > > Currently we are sending table_id as 50 and packet_in reason as OFPR_ACTION. > Shouldn’t we send packet_in reason as OFPR_NO_MATCH in this case? This seems like a reasonable argument. Would you mind submitting a patch (and including a test)? Thanks, Ben. ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
[ovs-discuss] Query regarding packet_in reason sent from OvS for “Table-miss” rule.
Hi, Currently in OvS if we hit "Table-miss" rules (associated with Controller action) then we send PACKET_IN message to controller with reason as OFPR_NO_MATCH. “Table-miss” rule is one whose priority is 0 and its catch all rule. But if we hit same "Table-miss" rule after executing group entry we will send the reason as OFPR_ACTION (for OF1.3 and below) and OFPR_GROUP (for OF1.4 and above). This is because once we execute group entry we set ctx->in_group and later when we hit the "Table-miss" rule, Since ctx->in_group is set we send reason as OFPR_ACTION (for OF1.3) and OFPR_GROUP (for OF1.4 and above). Since in the packet_in message we are sending the table-id of the corresponding “Table-miss” rule Shouldn’t we send the reason for packet-in as OFPR_NO_MATCH ( the reason appropriate to the Corresponding rule?) For eg: for the following pipeline we will send the reason as OFPR_ACTION even if we hit The “Table-miss” rule. cookie=0x800, duration=761.189s, table=0, n_packets=1401, n_bytes=67954, priority=4,in_port=9,vlan_tci=0x/0x1fff actions=write_metadata:0x678700/0xff01,goto_table:17 cookie=0x681, duration=768.848s, table=17, n_packets=1418, n_bytes=68776, priority=10,metadata=0x678700/0xff00 actions=write_metadata:0xe0678700/0xfffe,goto_table:60 cookie=0x680, duration=24944.312s, table=60, n_packets=58244, n_bytes=2519520, priority=0 actions=resubmit(,17) cookie=0x804, duration=785.733s, table=17, n_packets=1450, n_bytes=69724, priority=10,metadata=0xe0678700/0xff00 actions=write_metadata:0x67871d4d00/0xfffe,goto_table:43 cookie=0x822002d, duration=24960.795s, table=43, n_packets=53097, n_bytes=2230074, priority=100,arp,arp_op=1 actions=group:6000 group_id=6000,type=all,bucket=actions=CONTROLLER:65535,bucket=actions=resubmit(,48),bucket=actions=resubmit(,81) cookie=0x850, duration=24977.323s, table=48, n_packets=58309, n_bytes=2522634, priority=0 actions=resubmit(,49),resubmit(,50) cookie=0x805, duration=24984.679s, table=50, n_packets=6, n_bytes=264, priority=0 actions=CONTROLLER:65535,learn(table=49,hard_timeout=10,priority=0,cookie=0x860,NXM_OF_ETH_SRC[],load:0x1->NXM_NX_REG4[0..7]),goto_table:51 (Note that Table50 entry is a “Table-miss” rule). Currently we are sending table_id as 50 and packet_in reason as OFPR_ACTION. Shouldn’t we send packet_in reason as OFPR_NO_MATCH in this case? Thanks Rohith ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
