I would start at the Gateway. My first suspicion would lay in the 7000 acting as the Gateway and the routing information becoming lost, the packet may get lost on the return.
I begin by turning on the ICMP Debugging at the 7000 and monitor the initial responses. While in "ENABLE" mode at the 7000 console, or if you telnet to the 7000 remotely be sure and type "TERM MON" (this will out put the results to the accessing terminal. The type "DEBUG IP ICMP EVENT". Initially just start with a machine you cannot get to in the method you refer to in your message.
type "PING "
observe your results and verify that the ping message leaving the 7000 and going out the interface that is connected to the Cat 4006.
Next do a "SHOW IP ROUTE "
If the ping is going out the proper interface, try and "TRACE IP ". Observe where the Traceroute begins to hang.
If the initial Ping was unsuccessful, I would next do an extended ping using the IP address of the Particular interface facing the 4006 as the source address when prompted. If that ping works, the router's route table needs to be examined. If you are using OSPF, be sure the network is in your OSPF table on the router. You will immediately know it is not if the first "SHOW IP ROUTE " resulted with a "not in table" message.
I am assuming too much... It will still be the 7000 "gateway"'s responsibility in the beginning. If you have VLANS assigned on the remote 2950 switches, and/or your "Bridge Group" command is incorrect, the problem becomes a little more complex.
After the you are done with the DEBUG of the IP ICMP, be sure and turn it off with "UNDEBUG ALL" or "UNDEBUG IP ICMP".
More information would be required on your part, for example: Are the addresses of the remote LANS PUBLIC or PRIVATE?
I hope this has been able to get you jump started at least.
