ビリングカードを使って友達になった話

ハブラー、またこんにちは！ 昨年、私は1つの記事を書きました。その後、新しい記事を書く試みが何度かありましたが、うまくいきませんでした。 最後に、多かれ少なかれ形成された考えが現れました。それを本格的な記事として形式化しようとします。 それは、デバイスを使用すること、より正確には、使用する機器のデータベース、地理的な場所、使用する課金をどのようにリンクできるかについてです。 興味のある人-猫の下。







残念ながら、それがどのように始まったのか思い出せません。 入社時には、Quantum GISはすでに使用されていて、部分的にネットワークがマッピングされていました。 私は仕事に関連してKugisに精通しなければなりませんでした-購入したプロバイダーで使用するすべての機器を（仕事に就いたプロバイダーにのみ）配置するため。 その時、私はカードが何に使われるのか理解していなかったと言わなければならない-まあ、何も、私の意見はすぐに反対に変わった。



原則として、すべてがシンプルで、4つのレイヤーがあります。

• デバイス（スイッチ、メディアコンバーター、サーバーなど）;
• 論理接続（信号の発信元）;
• カップリング、スプライスカセット;
• ケーブル：光学および銅線（高速道路として使用する場合）。

Postgre SQLの2つのテーブル。1つ目はポイントを保存するため、2つ目は行用です。



クラッチ、スイッチ、または重要なクライアントは、タイプフィールドによって定義されます。 当時、いくつかのタイプがありましたが、将来起こりうる問題について誰も考えませんでした。



しばらくして、デバイスが適用されました。 イベントは、各タスクに繰り返し戻り、ナットを締めるたびに繰り返されるため、イベントの年表を伝えることはできません。 いずれにせよ、適用されたデバイスは特に有用な情報を提供しませんでした。 デバイスはローミングを続け、ポート番号は変更されました（つまり、25番目または28番目のポートで側面にスイッチを接続するインストーラーを意味します）。 概して、その時点でいくつかの問題領域を見ることができました-高速道路および生い茂ったセグメントとしてのUTPの使用（1つのスイッチから最大40人が接続され、この家で電気が失われたとき、最大30人がインターネットなしで残っていました）住宅）。 すでにこの段階で、ブランチマネージャーがこれらの在庫をなくすためのタスクが設定されています。



カードの操作に関しては、愚かなデバイスにpingを実行し、利用できないデバイスを赤色で着色したZabbixのみを使用できました。

前の記事で書いたように、UTMの機能を強化した新しいシェルを作成する作業が進行中でした。 購読者の住所をスペースを含むコンマで分割すると、集落、通り、家のリストが届きました。 このリストを使用して、独自のアドレスベースを取得しました。 そして、標準テーブルUTMに-ユーザーはhouse_idフィールドを追加しました。これにより、略語やタイプミスなしで正しいサブスクライバーアドレスを家まで取得できました。 新しいシェルでは、サブスクライバーアドレスは、単一のテキスト入力ではなく選択のセットになりました。 はい、ところで、KLADRは加入者のパスポートに書かれているものと一致しないため、使用しませんでした。



使用済みアドレスのリストを受け取ったら、マップ上のデバイスのアドレスを整理します。 したがって、house_idが一致する特定の数のサブスクライバーとデバイスを取得しました。 すでに何か。 この情報を分析した後、単一のデバイスをリストしていない家のリストを取得し、そこに複数の加入者が接続されています。



私たちの場合、vpn接続を介してインターネットへのアクセスが提供されたことを完全に忘れてしまいました。そのため、特に購入したプロバイダーのスタッフの一部が船外に出たときに、あるプロバイダーが別のプロバイダーに吸収された場合、使用する機器にギャップがあります。



そのため、デバイスのない家と加入者のいる家のリストがあります。 各ケースは一意であり、銅線が隣の家に移動し、管理されていないスイッチが接続されているなどです。 すべての問題領域が特定され、解決されます。 新しく発見された銅フリップ-光学部品の代替品。 次に、別のトピックに進み、上記の要約を繰り返します。これらのタスクに繰り返し戻り、その結果、ネットワークの状態に関する100％の知識を得ることができました。



次に、プロセスの論理コンポーネントについて話す価値があると思います。 一般に、スイッチのセットアップに関する別の投稿の概要を説明することはおそらく価値がありますが、このトピックのいくつかの側面を示すこともできません。このトピックを別に開きません。



