BIG-IP 管理データ プレーン概念ドキュメントからの包括的かつ詳細な説明:
BIG-IPの高可用性（HA）構成では、MACマスカレード機能を使用して、トラフィックグループに関連付けられたセルフIPアドレスがデバイス間を移動する際に同じMACアドレスを保持できるようにすることで、フェイルオーバーを高速化します。これにより、フェイルオーバー発生時に上流のスイッチやルーターがARPエントリを再学習する必要がなくなり、ほぼ瞬時にトラフィックを回復できます。
デフォルトでは、MACマスカレードはトラフィックグループがいくつのVLANにまたがっているかに関係なく、トラフィックグループごとに1つのMACアドレスを適用します。これは、複数のVLANに同じMACアドレスが存在するとネットワークポリシーに違反したり、スイッチングインフラストラクチャに混乱をきたしたりする可能性があるため、一部のネットワーク設計では問題を引き起こす可能性があります。
これを解決するために、BIG-IP はデータベース変数によって有効化される VLAN ごとの MAC マスカレードを提供します。
`tm.macmasqaddr_per_vlan = true`
この機能を有効にすると、次のようになります。
BIG-IPはVLANごとに固有のMACアドレスを導出します
トラフィック グループに設定されている基本 MAC アドレスは、最初の 4 オクテットのままです。最後の 2 オクテットは、16 進数で表現された VLAN ID に置き換えられます。VLAN ID は、ネットワーク バイト順序 (上位バイトが最初、下位バイトが 2 番目) でエンコードされます。
### VLAN ID 変換:
VLAN ID: 1501 (10進数)
16進数に変換:
1501₁₀ = 0x05DD
上位バイト: 05
下位バイト: DD
### 結果のMACアドレス:
ベースMAC: `02:12:34:56:00:00`
VLANごとの置換 → 最後の2バイト = `05:DD`
最終MACアドレス:
`02:12:34:56:05:dd`
### 他のオプションが間違っている理由:
A (01:15) - 1501の16進数変換が間違っている
B (dd:05) - バイト順序が逆になっています（リトルエンディアン、BIG-IPでは使用されません）
D (15:01) - 16進数の代わりに10進数を使用する
### 主要な BIG-IP HA コンセプトの強化:
VLAN ごとの MAC マスカレードは、トラフィック グループの高速フェイルオーバーの利点を維持しながら、VLAN ごとのレイヤー 2 の一意性を保証するため、マルチ VLAN HA 展開で推奨されるベスト プラクティスになります。

BIG-IP の処理フローは、パケットがシステム内を移動するときに特定の一連のイベントに従います。
* TCP ハンドシェイク: アプリケーション層のデータ (HTTP など) を処理する前に、TCP 接続を確立する必要があります。
* 最初のイベント: クライアントが仮想サーバーとの 3 ウェイ ハンドシェイクを完了したときにトリガーされる最初のイベントは、CLIENT_ACCEPTED です。
* プロファイルの影響: HTTPプロファイルが添付されている場合でも、システムはまずプロトコルレベルで接続を「承認」する必要があります。HTTP_REQUESTは、クライアントがBIG-IPが有効なHTTPリクエストとして認識するデータを送信した後にのみトリガーされます。クライアントが接続したがリクエストを送信しなかった場合、CLIENT_ACCEPTEDはトリガーされますが、HTTP_REQUESTはトリガーされません。

1 つのインターフェースがダウンした場合のフォールト トレランスの要件を満たすには、BIG-IP はリンク アグリゲーションを使用して、単一の物理リンクの損失によって VLAN が分離されないようにする必要があります。
オブジェクトの関係（データプレーンビュー）
* インターフェース = 物理リンク。
* トランク (LACP) = 複数のインターフェイスを 1 つの論理リンクにバンドルし、冗長性 (および場合によっては帯域幅の集約) を提供します。
* VLANはインターフェースまたはトランクに割り当てられます。同じトランクに複数のVLANが必要な場合は、802.1Qタグを使用する必要があります（インターフェース/トランクごとにタグなしVLANは1つしか設定できないため）。
* 次に、BIG-IP プレゼンスとルーティング/ARP 機能を提供するために、セルフ IP が VLAN 上に配置されますが、リンクの復元力を提供するのはセルフ IP ではなく、トランクです。
選択肢Dが正しい理由
* 2 つの物理インターフェースがあり、1 つに障害が発生した場合の回復力が必要な場合、LACP を有効にして両方のインターフェースを 1 つのトランクに入れます。
* 同じ 2 つのリンク上に外部 VLAN と内部 VLAN の両方が必要です。# 両方の VLAN をそのトランク上でタグ付きとして設定し、同じ集約リンク上で共存できるようにする必要があります。
* いずれかの物理インターフェイスに障害が発生した場合、トランクは残りのインターフェイスを介して稼働状態を維持し、両方の VLAN が動作可能な状態を維持します。
他の選択肢が間違っている理由
* A: 同じトランク/インターフェース上で、2つのVLANの両方をタグなしにすることはできません。タグなしVLANは1つだけ設定でき、追加のVLANはタグ付きである必要があります。
* B: 「それぞれ 1 つの VLAN を持つ」2 つのトランクとは、通常、VLAN を別々のトランクに分割することを意味します。
インターフェースは合計 2 つだけなので、トランクごとに 1 つのインターフェースになります。1 つのインターフェースがダウンすると、そのインターフェース上の VLAN もダウンします (その VLAN には冗長性がありません)。
* C: B と同じ冗長性の問題があり、LACP を無効にすると、スイッチ エンジニアが LACP を明示的に要求したときに期待されるネゴシエートされた集約動作が削除されます。

iRules は、高度なトラフィック操作を可能にするイベント駆動型スクリプトです。
* イベントの普遍性: BIG-IP データ プレーンを通過するすべてのパケットがイベントをトリガーします。
HTTP以外のトラフィックであっても、CLIENT_ACCEPTED（TCP接続が確立されたとき22）やCLIENT_DATA（生データが受信されたとき）などのイベントがトリガーされます。したがって、プロトコルに関係なく、すべてのクライアントトラフィックにはiRuleイベントをトリガーできるデータが含まれています。
* イベントの特異性：イベントは普遍的ではありません（選択肢Cは誤りです）。例えば、HTTP_REQUESTはHTTPヘッダー全体が解析された後にのみ発生します。リクエストがサーバーに送信される前にHTTP_RESPONSEイベントをトリガーすることはできません。
* プロトコルに依存しない: iRules は HTTP に限定されません (オプション A は誤り)。TCP、UDP、DNS、FTP、SIP などを処理できます。
* エラー処理: iRule がトリガーされないイベント（例: 純粋な TCP 仮想サーバにおける HTTP_REQUEST イベント）を参照している場合、そのイベントの iRule コードは実行されません。接続は終了されません（オプション D は偽です）。