Podcast de Redes de Eduardo Collado 2c4r6x

En la era digital actual, la decisión de dónde alojar tus servidores y datos es crucial para el éxito de tu negocio. Dos de las opciones más comunes son tener tus propios servidores en un centro de datos o utilizar una nube pública. Ambas tienen ventajas y desventajas, pero en este artículo exploraremos por qué tener tus propios servidores en un centro de datos puede ser la elección más acertada en muchas situaciones. Desde el control y la seguridad hasta la flexibilidad y los costes, hay una serie de razones convincentes para considerar esta opción. Control Total Una de las razones principales para optar por tener tus propios servidores en un centro de datos es el control total que obtienes sobre tus recursos informáticos, o como a los marketinianos les gusta llamarlos los "activos digitales". Cuando alojas tus servidores en una nube pública, estás confiando en un proveedor externo para gestionar y mantener esos servidores. Si bien esto puede ser conveniente en algunos casos, también significa que tienes limitaciones en cuanto a cómo puedes configurar y personalizar tus servidores. En contraste, cuando tienes tus propios servidores en un centro de datos, tienes el control total sobre la infraestructura. Puedes personalizar cada aspecto de tus servidores para satisfacer tus necesidades específicas. Esto es especialmente importante para empresas que tienen requisitos particulares en cuanto a rendimiento, seguridad y compatibilidad. Seguridad y Privacidad La seguridad y la privacidad son preocupaciones fundamentales en el mundo digital de hoy en día. Cuando utilizas una nube pública, estás confiando en el proveedor de la nube para proteger tus datos y servidores. Aunque muchos proveedores de nube tienen altos estándares de seguridad, aún existe el riesgo de que tus datos puedan ser comprometidos debido a un fallo en el proveedor o un ataque dirigido. Tener tus propios servidores en un centro de datos te brinda un mayor control sobre la seguridad y la privacidad de tus datos. Puedes implementar tus propias políticas de seguridad, configurar cortafuegos personalizados y tomar medidas adicionales para proteger tu infraestructura. Esto es especialmente importante si manejas datos sensibles o confidenciales, como información financiera o de clientes. Rendimiento Personalizado El rendimiento es otro aspecto crucial en la elección entre una nube pública y tus propios servidores. Cuando utilizas una nube pública, al final estás compartiendo recursos con otros s. Esto significa que el rendimiento de tus servidores puede verse afectado por las cargas de trabajo de otros clientes en la misma nube. Si necesitas un rendimiento consistente y personalizado, tener tus propios servidores te da la ventaja de poder configurarlos de acuerdo a tus necesidades específicas. Además, tener servidores dedicados en un centro de datos te permite escalar tu infraestructura de manera más eficiente. Puedes agregar más capacidad de procesamiento, almacenamiento o memoria según lo requieras, sin depender de las limitaciones de una nube pública. Cumplimiento Regulatorio Para muchas empresas, el cumplimiento regulatorio es un factor crítico a considerar. Dependiendo de tu industria y ubicación geográfica, es posible que debas cumplir con ciertos requisitos legales y normativas relacionados con la seguridad y la privacidad de los datos. Tener tus propios servidores en un centro de datos te permite un mayor control sobre el cumplimiento de estas regulaciones. Puedes implementar medidas específicas para cumplir con los estándares de tu industria y mantener un registro detallado de cómo se gestionan tus datos. Esto puede ser mucho más complicado de lograr en una nube pública, donde el proveedor puede estar sujeto a regulaciones diferentes a las tuyas. Costes a Largo Plazo Si bien puede parecer que alojar tus servidores en una nube pública es más económico a corto plazo debido a la falta de gastos iniciales de infraestructura, es importante considerar los costes a largo plazo. Los servicios de nube suelen tener modelos de precios basados en suscripción que pueden aumentar con el tiempo a medida que tu infraestructura crece. Por otro lado, cuando tienes tus propios servidores, tienes un coste inicial más alto para adquirir y configurar la infraestructura, pero los costes operativos a largo plazo pueden ser más predecibles y, en muchos casos, más bajos. Esto es especialmente cierto si planeas mantener tus servidores durante varios años. Realmente al final tus costes son el coste del armario o rack y el coste del tránsito o conectividad. Flexibilidad y Personalización La flexibilidad y la personalización son aspectos clave que pueden influir en tu decisión. Cuando alojas tus servidores en una nube pública, estás limitado por las opciones y configuraciones que ofrece el proveedor de la nube. Si deseas una solución altamente personalizada o necesitas ejecutar software específico, es posible que te encuentres con restricciones. Tener tus propios servidores te brinda la libertad de personalizar tu infraestructura según tus necesidades. Puedes seleccionar los componentes de hardware y software que mejor se adapten a tu carga de trabajo y objetivos comerciales. Confiabilidad y Disponibilidad La confiabilidad y la disponibilidad son esenciales para cualquier empresa. Si tus servidores están fuera de servicio, tu negocio puede sufrir graves interrupciones. Cuando dependes de una nube pública, estás en manos del proveedor de la nube para garantizar la disponibilidad. Tener tus propios servidores en un centro de datos te permite implementar medidas de alta disponibilidad y recuperación ante desastres a medida de tus necesidades. Puedes configurar sistemas redundantes y realizar copias de seguridad de tus datos de manera más específica para garantizar que tu negocio pueda seguir funcionando incluso en caso de problemas. Conclusiones En resumen, la elección entre tener tus propios servidores en un centro de datos y utilizar una nube pública depende de tus necesidades comerciales específicas y tus prioridades. Si valoras el control total, la seguridad, el rendimiento personalizado, el cumplimiento regulatorio, los costes a largo plazo, la flexibilidad, la confiabilidad y la disponibilidad, tener tus propios servidores en un centro de datos puede ser la mejor opción. Sin embargo, es importante destacar que no existe una respuesta única para todas las situaciones. Algunas empresas pueden encontrar que una combinación de ambas opciones, conocida como "nube híbrida", es la más adecuada para ellas. En última instancia, la elección dependerá de tus objetivos comerciales y recursos disponibles, pero es esencial considerar todas las implicaciones antes de tomar una decisión informada sobre dónde alojar tus servidores y datos.

Spanning Tree está pensado para evitar bucles y la información del protocolo se transporta por la red gracias a unos paquetes llamados BPDU (Bridge Protocol Data Unit). Estas BPDUs contienen información sobre switches, prioridades de puertos y direcciones. Realmente lo básico que podemos hacer para protegernos son 4 cosas: Portfast BPUGuard BPDUFilter RootGuard Portfast En Spanning Tree tenemos varios estados por los que tiene que pasar un puerto antes de ponerse en fordward o envío, ya sabéis: desactivado, bloqueo, escucha, aprendizaje y envío. Si habilitamos el portfast el puerto va a pasar automáticamente de bloqueo a envío, ni va a aprender macs antes ni nada, directamente se pone en forwarding. Este es muy útil en puertos que tengan un host en el que estén conectado en un puerto de y que necesite DH. Poniendo ejemplos de centros de datos podríamos configurar así un puerto de una iDRAC, IPMI o como vuestro fabricante favorito llame al puerto de consola remota y que por algún motivo, que no llevo a comprender, en vez de configurar la IP fija se le pone DH. En ese caso necesitaríamos que el puerto pase directamente a forwarding. Es decir, usaremos portfast en un puerto de los denominados edge. La configuración en un nexus será: switch(config)# int ethernet 1/45 switch(config-if)# spanning-tree port type edge Y en un catalyst, si alguien aún tiene podría ser switch(config)# int ethernet 1/45 switch(config-if)# spanning-tree portfast También podríamos hacer que los puertos por defecto estén en portfast, esto lo haremos: switch(config)# spanning-tree portfast default Pero a mi eso no me gusta demasiado y por eso prefiero ir puerto por puerto. Aquí estamos haciendo trampa pues también existe el comando switch(config)# int ethernet 1/45 switch(config-if)# spanning-tree port type edge trunk ¿Cómo que port type edge trunk? ¿Qué brujería es esta? Mente abierta, porque es posible que tengamos un servidor con varias vlans, varios subinterfaces, ese es el motivo, pero eso sí, siempre son puertos de edge, nunca un switch. BPUGuard Si portfast lo que hace es saltarse los estados de Spanning Tree ¿cómo hacemos para que el puerto caiga si recibe alguna BPDU?, para eso tenemos el BPDUGuard. Cuando habilitamos el BPDUGuard si se recibe una BPDU por ese puerto el puerto se queda en el estado errdisable. ¿Es recomendable usar esto? Pues depende qué tengamos conectado al otro lado, si lo que hay es un servidor pues el portfast es suficiente, pero si es un switch y queremos que el puerto caiga si recibimos por ahí BPDUs es muy reoocmendalbe poner el bpduguard. switch(config)# int ethernet 1/45 switch(config-if)# spanning-tree port type edge trunk switch(config-if)# spanning-tree bpduguard enable Por supuesto también se puede habilitar globalmente, pero como antes, no os lo recomiendo. No lo he dicho, pero para quitar el errdisable primero se soluciona el problema y luego se tira el puerto y se vuelve a levantar. BPDU Filter Esta funcionalidad es algo parecido a desactivar el Spanning Tree en un puerto. El BPDUFilter lo que hace es dejar de eviar BPDUs por ese puerto y obviamente no espera recibir BPDUs por ahí. Esto para configurarlo es: switch(config)# int ethernet 1/45 switch(config-if)# spanning-tree port type edge trunk switch(config-if)# spanning-tree bpdufilter enable Si configuramos BPDUfilter en dos switches enfrentados y configuramos los puertos como portfast el puerto levantará. Esta característica yo no la uso demasiado, pero oye, ahí está por si la necesitáis para lo que sea. Por supuesto también se puede habilitar globalmente. RootGuard Esta característica sí que me resulta muy interesante en redes en las que tenéis nodos centrales, algo muy común. Imaginad que tenéis una red en la que tenéis un par de switches más grandes donde concentráis todo y queréis que esos switches sean el root del spanning tree. Por supuesto le definís que sean el root del spanning tree, pero tenemos que prevenir que un switch por debajo se llegue a convertir en el root de spanning tree de la red, es decir, estamos indicando donde debe de estar el root en la red. Aquí hay un tema que quizás parezca un poco confuso y es la diferencia entre BPDUGuard y RootGuard. En BPDUGuard lo que hacemos es desabilitar un puerto si recibe una BPDU y ponerlo en errdisable, mientras que en RootGuard si recibe BPDU que indique ese es un root port, es decir, que por ahí se va al root lo que hace es poner el puerto en inconsistente y bloquear el puerto. La configuración sería: switch(config)# int ethernet 1/45 switch(config-if)# spanning-tree guard root

A día de hoy levantar una VPN está chupado, levantar un wireguard es una tarea sencilla que podemos hacer en un momento. Si tenemos que acceder a una red remota podemos hacerlo con un wireguard, claro que sí, sin problema, pero muchas veces necesitamos una solución rápida y directa, algo más rápido que levantar una VPN, o incluso puede que levantar una VPN sea un poco complicado porque se pisen direccionamientos o cualuier otro motivo. Para acceder a servicios remotos a veces lo más fácil es levantar un túnel SSH desde tu propio equipo y a funcionar. La forma más común de levantar un túnel SSH quizás seá con e en Windows, porque sí, los s de Windows también hacen cosas interesantes. Los túneles SSH los podemos hacer de dos formas: De nuestra máquina hacia afuera (ssh -L) Del destino a nuestra máquina (ssh -R) Elegiremos el túnel SSH normal o el túnel SSH inverso dependiendo de cómo tengamos la conexión. Por ejemplo si nosotros queremos ver en un puerto de localhost algo que está en una máquina a la que se llega por nuestra máquina de salto será un SSH normal. Si nosotros queremos abrir un puerto a una conexión externa entonces usaremos un SSH inverso. Donde se ve -> nosotros -> Destino nosotros -> máquina de salto -> destino ¿Cuando se usa esto? Cuando tienes a una red mediante una única máquina de salto por ssh, cuando quieres abrir una aplicación interna a una máquina externa sin exponerla a internet. La última vez que lo he usado ha sido por ejemplo hoy que he tenido que acceder a un entorno web de unos equipos de red tunelizando la web a través de una conexión ssh. A mi me pasa muchas veces que tengo que acceder a una máquina a la que no tengo directo, por ejemplo una máquina de salto ssh -L 7001:10.10.10.10:80 @pub001.host ssh -R 8081:10.10.10.10:80 @mipc

