第4のbe...、テーブル
今fedora 20な鯖で色々遊ぼうとしていて、
[fc20] == SIT == [R1] --- [R2]
見たいな感じにトンネル張ってfc20の中のdockerに曲げようとしたりしていた。
R1からの疎通に関しては問題なく出来ていたのだが、R2からテストしてみたところ全く通らなかった。
戻り経路は入れてなくて、とりあえずdockerだったり、そこら辺のインターフェイスにパケットが出現することを期待していた。
ところがtcpdumpで各所を眺めてみていたが、トンネルifには出現するが、他のところには一切出てこなかった。
fc20ではfirewalldが動いたが、トンネルもdockerもfirewalldのどのzoneにも属していなかったので直接(v6で遊んでたので)ip6tablesを眺めることにした。
まずは思いつくところとして、FORWARDとINPUTチェインの先頭にLOGを仕込んでみたが現れず。
それよりもっと前の段階だとどこだろうと、有名な
この図を眺めてnatテーブルやmangleテーブルのPREROUTINGに仕込んでみるがかすりもしなかった。
mangleテーブルですらパケットの切れ端が見えず、どこで落ちているか全く見当がつかなかった。
第4のテーブルとRPF
いよいよわからなくなってしまったが、netfilterのflowの図を知ったのは結構前だと思いだし、もしかしたら更新とかされているのでは？と、もう少しflowを探してみたところ、こんなのを発見。
rawテーブル...だと...？！？
今までnetfilterはテーブルが3つあると教えられて来たし、テーブルは3つだと説明している所が殆どで、第4のテーブルの出現には衝撃を受けた。
早速rawテーブルのPREROUTINGを眺めてみると、
# ip6tables -t raw -vL Chain PREROUTING (policy ACCEPT 3857 packets, 650K bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT ipv6-icmp any any anywhere anywhere ipv6-icmp router-advertisement 236 12108 DROP all any any anywhere anywhere rpfilter invert 3861 650K PREROUTING_direct all any any anywhere anywhere Chain OUTPUT (policy ACCEPT 1890 packets, 838K bytes) pkts bytes target prot opt in out source destination 1895 839K OUTPUT_direct all any any anywhere anywhere Chain OUTPUT_direct (1 references) pkts bytes target prot opt in out source destination Chain PREROUTING_direct (1 references) pkts bytes target prot opt in out source destination
なんか書いてある...
入力パケットのしょっぱなに通るPREROUTINGの2行目を見ると、rpfilterの文字が。
rawテーブルのこと知らなくてもRPFと言われたら分かった。
試しにPREROUTINGをwatchしながらR1からパケットを投げてみると案の定このポリシーのカウンタが増えていった。
ということでRPFなので経路を入れると普通に通った。
# ip -6 r avia dev
ちなみにmain以外のルーティングテーブルに入れてもRPFを通るようになる。
まとめ
- rawテーブルの存在
- firewalldは*tablesを手で書いていた時代よりも今のご時世に合ったルールを書いている
- マルチホームするときはパケットを見つけるのに苦労する
Docker内でTUN/TAPを使うときのメモ
Dockerコンテナ内でTUN/TAP IFを使う用途が出て最初上手くいかなかったのでその時のメモ。
使ったベースのイメージは公式(?)の fedora:20
/dev/net/tun が無い
$ docker run -ti fedora:20 bash bash-4.2# ip tuntap add tun0 mode tun open: No such file or directory bash-4.2#
まず最初に躓くのはこれ。まぁちょっとググったら分かるんだけど、何が"No such file or directory"なのか教えてくれないのでわかりづらい。
最近の環境だと大体しょっぱなからdevfs周りは整備されているから気づきづらいかもしれない
bash-4.2# mkdir -p /dev/net bash-4.2# mknod /dev/net/tun c 10 200 bash-4.2# chmod 666 /dev/net/tun
マジックナンバーはまぁkernel内部の話だから仕方ないのかなと思う。
rootでip tuntapしても怒られる
bash-4.2# ip tuntap add tun0 mode tun ioctl(TUNSETIFF): Operation not permitted bash-4.2#
ホストでSecureOS関連は動いていないので(ｺﾞﾒﾝﾅｻｲｲｼｶﾜｻﾝ)rootでも蹴られたのは解決までちょっとかかった。
docker runは実行時に--privilegedというオプションを渡せて、これで特権が必要なアクセスができるようになる。
$ docker run --help [14-08-31 23:00]
Usage: docker run [OPTIONS] IMAGE [COMMAND] [ARG...]
Run a command in a new container
(((snip)))
(use 'docker port' to see the actual mapping)
--privileged=false Give extended privileges to this container
--restart="" Restart policy to apply when a container exits (no,
ということで
--privileged付きで実行して、mknodすればいいことがわかったので、
$ docker run --privileged -ti fedora:20 bash bash-4.2# mkdir -p /dev/net bash-4.2# mknod /dev/net/tun c 10 200 mknod: '/dev/net/tun': File exists bash-4.2# ls -l /dev/net/tun crw-rw-rw- 1 root root 10, 200 Aug 31 14:04 /dev/net/tun bash-4.2#
どうやら--privilegedが付いていると/dev/net/tunは作られるようだ...
結論
- 基本的に--privilegedを付けてrunすればいい
- ただ、Dockerfile内とかで/dev/net/tunが存在している必要がある場合はmknodするしかない
- ところで、docker buildには--privilegedがないけど途中で必要なときどうすればいいんだろう
Cisco c2811に1GBのメモリを乗せてみると...
いろいろあってDDR ECC 512MBなDIMMを複数枚手に入れたので、自宅にあったc2811に挿してみた。
ちなみにサポートされているメモリの最大サイズは768MB*1で、c2811はスロットが2本あるので手元で最大1GBにできることになる。
PCとかは最大~GBとか書いてあっても挿せば公称最大より増やせたりするけど、ルータはどうなんだろうと思って挿してみた。
This platform does not support 1 GB Memory Total Memory is Restricted to 768 MB c2811 platform with 786432 Kbytes of main memory Main memory is configured to 64 bit mode with ECC enabled
なるほど、プログラム上の問題なのかハード的な問題なのかは知らないけど768MBにしっかり丸められるらしい。
CentOS 7リリースに寄せて
Ubuntuのリリースがあっても、GCCのリリースがあっても取り立ててトラフィックは増えないのに、CentOSのリリースがあるだけでとんでもないことになっている。
以前から日本のCentOS依存度が桁違いに高いと実しやかに囁かれていたが、事実であったことが証明されたようだ。
とりあえず、現在のftp.tsukubaの状態はこんな感じ
これはworkerの数で、赤がactiveにトラフィックを吐いている奴ら。
平時は左側の方の大体20~30ぐらいなんだけど、ピーク時には10倍ぐらいのworkerが仕事してた。
トラフィックはこっちで、対外線は1GbEなので、8割方埋まった感じ。
トラフィックが多い事自体はさほど問題ではないんだけど、かといってユーザが増えるとGbEが埋まってしまうのでそれ以上サービスできないというのがつらい。
あと、CentOSでmirrorを固定するのはどうなんだろうっていう。
まぁ、こういう時のためにミラーってあるんじゃないの？っていうのは十分わかるんだけど、fastestmirrorがあったりするところはそういうところを使って欲しいかなっていうのが感じる。
逆に、mirrorを指定しないといけないUbuntuみたいなのはちゃんと設定して欲しいし(jp.ubuntuなんかいつもhitoさんがﾋｨﾋｨ言ってる気がする...)。
jaistは緊急にクールダウンしてるし、iijとかはスッカスカって言ってるし、うちんとこは上に書いたようにまぁ出そうと思えば未だ出る。naraはまだsyncできていないって言ってた。
twitterで割とそういう情報今はとれるから、リリースノートと一緒にそういう人たちを眺めていると、まずそもそも自分が幸せになれると思う。
(rikenはちょっとわからないし、kddilabも中の人は知らない...)
まぁつまり、もうすこし、自分が使っているものに興味を持ってもいいんじゃないかなって思った。
-- 1:38追記
もう少し長いレンジで普段のトラフィックを眺めるとこんな感じ。異常なのがまぁなんとなくわかってもらえると思う
OSPF+VRFで困ってること
いろいろあって、vrfしてるところでospfを喋りたくなって
vrf definition vrf1 description vrf1 ! address-family ipv4 exit-address-family ! interface Loopback0 vrf forwarding vrf1 ip address 203.0.113.72 255.255.255.255 ip ospf 72 area 192.0.2.0 ! interface FastEthernet0/0 vrf forwarding vrf1 ip address 192.0.2.253 255.255.255.0 ip ospf 72 area 192.0.2.0 ! router ospf 72 vrf vrf1 router-id 203.0.113.72 log-adjacency-changes !
みたいな事した時に、
cisco2.osaka#sh ip os Routing Process "ospf 72" with ID 203.0.113.72 ... Connected to MPLS VPN Superbackbone, VRF vrf1
ってなってしまって、area 0がMPLS Super-Backbone扱いになってしまう。そのせいで、本来のarea 0から流れてくるLSAがなんか無視される。
LSDB眺めるとType5 LSAとして記録されてるけどribには乗らない。
MPLSを喋りたいわけではないので困った。
VyOSでOSPFv3を喋るときに注意しないといけないこと
VyOS 1.0.3で起こった
OSPFはMTUを揃えないといけないのは周知の事実だけど、VyOSはなんというか全体的にv6を特別扱いしてて、別オプション見て下さいm9m9m9ということが多くて、今回もそういうのにハマったという話。
対向が光Pなところにあるので、mtuが結構削られてしまうし、デフォルトだとそういうことしてくれないのでやるしかない。
例えば
address 192.0.2.0/30 address 2001:db8::/126 description tu-1.cisco1.osaka.flast.jp encapsulation gre ip { ospf { network point-to-point } } ipv6 { ospfv3 { } } local-ip 203.0.113.1 mtu 1414 multicast enable remote-ip 203.0.113.2 [edit interfaces tunnel tun0]
みたいな感じでやると、v4のOSPFはふつうにMTU 1414で喋ってくれるけど、v6の方は確か1476とかでしゃべり始める
ciscoはv4とv6でそれぞれmtu設定できるし、そういう感じだろうと思ってたけどv6自体は1414で動いてるっぽい。
で、OSPFv3は専用のオプションがあって、
ipv6 { ospfv3 { ifmtu 1414 } }
こうする。
うーん、、
