Unified Load Balancer 構成およびアドミニストレーション ガイド、リリース 2026.02

PDF

Unified Load Balancer 構成およびアドミニストレーション ガイド、リリース 2026.02

ULB で GTP-C ロードバランシングをサポートする

Want to summarize with AI?

Log in

ULB で GTP-C ロードバランサを導入し、主要な概念、要件、および運用上の考慮事項に焦点を当てます。ULB は、バックエンド Pod 全体に GTPv2-C 通信を分散する eBPF ベースの GTP-C ロードバランサを提供します。


ULB は、セッションアフィニティを維持しながら、バックエンド Pod 全体に GTPv2-C 通信を分散する eBPF ベースの GTP-C ロードバランサを提供します。ノードレベルのメッセージ、新しいセッションメッセージ、および既存のセッションメッセージを個別に処理します。アプリケーションは、セッションレベルとノードレベルの GTPv2-C 通信に個別のバックエンド Pod グループを使用できます。

GTP セッション管理:

新しいサブスクライバセッションが開始されると、ULB は構成されたロードバランシングアルゴリズムを使用して GTP-C サービスインスタンスを選択します。セッションが確立されたら、ULB はセッションアフィニティを維持し、そのセッションに関連付けられている後続のすべてのメッセージが、同じサービスインスタンスによって処理されるようにします。

GTP-C サービス Pod によって生成されたエグレス GTPv2-C セッションメッセージは、ULB 経由で適切な外部ピアにルーティングされます。これにより、ULB は一貫したセッション処理を保証しながら、GTPv2-C 出入力通信の両方をルーティングできます。

GTP ピア管理:

ULB は、ピアに関連するシグナリングメッセージを適切な GTP-C ノード管理 Pod にルーティングすることで、GTPv2-C ピア管理をサポートします。現在、ULB は、ランダム選択アルゴリズムを使用して、使用可能なノード管理バックエンド Pod 全体にピア管理メッセージを分散します。


GTP- C ロードバランサのカスタムリソース

この項では、GTP-C ロードバランサのカスタムリソースの構成例を示します。


セッションレベルのメッセージ

apiVersion: lbs.cisco.com/v1alpha1
kind: LoadBalancer
metadata:
  name: <gtpc-sess-lb-name>
spec:
  lbMode: bpf
  protocol: GTPC
  serviceIPs:
  - <ipv4-address>
  servicePort: 2123
  target:
    port: <target-port>
    selectors:
      matchLabels:
        <label-key1>: <label-value1>
        <label-key2>: <label-value2>
  trafficManagementPolicyRef: <gtpc-sess-tmp-name>
  ulbDirectServiceEnabled: false

ノードレベルのメッセージ

apiVersion: lbs.cisco.com/v1alpha1
kind: LoadBalancer
metadata:
  name: <gtpc-node-lb-name>
spec:
  lbMode: bpf
  protocol: GTPC
  serviceIPs:
  - <ipv4-address>
  servicePort: 2123
  target:
    port: <target-port>
    selectors:
      matchLabels:
        <label-key1>: <label-value1>
        <label-key2>: <label-value2>
  trafficManagementPolicyRef: <gtpc-node-tmp-name>
  ulbDirectServiceEnabled: false

GTP-C 通信管理ポリシーのカスタムリソース


セッションレベルのメッセージ

apiVersion: lbs.cisco.com/v1alpha1
kind: TrafficManagementPolicy
metadata:
  name: <gtpc-sess-tmp-name>
spec:
  # GTP-C v2 session message handling (Message Type >= 32)
  gtpcSessionMessages:

    # Load balancing algorithm
    algorithm: RANDOM_LOCAL

    # Affinity policy 
    sessionAffinity:
      # Node identifier extraction
      nodeIdentifier:
        target:
          header: GTPC          # GTP-C Header
          offset: 4             # TEID field offset
          length: 4             # TEID is 4 bytes
        operation:
          type: BITWISE_AND
          mask: "0x3C000000"    # Extract bits 26-29 (4 bits)

      # Session identifier extraction
      sessionIdentifier:
        target:
          header: GTPC          # GTP-C Header
          offset: 4             # TEID field offset
          length: 4             # TEID is 4 bytes
        operation:
          type: BITWISE_AND
          mask: "0x03FFFFFF"    # Extract bits 0-25 (26 bits)

      # Session Map provisioning strategy
      sessionMap:
        provisioningMode: APPLICATION_PUSH_NOTIFICATION 

      # Affinity Notification
      affinityNotification:
        # Currently single rule is allowed
        rules:
          - condition: KEY_NOT_FOUND

            # Action to take by marking spare bit in GTP-C Header
            # SET_GTPC_SPARE_BIT1: Set spare bit 1 in GTPC Header
            # SET_GTPC_SPARE_BIT2: Set spare bit 2 in GTPC Header 
            action: SET_GTPC_SPARE_BIT1

ノードレベルのメッセージ

apiVersion: lbs.cisco.com/v1alpha1
kind: TrafficManagementPolicy
metadata:
  name: <gtpc-node-tmp-name>
spec:
  # GTP-C v2 node message handling (Message Type < 32)
  gtpcNodeMessages:

    # Load balancing algorithm (RANDOM)
    algorithm: RANDOM