You have several problems with this setup.
Firstly, there is no generally-valid way to run arbitrary commands on a remote server via SNMP (thank God). That doesn't mean you couldn't define some corner of the OID space and implement your own agent, which runs pings on request, and reports back. But you'll still run into the other problems.
Secondly, PINGability is no guarantee of usability as a route; some routers don't respond to ICMP echo-request, though if yours does, this won't apply.
Thirdly, and this is the fatal one in my view, you've said the two servers (monitoring and monitored) are on different subnets. So if server B's default route is unavailable to it, how are the SNMP responses going to get to server A? You're setting up a monitoring system to test for a given condition, in a manner that is guaranteed to fail when the condition applies, and that's not a great idea.
I think you'd do better to work out what you actually want to know, and test for that. If it's (say) "can server B be reached on port 80", test for that. If it's "is server B's web application accessible and working correctly", test for that; a properly-written canary page can be very useful here. If it really is "can server B connect to the internet", you'll need a reliable backchannel on server B (ie, using the internet connection you're testing won't do), or server B should test and report on this itself via an out-of-band backchannel, eg direct-attach GSM modem. This last will be expensive and complex, so be very sure that you really do have a business need to know that before you commit to monitoring it.