Hoy vamos a hablar de Multiple Spanning Tree Protocol (802.1s) o también conocido como MST. En el mundo Cisco la mayoría de las empresas levantan VLANs, esas VLANs tienen asociada una instancia de Spanning Tree y hay mucha gente que no se pregunta mucho más sobre eso, simplemente si quieres ver los puertos bloqueados pues show spanning tree vlan 55 Y poco más, como mucho se define el root de alguna instancia de spanning tree para que el root de la instancia de la vlan 55 esté en un switch determinado y poco más. El protocolo que se utiliza por defecto en Cisco para el Spanning Tree es PVST+ y es el protocolo ideal para la gran mayoría de las redes empresariales, pero tiene un límite, el límite es que PVST+ sólo permite 128 instancias, que son muchas, pero claro, hay gente que necesita más de 128 VLANs en su red, en ese caso, la 129 no correrá spanning tree. Al configurar la vlan 129ª saldrá un mensaje diciendo que se ha quedado sin instancias de PVST y que esa vlan nueva no va a tener spanning tree y claro, la primera vez que ves ese mensaje se entra en crisis, ¿cómo que no voy a tener spanning tree en las vlans nuevas. Este es un tema que no he tratado anteriormente porque no creía que fuera una necesidad pero sin ir más lejos el otro día estaba mirando una red y saltó esta necesidad, en esa red había necesidad de bastantes más vlans que 128 y claro, por defecto hay PVST+ y no nos sirve para el Spanning Tree de esta red. Como opciones tendríamos CST o MST y claro, CST no vamos ni a considerarla. La elección del tipo de Spanning Tree depende de dos factores: Ubicación del root Utilización de los enlaces Ubicación del root Si tenemos una vlan de almacenamiento donde siempre va a ser necesario que todo el tráfico llegue a una cabina está claro que el root del STP tendría que estar en la cabina porque queremos que todos los enlaces de ese switch estén disponibles y no cortados. Utilización de los enlaces Con Spanning Tree podemos hacer que unas instancias vayan por un enlace y otras por otro, de forma que, si tenemos dos enlaces, tengamos utilizados ambos enlaces, obviamente la suma no debería ser mayor al ancho de banda de uno de los enlaces, teniendo en cuenta que son iguales. El objetivo de este capítulo no es explicar como funciona spanning tree, de eso ya hablé en Enero de 2018 en este mismo podcast en el capítulo Spanning Tree, el objetivo es que sepáis qué hacer cuando os quedéis sin instancias disponibles en PVST+. MST La solución será MST, que sólo nos ofrece 64 instancias, pero con la gracia de que podemos agregar vlans a una instancia, dividiendo de forma idéntica podríamos tener, por ejemplo, 64 instancias con 64 vlans cada instancia. Seguro que muchas vlans comparten la misma estructura, son vlans en las que tenemos servidores o PCs que tienen que comunicarse con un router, pues en este caso el root lo ponemos en el switch donde esté el router y todas esas vlans en una misma instancia, así que compartirán topología de nivel 2. Por desgracia nadie empieza una red utilizando MST, sino utilizando PVST+, por comodidad o por no pensar en el futuro Yo mismo nunca he iniciado una red desde 0 con MST, y siempre me arrepiento muchísimo, porque el cambio a MST es inevitable ya que el llegar a 128 instancias es sólo cuestión de tiempo. ¿Cómo levantaríamos el MST desde el principio? switch# conf t Enter configuration commands, one per line. End with CNTL/Z. switch(config)# spanning-tree mode mst switch(config)# spanning-tree mst configuration switch(config-mst)# instance 1 vlan 1 switch(config-mst)# instance 2 vlan 2-5 switch(config-mst)# instance 3 vlan 6,7,8 switch(config-mst)# exit switch(config)# spanning-tree mst 0-3 root primary Como se ve la configuración es muy sencilla y se entiende perfectamente spanning tree tradicional, si asignáramos una vlan a una instancia al final tendríamos el mismo comportamiento que PVST+. Migración de PVST+ a MST En un Mundo ideal podríamos convertir la configuración de todos los switches a la vez y ya estaría, pero ya sabéis que eso no va a suceder nunca, así que vamos a tener que ir paso a paso para hacer la conversión en la red. Identificar los puertos de de la red y configurarlos como spanning-tree portfast, como spanning-tree port type edge o como sea en el switch donde estemos. Asignar vlans a instancias de MST y decidir donde va a  estar el root primario y el secundario para cada instancia. Ojo, la instancia 0 no hay que usarla. Aprovechando que MST puede interactuar con PVST+ a nivel de puerto se pueden mantener ambas topologías a la vez. Ojo aquí porque hay que asegurarse que los trunks lleven todas las vlans. Asegurarse que los switches PVST+ tienen menor root bridge (numeración superior) que el CST, el root del MST instancia 0. Y lo más importante, no es que puedas tener un corte en la red, es que seguro que lo vas a tener, así que no hagas esto en hora de máximo tráfico. Una vez que se haya terminado hay que hacer dos cosas, tunear el MST con el port-priority switch(config-if)#spanning-tree mst 2 port-priority 64 Y limpiando la configuración que quede de PVST+ switch(config)#no spanning-tree backbonefast switch(config)#no spanning-tree backbonefast switch(config)#interface FastEthernet1/0/24 switch(config-if)#no spanning-tree vlan 20,40,200 port-priority 64 Una vez limpia la configuración procederemos a configurar MST en el siguiente y así iremos bajando niveles.

Hoy por la tarde ha pasado lo típico, nos hemos juntado 5 amigos a charlar, a charlar sobre como afecta el pensar en IPv4 cuando tienes que poner en funcionamiento IPv6, lo típico de cualquier charla entre amigos. Nos hemos juntado Adrián Almenar, DMNTR, Carlos Fraga, Andreu Adrover y un servidor alrededor de una sala de Zencastr y hemos grabado algo más de una hora de charla informal sobre el tema de moda en estos momentos ;-), el IPv6. Espero que os guste.

Hoy os traemos Adrián y yo una conversación sobre la gestión de filtros en BGP. A veces cuando contratáis un tránsito os piden que les digáis los rangos que se van a anunciar, pues mal, eso no es lo más adecuado desde que tenemos los objetos de RIPE AS y AS-SET. En el capítulo de hoy os contamos la diferencia entre access-list, prefix-list y route-map. También os hablamos de bgpq4 que podéis descargar desde https://github.com/bgp/bgpq4. Otra cosa que os comentamos es la direfencia entre AS y AS-SET y luego hablamos de RPKI y cómo automatizar los filtros. Ejemplos: Lista de prefijos: bgpq4 -A -SRADB,RIPE -F ‘%n/%l\n’ -4 AS-TECNOCRATICA bgpq4 -A -SRADB,RIPE -F ‘%n/%l\n’ -6 AS-TECNOCRATICA Lista de prefijos de sólo un AS: bgpq4 -A -SRADB,RIPE -F ‘%n/%l\n’ -4 as15954 bgpq4 -A -SRADB,RIPE -F ‘%n/%l\n’ -6 as15954 Configuración Cisco: bgpq4 -Al tecnocratica AS-TECNOCRATICA bgpq4 -Al tecnocratica -6 AS-TECNOCRATICA El ejemplo de un comando de cada sería: $ bgpq4 -A -SRADB,RIPE -F ‘%n/%l\n’ -4 AS-TECNOCRATICA 2.56.165.0/24 5.56.160.0/21 5.181.44.0/22 23.139.41.0/24 23.188.240.0/24 31.24.120.0/21 31.47.72.0/21 31.170.100.0/22 37.247.120.0/21 38.103.194.0/24 38.143.153.0/24 44.9.16.0/21 44.31.43.0/24 44.31.80.0/24 44.31.92.0/22 44.31.182.0/24 44.161.204.0/23 44.161.219.0/24 44.161.220.0/22 44.161.230.0/24 44.161.237.0/24 […] edu@andromeda:~$ bgpq4 -A -SRADB,RIPE -F ‘%n/%l\n’ -4 as15954 31.24.120.0/21 31.47.72.0/21 37.247.120.0/21 91.199.120.0/24 91.216.219.0/24 185.49.184.0/22 185.57.196.0/22 185.66.73.0/24 185.66.74.0/24 185.203.224.0/22 194.176.119.0/24 217.18.32.0/20 edu@andromeda:~$ bgpq4 -Al tecnocratica AS-TECNOCRATICA no ip prefix-list tecnocratica ip prefix-list tecnocratica permit 2.56.165.0/24 ip prefix-list tecnocratica permit 5.56.160.0/21 le 22 ip prefix-list tecnocratica permit 5.181.44.0/22 ip prefix-list tecnocratica permit 8.23.229.0/24 ip prefix-list tecnocratica permit 23.132.185.0/24 ip prefix-list tecnocratica permit 23.136.232.0/24 ip prefix-list tecnocratica permit 23.138.216.0/24 ip prefix-list tecnocratica permit 23.139.41.0/24 ip prefix-list tecnocratica permit 23.140.248.0/23 ge 24 le 24 ip prefix-list tecnocratica permit 23.141.88.0/24 ip prefix-list tecnocratica permit 23.188.240.0/24 ip prefix-list tecnocratica permit 31.24.120.0/21 ip prefix-list tecnocratica permit 31.47.72.0/21 ip prefix-list tecnocratica permit 31.170.100.0/22 ip prefix-list tecnocratica permit 37.247.120.0/21 ip prefix-list tecnocratica permit 38.103.194.0/24 ip prefix-list tecnocratica permit 38.134.111.0/24 ip prefix-list tecnocratica permit 38.143.153.0/24 ip prefix-list tecnocratica permit 41.216.177.0/24 ip prefix-list tecnocratica permit 41.216.178.0/24 ip prefix-list tecnocratica permit 41.216.186.0/24 ip prefix-list tecnocratica permit 44.9.16.0/21 ip prefix-list tecnocratica permit 44.31.43.0/24 ip prefix-list tecnocratica permit 44.31.80.0/24 ip prefix-list tecnocratica permit 44.31.92.0/22 ip prefix-list tecnocratica permit 44.31.182.0/24 ip prefix-list tecnocratica permit 44.159.68.0/24 ip prefix-list tecnocratica permit 44.161.204.0/23 ip prefix-list tecnocratica permit 44.161.219.0/24 ip prefix-list tecnocratica permit 44.161.220.0/22 ip prefix-list tecnocratica permit 44.161.230.0/24 ip prefix-list tecnocratica permit 44.161.237.0/24 ip prefix-list tecnocratica permit 44.161.238.0/23 ip prefix-list tecnocratica permit 44.161.240.0/21 ip prefix-list tecnocratica permit 44.161.248.0/22 ip prefix-list tecnocratica permit 45.13.185.0/24 ip prefix-list tecnocratica permit 45.61.161.0/24 ip prefix-list tecnocratica permit 45.61.162.0/24 ip prefix-list tecnocratica permit 45.81.152.0/22 ip prefix-list tecnocratica permit 45.89.255.0/24 ip prefix-list tecnocratica permit 45.90.16.0/22 ip prefix-list tecnocratica permit 45.90.145.0/24 ip prefix-list tecnocratica permit 45.95.113.0/24 ip prefix-list tecnocratica permit 45.130.16.0/22 ip prefix-list tecnocratica permit 45.131.132.0/22 ip prefix-list tecnocratica permit 45.137.160.0/22 […] Y en IPv6 pondríamos simplemente -6, esto lo podéis hacer en cualquier ordenador que tenga bgpq4 instalado.

