Cilium BGP Lab with LoadBalancing and more!

 

At this point, we know how to install Cilium and create a BGP peering with our routers. Now we need to let the outside world reach our Kubernetes apps.

If you don’t have the KinD cluster with Cilium go to https://arielantigua.com/weblog/2024/07/cilium-bgp-lab-locally/

When using Cilium you can reach an application using the Pod IP address or using a LoadBalance IP assigned to a Service. In the previous article we only advertised the Pod Address to our BGP neighbors, lets add more stuff so we can be close to a real deployment.

If you already have cloned the repo, go and do a pull so you can get the new config files and other stuff in the Makefile, or better yet, go and do a new clone of the repo and start from scratch, that’s the idea of the repo!

New stuff in this LAB.

      • serviceSubnet in cluster.yaml (10.2.0.0/16)
      • serviceSelector in the CiliumBGPPeeringPolicy (service = public), this useful to identify what LoadBalancer will be announced by this peering policy.
      • public-pool.yaml with the configuration for the LoadBalancer IP Pool.
      • If you look at the topo.yaml file, will find a new Linux node (client0) for testing, this is based on alpine:latest, will test reachability to our LoadBalancer IP from this container that is connected to tor1 with IP address 10.0.100.2/24
      • Bookinfo application so we can have something to reach from client0.

Now let’s build the environment, just like before, running make will create a KinD cluster with 4 nodes (1 control-plane and 3 workers), a containerlab topology with 3 routers (FRR), and 1 client (Alpine). decide to let alone the Cilium install manually or with make cilium, in case there is a need to do something different with the same KinD cluster or add another option to Cilium at install time.

A black screen with white text Description automatically generated

This is the result of running make, as you can see in the image, now you can go and install Cilium in whatever way you like the most, in this case, I will use these options:

cilium install --version=1.15 \
--helm-set ipam.mode=kubernetes \
--helm-set tunnel-protocol=vxlan \
--helm-set ipv4NativeRoutingCIDR="10.0.0.0/8" \
--helm-set bgpControlPlane.enabled=true \
--helm-set k8s.requireIPv4PodCIDR=true

The fastest way is to do this: make cilium

A screen shot of a computer Description automatically generated

A screen shot of a computer screen Description automatically generated

The nodes are ready for workloads.

Now is the time to apply both, the CiliumBGPPeeringPolicy and the CiliumLoadBalancerIPPool.

You can do it with make or the official way with kubectl.

kubectl apply -f cilium-bgp-peering-policies.yaml 

kubectl apply -f public-pool.yaml

A screen shot of a computer screen Description automatically generated

You can validate the configurations with the following commands.

kubectl get -f cilium-bgp-peering-policies.yaml -oyaml

kubectl get -f public-pool.yaml -oyaml

Our lab environment is ready to assign IP to LoadBalancer services, lest check the existing ones first.

Is time to deploy our test application.

Now there is an app in the repo, you can deploy the bookinfo application, which is used by Istio to do some demos, I just cloned it and added a Service to pick up an Address from our IP Pool and advertised it to the Tor(0,1) routers.

https://github.com/aredan/ciliumlabs/tree/main/bookinfo/kustomize

kubectl apply -k kustomize

A screenshot of a computer program Description automatically generated

Let’s check the Services that we have now.

A screen shot of a computer Description automatically generated

There is our LoadBalancer IP address (10.0.10.1) and others ClusterIP, the LoadBalancer is the one that we will be testing from client0.

A screenshot of a computer program Description automatically generated

We can see there is an IP assigned to the Service, but is better if we can validate that this address is being announced to the Tor routers.

docker exec -it clab-bgp-cplane-router0 vtysh -c 'show bgp ipv4'

A computer screen shot of a computer Description automatically generated

Also, from Cilium itself we can validate that his address is being announced from the virtualRouters.

Within the Cilium CLI exists a subcommand called bgp (hard to pass!!) and with this, we can validate a few things.

A screenshot of a computer Description automatically generated

A screen shot of a computer Description automatically generated

cilium bgp routes advertised ipv4 unicast

A black screen with white text Description automatically generated

Our four nodes are announcing the same address to upstream routers, this is because of the trafficPolicy assigned to the service.

Is time to reach our App.

We need to get into client0 container, this is an alpine container so ash is the shell.

Installing curl and Lynx. In case you don’t know what Lynx is, is a console browser, this feels like traveling to the past when the one that stayed more in the console was the strongest.

A black screen with white text Description automatically generated

A screenshot of a computer program Description automatically generated

A computer screen shot of a black screen Description automatically generated

We can see that curl is reaching the app, this way is hard to interact we the application, now with Lynx!

lynx http://10.0.10.1

A screenshot of a computer Description automatically generated

 

Isovalent (Cilium creators) announced new support for ClusterIP in BGP !!

pathvector – herramienta para configurar BIRD!

pathvector – herramienta para configurar BIRD!

Hace tiempo que estoy usando BIRD para convertir esos servidores Linux en routers con BGP/OSPF y tener enrutamiento dinámico. Uno de los obstáculos iniciales con BIRD era la sintaxis, muy diferente a Cisco y a Quagga (Ahora FRR), sentirme a gusto me tomo tiempo, pero se logro.

De ese cambio ya hace mucho tiempo, el segundo paso luego de usar BIRD es lo fácil que se puede automatizar su configuración, algo que hice en los primeros días era tener los archivos de configuración en Git para así poder versionarlos, luego usaba un contenedor Docker el cual generaba las configuraciones finales, lamentablemente cada herramienta o metodología tenia sus propios problemas y terminaba haciendo configuraciones manuales fuera de la herramienta que intentaba adoptar.

Continuar leyendo «pathvector – herramienta para configurar BIRD!»

