SNMPマネージャの活用

居室の片隅で地味にお仕事を続けてくれている積層LEDの監視灯があります。よくある「赤・黄・緑」の3色のランプで状態を教えてくれるものです(2色や5色のものもあるのですが3色が多いのではなかろうかと思います)

古いものではありますが、ふいのトラブルを察知するためにはとてもありがたい存在なのです。

積層灯を見上げる写真

■ちょっと使い方を変えてみようかと

この監視灯、世間的にはどう表現したら伝わりやすいのだろう?積層灯とか言ってもピンとこないだろうし3色ランプとでも表現したら良いのかなと微妙に悩むところではあるのですが、姿をみると誰しもが見たことのあるものであろうとおもいます。

ウチで使っているのはパトライト製のネットワークシグナルタワーの15年くらい前のもので、基本的にpingでの死活監視以外の機能は使っていない状態です。

しかし、何の気なしに販売されていた当時のカタログを眺めているとSNMPマネージャとしての機能も含まれているのだとかいう記載がありました。

ということは、定期的にpingが通るかどうかで判定しているのとは別に、ルーターなど監視対象機器からのtrapを受信して警告を発してくれるハズなわけで、pingよりも少し早くきめ細やかに察知できるかもしれないわけですね。

せっかく機能が実装されているならば、使ってみないと気になってしゃーない性質なのでちょっと設定をいじってみることにしました。

居室の片隅で光る積層灯

■まずはSNMPってなんぞや

ちょっとした規模であってもネットワーク構築に携わっていると知らず知らずのうちに目にしているSNMPですが、末尾に「P」と入っているからにはなんらかの通信プロトコルなんでしょうねえ、いつか使うことがあるかなあ?という程度の認識しかないのが普通だと思います。

実際、使わなくてもちゃんと動かす分にはなんら問題はなく、どちらかと言えばSNMPのご厄介になるシーンというのはようするにトラブルが発生している状態なので、できることならご厄介になりたくないプロトコルかもしれません。

トラブルへの対処というのは多くの場合は時間との戦いであったりもしますので(時間が経てば経つほど状況が悪くなるので)いち早く察知できるというのは本来ありがたいはずなのですが。

さて、横道にそれましたがそのSNMPは「Simple Network Management Protocol」という名称の略称になります。その名の通りというわけじゃありませんが枯れた技術として定着しているものです。

■SNMPってなにができるか

さてそのSNMPですが、v1、v2、v2c、v3といったバージョンがあるようで、標準的なものはv2cとされている(とりあえず積層灯がv2cに対応しているからそうなのでしょうと理解)らしいです。
※バージョンが上がるごとにセキュリティが高まり、セキュリティの低いv1とv2はもう使われないようですね

そしてこのプロトコルを使って、監視対象機器のCPUやメモリの使用状態やネットワークの通信状態であるとか、筐体温度はどのくらいまで上昇しているかとった割とハードウェア寄りの情報までこまごまと得ることができます。

しかもネットワークに負荷をかけることのない小さな情報のやりとりで済むのが特徴の1つとされています。

トラフィックやハードウェアの稼働率なども取得できるので稼働ログ的にも使えるようなのですが、そういう日常的な使い方というよりは異常をいち早く察知するという意図でtrapを飛ばすという用いられかたが多いように思います。

■まずはtrap送信側の設定

まずは状態を監視したいルーターにログインし、送信先として積層灯を思い浮かべながら設定します。

snmpv2c host 192.168.xxx.xxx public
snmpv2c trap host 192.168.xxx.xxx
snmp sysname “Router-1”

snmp trap enable snmp all
snmp trap send linkdown LAN2 on

※192.168.xxx.xxxはtrapの送信先となる積層灯のIPアドレス
※ちなみにYAMAHAルーターのコマンドです

という感じが最低限必要な情報になるでしょうか。送信する側の設定内容はいたってシンプルですね。

今回、実験台になってくれるルーターはLAN2ポートを保守用に空けてあるので、trapの設定もLAN2インターフェイスを明示してonにしています。

■そしてtrap受信側の設定

受信側の設定をするために積層灯の管理画面にログインし、

パトライトの積層灯設定画面でSNMPのtrap受信設定

