Recent content by jb33

more replication trouble. Hoping you find these reports useful, not inteded to pile on. 1368039969 error job-replicate 1035 20.56:57 end log initial remote replication finished (time: 27974 s, size: MB, performance: 0.0 MB/s) error noid 20.56:57 glib 942...

Oh no! Gea, what happened!? 2 replication jobs have deleted all my target snaps and all but one of my source snaps and I think forced me to reseed!! I think maybe given the fragility of WAN replication and the potential for jobs to fail zfs destroy should only fire after replication completes...

bummer, I think WAN link reliability is going to be an issue. Yesterday's manual 152GB send dropped 129GB into it last night. Do we have anything like zfs send --resume in the nappit replication? And is this normal? Kicked off my nappit replication this morning. Logging these every 15...

Gea, Thankyou ! I'm sure that was getting annoying! It was an http-proxy inspector on our WATCHGUARD set to deny unknown web request methods. Here's a list of the accepted methods. I screen-captured a minilog thought I saw it was a POST request. Know why it might have been failing? HEAD GET...

NC Shell output: Write nappit1 zfs list to nappit0 console on port 82. root@nappit1:~# zfs list | nc nappit0 82 root@nappit0:~# nc -l -p 82 NAME USED AVAIL REFER MOUNTPOINT r10 3.91T 235G 32K /r10 r10/B1...

Hi Gea, maybe this is the problem? root@nappit0:~# nc -l -p 81 nc: Address already in use

If I understand it correctly netcat is working. It's how I am manually replicating for the time being. Seems like its just the appliance-group recognition piece that's having trouble. I *think* I've got the firewalls passing the traffic and bypassing the IPS, etc. See the nc send/receive...

Alright! Got my first 92GBs snapshots from Friday manually WAN replicated! Looks like there are 200GBs more as of this morning (Sunday) which means that at ~20Mbps I should just be caught up before the doors open Monday. Phew. Had to wake up at 3 in the morning to kick off my 2nd stream so...

Good question! But yes, in both directions. root@nappit0:~# ping nappit1 nappit1 is alive root@nappit0:~# nc -vzu nappit1 81 Connection to nappit1 81 port [udp/*] succeeded! root@nappit0:~# nc -vz nappit1 81 Connection to nappit1 81 port [tcp/*] succeeded! root@nappit1:~# ping...

seems like it's open, see the port scans in both directions below. I clicked the ZFS link for the appliance in the t-AG and see this corresponding output in the jobs monitor. Anything in the fact that the host_ip=nappit1? By the way, there is no question of me buying the extension on Tuesday. No...

I seem to have a handful of issues. The big one is my target-side firewall [sonicwall TZ210] can't seem to handle the traffic. CPU spikes to 100% from about 5% as soon as I kick off a manual replication and latency goes from <30ms to >2000ms! During a manual remote replication, the target...

hmm, maybe that's not it. ICMP Traceroute completes between both nappit boxes... Do the hosts "register" any Route/MAC or IP info about each other when the appliance group is first established?

81 is open - ran a netcat port scan! handy little feature! - and I've confirmed all traffic is allowed between hosts. I think I've got a host routing issue but I'm not sure what it is yet. Both hosts can ping one another, resolve eachother's hostname with an answer from our domain dns box and...

Thanks Gea. Source IP unchanged. Target IP has changed. Current source appliance status (as read in target appliance-group) is 'remote call: timeout.' manual nc send/receive test was succesful across vpn. Confirm delete source from appliance-group and re-add? I tried to add before...