Hi Ilya,
Thanks for the quick response.
> In your case, you need a route for 192.168.1.20/24 (?)
> via br-phy, IIUC. See the 'Tunneling-related Commands' section in [0].
>
I tried to add that route but it fails -
$ ovs-appctl ovs/route/add 192.168.1.20/24 br-phy
Error while inserting route.
ovs-appctl: ovs-vswitchd: server returned an error
My guess is it's failing in *ovs_router_insert__()* because
*ovs_router_get_netdev_source_address()
*fails because br-phy doesn't have any associated IP. Is there a way to
avoid depending on the bridge or bridge port IP for tunneling and take the
source IP from the flow rules directly? The reason is that I don't want to
expose the vxlan IPs to the host kernel.
Thanks, Krishna
Note: My topology from [0]
+--------------+| vm0 | 10.10.10.10/24+--------------+
(vm_port0)
|
|
|+--------------+| br-int |
10.10.10.20/24
+--------------+ +--------------+|
vxlan0 | | vxlan0
|+--------------+ +--------------+
| tnl | tnl
| *tun_src=192.168.1.10,tun_dst=192.168.1.20*
| *tun_src=192.168.1.20,tun_dst=192.168.1.10*
| No IP on br-phy
|+--------------+ ||
br-phy | |+--------------+
+---------------+| dpdk0/eth1
|----------------------------------| eth1 |+--------------+
+---------------+Host A with OVS.
Remote host.
>> On 8/23/23 22:56, krishna khanal via discuss wrote:
>>* Hello,
*>> >>* I'm following [0] to set up a userspace vxlan tunnel between
two hosts and it works as expected. But, one of the requirements I
have is not to have any IP assigned to physical bridge (br-phy) but
use the flows to pick up the source IP. I've configured the bridges as
shown in [1] and added the flow rule as shown in [2].
*>> >>* VM is attached to br-int and has an IP 10.10.10.10 assigned to
it. My expectation is when the packet comes to br-int through br-int
internal interface, the packet is encapsulated using the flow keys and
use the local_ip or tun_src as the source IP but when we try to output
the packet to native tunnel, the source IP lookup fails and the packet
is dropped as shown in [3].
*>
> When the output action is executed, the packet is leaving the
> current bridge. So, when it gets encapsulated it has to be
> routed to one of the bridges based on the destination IP address
>for further processing.
>
> >>* Is there a way to make this work without assigning ip to br-phy? Can the
> >>routing after vxlan pick up the source IP from the configured rule and not
> >>depend on the system configured IP?
*>
> OVS is using kernel routing configuration for convenience reasons.
> You may add routes directly to OVS via 'ovs-appctl ovs/route/add'
> command. In your case, you need a route for 192.168.1.20/24 (?)
> via br-phy, IIUC. See the 'Tunneling-related Commands' section in [0].
>
> Note, however, that this route will only be stored in memory, so
> you will need to re-add it back on OVS restart.
>
> Best regards, Ilya Maximets.
>
> >>* *[0]*
*>>* https://docs.openvswitch.org/en/latest/howto/userspace-tunneling/
<https://docs.openvswitch.org/en/latest/howto/userspace-tunneling/>
<https://docs.openvswitch.org/en/latest/howto/userspace-tunneling/
<https://docs.openvswitch.org/en/latest/howto/userspace-tunneling/>>
*>> >>* *[1]*
*>* sudo ovs-vsctl show
*>* bf7d9abd-7275-4a22-9f80-7733bda04cc2
*>* Bridge br-phy
*>* datapath_type: netdev
*>* Port br-phy
*>* Interface br-phy
*>* type: internal
*>* Port eth1
*>* Interface eth1
*>* Bridge br-int
*>* datapath_type: netdev
*>* Port br-int
*>* Interface br-int
*>* type: internal
*>* Port vxlan
*>* Interface vxlan
*>* type: vxlan
*>* options: {key=flow, local_ip="192.168.1.10", remote_ip=flow}
*> >* *[2]*
*>* ovs-ofctl add-flow br-int \
*>* 'in_port=br-int
actions=set_tunnel:5001,set_field:192.168.1.20->tun_dst,set_field:192.168.1.10->tun_src,output:vxlan'
*> >* *[3]*
*>* ovs-appctl ofproto/trace br-int in_port=br-int
*>* Flow:
in_port=LOCAL,vlan_tci=0x0000,dl_src=00:00:00:00:00:00,dl_dst=00:00:00:00:00:00,dl_type=0x0000
*> >* bridge("br-int")
*>* ----------------
*>* 0. in_port=LOCAL, priority 32768
*>* set_tunnel:0x1389
*>* load:0xc0a80114->NXM_NX_TUN_IPV4_DST[]
*>* load:0xc0a8010a->NXM_NX_TUN_IPV4_SRC[]
*>* output:3
*>* -> output to native tunnel
*>* * >> native tunnel routing failed
*>* *
*>* Final flow:
tun_src=192.168.1.10,tun_dst=192.168.1.20,tun_ipv6_src=::,tun_ipv6_dst=::,tun_gbp_id=0,tun_gbp_flags=0,tun_tos=0,tun_ttl=0,tun_erspan_ver=0,gtpu_flags=0,gtpu_msgtype=0,tun_flags=0,in_port=LOCAL,vlan_tci=0x0000,dl_src=00:00:00:00:00:00,dl_dst=00:00:00:00:00:00,dl_type=0x0000
*>* Megaflow: recirc_id=0,eth,in_port=LOCAL,dl_type=0x0000
*>* *Datapath actions: drop*
*>* *
*>* *
*>* -Krishna*
_______________________________________________
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