Seguridad de Enrutamiento, como estamos y como debemos estar.

Nota: Esto es un post que esta publicado en el portal de ISCO-Dominicana, he decidido publicarlo aqui tambien y asi poder relacionarlo con otros proyectos que tengo en lista.

Seguridad de Enrutamiento, como estamos y como debemos estar.

Cada día la infraestructura de Internet es atacada de formas que no imaginamos, en los últimos años hemos visto como personas y/o organizaciones buscan la manera de lucrarse aprovechando las debilidades en la infraestructura de Internet ya sea apoderándose de recursos o haciendo que estos recursos no estén disponibles para los usuarios.

Muchos sabemos el origen de Internet, en sus primeros años nadie imagino que esta plataforma seria lo que es hoy y por esto, muchos de los protocolos que son pilares de Internet no cuentan con la seguridad necesaria para prevenir que un atacante pueda causar daños a la infraestructura que lo forma. Aunque en sus inicios estos protocolos no tenían esa seguridad que deseamos no quiere decir que no se han creado las medidas para protegerlos.

Continuar leyendo «Seguridad de Enrutamiento, como estamos y como debemos estar.»

VRF en Linux con BIRD para OSPF/BGP

VRF en Linux con BIRD para OSPF/BGP.

Desde hace mucho tiempo estoy jugando con BGP, inicialmente tenía BGP en pfSense, algo sencillo y con solo algunas rutas, eso fue en los tiempos de dn42.

En el 2016 encontré una comunidad de varios entusiastas de redes al nivel de Internet y pude conseguir un ASN registrado en RIPE.

Muchas cosas han cambiado desde esos días, he aprendido y experimentado, aprender es la razón de ser de aaNetworks. Lo complicado de mi red con direcciones IP Publicas y ASN es que localmente en mi casa no hay forma posible de tener una sesión BGP y publicar los prefijos desde ahí (imagínate que CLARO te permita hacer un túnel L2TP a un router con BGP!), dependo de VPS con Linux y BIRD.

Continuar leyendo «VRF en Linux con BIRD para OSPF/BGP»

RIPE Atlas – Estado actual en República Dominicana.

RIPE Atlas – Estado actual en República Dominicana.

Para los que no saben que es RIPE Atlas, es un Proyecto de RIPE NCC, su meta es colectar información de las conexiones a Internet usando un pequeño “probe” que se coloca en la red de un usuario, empresa o proveedor de Internet. Luego este probe realiza pruebas predefinidas para colectar valores como latencia, jitter y hasta pruebas de puertos, probar si DNS está respondiendo en servidores específicos.

No es un proyecto nuevo, los primeros registros se iniciaron en el 2010. Desde entonces existen países que han recibido esto como una herramienta para mejorar, pero lamentablemente otros no lo han hecho de esa manera debido al poco apoyo recibido. Tomaremos como ejemplo Republica Dominicana.

En nuestro país actualmente tenemos registrados 49 probes de los cuales solo 15 están conectados hoy [20/10/2019]. Si miramos detenidamente podremos ver que el primer probe en DO se conecto a la red de Atlas hace 4 años y 17 días y tiene 2 años desconectado.

¿Por qué pasa esto?

Mi opinión es que luego de recibir este pequeño aparato y conectarlo a la red, el usuario no siente que esta obteniendo un beneficio y en cualquier momento decide desconectarlo porque ya entiende que no lo necesita, lamentablemente esto también pasa en empresas, si miramos la lista de probes abandonados ahí muchos que al parecer fueron registrados por una empresa o proveedor y sufrieron la misma suerte.

¿Como podemos mejorar esto?

Tenemos que comprometernos a mejorar la infraestructura de Internet, hasta el menor esfuerzo como es hospedar un probe de RIPE Atlas aporta a mejorar Internet ya que permite que instituciones con áreas dedicadas al desarrollo usen esta plataforma para realizar pruebas de conectividad y entender mejor como cambian las redes de interconexión a través de los años.

¿Qué puedo hacer luego de tener un Probe?

Con RIPE Atlas tenemos que cumplir una condición para poder hacer uso de la plataforma, tenemos que acumular créditos, estos créditos se pueden conseguir dejando nuestro probe encendido y conectado a la red para que genere crédito a nuestro favor o recibiendo una donación de otro usuario. Luego que contamos con créditos podemos crear nuestras propias métricas.

Por ejemplo, hace un tiempo cree una métrica para medir la latencia desde Republica Dominicana a los DNS Resolver de CloudFlare.

En esta conjuración solicite 20 probes, todos de Republica Dominicana, actualmente están participando solo 9.

En la pestana de Latest Results podemos ver los últimos resultados de esta métrica.

En esta pestaña podemos apreciar la cantidad de RTT y HOPs utilizados por el probe para alcanzar a 1.0.0.1 que es uno de los DNS Open Resolver de CF. Lamentablemente uno de los probe está fuera de línea.

Otra pestaña de la cual podemos sacar ventaja es Tracemon.

Esta nos entrega un mapa con los saltos que hicieron los probe para llegar a su destino final, en cada punto podemos ver IP utilizada y ASN al cual pertenece esa IP.

Esto que acabo de mostrar aquí son de las configuraciones mas sencillas que se pueden crear en la plataforma, no soy ningún experto, pero sigo intentando sacarle partido a RIPE Atlas. Actualmente tengo dos probes corriendo, uno con mi ASN ( AS207036 ) y otro detrás del ASN de CLARO.

Para cerrar, si estas interesado en hospedar un probe de manera seria y con compromiso de tenerlo conectado, contáctame, actualmente estoy registrado como Embassador en Republica Dominicana, esto quiere decir que puedo asignar probes de algunos que tengo disponible.