You are correct, I will fix BFD config in v3.
For the overlay BFD packet, we don't set up a port to handle packets
targeted at 192.168.10.105. So ovs simply drops them.
On Wed, Jul 22, 2020 at 11:26 AM William Tu wrote:
> On Wed, Jul 22, 2020 at 11:02:32AM -0700, Yifeng Sun wrote:
> > Thanks
On Wed, Jul 22, 2020 at 11:02:32AM -0700, Yifeng Sun wrote:
> Thanks for reviewing.
>
> For these two packets:
>
> dnl outer IP: Source: 172.16.180.105 Destination: 172.16.180.106
> This one is normal BFD packet, bfd_should_process_flow should return
> true, as used to.
>
> dnl inner IP:
Please discard my previous email, I misunderstood your question.
The packet above is
dnl outer IP: Source: 172.16.180.105 Destination: 172.16.180.106
dnl inner IP: Source: 192.168.10.104 Destination: 192.168.10.105
So the bfd_should_process_flow returns false.
Yes, you are correct and
Thanks for reviewing.
For these two packets:
dnl outer IP: Source: 172.16.180.105 Destination: 172.16.180.106
This one is normal BFD packet, bfd_should_process_flow should return
true, as used to.
dnl inner IP: Source: 192.168.10.104 Destination: 192.168.10.105
This one is overlay BFD
On Wed, Jul 22, 2020 at 01:59:04AM -0700, Yifeng Sun wrote:
> Current OVS intercepts and processes all BFD packets, thus VM-2-VM
> BFD packets get lost and the recipient VM never sees them.
>
> This patch fixes it by only intercepting and processing BFD packets
> destined to a configured BFD
On Wed, Jul 22, 2020 at 01:59:04AM -0700, Yifeng Sun wrote:
> Current OVS intercepts and processes all BFD packets, thus VM-2-VM
> BFD packets get lost and the recipient VM never sees them.
>
> This patch fixes it by only intercepting and processing BFD packets
> destined to a configured BFD
Current OVS intercepts and processes all BFD packets, thus VM-2-VM
BFD packets get lost and the recipient VM never sees them.
This patch fixes it by only intercepting and processing BFD packets
destined to a configured BFD instance, and other BFD packets are made
available to the OVS flow table
