Skip to content

Protocols#
Description The Protocols application manages BGP, static, and aggregate route resources to automatically generate routing configurations for network nodes in both default and custom VRFs.
Supported OS SR Linux, SR OS
Catalog nokia-eda/catalog / manifest
Source Code coming soon

The Protocols application enables users to create and manage various routing protocols in EDA and contains resources that are split between Overlay and Default routing categories. These two categories define the deployment model for the resource.

Resources from the Default Routing category will be used in the network element's default VRF, whereas resources listed under the Overlay Routing category designed to be associated with a custom, non-default VRF.

The application provides the following components:

DEFAULT ROUTING

  • Default BGP Groups
  • Default BGP Peers
  • Default Static Routes
  • Default Aggregate Routes
  • Default Route Reflectors
  • Default Route Reflector Clients

OVERLAY ROUTING

  • BGP Groups
  • BGP Peers
  • Static Routes
  • Aggregate Routes
  • Route Reflectors
  • Route Reflector Clients

Summary dashboards for the following resource types:

  • Default BGP Peers
  • Default BGP Groups
  • Default Route Reflectors
  • Default Route Reflector Clients

Border Gateway Protocol (BGP)#

BGP configuration in the Protocols application supports both default VRF and custom VRF deployments, with comprehensive features for peer management, route reflection, and policy control.

Configuration Types#

The application supports two primary BGP deployment models:

  • Default BGP: Configuration in the default VRF using DefaultBGPPeer and DefaultBGPGroup custom resources (CRs).
  • Custom VRF BGP: Configuration in custom IP-VRFs using BGPPeer and BGPGroup CRs.

BGP Groups#

BGP Groups enable centralized management of peer configurations, ensuring consistent policy application across multiple peers.

Because a BGP group in the default VRF and custom VRF usually have different configuration options and represent different groups, two BGP groups resource types are offered - DefaultBGPGroup and BGPGroup.

Default BGP Group Configuration#

DEFAULT ROUTING → DGDefault BGP Group

apiVersion: protocols.eda.nokia.com/v1alpha1
kind: DefaultBGPGroup
metadata:
  name: example-default-group
  namespace: eda
spec:
  description: "Default VRF BGP group"
  localAS:
    autonomousSystem: 65001
  timers:
    holdTime: 90
    keepAlive: 30
  ipv4Unicast:
    enabled: true
    maxReceivedRoutes: 1000

cat << 'EOF' | kubectl apply -f -
apiVersion: protocols.eda.nokia.com/v1alpha1
kind: DefaultBGPGroup
metadata:
  name: example-default-group
  namespace: eda
spec:
  description: "Default VRF BGP group"
  localAS:
    autonomousSystem: 65001
  timers:
    holdTime: 90
    keepAlive: 30
  ipv4Unicast:
    enabled: true
    maxReceivedRoutes: 1000
EOF

Custom VRF BGP Group Configuration#

OVERLAY ROUTING → BGBGP Group

apiVersion: protocols.eda.nokia.com/v1alpha1
kind: BGPGroup
metadata:
  name: example-custom-group
  namespace: eda
spec:
  description: "Custom VRF BGP group"
  localAS:
    autonomousSystem: 65002
  timers:
    holdTime: 90
    keepAlive: 30
  ipv4Unicast:
    enabled: true
    maxReceivedRoutes: 1000

cat << 'EOF' | kubectl apply -f -
apiVersion: protocols.eda.nokia.com/v1alpha1
kind: BGPGroup
metadata:
  name: example-custom-group
  namespace: eda
spec:
  description: "Custom VRF BGP group"
  localAS:
    autonomousSystem: 65002
  timers:
    holdTime: 90
    keepAlive: 30
  ipv4Unicast:
    enabled: true
    maxReceivedRoutes: 1000
EOF

BGP Peers#

BGP peers represent individual BGP sessions and can inherit configurations from BGP groups. The Protocols application supports both explicit peer configuration and dynamic neighbor discovery. Selecting an interface will bind the session to the Toponode on which the Interface is deployed. The interface can be a DefaultInterface (interface in the default VRF) or a SystemInterface (primary loopback in the default VRF).

Default BGP Peer Configuration#

apiVersion: protocols.eda.nokia.com/v1alpha1
kind: DefaultBGPPeer
metadata:
  name: example-default-peer
  namespace: eda
spec:
  description: "Default VRF BGP peer"
  group: "example-default-group"
  interface: "system"
  interfaceKind: "SYSTEMINTERFACE"
  peerAS:
    autonomousSystem: 65100
  peerIP: "192.168.1.1"

