- Test - lists.nanog.org

RE: KVM over IP suggestions?
by nick.nauwelaerts＠thomson.com 23 Aug '05

23 Aug '05

> -----Original Message----- > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On > Behalf Of Kevin > Sent: Monday, August 22, 2005 10:27 PM > To: nanog(a)merit.edu > Subject: Re: KVM over IP suggestions? > > > We have a non-IP switch from Raritan and saw presentations on their > > IP KVM products. Seemed pretty impressive. One problem you may want > > to focus on is screen resolution since the video output must be > > converted to IP packets with a lower refresh rate. We're planning > > to buy a few of these switches for remote monitoring. > > The "IP Reach" video compression is bearable for installation and > recovery. Video quality is degraded, but unless you really cannot > stand moire patterns, it'll take an hour or so staring at the display > before your headache becomes unbearable. > > I have experience with Raritan's "Paragon IP Reach" products, and they > do work, but are expensive for such a low port density. Also it has > been very difficult to work with tech support to make the Paragon > product with a RADIUS server for OTP access control. > > The newer "Dominion" line may be better; I've heard some complaints > about their serial console products, nothing either way about KVM. We've tested Raritan's integrated KVM over IP + serial products for a while, but were less than impressed with their interface tools. Both the standalone client and the ActiveX client were prone to crashing, sometimes taking the raritan device with it. We've since junked the servers for which we needed the KVM over IP for in favor of HPs with advanced ilo or IBMs with remote supervisor cards, if which I'd recommend HPs offering any day. // nick

1 0

KVM over IP suggestions?
by Drew Weaver 23 Aug '05

23 Aug '05

Howdy, I'm looking for a way to give our remote users access to their servers, perhaps a KVM-IP solution. What we need is support for multiple users (more than 2), with access control that limits what users can connect to what ports on the KVM switch, and would allow you BIOS level access and os-installation type control over the server, would also be nice if it worked with windows and linux/unix based systems. Any suggestions would be helpful. Thanks, -Drew

10 11

Qwest PSTN problems / status page?
by Mike Lewinski 22 Aug '05

22 Aug '05

Is anyone aware of a network status page for Qwest PSTN. We have been told they are currently experiencing a major outage and "All calls are failing out-going" (which isn't true as I've made some calls, but am seeing intermittent congestion returned on our PRIs) I have also heard that it... "Seems to be on the public switching network.Seattle can call out, Minneapolis & Ohio can't." (We first noticed it WRT LD calls, and my first test was to OH and that succeeded, so whatever it is clearly is intermittent). Mike

3 3

RE: Qwest PSTN problems / status page?
by Nick Thompson 22 Aug '05

22 Aug '05

We are currently having outbound long distance issues via Qwest right now. A PSTN status page would be rather convenient at this moment. Nick Thompson ISP Administrator Multiband 2000 44th Street SW Fargo, ND 58103 -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Mike Lewinski Sent: Monday, August 22, 2005 4:16 PM To: nanog(a)merit.edu Subject: Qwest PSTN problems / status page? Is anyone aware of a network status page for Qwest PSTN. We have been told they are currently experiencing a major outage and "All calls are failing out-going" (which isn't true as I've made some calls, but am seeing intermittent congestion returned on our PRIs) I have also heard that it... "Seems to be on the public switching network.Seattle can call out, Minneapolis & Ohio can't." (We first noticed it WRT LD calls, and my first test was to OH and that succeeded, so whatever it is clearly is intermittent). Mike

2 1

Re: Question about propagation and queuing delays
by Robert E.Seastrom 22 Aug '05

22 Aug '05

"Howard, W. Lee" <Lee.Howard(a)stanleyassociates.com> writes: > Do carrier ISPs classify their voice traffic as Really > Important, and everybody else's data as Best Effort? This > isn't just selfishness, since We All Know voice is less > tolerant of latency and jitter than TCP. We do? Try to keep a single-TCP-stream session over 500 mbit/sec of goodput halfway across the country sometime. Most of us who have VoIP boxes have 20ms or better jitter playout buffers. Ever (successfully) talk to someone over a GSM handset when their coverage was a little marginal? The human ear is a marvelous tool compared to a TCP timer. Apologies if "We All Know" was supposed to be a cue to sarcasm or irony... ---Rob

1 0

(non-op) Calling Exchange Point Operators
by Joe Abley 22 Aug '05

22 Aug '05

A couple of people have expressed interest in an exchange-point BOF at NANOG 34 in Los Angeles. The BOF would include a few short presentations on topics of interest to exchange point operators, with time for more general comment and discussion. The kinds of topics that have been suggested to me are exchange point support tools (provisioning automation, monitoring, etc), architecture, vendor selection and policy. This would be a meeting about operating exchange points, rather than a vehicle for trying to attract ISPs to connect to your exchange. If there are exchange point operators here who are planning to go to LA in October, and to whom this sounds vaguely interesting, please drop me a note off-list with your thoughts. Joe (not wearing any particular hat, and speaking for himself)

1 0

Cisco Security Advisories: IDS related
by Fergie (Paul Ferguson) 22 Aug '05

22 Aug '05

