4/19/2023 0 Comments Peakhour edgerouter![]() The maximum-paths value tells how many potential BGP routing targets there can be. The following four commands set each of the Kubernetes worker nodes to be a neighbor to the router. The first real command sets the router-id to 192.168.1.1. The configure, commit, save, and exit commands are just the way how the EdgeRouter’s configuration mode is entered and the changes applied. Then the following commands set up BGP configuration and start up the BGP service in the router: configure set protocols bgp 64512 parameters router-id 192.168.1.1 set protocols bgp 64512 neighbor 192.168.1.201 remote-as 64512 set protocols bgp 64512 neighbor 192.168.1.202 remote-as 64512 set protocols bgp 64512 neighbor 192.168.1.203 remote-as 64512 set protocols bgp 64512 neighbor 192.168.1.204 remote-as 64512 set protocols bgp 64512 maximum-paths ibgp 32 commit save exit To configure the EdgeRouter, one has to ssh into the device or open the CLI window from the GUI, because there is no BGP support in the GUI. ![]() The default address pool has the Service addresses that MetalLB can give out as the addresses field. The number 64512 is the first “private” ASN, meaning it doesn’t belong to any real AS - it can be compared to a private IP address. I chose both peer-asn (the router) and my-asn (the cluster) number to be the same, indicating that both ends of the route are in the same Autonomous System. The peer-address field has the address of the router. In order to set up MetalLB, I applied this ConfigMap: apiVersion: v1 kind: ConfigMap metadata: namespace: metallb-system name: config data: config: | peers: - peer-address: 192.168.1.1 peer-asn: 64512 my-asn: 64512 address-pools: - name: default protocol: bgp addresses: - 192.168.1.224/27 MetalLB installation is simple and well explained in the documentation, so I’ll focus on the configuration. MetalLB deployment to Kubernetes starts a control pod and as many speaker pods as there are worker nodes. MetalLB gives out the addresses from this set. A switch sits between the router and the Kubernetes nodes. ![]() The network setup I have is pretty straightforward. This means that all packets belonging to a certain connection are routed to the same node, which is exactly what we need. Since all the nodes carry the same routing cost, the router selects the route by hashing the network connection details (such as source and destination IPs and the network protocol). MetalLB tells the router that it can route traffic to the service IP via a set of nodes on which the pod runs. Then, when a service of type=LoadBalancer is started, MetalLB assigns it a service IP from an address pool it controls. The idea is this: the router and the Kubernetes worker nodes are configured to be neighbors. ![]() You can read the details about how MetalLB uses BGP from it’s own documentation. MetalLB uses only a subset of BGP features. BGP load balancing is conceptually pretty simple, even though BGP itself is a complex protocol. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |