Re: Eaton 9130 UPS feedback

[Daniel Griggs]

Hi Seth,

A previous employer we looked at a few UPS.

We used Emerson GXT2/3 3Kva UPSs and they worked a treat.
We also tried the Eaton 9130 and we never had any problems with them, but the 
SNMP monitoring was only good for telling you if there was a problem, not what 
the problem was. So we eventually went back to the Emersons.

On 14/11/2012, at 8:59 AM, Seth Mattinen wrote:

 Does anyone use Eaton 9130 series UPS for anything? I'm curious how
 they've worked out for you.
 
 I bought a 700VA model to give it a whirl versus the traditional APC
 since the Eaton is an online type with static bypass and also does some
 high efficiency thing where it normally stays on bypass, but the first
 thing it did on the bench was have the inverter/rectifier or bypass
 section catch on fire and destroy itself.
 
 ~Seth
 

--
Daniel

Re: Angled Polish Connectors and DWDM

[Daniel Griggs]

We have been using APC connectors on our DWDM deployments now for about 5
years and have had no issues with it at all.

Additionally, last year we engaged several DWDM system providers  and one
of the questions we asked them was, did they know of any issues with APC
connectors especially with regard to dual polarization systems. All vendors
came back with having no issues with APC connectors.

On 1 October 2012 06:15, ML m...@kenweb.org wrote:

 On 9/30/2012 12:46 PM, Mikael Abrahamsson wrote:

 On Sun, 30 Sep 2012, ML wrote:

  So far our PMD testing has come back clear.


 How have you done the PMD testing?

 For verifying PMD and CD through an actual wavelength (not per-fiber, but
 through all the ADMs etc), I haven't really been able to find a good
 solution. Suggestions welcome.


 All tests done per span on dark fiber.

 CDs via a Nettest FD440: 1520nm to 1640nm
 PMD via a PerkinElmer* device: Just at 1550nm.

 -ML


 Couldn't find a model number in the test results. Just a reference to
 PerkinElmer.




-- 
Daniel Griggs
Network Operations
e: dan...@fx.net.nz
d: +64 4 4989567

Re: Common operational misconceptions

[Daniel Griggs]

Seems like dig doesn't always advertise a big enough buffer, I was having
the same issue as you. If you set the buffer size on the command line it
works as directed.

Daniels-Mac-mini:~ daniel$ dig edns-v4-ok.isc.org txt @149.20.64.58
;; Truncated, retrying in TCP mode.
;; Connection to 149.20.64.58#53(149.20.64.58) for
edns-v4-ok.isc.orgfailed: connection refused.
Daniels-Mac-mini:~ daniel$ dig edns-v4-ok.isc.org txt @149.20.64.58+bufsize=4096

;  DiG 9.7.3-P3  edns-v4-ok.isc.org txt @149.20.64.58 +bufsize=4096
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 18209
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;edns-v4-ok.isc.org.INTXT

;; ANSWER SECTION:
edns-v4-ok.isc.org.0INTXTEDNS-4096-OK EDNS-4096-OK
EDNS-4096-OK EDNS-4096-OK EDNS-4096-OK EDNS-4096-OK
snip
EDNS-4

;; Query time: 176 msec
;; SERVER: 149.20.64.58#53(149.20.64.58)
;; WHEN: Fri Feb 17 10:22:08 2012
;; MSG SIZE  rcvd: 4096




On 17 February 2012 05:53, Phil Regnauld regna...@nsrc.org wrote:

Borderline dns-ops, sorry folks! - but this is interesting
as we've been talking about ipv6 being operational, and this
is part of it...

 Mark Andrews (marka) writes:
 
  If you are seeing TC between the resolver and the server and the TCP
 query is being answers then
  something in the path is intercepting the DNS queries.

 TC is on the answer from the remote server to my resolver, so
 yeah, seems
like something is messing with the packets.

   Don't see any v6 fragments (that'd be a problem since PF doesn't
 handle
   them on this host).
 
  You should see something like this on the wire.  The second query is to
 answer
  dig's query over TCP.

 I'm not seeing fragments as you are.

Here's what I see:

 14:40:20.955876 IP6 2001:2000:1080:d::2.64561  2001:4f8:0:2::8.53: 52841
 TXT? edns-v6-ok.isc.org. (36)
 14:40:21.141948 IP6 2001:4f8:0:2::8.53  2001:2000:1080:d::2.64561:
 52841*-| 0/0/0 (36)
 14:40:21.142259 IP6 2001:2000:1080:d::2.53262  2001:4f8:0:2::8.53: Flags
 [S], seq 1112939462, win 65535, options [mss 1440,nop,wscale 6,sackOK,TS
 val 2571957531 ecr 0], length 0
 14:40:21.327895 IP6 2001:4f8:0:2::8.53  2001:2000:1080:d::2.53262: Flags
 [R.], seq 0, ack 1112939463, win 0, length 0

Cheers,
Phil




-- 
Daniel Griggs
Network Operations
e: dan...@fx.net.nz
d: +64 4 4989567