On the x86 host you have a routing table which will fail:
Destination Passerelle Genmask Indic Metric Ref Use Iface
0.0.0.0 192.168.0.1 0.0.0.0 UG 100 0 0 eno1
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eno1
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.0.0 0.0.0.0 255.255.255.0 U 100 0 0 eno1
Notice that both eth0 and eno1 cover the entire subnet. The only difference is that eno1 will never get used unless eth0 fails. The “metric” describes priorities, and a higher metric implies a higher cost. eno0 will never see a packet (other than setting up DHCP and/or route) since it has a higher metric.
What I will suggest is that on the host you use something like “nm-connection-editor” (if you don’t have this, then “sudo apt-get install network-manager-gnome”) and set the PCIe link (eno1) to static IPv4 address 192.168.0.14, and netmask 255.255.255.254. Then manually set the metric to 0. You might find this reference URL helpful, especially information about metric:
https://docs.ubuntu.com/core/en/stacks/network/network-manager/docs/routing-tables
Another app which might help is “ifmetric” (“sudo apt-get install ifmetric”), although I tend to edit files (NetworkManager can make file editing seem to fail at times, so first do everything you can in “nm-connection-editor” before using other tools). The “route” command can use the “metric” argument to set a metric (see “man route”).
Example with the command line tool (part of network-manager):
nmcli connection modify eno1 ipv4.route-metric 0
(you might need to ifdown and ifup the interface, not sure)
Then run “route” again to see if the metric is 0. Having the eno1 cover only a single address, and making its metric equal to eth0, implies the more specific address will get the traffic (and it is more specific if the netmask is a “/31”, or “255.255.255.254”).
There is a similar issue with the Jetson. You have two networks with conflicting networks over the same address range. Only the address with the metric of “0” will get traffic. Setting the PCIe network to have a single address in the route (meaning netmask is “255.255.254” instead of “255.255.255.0”), and setting metric to 0, should make that route available for that address.
Normally what someone would do in a situation like this is to simply put the second NIC (which your PCIe is emulating) on a different subnet…then there would be no conflict in anyway. For example, if the PCIe had address “192.168.1.x” (note “.1.” instead of “.0.”…a different “/24” subnet), then metric and route changes would never matter…this would be the only device on that subnet and there would be no confusion as to which interface to route to.
Pretty much any online web search you perform for Ubuntu networking, or docs on subnets, would be the same for this. It won’t matter if the NIC is really PCIe or real or virtual USB…at this point it is about network setup, and not about the PCIe side.