Re: [ovs-discuss] OVS setup on Winodws

[Alin Serdean via discuss]

Hi,The issue you are facing might be because the name of the network adapters is the same.I wanted to emphasize the importance of the following step: https://docs.openvswitch.org/en/latest/intro/install/windows/#add-virtual-interfaces-vifsThis is something particularly important for Windows and not the same under other OS.Alin.Sent from phone On 17 Apr 2023, at 20:33, Abu Rasheda via discuss  wrote:Do you have any ideas, or if this is the wrong list, the recommendation for another one?On Thu, Apr 13, 2023 at 7:14 PM Abu Rasheda via discuss  wrote:Hello!

On Windows Server 2019, compiled, and loaded OVS kernel module.
Commands like ovs-vsctl & ovs-dpctl are running fine.

I have two VMs (both running Ubuntu) under Hyper-V and have OVS
extended switch setup as described in
https://docs.openvswitch.org/en/latest/intro/install/windows/

I can connect one Ubuntu VM to the OVS switch, under the "Network
Adaptor" setting for the virtual machine. When I try to ping an IP
address get prints from the OVS datapath in the kernel! This led me to
believe that OVS is installed and configured (I am from a Linux
background and Windows is new for me :)).

However, when I try to add another Ubuntu VM to the OVS switch, I get
the following error:

Synthetic Ethernet Port (Instance ID ..): Error '{Data Not Accepted}
The TDI client could not handle the data received during an
indication.'

Failed to allocate resources while connecting to a virtual network.
The Ethernet switch may not exit.

Can OVS Extended switch only connect to a single VM? (on the same host),

I can connect these two machines to Windows virtual switch and ping
them. So either my setup has issues for OVS or there is a limitation
on OVS.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

___discuss mailing listdisc...@openvswitch.orghttps://mail.openvswitch.org/mailman/listinfo/ovs-discuss___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVS setup on Winodws

[Abu Rasheda via discuss]

Thanks! Let me try this.

On Mon, Apr 17, 2023 at 1:44 PM Alin Serdean  wrote:

> Hi,
>
> The issue you are facing might be because the name of the network adapters
> is the same.
>
> I wanted to emphasize the importance of the following step:
> https://docs.openvswitch.org/en/latest/intro/install/windows/#add-virtual-interfaces-vifs
>
> This is something particularly important for Windows and not the same
> under other OS.
>
> Alin.
>
> Sent from phone
>
> On 17 Apr 2023, at 20:33, Abu Rasheda via discuss <
> ovs-discuss@openvswitch.org> wrote:
>
> 
> Do you have any ideas, or if this is the wrong list, the recommendation
> for another one?
>
> On Thu, Apr 13, 2023 at 7:14 PM Abu Rasheda via discuss <
> ovs-discuss@openvswitch.org> wrote:
>
>> Hello!
>>
>> On Windows Server 2019, compiled, and loaded OVS kernel module.
>> Commands like ovs-vsctl & ovs-dpctl are running fine.
>>
>> I have two VMs (both running Ubuntu) under Hyper-V and have OVS
>> extended switch setup as described in
>> https://docs.openvswitch.org/en/latest/intro/install/windows/
>>
>> I can connect one Ubuntu VM to the OVS switch, under the "Network
>> Adaptor" setting for the virtual machine. When I try to ping an IP
>> address get prints from the OVS datapath in the kernel! This led me to
>> believe that OVS is installed and configured (I am from a Linux
>> background and Windows is new for me :)).
>>
>> However, when I try to add another Ubuntu VM to the OVS switch, I get
>> the following error:
>>
>> Synthetic Ethernet Port (Instance ID ..): Error '{Data Not Accepted}
>> The TDI client could not handle the data received during an
>> indication.'
>>
>> Failed to allocate resources while connecting to a virtual network.
>> The Ethernet switch may not exit.
>>
>> Can OVS Extended switch only connect to a single VM? (on the same host),
>>
>> I can connect these two machines to Windows virtual switch and ping
>> them. So either my setup has issues for OVS or there is a limitation
>> on OVS.
>> ___
>> 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
>
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVS setup on Winodws

