Meraki製品が相応しくない場合

Merakiの機器はクラウド管理ができるため使い勝手が良いと好む人もいます。私も賛成の一方で、Meraki特有の問題があります。

NW知識の汎用性

これは多くのエンジニアにとって当てはまりますが、NWエンジニア初心者やITやNWが専門ではない人には当てはまらないかも知れません。

Merakiは今やCiscoの傘下となっていますが、設計思想や設定方法は大きく異なります。

CiscoのCatalystに慣れている人は使い勝手が悪く感じるでしょう。

つまり、NW知識の多くがMerakiでは通用しません。もちろん技術の基本的なところは共通しますが、設計思想と仕様がこれまでの主流モデルと異なるので苦労します。

JuniperやYamahaのルータもかなりCiscoに寄せているので、その点でもやはりMerakiは独特と言わざるを得ません。

これは私の経験の話ですが、大規模環境でMerakiスイッチが多数あったり、スタックやSTPを使っている場合に、なんともよく分からない動きをします。

某案件で経験して、最終的にはなんとか安定したものの、なぜ安定したのか未だに理解できません。CatalystではこうなるのにMerakiではならない、NW的に問題ないのになぜか接続できない等という事が多々ありました。

その時はスタックを解除したり再構成したり、再起動したりしていたら接続が取れました。

エンジニアとして「理由は分からないが」と言うのは極力避けたいものです。

これは上述の大規模環境の話と似ている部分もありますが、Meraki機器のIPアドレス付与はDHCPが推奨されています。ですが、静的に設定することも可能です。

しかしながら、どうしてもDHCPが優先されるのか、静的アドレスを設定しても違うVLANでIPを取ってきてインターネットに接続してしまいます。

挙げ句の果てにインターネットへの接続を許可していないIPアドレスを掴んで管理できないと言う事象も経験しました。

VLANの数が多数か少数かはあまり関係ないかと思いますが、多数なほどよりランダムにIP取得をしてしまうので、なかなか大変でした。

これも前述の話と一部似ていますが、Meraki機器に静的IPアドレスを振ってもDHCPが優先されてしまう事があります。

管理上、管理セグメントを定めていても違うIPを使われてしまうと管理が破綻します。管理セグメント障害時には良いのかも知れませんが、管理セグメントだけ障害というのもなかなか起きない事象ですし、やはり意図してないIPで通信してしまうのは気持ちが悪いです。

こう言った点を踏まえて、柔軟にMeraki機器のIP設計をするのか、はたまたリスクを承知でしっかり固めるのか検討が必要です。

いずれにしても、これまでの他製品を使ったNWに適用してきた設計思想が使えないのは大変面倒です。私なりのNW設計のベストプラクティスがありましたが、今後はMeraki版のベストプラクティスを考えて行かねばなりません。