tests: routing: Add address with same prefix present

[jlduran]

Summary

Add a test for the fix: when adding an address to an interface with the
same prefix already present in the routing table.

Test Plan

/usr/tests # kyua test sys/net/routing/test_routing_l3.py
sys/net/routing/test_routing_l3.py:TestIfOps::test_add_address_same_prefix_present[inet6]  ->  passed  [0.221s]
sys/net/routing/test_routing_l3.py:TestIfOps::test_add_address_same_prefix_present[inet]  ->  passed  [0.255s]
...

[jlduran]

This is the test I'm using for the fix in D47534.
As explained in that review, Jenkins alerted that it broke test:
https://ci.freebsd.org/view/Test/job/FreeBSD-main-amd64-test/lastCompletedBuild/testReport/junit/sys.net.routing.test_routing_l3/py/TestIfOps__test_change_prefix_route_inet_/

I'll keep posted.
Thank you!

[markj]

In D47585#1085259, @jlduran wrote:

This is the test I'm using for the fix in D47534.
As explained in that review, Jenkins alerted that it broke test:
https://ci.freebsd.org/view/Test/job/FreeBSD-main-amd64-test/lastCompletedBuild/testReport/junit/sys.net.routing.test_routing_l3/py/TestIfOps__test_change_prefix_route_inet_/

Do we understand why this test is failing? Is it a test bug or does this represent a real bug in the commit?

[jlduran]

In D47585#1090640, @markj wrote:

In D47585#1085259, @jlduran wrote:

This is the test I'm using for the fix in D47534.
As explained in that review, Jenkins alerted that it broke test:
https://ci.freebsd.org/view/Test/job/FreeBSD-main-amd64-test/lastCompletedBuild/testReport/junit/sys.net.routing.test_routing_l3/py/TestIfOps__test_change_prefix_route_inet_/

Do we understand why this test is failing? Is it a test bug or does this represent a real bug in the commit?

If we set aside the fact that the same test for IPv6 has always been skipped:
The commit fixes this test (the one in the bug reports and in this review), by replacing pinned routes. When assigning to an interface an IPv4 address on the same subnet as another interface, it will replace the (pinned) route with the new interface, therefore failing the first check within the test. That is, it should have kept the first interface, according to the test. I don't know what to think about this one, up to this point, I would even consider it OK-ish.
However, the second part of the test, if we destroy the first second [EDIT] interface, that's where the problem is IMO. The route pointing to the first interface should be back.
I do not fully understand that test TBH, it looks like a lagg test or similar. I'm also not familiar with assigning IPv4 addresses on the same subnet to different interfaces, just like that. That's why, perhaps skipping both (IPv6 and v4) in the meantime would be my suggestion. So yes, I would guess it could be a test bug (just like it has always been for IPv6). I can't immediately see a real-life scenario to support it.

[ae]

IMHO when we already have an interface route, we should fail on trying to add the same route on different interface. And I think this should fail even before adding route, when an IP address will be configured.
If you want to test the case that was fixed in D47534 you need to add some static route, then configure interface route that will replace this static route, because interface route has higher priority.