BGP Overview

Overview

To scale the Cloud-Native Network Functions (CNF) Traffic Management Microkernel (TMM), learn and announce routing prefixes between networks, and to advertise subscriber NAT IP addresses to downstream routers, Border Gateway Protocol (BGP) sessions must be established on TMM’s upstream and downstream interfaces. The TMM Pod’s f5-tmm-routing container can be enabled and configured when installing the CNF Controller.

Review the sections below for BGP configuration assistance:

../_images/spk_info.png Note: The f5-tmm-routing container is disabled by default. Right click the CNF BGP image for a high-level overview.

BGP parameters

The tables below describe the available BGP Helm parameters.

bgp

Configure and establish BGP peering relationships.

Parameter Description
asn The AS number of the f5-tmm-routing container.
hostname The hostname of the f5-tmm-routing container.
neighbors.ip The IPv4 or IPv6 address of the BGP peer.
neighbors.asn The AS number of the BGP peer.
neighbors.password The BGP peer MD5 authentication password. Note: The password is stored in the f5-tmm-dynamic-routing configmap unencrypted.
neighbors.ebgpMultihop Enables connectivity between external peers that do not have a direct connection (1-255).
neighbors.acceptsIPv4 Enables advertising IPv4 virtual server addresses to the peer (true / false). The default is false.
neighbors.acceptsIPv6 Enables advertising IPv6 virtual server addresses to the peer (true / false). The default is false.
neighbors.softReconf Enables BGP4 policies to be activated without clearing the BGP session.
neighbors.maxPathsEbgp The number of parallel eBGP (external peer) routes installed. The default is 2.
neighbors.maxPathsIbgp The number of parallel iBGP (internal peer) routes installed. The default is 2.
neighbors.fallover Enables bidrectional forwarding detection (BFD) between neighbors (true / false). The default is false.
neighbors.routeMap References the routeMaps.name parameter, and applies the filter to the BGP neighbor.

prefixList

Create prefix lists to filter specified IP address subnets.

Parameter Description
name The name of the prefixList entry.
seq The order of the prefixList entry.
deny Allow or deny the prefixList entry.
prefix The IP address subnet to filter.

routeMaps

Create route maps that apply to BGP neighbors, referencing specified prefix lists.

Parameter Description
name The name of the routeMaps object applied to the BGP neighbor.
seq The order of the routeMaps entry.
deny Allow or deny routeMaps entry.
match The name of the referenced prefixList.

bfd

Enable BFD and configure the control packet intervals.

Parameter Description
interface Selects the BFD peering interface.
interval Sets the minimum transmission interval in milliseconds (50-999).
minrx Sets the minimum receive interval in milliseconds (50-999).
multiplier Sets the Hello multiplier value (3-50).

Scaling TMM Pods

When scaling TMM Pods beyond a single instance in the Namespace, you must configure BGP with Equal-cost Multipath (ECMP) load balancing. With ECMP configured, each TMM replica establishes a peer relationship with the upstream (clientside) router, and each routing prefix TMM advertises will have multiple next-hop entries; one for each TMM self IP address.

The upstream router should be configured with an ECMP algorithm that load balances connections across the TMM Pods. F5 recommends ECMP Resilient Hashing if this option is available. For CGNAT the upstream router must be configured with an ECMP algorithm based on the Source IP of subscriber.

  1. When installing the CNF Contoller, set the maxPathsEbgp parameter to the maxiumum number of TMM replicas you intend to use:

    Note: In this example, the maxPathsEbgp parameter configures up to 4 TMM Pod replicas:_

    tmm:
  dynamicRouting:
    enabled: true
    tmmRouting:
      config:
        bgp:
          asn: 100
          maxPathsEbgp: 4
          maxPathsIbgp: 'null'
          hostname: cnf-bgp
          neighbors:
          - ip: 10.10.10.200
            asn: 200
            ebgpMultihop: 10
          - ip: 192.168.10.200
            asn: 400
            ebgpMultihop: 10

  2. Once the CNF Controller has been installed, log in to the peer router and verify the advertised routing prefixes are being advertised with the TMM self-IPs as next hops:

    show ip bgp

    In this example, the TMM replicas with self IP addresses 10.10.10.250 and 10.10.10.251 are advertising the 10.11.12.0/24 subnet:

    Network            Next Hop         Metric     Path
