最近の変更サイトマップ

NETGEARのLAGのAdmin ModeメニューはLAGの有効/無効指定を意味するらしい

ネットギアのL2スイッチのLAG設定に「Admin Mode」なる謎の項目がある。

 XS512EMのLAG設定画面

スイッチの内蔵ヘルプを見ても“Admin Mode - Select Enable or Disable to set the Admin Mode.”という何の役にも立たない情報しかなく、全く以て意味がわからない。確実な情報は見つけられなかったんだけど、結局のところ機能のオン/オフを切り替える程度のものっぽい。もちろん、Enableが有効でDisableが無効ね。

機種は違うが公式フォーラムでは、Enableだとトラフィックが流れてDisableだと全く流れない、という回答になってるが、少なくともXS512EMのLAG設定のに関してはLAGのEnable/Disableにしか影響してなさそう。実際、Admin Modeの状態を問わずパケットは流れてるし、LAGを設定してもDisableならLAG StatsuはDownのまま、Enableにして初めてUpになった。

フォーラム回答の挙動は、マネージドスイッチ以上で設定できるポート毎のAdmin Modeの解説なんじゃないかって気がする。いずれにせよ、もっと分かりやすい名前にしとけよと思うけど…。

参考サイト

ブリッジネットワーク接続の仮想マシンを使う時はport-securityに気をつける

ブリッジネットワーク接続の仮想マシンがあり、その通信がCiscoのCatalystスイッチを通るネットワーク構成の時は、スイッチのポートセキュリティ設定に気をつけなければならない。さもないと仮想マシンが通信できなくてハマる。VMとLAN内の物理マシンとでARP RequestとReplayは通っており、互いのARPテーブルは正しく作られているように見えるのに通信が出来なくて超ハマる。3ヶ月くらい悩んでた…(ヽ´ω`)

port-securityが有効なポートでは、最初に通過したMACアドレス以外のフレームが破棄される。

ここで、ブリッジ接続の仮想マシンのフレームは、物理マシンが繋がってるポートに流れる事になる。つまり、1ポートに対して複数のMACアドレスが関連付けられるわけだが、port-securityが有効だと最初の通信のMACアドレスしか有効にならない。それは殆どのケースで物理マシンのMACアドレスになるので、VMは一切通信出来なくなるという寸法。逆にいえば、物理マシンの通信ならOKなので、NATでVMの通信を物理マシンの通信に変換してやれば通信できるということだ。実際、NAT接続でなら通信出来てた。

対策方法は次の3つ。

  1. port-securityを無効化する
  2. 信頼するMACアドレスを静的に追加する
  3. 学習するMACエントリの上限を引き上げる(デフォルトでは1個)

自宅ネットワークならport-security無効化が簡単で影響も殆どないかと。

この問題を調べてる時に、ブリッジ接続が上手くいかないと嘆いているロシアのフォーラムを見つけたんだけど、結局使ってるホスティング業者を変えたら動いた!って結末だったので、恐らくダメだった方の業者のスイッチで似たようなセキュリティ設定になってたんだろうと思う。

原因がわかって全てが繋がった感じ。通信だけにね(´・∀・` )

参考サイト

Cisco Catalystに繋いだPCが通信可能になるまで時間がかかるのはSTPのせい

最近、有線LANで繋いでるMacBook Proをスリープから復帰させると、暫く通信できない状態となる現象に見舞われていた。今までは全く問題なかったファイルサーバへの再接続もタイムアウトしてマウントが解除されてしまい、著しく使い勝手が悪い。Skype先生も激おこの模様。

こんな表示、初めて見たわい。

暫く何でかなーと思ってたが、そういえばL2SWをSG200-08からCatalyst 2960G-8TC-Lに変えたことを思い出した。スイッチを変えただけで、再リンクアップ時の挙動が変わるかいな!と半信半疑でググってみたら、Catalystはデフォルトでスパニングツリーが有効となっていて、ポートがフォワーディング(通信可能)状態になるまで30〜60秒かかるそうな。ネットが使えるようになるまでの体感時間と一致するし、原因はこれで確定だなー。言われてみれば、ネスペの勉強でそれっぽいことやった気がする…。

というわけで、クライアントを繋ぐポートはスパニングツリー設定をportfastにすればおkっぽい。

spanning-tree portfast
spanning-tree bpduguard enable

2行目のbpdugurdは、当該ポートでBPDUを受信した場合にポートをブロックするための設定。間違ってL2SWが繋がれたりループ接続された時に、ループ構成になることを防止する。自宅ネットワーク程度なら設定しなくても大して問題ないだろうけどさ。