[Abu Rasheda via discuss]

Do you have any ideas, or if this is the wrong list, the recommendation for
another one?

On Thu, Apr 13, 2023 at 7:14 PM Abu Rasheda via discuss <
ovs-discuss@openvswitch.org> wrote:

> Hello!
>
> On Windows Server 2019, compiled, and loaded OVS kernel module.
> Commands like ovs-vsctl & ovs-dpctl are running fine.
>
> I have two VMs (both running Ubuntu) under Hyper-V and have OVS
> extended switch setup as described in
> https://docs.openvswitch.org/en/latest/intro/install/windows/
>
> I can connect one Ubuntu VM to the OVS switch, under the "Network
> Adaptor" setting for the virtual machine. When I try to ping an IP
> address get prints from the OVS datapath in the kernel! This led me to
> believe that OVS is installed and configured (I am from a Linux
> background and Windows is new for me :)).
>
> However, when I try to add another Ubuntu VM to the OVS switch, I get
> the following error:
>
> Synthetic Ethernet Port (Instance ID ..): Error '{Data Not Accepted}
> The TDI client could not handle the data received during an
> indication.'
>
> Failed to allocate resources while connecting to a virtual network.
> The Ethernet switch may not exit.
>
> Can OVS Extended switch only connect to a single VM? (on the same host),
>
> I can connect these two machines to Windows virtual switch and ping
> them. So either my setup has issues for OVS or there is a limitation
> on OVS.
> ___
> 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] Packet duplication when using OVS+DPDK

[Ali Shirvani via discuss]

Hello everyone,

We set up the openvswitch-switch-dpdk on a Debian server with Intel XL710
NIC.

We have bind the XL710 NIC to the vfio-pci driver via following command:

dpdk-devbind.py --bind=vfio-pci eth0

We created an OVS switch named br0 with netdev datapath and added the eth0
to the bridge and assigned an IP address to the br0, but when we ping that
IP address we got DUP in the reports.

Would you please guide me how I should find the solution? I've read the
following links but could not find any solution.

https://docs.openvswitch.org/en/latest/intro/install/dpdk/
https://docs.openvswitch.org/en/latest/faq/issues/

Best regards,
Ali
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Hardware compatibility

[Justas Poderys via discuss]

I would definitely recommend the Napatech LinkVirtualization SmartNICs. Works 
great with OvS-DPDK w/ rte_flow and are lightning fast (line rate @ 64B 
packets).

Best regards,

Justas Poderys, PhD
Product Architect



Napatech A/S
Tobaksvejen 23 A
DK-2860 Soeborg
Denmark

-Original Message-
From: discuss  On Behalf Of Tom Jay via 
discuss
Sent: 10. april 2023 14:52
To: ovs-discuss@openvswitch.org
Subject: [ovs-discuss] Hardware compatibility

Hi,

I'm interested in trying OVS and would like to try the hardware features 
(hardware offloading). Is there a list of hardware that OVS is compatible with?

Thanks.

Tom


___
discuss mailing list
disc...@openvswitch.org
https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fmail.openvswitch.org%2fmailman%2flistinfo%2fovs-discuss=E,1,X2jhbGU9zDNuTDpWGxtgtMtRnUVDAmMgQe4I3OzlDIUPFG9a0WnqPty8irY1DY0VweSxeRNqdwn1Al1UrKKTADGtU8Q30H3oZ8fQYqY1Y5e4lBvXKMqzB2iL=1
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] ovs-vswitchd crashes serveral times a day

[Paolo Valerio via discuss]

"Plato, Michael"  writes:

> Hi Paolo,
> I installed the patch for 2.17 on april 6th in our test environment and can 
> confirm that it works. We haven't had any crashes since then. Many thanks for 
> the quick solution!
>

Hi Micheal,

Nice! That's helpful. Thanks for testing it.

Paolo

