[ovs-dev] 邮件系统备案提醒

[postmaster]

这是一封 HTML 格式的邮件，请以网页方式查看邮件。

CACESA 
En Constante Movimiento

Este mensaje y cualquier documento adjunto va dirigido a su destinatario y 
puede contener información privada y confidencial.  
Si usted no es el destinatario del presente mensaje no está autorizado a 
leerlo, retenerlo o difundirlo.

This message and any attachments to it is intended for its addressee and may 
contain information that is private and confidential. 
Any reading, retention, distribution or copy of this communication by any 
person other than its intended recipient is prohibited.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] This is urgent, please!

[lester . larry]

9167

Hello!

Although you might be apprehensive about my email, since we have not met 
before, I am Lester Larry. I am lawyer to Saif al-Islam Gaddafi, son of late 
Colonel Muammar Gaddafi - former Libyan President. I met Dr. Saif al-Islam 
Gaddafi in 2008, when he was awarded a PhD by the London School of Economics.

There is the sum of 491, 450, 000.00 euros in an account tied to my client's 
name. However, there have been no beneficiaries stated concerning these funds, 
the implication of which is that no one would ever come forward to claim it. 
This is because my client is presently distressed in his country. What makes 
these funds 100% safe is because they were lodged in a London-based bank 
through the Gaddafi International Charity and Development Foundation.

Consequently, I propose that you and I work together to transfer the funds out 
of the bank into an account in a bank you deem appropriate. I will be delighted 
to enlist your co-operation on this project. Once the fund has been transferred 
to your nominated bank account, we shall then split in the ratio of 70 per cent 
for me, and 30 per cent for you, bearing in mind
that your role in this transaction is critical. Please, note that ANY 'Estate 
or Inheritance Tax' in your country will be footed from my end.

In the event that you are interested in this proposal, feel free to email me at 
lester.la...@outlook.com for detailed work plan.

Please, note that this transaction needs to be effected as quickly as possible, 
and that is apparently because time is of the essence.

For the purpose of emphasis, this transaction is 100% safe. However, I need to 
be certain you are trustworthy, please!

Best regards,

Lester Larry
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [ovs-discuss] ovn: unsnat handling error for Distributed Gateway

[Mickey Spiegel]

On Thu, Apr 6, 2017 at 7:34 AM, Guoshuai Li  wrote:

>
> revese my topology:
>
>  +-++
>  |  VM  172.16.1.7  |
>  +-++
>|
>  +-++
>  |  Logical Switch  |
>  +-++
>|172.16.1.254
>   10.157.142.3 +---++
>   ++  Logical Router 1  +
>   |++
> +-++
> |  Logical Switch  |
> +--+
>   |++
>   ++  Logical Router 2  |
>   10.157.142.1 ++
>
>
> Hi All, I am having a problem for ovn and need help, thanks.
>>
>>
>> I created two logical routes and connected the two LogicalRoutes through
>> a external LogicalSwitch (connected to the external network) .
>>
>> And then LogicalRoute-1 connected to the VM through the internal
>> LogicalSwitch .
>>
>> my topology:
>>
>>   10.157.142.3  172.16.1.254
>>++ +-++
>>+-++
>>   ++  Logical Router 1 +--|
>> Logical Switch  +---+ VM 172.16.1.7   |
>>   |++ +--+
>>+--+
>> +-++
>> |  Logical Switch  |
>> +--+
>>   |++
>>   ++  Logical Router 2  |
>>++
>>   10.157.142.1
>>
>> I tested the master and Branch2.7, it Can not be transferred from VM
>> (172.16.1.7) to LogicaRouter-2 's port (10.157.142.
>>
> Sorry, The destination address is 10.157.142.1, And The SNAT/unSNAT
> address is 10.157.142.3.
>
>> ) via ping.
>> My logical router is a distributed gateway, and the two logical router
>> ports that connect external LogicalSwitch are on the same chassis.
>> If the two logical router ports are not on the same chassis ping is also
>> OK, And ping from VM (172.16.1.7) to external network is also OK.
>>
>> I looked at the openflow tables on gateway chassis,  I suspected unsnat
>> handling error in Router1 input for icmp replay.
>> I think it is necessary to replace the destination address 10.157.142.3
>> with 172.16.1.7 in Table 19 and route 172.16.1.7 in Table 21, but now the
>> route match is 10.157.142.0/24.
>>
>> cookie=0x92bd0055, duration=68.468s, table=16, n_packets=1, n_bytes=98,
>> idle_age=36, priority=50,reg14=0x4,metadata=0x7,dl_dst=fa:16:3e:58:1c:8a
>> actions=resubmit(,17)
>> cookie=0x45765344, duration=68.467s, table=17, n_packets=1, n_bytes=98,
>> idle_age=36, priority=0,metadata=0x7 actions=resubmit(,18)
>> cookie=0xaeaaed29, duration=68.479s, table=18, n_packets=1, n_bytes=98,
>> idle_age=36, priority=0,metadata=0x7 actions=resubmit(,19)
>> cookie=0xce785d51, duration=68.479s, table=19, n_packets=1, n_bytes=98,
>> idle_age=36, priority=100,ip,reg14=0x4,metadata=0x7,nw_dst=10.157.142.3
>> actions=ct(table=20,zone=NXM_NX_REG12[0..15],nat)
>> cookie=0xbd994421, duration=68.481s, table=20, n_packets=1, n_bytes=98,
>> idle_age=36, priority=0,metadata=0x7 actions=resubmit(,21)
>> cookie=0xaea3a6ae, duration=68.479s, table=21, n_packets=1, n_bytes=98,
>> idle_age=36, priority=49,ip,metadata=0x7,nw_dst=10.157.142.0/24
>> actions=dec_ttl(),move:NXM_OF_IP_DST[]->NXM_NX_XXREG0[96..12
>> 7],load:0xa9d8e03->NXM_NX_XXREG0[64..95],mod_dl_src:fa:16:
>> 3e:58:1c:8a,load:0x4->NXM_NX_REG15[],load:0x1->NXM_NX_REG10
>> [0],resubmit(,22)
>> cookie=0xce6e8d4e, duration=68.482s, table=22, n_packets=1, n_bytes=98,
>> idle_age=36, priority=0,ip,metadata=0x7 actions=push:NXM_NX_REG0[],pus
>> h:NXM_NX_XXREG0[96..127],pop:NXM_NX_REG0[],mod_dl_dst:00:
>> 00:00:00:00:00,resubmit(,66),pop:NXM_NX_REG0[],resubmit(,23)
>> cookie=0xce89c4ed, duration=68.481s, table=23, n_packets=1, n_bytes=98,
>> idle_age=36, priority=150,reg15=0x4,metadata=0x7,dl_dst=00:00:00:00:00:00
>> actions=load:0x5->NXM_NX_REG15[],resubmit(,24)
>> cookie=0xb2d84350, duration=68.469s, table=24, n_packets=1, n_bytes=98,
>> idle_age=36, priority=100,ip,metadata=0x7,dl_dst=00:00:00:00:00:00
>>
>> I do not know why and need help, thanks.
>>
>
I was able to reproduce this. I agree with your analysis. Looking at
ovs-ofctl dump-flows, the packet counts indicate that the packet is subject
to ct(...,nat), but the routing table match is as if NAT never occurred.

I tried with gateway routers and it worked. There are some differences in
ovs-dpctl dump-flows.

For the case of gateway routers:

vagrant@compute2:~$ sudo ovs-dpctl dump-flows