Joe,<br><br>Do you have any support to any extent with BB?  The main reason I switched was that there was a mailing list to look to for support.  Secondly, it wasn't BB.<br><br>Josh<br><br><div><span class="gmail_quote">

On 11/2/07, <b class="gmail_sendername">Sloan</b> <<a href="mailto:joe@tmsusa.com">joe@tmsusa.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

Deiss, Mark wrote:<br>><br>> For a vanilla BB environment, you can have multiple BBDISPLAY entities<br>> but the recommendation is that there is only one BBNET entity. A BBNET<br>> server that is generating the pings out to the clients will be sending

<br>> the ping results to all of the BBDISPLAY entities (as defined on the<br>> BBNET host). If you have multiple BBNET entities that ping the same<br>> servers, you will be sending duplicated results as far as the

<br>> individual BBDISPLAY servers are concerned (the connection messages<br>> will be renamed to the host being pinged). To support multiple BBNETs<br>> in a non-race environment requires additional coding to carefully

<br>> direct the BBNET results to not trip over each other. The default<br>> behavior is to pump them out to whatever BBDISPLAY is listed - you get<br>> the race conditions when you want all the BBDISPLAY servers to monitor

<br>> all of the BBNET hosts (i.e. want BBNET to send their client-side<br>> tests to the BBDISPLAY entities - this will result in the BBNET poll<br>> messages going out to all the BBDISPLAY entities also).<br>>

<br><br>Interestingly enough, we've been running redundant bb servers for each<br>lan, without any concern for race conditions and while that has it's own<br>peculiar behavior in corner cases, we've never seen any sort of real,

<br>intractable problems with it. The general consensus here is that<br>redundancy is good, except for the notifications - we don't want to be<br>notified twice for every incident, thus the so-called bb "failover"

capability saves us that annoyance with no extra hacks required. I probably made it sound a lot more sophisticated than it really is - we really just have active/active BBNET/BBDISPLAY servers, with the delegation of BBPAGER decided by the failover status.

<br><br>It looks like Henrik has a good roadmap to get there in 4.3 from what I<br>read here, so hopefully we've got our bb replacement at last. The only<br>other concern is that we copy all bb notifications as snmp traps to

<br>netcool, but it looks as though that should be with a hobbit plugin.<br><br>Joe<br><br>To unsubscribe from the hobbit list, send an e-mail to<br><a href="mailto:hobbit-unsubscribe@hswn.dk">hobbit-unsubscribe@hswn.dk</a>

</blockquote></div> <br clear="all"> --  Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 Those who don't understand UNIX are condemned to reinvent it, poorly.

<br>--- Henry Spencer