動作設定の項目の中にある「TRAP受信設定」という非常にわかりやすいメニューを開くことになります。

積層灯SNMP受信TRAP設定画面

そして、実際に受信したいものを設定するわけなのですが、一瞬ひるんだのが「TRAP番号」の項目。その下にOIDと書かれた項目があるので、それではこのTRAP番号とやらには何を入れるんだろう?と悩んだわけなのですが、結論としてはここにOIDを入れることになります(むしろvariable bindings1と2は空で良さそうです)

グループ名称は任意の文字列で良いので自分がわかりやすいように「テスト、リンクダウン」とでも入力しておき、

TRAP送信元アドレスは、監視対象ルーターのIPアドレスを入力しておきます。

■OIDはなんだろう?

さて、TRAP番号と書かれている項目にはOIDという識別子を入力すれば良いということは解ったものの、具体的にどういったOIDを入力したら良いのだろうと少し頭を悩ませます。

先述のようにSNMPでは監視対象機器の様々な状態を得ることができるわけなのですが、動作テストも含めて最もわかりやすいのはネットワークのリンクダウンとリンクアップだと思いますので、ここはひとまずLinkDownとLinkUPのOIDを調べます。

ここでも、OIDを調べようとすると標準MIB、拡張MIBと絡んできますがひとまず標準MIBでサイト検索するとある程度まとまった情報が出てきますので、そのなかから必要そうなものをピックします。

1.3.6.1.6.3.1.1.5.3 (LinkDown時)
1.3.6.1.6.3.1.1.5.4 (LinkUp時)

あと、今回ヤマハのルーターからのtrapを活用したいのでヤマハ独自のMIBの中から、

1.3.6.1.4.1.1182.2.3.0.5 (トンネルLinkDown時)
1.3.6.1.4.1.1182.2.3.0.6 (トンネルLinkUp時)
1.3.6.1.4.1.1182.2.1.0.3 (ルーター本体のALARM LED点灯時)
1.3.6.1.4.1.1182.2.2.0.1 (ルーターへのログイン時)

も、いずれ使いそうなのでメモっておくことにします。
もっと詳しくはYAMAHAさんのページも参考になるかもしれません

スクリーンショットには設定3のページ(空のページ)を貼っていますが、実際にはリンクダウンのTRAP受信は設定1、リンクアップのTRAP受信は設定2にそれぞれのOIDを入れています。

さて、受信する項目を入力したら、さらにその下にある動作設定をすることになります。

積層灯SNMP受信TRAPの動作設定画面

動作と言っても設定すべきことは単純で、どのランプを点灯あるいは点滅や消灯させるか、ブザーを鳴らすか、メールを送信するかといったような設定になります。

ただ、今現在すでに3色あるLEDランプのうち赤色と黄色はping監視で使っているので触らないこととして、正常時には点灯したままにしている緑色のランプの設定で遊んでみることに。

点灯時=正常な状態である、
消灯時=監視できていない状態、というのが基本定義なので

点滅1、点滅2という2つの状態はまだ自由に使えることになります。なので今回はLinkDownのtrapを受信したら点滅させ、LinkUpのtrapを受信したら点灯状態に戻すといった2つの設定を行ってみます。

といっても記載する内容は単純で、設定1にLinkDown時のOIDをTRAP番号として入力、設定2にLinkUp時のOIDをTRAP番号として入力、設定1・2いずれのTRAP送信元アドレスにもルーターのIPアドレスを入力し、動作状態は緑色を点滅・点灯とそれぞれ選択して残りは空欄でOK

■いざ実験

さて、送信側受信側それぞれの準備ができたところで、いよいよLAN2に接続したケーブルを抜いてみることにします。

すると間髪をいれず積層灯の緑ランプが点滅をはじめました。どうやら正常にtrapが受信されて設定通りに動いたようです。

ふたたびLAN2にケーブルを接続してみると、これもまた間髪をいれず積層灯の緑ランプが点灯状態にもどりました。しっかりとtrapを受信して区別してくれています。

pingだと60秒間隔で最低でも1周期、ようするに60秒ほどは反応が遅れるわけですがSNMPのtrapに反応するとほぼその瞬間に状態変化があります。さすがに早いですし意外に簡単だなという印象です。