大きくなりすぎたセグメントを特定できたという事実について言えば、すでにいくつかの標準を特定していると思います。 はい、そうです。 私はそれらを簡単にリストしようとしますが、何かはっきりしない場合は、コメントで尋ねて、喜んで答えます。

1. 機器はネットワーク192.168.x.0 / 24にあります。
2. 各192.168.x.1スイッチは、所有するギガビットポートの数と同じ数のセグメント（24以下）を定義します。 たとえば、D-Link DGS 3627G-24セグメント。 x-ネットワーク番号（各L3で増加する）を見てみましょう。
3. 各セグメントは、240個以下の加入者ポートを持つ10個以下のデバイスで構成されます。
4. 各セグメントはスイッチから始まり、そのIPアドレスは原則に従って形成されます：192.168.x.y0、ここでyはセグメントが接続されているL3ポートの番号です。 たとえば、IPアドレスが192.168.37.1のL3スイッチの場合、ポート19のブッシュは192.168.37.190のスイッチで始まります（つまり、最初のデバイスのアドレスの最後の数字は常に10の倍数になります）。
5. セグメント内の残りのスイッチ（管理対象の10個のうち残りの9個以下）は、アドレス192.168.x.y1-192.168.x.y9を受け取ります。
6. セグメントの最初のスイッチは、このセグメントに接続されているサブスクライバーのIPアドレスを次のように設定します。10.x.y0.n（nはサブスクライバーのシリアル番号）は、セグメント内のサブスクライバーの数とともに増加します。 いくつかの制限を追加しました。nを10未満にすることはできません（1つはゲートウェイであり、万が一に備えて残りを予約しておきます）。 192.168.37.190-192.168.37.199スイッチに接続されたサブスクライバーは、アドレス10.137.190.10-10.137.190.249を取得します。
7. 管理ネットワーク全体が個別のvlanに移動され、vlanは各サブスクライバセグメントにも割り当てられます（これらはこの記事とは関係がないため、ここでは取り上げません）。

したがって、各セグメントでは理論的に最大240のサブスクライバーを接続できますが、実際にはそのような数はありません（最大数は50〜60のサブスクライバーで変動します）。



これで、ネットワークはリストされている要件を満たしています。 はい、これらの要件には欠点がないわけではありませんが、それでも完全に管理および構造化されたネットワークが得られます。 gponの実装に関連して、いくつかの調整が行われますが、それらについては詳しく説明しません。



これらの仮定が形成された時点で、pikeコマンドによってアドレスがスイッチに割り当てられました。 当初、ある管理者が1つの場所にスイッチを設定し、別の場所にスイッチを設定した結果、同じIPアドレスを使用していた場合がありました。 これには何か関係がありました。



ただし、セグメンテーションに加えて、ネットワーク全体で鉄操作の統一モデルをグローバルに定義する必要があります。 スイッチを構成する方法を教えられたので、それは私の記憶にはっきりと置かれました。 さまざまな鉄片の設定例を含むテキストファイルがいくつかあり、設定の特定のデバイスごとに、いくつかの基本的に同一のハードウェア（たとえばDES 3028と3200-28）が異なって設定されていました。 ここではなく、時間設定があります。 ACLがあり、ありますが、異なっています。



2011年、トヴェリ地域で激しい雷雨が発生し、ネットワーク全体のスイッチポートの一部が燃え尽き、ネットワークは30〜40％になりました。 スイッチの頭脳は苦しんでいませんが、巻線ポートがトリックを行ったため、彼女は寝ました-プロセッサに100％の負荷がかかり、スイッチはもはや私たちと通信したくないのです。 2週間の眠れぬ夜（誇張なし）-インストーラーはスイッチをオフィスに持ち込む時間がないため、設置場所のスイッチがしばらくの間作動し、バッファーからストームコントロールを設定するまでしばらく待っていなければなりませんでした。 この例や他の例が彼らの仕事をした-他の標準が形成された スクリプトはネットワーク全体に必要な設定を埋め、問題はなくなりました。 はい、昨年はすべての中継スイッチでUPSを設置しましたが、その前後の違いは説明できません。 Zabbixの呼び出し回数は減りました。 停電の問題を解決することに加えて、彼らは雷雨の問題も解決しました-スイッチよりもRapanを変更する方が安価です。