This may affect several folks: SSL Certificate Validation Vulnerability in IDS Management Software http://www.cisco.com/en/US/products/hw/vpndevc/ps4077/products_security_adv… Cisco Intrusion Prevention System Vulnerable to Privilege Escalation http://www.cisco.com/en/US/products/sw/secursw/ps2113/products_security_adv… FYI, - ferg ps. A couple of new bots surfaced over the weekend, too.... :-/ -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(a)netzero.net or fergdawg(a)sbcglobal.net ferg's tech blog: http://fergdawg.blogspot.com/

1 0

RE: KVM over IP Suggestions?
by Simon Hamilton-Wilkes 22 Aug '05

22 Aug '05

True, but I've added it to our Cisco ACS server boxes so at least didn't need more hardware. A couple of models (DSR2161 certainly) have alternative firmware available on the Dell site which removes the requirement for the authentication server, but most of the access control goes with it. -----Original Message----- From: Aaron Glenn [mailto:aaron.glenn@gmail.com] Sent: Monday, August 22, 2005 9:42 AM To: Simon Hamilton-Wilkes Cc: nanog(a)nanog.org Subject: Re: KVM over IP Suggestions? On 8/22/05, Simon Hamilton-Wilkes <simon(a)jettis.com> wrote: > > They support P/S2 / USB / Sun and serial - though are a very expensive > way to do serial. And (last time I looked, at least) they required an expensive, proprietary, Windows-only authentication server (DSView) in addition to the client software licenses and hardware costs. aaron.glenn

1 0

Mpower contact
by Jack Bailey 22 Aug '05

22 Aug '05

Anyone have a contact at Mpower who can work on routing issues outside the hours of 9 to 5 Mon - Fri? Thanks.

1 0

Re: New N.Y. Law Targets Hidden Net LD Tolls
by Robert Bonomi 21 Aug '05

21 Aug '05

> From owner-nanog(a)merit.edu Fri Aug 19 14:37:28 2005 > From: Barry Shein <bzs(a)world.std.com> > Date: Fri, 19 Aug 2005 15:31:42 -0400 > To: nanog(a)nanog.org > Subject: Re: New N.Y. Law Targets Hidden Net LD Tolls > > > > Can't one still get minimal phone service which charges a toll on > every phone call? I know this used to cost like $5/mo but I think they > eliminated it in MA a few years ago, or made it hardship-only. Authoritative answer: "Maybe." Depends on the locale, the state regulators, and the phone company. Frequently called "Lifeline" service, when marketed for the elderly, disabled, etc. Also called "measured zero" -- when offered to the general public (for the 'cheap SOB' customer) > > Simple business lines here normally charge for every phone call, 1MB > as they're called, MB = Measured Business tho I guess that's not what > Spitzer was concerned with. > > But that's a big part of the problem, the telcos don't make this > information readily available in a form ISPs can use, and even if they > did it'd depend on the specific service option the customer had. In > our experience customers don't generally know what phone service they > have in any useful way (such as the exact name the telco calls it, > circle dialing, metro calling, etc.) I've had an ILEC refuse to tell me (a CLEC customer) where _their_ "rate center" for my numbers was. That it was 'proprietary' information that they would not release to non-customers. Never mind the fact that the reason I wanted it, was to give it to those of *their* customers who were, incidentally, also my customers. > > And boy howdy we've tried to help, motivated by the occasional livid > customer who got an unexpectedly large bill. We've had a warning just > like the one suggested on our pick a number since before some list > members here were born. It *is* definitely 'good business practice' to supply such advice to "double check" the suggested number. I question the _requirement_ -- and penalties for failure -- to do so. The area transit authority publishes a _single_ 7-digit number that you can call from anywere in the 6 NPA region they service to get travel information. For large portions of the territory dialing that 'same NPA' number results in a pricey INTRA-LATA toll call. For a differently- delimited large area, dialing a different NPA, and then that 7-digits gets you a much _less_expensive_ call to an apparent destination that is (apparently, based on the rates) much 'closer to home'. Why isn't the gov't requiring *them* to run a similar disclaimer -- and with severe penalties for non-compliance -- on all their materials listing that number? > In my not insignificant experience there's some VP inside every RBOC > cackling madly over the revenues generated by this confusion. > > And, no, don't give me the old "don't attribute to malice what can be > adequately explained by stupidity." It is *definitely* not stupidity. In the case mentioned above, the ILEC was handing calls off to the CLEC at points away from where the 'nearest' ILEC-CLEC inter-connect to the CLEC POP was. Calls to lines that were only a few dozens of numbers apart were being routed through _different_ tie-points, with *different* costs to the caller. > Double-digit billion $$ companies don't make universal, big revenue > generating mistakes over a period of probably 50 years with no doubt > millions of complaints (not just ISP dialing) out of "stupidity". > > Such confusion is their stock in trade. > > And I suspect that's, as Paul Harvey used to say, "The rest of the > story". Spitzer's office must have tried to look into why ISPs et al > can't just make a reasonably accurate suggestion to customers looking > for a phone number and, upon querying the telcos, was met with a big: > hahahahahahaha yeah, right! > > It's too obvious to have possibly been missed. > > -- > -Barry Shein > > Software Tool & Die | bzs(a)TheWorld.com | http://www.TheWorld.com > Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD > The World | Public Access Internet | Since 1989 *oo* >

2 1