タグ付けされた質問 「metro-ethernet」

7
OSPFをメトロイーサネット全体に展開するのは理にかなっていますか?
顧客のために複数のブランチサイトを相互に接続する必要がある場合、通常、信頼できるキャリア経由のMPLS VPNをお勧めします。各サイトのCEはアップストリームPEとBGPを話し、各サイトは独自のプライベートASNで番号が付けられます。BGPは無数のトラフィックエンジニアリングツールを提供し、隣接はnサイトに対してn + 1に制限されているため、これは非常に便利です(+1はコロ環境です)。 しかし、最近、メトロイーサネットソリューションに対する顧客の関心が高まっていることに気付きました。多くのお客様は、共通のメトロエリア内にブランチサイトを持ち、MetroEの見積もりは、同じ速度の回線のMPLSサービスよりも数百ドル(USD)安くなっています。これは魅力的ですが、メッシュトポロジをハブアンドスポークに変えることを避けながら、レイヤー2バックボーン全体に最適なルーティングを確立する方法がわかりません。 BGPは、メッシュ接続を維持するために、ブランチサイト間の隣接関係のフルメッシュを必要としますが、これは明らかにスケーラビリティの観点から望ましくありません。もう1つのオプションは、IGP、つまりOSPFを展開し、すべてのサイトがWANを介して隣接関係を形成することです。私は各サイトを独自のエリアとして扱いたいと思いますが、これはやり過ぎのようですが、各サイトからアドバタイズされたルートを要約する機能を保持したいと思います。これはエリア境界でのみ実行できます。 これは理にかなっていますか?この方法でOSPFを展開するときに注意する必要がある警告はありますか(たとえば、LSAフラッディングを無効にすることを検討する必要があります)。または私が見落とした別の解決策はありますか?

2
低メトロイーサネットTCPスループットのトラブルシューティング
セットアップ レイヤー2ネットワークとして存在するいくつかの専用線を借りました。つまり、データセンターに1本の大きなパイプがあり、リモートサイトには小さなパイプがあります。レイヤー2ネットワーク内では、何でも好きなことができます。おそらく802.1adを使用して、ネットワーク内の各顧客に個別のネットワークを提供します。AFAICSほとんどのサイトはプレーンVDSLで接続されています。 各サイトにルーターを配置し、各サイトに独自のVLANを割り当てることにしました。したがって、DCのファイアウォールには、サイトと同数のVLANが定義されています。したがって、各サイトは独自のVLANでオンアドレス範囲を使用します。 ネットワーク図: 問題 現在、スループットの問題に直面しています。 サイトからDCへのFTP転送の実行は、回線速度である約10Mb / sで正常に機能します。 DCからサイトへのFTP転送の実行は、6Mb / s以下ではうまく機能しません。 どちらが転送を開始するかは関係ありません。唯一一貫したことは、1つの方向がうまく機能していないことです。残念なことに、それはサイトへの方向です。これは、ターミナルサーバークライアントを使用したいときに最も必要な帯域幅だからです。 転送から約10秒で、スループットが低下します。スニッフィング時にDUP ACKが表示されます。プロバイダの側でレート制限につながる可能性があるのはどれですか?? (現在、彼らには手がかりがありません。エスカレーションする前に私たちが過失になっていないことを確認したいです) 注リモートサイトは何らかの理由で10Mbに制限されています。メトロポートへの切り替えを10Mbに設定しても解決しません。実際、それは最悪です(最大30 KB / s)。100Mbに設定しても正常に機能しますが、すでに概説した問題が発生し始めています。1Gでも同じです。 問題のキャプチャはここからダウンロードできます: * http://178.63.11.6/dc-to-remote_dc-side.pcapng * http://178.63.11.6/dc-to-remote_remote-side.pcapng 診断 画像には、エラーの詳細が記載されたWireshark IO Graphが表示されます。 左側:DCからサイトへのFTP転送 右側:サイトからDCへのFTP転送 反対側が転送を開始した場合(つまり、リモートから取得するのではなく、DCから取得した場合)、問題は変わりません。 ここで問題になると思われるものをお楽しみください。 更新#1(上記に統合) 更新#2(更新) これは輻輳制御のものでなければなりません。 DCからリモートに10G-> 1G-> 100M-> 10M-> 1Gリンクがあることに注意してください。<-動作していません したがって、他の方向では逆になります:1G-> 10M-> 100M-> 1G-> 10G。<-元気 最初の「1G-> 10M」は、リモートサイトで「見えない」10Mであり、アップリンクポート速度を含むすべてが1Gに設定されています。 ただし、DCでの100Mbpsは実際の100Mbpsであり、インターフェイスは物理層で100Mbpsに設定されます。 私は今iperfを使用しました: …

