To step a little bit outside of the TSM box, have you considered using
iptables (you¹re a Linux shop, right?) with a time rule on the TSM server to
block these troublesome hosts/subnets from connecting to TSM during
undesirable times. You can either be heavy-handed and stop any matching
packet after the witching hour, or let existing connections survive (so you
can more gracefully stop them using cancel session).
-Ken 


On 9/26/12 4:23 PM, "Zoltan Forray" <zforray AT VCU DOT EDU> wrote:

> That is my whole point of my question/this discussion.  So far the only
> thing to do is what I already thought of (1-disable sessions, 2-cancel
> session,  3-try to lock the node in-between retries...) but that in itself
> is problematic since the node will "keep banging on the door" for a while
> trying to re-establish the failed connection before it gives up...
> 
> Also, disabling sessions will effect every node on that TSM server,
> including legitimate backups that run throughout the day that don't effect
> network traffic since they are on their own private subnet....
> 
> On Wed, Sep 26, 2012 at 4:15 PM, Alex Paschal <apaschal5 AT frontier DOT 
> com>wrote:
> 
>> > Out of curiosity, when you cancel the sessions manually, how do you stop
>> > them from restarting?
>> >
>> >
>> > On 9/26/2012 11:15 AM, Zoltan Forray wrote:
>> >
>>> >> All of this discussion is great but the bigger picture/issue is being
>>> >> missed.
>>> >>
>>> >> Yes, I would like to automate it but isn't really possible since it is
>>> >> subjective to which one is eligible to be canceled.
>>> >>
>>> >> If I (or an operator) figure out which to cancel and then cancel it,
>>> >> backup
>>> >> session will automatically restart and keep on going.  I want to be able
>>> >> to
>>> >> stop it from restarting, as well!
>>> >>
>>> >> On Wed, Sep 26, 2012 at 1:28 PM, Ehresman,David E.
>>> >> <deehre01 AT louisville DOT edu>**wrote:
>>> >>
>>> >>
> 
> 
> --
> *Zoltan Forray*
> TSM Software & Hardware Administrator
> Virginia Commonwealth University
> UCC/Office of Technology Services
> zforray AT vcu DOT edu - 804-828-4807
> Don't be a phishing victim - VCU and other reputable organizations will
> never use email to request that you reply with your password, social
> security number or confidential personal information. For more details
> visit http://infosecurity.vcu.edu/phishing.html