私たちはそれを理解しました。 次の論理ステップは、スイッチポートのMACアドレスを削除することです。 加入者のMACアドレスがわかっているため、誰がどのポートに含まれているかを判別できました。 浅瀬が再び浮上した。 管理された24ポートスイッチ、7つのサブスクライバ、1番目のポートに2番目、7番目に3番目、そしていくつかのポートが分散していることがわかります。 ええ、再び5ポートハブ。 ええ、はい、シールドのインストーラーは、フロアの2番目のサブスクライバーにutpをドラッグしないように設定しました。 排除します。 整理整頓します。 サブスクライバーが再バインドします。 私たちは観察するか、むしろ前進します。 バム！ 戻って いずれかの都市では、取引に参加しているインストーラーは、新しいサブスクライバーをオンにしたときに接続するだけであるため、時間を短縮し、既に稼働しているサブスクライバーをポートから引き出します（視覚的に表示されています-動作しています）、そしてこのポートに新しいものを含めますどこでも作業できます。 彼らはこれに対して責任を負いません。 別のインストーラーがアプリケーションをポップアップします-サブスクライバーはインターネットを失いました。 その理由は明らかだと思います。 彼らはそのようなリュイリーを枝の頭と彼の口に挿入し、これらのビジネスマンの何人かは去った。 残りの良いレッスン。 スクリーンショットを（遅延を検索するために）どこかに保存しました。数日かかりました-7人のサブスクライバーが1つのポートを訪問しました（この方法で新しい家が含まれました）。 今後は、システムを既にテストした時点で、サブスクライバーのアドレスを選択するときに、特定のスイッチのみが提供されたと言います。 そして、スイッチの選択-マーク付きのポート（無料/バーンアウト/ビジー/ハブ）から選択するように提案されました-すなわち 任意のポートを選択できますが、警告が表示されます。 ポートが選択されるとすぐに、システムでポートが焼き付けられていない場合、ポートを有効にするコマンドがスイッチに送信されます。 多くの側面がありますが、私はそれらに注意を払いません。 一般に、この都市では、創設者の許可を得て、このシステムを含めました。 インストーラーは石鹸で実行されました-インターネットを失ったすべての加入者をチェックしました。 はい、それは、例えば、加入者に関しては失礼であり、私は通常、毎月の支払い義務を果たす加入者との実験の熱烈な反対者ですが、すべてが彼らのために行われました。 そのため、数日以内に、ポートへの加入者の緊密な結合を受け取り、規制に従ってインストーラーを強制的に動作させました。 ポートバインディングのトピックを要約すると、impbバインディングはネットワーク全体で作成され、未使用のポートはすべてオフになっていると言えます。 各加入者について、ポート移行と言うことができます。







先に進む前に、すでに述べたことに戻り、何が達成されたかを示し、解決されるべきものを特定したいと思います。

私たちが持っています：

• デバイステーブル。
• 集落（ここではエリアと地区）、通りと家（または他のオブジェクト）を持つ3つのテーブル。
• サブスクライバーのテーブル。

上記の仮定から、鉄のIPアドレスが加入者のIPアドレスを決定すると判断します。 加入者のテーブルでは、デバイスをIPアドレスとして保存します。 ただし、IPアドレスは、デバイステーブルに格納されているデバイスのパラメーターの1つにすぎません。 その中の主な識別子は常にgidでした。 ただし、gidは変更を意味します。デバイスは削除でき、同じIPアドレスが割り当てられた状態で新しいデバイスがインストールされます。 ところで、私は現在このタスクに取り組んでいます。



ポートを焼けているとマークします。より正確には、デバイスが修理のために与えられ、マークが「復元」されるまで、ポートはオンになりません。 しかし、修理のためにデバイスを送信すると、カードから取り外すことができ（可能性があります）、すべての情報が失われます。 今日、私たちは、どの分野とどこがより重要であるかを知りません。 残念ながら、すべてのデバイスがシリアル番号を持っているわけではありません（私の意見では、デバイスが消去されたsnで返された、もちろん紙ではありません）が、誰もが必要なmacを持っています。 したがって、PostgreSQLトリガーを使用して、すべてのフィールド（およびgid、ip、sn、mac）を示すすべてのイベントを作成します。 焼けたポートのマークは、mac-addressにバインドされたテーブルに保存されます。