たいていのネットワーク系のトラブルはpingでも検出できますし実用上は支障ないわけですが、SNMPの活用でよりきめ細やかに、たとえばトラフィックが一定値を上回ったりルーターの温度上昇によっても警告を発するといった対応も可能ですし、ネットワーク機器以外にもたとえばプリンタの状態なども監視することができるわけで、業務が止まってしまうほどのトラブルに至るまえに未然に兆候を察知することができるようになります
深堀りしてゆくと応用できる幅が広がりそうではありますね。


消えちゃった動画や写真データの復元は
安心安全な『株式会社パソコントラブル救助隊』へ。
https://hqsecure.net/

決済手数料あれこれ

クレジットカード決済やスマホ決済が日常に浸透してきて、とても便利ですよね。

私も普段の買い物で財布から現金を取り出すというシーンがほとんどなくなり、むしろスマホが無いととても困ってしまうようになりました。

■事業者としては手数料支払いが

さて、クレジットカード決済やスマホ決済などは消費者の立ち位置としてはすごく便利なのですけれど、事業者の立ち位置になると必ず手数料を決済事業者さんに支払わねばならないというコストが発生します。

決済手段の選択肢がほぼ無い状態だとあまり気にはならないのですが、複数の決済手段を選択いただける状態まで環境が整ってくると、はたしてどの手段がコストを抑えることができるのだろうと気になることがあります。

限界までコストを突き詰めていると、時々話題になるのですが飲食店で「ランチタイムはカード決済お断り」なんていうカード会社との契約に違反するお話がチラホラでてくるのですが、事業者がわが現金決済を求める気持ちもよく理解できたりするわけです。

■決済金額によって手数料が変動する

さて、決済手数料というのはだいたいの場合は決済金額の~%という形で決済事業者さんと契約することになります。

たとえば楽天PAYでクレカ決済だと、決済金額の2.95%が手数料として徴収されますし、ヤマト運輸さんのWEBコレクトなら決済金額の5.5%が手数料として徴収されることになります。

この手数料率だけで考えると、手数料率の低い決済手段がもっともコストがかからないのではないかと考えがちなのですが本当にそうだろうか?と思うようなことも現実には多々あります。

■シミュレーションしてみた

さて、複数の要素が絡み合うような計算はエクセルにさせるのが最も理解しやすいので、久しぶりにシートを作ってみます。

決済金額と手数料試算

ざっくりしたシートですが、売上に相当する請求金額と納品先地域を入力すると決済手段ごとに手数料と手取り額が計算されるようなイメージです。

ちょうど決済金額が3万円を下回るかどうかという点が日常でありがちな値だと思われますので、わずかに下回る29500円の請求を例にとります

手数料率は各社で公表されている値送料についても一般契約でサイズ60のお荷物の値としています。

たとえば宅急便コレクト(代引き)の場合には手数料率は4.29%WEBコレクトの場合には5.5%代引きのほうが手数料率は1%以上低くなるわけなのですが、実際の手取りを計算してみると代引きのほうが少ない、なぜ?となるわけです。

よく見てみると手数料率にかかる金額が、決済金額+送料を元に計算されています。そのため決済金額が少し大きくなる影響で振込手数料も増加することとなり、さらには代引き手数料も差し引かれることになります。

その結果、手数料率の低い代引き便よりも、手数料率の高いWEBコレクトのほうがトータルコストが抑えられ、結果として少し手取りが多くなるという計算結果になったりします。

■送料という大きな要素を除いても

同じようなことが実店舗決済のAirPAYと楽天PAYでも生じます

クレジットカード決済で比較した場合、楽天PAYの手数料率は2.95%AirPAYの手数料率は3.24%楽天PAYのほうが手数料率が0.3%ほど低く抑えられます

しかし、楽天PAYで決済した場合には楽天銀行の口座への入金は手数料0円ですが、楽天銀行の口座から他行へ振込みしたりATM出金する際に手数料が発生します(楽天銀行以外へ入金手配した場合には入金手数料で330円が発生しますので、楽天銀行口座へ入金設定するのが最も安上がりです)

