Servicios Virtualización y Cloud Computing

Sobre el autor

Florian Murillo

Florián Murillo es CTO y socio fundador de Cloud Consulting, consultora especializada en cloud computing y DataCenter, con mas de 25 años asesorando empresas de todos los tamaños y con amplia experiencia en Seguridad, Virtualización VMware (VCP5 y VCI5) y Networking de Cisco (CCNP, CCDP y CCSP). Actualmente se dedica a ayudar a desarrollar negocios y proyectos en la nube a integradores, consultoras y proveedores de servicio.

Artículos Relativos

20 Comentarios

  1. 1

    Aurelio Llorente

    Y digo yo… ¿Por qué no lo ponen en “Reject” por defecto?

    Me hacen mucha gracia los fabricantes que te dan unas recomendaciones de seguridad más o menos “imprescindibles” pero luego en las configuraciones por defecto no las aplican.
    Si es necesario que lo cambien todos los usuarios ¿Por qué no viene cambiado de fábrica?

    Responder
    1. 1.1

      Jose Maria Gonzalez

      Hola Aurelio, con permiso de Florrán, muy buena pregunta?

      Sabes por qué esta por defecto en “Reject” ? Déjame que te conteste con otra pregunta, Que aplicación famosa de Windows no funciona si el MAc Address Change esta en reject? Algún voluntario?

      rgds,
      J.

      Responder
        1. 1.1.1.1

          Jose Maria Gonzalez

          Exacto, Roberto, NLB y en modo unicast no funciona si tenemos el Mac address change en reject, por eso esta en aceptar por defecto.

          No obstante si no tenemos un cluster NLB en modo unicast deberíamos de activar el forget transmits y el mac address change como apunta nuestro compañero Florián. Sin embargo, un cluster NLB en modo multicast no tiene este problema.

          Rgds,
          J.

          Responder
          1. 1.1.1.1.1

            Aurelio Llorente

            Vamos, que al final se confirma la teoría de Florián, es la opción que menos llamadas genera, aunque sea una opción insegura y que sólo afecta en unas determinadas condiciones muy concretas. Mejor tener la configuración por defecto insegura, antes que recibir consultas de los ¿pocos? que usan clusters unicast.

          2. Jose Maria Gonzalez

            Hola Aurelio,

            Esta documentado en el KB de VMware. La mayoría de mis clientes no usan NLB y por extensión es lo que ha visto VMware por eso es mejor “joder” – excuse my French!!! – a unos cuantos que no a todos, no crees?

            rgds,
            J.

  2. 2

    Florián

    Hola Aurelio, no tengo una certeza completa, pero tengo una teoría, son las opciones que generan menos llamadas a soporte del fabricante ;-)

    Responder
  3. 3

    Aurelio Llorente

    Pues es una buena teoría. :-D
    Además es aplicable a más empresas.

    Responder
  4. 4

    miguel

    Gracias por el aporte florian.

    Responder
  5. 5

    Florián Murillo

    @Chema ¿El cluster de Microsoft? ;-)

    Responder
  6. 6

    Florián

    @Chema: Mejor explicado imposible ;-)

    Responder
    1. 6.1
  7. 7

    CABC

    Convendría aclarar que la funcionalidad se llama “Forged transmits”, no “Forget transmits”. Esta última expresión traducida sería algo así como “Olvidar transmisiones” mientras que la traducción de “forged” es fraguar/forjar/falsificar lo que daría una traducción del tipo “Transmisiones falsificadas/fraguadas”.

    Por otra parte, esa hipérbole hacia Microsoft como culpable del valor por defecto parece tener más carácter de animosidad que nada. La técnica que usa Microsoft no es engendro exclusivo suyo. Nada más mencionar este tema trae a mi mente el mismísimo Cisco HSRP o su versión oficial de IETF, el VRRP (RFC3768). Cualquier solución que se precie de implementar una IP virtual deberá recurrir a estas técnicas. Recurre el mismo VMware a usar sus macs virtuales haciendo todo el tiempo “forged transmits” sobre NICs que tienen MAC address efectivas distintas. Esperar que VMware ponga por defecto un “reject” en ese campo es como pedir a un fabricante de switches que por defecto sólo permita una MAC address en un puerto. Una afirmación capciosa del estilo podría ser, en ese hipotético caso, que el fabricante de switch no lo implementa porque VMware no funcionaría.

    Responder
  8. 8

    Florián

    @CABC, gracias por la corrección, siempre va bien un buen corrector en un blog. Por otro lado, no entiendo la referencia que haces a Microsoft, yo siempre he estado hablando de VMware, igual no lo he dejado suficientemente claro. Gracias por tu aportación.

    Responder
    1. 8.1

      CABC

      Gracias por la respuesta. Cuando me refiero a lo de Microsoft lo hago en el contexto de los comentarios que se fueron planteando a posteriori, no sobre el contenido que escribiste.

      Responder
  9. 9

    satos

    en definitiva, ¿cual sería la mejor opcion para configurar esos 3 parametros? ¿me podeis decir cual es el KB que indica las best practices para su configuración? llevo un buen rato indagando pero no doy con el.

    Muchas gracias.

    Responder
  10. 11

    Florián

    @Precios de Peajes ¿tienes algún problema concreto? Te funciona “el Microsoft” o “el Citrix”.
    Si nos das una pista a lo mejor te podemos ayudar mejor. Gracias por participar.

    Responder

Deja un Comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Una Web de JMG Virtual Consulting, especialistas en Soluciones de Virtualización y Formación Oficial VMware y OpenStack | Copyrights © 2017