結論からいうと CAT6 か CAT6A を使う。33m までなら CAT6 でも良いことになっているので家庭なら CAT6 でも十分ということになる。ただ伝送帯域に余裕がないので、取り回しに問題がないなら CAT6A を使うほうが良さそう。

8P8C (RJ45) コネクタを使う CAT7 CAT8 規格は存在しない

簡単にいうと CAT7 CAT8 のコネクタは CAT6A 以前とは互換性がない。市場には 8P8C で CAT7/CAT8 なケーブルが売っているではないか?と思うかもしれないが、あれはケーブルだけ CAT7/CAT8 なだけで、全体としては規格に適合していない野蛮なものである。

ケーブルにいくら CAT7 CAT8 適合なものを使っても、コネクタに 8P8C (RJ45) を使う場合には CAT6A と同等の扱いとなる。ただの硬い CAT6A ケーブルでしかない。それなら CAT6A で良い。

また、CAT7 以上では STP (シールド付き) なので、機器側でアースがしっかりとれていなければならない。家庭用機器でアースをとるものはほとんどない (接地用端子・接地極がついたコンセントがそもそも普及してない) で、この点でもやはり意味がない。

電位が浮いてる状態の導体があると、そこがアンテナになってしまう。また、適切に両端を接地したとしても、今度はグラウンドループが形成されるため、かえってノイズが増えることもある。接地すべきかどうかがケースバイケースで決まってしまう。ノイズ対策は「グランド繋げば解決」みたいな簡単なものでは全くない。

この点でシールドケーブルは素人には光ケーブルよりも取り扱いが難しい。なので10Gbpsを超えるようになってくると本格的にファイバーに移行する必要が出てくるのではないかと思う

  1. トップ
  2. tech
  3. 10GBASE-T LANケーブル CAT6 CAT6A CAT7 CAT8

LAN向けのDNSキャッシュサーバ

経緯としてRTX1200 の DNS 機能が TCP フォールバックに対応してないのでオフにした、というのがある。直接 8.8.8.8 8.8.4.4 を DHCP で広告するようにしてみたが、RTT が 8ms ぐらいあるので、やはり LAN 内にキャッシュサーバがあったほうがいいかなと思いはじめた。

LAN内には常時動いている Raspberry Pi のホストがいるので、ついでにこのホストにDNS機能もやらせることにしてみた。

unbound

unbound がキャッシュサーバ専用でよさそうなのでこれにする。

sudo apt-get install unbound
#/etc/unbound/unbound.conf.d/my.conf   
# See /usr/share/doc/unbound/examples/unbound.conf for a commented
server:
        verbosity: 1
        num-threads: 4
        interface: 0.0.0.0
        interface: ::
        msg-cache-size: 64m
        msg-cache-slabs: 4
        rrset-roundrobin: yes
        rrset-cache-size: 128m
        rrset-cache-slabs: 4
        infra-cache-slabs: 4
        access-control: 192.168.0.0/16 allow
        key-cache-size: 64m
        key-cache-slabs: 4
        neg-cache-size: 64m
        prefetch: yes
        minimal-responses: yes
        incoming-num-tcp: 100
        outgoing-num-tcp: 100
forward-zone:
    name: "."
    forward-addr: 8.8.8.8
    forward-addr: 8.8.4.4
# 自動起動
sudo systemctl enable unbound
# 起動
sudo systemctl start unbound
# ステータス
sudo systemctl status unbound
# ログ
sudo journalctl -r

以下のようなコマンドでクエリ数やキャッシュヒット率が見れる。

unbound-control stats_noreset | grep total

今後

キャッシュヒット率を見つつ、あんまり意味がなさそうなら (数%ぐらいしかヒットしないとか) やめるつもり。

自宅は昼間は誰もいないので、このタイミングでTTLが短いほとんどのキャッシュは無効になってしまう。unbound の prefetch は TTL が残り10%になったときにクエリがくると再問合せする機能なので、クエリがこなければ一切 prefetch はされない。

さらには一番影響がでるブラウザでは、DNS prefetch が実装されているので、体感的にはネットワークの近くにDNSがあっても意味がないことが多い。

自分で DNS キャッシュサーバを運用するコストと釣り合わないかもしれない。

(備考)raspberry pi の ip アドレスを固定

raspi の IP アドレスを固定しておく

#/etc/dhcpcd.conf 
interface eth0
static ip_address=192.168.0.222/24
static routers=192.168.0.1
static domain_name_servers=127.0.0.1
sudo systemctl daemon-reload
sudo systemctl stop dhcpcd
sudo ip addr flush dev eth0 ; sudo systemctl start dhcpcd
sudo systemctl restart avahi-daemon.service 

確認

dig @192.168.0.222 example.com

同一ホストで

sudo unbound-control stats_noreset | grep total
sudo unbound-control dump_cache
  1. トップ
  2. tech
  3. RaspberryPi を家庭内 LAN の DNS キャッシュサーバーに