10.11.12.0/24      10.10.10.250          0     200
                   10.10.10.251          0     200

  3. The external peer routers should now distribute traffic flows to the TMM replicas based on the configured ECMP load balancing algorithm.

Advertising IP routes

To ensure upstream routers use TMM as a gatway, and to ensure downstream routers correclty route back through TMM, BGP peering relationships should be established on TMM’s upstream and downstream interfaces. With BGP relationships, TMM can advertise routes learned from the downstream router, and any destination IP addresses defined in the Traffic Management CNF Custom Resources to the upstream router. TMM will also advertise IP addresses defined in the F5SPKNatPolicy CR, to ensure the downstream router sends connections back through TMM.

  1. When installing the CNF Contoller, set the acceptsIPv4 and the acceptsIPv6 parameters to advertise IPv4 and IPv6 destination addresses:

    Note: In this example, the acceptsIPv4 and acceptsIPv6 parameters are set on the upstream BGP peer:

    tmm:
  dynamicRouting:
    enabled: true
    tmmRouting:
      config:
        bgp:
          asn: 100
          maxPathsEbgp: 4
          maxPathsIbgp: 'null'
          hostname: cnf-bgp
          neighbors:
          - ip: 10.10.10.200
            asn: 200
            ebgpMultihop: 10
            acceptsIPv4: true
            acceptsIPv6: true
          - ip: 192.168.10.200
            asn: 400
            ebgpMultihop: 10

  2. Once the CNF Controller has been installed, log in to the peer router and verify the advertised routing prefixes are being advertised with the TMM self-IPs as next hops:

    show ip bgp

    In this example, the TMM replicas with self IP addresses 10.10.10.250 and 10.10.10.251 are advertising the CR destination address 192.168.10.100:

    show ip bgp

    Network             Next Hop         Metric     Path
192.168.10.100/32   10.10.10.250          0     200
                    10.10.10.251          0     200

Enabling BFD

Bidirectional Forwarding Detection (BFD) rapidly detects loss of connectivity between BGP neighbors by exchanging periodic BFD control packets on the network link. After a specified interval, if a control packet is not received, the connection is considered down, enabling fast network convergence. The BFD configuration requires the interface name of the external BGP peer. Use the following command to obtain the external interface name:

kubectl get ingressroutevlan <external vlan> -o "custom-columns=VLAN Name:.spec.name"

  1. When installing the CNF Contoller, configure the bfd for the interface to monitor:

    Note: In this example, BFD is enabled on TMM’s external interface:

    tmm:
  dynamicRouting:
    enabled: true
    tmmRouting:
      config:
        bgp:
          asn: 100
          maxPathsEbgp: 4
          maxPathsIbgp: 'null'
          hostname: cnf-bgp
          neighbors:
          - ip: 10.10.10.200
            asn: 200
            ebgpMultihop: 10
            acceptsIPv4: true
            acceptsIPv6: true
          - ip: 192.168.10.200
            asn: 400
            ebgpMultihop: 10
        bfd:
          interface: external
          interval: 100
          minrx: 100
          multiplier: 3

  2. Once the CNF Controller has been installed, verify the BFD configuration is working.

    In this example, the f5-tmm-routing container is in the cnf-gateway Namespace:

    kubectl exec -it deploy/f5-tmm -c f5-tmm-routing -n cnf-gateway -- bash

  3. Log in IMI shell and turn on privileged mode:

    imish
en

  4. View the bfd session status:

    images/images/spk_info.png Note: You can append the detail argument for verbose session information.

    show bfd session

    In this example, the Sess-State is Up:

    BFD process for VRF: (DEFAULT VRF)
=====================================================================================
Sess-Idx   Remote-Disc  Lower-Layer  Sess-Type   Sess-State  UP-Time   Remote-Addr
2          1            IPv4         Single-Hop  Up          00:03:16  10.10.10.200/32
Number of Sessions:    1

  5. BGP should now quickly detect link failures between neighbors.

Feedback

Provide feedback to improve this document by emailing spkdocs@f5.com.

Supplemental