Eres una empresa que has ido creciendo y necesitas contratar un rack en un centro de datos para poder ahí los servidores de tu empresa y dar servicio. ¿Qué posibilidades tienes para darle conectividad a ese rack? porque es obvio que vas a necesitar algún tipo de conectividad, si contratas un rack, unas Us o incluso una sala vas a querer conectarte a ella de alguna manera. Este tema quería tratarlo en un hilo de Twitter, pero claro, según iba pensando se me disparaban las posibilidades, así que este capítulo de hoy es un hilo de Twitter que bien ha merecido su propio audio en el podcast. De hecho el hilo en cuestión se me escapó a medio escribir y me lo tuve que cargar. Lo primero es decidir si la conectividad va a ser pública o no, porque no todos los racks están conectados al Internet público, algunos racks son simplemente cabinas de replicación, es decir, la replicación de una cabina que está en la oficina del cliente, para evitar desastres y cosas así. En este caso es posible que sólo queramos que la cabina sea accesible únicamente desde la oficina principal donde está la otra cabina, en este caso lo normal es contratar capacidad portadora, es decir, una conexión de 1 o 10G a un operador y que sea la únión del D con la oficina de la empresa. Si los requisitos son mayores siempre se puede poner una fibra oscura e iluminarla con SFPs de 40G o incluso meter CWDM o ¿por qué no? DWDM. Y si los requisitos son más sencillos a lo mejor con un túnel sobre internet puede servir, evidentemente depende muchísimo de los requisitos de cada cliente. También puede ser el caso que queramos tener la grabación de las cámaras de seguridad de una casa, aquí a lo mejor una VPN será suficiente. Depende en cada caso. Ahora, si queremos que los servicios se conecten a Internet tenemos dos opciones, tener direccionamiento propio con BGP o requerir direccionamiento del hoster. Sí, obviamente existe la posibilidad de tener direccionamiento propio pero no BGP, pero eso hablamos otro día porque no es lo normal. Si tienes direccionamiento público y AS lo ideal es levantar un par de sesiones BGP (al menos) con un par de routers y adelante. Si quieres direccionamiento del hoster pues tendrás que ponerte un gateway, que será un firewall, un router o similar y enrutar por ahí, obviamente el hoster también tiene que enrutar por ese equipo tu direccionamiento. Todo está está muy bien, pero seguro que no hay nada nuevo, la gracia de esto es ¿cómo pongo los cables? pues ahí es donde está la chicha de todo esto. Hay varias posibilidades, desde la más simple, en la cual le doy al cliente un único cable cable que une la plataforma del hoster con el firewall del cliente, el hoster configura una ruta al rango asignado al cliente hacia el firewall y el cliente una ruta por defecto a través de su firewall. Esta solución no es la mejor obviamente, para un servidor vale, pero para una infraestructura no es lo óptimo. A partir de aquí podemos complicar esto hasta el infinito dando más seguridad y más redundancia. Por ejemplo, si el cliente tiene un único firewall pero la posibilidad de tener dos uplinks podemos darle un LA conectado a dos switches Nexus con VPC, de forma que si cayese un switch o uno de los cables el cliente seguiría funcionando por el otro cable, sin convergencias ni nada de nada porque el LA seguiría funcionando, pero sólo por un puerto, cuando levantara de nuevo el enlace caído el LA se volvería a formar con dos puertos. Esta solución es muy limpia y a mi personalmente me gusta, ¿cómo se configura? En el lado del hoster hay que configurar un LA y una VLAN, y será esa VLAN la que pasemos por el LA y el gateway para el cliente estará configurado en un interfaz VLAN que puede estar en ese mismo VPC, la pareja de switches, o en otro lado donde llegue la VLAN en cuestión. En el lado del cliente simplemente hay que configurar un LA para el interfaz externo. Si el cliente quiere poner un switch será igual que si pone un servidor o un firewall, pero ¿qué pasa si quiere poner dos switches?, aquí hay que ir con cuidado y tenemos que ver si el cliente nos ofrece confianza suficiente porque sus equipos van a enviar BPDUs y van a ser capaces de bloquear puertos de Spanning Tree, así que ahí con cariño. Pero el problema importante surge en el momento en el que el hoster poner un par de Nexus en VPC y el cliente se pone otro par de Nexus, también en VPC y tiramos un par de cables, ahí la redundancia es total, pero claro, en este tipo de escenarios puedes encontrarte que ambas parejas de VPC se ponen como root de STP en las vlans que pasan por esos cables y las vlans entre las dos parejas de switches quedan bloqueadas por spanning tree, así que es interesante definir el root de spanning tree preferiblemente en el lado del hoster. De todos modos yo no soy nada partidario de que el cliente se conecte directamente con unos switches a nivel 2, siempre que se pueda que el cliente ponga un dispositivo de capa 3, un router o un firewall, eso es lo ideal para todas las partes. También se puede hacer el balanceo con ECMP en BGP, simplemente poniendo varios interfaces y creando una sesión BGP de loopback a loopback usando esos enlaces, y ahí nos quitamos todo el problema de los spanning tree y de los balanceos por LA.

En el mundo de las redes hay dos tipos de personas, los que les ha pasado esto que voy a contar y los que aún no les ha pasado, pero les pasará. Vamos a suponer una red con su OSPF, si eres de alta alcurnia, su ISIS, una red con su BGP con sus filtros y por qué no con su eVPN y por supuesto a eso añadir todo lo que se os ocurra. A alguien que haya podido montar todo eso se le presupone que sabe y mucho, realmente es totalmente cierto, uno no termina el CCNA y monta eso, hay que saber un poquito más. Toda esta introducción es para contaros que además de haber estudiado y leído mucho en redes además hay que tener experiencia de perro viejo, algo de lo que realmente no hay que preocuparse porque llega con el tiempo, además, llega de una forma maravillosa, no hace falta estudiar, sólo estar ahí, ojalá todo fuera así. Pues lo más sencillo, que es sentarte y aprender ciertas cosas de la vida, como el switchport trunk allowed vlan ADD, todas estas cosas llegan solas con el tiempo, pero tiene que pasar ese tiempo. De vez en cuando te encuentras con gente que pasan de no saber nada o muy poco de redes a saber muchísimo más que tú en muy poco tiempo, en mi caso me ha pasado ya con dos personas de forma clarísima. Un día en un bar si queréis desarrollamos esta punto. El tema es que hay gente que tienen una capacidad de aprender bestial y son capaces de aprender 10 veces más rápido que una persona normal, pero por suerte las putadas de la vida nos llegan a todos a la misma velocidad y a esas personas no les llegan 10 veces más rápidas, así que la segunda parte del aprendizaje, la que viene con el tiempo pues no van 10 veces más rápido, mucha experiencia la cogen de libros, pero quedan cosas por ahí colgando. Esto es lo cuento porque a veces te encuentras con un de redes de 25 años, a lo sumo, y que saben un montón, en el grupo de telegram del podcast hay unos cuantos con los que he coincidido con esas edades y eran auténticas bestias pardas, y otros que son bestias pardas pero que ya me pillan un poco de lejos porque no he compartido con ellos trabajo. Yendo al grano, cualquiera de esas bestias pardas te va a levantar un ISP, te va a configurar el OSPF, te va a levantar el BGP, todo, pero a veces los más viejos del lugar tenemos alguna ventaja y es que ya hemos pasado por algo que ellos no, pero eso sólo sirve una vez. Hay un tema que asusta mucho y eso que todos lo tenemos claro, pero claro, tocarlo en un router en producción es una historia. ¿Vosotros tocaríais o incluso borraríais la ruta por defecto en un router BGP por el que pasa todo vuestro tráfico? Ya os digo yo que no, vosotros tenéis un router con una configuración de 15 o 20 páginas y de repente veis que hay tráfico que empieza a saltar de un router a otro como si eso fuera una pelota de ping pong. ¿Qué es lo primero que haríais? es probable que miraseis en la tabla de BGP ese prefijo y si os dice algo del estilo Network not in table diréis, claro, no está en BGP y entonces revisando la configuración os encontraréis algo del estilo: ip route 0.0.0.0 0.0.0.0 null0 250 Ahí es donde empieza el mal rollo porque veis que la ruta por defecto no está funcionando porque el tráfico no se está hundiendo sino que sigue botando. ¿Por qué se va a hundir? Se va a hundir porque no hay prefijo BGP que incluya ese rango de forma específica, sí, hay rangos que no se anuncian por lo que sea, y al no haber una ruta más específica pues debería de ir por ese null0, pero no va. Interesante, sigues mirando y ves que claro, hay un 0.0.0.0/0 que está en OSPF y tú sabes que OSPF tiene distancia istrativa 110 mientras que esa ruta estática a null0 tiene una distancia istrativa de 250 y aquí vamos a mirar la distancia istrativa porque ambas rutas son exactamente igual de específicas. Y te das cuenta que podrías quitar ese ip route 0.0.0.0 0.0.0.0 null0 250 ¿Qué haces? ¿Lo quitas? ¿Realmente vas a quitar la ruta por defecto del router?, la única que está escrita en la configuración, pues aquí es normal que entren dudas. Recordemos que todo el tráfico está pasando por ese router y eso es una ruta por defecto. Además esa ruta por defecto bastante tenemos con entender que realmente lo único que hace es hacer que ese prefijo esté en el IGP, recordad el tema de la sincronización y de BGP. Pues además de entender que esa ruta es sólo para que el prefijo esté en el IGP tenemos que saber también que realmente no pasa nada porque la estamos aprendiendo también por OSPF, así que si la borramos no pasa nada. Ahora, volviendo al OSPF, el tráfico llega al router y el router tiene una ruta por defecto en OSPF (DA 110) y se lo manda a un switch, ese switch tiene otra ruta por defecto por otro router y así …. aquí está el ping pong. Y para quitar el ping pong lo que podemos hacer es borrar la ruta estática con DA de 250 y meter una ruta por defecto normal y moliente: no ip route 0.0.0.0 0.0.0.0 null0 250 ip route 0.0.0.0 0.0.0.0 null0 Ahora cuando el tráfico llegue al router ya no se lo va a pasar el nexthop de OSPF pues tiene una ruta estática con DA de 1 y OSPF es DA de 110, así que preferirá DA 1. Esto que os he contado es algo muy obvio, pero esto en medio de una incidencia es horrible y esto es algo que superarás fácilmente si ya te ha pasado o si alguien te lo ha contado, pero si te enfrentas la primera vez es es muy muy complicado de salir. En el caso que nos ocupa la persona en cuestión consiguió salir sin modificar la ruta estática utilizando filtros de BGP, una genialidad que mi no se me habría ocurrido, realmente esta persona pudo suplir perfectamente el no ser zorro viejo con unos conocimentos de BGP que hacen que te vuele la cabeza. El tema es que los mortales tenemos que sabernos estas cosas porque ya os digo yo que a parir esos filtros esos no llegamos el 99% ni de broma.

