Ghost nodes occur from those locking their netrom routes, reloading stale
saved netrom tables, or perhaps from the excessive ping ponging of INP3
nodes which do not follow NetRom detrating standards (but gladly uses such
as a transport). Another reason why this may be occurring (as you stated) is
NetRom links set a too high of a quality and stations broadcasting tables
stating that they physically host their neighbor nodes on their own lan.

This has been an issue since the beginning of axip linking (axudp came many
years later). I still see my old nodes from 10 years ago still being
propagated out within the INP3 cloud. Lowering NetRom neighbor link quality
is half of what a sysop can do... but also raising min_obs and
worst_qual can help filter some of the underlaying nodes even ghost nodes
within the INP3 cloud from showing on your node.

My strong suggestion is the following:

For RF based NetRom nodes:
DefQual: 203
Min_Obs: 3
Def_Obs: 5
WorstQl: 50

This setting allows for 1 missed obs broadcast every 15 minutes before a
node is dropped from the nodes list, meaning within 30 minutes that node
will cease being seen. Also with the qualities set forth, This sets forth
a 6 hop stretch which keeps the integrity of what you list for nodes sane, 
and users will be presented with a nodes list of connectable nodes.

For axip based NetRom nodes:
DefQual: 203
Min_Obs: 4
Def_Obs: 5
WorstQl: 181

This setting allows for wormhole nodes to be displayed on your nodes
list and does not allow for a failed obs broadcast before dropping their
neighbor node off your listings. If an internet wormhole node dies it should
drop as soon as possible which for basic NetRom is 15 minutes. Also onl their
direct neighbor nodes should only appear so 1 hop from YOUR neighbor is seen.

For INP3 Neighbors:
DefQual: 128
Min_Obs: 4
Def_Obs: 5
WorstQl: 127

This allows your immediate INP3 neighbor ONLY to appear on your node and 
does not allow for you to retransmit a hop to your other axip based neighbors
but does offer services to your RF neighbors. Since there seems a path to all
other wormholes from each other there's no need to confuse the paths even
more but it will allow a gateway into the cloud from your RF neighbor. Once
they connect through you to the INP3 neighbor they can see the cluster of
nodes on the cloud, most of which exceeds 850* nodes now.

*For someone on 300 baud HF to pull up 850 nodes it will take them about 45
minutes to download the whole list - which WILL TIMEOUT the user. Not a good
idea to have on your node. You want to service ALL users from 300 baud to
802.11 Hamnet/Hamwan users.

We can't control what others do but we can control what we do. A schema of this
which I've tested well for over 3 years now does what should be done. We as
sysops must remember that it's not the number of nodes we carry that defines
us as a station, it's the integrity of those nodes we do carry that the end
user wants us to deliver. Offering end users nodes that don't exist anymore
is of no integrity, and presents your node as a non-functional node to them.
Users talk amongst themselves, so if they say to each other that your node
doesn't work, you'll lose servicing those users and they'll go elsewhere -
especially straight internet!