さて、地図について。 当初、誰もがクギスにポイントを置くことができました。 現在、この操作はデータベースのトリガーによって禁止されています。 ハードウェアに関するすべての作業は、Webインターフェイスに転送されます。 「倉庫」という概念があり（ブランチオフィスの数に応じていくつかあります）、デバイスの追加が特定の人に許可され、デバイスのMACアドレス、シリアル番号、モデルが示されます。 私が言ったように、くしゃみはログに書き込まれます。 さらに、Zabbixは定期的にハードウェアからすべてのパラメーターを削除します。そのため、スイッチを不正に交換すると、サブスクライバーが動作できなくなり、ヘッドにピストンが挿入されます。 前回の記事へのコメントには、私が覚えている限りでは、そのようなシステムを構築することは不可能であるというコメントがありました。 おそらく。 ナッツを締め、加害者を罰し、それだけです。



さらに、デバイスのIPアドレスは一般に魔法の変数です。 構成ファイルの形成時を含む、いくつかのシステムで監視されます。 はい、この作業をスクリプトに移行しました。 スクリプトはip-addressに設定を作成しますが、これまでは記入するだけでしたが、将来はあまり見られないように自動的に記入されます。 そのため、デバイスを目的のポイント（将来の展開の場所）に移動する際にマップ上で予備的な準備が行われなかった場合、構成は生成されません。 だから私は次のポイントに行きました。



実際には、最初は、マップ上のこれらのすべてのライン、ポリゴン、およびポイントは、いかなる方法でも接続されていませんでした。 OSMの裏付けがあり、上で書いた4つのレイヤーがありました。それだけです。 いくつかのトリガーを走り書きして、ポイントのジオメトリを変更し（デバイスを読み取り）、描画時にスティッキングを設定すると、デバイスへの接続線をスティッキングできました。 したがって、デバイスのマップ上を移動すると、デバイスとの「リンク」の接点も変更されます。 いわゆるリンクは、いくつかの方法で機器に結び付けられています（光学とカップリングのように）。 まず、幾何学的に-線の始点または終点はデバイスポイントの座標と一致する必要があります。 次に、dstart、dstartport、dend、dendportの各フィールドがあり、このリンクがどのデバイスとポートからどのデバイスとポートに行くかを決定します。 私はこのタスクをいじる必要がありました-描画されたすべての線、すべてのデバイスをチェックし、形状、入力された値をチェックしてから、トリガーを掛けて結果を楽しんでください。



デバイスの座標を変更する前の画像：



および後：





スイッチポートのMACアドレスを分析し、デバイスとサブスクライバのMACアドレスを知ると、これらのリンクのどの情報が信頼できないかを確認できます。 このシステムのおかげで、スイッチ間を流れるトラフィック、高速道路に使用されるポート、転送されるフォークなどを視覚的に確認できます。 など この情報はすべて、デバイス構成の作成時にも使用されます。 次に、2番目のサブスクライバを管理対象スイッチのポートにバインドするには、接続するデバイスをカードに指定し、管理対象スイッチからこの愚かな鉄片へのリンクを設定する必要があります。 何をすべきか、そのような状況があります-25番目のサブスクライバーとポート24ですが、これについて知る必要があります。 そうしないと、サブスクライバをポートにバインドすることが不可能になるため、impbレコードが作成されず、このサブスクライバは機能しません。



実際、これを記事の終わりと呼ぶことはできませんが、あなたは何ができますか？あなたはあなたの娘の後に行かなければなりません（今日は幼稚園では短い日です）、そして私が一言で下書きにそれを保存し、再び戻ったら、私が書いたものを削除します。



すでにいくつかの小計を提供しているので、詳細については繰り返しません。 2つの完全に接続されていないシステムを1つに接続することができ、その結果、機器が自動的に構成されました（各スイッチに3種類の構成があります）。 もちろん、これだけではありません。

• 使用されるオブジェクトのタイプ（カップリング、スイッチなど）は2回分割されました（基本クラス、および各クラスのより詳細な実装）。
• マップ上のデバイスを使用して、OSMからハウスIDを計算し、そこにosm_idとosm_geometryを追加して独自のハウステーブルを拡張しました（したがって、興味のあるハウスの編集がわかります）。
• 彼らはOSMプロジェクトに存在しない家の一部を与えました。
• 1つのスイッチが複数のセグメントに参加する可能性が追加されました（これは、2つのプロバイダーが同じスイッチを使用する場合です）。
• vpnからipoeへのサブスクライバーの転送（mac-addressによるバインドのみ）。

他にもたくさんあります。



前回のように記事が多少ぼやけていることがわかりましたが、社内で発生するすべてのプロセスを明確に説明することは想像できません。 トピックでさらに詳細な検討が必要な場合は、お問い合わせください-回答します。