この入出金の手数料まで含めてコスト計算した場合には、決済手数料率の高いAirPAYのほうが実はトータルコストが低くなり手取り金額が大きくなるということも起こりえます。

もちろんこれらは1売上毎にコストが発生するという前提に立った単純試算ですので、実運用として複数売上や一定期間の売上をプールしておいてから入出金した場合にはぐんとコストを抑えることになります

■手数料は必ず誰かが負担する

こういったコストが発生するからといって、そのコスト分を商品やサービス料金に上乗せして請求することは基本的にはNGという契約になっていることがほとんどだと思います。

また、道義的にも決済手段によって料金が上乗せされるというのは気持ちの悪いことだと思いますから弊社ではもちろん行っていません。

決済事業者さんの提供している仕組みを活用させてもらっているという点でも、商品・サービス料金からある程度の手数料が徴収されるというのはある意味当然のことでもあると考えます。

なので、自分が消費者に立った場合でもこういったコストはどこかで必ず発生しているものだという認識はしっかり持っておかないといけないのだろうな、なんて思ったのでした。


消えちゃった動画や写真データの復元は
安心安全な『株式会社パソコントラブル救助隊』へ。
https://hqsecure.net/

HR01はDHCPを通さない?

インターネット接続をモバイル回線にだけ頼っている拠点があり、ドコモのHome5G契約でHR01を終段として手前にVPNルーターを配置して部屋内のネットワークを構築しています。

DHCP整理前のネットワーク図

二軍落ちした機材をその都度寄せ集めながら環境をつくっていると、なんとなくこんなごちゃっとした感じになりがちですよね(言い訳モードに入っている)

もともとはHR01で全てをこなしていたところに、HUBを追加し有線ルーターを追加し古い無線APを追加し・・・という流れが図からも滲みだしている感じがします。

■そもそもWi-Fiは2つも要る?

二軍落ちを再配備する場所となっているがゆえに後から追加した無線APはちょっと古いのです。HR01がWi-Fi6に対応しているのと比べて後で追加した古い無線APはWi-Fi5だったりWPA2までだったりといった明らかな見劣りがします

なのでVPNを介する必要がない通信はHR01に繋いだままで良いから、VPNが必要なものだけ有線ルーターを介してもらおうという考えかた。

■DHCPサーバーが2つ

しかし、HR01の柔軟性の低さに時々イラッとするときがあります。

ご利用の方なら気づいているかもしれませんが、HR01はなにかと細かな設定ができず本体内で決め打ちされている様子なのです。

それが顕著にわかるのがGW。
いったんHR01に接続した端末でも有線ルーターでどこに流すか判断させようと考えても、そういった設定が一切できず、なにがなんでもHR01自身がGWになってくれます

そのため役割分担としてDHCPサーバーを2つ(HR01と有線ルーター)存在させることにしてお互いの払い出し範囲を被らないようにという運用をしばらくしてみました。

普通に考えると、接続した端末がアドレスを配っておくれと要求したときに早い物勝ちでどちらかのDHCPサーバーから払い出してくれそうなものですが、ほぼ100%の確率でHR01から払い出されます。

■HR01のDHCPサーバーを止めてしまおう。

いっそHR01のDHCPサーバーを止めてしまえば有線ルーターのDHCPサーバーからアドレス払い出しを受けることができるので、結果としてHR01にWi-Fi接続した端末でも有線ルーターを介しての通信ができるのではないかと甘い期待をしたのです。

奇跡的にもHR01の設定画面にDHCPサーバーを無効にするという項目があったので実験してみました。

しかし、無効にしたとたんにHR01のWi-Fiに接続した端末は同一セグメントに存在するDHCPサーバーからのIPアドレスの払い出しを受けられず通信不能に。有線側につながっている端末はちゃんと払い出しを受けることができるのに。

どうもHR01のWi-Fiに接続した端末がDHCPを呼んでもちゃんと応答が返ってきていない様子です。

似たような使い方を実験されていた方の記事では、他のDHCPサーバーからの応答をブロードキャストするよう設定すれば想定通りに払い出しを受けられるということだそうで。