El pasado 14 de Marzo de 2018, hace ya más de 4 años se delegó la zona home.arpa a los servidores del AS112, un sistema autónomo que cualquiera puede anunciar y que Tecnocrática empezó a anunciar hace ya dos o tres años, objetivo, que los datos que se envían ahí no salgan de España porque ya bastante tenemos como para que encima información de nuestras casas pueda andar alegremente circulando por Internet. Muchos de nosotros tenemos en casa cositas que se conectan a Internet, asistentes personales, lavadoras, neveras, hornos, aspiradoras, relojes, interruptores, teléfonos, bombillas, incluso dispensadores de comida para animales. La verdad es que no somos conscientes hasta que miramos en el servidor de DH de nuestra red la cantidad de cesiones de IPs que hay. De todos los dispositivos que tenemos conectados muchos de ellos funcionan de forma autónoma, nosotros no controlamos la conexión a Internet de una bombilla o del famoso dispensador de alimentos para animales por poner sólo un par de ejemplos. Estos cacharritos para conectarse a Internet utilizan, como todos, un servidor de DNS al que le hacen preguntas y a veces hacen preguntas sobre elementos de la LAN o se identifican ellos mismos como por ejemplo asistente_salon.home.arpa y claro, nuestro DNS no lo conoce, así que preguntará recursivamente para arriba hasta que llegue a los servidores de DNS de la zona home.arpa y claro, en esos servidores de DNS ahora se sabe que alguien con la IP (x.y.z.k) tiene algo llamado asistente_salon, y si te esperas un poco verás que también tiene un movil_ernesto y si sigues mirando pues sacar muchísimas cosas. Quizás no parezca demasiado crítico, pero si podemos inferir que Fulanito de tal tiene 3 bombillas, 2 asistentes y 1 aspiradora seguro que podemos sacar más datos. Obviamente esto es un problema para la privacidad, aunque no fue la privacidad el detonante de controlar esto, que va, el detonante fue la carga de los DNS, bajar la carga de los DNS tal y como dice en la RFC7534: in order to reduce the load on the IN-ADDR.ARPA authoritative servers Para bajar la carga de los servidores DNS se delegó la zona home.arpa a los servidores del AS112. Los rangos a lo que esto afecta es a los asociados con las peticiones de PTR de RFC1918: 10.0.0.0/8 172.16.0.0/12 169.254.0.0/16 192.168.0.0/16 En cuanto a los servidores utilizados para esas resoluciones tenemos los siguientes: 1.- Direcciones de Anycast para los servidores de DNS: 192.175.48.1 / 2620:4f:8000::1 192.175.48.6 / 2620:4f:8000::6 192.175.48.42 / 2620:4f:8000::42 2.- Direcciones de Anycast para DNAME. El registro DNAME proporciona la redirección de una parte del árbol de nombres DNS a otra parte del árbol de nombres DNS. 192.31.196.0/24 / 2001:4:112::/48 Así que será necesario anunciar los siguientes prefijos en BGP: 192.31.196.0/24 192.175.48.0/24 2001:4:112::/48 2620:4f:8000::/48 Estos rangos y ese AS se permite que lo anuncie cualquiera por anycast. ¿Por qué Tecnocrática tiene los DNS del AS112 y anuncia los rangos del AS112? Como os he comentado anteriormente en esas peticiones de DNS hay información que puede ser utilizada por empresas que puedan gestionar dicha información y que le puedan sacar partido. ¿Es nuestro caso? Pues me encantaría decir que sí, pero no es verdad, simplemente lo hacemos porque consideramos que esto deberían de hacerlo todos los operadores de red para que no llegue a esas empresas que luego pueden hacer con esto algo provechoso para ellos en contra de la privacidad de la gente. Nosotros anunciamos el AS112 principalmente en puntos neutros de intercambio con otros operadores españoles para que esa información sea resuelta desde España y no salga fuera de España, es una especie de poner nuestro granito de arena para que la información de la gente que vive en España no salga fuera. ¿Qué hacemos nosotros con esa información?, la verdad es que nada, se contesta a la petición DNS recibida y ya está, ni guardamos peticiones ni hacemos ningún tipo de estudio de esos datos, bastante tenemos con lo nuestro, simplemente es algo que debería de hacer todo el Mundo, el proteger a sus s y como no lo hacen, pues nosotros intentamos suplir esa carencia. Estoy seguro que a nadie le apetece que ninguna empresa de Marketing se dedique a hacer estudios de cuantos cacharritos tiene cada uno para luego vender un perfil a ningún vendedor. Porque esta información a lo mejor no os parece importante, pero no es el mismo perfil quien tiene 4 asistentes, 10 bombillas y 1 aspiradora que el que sólo tiene una bombilla. Ojalá llegue el día en que todos los operadores de España lo anuncien y ya no tengamos que hacerlo nosotros.

El otro día en el grupo de Telegram del podcast (https://t.me/grupopodcast) surgió una conversación interesantísima, en la cual se hablaba sobre los tránsitos con ruta por defecto y de los tránsitos con full routing. Pues se comentaros distintas visiones sobre el tema y aquí me gustaría contaros un poco cual es mi visión sobre el tema por si a alguien le puede servir. El tránsito es un tema del que ya os estuve hablando el 14 de diciembre de 2017, en un audio llamado "Tránsitos y peering", pero hoy vamos a profundizar un poco más, además, os quiero hablar de la importancia de los filtros en los tránsitos, porque a veces a nuestro amigo BGP hay que ayudarle un poco a elegir el camino correcto ya sea mediante communities, mediante prefijos, mediante AS-PATH o lo que queráis. Recordad que BGP nos ayuda a tomar la decisión correcta en cuanto a qué camino elegir en cada caso, obviamente esto sólo tiene sentido si tenemos al menos dos caminos, porque sino sólo habrá una posibilidad, pero aún así algo podremos hacer si tenemos un full routing. Si sólo tenemos un camino como mucho podremos pasar a nuestro tránsito que no anuncie un prefijo a un AS, en un IXP o que le meta un prepend cuando nuestro tránsito se lo anuncie a alguien, no está mal, pero es limitado. Si tenemos dos tránsitos, con ruta por defecto los dos, lo único que podemos hacer es tener uno de backup del otro o tener un router externo que le mande la mitad de tráfico a uno o al otro, pero todo esto es bastante deficiente. Aún teniendo los dos como ruta por defecto podremos anunciar communities para que los filtros de nuestros tránsitos hagan algo con ello, lo que hemos comentado antes. Ahora, si tenemos al menos dos tránsitos con full routing ya podemos hacer hacer cosas interesantes como por ejemplo decir que para ir a un AS concreto vaya por un tránsito como elección principal diga lo que diga BGP porque os voy a contar un secreto "BGP es falible" y a veces la decisión que toma BGP no es la misma que la decisión que nosotros como es de ese AS tomamos. Lo primero es recordar cual es la selección de rutas en BGP, os hago un resumen: Preferimos el path con mayor WEIGHT. Preferimos el path con mayor LOCAL PREFERENCE. Preferimos el path generados con network o redistribute sobre los agregados. Preferimos el path con el AS PATH más corto. Preferimos el path con ORIGIN TYPE menor, siendo el orden: IGP < EGP < Incompleto. Preferimos el path con menor MED. Preferimos eBGP sobre iBGP. Preferimos el path con menor métrica en el IGP hasta el peer BGP (el más cerecano) .... La selección completa la tenéis enel documento titulado BGP Best Path Selection Algorithm (https://www.cisco.com/c/en/us//docs/ip/border-gateway-protocol-bgp/13753-25.html) BGP por ejemplo puede decir que para ir al destino 192.0.2.1 el mejor tránsito es el primero de ellos y para ir a otro destino el segundo de ellos. En este caso la decisión de encaminamiento ha sido tomada por el algoritmo de selección de path de BGP, vamos a suponer que la decisión se ha tomado en la selección del AS PATH más corto, pero vemos que por el AS PATH más corto tenemos un retardo de 153ms, mientras que por el otro tránsito el retardo es de 48ms, en este caso tendremos que decirle a nuestros routers que el camino bueno es por el segundo tránsito, aunque el algoritmo de selección de path de BGP diga lo contrario. ¿Cómo podemos modificar la decisión de routing en BGP o en cualquier otro protocolo? mediante filtros. Los filtros van a estar compuestos por route-maps y estos van a tener sus condiciones y sus modificadores. Por ejemplo, en el segundo tránsito podemos crear un filtro de la siguiente manera: Router bgp 65510 neighbour 198.51.100.2 remote-as 65512 neighbour 198.51.100.2 route-map ruta_por_aqui in route-map ruta_por_aqui permit 10 match ip address prefix-list rutas_preferidas set local-preference 150 ip prefix-list rutas_preferidas 192.0.2.0/24 En este ejemplo lo que hacemos es decir al router en el tránsito al 198.51.100.2 que lo que aprenda por ahí mire si está la 192.0.2.0/24 y que le aplique una Local Preference de 150, y como por defecto es 100 se preferirá este tránsito para ese prefijo. Ahora queremos que el tráfico contra el AS12345 vaya siempre por este tránsito, en vez de utilizar un prefix-list usaremos un as-path: Router bgp 65510 neighbour 198.51.100.2 remote-as 65512 neighbour 198.51.100.2 route-map ruta_por_aqui in route-map ruta_por_aqui permit 10 match as-path 10 set local-preference 150 ip as-path access-list 10 permit ^65000$ En este ejemplo lo que hacemos es decir que el tráfico del AS65000 tendrá una local preference de 150 por este tránsito. Esta es la forma de hacerlo en Cisco, evidentemente en otros routers habrá que adaptar el filtro a cada router, pero la idea subyacente es la misma. Y obviamente esto no funcionaría si recibimos sólo una ruta por defecto.

¿Qué es ITIL? Las siglas ITIL significan Information Technology Infrastructure Library, que traduciríamos literalmente como Biblioteca de Infraestructura de Tecnologías de Información. ITIL es una guía de buenas prácticas para la gestión de servicios de tecnologías de la información. No es un estándar… pero muchas empresas intentan implantar ITIL internamente para mejorar la calidad del servicio ofrecido. No es como hemos dicho un estándar… pero muchas empresas demandan que sus proveedores tengan implantadas las buenas prácticas de ITIL para hablar el mismo lenguaje que el proveedor y poder valorar la calidad del servicio recibido. Axelos es la empresa que lo desarrolla y potencia a nivel mundial. Existen en Internet montones de recursos para aprender, formarse y preparar la Certificación que hoy en día está en su versión 4, ITIL 4. Este canal de Internet es muy agradable para saber qué es ITIL Es un aporte muy interesante y se empieza a familiarizarse uno con un lenguaje al cual generalmente no estamos acostumbrados. AFIRMACIÓN CLARA Y CONTUNDENTE: Los primeros días de estudio y aproximación hay que acostumbrarse a un nuevo lenguaje, conceptos a los que no estamos acostumbrados algunas veces abstrusos y aparentemente subjetivos. Fijaros como se define Servicio (pregunta de examen): «Un medio para permitir la creación conjunta o la cocreación de valor al facilitar los resultados que los clientes desean lograr, sin que los clientes tengan que istrar costos y riesgos específicos» Y fijaros como de define Práctica: “En ITIL, una práctica de gestión es un conjunto de recursos organizativos diseñados para realizar un trabajo o lograr un objetivo” Y otra más… como se define Producto: “Es una configuración de recursos creados por una organización que serán potencialmente útiles/valiosos para los clientes” Lo primero que hay que hacer para Certificarse es acostumbrarse a este lenguaje a través de lecturas y vídeos… una vez que se asimila esta forma de hablar ya se puede avanzar. Disparadores más habituales de la Certificación ITIL 4: La empresa te dice que tienes que certificar pues es parte de la oferta que se le hace al cliente, “nuestra gente está certificada” o el cliente exige para renovar que la gente esté certificada. La gente en búsqueda activa de empleo descubre que tener ITIL es un plus. Entonces se certifican. Pura vocación de dedicarse a la gestión en TI. La empresa suele contratar un curso de 2 días 1º horas en total, os compra el voucher y en pocos días te examinas. ¡¡¡Para mi Error!!! Eso implica que uno se aturulle y estrés… y además la posibilidad de fracaso con el consiguiente disgusto y descrédito personal. Mi propuesta… en un mes dedicarle todos los días un ratito. No más de un mes. Un tercio del tiempo viendo vídeos sobre el tema. Otro tercio leyendo la documentación oficial la cual es larga y a veces infumable y muy memorística. El tercer tercio del tiempo haciendo tests de prueba, desde prácticamente el primer día. Recursos en Internet a nivel de vídeos hay muchos y LinuxDoesMatter recomienda estos: Antonio Cedillo Hernández. El solo visionado de su lista ya te aclara qué es ITIL y por ejemplo media docena de preguntas del examen. https://www.youtube.com/channel/UCdAAwTONhpYNNxJgeu2jtPg JUANMAS, entrañable colombiano que explica todo el ITIL muy pausadamente y con un simulador de examen de unas 20 preguntas de las cuales me salieron entre 8 y 10 el día del examen. https://www.youtube.com/c/ValueInsightsAgileandITILTrainingPartner Alex de Value Insights un material valiosísimo cubre en sus videos también toda la certificación y tiene vídeos con simulación de exámenes con preguntas que también me cayeron en el examen. Yo lo que hice también en mi móvil / Tablet me instale apps de ITIL4 que regalan un examen y si pagas te desbloquean mas exámenes… me descargué media docena, nunca pagué y fueron valiosísimos. App de Ucertify, ExamMobile, Zindiak, etc. Llegue a tener 6 apps simuladoras de examen ITIL 4 en el móvil, ninguna mala. ¿Cómo empezar? ITIL 4 no es una Certificación ni difícil ni larga. Distribuye tu tiempo viendo videos, leyendo la documentación oficial y haciendo test desde el primer día. Abórdalo así, por tópicos: Componentes clave y definiciones (5 preguntas) El Sistema del Valor del Servicio (1 preguntas) Las Cuatro Dimensiones (2 preguntas) Los Principios Guía o Rectores (6 preguntas) La Cadena del Valor del Servicio (2 preguntas) La Prácticas más importantes (19 preguntas) Otras Prácticas (5 preguntas) Total 40 preguntas se pasa el examen con 26 aciertos. Coges cada tema y lo lees, ves vídeos y desde el primer vía contestas preguntas relativo a cada tópico. Todos los días lectura, visionado de vídeos y realización de test de forma masiva. Hay muchos simuladores en Internet para hacer test y te enseñan y corrigen el error, también se aprende equivocándose y viendo la explicación del porqué del error. Pensad que no hay que desarrollar nada sino reconocer la respuesta correcta de entre 4. Al leer no hace falta empollar, al ver vídeos fijas ideas de lo que has leído y al hacer test sobre lo que ya has trabajado “tatúas en tu mente conceptos” y luego respondes con corrección. Imaginaros que yo os tengo que preparar para el examen. Cojo el tópico de “Conceptos clave y definiciones” antes mencionado, le vemos en el manual, las leemos en alto, vemos un vídeo que los explique otra vez y os propongo 20 ó 30 preguntas de test sobre este tópico en concreto. Ese ha sido mi modelo, os lo comparto por si os resultase útil. En el examen acerté prácticamente todas, no por ser muy listo ni por tener mucha memoria sino porque el modelo expuesto funcionó para mí. Tiempo distribuido en lectura, vídeos de buena calidad y muchos, muchos tests. La empresa paga el examen o vosotros y obtenéis un vaucher. Lo canjeáis en: www.peoplecert.com única entidad examinadora y seguís lo pasos. Unos 300 euros. El software para examinarse se llama Examshield y sólo fui capaz de instalarlo a través de la AppStore de Microsoft Windows 10, el ejecutable para instalármelo un puro “exe” que proporciona Peoplecert, no funcionó. El examen es proctorizado se hace en casa y tenéis que estar en una habitación solos con cámara y la puerta debe estar cerrada y se debe ver por parte el vigilante (to tuve que hacer el examen ladeado para que se viese la puerta, sino no vale). Ensayar con la cámara todo el recorrido que os va a obligar a hacer el proctor, giro copernicano de 360º a la habitación, arriba y debajo de la habitación, mesa limpia 100%, bueno un vaso de agua vale, botella con etiqueta no y reloj tampoco. Yo no ensayé y el cable no daba y al hacer los malabarismos dí la botón de ahorro de energía… ja ja ja me tuve que volver a conectar y esto retrasó el examen casi 15 minutos… y Nervios chicos Nervios que tontos somos a veces los seres humanos… ja ja ja. Para previsores: Te venden “mock exams” para que compruebes tu nivel, unos 90 Euros. Para cobardes: Por otros 90 euros que tienes que pagar como máximo una hora antes del examen te dan una segunda oportunidad si suspendes que se llama Take2. Preguntas que podemos hacernos: ¿Para qué sirve ITIL, Que es eso de ITIL? ¿Te pagarías tu un curso de ITIL por gusto? de tu dinero me refiero ¿Cuánto puede costar certificarse? ¿Crees que se tiene más salida laboral si se está certificado? ¿Es itil una religión?, es decir, ¿Crees que se ha de adaptar a cada entorno o se ha de seguir al pie de la letra? ¿Tiene como versiones ITIL? ¿Cuál es la última versión? ¿Crees que alguien certificado en ITIL trabaja mejor en equipo? Reflexión personal. Yo ya sabía que trabajaba en un entorno donde ITIL está aplicado. La prioridad de los incidentes. La gestión de cambios. Mi relación con el cliente. Lo que me exijo a mí mismo (documentar, SLAs) y lo que me exigen (crear un procedimiento). El buen compañero y trabajador que documenta el malo que no documenta. El fomento de la colaboración y eliminación de silos (Dptos. con información que no circula) La forma en la que abordo un problema, al margen de los puros comandos. Por ejemplo incidente en un CI y ver que incidentes han estado asociados a ese CI a través de la herramienta de ticketing. ¿El incidente es recurrente? Entonces tenemos un Problema Mi relación con el dispatcher su rol y mi rol La armonía de los principios guía de ITIL 4 http://www.icorp.com.mx/blog/7-principios-guia-de-itil-para-llevar-a-tu-empresa-al-siguiente-nivel/ Enfócate en el valor. Empieza donde estás. Progresa iterativamente y con retroalimentación. Colabora y promueve la visibilidad. Piensa y trabaja holísticamente. Mantenlo simple y práctico. Optimiza y automatiza. Son como los mandamientos, cada acción que hagamos en el trabajo la debemos confrontar con los principios guía. Principios universales y perdurables ITIL 4 me da un visión más amplia y quizá comprendí por qué un compañero a pesar de ser buen técnico fracasó cuando fue “ascendido” para realizar tareas de mejora continua ITIL 4 propone esta “rueda o circulo de acciones” Mejora continua Mejora continua Este compañero era un auténtico “silo” de información. Violaba el mandamiento de “Colaborar y promover la visibilidad” y una de las preguntas del examen y una realidad de cara a la mejora continua es… ¿Quiénes están implicados en la mejora continua? Respuesta. TODOS. Esta implicación de todos, este buen técnico y taciturno compañero nunca lo comprendió. ITIL me ayudó a comprender el porqué de su fracaso. Y también ayuda a cada uno a desempeñar mejor el trabajo del día a día, confrontando nuestras acciones contra los “mandamientos” o Principios Guía de ITIL 4. Agradecimientos con el permiso del conductor del programa Eduardo Collado Lo prometido a Alex de Value Insights “Dear Alex as I promised you and despite this is a Podcast in Spanish language, with the allowance of the host and conductor Mr Eduardo Collado in his program I want to give you a sincere thanks for all those videos hosted on YouTube whose quality and value is incalculable for learning ITIL 4 and the exam Certification” Lo prometido a Juan Manuel Sarmiento Sáenz (JUANMAS) “Querido y entrañable Juan Manuel Sarmiento muchas gracias por todo ese material depositado en YouTube para ayudar a aprender ITIL 4 y pasar la certificación. Todo los videos muy interesantes e informativos y como anécdota te diré que de tu examen de prueba para ayudar a aprobar me cayeron yo creo que unas 10 preguntas. Eternamente agradecido tienes un amigo en España no te preocupes por tu acento cuando vengas que mi mujer es Colombiana” LinuxDoesMatter además de hablar aquí sobre ITIL también lo hizo en el canal de twitch de Fanta, sobre el minuto 40 https://www.twitch.tv/videos/1587015281?t=00h40m20s Etiquetada como itil 4, linuxdoesmatter

Hoy tenemos a DMNTR (https://twitter.com/weareDMNTRs) con quien he podido compartir un café en nuestro bar virtual favorito y nos ha estado hablando de BGP, de AS, de su experiencia en redes, de su futuro, en fin, una charla bastante amena, espero que os guste. DMNTR es un técnico de Granada que en poco más de lo que dura un verano se ha montado un AS, se ha hecho miembro de RIPE, tiene funcionando 464xlat y seguro que dentro de muy poco será uno de los referentes de IPv6, al menos, a nivel español.

Hola a todos, hoy iba a titular el capítulo siguiendo las instrucciones de un buen amigo que sabe mucho de posicionamiento como «la gestión definitiva de tus dispositivos con VRF», o algo del estilo «No te podrás creer lo que puedes hacer con RouterOS7» o alguna cosa así, pero al final no he tenido estómago para hacerlo y el capítulo se va a llamar «Gestionar tus dispositivos con VRF» y vamos a aprovechar para comentar la funcionalidad nueva de VRF en Mikrotik. Hoy vamos a hablar de VRF (Virtual Routing and Forwarding) que en RouterOS7 ya viene por defecto gracias a que ya viene incluido en el kernel de Linux. Lo primero es tener claro qué es eso de VRF, ya os he dicho que VRF significa Virtual Routing and Forwarding, pero aún no os he contado qué hace. No se si además de seguir el podcast os leéis los artículos que de vez en cuando voy colgando en la web. En 2016 colgué un artículo hablando de PBR en linux, en el artículo lo que os comentaba era cómo hacer que se tomara una decisión de routing en función del origen, es decir, podíamos seleccionar el next hop dependiendo del origen en vez del destino. Para explicar esto encabecé el artículo con la frase de Anton Chejov, que escribió unos fantásticos cuentos por si no los habéis leído, «Si quieres ser universal, habla de tu pueblo, de tu aldea», es decir, nunca olvides de donde vienes. Pues bien, si vamos un poco más allá en ese concepto podemos por ejemplo seleccionar un nexthop en función del interfaz por el que ha entrado ese tráfico y ya si vamos otro poquito más allá podemos hacer que en función del interfaz de entrada tengamos una tabla de rutas independiente. Al tener tablas de rutas diferentes en función del interfaz podemos tener por ejemplo rutas por defecto diferentes en función del interfaz y por supuesto esas tablas de rutas, por defecto, no se verán entre si. De esta manera podemos decir que el gateway de la tabla principal es la 192.168.1.1 y de la tabla de gestión la 10.1.1.1 y podemos tener destinos a los que se llegue por una tabla pero no por otra. Esto puede ser muy útil porque el router no va a tener forma de unir las dos tablas. Esto nos permite tener tablas de rutas separadas, una para la gestión y otra para el tráfico general. Esto es algo que ser podía hacer de forma más o menos sencilla en otros dispositivos desde hace ya bastante tiempo. Bueno, después del rollo, vamos a buscarle una utilidad práctica a todo esto. Si sois s de otros equipos de red como Cisco o Juniper esto os va a sonar bastante viejuno, pero en Mikrotik es algo relativamente nuevo gracias al kernel de Linux. En la versión de RouterOS7 ya tenéis soporte de VRFs, así que [edu@Casa Edu] > /ip/vrf/add name=gestion interfaces=ether1 [edu@Casa Edu] > /ip/route/add gateway=10.1.1.1 vrf-interface=ether1 [edu@Casa Edu] /ip/service> print Flags: X, I - INVALID Columns: NAME, PORT, CERTIFICATE, VRF # NAME PORT CERTIFICATE VRF 0 telnet 23 main 1 ftp 21 2 www 80 main 3 ssh 22 main 4 X www-ssl 443 none main 5 api 8728 main 6 winbox 8291 main 7 X api-ssl 8729 none main [edu@Casa Edu] /ip/service> set numbers=2 vrf=gestion Con esto que os paso tan sencillo la gestión de vuestro mikrotik ya no será accesible desde los clientes. Hasta ahora la protección de los Mikrotik ha sido un tema bastante arduo porque dependía en buena medida de la configuración del firewall y de cómo se redistribuían las rutas, por ejemplo, redistribuir las redes de gestión en la tabla de rutas general es algo que deberíamos de evitar siempre que podamos. Ahora, todo esto tiene una pega, yo no me había dado cuenta, pero mi compañero Adrián sí, y es que el SNMP no puede ser expuesto en una VRF, supongo que para futuras versiones eso se solucionará. A partir de la versión de hoy, la 7.3 ya se puede exponer el SNMP a la VRF.

Tomarte un café siempre es un placer, pero con amigos y una buena conversación es muchísimo mejor. En el audio de Hoy tenemos a Jordi Palet que viene a hablarnos de Ipv6 a Adrian y a mi y ya que estamos a los demás que queráis escuchar. Estuvimos hablando durante mucho tiempo aunque sólo grabamos una hora sobre IPv6, transferencias de derechos de uso de IPs, la situación en España, en Europa y en Latinoamérica y de muchas curiosidades. Los documentos de los que hablamos en el audio son estos: RIPE 690 - https://www.ripe.net/publications/docs/ripe-690 RFC 8273 - https://www.rfc-editor.org/rfc/rfc8273.html RFC 8585 - https://www.rfc-editor.org/rfc/rfc8585.html RFC 8683 - https://www.rfc-editor.org/rfc/rfc8683.html

Hoy ha salido la noticia de que Cogent había dejado de dar servicio a empresas en Rusia, cosa que no es cierto, entre otras cosas, y que en este audio os cuento cómo está funcionando ahora el internet en Rusia. He cogido como ejemplo mail.ru y esa funcionando gracias a la conexión que le presta Level3, Megafon.ru (segundo operador de telefonía móvil de Rusia) y Hurricane Electric. A Megafon.ru le da servicio entre otros Cogent. Os pego los comandos de los que hablo en el audio: edu@andromeda:~$ dig mail.ru ; <<>> DiG 9.16.1-Ubuntu <<>> mail.ru ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3808 ;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 65494 ;; QUESTION SECTION: ;mail.ru. IN A ;; ANSWER SECTION: mail.ru. 47 IN A 217.69.139.202 mail.ru. 47 IN A 94.100.180.200 mail.ru. 47 IN A 94.100.180.201 mail.ru. 47 IN A 217.69.139.200 ;; Query time: 0 msec ;; SERVER: 127.0.0.53#53(127.0.0.53) ;; WHEN: lun mar 07 21:03:47 CET 2022 ;; MSG SIZE rcvd: 100 edu@andromeda:~$ dig aaaa mail.ru ; <<>> DiG 9.16.1-Ubuntu <<>> aaaa mail.ru ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33212 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 65494 ;; QUESTION SECTION: ;mail.ru. IN AAAA ;; ANSWER SECTION: mail.ru. 10 IN AAAA 2a00:1148:db00:0:b0b0::1 ;; Query time: 0 msec ;; SERVER: 127.0.0.53#53(127.0.0.53) ;; WHEN: lun mar 07 21:03:54 CET 2022 ;; MSG SIZE rcvd: 64 Ahora vemos esas IPs de donde son: edu@andromeda:~$ whois 94.100.180.200 % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to and Conditions. % See http://www.ripe.net/db//db--conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '94.100.176.0 - 94.100.183.255' % Abuse for '94.100.176.0 - 94.100.183.255' is '[email protected]' inetnum: 94.100.176.0 - 94.100.183.255 netname: VK-FRONT descr: VK Services country: RU -c: VG659-RIPE -c: EY1327-RIPE tech-c: MAIL-RU status: ASSIGNED PA mnt-by: MNT-NETBRIDGE created: 2008-08-01T07:40:20Z last-modified: 2021-12-27T10:28:02Z source: RIPE role: VK NOC address: Limited liability company Mail.Ru address: Leningradskiy prospect, 39/79 address: 125167 Moscow Russia phone: +7 495 7256357 fax-no: +7 495 7256359 remarks: ------------------------------------------ -c: VG659-RIPE -c: EY1327-RIPE tech-c: DBF3-RIPE tech-c: IS13 remarks: ----------------------------------------- remarks: General questions: [email protected] remarks: Spam & Abuse: [email protected] remarks: Search Abuse: [email protected] remarks: Routing inquiries: [email protected] remarks: Peering issues: [email protected] remarks: ----------------------------------------- remarks: --------- A T T E N T I O N !!! --------- remarks: Please use [email protected] e-mail remarks: address for spam and abuse complaints. remarks: Mails for other addresses will be ignored! remarks: ----------------------------------------- mnt-by: MNT-NETBRIDGE abuse-mailbox: [email protected] nic-hdl: MAIL-RU created: 2010-11-29T12:03:47Z last-modified: 2021-12-24T09:11:25Z source: RIPE # Filtered person: Elena Yakupova address: 39/79, Leningradsky prospect address: Moscow, Russia,125167 phone: +7 495 725 6357 nic-hdl: EY1327-RIPE mnt-by: MNT-NETBRIDGE created: 2018-11-14T11:06:34Z last-modified: 2018-11-14T11:06:34Z source: RIPE # Filtered person: Vladimir Gabrelyan address: 47, Leningradsky prospect, Moscow, Russia fax-no: +7 495 7256357 phone: +7 495 7256357 nic-hdl: VG659-RIPE mnt-by: MNT-NETBRIDGE remarks: modified for Russian phone area changes created: 2004-06-08T13:21:36Z last-modified: 2010-11-29T13:30:08Z source: RIPE # Filtered % Information related to '94.100.176.0/20AS47764' route: 94.100.176.0/20 descr: Moscow region origin: AS47764 mnt-by: MNT-NETBRIDGE created: 2008-08-15T09:00:39Z last-modified: 2022-02-15T10:59:54Z source: RIPE % This query was served by the RIPE Database Query Service version 1.102.2 (WAGYU) Y la IP del otro rango: edu@andromeda:~$ whois 217.69.139.200 % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to and Conditions. % See http://www.ripe.net/db//db--conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '217.69.136.0 - 217.69.143.255' % Abuse for '217.69.136.0 - 217.69.143.255' is '[email protected]' inetnum: 217.69.136.0 - 217.69.143.255 netname: VK-FRONT descr: VK Services country: RU -c: VG659-RIPE -c: EY1327-RIPE tech-c: MAIL-RU status: ASSIGNED PA mnt-by: MNT-NETBRIDGE created: 2018-11-21T08:40:03Z last-modified: 2021-12-27T10:28:02Z source: RIPE role: VK NOC address: Limited liability company Mail.Ru address: Leningradskiy prospect, 39/79 address: 125167 Moscow Russia phone: +7 495 7256357 fax-no: +7 495 7256359 remarks: ------------------------------------------ -c: VG659-RIPE -c: EY1327-RIPE tech-c: DBF3-RIPE tech-c: IS13 remarks: ----------------------------------------- remarks: General questions: [email protected] remarks: Spam & Abuse: [email protected] remarks: Search Abuse: [email protected] remarks: Routing inquiries: [email protected] remarks: Peering issues: [email protected] remarks: ----------------------------------------- remarks: --------- A T T E N T I O N !!! --------- remarks: Please use [email protected] e-mail remarks: address for spam and abuse complaints. remarks: Mails for other addresses will be ignored! remarks: ----------------------------------------- mnt-by: MNT-NETBRIDGE abuse-mailbox: [email protected] nic-hdl: MAIL-RU created: 2010-11-29T12:03:47Z last-modified: 2021-12-24T09:11:25Z source: RIPE # Filtered person: Elena Yakupova address: 39/79, Leningradsky prospect address: Moscow, Russia,125167 phone: +7 495 725 6357 nic-hdl: EY1327-RIPE mnt-by: MNT-NETBRIDGE created: 2018-11-14T11:06:34Z last-modified: 2018-11-14T11:06:34Z source: RIPE # Filtered person: Vladimir Gabrelyan address: 47, Leningradsky prospect, Moscow, Russia fax-no: +7 495 7256357 phone: +7 495 7256357 nic-hdl: VG659-RIPE mnt-by: MNT-NETBRIDGE remarks: modified for Russian phone area changes created: 2004-06-08T13:21:36Z last-modified: 2010-11-29T13:30:08Z source: RIPE # Filtered % Information related to '217.69.128.0/20AS47764' route: 217.69.128.0/20 descr: Moscow region origin: AS47764 mnt-by: MNT-NETBRIDGE created: 2009-03-20T11:55:16Z last-modified: 2022-02-15T10:59:53Z source: RIPE % This query was served by the RIPE Database Query Service version 1.102.2 (BLAARKOP) Ahora vemos el AS47764: edu@andromeda:~$ whois as47764 % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to and Conditions. % See http://www.ripe.net/db//db--conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to 'AS47104 - AS51355' as-block: AS47104 - AS51355 descr: RIPE NCC ASN block remarks: These AS Numbers are assigned to network operators in the RIPE NCC service region. mnt-by: RIPE-NCC-HM-MNT created: 2021-12-09T08:21:17Z last-modified: 2021-12-09T08:21:17Z source: RIPE % Information related to 'AS47764' % Abuse for 'AS47764' is '[email protected]' aut-num: AS47764 as-name: mailru-as org: ORG-LLCn4-RIPE descr: Mail.Ru descr: Moscow, Russia descr: http://mail.ru .............. Ahora vemos el prefijo en la tabla de BGP en IPv6: BGP table version is 13717370, local router ID is 10.255.255.2, vrf id 0 Default local pref 100, local AS 15954 Status codes: s suppressed, d damped, h history, * valid, > best, = multipath, i internal, r RIB-failure, S Stale, R Removed Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric Lorf Weight Path N i2a00:1148::/29 fd10:1:1:1::25 100 0 6939 47764 i N i fd10:1:1:1::23 100 0 6939 47764 i N i 2001:7f8:a0::1b1b:0:1 100 0 6939 47764 i N i2a00:1148::/32 fd10:1:1:1::25 100 0 6939 47764 i N i fd10:1:1:1::23 100 0 6939 47764 i N i 2001:7f8:a0::1b1b:0:1 100 0 6939 47764 i N i2a00:1148:5::/48 fd10:1:1:1::25 100 0 6939 47764 21051 i N i fd10:1:1:1::23 100 0 6939 47764 21051 i N i 2001:7f8:a0::1b1b:0:1 100 0 6939 47764 21051 i N i2a00:114f:4::/46 fd10:1:1:1::25 100 0 6939 47764 199295 i N i fd10:1:1:1::23 100 0 6939 47764 199295 i N i 2001:7f8:a0::1b1b:0:1 100 0 6939 47764 199295 i N i2a00:a300::/32 fd10:1:1:1::25 100 0 6939 47764 i N i fd10:1:1:1::23 100 0 6939 47764 i N i 2001:7f8:a0::1b1b:0:1 100 0 6939 47764 i N i2a00:b4c0::/32 fd10:1:1:1::25 100 0 6939 47764 i N i fd10:1:1:1::23 100 0 6939 47764 i N i 2001:7f8:a0::1b1b:0:1 100 0 6939 47764 i Displayed 6 routes and 551807 total paths Ahora los prefijos en IPv4: BGP table version is 61302925, local router ID is 10.255.255.2, vrf id 0 Default local pref 100, local AS 15954 Status codes: s suppressed, d damped, h history, * valid, > best, = multipath, i internal, r RIB-failure, S Stale, R Removed Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric Lorf Weight Path N*>i5.61.16.0/21 83.231.151.17 0 100 0 2914 3356 47764 i N* i 149.14.52.9 0 100 0 174 31133 47764 i N*=i 91.216.219.85 0 100 0 2914 3356 47764 i N*>i5.61.232.0/21 83.231.151.17 0 100 0 2914 3356 47764 i N* i 149.14.52.9 0 100 0 174 31133 47764 i N*=i 91.216.219.85 0 100 0 2914 3356 47764 i N* i5.101.40.0/22 149.14.52.9 0 100 0 174 31133 47764 i N*>i 83.231.151.17 0 100 0 2914 3356 47764 i N*=i 91.216.219.85 0 100 0 2914 3356 47764 i N*>i5.181.60.0/22 83.231.151.17 0 100 0 2914 3356 47764 i N* i 149.14.52.9 0 100 0 174 31133 47764 i N*=i 91.216.219.85 0 100 0 2914 3356 47764 i N*>i5.188.140.0/22 83.231.151.17 0 100 0 2914 3356 47764 i N* i 149.14.52.9 0 100 0 174 31133 47764 i N*=i 91.216.219.85 0 100 0 2914 3356 47764 i N*>i37.139.32.0/22 83.231.151.17 0 100 0 2914 3356 47764 i N* i 149.14.52.9 0 100 0 174 31133 47764 i N*=i 91.216.219.85 0 100 0 2914 3356 47764 i N*>i37.139.40.0/22 83.231.151.17 0 100 0 2914 3356 47764 i N* i 149.14.52.9 0 100 0 174 31133 47764 i N*=i 91.216.219.85 0 100 0 2914 3356 47764 i N*>i44.31.32.0/22 83.231.151.17 0 100 0 2914 1299 47764 199295 199295 i N* i 149.14.52.9 0 100 0 174 12389 47764 199295 199295 i N*=i 91.216.219.85 0 100 0 2914 1299 47764 199295 199295 i N*>i45.84.128.0/22 83.231.151.17 0 100 0 2914 3356 47764 i N* i 149.14.52.9 0 100 0 174 31133 47764 i N*=i 91.216.219.85 0 100 0 2914 3356 47764 i N*>i45.136.20.0/22 83.231.151.17 0 100 0 2914 3356 47764 i N* i 149.14.52.9 0 100 0 174 31133 47764 i N*=i 91.216.219.85 0 100 0 2914 3356 47764 i N*>i79.137.157.0/24 83.231.151.17 0 100 0 2914 3356 47764 i N* i 149.14.52.9 0 100 0 174 31133 47764 i N*=i 91.216.219.85 0 100 0 2914 3356 47764 i N*>i79.137.174.0/23 83.231.151.17 0 100 0 2914 3356 47764 i N* i 149.14.52.9 0 100 0 174 31133 47764 i N*=i 91.216.219.85 0 100 0 2914 3356 47764 i N*>i79.137.240.0/21 83.231.151.17 0 100 0 2914 3356 47764 i N* i 149.14.52.9 0 100 0 174 31133 47764 i N*=i 91.216.219.85 0 100 0 2914 3356 47764 i N*>i84.23.52.0/22 83.231.151.17 0 100 0 2914 3356 47764 i N* i 149.14.52.9 0 100 0 174 31133 47764 i N*=i 91.216.219.85 0 100 0 2914 3356 47764 i N*>i85.192.32.0/22 83.231.151.17 0 100 0 2914 3356 47764 i N* i 149.14.52.9 0 100 0 174 31133 47764 i N*=i 91.216.219.85 0 100 0 2914 3356 47764 i N*>i87.239.104.0/21 83.231.151.17 0 100 0 2914 3356 47764 i N* i 149.14.52.9 0 100 0 174 31133 47764 i N*=i 91.216.219.85 0 100 0 2914 3356 47764 i N*>i89.208.84.0/22 83.231.151.17 0 100 0 2914 3356 47764 i N* i 149.14.52.9 0 100 0 174 31133 47764 i N*=i 91.216.219.85 0 100 0 2914 3356 47764 i N*>i89.208.196.0/22 83.231.151.17 0 100 0 2914 3356 47764 i N* i 149.14.52.9 0 100 0 174 31133 47764 i N*=i 91.216.219.85 0 100 0 2914 3356 47764 i N*>i89.208.208.0/22 83.231.151.17 0 100 0 2914 3356 47764 i N* i 149.14.52.9 0 100 0 174 31133 47764 i N*=i 91.216.219.85 0 100 0 2914 3356 47764 i N*>i89.208.216.0/23 83.231.151.17 0 100 0 2914 3356 47764 i N* i 149.14.52.9 0 100 0 174 31133 47764 i N*=i 91.216.219.85 0 100 0 2914 3356 47764 i N*>i89.208.220.0/22 83.231.151.17 0 100 0 2914 3356 47764 i N* i 149.14.52.9 0 100 0 174 31133 47764 i N*=i 91.216.219.85 0 100 0 2914 3356 47764 i N*>i89.208.228.0/22 83.231.151.17 0 100 0 2914 3356 47764 i N* i 149.14.52.9 0 100 0 174 31133 47764 i N*=i 91.216.219.85 0 100 0 2914 3356 47764 i N*>i94.100.176.0/20 83.231.151.17 0 100 0 2914 3356 47764 i N* i 149.14.52.9 0 100 0 174 31133 47764 i N*=i 91.216.219.85 0 100 0 2914 3356 47764 i N*>i94.139.244.0/22 83.231.151.17 0 100 0 2914 3356 47764 i N* i 149.14.52.9 0 100 0 174 31133 47764 i N*=i 91.216.219.85 0 100 0 2914 3356 47764 i N*>i95.163.32.0/19 83.231.151.17 0 100 0 2914 3356 47764 i N* i 149.14.52.9 0 100 0 174 31133 47764 i N*=i 91.216.219.85 0 100 0 2914 3356 47764 i N*>i95.163.32.0/23 83.231.151.17 0 100 0 2914 3356 47764 21051 i N* i 149.14.52.9 0 100 0 174 31133 47764 21051 i N*=i 91.216.219.85 0 100 0 2914 3356 47764 21051 i N* i95.163.32.0/24 149.14.52.9 0 100 0 174 31133 47764 21051 i N*>i 83.231.151.17 0 100 0 2914 3356 47764 21051 i N*=i 91.216.219.85 0 100 0 2914 3356 47764 21051 i N* i95.163.33.0/24 149.14.52.9 0 100 0 174 31133 47764 21051 i N*>i 83.231.151.17 0 100 0 2914 3356 47764 21051 i N*=i 91.216.219.85 0 100 0 2914 3356 47764 21051 i N*>i95.163.180.0/22 83.231.151.17 0 100 0 2914 3356 47764 i N* i 149.14.52.9 0 100 0 174 31133 47764 i N*=i 91.216.219.85 0 100 0 2914 3356 47764 i N* i95.163.208.0/21 149.14.52.9 0 100 0 174 31133 47764 i N*>i 83.231.151.17 0 100 0 2914 3356 47764 i N*=i 91.216.219.85 0 100 0 2914 3356 47764 i N* i95.163.216.0/22 149.14.52.9 0 100 0 174 31133 47764 i N*>i 83.231.151.17 0 100 0 2914 3356 47764 i N*=i 91.216.219.85 0 100 0 2914 3356 47764 i N* i95.163.248.0/21 149.14.52.9 0 100 0 174 31133 47764 i N*>i 83.231.151.17 0 100 0 2914 3356 47764 i N*=i 91.216.219.85 0 100 0 2914 3356 47764 i N*>i109.120.180.0/22 83.231.151.17 0 100 0 2914 3356 47764 i N* i 149.14.52.9 0 100 0 174 12389 47764 i N*=i 91.216.219.85 0 100 0 2914 3356 47764 i N*>i109.120.188.0/22 83.231.151.17 0 100 0 2914 3356 47764 i N* i 149.14.52.9 0 100 0 174 12389 47764 i N*=i 91.216.219.85 0 100 0 2914 3356 47764 i N* i128.140.168.0/21 149.14.52.9 0 100 0 174 31133 47764 i N*>i 83.231.151.17 0 100 0 2914 3356 47764 i N*=i 91.216.219.85 0 100 0 2914 3356 47764 i N* i146.185.208.0/22 149.14.52.9 0 100 0 174 31133 47764 i N*>i 83.231.151.17 0 100 0 2914 3356 47764 i N*=i 91.216.219.85 0 100 0 2914 3356 47764 i N* i146.185.240.0/22 149.14.52.9 0 100 0 174 31133 47764 i N*>i 83.231.151.17 0 100 0 2914 3356 47764 i N*=i 91.216.219.85 0 100 0 2914 3356 47764 i N* i178.22.88.0/21 149.14.52.9 0 100 0 174 31133 47764 i N*>i 83.231.151.17 0 100 0 2914 3356 47764 i N*=i 91.216.219.85 0 100 0 2914 3356 47764 i N* i178.22.90.0/23 149.14.52.9 0 100 0 174 31133 47764 21051 i N*>i 83.231.151.17 0 100 0 2914 3356 47764 21051 i N*=i 91.216.219.85 0 100 0 2914 3356 47764 21051 i N* i178.22.90.0/24 149.14.52.9 0 100 0 174 31133 47764 21051 i N*>i 83.231.151.17 0 100 0 2914 3356 47764 21051 i N*=i 91.216.219.85 0 100 0 2914 3356 47764 21051 i N* i178.22.91.0/24 149.14.52.9 0 100 0 174 31133 47764 21051 i N*>i 83.231.151.17 0 100 0 2914 3356 47764 21051 i N*=i 91.216.219.85 0 100 0 2914 3356 47764 21051 i N* i178.22.92.0/23 149.14.52.9 0 100 0 174 31133 47764 21051 i N*>i 83.231.151.17 0 100 0 2914 3356 47764 21051 i N*=i 91.216.219.85 0 100 0 2914 3356 47764 21051 i N* i178.237.16.0/20 149.14.52.9 0 100 0 174 31133 47764 i N*>i 83.231.151.17 0 100 0 2914 3356 47764 i N*=i 91.216.219.85 0 100 0 2914 3356 47764 i N* i178.237.29.0/24 149.14.52.9 0 100 0 174 31133 47764 i N*>i 83.231.151.17 0 100 0 2914 3356 47764 i N*=i 91.216.219.85 0 100 0 2914 3356 47764 i N* i185.5.136.0/22 149.14.52.9 0 100 0 174 31133 47764 i N*>i 83.231.151.17 0 100 0 2914 3356 47764 i N*=i 91.216.219.85 0 100 0 2914 3356 47764 i N* i185.6.244.0/22 149.14.52.9 0 100 0 174 31133 47764 60863 i N*>i 83.231.151.17 0 100 0 2914 3356 47764 60863 i N*=i 91.216.219.85 0 100 0 2914 3356 47764 60863 i N* i185.16.148.0/22 149.14.52.9 0 100 0 174 31133 47764 i N*>i 83.231.151.17 0 100 0 2914 3356 47764 i N*=i 91.216.219.85 0 100 0 2914 3356 47764 i N* i185.16.244.0/22 149.14.52.9 0 100 0 174 31133 47764 i N*>i 83.231.151.17 0 100 0 2914 3356 47764 i N*=i 91.216.219.85 0 100 0 2914 3356 47764 i N*>i185.16.244.0/23 83.231.151.17 0 100 0 2914 3356 47764 i N*=i 91.216.219.85 0 100 0 2914 3356 47764 i N* i 149.14.52.9 0 100 0 174 31133 47764 i N*>i185.16.246.0/24 83.231.151.17 0 100 0 2914 3356 47764 i N*=i 91.216.219.85 0 100 0 2914 3356 47764 i N* i 149.14.52.9 0 100 0 174 31133 47764 i N*>i185.16.247.0/24 83.231.151.17 0 100 0 2914 3356 47764 i N*=i 91.216.219.85 0 100 0 2914 3356 47764 i N* i 149.14.52.9 0 100 0 174 31133 47764 i N* i185.86.144.0/22 149.14.52.9 0 100 0 174 31133 47764 i N*>i 83.231.151.17 0 100 0 2914 3356 47764 i N*=i 91.216.219.85 0 100 0 2914 3356 47764 i N* i185.100.104.0/22 149.14.52.9 0 100 0 174 31133 47764 i N*>i 83.231.151.17 0 100 0 2914 3356 47764 i N*=i 91.216.219.85 0 100 0 2914 3356 47764 i N*>i185.130.112.0/22 83.231.151.17 0 100 0 2914 3356 47764 i N* i 149.14.52.9 0 100 0 174 12389 47764 i N*=i 91.216.219.85 0 100 0 2914 3356 47764 i N* i185.187.63.0/24 149.14.52.9 0 100 0 174 31133 47764 i N*>i 83.231.151.17 0 100 0 2914 3356 47764 i N*=i 91.216.219.85 0 100 0 2914 3356 47764 i N* i185.226.52.0/22 149.14.52.9 0 100 0 174 31133 47764 i N*>i 83.231.151.17 0 100 0 2914 3356 47764 i N*=i 91.216.219.85 0 100 0 2914 3356 47764 i N* i185.241.192.0/22 149.14.52.9 0 100 0 174 31133 47764 i N*>i 83.231.151.17 0 100 0 2914 3356 47764 i N*=i 91.216.219.85 0 100 0 2914 3356 47764 i N* i188.93.56.0/21 149.14.52.9 0 100 0 174 31133 47764 i N*>i 83.231.151.17 0 100 0 2914 3356 47764 i N*=i 91.216.219.85 0 100 0 2914 3356 47764 i N* i188.93.59.0/24 149.14.52.9 0 100 0 174 31133 47764 21051 i N*>i 83.231.151.17 0 100 0 2914 3356 47764 21051 i N*=i 91.216.219.85 0 100 0 2914 3356 47764 21051 i N*>i193.0.170.0/23 83.231.151.17 0 100 0 2914 3356 47764 58116 i N* i 149.14.52.9 0 100 0 174 31133 47764 58116 i N*=i 91.216.219.85 0 100 0 2914 3356 47764 58116 i N* i193.203.40.0/22 149.14.52.9 0 100 0 174 31133 47764 i N*>i 83.231.151.17 0 100 0 2914 3356 47764 i N*=i 91.216.219.85 0 100 0 2914 3356 47764 i N* i194.186.63.0/24 149.14.52.9 0 100 0 174 31133 47764 i N*>i 83.231.151.17 0 100 0 2914 3356 47764 i N*=i 91.216.219.85 0 100 0 2914 3356 47764 i N* i195.211.20.0/22 149.14.52.9 0 100 0 174 31133 47764 i N*>i 83.231.151.17 0 100 0 2914 3356 47764 i N*=i 91.216.219.85 0 100 0 2914 3356 47764 i N* i195.211.20.0/24 149.14.52.9 0 100 0 174 31133 47764 21051 i N*>i 83.231.151.17 0 100 0 2914 3356 47764 21051 i N*=i 91.216.219.85 0 100 0 2914 3356 47764 21051 i N* i195.211.21.0/24 149.14.52.9 0 100 0 174 31133 47764 21051 i N*>i 83.231.151.17 0 100 0 2914 3356 47764 21051 i N*=i 91.216.219.85 0 100 0 2914 3356 47764 21051 i N* i195.211.128.0/23 149.14.52.9 0 100 0 174 31133 47764 21051 i N*>i 83.231.151.17 0 100 0 2914 3356 47764 21051 i N*=i 91.216.219.85 0 100 0 2914 3356 47764 21051 i N* i195.211.128.0/24 149.14.52.9 0 100 0 174 31133 47764 21051 i N*>i 83.231.151.17 0 100 0 2914 3356 47764 21051 i N*=i 91.216.219.85 0 100 0 2914 3356 47764 21051 i N* i195.211.130.0/23 149.14.52.9 0 100 0 174 31133 47764 21051 i N*>i 83.231.151.17 0 100 0 2914 3356 47764 21051 i N*=i 91.216.219.85 0 100 0 2914 3356 47764 21051 i N* i195.218.168.0/24 149.14.52.9 0 100 0 174 31133 47764 i N*>i 83.231.151.17 0 100 0 2914 3356 47764 i N*=i 91.216.219.85 0 100 0 2914 3356 47764 i N*>i195.218.190.0/23 83.231.151.17 0 100 0 2914 3356 47764 i N* i 149.14.52.9 0 100 0 174 31133 47764 i N*=i 91.216.219.85 0 100 0 2914 3356 47764 i N*>i213.109.75.0/24 83.231.151.17 0 100 0 2914 3356 47764 42834 i N* i 149.14.52.9 0 100 0 174 31133 47764 42834 i N*=i 91.216.219.85 0 100 0 2914 3356 47764 42834 i N* i213.109.79.0/24 149.14.52.9 0 100 0 174 31133 47764 44903 i N*>i 83.231.151.17 0 100 0 2914 3356 47764 44903 i N*=i 91.216.219.85 0 100 0 2914 3356 47764 44903 i N* i213.219.212.0/22 149.14.52.9 0 100 0 174 31133 47764 i N*>i 83.231.151.17 0 100 0 2914 3356 47764 i N*=i 91.216.219.85 0 100 0 2914 3356 47764 i N* i217.20.144.0/20 149.14.52.9 0 100 0 174 31133 47764 i N*>i 83.231.151.17 0 100 0 2914 3356 47764 i N*=i 91.216.219.85 0 100 0 2914 3356 47764 i N* i217.69.128.0/20 149.14.52.9 0 100 0 174 31133 47764 i N*>i 83.231.151.17 0 100 0 2914 3356 47764 i N*=i 91.216.219.85 0 100 0 2914 3356 47764 i Displayed 75 routes and 2651819 total paths Los ASs involucrados son: AS47764: Mail.ru AS6939: Hurricane Electric AS3356: Level 3 AS31133: Megafon.ru AS1299: Telia AS12389: Rostelecom

Cuando ponéis una ruta por defecto en ipv4 es fácil, ponéis la 0.0.0.0/0 y ya está, pero en Ipv6 no funciona igual y poner la ::/0 no deja de ser una barbaridad porque no todo el espacio de direccionamiento está asignado y hay direcciones como las ULA o las Link Local que no tiene ningún sentido que sean accesible vía una ruta por defecto. Recordemos que en IPv6 el espacio de direccionamiento público reservado es únicamente el 2000::/3 y todo lo que no esté ahí no tiene sentido encaminarse por internet. Esto tiene sus implicaciones porque en productos como los Cisco podemos encontrarnos con problemas si no conocemos esta funcionamiento. Si usamos un protocolo como por ejemplo OSPFv3  y queremos inyectar una ruta por defecto podemos hacerlo usando el default-intormation originate, de hecho en IPv4 se hace así, pero esto nos va a inyectar la ::/0 y no la 2000::/3, así que en Ipv6 si es posible mejor no usar el default-information originate, sino crearos vuestro propio route map.

Hoy os traigo un audio sobre BGP Anycast. Anunciar el mismo direccionamiento IP desde varios sitios a la vez nos permite utilizar BGP para "acercar el contenido al final". Si os fijáis en ping.pe al probar contra la 8.8.8.8 veréis que los tiempos son siempre bajos, y esto sólo puede ser posible si el contenido, en este caso, el servidor con la IP 8.8.8.8 está en esos sitios. Así que tenemos la dirección 8.8.8.8 dispuesta en varios sitios a la vez. ping 8.8.8.8. Sin embargo si miramos contra este podcast veremos que los tiempos son diferentes: ping eduardocollado.com En este caso lo que se ve es que sólo hay un servidor y que está en Europa, en concreto en la ciudad de Madrid, pero no está en todas partes, no está siendo anunciado por Anycast.

En el audio de hoy os hablo del procedimiento para migrar un par de switches de core en una red tradicional con dos switches de los que cuelgan los switches de . Cableado al nuevo switch. Interface vlan. Prioridad de Spanning Tree entre 4096 y 32768 en saltos de 4096. Cuanto más pequeño mejor. En VRRP la prioridad más grande es la que se queda con el rol de master, el otro en Standby.

Hoy tenemos a Nacho Mateo de IPBroker (ipbroker.com) en el podcast que viene a explicarnos como funciona el mundo de la compra, venta y alquiler de direccionamiento IPv4. Se han terminado las direcciones IPv4 y mientras no migremos a IPv6 será necesario usar direccionamiento IPv4 o algún mecanismo de transición. En el audio de hoy Nacho nos cuenta desde por qué cree él que no hay que gastar el dinero en CGNAT y sí en direcciones IPv4 hasta temas más serios como los problemas subyacentes de la venta de bien que son las direcciones IP. También hay unas preguntas que se generaron en el grupo de telegram del podcast y que no ha rehuido contestar ni una de ellas. Espero que os guste y cualquier duda podéis ar con Nacho sin problemas.

MANRS (Normas mutuamente acordadas para en encaminamiento seguro) son un conjunto de normas a las que puedes adherirte voluntariamente después de demostrar que cumples todos los requisitos. MANRS persigue eliminar las amenazas de encaminamiento más comunes: Secuestro de prefijos. Fugas de ruta. Suplantación de direccionamiento IP. Aquí vamos a centrarnos en MANRS para proveedores de servicios, pero también se puede aplicar MANRS para IXP, redes de distribución de contenidos, proveedores en la nube o incluso fabricantes. En cuanto a los proveedores de servicios de Internet (ISP) los beneficios de adherirse a MANRS son varios como por ejemplo: Reconocimiento por la comunidad como buenos ciudadanos de la red y contribuidores de la estabilidad en Internet. Demostrar competencia en seguridad y compromiso con clientes. Ofrecer un servicio de conectividad acorde a los estándares más altos. Contribuir a reducir los problemas de seguridad de routing. Las fases para cumplir MANRS son cuatro: Validación: Publicar información de routing en lugares que se puedan validar por cualquiera. Filtrado: Filtrar para anunciar con exactitud los prefijos propios y de sus clientes, filtrando el resto. Antisuplantación: Impedir el tráfico desde IPs suplantadas. Coordinación: Mantener información de o actualizada.