127.0.0.1 より localhost のほうが書きやすいし良さそう、と思って localhost と書いているとしばしばハマります。

というかなんとなく localhost = 127.0.0.1 と考えがちではないでしょうか? そんなことはないので気をつけましょう。

最近のシステムなら /etc/hosts を確認すると少なくとも2つの localhost エントリを見ることができるでしょう。

127.0.0.1       localhost
::1             localhost 

上は IPv4、下は IPv6 です。localhost はどちらのアドレスにも解決しうるホスト名となっています。

どういうときにハマるか

例えば同一サーバでリバースプロキシを行ってバックエンドサーバと繋ぎこみを行う場合、フロントのリバースプロキシで localhost:5000 と書くと IPv4 IPv6 どちらでアクセスされるか不定です。バックエンドサーバが IPv4 しか bind していないと IPv6 アドレスが選択されたとき接続不可になります。

正しい方法

すべてのサービスで IPv4 IPv6 ともに接続可能にし、ホスト名でアクセスできるようにすること。

非公開な内部向けサーバとかだと割と IPv4 しか使えないようにしがちではないかと思いますが、ちゃんとやったほうが無難です。

次善の策

ホスト名でひける IP アドレスの種類と実際に受けつけるプロトコルの種類をあわせること。

localhost の替わりに 127.0.0.1 か ::1 を使ってプロトコルを明示すること。

localhost に限らない

実際にところは localhost に限らず、ホスト名でアクセスするときには必ず気をつけるポイントです。DNS で IPv4 IPv6 いずれのアドレスも解決できるようにするなら、そのホスト上で待ち受けるサービスは全てデュアルスタックになっていないと、あらぬところでハマったりします。

  1. トップ
  2. tech
  3. localhost と書くと IPv6 対応したときに死ぬことがある

RTX1200 から直接 prometheus 形式でメトリクスを取得できる Lua スクリプトを書いた。

prometheus + grafana のセットアップ (Ubuntu 16.04.4 LTS) | tech - 氾濫原 自宅 raspberrypi への prometheus セットアップとリモートの prometheus との連携 | tech - 氾濫原 とやってきて、自宅内のメトリクスを grafana で表示できるようにしたので、自宅のルーターの RTX1200 のメトリクスをとるようにした。

RTX1200 はユーザー Lua を実行できる環境があり、そこそこ高級なことができる。TCP サーバは簡単に立てられる。HTTP サーバはないが、不特定多数のリクエストを受けるものでもないので、自力で簡単なものを実装した。

Luaスクリプト

https://github.com/cho45/rtx1200_exporter/blob/master/rtx1200_exporter.lua

エンコーディングが sjis なのが注意点。9100 を listen している。IPv6 を listen する方法はないっぽいので、必ず IPv4 でアクセスする必要がある。

出力サンプル

メトリクス名が prometheus のベストプラクティスから外れてるのは、もともと SNMP でとっていた値があるため。

というか SNMP ではとれるけど Lua からは直接とることのできないメトリクスがあるのでちょっと困る。 Lua から自分向けに SNMP 使えばとれると思うが今回やっていない。

# Collecting metrics...
# TYPE yrhCpuUtil5sec gauge
yrhCpuUtil5sec 3
# TYPE yrhCpuUtil1min gauge
yrhCpuUtil1min 2
# TYPE yrhCpuUtil5min gauge
yrhCpuUtil5min 2
# TYPE yrhInboxTemperature gauge
yrhInboxTemperature 46
# TYPE yrhMemoryUtil gauge
yrhMemoryUtil 24
# TYPE ifOutOctets counter
# TYPE ifInOctets counter
ifOutOctets{if="1"} 51255053848
ifInOctets{if="1"} 8057224805
ifOutPkts{if="1"} 43465561
ifInPkts{if="1"} 27396255
ifOutOctets{if="2"} 8411163805
ifInOctets{if="2"} 52401299138
ifOutPkts{if="2"} 25933809
ifInPkts{if="2"} 42718551
ifOutOctets{if="3"} 0
ifInOctets{if="3"} 0
ifOutPkts{if="3"} 0
ifInPkts{if="3"} 0
# TYPE ipSession counter
ipSession{proto="v4"} 59
ipSession{proto="v6"} 35
# TYPE ipChannel counter
ipChannel{proto="v4"} 59
ipChannel{proto="v6"} 35

Lua のデバッグ方法

いまいちベストのデバッグ方法がわからないが、以下のような手順でやった。

以下の upload.sh を保存するたびに実行

#!/bin/sh

PASS=adminpass

cat <<EOF | tftp 192.168.0.1
put rtx1200_exporter.lua /rtx1200_exporter.lua/$PASS
quit
EOF

telnet 繋ぎっぱなしで以下を手動で実行

terminate lua all
lua /rtx1200_exporter.lua
show status lua
  1. トップ
  2. tech
  3. RTX1200 prometheus exporter Lua スクリプト