有線ルーター側にそんな設定の余地があるのだろうかとTelnetでもぐりこみ、念の為にコマンドで

dhcp sever rfc2131 compliant except broadcast-nak reply-ack

などとConfigに記載されていた部分を変更したりしていく通りか試してみたのですがどうも正解には至らないようで断念。

HR01のDHCPサーバーを止めるとHR01のWi-Fi側に接続した端末(なおかつ固定IPアドレス設定ができないもの)は通信不能となる、という事態は回避できないようです。

■あっさりHR01のWi-Fiを無効に

あれこれ理想の形は思い描いていたものの、結局HR01のWi-Fiをオフにしてしまうことに。

DHCP整理後のネットワーク図

すると、古い無線APだけがWi-Fi端末を受け持つことになるので(若干、接続数とスループットの問題は起こりそうだが)経路図としてはスッキリとしました。

ついでにチャンネルも空いたことだしと、電波の出力調整も最小限に絞っていたものを見直して隅々まで安定するレベルに。

わざわざ古い無線APにフル活躍してもらうというのが気がかりだったのでHR01に振り分けていたのだけれど、結論としてはHR01のターゲット利用者が「ややこしい構成を考えないライトユーザーであろう」という認識のもとでのしょぼい仕様なのでやむを得ない

でもそのおかげか、
ルンバくんが定期的にネットワークから切り離されてしまう
ネットワークに接続できません」とか「MQTT接続中
となってしまい使えない症状も、
M5stackの通信が頻繁に途切れる
という症状も
すっきり改善されるというのは予想外に良い効果だったかもしれない。


消えちゃった動画や写真データの復元は
安心安全な『株式会社パソコントラブル救助隊』へ。
https://hqsecure.net/

突然ですが私は下戸です

いきなり何をタイトルにしているのかと思われる向きも多いかとおもいますが、本当に下戸なんです。体質的にアルコールと上手にお付き合いできない

特に話題を絞らないという方針のココですし、飲酒ネタではないのでタブーに引っかかる事もないでしょうからあえて。

■依頼の対価はお酒で

でも、どういうわけか昔から「コイツにややこしい事を頼むときには酒を持っていけば断られなくて済むだろう」と思われがちなようで。

そんなに「酒飲みに見えるのだろうか?」と聞いたら二つ返事で「うんうん」と返されることもあります。まさか下戸とは微塵も思われていない事が多いようで。

なので、珍しい焼酎だったり一升瓶など高そうなアルコール製品と抱き合わせで面倒な相談を持ってこられると、高そうな手土産なのでとりあえず嬉しくは無いが話を聞かないとしかたないかという感じになり非常に微妙な気持ちになります。

そして、いただいたお酒の処理に頭を悩ませることになる

変化球としてIPA(イソプロピルアルコール)を手土産に持参したバリバリの技術者というのも例外にいましたが、これは飲み物ではなく実用品としてぎりぎりセーフかもしれません。
※危険物取扱者の免許は保持してますが大量にあっても困る。

危険物取扱者免状の写真

■アルコールより嬉しいものは

むしろ個人的には花より団子、アルコールよりお菓子、美味い酒よりチョコの方がよっぽど喜びます。

ですがそんなに舌が肥えているわけではないので、高級なチョコを食してもありがたみを感じにくいというかもったいなく。

むしろ手土産ならばそれもそんなに高いものでなく、普通にスーパーで買える紗々あたりが個人的にとても美味だと思いますね。

でもすっかりチョコ製品というのも高くなってしまったので、なかなか自分では買うことが少なくなってしまったのですが、リスカ株式会社のチョコ製品はなかなかお手頃価格でなおかつチョコ感がしっかりしててお買い得だなあと思ったりもするわけです。

わりとコンビニに並んでいるPB商品のなかにもリスカ製造のものを見かけますし。私のような庶民の味方(^^)

リスカ株式会社のしっとりチョコ

■和菓子も良いですね

そのほか和菓子も、なんかカラダに優しく美味しいという印象を強くもってます。

オーソドックスに大福とか安倍川餅とか、羊羹や回転焼き(大判焼きとか御座候とか 地域によって呼び名がたくさんある物の代表格でしたよね)なんかも大好きです。