> Best regards
>
> Michael
>
> -Ursprüngliche Nachricht-
> Von: Paolo Valerio  
> Gesendet: Montag, 17. April 2023 10:36
> An: Lazuardi Nasution 
> Cc: ovs-discuss@openvswitch.org; Plato, Michael 
> Betreff: Re: Re: [ovs-discuss] ovs-vswitchd crashes serveral times a day
>
> Lazuardi Nasution  writes:
>
>> Hi Paolo,
>>
>> I'm interested in your statement of "expired connections (but not yet 
>> reclaimed)". Do you think that shortening conntrack timeout policy will help?
>> Or, should we make it larger so there will be fewer conntrack table 
>> update and flush attempts?
>>
>
> it's hard to say as it depends on the specific use case.
> Probably making it larger for the specific case could help, but in general, I 
> would not rely on that.
> Of course, an actual fix is needed. It would be great if the patch sent could 
> tested, but in any case, I'll work on a formal patch.
>
>> Best regards.
>>
>> On Wed, Apr 5, 2023 at 2:51 AM Paolo Valerio  wrote:
>>
>> Hello,
>>
>> thanks for reporting this.
>> I had a look at it, and, although this needs to be confirmed, I suspect
>> it's related to nat (CT_CONN_TYPE_UN_NAT) and expired connections (but
>> not yet reclaimed).
>>
>> The nat part does not necessarily perform any actual translation, but
>> could still be triggered by ct(nat(src)...) which is the all-zero binding
>> to avoid collisions, if any.
>>
>> Is there any chance to test the following patch (targeted for ovs 2.17)?
>> This should help to confirm.
>>
>> -- >8 --
>> diff --git a/lib/conntrack.c b/lib/conntrack.c
>> index 08da4ddf7..ba334afb0 100644
>> --- a/lib/conntrack.c
>> +++ b/lib/conntrack.c
>> @@ -94,9 +94,8 @@ static bool valid_new(struct dp_packet *pkt, struct
>> conn_key *);
>>  static struct conn *new_conn(struct conntrack *ct, struct dp_packet 
>> *pkt,
>>                               struct conn_key *, long long now,
>>                               uint32_t tp_id);
>> -static void delete_conn_cmn(struct conn *);
>> +static void delete_conn__(struct conn *);
>>  static void delete_conn(struct conn *);
>> -static void delete_conn_one(struct conn *conn);
>>  static enum ct_update_res conn_update(struct conntrack *ct, struct conn
>> *conn,
>>                                        struct dp_packet *pkt,
>>                                        struct conn_lookup_ctx *ctx,
>> @@ -444,14 +443,13 @@ zone_limit_delete(struct conntrack *ct, uint16_t
>> zone)
>>  }
>>
>>  static void
>> -conn_clean_cmn(struct conntrack *ct, struct conn *conn)
>> +conn_clean_cmn(struct conntrack *ct, struct conn *conn, uint32_t hash)
>>      OVS_REQUIRES(ct->ct_lock)
>>  {
>>      if (conn->alg) {
>>          expectation_clean(ct, >key);
>>      }
>>
>> -    uint32_t hash = conn_key_hash(>key, ct->hash_basis);
>>      cmap_remove(>conns, >cm_node, hash);
>>
>>      struct zone_limit *zl = zone_limit_lookup(ct, conn->admit_zone);
>> @@ -467,11 +465,14 @@ conn_clean(struct conntrack *ct, struct conn *conn)
>>      OVS_REQUIRES(ct->ct_lock)
>>  {
>>      ovs_assert(conn->conn_type == CT_CONN_TYPE_DEFAULT);
>> +    uint32_t conn_hash = conn_key_hash(>key, 
>> ct->hash_basis);
>>
>> -    conn_clean_cmn(ct, conn);
>> +    conn_clean_cmn(ct, conn, conn_hash);
>>      if (conn->nat_conn) {
>>          uint32_t hash = conn_key_hash(>nat_conn->key, ct->
>> hash_basis);
>> -        cmap_remove(>conns, >nat_conn->cm_node, hash);
>> +        if (conn_hash != hash) {
>> +            cmap_remove(>conns, >nat_conn->cm_node, hash);
>> +        }
>>      }
>>      ovs_list_remove(>exp_node);
>>      conn->cleaned = true;
>> @@ -479,19 +480,6 @@ conn_clean(struct conntrack *ct, struct conn *conn)
>>      atomic_count_dec(>n_conn);
>>  }
>>
>> -static void
>> -conn_clean_one(struct conntrack *ct, struct conn *conn)
>> -    OVS_REQUIRES(ct->ct_lock)
>> -{
>> -    conn_clean_cmn(ct, conn);
>> -    if (conn->conn_type == CT_CONN_TYPE_DEFAULT) {
>> -        ovs_list_remove(>exp_node);
>> -        conn->cleaned = true;
>> -        atomic_count_dec(>n_conn);
>> -    }
>> -    ovsrcu_postpone(delete_conn_one, conn);
>> -}
>> -
>>  /* Destroys the connection tracker 'ct' and frees all the allocated
>> memory.
>>   * The caller of this function must already have shut down packet input
>>   * and PMD threads (which would have been quiesced).  */
>> @@ -505,7 +493,10 @@ conntrack_destroy(struct conntrack *ct)
>>
>>      

Re: [ovs-discuss] ovs-vswitchd crashes serveral times a day

[Plato, Michael via discuss]

Hi Paolo,
I installed the patch for 2.17 on april 6th in our test environment and can 
confirm that it works. We haven't had any crashes since then. Many thanks for 
the quick solution!

Best regards

Michael

-Ursprüngliche Nachricht-
Von: Paolo Valerio  
Gesendet: Montag, 17. April 2023 10:36
An: Lazuardi Nasution 
Cc: ovs-discuss@openvswitch.org; Plato, Michael 
Betreff: Re: Re: [ovs-discuss] ovs-vswitchd crashes serveral times a day

Lazuardi Nasution  writes:

> Hi Paolo,
>
> I'm interested in your statement of "expired connections (but not yet 
> reclaimed)". Do you think that shortening conntrack timeout policy will help?
> Or, should we make it larger so there will be fewer conntrack table 
> update and flush attempts?
>

