Ignore our own prefixes from our own routers, and say why a route for a network of this machine is held

Two routers of an AS that both originate a prefix (anycast) each
announce it to the other over their internal session. Each took the
other's route, could not install it in the kernel, since the prefix is
on one of its own interfaces, and so held it, counted as rejected with
"next hop unreachable": a permanent rejection on a healthy session, for
a next hop that was in fact fine.

A route from a peer in our own AS for a prefix this router originates
is now ignored: not taken, not held, not counted. Only that prefix
itself; what is inside it is judged as usual. From other networks such
routes are refused as our own prefixes, as before.

A route that is held because its prefix is a network of this machine,
or inside one (an exchange's LAN prefix, say), is now counted as "prefix
is a network of this router", apart from routes whose next hop cannot
be reached.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

scripts/interop/lab.sh

@@ -818,7 +818,7 @@ phase_hijacks() {
     # The LAN's own prefix. The lab takes bogons, so the policy lets it
     # by; it is still not a route the kernel could be given, and so not
     # one to take: it would compete with the connected route.
-    wait_for "the LAN's prefix to be held" refused_for "next hop unreachable"
+    wait_for "the LAN's prefix to be held" refused_for "prefix is a network of this router"
     dut_lacks 10.9.0.0/24 || fail "the LAN's own prefix was taken from FRR"
     in_ns dut ip -4 route show proto bgp | grep -q "^10.9.0.0/24 " && fail "the LAN's own prefix was installed by way of a peer"
     in_ns dut ping -q -c 1 -W 2 10.9.0.3 >/dev/null || fail "the LAN is not reachable any more"