※時期限定ですが七條甘春堂さんの天の川は美しいですよね

ご褒美的にはイチゴ大福も嬉しいものですが。

あと時々ですが金平糖を食べたくなったりもするので、京都に出かけたときに時間的に余力があれば老舗の緑寿庵清水さんに立ち寄って自分用ご褒美として買って帰ったりもします。

あ、いえ、ここまで書いておいてなんですが、
べつに相談に訪れる方々に手土産を要求しているわけではありませんので誤解のなきようにお願いいたします。


消えちゃった動画や写真データの復元は
安心安全な『株式会社パソコントラブル救助隊』へ。
https://hqsecure.net/

Dreamweaverの動作保証はMacOS11.0まで

なんだかんだでバグだろうっていう不審な動作の多いAdobe Dreamweaverですが、先日の「DreamweaverでGitする」の記事で構築した通りGitをDreamweaverから直接活用する方向での設定を済ませたのですね。

ところが、みごとに高確率でとんでもない不具合にあたることに。

■Git応答という空のダイアログが

その不具合の内容ですが「Git 応答」というタイトルの空のダイアログがPUSHが成功したあとに表示されてしまい、もとのウインドウの操作の一切を阻んでしまうという症状に陥るもの。

上のは正常にpushが済んだ際に表示されるダイアログですが、これをOKして閉じたあとに次のようなダイアログが出てきてしまいます。

これにはOKボタンもなにも存在せず、ESCを押そうが他のウインドウを選択しようがこのダイアログを閉じることができないため、完全に操作不能という状態に陥ります

こうなると、特定のプロセスをキルして乗り切ろうと考えても見当たらず、やむなくアクティビティモニタからDreamweaverのプロセスを強制終了させて閉じるしかありません(当然ながら未保存のデータは失われます)

■Adobeサポートに問い合わせ

せっかくサブスク契約しているわけですし、先日からその料金も上がったわけですし、こういうトラブルのときこそサポートを活用しないともったいない

というわけでAdobeさんのWEBサイトからチャットサポートで相談してみました。

相談したところ、まず1つめに衝撃の回答が「Dreamweaver21.3(問い合わせ時最新版)はMacOS10.14~MacOS11.0までしか動作保証していない」

おいおい、MacOS11ってBig Surじゃないか。何年前のバージョンだよ。いまやMacOSは14系統が主流だし、わたしのアップデートから置いていかれたMacBookですら13.6.3(Ventura)だと言うのに

どうやらDreamweaverは最新のOSをサポートするつもりは無いのか4年ほど前から時が止まっているらしい(愚痴)サブスクなのに

いつまで経っても入力した文字が勝手に消えたり入力していない文字に置き換わったりする面倒なバグが放置されているわけだわ。

■結論、DWでGitは使えん

そして2つめの衝撃は、サポートに提示された対処法を試しているとき。環境設定でGitパスをちゃんと(動作していた)設定にしているにもかかわらずGitが無いとか警告されるように(笑)

もうぐちゃぐちゃですね、これはちょっと毎月課金されているツールとしては酷い。ベータ版とか書いてないよな。

とはいえ、DreamweaverはGitさえ使わなければHTML・CSSの編集には強力なツールであることには違い無いので使い続けるわけなのですが(どのみちターミナルからコマンド操作しますしね)

■Gitの設定を解除しようとしたら

というわけで3つめの衝撃。

動かない機能を有効にしていると仕事の邪魔になるだけなので、サイト管理からGit関連付けを解除しようとしたら、そもそもチェックボックスがグレーアウトしていて解除できない(ポップアップでGitに関連づけられていると表示されるのみ)

こうなるともう、新規サイトとして設定を新たに作り直すしか解決策がなさそうです。

どうもAdobeさんの設計思想なのか、こういった後戻り操作をさせてくれないことが多いように思いますね(Macromediaのときはそんなにややこしく感じなかったのに)

というわけでDreamweaverから直接のGit連携はたった2日で断念することにしたのでした(私の環境だけの問題かもしれないですので参考程度に)


消えちゃった動画や写真データの復元は
安心安全な『株式会社パソコントラブル救助隊』へ。
https://hqsecure.net/