Orz日記 by Akio Morita

_ [FreeBSD][IPv6]IPv6 gateway考察

WAN側のIPv6通信は確保したので、LAN側をどうするかの考察

技術的には以下のアイデアがある

• WAN側から提供されるaddress prefixをLAN側で使う (LAN側にglobal unicast addressを付ける)
  • RA proxyによりWAN側のRAをLAN側に転送する
    • YAMAHA等のルーターアプライアンスにある機能
  • WAN側のNICからaddress prefixを切り出して、LAN側NICのrtadvdで配り直す (非常に稀なケースになると思われるが、途中でaddress prefixが変更された場合の対処を考える必要がある)
  • LAN内のDNS上のIPv6アドレスがWAN側のaddress prefix依存になる
    • IPv6初期に提案されていたDNAME/A6レコードによるaddress prefixとホストアドレスの分離は、非推奨になっているぽぃ
    • address prefix変更をトリガーにして、AAAAを動的に合成する実装が必要
• LAN側にRFC4193 unique local unicast addressを与えて、境界ルーターでprefixを付け替える
  • ipfwだとNPTv6が該当
  • LAN内のAAAAレコードは、unique local unicastなので動的な変更を考慮しなくてよい

一番手がかからないのはYAMAHAルーターあたりを買ってくる(ついでにMAP-EなIPv4 over IPv6トンネルも開通する)辺りだが、LAN側にDNSで引けるIPv6アドレスを割り当てるなら次点はunique local unicastによる実装か？

_ [FreeBSD]sys/netinet/libalias/alias_db.cエンバグしてるぽぃ

久々にカーネルパニック(Fatal trap 18: integer divide fault while in kernel mode)で死んだ

バックトレースからsys/netinet/libalias/alias_db.cが怪しい

KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00b27f30b0
vpanic() at vpanic+0x181/frame 0xfffffe00b27f3100
panic() at panic+0x43/frame 0xfffffe00b27f3160
trap_fatal() at trap_fatal+0x387/frame 0xfffffe00b27f31c0
trap() at trap+0x8b/frame 0xfffffe00b27f32d0
calltrap() at calltrap+0x8/frame 0xfffffe00b27f32d0
--- trap 0x12, rip = 0xffffffff808a68bc, rsp = 0xfffffe00b27f33a0, rbp = 0xfffffe00b27f33b0 ---
HouseKeeping() at HouseKeeping+0x1c/frame 0xfffffe00b27f33b0
LibAliasInLocked() at LibAliasInLocked+0x2f/frame 0xfffffe00b27f3470

おそらく当該コードは stable/13 390866d47effe8f5a11f3f852ae891f14dd4d15cで導入されたHouseKeepingの起床レートを処理パケットレートに基づいて調整するコードのコーナーケースと思われる

コーディング的には、kernel modeでの経時処理が重いので可能な限り処理パケット数で起床レートを制御し、直近約1秒の処理パケット数から平均毎秒3回の起床レートとなるようpacket_limitを制御するのが目的だが、パケットレートが低い場合に穴がある模様

• packet_limitの更新コードにたどり着いた時点で、packetsはその時点のpacket_limitの整数倍
• 3 * packet_limit > packets時には、packet_limitが引き下げられる
• packet_limitが3未満のケースでは、packet_limit = 0(非負の整数除算は切り捨て)に設定され、次回の呼び出し時にpackets % packet_limitで整数ゼロ除算で例外になる
• 1packet/secへ向けて処理レートが減衰するケースでは、packet_limitの最短更新シナリオは、1000(初期値)->333->111->37->12->4->1->0で7秒ほどでpanicに至ると推定される

mainも現時点 では、治ってないぽぃ

修正は、packet_limitに下限値を設定しておく辺りか

user spaceのnatdを使っている場合は、デーモンが死んでNATが機能しなくなるものと思われる

void
HouseKeeping(struct libalias *la)
{
	static unsigned int packets = 0;
	static unsigned int packet_limit = 1000;

	LIBALIAS_LOCK_ASSERT(la);
	packets++;

	/*
	 * User space time/gettimeofday/... is very expensive.
	 * Kernel space cache trashing is unnecessary.
	 *
	 * Save system time (seconds) in global variable LibAliasTime
	 * for use by other functions. This is done so as not to
	 * unnecessarily waste timeline by making system calls.
	 *
	 * Reduce the amount of house keeping work substantially by
	 * sampling over the packets.
	 */
	if (packets % packet_limit == 0) {
		time_t now;

#ifdef _KERNEL
		now = time_uptime;
#else
		now = time(NULL);
#endif
		if (now != LibAliasTime) {
			/* retry three times a second */
			packet_limit = packets / 3;
			packets = 0;
			LibAliasTime = now;
		}

	}
	/* Do a cleanup for the first packets of the new second only */
	if (packets < (la->udpLinkCount + la->tcpLinkCount)) {
		struct alias_link * lnk = TAILQ_FIRST(&la->checkExpire);

		CleanupLink(la, &lnk, 0);
	}
}