0

LACNIC31 – dia 4

LACNIC31 – dia 4

Hemos tenido otra sesión de discusión sobre políticas las cuales se busca que sean aceptadas mediante consenso, vuelvo y repito, esto es un tema el cual no quiero abordar sin tener cierto conocimiento de como es el proceso de aplicación y aprobación de estas, más adelante será.

https://www.lacnic.net/3635/49/evento/agenda-lacnic-31#miercoles-fpp

A las 11:30 inicio el FTL (Foro Técnico de LACNIC), recomendado para todos aquellos apasionados a las tecnologías como yo.

Aquí una lista de los temas presentados en el FTL y un pequeño comentario personal:

Introducción Foro Técnico de LACNIC

Esta es la presentación y que pasa en el FTL, también aprovecharon para invitar a otros a que participen en esta iniciativa de LACNIC.

Presentación: https://www.lacnic.net/innovaportal/file/3635/1/presentacion-ftl-2019.pdf

Video: https://youtu.be/ZGkDtoqvAIk

Problemas de seguridad del mundo real en una nube pública

Muchos de los problemas presentados aquí son conocidos y si no me equivoco existen implementaciones para mitigar ataques ya sean internos o externos, siendo los ataques internos (otro tenant o un empleado furioso) los más difíciles de detectar.

Presentación: https://www.lacnic.net/innovaportal/file/3635/1/charliekaufman.pdf

Video: https://youtu.be/HyGqL5YIfxc

UpDown RPKI LACNIC

Super interesante presentación sobre la funcionalidad UpDowm de RPKI, necesito investigar un monto sobre y esto y de posibles automatizaciones con BIRD y RouterOS que son las plataformas de enrutamiento que actualmente estoy usando.

Presentación: https://www.lacnic.net/innovaportal/file/3635/1/12-updown_rpki_lacnic.pdf

Video: https://youtu.be/RP6ePaLcp-Q

Juntos es posible, el paradigma de compartir los costos

Una presentación la cual me deja pensando y me apena, aquí podemos ver como se logra completar un proyecto que aporta a una nación de manera gigantesca, un IXP es parte de la infraestructura necesaria para que un país pueda sostenerse en caso de incidentes que afecten enlaces internacionales, lamentablemente, en RD tenemos poco interés en resolver este tema.

Presentación: https://www.lacnic.net/innovaportal/file/3635/1/63-juntos.pdf

Video: https://youtu.be/2QveRcIPOCw

Automatización de listas de prefijos en peering BGP – Cómo hacerlo y su importancia

Excelente presentación donde nos muestran herramientas para crear de manera automática las listas que usaremos en los filtros de BGP y así poder controlar anuncios recibidos por ASN conectados al nuestro. Usando IRR como fuente de información se crean listas para permitir que una subred sea anunciada a otros o aceptadas por nosotros mismos.

Presentación: https://www.lacnic.net/innovaportal/file/3635/1/48-lacnic31-douglasfischer_automatizacaodelistasdeprefixosbgp.pdf

Video: https://youtu.be/qBD7zCnbTF4

Privacidad en DNS

Esta demostrado que cada día la información generada por un computador es de mucho valor para terceros, soy muy participe de exponer lo mínimo de mi información personal al Internet, muchas veces se expone esta información de manera voluntaria, pero en otras ocasiones somos víctimas de técnicas para colectar dicha información.

Estas técnicas son desconocidas por muchas personas y es difícil entender porque deben hacer cambios en sus redes si todo esta funcionando bien. Personalmente no utilizo DNS de terceros, esta presentación me da mas razones para seguir corriendo mis propios DNS y apunarlos a los root zones sin necesidad de un resolver de una entidad la cual puede usar mi información para sacar beneficios.

Presentación: https://www.lacnic.net/innovaportal/file/3635/1/fgont-lacnic-ftl2019-dns-privacy-final.pdf

Video: https://youtu.be/Gq_QHu8mCQs

Servicios de información de RIPE NCC para operadores

Desde hace alrededor de dos anos estoy usando varias herramientas de RIPE NCC, una de estas es RIPE Stats ( https://stats.ripe.net ), mucha información interesante desde el punto de vista curioso y mucho mas del punto de vista técnico.

https://stat.ripe.net/AS207036#tabId=at-a-glance

Presentación: https://www.lacnic.net/innovaportal/file/3635/1/lacnic-31-en_comms-3.pdf

Video: https://youtu.be/cpIQOaA4bI0

BSDRP – Una opción de softrouter con FRR

Este es un viejo conocido y mucho mas aun porque esta basado en el sistema operativo que mas me ha gustado en todo el tiempo que he usado OpenSource, FreeBSD.

BSDRP es un proyecto fundado por la misma persona que una vez trabajo en FreeNAS. Este señor es un maestro en los equipos de embebidos.

Algo que tenia ganas de preguntar es porque uso FRR y no BIRD, no quería montar un flame-war 😊

Presentación: https://www.lacnic.net/innovaportal/file/3635/1/4-bsdrp-lacnic31.pdf

Video: https://youtu.be/8DdtN_fj_uQ

RIPE Atlas Anchors en Máquinas Virtuales

Atlas, una plataforma que aporta un montón para un operador de redes, lamentablemente en RD ahí poco compromiso con este tipo de iniciativa.

Hace más de dos años que tengo un corriendo detrás de mi ASN (AS207036), he solicitado otro para ponerlo detrás de CLARO (AS6400).

https://atlas.ripe.net/probes/?search=&status=&af=&country=DO

Aquí se pueden ver los desplegados en DO y la gran cantidad de probes abandonados.

https://atlas.ripe.net/probes/28779/ – aaNetworks Probe – parece que tener que renombrarlo a Probe1

Presentación: https://www.lacnic.net/innovaportal/file/3635/1/ripe-atlas-virtual-machine-anchors-lacnic-31_last.pdf

Video: https://youtu.be/A7AvGVayQAA

0

LACNIC31 – dia 3

LACNIC31 – dia 3

Oficialmente LACNIC31 inicia el día de hoy con varios eventos de “rendición de cuenta” diría yo. La lista de estos eventos se puede encontrar en: https://www.lacnic.net/3635/49/evento/agenda-lacnic-31#martes-lacnic

Donde quiero que se enfoquen es en el Keynote, Radia Perlman ha tenido a cargo esta parte del inicio, y personalmente hacia muchos anos que no prestaba atención a alguien hablar como a esta señora, aun mejor cuando he investigado y leído que ha sido la creadora del Spanning Tree Protocol y grandes contribuciones como link-state routing protocols del cual se derivan tales como el protocolo de enrutamiento IS-IS y OSPF.

La presentación es mayormente una recopilación de acontecimientos y decisiones hechas en torno al desarrollo o colaboración en nuevas tecnologías.

Para los que se la perdieron en la transmisión en vivo, el STAFF de LACNIC ya ha publicado el video!

https://www.youtube.com/watch?v=0DcogUv4NNM&feature=youtu.be

nota: si quieren entender mejor como funciona spanning tree, prestarle atención al poema, epico!!

Foro público de políticas

Muy importante sección esta, se discutieron varias políticas que actualmente tiene el estado = DISCUSION. Como comenté en el post anterior, espero poder integrarme a este tipo de aportes porque me interesa mucho que los cambios necesarios sean realizados y así todos saldremos beneficiados.

El día de mañana promete mucho y tendrá más sesiones técnicas que los anteriores!!!

 

0

LACNIC31 – dia 2

LACNIC31 – dia 2

¡Seguimos sacándole provecho a este evento!

El día de hoy ha sido completo de IPv6, hemos tenido un refresh de que es IPv6 y de planes de direccionamiento, una de las partes más interesantes fue de los mecanismos de transición disponibles actualmente, en esta sección vimos los pro y contras de algunos de estos y las recomendaciones.

Mecanismos de transición IPv6-only y IPv4aaS en redes fijas y móviles.

https://www.lacnic.net/innovaportal/file/3512/1/ipv6-only_v13.pdf

Si le pegamos una mirada a la presentación de Jordit Palet podremos ver varias comparaciones y recomendaciones para ayudarnos al momento de seleccionar unas de estas tecnologías.

Una cosa esta clara, NAT64 tiene demasiados temas pendientes.

Teniendo en cuenta todo lo bueno que se hablo de 464XLAN este parece ser el ganador indiscutible, no crean mucho de lo que escribo con relación a esta implementación ya que no la he usado y pretendo subir unos laboratorios relacionado a estos métodos de transición.

IPv6 en Cable

Otro tema discutido en el día de hoy fue con relación a despliegues en un operador de Cable, muchas de las decisiones realizadas en este despliegue se pueden extrapolar a una implementación de otro tipo, por ejemplo, una implementación Wireless teniendo en cuenta que se debe tener control de CPE y que este soporte CLAT o dual-stack en el mejor de los casos.

https://www.lacnic.net/innovaportal/file/3512/1/lacnic-31—tutorial-ipv6-en-redes-de-cable-v2.pdf

 

Demo con conexión a internet de Jool/464XLAT.

Para cerrar el día nos han presentado una herramienta desarrollada por NIC México la cual nos permite implementar una plataforma con mecanismo de transición de IPv4/IPv6 de una manera rápida y fácil.

Robándome un poco de la página oficial del proyecto:

Jool is an Open Source implementation of IPv4/IPv6 Translation on Linux. Until version 3.2.x, it used to be only a Stateful NAT64; starting from 3.3.0, it also supports SIIT mode.

Si miramos en las implementaciones de transición soportadas vemos que sobre sale:

RFC 6877 464XLAT Rather implemented as SIIT-DC-DTM; see below.

Realizamos varios laboratorios los cuales se pueden encontrar en la diapositiva publica de la sesión:

https://www.lacnic.net/innovaportal/file/3512/1/jool.lacnic.31.pdf

Voy a probar esta solución en mi ambiente de enrutamiento virtual basado en EVE-ng para entender mejor como esta plataforma encajaría en una red empresarial y las ventajas que nos brindaría.

0

LACNIC31 – dia 1

LACNIC31 – dia 1

Iniciando con mi primera asistencia a este evento, hoy todo ha ido muy tranquilo.

Llegada al hotel, registro al evento y asistencia a la Sesión para Becados. La sesión fue muy interesante y saber que aplicaron casi 500 personas para asistir como becados a LACNIC31, de los cuales solo se seleccionaron 38 (conté la lista en lacnic.net) y saber que he sido uno de ellos me emociona mucho, y esa es la razón por la cual verán posts relacionados a LACNIC31 toda esta semana.

Luego de terminar la Sesión para Becados, me quede para la segunda sesión del día que fue relacionada a las políticas que se van a discutir en esta semana.

Es importante participar de las discusiones de políticas en LACNIC, aunque no lo he hecho anteriormente pretendo activarme en lo que a esto respecta para cambiar algunas cosas que personalmente no me gustan de cómo funciona la asignación de direcciones en LACNIC, eso es un tema para otro post.

Aquí esta la lista de políticas que están para discusión, si les interesa claro.

https://politicas.lacnic.net/politicas/list?state=ENDISCUSION

0

Kubernetes en premisa con MetalLB en modo BGP.

Kubernetes en premisa con MetalLB en modo BGP.

Una de las desventajas de tener un cluster de k8s en premisa es la falta de LoadBalancer. Gracias a MetalLB esto está resuelto de una manera fácil y elegante.

Cuando queremos publicar servicios en k8s, lo hacemos usando un Ingress Controller (nginx o Traefik por nombrar algunos). Este servicio se apoya de las direcciones IP de los hosts si no tenemos LoadBalancer. El tema se complica cuando queremos publicar servicios que no son HTTP o HTTPS, sé que nginx puede publicar otros protocolos. La ventaja de un IP via LoadBalancer es que podemos usarlos en varios servicios (pods) y publicar cualquier puerto en TCP o UDP.

MetalLB

Los requerimientos son los siguientes:

  • Un cluster de k8s en la versión 1.9.0 o más reciente y que no tenga un tipo de LoadBalancer en funcionamiento, esto quiere decir que tendríamos problemas usando esta solución en GKE por ejemplo.
  • Una configuración de cluster que pueda coexistir con MetalLB https://metallb.universe.tf/installation/network-addons/
  • Direcciones IPv4 para asignar usando este servicio.
  • Dependiendo del modo operativo, podríamos necesitar un router que soporte BGP.
  • https://metallb.universe.tf/#requirements

En mis primeras pruebas, MetalLB fue configurado usando Layer2 (capa 2), es la forma más rápida de probar esta solución, después de varios días de desplegar aplicaciones que hacían uso de LoadBalancer me di cuenta de que algunas direcciones IP de momento no respondían a las peticiones ARP que son necesarias para alcanzar dicha dirección IP. Por esta razón ahora desplegare MetalLB usando BGP.

En modo BGP, la configuración es más extensa y cuanta con campos que tendrán sentido si se ha usado BGP anteriormente.

En mi caso, ya tengo algo de experiencia usando este protocolo y por eso decidí cambiar de Layer2 a BGP en lugar de buscar una solución al problema descrito anteriormente. Además, mi router de core soporte BGP.

Configuración en Mikrotik RouterOS.

Debemos preparar el router (o en su defecto un Switch con L3 & BGP) para aceptar sesiones BGP desde los nodos de k8s, MetalLB ejecutara un agente en todos los nodos de k8s y estos iniciaran una sesión BGP con nuestro router.

Configuración básica en RouterOS – CLI:

/routing bgp instance
set default as=64635 redistribute-connected=yes redistribute-static=yes router-id=10.45.254.2
/routing bgp peer
add multihop=no name=kube1 remote-address=172.22.35.25 remote-as=64636 ttl=default
add multihop=no name=kube2 remote-address=172.22.35.26 remote-as=64636 ttl=default
add multihop=no name=kube3 remote-address=172.22.35.27 remote-as=64636 ttl=default

 

Instalando MetalLB.

kubectl apply -f https://raw.githubusercontent.com/google/metallb/v0.7.3/manifests/metallb.yaml

También se puede instalar usando Helm, para más información: https://metallb.universe.tf/installation/

Revisamos nuestro entorno k8s para validar que tenemos los componentes de MetalLB en un correcto estado.

¡Excelente! Tenemos tres speaker, uno en cada nodo.

Configurando MetalLB.

Necesitamos un kind tipo ConfigMap para aplicar la configuración deseada a MetalLB.


apiVersion: v1

kind: ConfigMap

metadata:

namespace: metallb-system

name: config

data: config: |

peers:

- peer-address: 172.22.35.1

peer-asn: 64635

my-asn: 64636

address-pools:

- name: default

protocol: bgp

addresses:

- 172.22.35.64/26

bgp-advertisements:

- aggregation-length: 32

localpref: 100

communities:

- name: public

protocol: bgp

addresses:

- 200.1.154.64/26

auto-assign: false

bgp-advertisements:

- aggregation-length: 32

localpref: 100

communities:

Aplicamos el configMap:

Si todos nuestros parámetros son correctos, revisamos en el core router y debemos tener las sesiones BGP establecidas.

¿Qué tenemos?

En este punto deberemos contar con la opción de seleccionar una dirección IP, en mi caso podría ser del pool llamado default o del pool llamado public, se puede diferenciar que las IP del pool llamado public son ruteables y existen en la tabla de Internet (200.1.154.0/24).

Vamos a inicializar un pod que haga uso de una dirección del pool default. Para esto usare un contenedor con un servicio de SMTP el cual no necesita almacenamiento.

Deployment + Service

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
labels:
app: smtp
name: smtp
spec:
progressDeadlineSeconds: 600
replicas: 1
revisionHistoryLimit: 10
selector:
matchLabels:
app: smtp
strategy:
rollingUpdate:
maxSurge: 1
maxUnavailable: 1
type: RollingUpdate
template:
metadata:
creationTimestamp: null
labels:
app: smtp
spec:
containers:
- env:
- name: RELAY_NETWORKS
value: 172.22.35.0/24:10.45.0.0/16:200.1.154.0/24
image: namshi/smtp
imagePullPolicy: IfNotPresent
name: smtp
ports:
- containerPort: 25
name: smtp-port
---
apiVersion: v1
kind: Service
metadata:
creationTimestamp: null
labels:
app: smtp
name: smtp
annotations:
metallb.universe.tf/allow-shared-ip: ekvm
metallb.universe.tf/address-pool: default
spec:
externalTrafficPolicy: Local
ports:
- name: smtp
nodePort: 25
port: 25
protocol: TCP
targetport: smtp-port
selector:
app: smtp
loadBalancerIP: 172.22.35.70
type: LoadBalancer</pre>

¡Excelente!

¡Nuestro servicio de SMTP responde en el IP asignado por MetalLB!

El próximo paso es el almacenamiento.