2401785_ja-JP

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

2401785_ja-JP

2401785_ja-JP

SJA1110経由のPTP

こんにちは、

私たちはSJA1110スイッチを介して接続されたPolarFire SoC GEMでPTPをデバッグしています。

我々は以下のことを観察した。

  • Layer 2上のPTP(ptp4l -2)はスイッチで受信されます(入力カウンターが増加します)が、転送はされません(出口カウンターが増加しません)。
  • PTP over UDP (ptp4l) は、同じブリッジパスを介して正しく転送されます。
  • 通常のイーサネットトラフィック(ICMP/ARP)も正しく転送されます。

SJA1110で、レイヤ2 PTPフレーム(宛先MACアドレス01:1B:19:00:00:00)をブリッジポート経由で転送するために、特別な処理や追加の設定が必要ですか?レイヤ2 PTPの転送に関して、既知の制限事項はありますか?

また、PolarFire SoC GEMでは、UDP over PTP(ptp4l)は完全にサポートされ推奨されているのでしょうか、それともレイヤー2のみがサポート/推奨されているトランスポートなのでしょうか?

何かアドバイスをいただければ幸いです。

Re: PTP over SJA1110

こんにちは、 @Ankur_pixl さん

典型的なgPTPや時間認識ブリッジのケースでは、スイッチがすべてのgPTPフレームを通常のマルチキャストトラフィックとして透過的に転送することは期待されません。 通常の流れは、スイッチがグランドマスターからgPTPフレームを受け取り、内部Cortex-M7上で動作するgPTPスタックを通じて処理し、接続された下流デバイスに向けて適切なタイムスタンプを持つ独自のgPTPフレームを生成するというものです。
 
SJA1110通常、レイヤー2オートモーティブプロファイル向けに設定されており、PTP宛先MACアドレスは01:80:C2:00:00:0Eです。このアドレスは802.1AS/gPTPスタイルのレイヤー2トランスポートに使用され、そのようなフレームは通常、単にブリッジされる通常のマルチキャストトラフィックではなく、スイッチのPTP/gPTP機能によって処理されます。
 
イングレスカウンターが増加する一方で、エグレスカウンターが増加しないというあなたの観察は、レイヤー2のPTPフレームがスイッチに受信されているものの、通常のブリッジパスを経由して転送されていないことを示唆しています。一つの考えられる説明としては、使用されるPTPマルチキャストMACアドレスがSJA1110設定(例えばGeneral Parametersテーブル、DPI構成、L2ルックアップテーブル、その他のPTP/トラップ関連設定項目)によってマッチングされ、フレームが期待される外部エグレスポートに転送されるのではなく、ホストポート、特に内部Cortex-M7ホストにトラップされるというものがあります。
 
これにより、PTP over UDPや通常のイーサネットトラフィック(ICMP/ARP)が正しく転送される理由も説明できます。これらのフレームは、同じレイヤ2 PTP/gPTP分類ルールに一致しないため、通常のブリッジトラフィックとして処理されます。
 
SJA1110の設定において、以下の点を確認してください。
 
1. スイッチでどのPTP宛先MACアドレスが設定されているか、特に一般パラメータテーブルで。
2. PTP/gPTPフレームがホストポートにトラップされるように設定されているかどうか。
3. 内部Cortex-M7ホストがgPTPスタックを実行しているか、トラップされたPTPフレームを受信しているか。
4. 使用される宛先MACアドレスが01:1B:19:00:00:00か01:80:C2:00:00:0Eか。
5. L2ルックアップテーブルまたはマルチキャスト転送設定に、この宛先MACアドレスを必要な外部ポートに転送するエントリが含まれているかどうか。
6. このトラフィックに関して、入力ポートと出力ポートが同じ VLAN および転送ドメインに属しているかどうか。
 
SJA1110をgPTP/時間認識ブリッジとして使用する場合、通常想定される構成は、元のgPTPフレームを単純に透過的に転送するものではありません。スイッチはgPTPタイミングドメインに参加し、接続されたデバイスに対して対応するgPTPメッセージを生成します。
 
もしSJA1110を生のレイヤー2 PTPフレームの単純なイーサネットブリッジとしてのみ使用する意図であれば、このトラフィックに対してPTPトラップや特殊処理を無効化または回避し、対応するマルチキャスト宛先MACアドレスをL2転送設定で明示的に許可する必要があります。
 
PolarFire SoC GEMについては、推奨または完全にサポートされているPTPトランスポートモードについて断言することはできません。SJA1110の観点からすると、ブリッジパスが許可する場合、UDP上のPTPは通常のIP/UDPトラフィックとして転送される可能性があります。しかし、これは必ずしもPolarFire GEMドライバーがハードウェアタイムスタンプでUDPトランスポートをサポートしたり推奨されたりしているという意味ではありません。対応するPTPトランスポートおよびタイムスタンプモードについては、PolarFire SoC GEMドキュメントまたはMicrochipサポートで確認してください。
 

よろしくお願いいたします。

パベル

Re: PTP over SJA1110

こんにちは、

宛先MACアドレスは01:1B:19:00:00:00です。私たちはLinux DSAブリッジでスイッチを使っており、Cortex-M7コアを操作したり設定したりすることはできません。