cat << 'EOF' | kubectl apply -f -
apiVersion: protocols.eda.nokia.com/v1alpha1
kind: DefaultBGPPeer
metadata:
  name: example-default-peer
  namespace: eda
spec:
  description: "Default VRF BGP peer"
  group: "example-default-group"
  interface: "system"
  interfaceKind: "SYSTEMINTERFACE"
  peerAS:
    autonomousSystem: 65100
  peerIP: "192.168.1.1"
EOF

Custom VRF BGP Peer Configuration#

apiVersion: protocols.eda.nokia.com/v1alpha1
kind: BGPPeer
metadata:
  name: example-custom-peer
  namespace: eda
spec:
  description: "Custom VRF BGP peer"
  group: "example-custom-group"
  interface: "customer-1"
  interfaceKind: "ROUTEDINTERFACE"
  peerAS:
    autonomousSystem: 65200
  peerIP: "192.168.2.1"

cat << 'EOF' | kubectl apply -f -
apiVersion: protocols.eda.nokia.com/v1alpha1
kind: BGPPeer
metadata:
  name: example-custom-peer
  namespace: eda
spec:
  description: "Custom VRF BGP peer"
  group: "example-custom-group"
  interface: "customer-1"
  interfaceKind: "ROUTEDINTERFACE"
  peerAS:
    autonomousSystem: 65200
  peerIP: "192.168.2.1"
EOF

Address Family Support#

The Protocols application provides comprehensive support for multiple BGP address families including, but not limited to:

IPv4 Unicast#

  • Enable/disable IPv4 unicast routing
  • Support for IPv6 next-hops (RFC 5549)
  • Configurable maximum route limits
  • Next-hop self options
  • Independent policy control

IPv6 Unicast#

  • Enable/disable IPv6 unicast routing
  • Configurable maximum route limits
  • Independent policy control

L2VPN EVPN#

  • Enable/disable EVPN
  • Support for IPv6 next-hops
  • Configurable maximum route limits
  • Integration with overlay services

Route Reflection#

Route reflection enables scalable iBGP deployments by eliminating the need for a full mesh of iBGP sessions. The Protocols application supports route reflection in both default and custom VRFs.

The router reflector resources can select the clients to connect to using a label selector. The label selector will select RouteReflectorClient or DefaultRouteReflectorClient resources; if the clients are not EDA resources, you may specify a list of client IPs to which the the route reflector will attempt to establish a session.

Configuration Types#

  • Default VRF: Using DefaultRouteReflector and DefaultRouteReflectorClient.
  • Custom VRF: Using RouteReflector and RouteReflectorClient.

Route Reflector Configuration#

Default VRF Example#
apiVersion: protocols.eda.nokia.com/v1alpha1
kind: DefaultRouteReflector
metadata:
  name: example-default-rr
  namespace: eda
spec:
  description: "Default VRF Route Reflector"
  clusterID: "1.1.1.1"
  defaultBGPRRGroup: "rr-group"
  interface: "system"
  interfaceKind: "SYSTEMINTERFACE"
  clientSelector:
    - "role=leaf"
  clientIPs:
    - "192.168.1.1"
    - "192.168.1.2"
  ipv4Unicast:
    enabled: true

cat << 'EOF' | kubectl apply -f -
apiVersion: protocols.eda.nokia.com/v1alpha1
kind: DefaultRouteReflector
metadata:
  name: example-default-rr
  namespace: eda
spec:
  description: "Default VRF Route Reflector"
  clusterID: "1.1.1.1"
  defaultBGPRRGroup: "rr-group"
  interface: "system"
  interfaceKind: "SYSTEMINTERFACE"
  clientSelector:
    - "role=leaf"
  clientIPs:
    - "192.168.1.1"
    - "192.168.1.2"
  ipv4Unicast:
    enabled: true
EOF
Custom VRF Route Reflector Example#
apiVersion: protocols.eda.nokia.com/v1alpha1
kind: RouteReflector
metadata:
  name: example-custom-rr
  namespace: eda
spec:
  clusterID: "2.2.2.2"
  bgpGroup: "custom-rr-group"
  interface: "customer-1"
  interfaceKind: "ROUTEDINTERFACE"
  ipv4ClientSelector:
    - "role=customer-edge"
  ipv6ClientSelector:
    - "role=customer-edge"
  clientIPs:
    - "172.16.1.1"
    - "172.16.1.2"

