(Wow, this took a while -- I had to draw it out twice.)
First, I don't see a route rule on Kentucky that gets packets to 172.16.200.0/24. And the no-gate implies (to me, since I've never handled this specific syntax before) that there's no default gateway on it.
Routing 101: just because the network can get a packet to you, it doesn't mean it can get one back to where it came from. So even if you can get pings to Kentucky, the answers won't get back.
ST1 has the same route specified twice:
up route add -net 172.16.200.0 netmask 255.255.255.0 gw 10.10.10.5 dev eth1
...which is harmless because it says the same thing.
Also, I think this line on ST2 is wrong:
up route add -net 192.168.254.0 netmask 255.255.255.0 gw 10.10.10.5 dev eth0
...which I think means you are telling it that the 192.168.254.0/24 network is reachable via itself, on the wrong interface. It also contradicts the right route, which is in the first cluster on ST2:
up route add -net 192.168.254.0 netmask 255.255.255.0 gw 10.10.10.6 dev eth1
So. Get rid of the
up route add -net 192.168.254.0 netmask 255.255.255.0 gw 10.10.10.5 dev eth0 on ST2, add a rule on Kentucky to either default-route (or just send packets for 172.16.200/24) via ST1, and it should work.
If that doesn't work, do a
netstat -rn on both ST1 and ST2 and post the output of that.