ovn-bgp-agent

Bug #2052485
Comment #4

Comment 4 for bug 2052485

Revision history for this message

Andy Litzinger (alitzinger) wrote on 2024-02-06:

Hi eduardo,
thank you for your reply.
>We cover some cases like this on our downstream environments and they don't fail.
awesome, I will try and look and see if I can understand how the tests are configured

>I am wondering if the problem in your setup is the existence of any route to the public subnet 172.24.4.0/24 on the computes.

Do you wonder if such a route exists and it's next hop isn't the upstream switch? No, there is not. As long as any route that existed does point properly to the upstream switch then that would still accomplish the same result as following the default route to the upstream switch, right? Or am I missing something that would explain why it has to be a default route and not a more specific route?

>In my case, the public subnet is 172.16.100.0/24. One of the VMs sends a ping to another one. That ping >goes through this path when it leaves the source compute:
>- tap interface (src and dest MACs correspond with the src and dest VM MAC addresses)
I observe the same at my tap interfaces. I am a little confused as to how my two vms on separate nodes have learned the proper mac addresses for each other, but don't have connectivity. What responded to their respective arp requests? I managed to capture an arp request on the tap interface and it looked like the two vms were happily L2 adjacent- the 2nd vm responded to the arp:
22:52:05.554413 fa:16:3e:26:77:6a > fa:16:3e:dd:6b:48, ethertype ARP (0x0806), length 42: Request who-has 172.24.4.56 tell 172.24.4.93, length 28
22:52:05.554773 fa:16:3e:dd:6b:48 > fa:16:3e:26:77:6a, ethertype ARP (0x0806), length 42: Reply 172.24.4.56 is-at fa:16:3e:dd:6b:48, length 28

>- br-ex (dest MAC modified to br-ex MAC due to br-ex flows)
Can you explain why/how this happens? How can I validate the mac rewrite? Does br-ex perform some kind of source NAT on the packet too? Otherwise I'm really struggling to understand how routing even comes into play. You route when the src and dst IP are on different subnets. If they are on the same subnet, you bridge. But I suppose there could be some ovn/ovs magic here that causes br-ex to re-write only the mac addrs and still hand off the packet to the kernel. And perhaps the Linux kernel routing consults it's routing table for this flow despite the fact that it should be an bridged flow?

I will describe my set up in more detail in another comment shortly.

Hi eduardo,
  thank you for your reply.
>We cover some cases like this on our downstream environments and they don't fail.
awesome, I will try and look and see if I can understand how the tests are configured

>I am wondering if the problem in your setup is the existence of any route to the public subnet 172.24.4.0/24 on the computes.

Do you wonder if such a route exists and it's next hop isn't the upstream switch? No, there is not.  As long as any route that existed does point properly to the upstream switch then that would still accomplish the same result as following the default route to the upstream switch, right?  Or am I missing something that would explain why it has to be a default route and not a more specific route?

>In my case, the public subnet is 172.16.100.0/24. One of the VMs sends a ping to another one. That ping >goes through this path when it leaves the source compute:
>- tap interface (src and dest MACs correspond with the src and dest VM MAC addresses)
I observe the same at my tap interfaces.  I am a little confused as to how my two vms on separate nodes have learned the proper mac addresses for each other, but don't have connectivity.  What responded to their respective arp requests?  I managed to capture an arp request on the tap interface and it looked like the two vms were happily L2 adjacent- the 2nd vm responded to the arp:
22:52:05.554413 fa:16:3e:26:77:6a > fa:16:3e:dd:6b:48, ethertype ARP (0x0806), length 42: Request who-has 172.24.4.56 tell 172.24.4.93, length 28
22:52:05.554773 fa:16:3e:dd:6b:48 > fa:16:3e:26:77:6a, ethertype ARP (0x0806), length 42: Reply 172.24.4.56 is-at fa:16:3e:dd:6b:48, length 28

>- br-ex (dest MAC modified to br-ex MAC due to br-ex flows)
Can you explain why/how this happens?  How can I validate the mac rewrite?  Does br-ex perform some kind of source NAT on the packet too?  Otherwise I'm really struggling to understand how routing even comes into play. You route when the src and dst IP are on different subnets. If they are on the same subnet, you bridge. But I suppose there could be some ovn/ovs magic here that causes br-ex to re-write only the mac addrs and still hand off the packet to the kernel. And perhaps the Linux kernel routing consults it's routing table for this flow despite the fact that it should be an bridged flow?

I will describe my set up in more detail in another comment shortly.