cat << 'EOF' | kubectl apply -f -
apiVersion: protocols.eda.nokia.com/v1alpha1
kind: RouteReflector
metadata:
  name: example-custom-rr
  namespace: eda
spec:
  clusterID: "2.2.2.2"
  bgpGroup: "custom-rr-group"
  interface: "customer-1"
  interfaceKind: "ROUTEDINTERFACE"
  ipv4ClientSelector:
    - "role=customer-edge"
  ipv6ClientSelector:
    - "role=customer-edge"
  clientIPs:
    - "172.16.1.1"
    - "172.16.1.2"
EOF

Route Reflector Client Configuration#

Route reflector clients establish sessions with route reflectors based on selectors or explicit IP addresses. The label selector will select DefaultRouteReflector or RouteReflector resources, or a list of IP addresses can be provided which the router relctor client will try to establish a session to.

Default VRF Client Example#
apiVersion: protocols.eda.nokia.com/v1alpha1
kind: DefaultRouteReflectorClient
metadata:
  name: example-default-rr-client
  namespace: eda
spec:
  defaultBgpClientGroup: "client-group"
  interface: "system"
  interfaceKind: "SYSTEMINTERFACE"
  routeReflectorSelector:
    - "role=spine"
  routeReflectorIPs:
    - "192.168.0.1"
    - "192.168.0.2"

cat << 'EOF' | kubectl apply -f -
apiVersion: protocols.eda.nokia.com/v1alpha1
kind: DefaultRouteReflectorClient
metadata:
  name: example-default-rr-client
  namespace: eda
spec:
  defaultBgpClientGroup: "client-group"
  interface: "system"
  interfaceKind: "SYSTEMINTERFACE"
  routeReflectorSelector:
    - "role=spine"
  routeReflectorIPs:
    - "192.168.0.1"
    - "192.168.0.2"
EOF
Custom VRF Client Example#
apiVersion: protocols.eda.nokia.com/v1alpha1
kind: RouteReflectorClient
metadata:
  name: example-custom-rr-client
  namespace: eda
spec:
  bgpGroup: "custom-client-group"
  interface: "customer-1"
  interfaceKind: "ROUTEDINTERFACE"
  ipv4RouteReflectorSelector:
    - "role=provider-edge"
  ipv6RouteReflectorSelector:
    - "role=provider-edge"
  routeReflectorIPs:
    - "172.16.0.1"
    - "172.16.0.2"

cat << 'EOF' | kubectl apply -f -
apiVersion: protocols.eda.nokia.com/v1alpha1
kind: RouteReflectorClient
metadata:
  name: example-custom-rr-client
  namespace: eda
spec:
  bgpGroup: "custom-client-group"
  interface: "customer-1"
  interfaceKind: "ROUTEDINTERFACE"
  ipv4RouteReflectorSelector:
    - "role=provider-edge"
  ipv6RouteReflectorSelector:
    - "role=provider-edge"
  routeReflectorIPs:
    - "172.16.0.1"
    - "172.16.0.2"
EOF

Static Routes#

Static routes provide explicit path control for network traffic.

Configuration Types#

The application supports two types of static route deployments:

  • Default Static Routes: Configuration in the default VRF using a DefaultStaticRoute resource.
  • Custom VRF Static Routes: Configuration in custom VRFs using a StaticRoute resource.

Default VRF Static Route Configuration#

apiVersion: protocols.eda.nokia.com/v1alpha1
kind: DefaultStaticRoute
metadata:
  name: example-default-static
  namespace: eda
spec:
  defaultRouter: "default-router"
  prefixes:
    - "192.168.0.0/24"
    - "172.16.0.0/24"
  preference: 5
  nexthopGroup:
    nexthops:
      - ipPrefix: "10.0.0.1"
      - ipPrefix: "10.0.0.2"
    resolve: true
    bfd:
      enabled: true

cat << 'EOF' | kubectl apply -f -
apiVersion: protocols.eda.nokia.com/v1alpha1
kind: DefaultStaticRoute
metadata:
  name: example-default-static
  namespace: eda
spec:
  defaultRouter: "default-router"
  prefixes:
    - "192.168.0.0/24"
    - "172.16.0.0/24"
  preference: 5
  nexthopGroup:
    nexthops:
      - ipPrefix: "10.0.0.1"
      - ipPrefix: "10.0.0.2"
    resolve: true
    bfd:
      enabled: true
EOF