やっぱり、実際に状況に遭遇すると理解が一気に進むもんですな。

参考サイト

OpenSSHとSOCKSの組み合わせが凄い

会社でSkypeが禁止されてしまった。セキュリティ対策の側面もあるが、ルータの負荷軽減という面が一番大きいように思う。実際、前の会社ではSkypeのせいでルータがよくダウンしていた。

Skypeが使えないと友達や他社の知り合いとのやり取り、副業のやり取りなど何かと不便なので、どうにか使えないものかと調べてみたらSOCKSを使えば行けそうとな。OpenSSHがSOCKSプロクシ機能を持ってるので、SSHで繋がる自分鯖を外部に持っててSSHの疎通さえできれば、ポート転送との合体技で何も考えることなく使えるのが素晴らしい!素晴らしいを通り越して恐怖すら覚えると同時に、昔の人も同じような状況に陥って編み出したんだろうなぁと少し親近感(恐らくもっと崇高な目的だったろうから、自分の状況と比べるのはおこがましいが…)。

んで、試しにやってみたらマジチョー簡単にSOCKS経由の自宅鯖経由でSkypeが繋がった。マジパネェ……。ついでに、WebブラウザもSOCKSプロクシ設定することで、自宅回線経由でネットができる。ぁゃιぃサイトも見放題だね!

もう全部の通信アプリがSOCKS対応すればいいのに(´・ω・`)

FreeBSDでVirtualBoxを動かしていると巨大ファイルの転送でCannot allocate memoryが出る

FreeBSD 10.1-RELEASEな自宅ファイルサーバからMacにファイルをコピーすると「予期しないエラーが起きたため、操作を完了できません(エラーコード -50)。」が発生してコピーに失敗する現象に長らく苦しめられていた。経験的にファイルサイズが大きいほど発生確率が高く、数百MBくらいまでのファイルなら問題ないが、2GBを超えるとまずアウトっていう。鯖→Macの場合AFP(Netatalk 3.1.7)でもCIFS(Samba 4.2.5)でも発生し、鯖→Windowsの場合は言うまでもなくCIFSしか使えないが、所々詰まりながらも一応成功するといった具合。

失敗時はNetatalkのログに「Cannot allocate memory」が必ず記録されている。発生場所は大体{fork.c:913} (error:AFPDaemon): afp_read{dsi_stream.c:424} (error:DSI): dsi_stream_read_fileのどっちか。メモリたんねーと言われましても、32GB積んでるtopで見ても余裕のよっちゃんイカで数GBレベルで残ってますし…。もう全くわけがわからないよ!本格的に原因を探ろうとsshで各種情報をモニタリングしながらコピーしたら、今度はsshdまでCannot allocate memory吐いて接続切れるし……。

ドライバの不具合?NIC/L2SW由来の不具合??もしかしてケーブルが腐ってる???などなど、疑心暗鬼ロードを爆走していたが、ようやく、ついに!遂に!!原因がわかったッ!!!!

犯人はヤス何とVirtualBox VirtualBox実行中はnetgraph関連のメモリが不足しやすく?なるっぽい。ここここで同症状が報告されており、/boot/loader.confnet.graph.maxdata=65536を追加すればおkと書いてあった。

このカーネルパラメータはnetgraphのデータキューの最大確保数を表すものらしい。同様に非データ用のnet.graph.maxallocなんてのもある。それぞれ/usr/src/sys/netgraph/ng_base.cで定義されていて、コメントが若干怖いことが書いてあった。

static int maxalloc = 4096;/* limit the damage of a leak */
static int maxdata = 512;  /* limit the damage of a DoS */

下手に大きくすると問題発生時に被害が拡大しそうな雰囲気。ま、外部公開してなきゃそんなに気にしなくてもいいだろうけど。

ついでにdmesgLimiting open port RST response from 208 to 200 packets/sec.なるログも出ていたので、/etc/sysctl.confに以下を追加。

net.inet.icmp.icmplim=2000

肝心のloader.confも一応。

net.graph.maxdata=65536
net.graph.maxalloc=65536

上記設定で1~6GBほどのファイルを100GB分くらいコピーしてみたら、何の問題もなく完了した。普通に動くって素晴らしい。

参考サイト

start.txt · 最終更新: 2016-05-07 17:46 by decomo
CC Attribution-Noncommercial-Share Alike 3.0 Unported
www.chimeric.de Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0