[...] I was assuming that any routing loop in the system would be transient, but this one is not (the traceroute is still showing the same behavior).
That is not a good assumption to make.
The extent to which I see this also makes me think that there is something else going on.
It is, indeed, something else.
Do you think that it can be a real persistent routing loop (data packets would actually shuttle between the two interfaces) as against some wierdness because of traceroute?
Yes. The case of an upstream following a route to a prefix that the downstream entity does not cover is, possibly, the most common instance of this. For example, the upstream router points a static for 192.168.1.0/24 at the downstream router. The downstream router subnets that /24 into two prefixes: 192.168.1.0/25, and 192.168.1.128/26; the remaining /26 is "reserved for future growth," but the operator does not install a covering route for the whole /24. The downstream router points a static default at the upstream router. Now, if a packet is addressed to a destination in the "missing" /26, it will follow the /24 route to the downstream router, find no route there more specific than default and go back to the upstream router, follow the /24 route to the downstream router, find no route there more specific than default and go back to the upstream router, etc., until TTL expires. Traceroute will display the loop for you, as you have seen. Since the more specific prefixes that the downstream uses function quite normally, there is little to no incentive on the part of the downstream to clean this up, unless a large traffic flow to the missing portion causes noticable traffic increase. Stephen