L2スイッチ

セグメントを構築する機器 スイッチングハブ

用途はリピーターハブと同じで、あるポートに届いたイーサネットフレームを他の全てのポートへ転送する。ただし帯域を有効利用するため転送されてきたポートと MAC アドレスの対応を記憶して、次回から必要のないポートに転送することをやめる。

ルーター

セグメント間を接続する機器

IPヘッダを解釈し、ルーティングテーブルから次に転送すべきルーターへパケットを転送する。

頻出事例

(IPv6) ルーターを介したコンピュータ同士の通信 (外部ネットワークなど)

こちらも ARP 部分が ICMPv6 でおきかわる。ルーターの場合はネットワーク接続時の要求や、定期的にブロードキャストされる Router Advertisement メッセージから MAC アドレスがキャッシュされているため、基本的にルーター MAC アドレスが既知のものとなる。

ref

• https://github.com/google/bbr/blob/master/Presentations/bbr-2017-02-08-google-net-research-summit.pdf
• BBR: Congestion-Based Congestion Control とは
• Google Cloud Platform Japan 公式ブログ: 輻輳制御の新アルゴリズム TCP BBR を GCP に導入

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

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

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

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

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

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

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