Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

第32章 ネットワーク

ip6mr がすでに登録されていないデバイスを登録解除しても、ネットワーク動作は継続します

以前は、IPv6 マルチキャストルーティング (ip6mr) コードが、すでに登録されていないデバイスを登録解除しようとしていました。その結果、ネットワーク動作が停止するバグが syslog に報告されました。この更新により、ip6mr は、 すでに未登録としてマークされているデバイスを登録解除しなくなりました。その結果、syslog でバグは報告されなくなり、ネットワーク動作は説明されたシナリオで継続されます。(BZ#1445046)

VTI 経由で大きなファイルを送信しても失敗しなくなりました

以前は、Virtual Tunnel Interface (VTI) を介して大きなファイルを送信すると、VTI が Path Maximum Transmission Unit (PMTU) を処理しないために失敗していました。その結果、PMTU サイズより大きいサイズのファイルは送信できませんでした。この更新により、PMTU 処理が追加されました。その結果、Tx パスで PMTU を更新できるようになり、前述の問題は発生しなくなります。(BZ#1467521)

IPv6 カプセル化を使用した L2TP が名前空間で機能するようになりました

以前は、IPv6 カプセル化で Layer 2 Tunneling Protocol (L2TP) を使用すると、名前空間がサポートされませんでした。その結果、L2TP を名前空間で使用できなくなりました。この更新により、IPv6 カプセル化を使用した L2TP が名前空間を認識するようになり、前述の問題は発生しなくなります。(BZ#1465711)

ARP エントリーのフラッシュが失敗しなくなりました

以前は、不完全または失敗した Address Resolution Protocol (ARP) エントリーをフラッシュしようとしても効果がありませんでした。その結果、不完全な ARP エントリーがそこに残り、場合によってはシステムやネットワークのデバッグに問題が発生しました。この更新により、不完全または失敗した ARP エントリーを削除できるようになります。その結果、ユーザーは期待どおりに ARP テーブルを取得できるようになりました。(BZ#1383691, BZ#1469945)

クラスフルキューイング規則で cls_matchall を使用しても、カーネルがクラッシュしなくなりました

以前は、matchall 分類子 (cls_matchall) はパケットに classic オプションを割り当てませんでした。その結果、階層トークンバケット (HTB) やクラスベースキュー (CBQ) などのクラスフルキューイング規則 (クラスフル qdiscs) で cls_matchall を 使用しようとすると、カーネルが予期せず終了しました。今回の更新により、cls_matchall がclassid を処理するときに、classid がパケットに割り当てられます。その結果、classful qdiscs を使用した cls_matchall が正常に使用できるようになり、説明されているシナリオではユーザーが指定した classid の値が無視されなくなりました。
classid に関連するカーネルアクションの詳細については、tc-matchall (8) のマニュアルページの OPTIONS セクションを参照してください。(BZ#1460213)

ユーザーが閉じられた SCTP ポートに接続しても、ICMP エラーパケットが失われないようになりました。

以前は、閉じられた Stream Control Transmission Protocol (SCTP) ポートに接続しようとすると、サーバーからの Internet Control Message Protocol (ICMP) エラー応答が失われました。この問題は、データの受信に非線形バッファーを使用する Network Interface Cards (NICs) でのみ発生しました。その結果、閉じられた SCTP ポートへの接続の場合、ユーザーはサーバーから connection refused エラーメッセージをすぐに受け取るのではなく、タイムアウトになるまで待機していました。この更新により、受信データは直線的に処理され、ICMP エラー応答が失われることはありません。その結果、上記の状況では、ユーザーは対応する ICMP エラーを受け取ります。(BZ#1450529)

SCTP は正しい送信元アドレスを選択するようになりました

以前は、セカンダリー IPv6 アドレスを使用する場合、ストリーム制御伝送プロトコル (SCTP) は、宛先アドレスと最もよく一致する接頭辞に基づいて送信元アドレスを選択していました。その結果、場合によっては、間違った IPv6 アドレスを持つインターフェイスを介してパケットが送信されることがありました。今回の更新により、SCTP はこの特定のルートのルーティングテーブルにすでに存在するアドレスを使用します。その結果、ホスト上でセカンダリーアドレスが使用される場合、SCTP は予期される IPv6 アドレスを送信元アドレスとして使用します。(BZ#1460106)

iptables CLUSTERIP ターゲットによって保持されているデバイス参照が、ネームスペースの削除時に適切に解放されるようになりました。

以前は、iptables CLUSTERIP ターゲットは、関連するルールで入力デバイスとして指定されたネットワークデバイスへの直接参照を保持していました。名前空間内のルールが削除されても、対応する参照は解放されませんでした。その結果、ネームスペースの削除時に、CLUSTERIP ターゲットが保持するダングリング参照により、ネームスペースに含まれるネットワークデバイスの削除が妨げられることがありました。このため、同じ名前のデバイスを作成できず、関連するメモリーも解放されませんでした。今回の更新により、CLUSTERIP ターゲットルール参照は関連デバイスではなく、そのインデックスを保持するようになりました。その結果、ネームスペースを削除すると、このネームスペースに関連するすべてのルールと参照も適切にクリアされます。(BZ#1472892)

nftables 設定ファイルは公開されなくなりました

以前は、RPM ファイルでのインストール中に、nftables 設定ファイルのモードビットがそれに応じて調整されませんでした。その結果、/etc/nftables ディレクトリー内の設定テンプレートと etc/sysconfig/nftables.conf メイン設定ファイルは一般に読み取り可能でした。この更新により、設定ファイルのインストール時にファイルモードビットが正しい値に明示的に設定されます。その結果、ユーザーは正しい権限で設定ファイルをインストールできるようになります。
管理者によって変更されていない設定ファイルは、正しい権限を持つ設定ファイルに置き換えられることに注意してください。
変更された設定ファイルは置き換えられません。その場合、/etc/sysconfig/nftables.conf に対して、正しい権限を持つ rpmnew ファイルが作成されます。/etc/nftables 内のファイルについては、rpmnew ファイルは作成されないため、ユーザーは手動で権限を設定する必要があります。(BZ#1451404)

SENDER_DRY_EVENTS が有効な場合、Ready to read イベントがアプリケーションに正しく送信されるようになりました。

以前は、SENDER_DRY_EVENTS 通知を有効にしたとき、または Stream Control Transmission Protocol (SCTP) 部分信頼性がチャンクの削除をトリガーしたとき、SCTP スタックはイベントがすでに生成されたというフラグを立ててアプリケーションに送信していました。しかし、その後も旗は外されなかった。その結果、アプリケーションは ready to read イベントを逃しました。今回の更新により、スタックはそのような場合にイベントにフラグを立てなくなりました。その結果、Ready to Read イベントがアプリケーションに正しくディスパッチされるようになりました。(BZ#1442784)

SCTP 統計が利用可能になりました

以前は、ストリーム制御伝送プロトコル (SCTP) 統計パーサーは /proc/net/sctp/snmp ソースファイルを処理できませんでした。その結果、ユーザーは統計情報を確認できなくなりました。SCTP 統計の解析が修正されました。その結果、ユーザーは SCTP 統計を利用できるようになりました。(BZ#1329338)

firewalld サービスデーモンが rmmod プロセスでハングしなくなりました

以前は、一部のネットワークデバイスドライバー、特に一部の Wi-Fi および IP over InfiniBand Network Interface Cards (IPoIB NICs) ドライバーは、追跡されていないパケットに関連付けられた conntrack エントリーを無制限に保持していました。その結果、削除時には、conntrack カーネルモジュールはこれらのエントリーが解放されるのを待つビジーループ状態になりました。これにより、rmmod nf_conntrack モジュールが CPU 使用率の 100% を消費し、シャットダウン時に firewalld がハングするようになりました。この更新により、新しいカーネルは notrack conntrack エントリーのサポートを削除し、conntrack はそのようなエントリーが解放されるのを待機しなくなります。その結果、firewalld のシャットダウンがハングしなくなりました。(BZ#1317099)