it's hard to say as it depends on the specific use case.
Probably making it larger for the specific case could help, but in general, I 
would not rely on that.
Of course, an actual fix is needed. It would be great if the patch sent could 
tested, but in any case, I'll work on a formal patch.

> Best regards.
>
> On Wed, Apr 5, 2023 at 2:51 AM Paolo Valerio  wrote:
>
> Hello,
>
> thanks for reporting this.
> I had a look at it, and, although this needs to be confirmed, I suspect
> it's related to nat (CT_CONN_TYPE_UN_NAT) and expired connections (but
> not yet reclaimed).
>
> The nat part does not necessarily perform any actual translation, but
> could still be triggered by ct(nat(src)...) which is the all-zero binding
> to avoid collisions, if any.
>
> Is there any chance to test the following patch (targeted for ovs 2.17)?
> This should help to confirm.
>
> -- >8 --
> diff --git a/lib/conntrack.c b/lib/conntrack.c
> index 08da4ddf7..ba334afb0 100644
> --- a/lib/conntrack.c
> +++ b/lib/conntrack.c
> @@ -94,9 +94,8 @@ static bool valid_new(struct dp_packet *pkt, struct
> conn_key *);
>  static struct conn *new_conn(struct conntrack *ct, struct dp_packet *pkt,
>                               struct conn_key *, long long now,
>                               uint32_t tp_id);
> -static void delete_conn_cmn(struct conn *);
> +static void delete_conn__(struct conn *);
>  static void delete_conn(struct conn *);
> -static void delete_conn_one(struct conn *conn);
>  static enum ct_update_res conn_update(struct conntrack *ct, struct conn
> *conn,
>                                        struct dp_packet *pkt,
>                                        struct conn_lookup_ctx *ctx,
> @@ -444,14 +443,13 @@ zone_limit_delete(struct conntrack *ct, uint16_t
> zone)
>  }
>
>  static void
> -conn_clean_cmn(struct conntrack *ct, struct conn *conn)
> +conn_clean_cmn(struct conntrack *ct, struct conn *conn, uint32_t hash)
>      OVS_REQUIRES(ct->ct_lock)
>  {
>      if (conn->alg) {
>          expectation_clean(ct, >key);
>      }
>
> -    uint32_t hash = conn_key_hash(>key, ct->hash_basis);
>      cmap_remove(>conns, >cm_node, hash);
>
>      struct zone_limit *zl = zone_limit_lookup(ct, conn->admit_zone);
> @@ -467,11 +465,14 @@ conn_clean(struct conntrack *ct, struct conn *conn)
>      OVS_REQUIRES(ct->ct_lock)
>  {
>      ovs_assert(conn->conn_type == CT_CONN_TYPE_DEFAULT);
> +    uint32_t conn_hash = conn_key_hash(>key, 
> ct->hash_basis);
>
> -    conn_clean_cmn(ct, conn);
> +    conn_clean_cmn(ct, conn, conn_hash);
>      if (conn->nat_conn) {
>          uint32_t hash = conn_key_hash(>nat_conn->key, ct->
> hash_basis);
> -        cmap_remove(>conns, >nat_conn->cm_node, hash);
> +        if (conn_hash != hash) {
> +            cmap_remove(>conns, >nat_conn->cm_node, hash);
> +        }
>      }
>      ovs_list_remove(>exp_node);
>      conn->cleaned = true;
> @@ -479,19 +480,6 @@ conn_clean(struct conntrack *ct, struct conn *conn)
>      atomic_count_dec(>n_conn);
>  }
>
> -static void
> -conn_clean_one(struct conntrack *ct, struct conn *conn)
> -    OVS_REQUIRES(ct->ct_lock)
> -{
> -    conn_clean_cmn(ct, conn);
> -    if (conn->conn_type == CT_CONN_TYPE_DEFAULT) {
> -        ovs_list_remove(>exp_node);
> -        conn->cleaned = true;
> -        atomic_count_dec(>n_conn);
> -    }
> -    ovsrcu_postpone(delete_conn_one, conn);
> -}
> -
>  /* Destroys the connection tracker 'ct' and frees all the allocated
> memory.
>   * The caller of this function must already have shut down packet input
>   * and PMD threads (which would have been quiesced).  */
> @@ -505,7 +493,10 @@ conntrack_destroy(struct conntrack *ct)
>
>      ovs_mutex_lock(>ct_lock);
>      CMAP_FOR_EACH (conn, cm_node, >conns) {
> -        conn_clean_one(ct, conn);
> +        if (conn->conn_type == CT_CONN_TYPE_UN_NAT) {
> +            continue;
> +        }
> +        conn_clean(ct, 

Re: [ovs-discuss] ovs-vswitchd crashes serveral times a day

[Paolo Valerio via discuss]

Lazuardi Nasution  writes:

> Hi Paolo,
>
> I'm interested in your statement of "expired connections (but not yet
> reclaimed)". Do you think that shortening conntrack timeout policy will help?
> Or, should we make it larger so there will be fewer conntrack table update and
> flush attempts?
>

it's hard to say as it depends on the specific use case.
Probably making it larger for the specific case could help, but in
general, I would not rely on that.
Of course, an actual fix is needed. It would be great if the patch sent
could tested, but in any case, I'll work on a formal patch.

> Best regards.
>
> On Wed, Apr 5, 2023 at 2:51 AM Paolo Valerio  wrote:
>
> Hello,
>
> thanks for reporting this.
> I had a look at it, and, although this needs to be confirmed, I suspect
> it's related to nat (CT_CONN_TYPE_UN_NAT) and expired connections (but
> not yet reclaimed).
>
> The nat part does not necessarily perform any actual translation, but
> could still be triggered by ct(nat(src)...) which is the all-zero binding
> to avoid collisions, if any.
>
> Is there any chance to test the following patch (targeted for ovs 2.17)?
> This should help to confirm.
>
> -- >8 --
> diff --git a/lib/conntrack.c b/lib/conntrack.c
> index 08da4ddf7..ba334afb0 100644
> --- a/lib/conntrack.c
> +++ b/lib/conntrack.c
> @@ -94,9 +94,8 @@ static bool valid_new(struct dp_packet *pkt, struct
> conn_key *);
>  static struct conn *new_conn(struct conntrack *ct, struct dp_packet *pkt,
>                               struct conn_key *, long long now,
>                               uint32_t tp_id);
> -static void delete_conn_cmn(struct conn *);
> +static void delete_conn__(struct conn *);
>  static void delete_conn(struct conn *);
> -static void delete_conn_one(struct conn *conn);
>  static enum ct_update_res conn_update(struct conntrack *ct, struct conn
> *conn,
>                                        struct dp_packet *pkt,
>                                        struct conn_lookup_ctx *ctx,
> @@ -444,14 +443,13 @@ zone_limit_delete(struct conntrack *ct, uint16_t
> zone)
>  }
>
>  static void
> -conn_clean_cmn(struct conntrack *ct, struct conn *conn)
> +conn_clean_cmn(struct conntrack *ct, struct conn *conn, uint32_t hash)
>      OVS_REQUIRES(ct->ct_lock)
>  {
>      if (conn->alg) {
>          expectation_clean(ct, >key);
>      }
>
> -    uint32_t hash = conn_key_hash(>key, ct->hash_basis);
>      cmap_remove(>conns, >cm_node, hash);
>
>      struct zone_limit *zl = zone_limit_lookup(ct, conn->admit_zone);
> @@ -467,11 +465,14 @@ conn_clean(struct conntrack *ct, struct conn *conn)
>      OVS_REQUIRES(ct->ct_lock)
>  {
>      ovs_assert(conn->conn_type == CT_CONN_TYPE_DEFAULT);
> +    uint32_t conn_hash = conn_key_hash(>key, ct->hash_basis);
>
> -    conn_clean_cmn(ct, conn);
> +    conn_clean_cmn(ct, conn, conn_hash);
>      if (conn->nat_conn) {
>          uint32_t hash = conn_key_hash(>nat_conn->key, ct->
> hash_basis);
> -        cmap_remove(>conns, >nat_conn->cm_node, hash);
> +        if (conn_hash != hash) {
> +            cmap_remove(>conns, >nat_conn->cm_node, hash);
> +        }
>      }
>      ovs_list_remove(>exp_node);
>      conn->cleaned = true;
> @@ -479,19 +480,6 @@ conn_clean(struct conntrack *ct, struct conn *conn)
>      atomic_count_dec(>n_conn);
>  }
>
> -static void
> -conn_clean_one(struct conntrack *ct, struct conn *conn)
> -    OVS_REQUIRES(ct->ct_lock)
> -{
> -    conn_clean_cmn(ct, conn);
> -    if (conn->conn_type == CT_CONN_TYPE_DEFAULT) {
> -        ovs_list_remove(>exp_node);
> -        conn->cleaned = true;
> -        atomic_count_dec(>n_conn);
> -    }
> -    ovsrcu_postpone(delete_conn_one, conn);
> -}
> -
>  /* Destroys the connection tracker 'ct' and frees all the allocated
> memory.
>   * The caller of this function must already have shut down packet input
>   * and PMD threads (which would have been quiesced).  */
> @@ -505,7 +493,10 @@ conntrack_destroy(struct conntrack *ct)
>
>      ovs_mutex_lock(>ct_lock);
>      CMAP_FOR_EACH (conn, cm_node, >conns) {
> -        conn_clean_one(ct, conn);
> +        if (conn->conn_type == CT_CONN_TYPE_UN_NAT) {
> +            continue;
> +        }
> +        conn_clean(ct, conn);
>      }
>      cmap_destroy(>conns);
>
> @@ -1052,7 +1043,10 @@ conn_not_found(struct conntrack *ct, struct
> dp_packet *pkt,
>              nat_conn->alg = NULL;
>              nat_conn->nat_conn = NULL;
>              uint32_t nat_hash = conn_key_hash(_conn->key, ct->
> hash_basis);
> -            cmap_insert(>conns, _conn->cm_node, nat_hash);
> +
> +            if (nat_hash != ctx->hash) {
> +