Custom VRF Static Route Configuration#

apiVersion: protocols.eda.nokia.com/v1alpha1
kind: StaticRoute
metadata:
  name: example-custom-static
  namespace: eda
spec:
  router: "customer-router"
  prefixes:
    - "192.168.1.0/24"
    - "192.168.2.0/24"
  preference: 10
  nodes:
    - "node1"
    - "node2"
  nexthopGroup:
    nexthops:
      - ipPrefix: "10.1.0.1"
        bfd:
          enabled: true
      - ipPrefix: "10.1.0.2"
    resolve: true

cat << 'EOF' | kubectl apply -f -
apiVersion: protocols.eda.nokia.com/v1alpha1
kind: StaticRoute
metadata:
  name: example-custom-static
  namespace: eda
spec:
  router: "customer-router"
  prefixes:
    - "192.168.1.0/24"
    - "192.168.2.0/24"
  preference: 10
  nodes:
    - "node1"
    - "node2"
  nexthopGroup:
    nexthops:
      - ipPrefix: "10.1.0.1"
        bfd:
          enabled: true
      - ipPrefix: "10.1.0.2"
    resolve: true
EOF

Route Aggregation#

Route aggregation enables efficient route summarization and management.

Configuration Types#

The application supports two types of route aggregation:

  • Default Aggregate Routes: Configuration in the default VRF using a DefaultAggregateRoute resource.
  • Custom VRF Aggregate Routes: Configuration in custom VRFs using an AggregateRoute resource.

Default VRF Aggregate Route Configuration#

apiVersion: protocols.eda.nokia.com/v1alpha1
kind: DefaultAggregateRoute
metadata:
  name: example-default-aggregate
  namespace: eda
spec:
  defaultRouter: "default-router"
  prefixes:
    - "192.168.0.0/16"
    - "172.16.0.0/12"
  aggregatorIP: "10.0.0.1"
  aggregatorASN: 65001
  summaryOnly: true
  generateICMP: false

cat << 'EOF' | kubectl apply -f -
apiVersion: protocols.eda.nokia.com/v1alpha1
kind: DefaultAggregateRoute
metadata:
  name: example-default-aggregate
  namespace: eda
spec:
  defaultRouter: "default-router"
  prefixes:
    - "192.168.0.0/16"
    - "172.16.0.0/12"
  aggregatorIP: "10.0.0.1"
  aggregatorASN: 65001
  summaryOnly: true
  generateICMP: false
EOF

Custom VRF Aggregate Route Configuration#

apiVersion: protocols.eda.nokia.com/v1alpha1
kind: AggregateRoute
metadata:
  name: example-custom-aggregate
  namespace: eda
spec:
  router: "customer-router"
  prefixes:
    - "192.168.1.0/24"
    - "192.168.2.0/24"
  aggregatorIP: "10.0.0.2"
  aggregatorASN: 65002
  nodes:
    - "node1"
    - "node2"
  summaryOnly: true
  generateICMP: false

cat << 'EOF' | kubectl apply -f -
apiVersion: protocols.eda.nokia.com/v1alpha1
kind: AggregateRoute
metadata:
  name: example-custom-aggregate
  namespace: eda
spec:
  router: "customer-router"
  prefixes:
    - "192.168.1.0/24"
    - "192.168.2.0/24"
  aggregatorIP: "10.0.0.2"
  aggregatorASN: 65002
  nodes:
    - "node1"
    - "node2"
  summaryOnly: true
  generateICMP: false
EOF

Operational State and Verification#

BGP Status#

# Check BGP peer status
kubectl get bgppeers
NAME         SESSION STATE   LAST CHANGE   ENABLED   OPERATIONAL STATE   PEER AS
example-peer Established    10m           true      up                  65100

# Check BGP group status
kubectl get bgpgroups
NAME          LAST CHANGE   OPERATIONAL STATE
example-group 10m          up

# Check route reflector status
kubectl get routereflectors
NAME    LAST CHANGE   OPERATIONAL STATE   NUM RR BGP PEERS   NUM RR BGP PEERS DOWN
rr-1    10m          up                  4                  0

Static Route Status#

# Check static route status
kubectl get staticroutes
NAME          LAST CHANGE   OPERATIONAL STATE   HEALTH
custom-route  10m          up                  100

Aggregate Route Status#

# Check aggregate route status
kubectl get aggregateroutes
NAME             LAST CHANGE   OPERATIONAL STATE   HEALTH
customer-summary 10m          up                  100