2
キャリアのVLANタグが自分のものと重複している
私は3サイトのネットワークを持っています。1つはデータセンターのコロコロで、他の2つはオフィスです。先ほどインストールした新しいメトロイーサネットサービスでは、オフィスに向かうコロコロサイトのトラフィックが、オフィスに応じてVLAN 10または20にある必要があります。 残念ながら、彼らは私の入力なしでVLANを選択し、それらは私が現在使用しているVLANと重複しています。coloでVLAN 10が使用されており、vlan 20がいずれかのオフィスで使用されています。 VLANの番号を付け直したり、キャリアに番号を付け直したりせずに、これを機能させるためにできることはありますか?私が読んだことによると、私のスイッチはトランショナルVLANをサポートしていないようです。 coloサイトには、ipservices iOS 15.0(2)SEを搭載したCisco Catalyst 3560-Xスイッチがあり、オフィスでは、ipbase iOS 12.2.somethingを搭載した3560/3750を実行しています。

1
単方向パケット損失
最近、いくつかのMetroE回路(L2接続)を100Mbpsから1Gbpsにアップグレードした後、一部のサイト間で大きなファイル転送が失敗することに気付きました。ただし、転送は方向にのみ失敗します。たとえば、次の例を考えてみましょう。 から->へ A-> B =失敗 B-> A =成功 A-> C =成功 C-> A =成功 B-> C =成功 C-> B =成功 各サイトは、サイトにあるL3スイッチの背後にあるルーティングされたセグメントです。L3スイッチはプロバイダーのCPEメディアコンバーターに接続し、CPEメディアコンバーターはファイバーを介してプロバイダーのネットワークに接続します。静的ルーティングは、L3スイッチ間で使用されます。 *Site A* *Site B* L3 Switch <-> CPE <--- Provider ---> CPE <-> L3 Switch | CPE | L3 Switch *Site C* プロバイダーはCPEからの回線のエンドツーエンドのテストを実行し、損失は報告していません。ただし、転送が失敗する前に、ホスト上のパケットキャプチャに重複したACKが多数表示されます。 式からL3スイッチを削除し、2つのホストを各サイトのCPEデバイスに直接接続すると、ファイル転送は正常に完了します。 Host A <-> CPE <--- …

2
2つのJuniper EX 4200間のMetro-EリンクでのVLANロードシェアリング
Cisco 2960とCisco 3560(アクセスレイヤースイッチ)に接続された2つのサイトのコアスイッチとして、Juniper EX 4200があります。偶数番号のVLANでは、1つのジュニパースイッチがルートブリッジになり、奇数番号のVLANでは、他のジュニパースイッチがルートブリッジになります。 コアスイッチを接続するCoxおよびVerizon Metro-Eリンクがあります(両方のサイトでJuniper EX 4200)。 VSTPを使用してVLANロードシェアリングを実行したいのですが、どういうわけか期待どおりに機能しません。一部のVLANをCOXを通過させ、一部をVerizonを通過させたい。Coxに問題がある場合、すべてのVLANトラフィックはVerizonを通過し、その逆も同様です。RSTPは、両方のジュニパー製スイッチでも有効です。 両方のMetro-Eリンクを一緒に立ち上げると、すべてのCiscoアクセスレイヤスイッチのログメッセージにMACフラッピングが表示されます。コックスのみが接続されている場合、すべてが正常に動作します。Verizonのみが接続されている場合、すべてが正常に動作します。しかし、COXとVerizonの両方が接続されていると、ネットワークが混乱し、すべてのCiscoスイッチでMACフラッピングが発生します。すべてのCiscoスイッチはPVSTを実行しています。 COXリンクとVERIZON Metro-Eリンクの両方がアクティブなときにVSTPが機能しないのはなぜですか。 更新(2013年12月9日):===== ジュニパーのKB:KB18291およびKB15138に基づいて、私は次のことを行いました。 すべてのJuniperおよびCiscoスイッチで共通のネイティブVLAN 50(およびシャットダウンVLAN 1)を有効にし、CiscoスイッチがネイティブVLANのJuniperに接続するトランクポートを構成しました。(これは、スパニングツリーBPDUがCiscoとJuniperの間でネイティブVLANを介して交換されるためです)。デフォルトでは、CiscoネイティブVLANはvlan 1であり、JuniperにはネイティブVLANはありません。そのため、ジュニパーはBPDUを理解せず、対応するVLANにフラッディングするブロードキャストトラフィックとして扱います。このため、シスコとジュニパー間のSTPは収束しません。 シスコスパニングツリーモードをPVSTからRapid-PVSTに変更しました(ジュニパーでは、シスコスパニングツリーモードをデフォルトからPVSTからRapid-PVSTに変更することをお勧めしています)。Rapid PVSTは、ジュニパーのスパニングツリープロトコル「VSTP」とうまく収束します。 Juniperのドキュメントに従ってRSTPプロトコルステートメントを削除 ジュニパー製スイッチのVLANおよびネイティブVLANに対して入力されたvstpインターフェイスプライオリティコマンド CoxリンクとVerizonリンクが同時にアップすると、両方のサイトでジュニパーコアスイッチにハングオフする一部のCiscoスイッチがダウンすることがわかります。また、ジュニパーでは(「show ethernet-switching interfaces」コマンドを使用して)、Ciscoスイッチが接続されている一部のインターフェイスがSTPによってブロックされていることを確認しました。 誰かが何が起こっているのか理解できますか?
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.