クライアントにサービスを提供するためのチャネルを展開したエリアの1つで、新しくインストールされたPBXを接続し、E1ストリームを介して確実に接続する必要があるクライアントがいたという問題に直面しました。 セントラルノードとクライアントのリモートプレゼンスポイントの間では、ギガビットイーサネットのみがレンタルされたファイバーを介して送信されたため、E1チャネルをさらに転送する必要がありました。 通信ノード間の光ファイバの減衰が大きいため状況は複雑であったため、30 dB（120 km）の長距離SFPモジュールがスイッチにインストールされ、単一の専用ファイバで動作しました。 問題の可能な解決策を分析した後、いくつかの可能なアプローチが提案されました。
1）もう1本の光ファイバーをレンタルし、その上にE1光モデムをインストールします。
2）CWDMシステムの通信ノード間の光回線をシールします。
3）作業用データネットワーク（TDM over IP、 en.wikipedia.org / wiki / TDMoIP ）に疑似回線伝送デバイスをインストールし、E1をイーサネットに変換してから、変換された形式のオブジェクト間で転送し、中央ノードで逆変換を実行します。
4）ギガビットイーサネット伝送とE1伝送を組み合わせ、光回線での高減衰での動作をサポートするデバイスを見つけます。
最初のソリューションは、追加のファイバに定期的なサブスクリプション料金が必要だったため、すぐに破棄されました。 2番目のオプションは非常に適しているように見えましたが、CWDMマルチプレクサーと、CWDMマルチプレクサーに接続するためのE1ポートとSFPの形のアップリンクポートを備えたメディアコンバーター（マルチプレクサー）の追加コンポーネントをインストールする必要がありました。 E1モデムに固定E1ポートがある場合、モデムをCWDMにシステムに接続するために、アクティブな波長コンバータを追加インストールする必要があります。 この決定はやや面倒で、これも破棄されました。
3番目のソリューションは非常に現実的でしたが、クライアントは「E1 G.703ストリームを変換および構造変更なしで、また疑似ワイヤデータ転送技術を使用せずに送信する必要がある」という1つの必須条項との合意の締結を要求しました。 したがって、彼らもこの決定を拒否することにしました。 最後のオプションは残りました。
デバイスの要件が策定されました：ギガビットイーサネットポート、E1ポート（拡張可能な場合は少なくとも2倍）、統合長距離光ポート、または光モジュールをインストールするためのSFPポートの存在。 私の経験では、すべてのデバイスがモジュールをサポートしているわけではないため、最後の基準は長距離光モジュールのサポートでした。
インターネットで短い検索を行った後、適切なデバイスを見つけ、問題を解決するためにラボでテストに使用しました。 適切な機器を受け取りました：RCMS2912-4 / 8T1E1GE 2マルチプレクサ。 （ http://www.raisecom.su/equipment/e1ethopt/multiservpdh/rcms2912/ ）、マルチプレクサをインストールするためのシャーシ-RC001-1D-WP 2個 （ http://www.raisecom.su/equipment/chassis/rc0011d/ ）。 デバイスへの完全なセットには、英語の説明が記載されたディスクもありました。
ボード上のRCMS2912マルチプレクサには、ギガビットイーサネット銅線ポート、4つのE1ポート、および光モジュールを取り付けるための2つのSFPポートがありました。 フロントパネルには、E1ポートのアラーム、イーサネットポートのステータス、光ポートのステータスを表示する複数のインジケータも表示されます。
私たちが最初に抱いた疑問の1つは、デバイスが通信センターの稼働中のスイッチにインストールされた既存の長距離SFPモジュールで動作するかどうかでした。 同じ予備のSFPが用意されていたため、ネットワークに機器を設置せずに「テーブルで」テストを実行できました。 回路が組み立てられました。
パケットは、pingユーティリティを使用してスイッチ1からスイッチ2に送信されました。 テストは成功し、SFPは新しい機器で安全に動作し始めました。
ping 172.10.2.165 count 100 waittime 1
中止するには、CTRL + Cを入力します。
100、8バイトのICMPエコーを172.10.2.165に送信すると、タイムアウトは1秒です。
!!!
-PING統計----
100パケット送信、
100パケット受信、成功率は100％（100/100）
往復（ミリ秒）最小/平均/最大= 0/0/0
次に、E1伝送のデバイスの動作を確認する必要がありました。 残念ながら、当時の「ミニラボ」にはE1テスターがなく、2つのCISCO 2610ルーターを使用してE1をチェックし、次の回路を組み立てました。
テストの準備における唯一の困難は、CISCO 2610とRCMS-2912を接続するためのE1ケーブルを準備することでした。 これを行うには、インターネット上のCISCOモジュールのピン配置を上げて、Raisecomマルチプレクサーのピン配置を監視する必要がありました。 上記のスキームに従ってデバイスを接続した後、チャネルが上がり、パケットがルーター間で正常に通過し始めました。 テストに合格しました。
ギガビットイーサネットチャネルの帯域幅のテストを実施することが決定されました。 ギガビットイーサネットネットワークカードを備えた3台のコンピューターのみが利用可能でした。 ソフトウェアがiperfを使用したため。 組み立て済みの回路
2台のPC間。 結果は
次に、回路を組み立てました。
そして結果が得られます
したがって、デバイスは負荷に非常によく対応し、テストはその後、〜450 Mbit / sの速度で作業チャネルで繰り返されました。
デバイスの追加機能の1つは、SFPポートの冗長性のサポートでした。 この機能により、デバイスは、最初の光ポートのリンクがドロップした場合に2番目の光ポートに切り替えることができます。
この機能の動作も確認することにしました。 長距離モジュールの追加ペアがなく、20 km SFPが使用され、回路が組み立てられました。
テストの場合-PC_Aはサーバーモードでiperfをオンにし、PC_Bでは次の設定でUDP上のiperfテストをオンにしました。
PC_Bでは、UDPプロトコルを使用してテストを実行するために、iperf（ http://sourceforge.net/projects/iperf/ ）がクライアントモードで起動されました。
目標は、2つの光チャネルを切り替えるときにパケット損失が発生するかどうかを判断することでした。 次に、光パッチコードを引き出して所定の位置に取り付けました。 結果は次のとおりです。
テストでは、テスト中にUDPパケットが失われないことが示されました。 デバイスはタスクを正常に処理しました。
すべてのテストの後、動作中のネットワークにデバイスをインストールすることが決定されました。 48時間のテストでは、デバイスが正常に機能することが示され、その後クライアントを接続しました。
この解決策は非常に有益であることが判明しました-問題を解決するための他のオプションと比較した場合、約60,000ルーブル。