L2構成でこのトラフィックを通過させるにはどうすればよいでしょうか?ブリッジmdbを使用しましたが、うまくいきません。エントリはインストールされ、オフロード済みとして表示されますが、フレームはポート間で転送されません。これはCortex-M7コアで明示的に設定する必要がありますか?

当社のシステムに関する追加情報:

当社のMACアドレス/ポート構成は以下のとおりです。

bridge mdb add dev br-EPS port epc2-uplink grp 01:1b:19:00:00:00 permanent
bridge mdb add dev br-EPS port t1-6        grp 01:1b:19:00:00:00 permanent

これらは bridge -d mdb show ではオフロードされていると表示されますが、一方のポートに到着した L2 PTP フレームはもう一方のポートには転送されません。

重要なのは、スイッチのポートの一つに動作するCPUポートがないことです。これは純粋に2つのポート間のルート(ポート間転送)として動作し、そのパスにはホストやCPUポートは含まれません。予約済みマルチキャスト01:1b:19:00:00:00はデフォルトでマネジメント/CPUルートに閉じ込められているようで、そのルートはここでは利用できないため、フレームは転送ではなくドロップされているのではないかと推測しています。

CPUや管理ポートに頼らずに、この予約済みPTPマルチキャストMACをハードウェア内で2つのユーザーポート間で転送するスイッチの設定方法についてアドバイスいただけますか?

-- アンクル

Re: PTP over SJA1110

こんにちは、 @Ankur_pixl さん

宛先MACアドレス01:1B:19:00:00:00は、IEEE 1588レイヤ2 PTPマルチキャストアドレスです。これは、通常、SJA1110 gPTPオートモーティブプロファイル構成で使用される802.1AS / Automotive Profile gPTP宛先MACアドレス01:80:C2:00:0Eとは異なります。
 
あなたの説明からすると、これは標準的なLinuxブリッジMDBの問題とは思えません。MDBエントリが正しくインストールされ、オフロードされたと報告されていても、フレームが通常のマルチキャスト転送パスに到達しない場合があります。
 
おそらく、SJA1110ハードウェアやSJA1110 DSAドライバーが、通常のL2マルチキャスト転送決定が適用される前に、この宛先MACをPTP/制御フレームとして分類しているのが考えられます。その場合、フレームは2つのユーザーポート間で直接転送されるのではなく、CPUやマネジメントパスにリダイレクトされることがあります。
 
これは、観察された挙動を説明するだろう。
 
- 入力カウンターが増加し、フレームがスイッチに受信される、
- MDBエントリがインストールされ、オフロード済みとして表示されます。
- しかし、通常のポート間転送が適用される前にフレームがCPUやマネジメントルートに閉じ込められている可能性が高いため、エグレスカウンターは増加しません。
 
ポート間転送パスにCPUやマネジメントルートが存在しない場合、トラップされたフレームは事実上ドロップされる可能性があります。
 
Cortex-M7についてですが、Linux DSAブリッジ経由でスイッチを使用し、内部Cortex-M7上でgPTPスタックを実行・制御していない場合、通常はCortex-M7アプリケーションから設定するものではありません。このユースケースでは、関連する構成はLinux DSAドライバーと、そのドライバーによってプログラムされたスイッチハードウェア構成によって所有されます。
 
ただし、01:1B:19:00:00:00 に対して専用の PTP/制御フレームトラップ ルールがアクティブになっている場合は、「bridge mdb」だけでは不十分な場合があります。このトラフィックをハードウェア上で2つのユーザーポート間で直接転送するには、スイッチの設定で以下を満たす必要があります:
 
1. 01:1B:19:00:00:00 の PTP/制御フレームトラップはこのトラフィックに対して無効化またはバイパスされており、
2. 必要なユーザーポートに向けて有効なL2マルチキャスト転送エントリが01:1B:19:00:00:00に存在します。
 
現時点では、SJA1110 DSA構成でそのようなルールが有効になっている場合、標準の`bridge mdb`コマンドだけでは、下位レベルのPTP/制御フレームトラップルールを上書きすることはできないと考えられます。
 
次のステップとして、SJA1110 DSAドライバーまたはBSPがPTPハードウェアのタイムスタンプを有効にしているか、01:1B:19:00:00:00のMACフィルター/PTPトラップルールをインストールしているか確認してください。そのようなルールが存在する場合、解決策は単に実行時のLinuxブリッジMDBコマンドだけでなく、ドライバーレベルの変更やスイッチの静的設定変更を必要とする可能性が高いです。
 
以下の情報を教えていただけますか?
 
- Linux BSP/カーネル版
- SJA1110 DSAドライバのソースベースライン、
- 「bridge -d mdb show」の完全な出力、
- 関与するDSAポート名および物理スイッチポート番号、
- SJA1110 DSAドライバーでPTPハードウェアのタイムスタンプが有効かどうか、
- 可能であれば、DSAマスター/CPUインターフェース上でパケットキャプチャを行い、レイヤー2のPTPフレームがCPUパスにトラップされているかどうかを確認すること。
 
この情報をもとに、フレームがPTP/コントロールトラップパスに消費されているか、あるいは別のL2マルチキャスト転送制限があるかをさらに確認できます。

よろしくお願いいたします。

パベル

Tags (1)
No ratings
Version history
Last update:
yesterday
Updated by: