BGP Peering Policy ( Legacy )
Warning
CiliumBGPPeeringPolicy will be discontinued in future. Consider
using the new BGP APIs to configure the BGP Control Plane.
Configure Peering
apiVersion: "cilium.io/v2alpha1"
kind: CiliumBGPPeeringPolicy
metadata:
name: rack0
spec:
nodeSelector:
matchLabels:
rack: rack0
virtualRouters:
- localASN: 64512
neighbors:
- peerAddress: '10.0.0.1/32'
peerASN: 64512
All BGP peering topology information is carried in a CiliumBGPPeeringPolicy
CRD. A CiliumBGPPeeringPolicy can be applied to one or more nodes based on
its nodeSelector field. Only a single CiliumBGPPeeringPolicy can be
applied to a node. If multiple policies match a node, Cilium clears all BGP
sessions until only one policy matches the node.
Warning
Applying another policy over an existing one will cause the BGP session to be cleared and causes immediate connectivity disruption. It is strongly recommended to test the policy in a staging environment before applying it to production.
Each CiliumBGPPeeringPolicy defines one or more virtualRouters. The
virtual router defines a BGP router instance which is uniquely identified by
its localASN. Each virtual router can have multiple neighbors defined.
The neighbor defines a BGP neighbor uniquely identified by its peerAddress
and peerASN. When localASN and peerASN are the same, iBGP peering
is used. When localASN and peerASN are different, eBGP peering is used.
Specifying Router ID (IPv6 single-stack only)
When Cilium is running on an IPv4 or a dual-stack, the BGP Router ID is automatically derived from the IPv4 address assigned to the node. When Cilium is running on an IPv6 single-stack cluster, the BGP Router ID must be configured manually. This can be done by setting the annotation on the Kubernetes Node resource:
$ kubectl annotate node <node-name> cilium.io/bgp-virtual-router.64512="router-id=10.0.0.2"
Currently, you must set the annotation for each Node. In the future, automatic assignment of the Router ID may be supported. Follow #30333 for updates.
Validating Peering Status
Once the CiliumBGPPeeringPolicy is applied, you can check the BGP peering
status with the Cilium CLI with the following command:
$ cilium bgp peers
Node Local AS Peer AS Peer Address Session State Uptime Family Received Advertised
node0 64512 64512 10.0.0.1 established 10s ipv4/unicast 0 0
ipv6/unicast 0 0
Node Annotations
A CiliumBGPPeeringPolicy can apply to multiple nodes. When a
CiliumBGPPeeringPolicy applies to one or more nodes each node will
instantiate one or more BGP routers as defined in virtualRouters. However,
there are times when fine-grained control over an instantiated virtual router’s
configuration needs to take place. This can be accomplished by applying a
Kubernetes annotation to Kubernetes Node resources.
A single annotation is used to specify a set of configuration attributes to apply to a particular virtual router instantiated on a particular host.
The syntax of the annotation is as follows:
cilium.io/bgp-virtual-router.{asn}="key=value,..."
The {asn} portion should be replaced by the virtual router’s local ASN you
wish to apply these configuration attributes to. Multiple option key/value
pairs can be specified by separating them with a comma. When duplicate keys are
defined with different values, the last key’s value will be used.
Overriding Router ID
When Cilium is running on an IPv4 single-stack or a dual-stack, the BGP Control
Plane can use the IPv4 address assigned to the node as the BGP Router ID
because Router ID is 32bit long, and we can rely on the uniqueness of the IPv4
address to make Router ID unique which is not the case for IPv6. Thus, when
running in an IPv6 single-stack, or when the auto assignment of the Router ID
is not desired, the administrator needs to manually define it. This can be
accomplished by setting the router-id key in the annotation.
$ kubectl annotate node <node-name> cilium.io/bgp-virtual-router.{asn}="router-id=10.0.0.2"
Listening on the Local Port
By default, the BGP Control Plane instantiates each virtual router without a
listening port. This means the BGP router can only initiate connections to the
configured peers, but cannot accept incoming connections. This is the default
behavior because the BGP Control Plane is designed to function in environments
where another BGP router (such as Bird) is running on the same node. When
it is required to accept incoming connections, the local-port key can be
used to specify the listening port.
$ kubectl annotate node <node-name> cilium.io/bgp-virtual-router.{asn}="local-port=179"
Advertising PodCIDRs
BGP Control Plane can advertise PodCIDR prefixes of the nodes selected by the
CiliumBGPPeeringPolicy to the BGP peers. This allows the BGP peers to reach
the Pods directly without involving load balancers or NAT. There are two ways
to advertise PodCIDRs depending on the IPAM mode setting.
Kubernetes and ClusterPool IPAM
When Kubernetes or ClusterPool IPAM is used, set the
virtualRouters[*].exportPodCIDR field to true.
apiVersion: "cilium.io/v2alpha1"
kind: CiliumBGPPeeringPolicy
metadata:
name: rack0
spec:
nodeSelector:
matchLabels:
rack: rack0
virtualRouters:
- localASN: 64512
exportPodCIDR: true # <-- enable PodCIDR advertisement
neighbors:
- peerAddress: '10.0.0.1/32'
peerASN: 64512
With this configuration, the BGP speaker on each node advertises the PodCIDR prefixes assigned to the local node.
MultiPool IPAM
When MultiPool IPAM is used, specify the
virtualRouters[*].podIPPoolSelector field. The .podIPPoolSelector field
is a label selector that selects allocated CIDRs of CiliumPodIPPool
matching the specified .matchLabels or .matchExpressions.
apiVersion: "cilium.io/v2alpha1"
kind: CiliumBGPPeeringPolicy
metadata:
name: rack0
spec:
nodeSelector:
matchLabels:
rack: rack0
virtualRouters:
- localASN: 64512
podIPPoolSelector: # <-- select CiliumPodIPPool to advertise
matchLabels:
environment: production
neighbors:
- peerAddress: '10.0.0.1/32'
peerASN: 64512
This advertises the PodCIDR prefixes allocated from the selected
CiliumPodIPPools. Note that the CIDR must be allocated to a CiliumNode that
matches the .nodeSelector for the virtual router to announce the PodCIDR as
a BGP route.
If you wish to announce ALL CiliumPodIPPool CIDRs within the cluster, a NotIn match expression
with a dummy key and value can be used like:
apiVersion: "cilium.io/v2alpha1"
kind: CiliumBGPPeeringPolicy
spec:
nodeSelector:
matchLabels:
rack: rack0
virtualRouters:
- localASN: 64512
podIPPoolSelector:
matchExpressions:
- {key: somekey, operator: NotIn, values: ['never-used-value']}
neighbors:
- peerAddress: '10.0.0.1/32'
peerASN: 64512
There are two special purpose selector fields that match CiliumPodIPPools based on name and/or
namespace metadata instead of labels:
Selector |
Field |
io.cilium.podippool.namespace |
|
io.cilium.podippool.name |
|
For additional details regarding CiliumPodIPPools, see the Multi-Pool (Beta) section.
Other IPAM Types
When using other IPAM types, the BGP Control Plane does not support advertising
PodCIDRs and specifying virtualRouters[*].exportPodCIDR doesn’t take any
effect.
Advertising Service Virtual IPs
In Kubernetes, a Service has multiple virtual IP addresses,
such as .spec.clusterIP, .spec.clusterIPs, .status.loadBalancer.ingress[*].ip
and .spec.externalIPs.
The BGP control plane can advertise the virtual IP address of the Service to BGP peers.
This allows users to directly access the Service from outside the cluster.
To advertise the virtual IPs, specify the virtualRouters[*].serviceSelector field
and the virtualRouters[*].serviceAdvertisements field. The .serviceAdvertisements
defaults to the LoadBalancerIP service. You can also specify the .serviceAdvertisements
field to advertise specific service types, with options such as LoadBalancerIP,
ClusterIP and ExternalIP.
It is worth noting that when you configure virtualRouters[*].serviceAdvertisements as ClusterIP,
the BGP Control Plane only considers the configuration of the service’s .spec.internalTrafficPolicy and ignores
the configuration of .spec.externalTrafficPolicy.
For ExternalIP and LoadBalancerIP, it only considers the configuration of
the service’s .spec.externalTrafficPolicy and ignores the configuration of .spec.internalTrafficPolicy.
The .serviceSelector field is a label selector that selects Services matching
the specified .matchLabels or .matchExpressions.
When your upstream router supports Equal Cost Multi Path(ECMP), you can use this feature to load balance traffic to the Service across multiple nodes by advertising the same ingress IPs from multiple nodes.
apiVersion: "cilium.io/v2alpha1"
kind: CiliumBGPPeeringPolicy
metadata:
name: rack0
spec:
nodeSelector:
matchLabels:
rack: rack0
virtualRouters:
- localASN: 64512
serviceSelector: # <-- select Services to advertise
matchLabels:
app: foo
serviceAdvertisements: # <-- specify the service types to advertise
- LoadBalancerIP # <-- default
- ClusterIP # <-- options
- ExternalIP # <-- options
neighbors:
- peerAddress: '10.0.0.1/32'
peerASN: 64512
Warning
Many routers have a limit on the number of ECMP paths they can hold in their routing table (Juniper). When advertising the Service VIPs from many nodes, you may exceed this limit. We recommend checking the limit with your network administrator before using this feature.
Advertising ExternalIP Services
If you wish to use this together with kubeProxyReplacement feature (see Kubernetes Without kube-proxy docs),
please make sure the ExternalIP support is enabled.
If you only wish to advertise the .spec.externalIPs of Service,
you can specify the virtualRouters[*].serviceAdvertisements field as ExternalIP.
apiVersion: "cilium.io/v2alpha1"
kind: CiliumBGPPeeringPolicy
metadata:
name: rack0
spec:
nodeSelector:
matchLabels:
rack: rack0
virtualRouters:
- localASN: 64512
serviceSelector: # <-- select Services to advertise
matchLabels:
app: foo
serviceAdvertisements: # <-- specify the service types to advertise
- ExternalIP
neighbors:
- peerAddress: '10.0.0.1/32'
peerASN: 64512
Advertising ClusterIP Services
If you wish to use this together with kubeProxyReplacement feature (see Kubernetes Without kube-proxy docs),
specific BPF parameters need to be enabled.
See External Access To ClusterIP Services section for how to enable it.
If you only wish to advertise the .spec.clusterIP and .spec.clusterIPs of Service,
you can specify the virtualRouters[*].serviceAdvertisements field as ClusterIP.
apiVersion: "cilium.io/v2alpha1"
kind: CiliumBGPPeeringPolicy
metadata:
name: rack0
spec:
nodeSelector:
matchLabels:
rack: rack0
virtualRouters:
- localASN: 64512
serviceSelector: # <-- select Services to advertise
matchLabels:
app: foo
serviceAdvertisements: # <-- specify the service types to advertise
- ClusterIP
neighbors:
- peerAddress: '10.0.0.1/32'
peerASN: 64512
Additionally, when the .spec.clusterIP or .spec.clusterIPs of the Service contains None,
this IP address will be ignored and will not be advertised.
Advertising Load Balancer Services
You must first allocate ingress IPs to advertise them. By default, Kubernetes doesn’t provide a way to assign ingress IPs to a Service. The cluster administrator is responsible for preparing a controller that assigns ingress IPs. Cilium supports assigning ingress IPs with the Load Balancer IPAM feature.
apiVersion: "cilium.io/v2alpha1"
kind: CiliumBGPPeeringPolicy
spec:
nodeSelector:
matchLabels:
rack: rack0
virtualRouters:
- localASN: 64512
serviceSelector:
matchLabels:
app: foo
neighbors:
- peerAddress: '10.0.0.1/32'
peerASN: 64512
This advertises the ingress IPs of all Services matching the .serviceSelector.
If you wish to announce ALL services within the cluster, a NotIn match expression
with a dummy key and value can be used like:
apiVersion: "cilium.io/v2alpha1"
kind: CiliumBGPPeeringPolicy
spec:
nodeSelector:
matchLabels:
rack: rack0
virtualRouters:
- localASN: 64512
serviceSelector:
matchExpressions:
- {key: somekey, operator: NotIn, values: ['never-used-value']}
neighbors:
- peerAddress: '10.0.0.1/32'
peerASN: 64512
There are a few special purpose selector fields which don’t match on labels but
instead on other metadata like .meta.name or .meta.namespace.
Selector |
Field |
io.kubernetes.service.namespace |
|
io.kubernetes.service.name |
|
Load Balancer Class
Cilium supports the loadBalancerClass.
When the load balancer class is set to io.cilium/bgp-control-plane or unspecified,
Cilium will announce the ingress IPs of the Service. Otherwise, Cilium will not announce
the ingress IPs of the Service.
externalTrafficPolicy
When the Service has externalTrafficPolicy: Cluster, BGP Control Plane
unconditionally advertises the ingress IPs of the selected Service. When the
Service has externalTrafficPolicy: Local, BGP Control Plane keeps track of
the endpoints for the service on the local node and stops advertisement when
there’s no local endpoint.
Validating Advertised Routes
Get all IPv4 unicast routes available:
$ cilium bgp routes available ipv4 unicast
Node VRouter Prefix NextHop Age Attrs
node0 64512 10.1.0.0/24 0.0.0.0 17m42s [{Origin: i} {Nexthop: 0.0.0.0}]
Get all IPv4 unicast routes available for a specific vrouter:
$ cilium bgp routes available ipv4 unicast vrouter 64512
Node VRouter Prefix NextHop Age Attrs
node0 64512 10.1.0.0/24 0.0.0.0 17m42s [{Origin: i} {Nexthop: 0.0.0.0}]
Get IPv4 unicast routes advertised to a specific peer:
$ cilium bgp routes advertised ipv4 unicast peer 10.0.0.1
Node VRouter Prefix NextHop Age Attrs
node0 64512 10.1.0.0/24 10.0.0.2 17m42s [{Origin: i} {AsPath: } {Nexthop: 10.0.0.2} {LocalPref: 100}]
Neighbor Options
Each virtualRouters can contain multiple neighbors. You can specify
various BGP peering options for each neighbor. This section describes the
available options and use cases.
Warning
Change of an existing neighbor configuration can cause reset of the existing BGP peering connection, which results in route flaps and transient packet loss while the session reestablishes and peers exchange their routes. To prevent packet loss, it is recommended to configure BGP Graceful Restart.
Peer Port
By default, the BGP Control Plane uses port 179 for BGP peering. When the neighbor is
running on a non-standard port, you can specify the port number with the peerPort
field.
apiVersion: "cilium.io/v2alpha1"
kind: CiliumBGPPeeringPolicy
spec:
nodeSelector:
matchLabels:
rack: rack0
virtualRouters:
- localASN: 64512
neighbors:
- peerAddress: '10.0.0.1/32'
peerASN: 64512
peerPort: 1179 # <-- specify the peer port
Timers
BGP Control Plane supports modifying the following BGP timer parameters. For more detailed description for each timer parameters, please refer to RFC4271.
Name |
Field |
Default |
ConnectRetryTimer |
|
120 |
HoldTimer |
|
90 |
KeepaliveTimer |
|
30 |
In datacenter networks which Kubernetes clusters are deployed, it is generally
recommended to set the HoldTimer and KeepaliveTimer to a lower value
for faster possible failure detection. For example, you can set the minimum
possible values holdTimeSeconds=9 and keepAliveTimeSeconds=3.
apiVersion: "cilium.io/v2alpha1"
kind: CiliumBGPPeeringPolicy
spec:
nodeSelector:
matchLabels:
rack: rack0
virtualRouters:
- localASN: 64512
neighbors:
- peerAddress: '10.0.0.1/32'
peerASN: 64512
connetRetryTimeSeconds: 90 # <-- specify the ConnectRetryTimer
holdTimeSeconds: 9 # <-- specify the HoldTimer
keepAliveTimeSeconds: 3 # <-- specify the KeepaliveTimer
eBGP Multihop
By default, IP TTL of the BGP packets is set to 1 in eBGP. Generally, it is encouraged to not change the TTL, but in some cases, you may need to change the TTL value. For example, when the BGP peer is a Route Server and located in a different subnet, you may need to set the TTL value to more than 1.
apiVersion: "cilium.io/v2alpha1"
kind: CiliumBGPPeeringPolicy
spec:
nodeSelector:
matchLabels:
rack: rack0
virtualRouters:
- localASN: 64512
neighbors:
- peerAddress: '10.0.0.1/32'
peerASN: 64512
eBGPMultihopTTL: 4 # <-- specify the TTL value
MD5 Passwords
By configuring authSecretRef for a neighbor you can configure that a
RFC-2385 TCP MD5 password should be configured on the session with this BGP
peer.
apiVersion: "cilium.io/v2alpha1"
kind: CiliumBGPPeeringPolicy
metadata:
name: rack0
spec:
nodeSelector:
matchLabels:
rack: rack0
virtualRouters:
- localASN: 64512
neighbors:
- peerAddress: '10.0.0.1/32'
peerASN: 64512
authSecretRef: "bgp-password" # <-- specify the secret name
authSecretRef should reference the name of a secret in the BGP secrets
namespace (if using the Helm chart this is kube-system by default). The
secret should contain a key with a name of password.
BGP secrets are limited to a configured namespace to keep the permissions needed on each Cilium Agent instance to a minimum. The Helm chart will configure Cilium to be able to read from it by default.
An example of creating a secret is:
$ kubectl create secret generic -n kube-system --type=string secretname --from-literal=password=my-secret-password
If you wish to change the namespace, you can set the
bgpControlPlane.secretNamespace.name Helm chart value. To have the
namespace created automatically, you can set the
bgpControlPlane.secretNamespace.create Helm chart value to true.
Because TCP MD5 passwords sign the header of the packet they cannot be used if the session will be address translated by Cilium (i.e. the Cilium Agent’s pod IP address must be the address the BGP peer sees).
If the password is incorrect, or the header is otherwise changed the TCP
connection will not succeed. This will appear as dial: i/o timeout in the
Cilium Agent’s logs rather than a more specific error message.
If a CiliumBGPPeeringPolicy is deployed with an authSecretRef that Cilium cannot find, the BGP session will use an empty password and the agent will log an error such as in the following example:
level=error msg="Failed to fetch secret \"secretname\": not found (will continue with empty password)" component=manager.fetchPeerPassword subsys=bgp-control-plane
Graceful Restart
The Cilium BGP Control Plane can be configured to act as a graceful restart
Restarting Speaker. When you enable graceful restart, the BGP session will restart
and the “graceful restart” capability will be advertised in the BGP OPEN message.
In the event of a Cilium Agent restart, the peering BGP router does not withdraw routes received from the Cilium BGP control plane immediately. The datapath continues to forward traffic during Agent restart, so there is no traffic disruption.
Configure graceful restart on per-neighbor basis, as follows:
apiVersion: "cilium.io/v2alpha1"
kind: CiliumBGPPeeringPolicy
metadata:
name: rack0
spec:
nodeSelector:
matchLabels:
rack: rack0
virtualRouters:
- localASN: 64512
neighbors:
- peerAddress: '10.0.0.1/32'
peerASN: 64512
gracefulRestart:
enabled: true # <-- enable graceful restart
restartTimeSeconds: 120 # <-- set RestartTime
Warning
When enabled, graceful restart capability is advertised for IPv4 and IPv6 address families by default. From v1.15, we have a known issue where Cilium takes long time (approximately 300s) to restart route advertisement after graceful restart when Cilium advertises both IPv4 and IPv6 address families, but a remote peer advertises only one of them. You can work around this issue by aligning the address families advertised by Cilium and remote with the families field. You can track #30367 for updates.
Optionally, you can use the RestartTime parameter. RestartTime is the time
advertised to the peer within which Cilium BGP control plane is expected to re-establish
the BGP session after a restart. On expiration of RestartTime, the peer removes
the routes previously advertised by the Cilium BGP control plane.
When the Cilium Agent restarts, it closes the BGP TCP socket, causing the emission of a
TCP FIN packet. On receiving this TCP FIN, the peer changes its BGP state to Idle and
starts its RestartTime timer.
The Cilium agent boot up time varies depending on the deployment. If using RestartTime,
you should set it to a duration greater than the time taken by the Cilium Agent to boot up.
Default value of RestartTime is 120 seconds. More details on graceful restart and
RestartTime can be found in RFC-4724 and RFC-8538.
Advertised Path Attributes
BGP advertisements can be extended with additional BGP Path Attributes - BGP Communities (RFC-1997) or Local Preference. These Path Attributes can be configured selectively for each BGP peer and advertisement type.
The following code block shows an example configuration of AdvertisedPathAttributes for a BGP neighbor,
which adds a BGP community attribute with the value 64512:100 to all Service announcements from the
matching CiliumLoadBalancerIPPool and sets the Local Preference value for all Pod CIDR announcements
to the value 150:
apiVersion: "cilium.io/v2alpha1"
kind: CiliumBGPPeeringPolicy
metadata:
name: rack0
spec:
nodeSelector:
matchLabels:
rack: rack0
virtualRouters:
- localASN: 64512
neighbors:
- peerAddress: '10.0.0.1/32'
peerASN: 64512
advertisedPathAttributes:
- selectorType: CiliumLoadBalancerIPPool # <-- select CiliumLoadBalancerIPPool and add BGP community 64512:100
selector:
matchLabels:
environment: production
communities:
standard:
- 64512:100
- selectorType: PodCIDR # <-- select PodCIDR and add local preference 150 and BGP community 64512:150
localPreference: 150
communities:
standard:
- 64512:150
Note
Note that Local Preference Path Attribute is sent only to iBGP peers (not to eBGP peers).
Each AdvertisedPathAttributes configuration item consists of two parts:
SelectorTypewithSelectordefine which BGP advertisements will be extended with additional Path Attributes.
Communitiesand / orLocalPreferencedefine the additional Path Attributes applied on the selected routes.
There are three possible values of the SelectorType which define the object type on which the Selector applies:
PodCIDR: matchesCiliumNodecustom resources (Path Attributes apply to routes announced for PodCIDRs of selectedCiliumNodeobjects).
CiliumLoadBalancerIPPool: matchesCiliumLoadBalancerIPPoolcustom resources (Path Attributes apply to routes announced for selectedCiliumLoadBalancerIPPoolobjects).
CiliumPodIPPool: matchesCiliumPodIPPoolcustom resources (Path Attributes apply to routes announced for allocated prefixes of selectedCiliumPodIPPoolobjects).
There are two types of additional Path Attributes that can be advertised with the routes: Communities and LocalPreference.
Communities defines a set of community values advertised in the supported BGP Communities Path Attributes.
The values can be of three types:
Standard: represents a value of the “standard” 32-bit BGP Communities Attribute (RFC-1997) as a 4-byte decimal number or two 2-byte decimal numbers separated by a colon (e.g.64512:100).
WellKnown: represents a value of the “standard” 32-bit BGP Communities Attribute (RFC-1997) as a well-known string alias to its numeric value. Allowed values and their mapping to the numeric values:
Well-Known Value
Hexadecimal Value
16-bit Pair Value
internet
0x00000000
0:0
planned-shut
0xffff0000
65535:0
accept-own
0xffff0001
65535:1
route-filter-translated-v4
0xffff0002
65535:2
route-filter-v4
0xffff0003
65535:3
route-filter-translated-v6
0xffff0004
65535:4
route-filter-v6
0xffff0005
65535:5
llgr-stale
0xffff0006
65535:6
no-llgr
0xffff0007
65535:7
blackhole
0xffff029a
65535:666
no-export
0xffffff01
65535:65281
no-advertise
0xffffff02
65535:65282
no-export-subconfed
0xffffff03
65535:65283
no-peer
0xffffff04
65535:65284
Large: represents a value of the BGP Large Communities Attribute (RFC-8092), as three 4-byte decimal numbers separated by colons (e.g.64512:100:50).
LocalPreference defines the preference value advertised in the BGP Local Preference Path Attribute.
As Local Preference is only valid for iBGP peers, this value will be ignored for eBGP peers
(no Local Preference Path Attribute will be advertised).
Once configured, the additional Path Attributes advertised with the routes for a peer can be verified using the
cilium bgp routes Cilium CLI command, for example:
$ cilium bgp routes advertised ipv4 unicast peer 10.0.0.1
VRouter Prefix NextHop Age Attrs
64512 10.1.0.0/24 10.0.0.2 3m31s [{Origin: i} {LocalPref: 150} {Nexthop: 10.0.0.2}]
64512 192.168.100.190/32 10.0.0.2 3m32s [{Origin: i} {LocalPref: 100} {Communities: 64512:100} {Nexthop: 10.0.0.2}]
Address Families
By default, the BGP Control Plane advertises IPv4 Unicast and IPv6 Unicast
Multiprotocol Extensions Capability (RFC-4760) as well as Graceful Restart
address families (RFC-4724) if enabled. If you wish to change the default
behavior and advertise only specific address families, you can use the
families field. The families field is a list of AFI (Address Family
Identifier) and SAFI (Subsequent Address Family Identifier) pairs. The only
options currently supported are {afi: ipv4, safi: unicast} and {afi:
ipv6, safi: unicast}.
Following example shows how to advertise only IPv4 Unicast address family:
apiVersion: "cilium.io/v2alpha1"
kind: CiliumBGPPeeringPolicy
metadata:
name: rack0
spec:
nodeSelector:
matchLabels:
rack: rack0
virtualRouters:
- localASN: 64512
neighbors:
- peerAddress: '10.0.0.1/32'
peerASN: 64512
families:
- afi: ipv4
safi: unicast