00000001 + 00000001 = 00000011 texto alternativo http://locobox.googlepages.com/red_x_round.png

Conceptos erróneos sobre las redes *

¡Es hora de confesar! ... 'en algún momento' creías que sabías algo, y terminó siendo incorrecto, o no del todo correcto debido a una idea errónea sobre el tema.

Creemos una buena lista de conceptos erróneos populares que incluso los administradores de TI experimentados tienen, explícitamente sobre las redes. Mi esperanza es construir una descarga mental muy útil que sirva como un buen recurso para los miembros de esta comunidad.

Comenzaré con un ejemplo extremadamente obvio (los elementos con más votos estarán en la parte superior) :

• Todas las direcciones que comienzan con 169 provienen del sistema de conmutación por error APIPA

  Solo 169.254.0.0/16 está reservado para la asignación APIPA cuando el sistema operativo no puede encontrar una dirección asignada para una interfaz de red ( léase: rfc3927 ).

***** No debe confundirse con "Errores cometidos por los administradores de sistemas"

Mito: Permitir que ICMP sea inseguro.

Este es un motivo favorito mío, y está lo suficientemente extendido como para causar problemas importantes en Internet. Además de los diagnósticos prácticos que todos conocemos y amamos, está Path MTU Discovery y otras cosas que se rompen cuando se bloquea ICMP.

Algunas personas tienen creencias religiosas sobre las direcciones IP permitidas y no permitidas. Ayer vi en una de las respuestas aquí que 'las direcciones IP que terminan en .0 o .255 no son válidas', lo cual es completamente incorrecto.

Otros todavía piensan que solo tenemos subredes de tamaño A, B, C, mientras que CIDR estuvo gobernando el mundo durante bastante tiempo.

Algunos afirman que deshabilitar las respuestas ICMP hará que mi estación de trabajo sea invisible en su segmento LAN, lo cual no es cierto. Aún puede enviar solicitudes ARP y, en la mayoría de los casos, la máquina enviará una respuesta ARP, aunque tiene un firewall de nivel IP en ejecución.

Otros dicen que las subredes privadas (192.168.0.0/16 o 10.0.0.0/8 no son 'enrutables'), lo cual es completamente incorrecto nuevamente.

Las personas se sorprenden realmente cuando aprenden cómo la saturación de carga afecta sus velocidades de descarga. Esto depende en gran medida de los algoritmos de colas en ambos extremos del cuello de botella, pero en el caso de las conexiones ADSL típicas, la carga puede afectar significativamente la descarga.

En el lado divertido: algunos todavía piensan que "Internet es una serie de tubos" .

Todas las conexiones a Internet se crean de la misma manera, lo que importa es la velocidad de descarga.

"Acabo de descubrir qué es un T1, ¿no sabes que mi cable de Comcast en casa es 6 veces más rápido que nuestra conexión en el trabajo? ¿Por qué no tenemos eso aquí?"

Ya no aparece, pero llegó al punto en el que preferiría tragar alimentos básicos que tratar de explicar un SLA a otro tipo de marketing. (OK, tenía la misma pregunta cuando era un exfoliante de soporte de estación de trabajo, ¡lo admito!)

James Gosling cita a Peter Deutsch con crédito por las ocho falacias de la computación distribuida :

Esencialmente, todos, cuando crean una aplicación distribuida, hacen las siguientes ocho suposiciones. Todos demuestran ser falsos a la larga y todos causan grandes problemas y experiencias de aprendizaje dolorosas.

1. La red es confiable
2. La latencia es cero
3. El ancho de banda es infinito
4. La red es segura
5. La topología no cambia
6. Hay un administrador
7. El costo de transporte es cero
8. La red es homogénea.

Los tengo en la pared de mi cubo de cara al pasillo. A veces siento que me tropiezo con más de uno por día .

Un viejo pero bueno

• BPS (bits por segundo) y BAUD son lo mismo, que no lo son. BAUD es la tasa de símbolos. En muchos sistemas, los símbolos codifican cada uno 2 o más bits. p.ej,

  + 2v = 11
  + 1v = 10
  -1v = 01
  -2v = 00

En la práctica...

802.11A! = 54 Mbit / s, 802.11A ~ 27 Mbit / s

802.11B! = 11 Mbit / s, 802.11B ~ 5 Mbit / s

802.11G! = 54 Mbit / s, 802.11G ~ 22 Mbit / s

Odio cuando se culpa a la red de algo con una aplicación que se ejecuta lentamente.

Cuando todo funcione, excepto su Outlook, deje de actualizar el ticket para el equipo de redes que dice que la red está inactiva. Los trabajadores ignorantes de la mesa de ayuda son la ruina de la existencia de muchos administradores.

Que hacer cosas en "hardware" siempre es mejor que hacerlo en "software".

(¿Qué lleva a la pregunta obvia de dónde se traza la línea entre estos dos de todos modos, o si hay alguna buena distinción?)

Que "MBps" y "mbps" son intercambiables. Incluso si pudiera discernir contextualmente que los 'milibits' no son una unidad de medida válida, todavía hay un factor de diferencia de 8 entre los dos.

Y ni siquiera me hagas comenzar con mebibits.

En un entorno de LAN empresarial, muchas personas todavía asumen que el enrutamiento entre vlans es más lento que el cambio. Con los conmutadores modernos de hoy, tanto la conmutación como el enrutamiento se manejan en hardware que puede procesar / reenviar estos paquetes a la misma velocidad.

La idea de que los dispositivos de hardware dedicados siempre son mejores, más confiables y de mayor rendimiento que los productos básicos y / o hardware de PC, en la práctica , con los costos actuales.

Básicamente es lo que Cisco quiere que creas; claro, el NPE en el chasis del enrutador solo tiene un procesador ARM de ~ 300 MHz, pero tiene todos estos ASIC (Circuitos integrados específicos de la aplicación) solo para reenvío rápido de paquetes, búsquedas de enrutamiento FIB, etc.

Mientras que eso puede ser verdad, y por lo general me haga el favor usando el engranaje propietaria de ese tipo de enrutadores y conmutadores para una variedad de razones administrativas y MTBF-relacionados, el hecho es que en la era de 3 GHz y 8 GB de RAM, a menudo la presencia de ASIC y CAM simplemente no importa: la PC aún puede fumar ese enrutador. Claro, todo se hace en la CPU en lugar de fuera del tablero para hardware dedicado, y claro, todo está en procesos sujetos a los estragos de un entorno de programación de espacio de usuario en un SO de uso general, pero cuando tienes 20 veces la potencia de la CPU, a veces no importa, todavía sale muy por delante y es mucho más barato.

Aprendí esto nuevamente recientemente cuando se trata de un pandeo PIX de gama alta para aumentar las cargas de procesamiento de paquetes en un entorno de VoIP en crecimiento (enrutadores paralizados de paquetes por segundo mucho más que el rendimiento general per se, y las transmisiones de audio VoIP consisten en muy grandes cantidades de paquetes muy pequeños); Mientras tanto, el firewall de Linux que configuré como medida provisional para el enrutamiento entre VLAN hizo volar esa cosa fuera del agua.

Lo mismo para BGP. Todavía hay un debate vivo en el mundo de Cisco sobre las especificaciones mínimas del enrutador necesarias para mantener una o más vistas BGP completas de la tabla de enrutamiento IPv4 en constante crecimiento, ya que muchos modelos de enrutadores generalmente son capaces de hacerlo si no escasean en la RAM . Bueno, ya sabes, Quagga y un servidor Linux sólido con una gran NIC y ajustes de E / S de baja interrupción pueden hacer maravillas. :-)

Esa duplicación de dirección MAc no es posible. Lo es, es bastante improbable.

La idea errónea de que el uso inalámbrico significa que el acceso a Internet es mucho más lento porque muestra 54 MB / s, mientras que el uso de una conexión Ethernet muestra 100 MB / s.

No hace falta decir que fue difícil explicarle al usuario que solo era la velocidad de la red local y, de hecho, la velocidad de Internet para el sitio era de solo 8 mbps / 900 KB / s.

O, alternativamente, los usuarios que le exigen que suministre una conexión de banda ancha, luego, cuando les dice que la conexión inalámbrica que están utilizando está conectada a una conexión a Internet de banda ancha, exclaman "¡No, me refiero al cable azul!"

El tipo de cable no importa para la red siempre que esté engarzado profesionalmente. Esto viene de un administrador que se pregunta por qué las computadoras nuevas todavía acceden lentamente a Internet con sus adaptadores 100Base-T. El cable de red era Cat-3 IIRC.

La idea errónea de que una red conmutada Ethernet == una red segura. No lo hace.

Además de la omnipresente presencia de herramientas de envenenamiento por arp como 'Cain & Abel' y sus semejantes, el hecho de que la tabla CAM se agote cada cierto tiempo (por defecto 5 minutos en un conmutador Cisco ) y, por lo tanto, inunda el tráfico de unidifusión como un centro se traduce en fuga de paquetes y por lo tanto fuga potencial de información.

Puede cambiar el valor de tiempo de espera en los conmutadores administrados para compensar la cantidad de inundación que desea permitir, pero dado que es parte del funcionamiento de la conmutación Ethernet, no puede mitigarlo por completo.

Que necesita un cable cruzado para conectar 2 computadoras con Gigabit Ethernet. Usted no! ¡Patch hace el truco!

Mito: Duplicar los bps de un enlace duplica el rendimiento útil.

Al igual que con muchos mitos, esto puede ser cierto en algunas circunstancias limitadas, pero ignora la latencia del enlace y los límites de rendimiento de los sistemas finales y los protocolos.

Aumentar los bps reduce el tiempo que le toma a un sistema llevar los datos al enlace, no hace que los datos se muevan a lo largo del enlace más rápido. El tiempo para que el primer bit llegue al otro extremo es el mismo que antes, pero el retraso hasta que llega el último bit se reduce.

Tengo algunos mitos relacionados con las redes privadas (10.xxx, 192.168.xx, etc.).

Mito 1: las IP privadas nunca pueden aparecer en la red pública. Por lo tanto, no es posible que una IP privada que no sea la suya aparezca, por ejemplo, en una lista de trazado de ruta o en los encabezados SMTP "Recibidos por".

Mito 2: no es posible que un servidor DNS con conexión a Internet distribuya direcciones IP de red privada.

Ambos mitos surgen del mismo error: que las IP privadas son verdaderamente privadas y que nunca se mezclan con las IP públicas. Creo que la especificación solo dice que las IP privadas nunca se enrutarán en la red pública. Es decir, si intenta encontrar la ruta a alguna IP privada aleatoria (suponiendo que no esté en su propia red), no llegará a ninguna parte.

Pero eso no excluye las IP privadas que aparecen en la salida o el resultado de alguna consulta. Los servidores de correo interno, por ejemplo, no tienen una dirección IP pública, entonces, ¿qué otra dirección IP pueden incluir en el encabezado Recibido por que no sea la suya?

Del mismo modo, una gran red institucional puede usar diferentes redes privadas entre sus numerosas LAN. Los paquetes que pasan a través de su red recogerán las IP privadas de los enrutadores, incluso si el paquete finalmente regresa a la red pública. Por lo tanto, un traceroute puede incluir la IP privada de un enrutador en su salida.

Mito 3: Dado que las direcciones de red privadas no son enrutables, dos LAN que comparten el mismo espacio de direcciones de red privada pueden conectarse a través de un puente (como una VPN) sin ningún problema.

No funcionará, al menos no en mi experiencia. Digamos que su trabajo usa la red 192.168.1.x y usted usa la misma en casa (como es típico en los enrutadores de consumo). Estableces una conexión VPN desde la PC de tu casa para trabajar. En algún momento, desea enviar un trabajo de impresión a una impresora en el trabajo cuya dirección IP es 192.168.1.10. La PC de su hogar busca en su tabla de enrutamiento para averiguar dónde enviar ese paquete. ¿Qué LAN debe recibirla: la LAN de su hogar o la LAN de su trabajo? Respuesta: no lo se. Tal vez este, tal vez ese. Uno de ellos lo obtendrá, pero probablemente depende de su sistema operativo y software VPN para distinguir cuál tiene prioridad. Si es como el software VPN con el que he tenido experiencia, su LAN doméstica lo obtendrá y si no hay un dispositivo en 192.168.1.10, el paquete se descartará eventualmente.

Solución: cuando use una VPN, asegúrese de que ambas LAN estén usando diferentes espacios de red.

Creo que el error más grande que veo es que las redes basadas en IP pueden resolver todas nuestras necesidades técnicas o de TI.

El mayor ejemplo que veo de esto es VOIP. Es una infraestructura de telecomunicaciones que es increíblemente costosa, requiere muchos recursos y es difícil de administrar adecuadamente. Seguro que las implementaciones funcionan ... más o menos, pero estoy seguro de que podría haber sistemas mucho mejores con protocolos / infraestructura dedicados.

Que un punto de acceso inalámbrico de estilo hogareño (o dos) puede reemplazar una red cableada en un entorno multiusuario. Claro, su conexión inalámbrica en el hogar maneja hasta 5 o más PC, pero intente hacer frente a dos aulas de 30 niños que intentan usar computadoras portátiles para iniciar sesión en un dominio de Windows al mismo tiempo. Necesita un sistema inalámbrico administrado o algunos puntos de cable fijos para manejar parte (bueno, la mayoría) de la carga. Y una nota rápida para los vendedores de sistemas inalámbricos administrados: sí, estoy seguro de que su sistema tiene un mejor rendimiento que la competencia, pero no es infinito: solo hay tanto ancho de banda que puede exprimir del conjunto limitado de frecuencias disponible para la conexión inalámbrica 802.11, ¡no puedes cambiar las leyes de la física!

Eso, si SMB File Sharing / NetBIOS no funciona, nada más funcionará en la red (incluida la exploración de WWW) y toda la red está inactiva.

Un antiguo educador conectado a la red convertido en administrador de sistemas pensó que cuando estaba en la escuela secundaria. No sé si ella fue desilusionada de la noción anterior.

¿Qué tal la idea errónea de que puede dividir el ancho de banda de un enlace (en bits / seg) por 8 para modelar con precisión cuántos bytes transitará? Siempre deposito el 75% (máximo) de ocho décimas de la velocidad del enlace (es decir, para un enlace de 10 GBps, deposito 600 MBps como máximo).

Bien, aquí hay algo que acabo de resolver que antes me había eludido, por cada paquete que envía parece que la sobrecarga promedio es de 38 bytes, esto incluye el encabezado IP y TCP (por supuesto, este valor asume que todos los campos en el encabezado TCP se usan al máximo, el tamaño del encabezado IP es un valor común, es decir, no hay valores DSCP, etc., etc.), por lo que para transferir, digamos 2 MB (con tamaños de paquetes a 64 KB que aumentan sus paquetes por segundo [paquetes más grandes por segundo = sobrecarga menor] ) está buscando 1.2 KB de sobrecarga, no mucho, pero eso equivale a 6.78 MB por cada 10 GB transferidos, y 607.8 MB por cada 1 TB transferido.

Me siento mejor ahora: D

Mito: Agregar más ancho de banda a una conexión siempre hará que las cosas sean más rápidas.

No tanto. Si su enlace no está saturado y está intentando obtener datos de China a los EE. UU., Es posible que simplemente vaya tan rápido como pueda. Lleva tiempo (incluso a la velocidad de la luz) llegar de los EE. UU. A China, y hacer que el enlace no vaya más rápido si solo tiene un flujo de datos entre los sitios.

Ajustar con cariño un socket con la SO_LINGERopción de evitar el TIME_WAITestado de TCP porque " TIME_WAITes, ya sabes, entonces, ya sabes, viejo y, ya sabes, como asqueroso ".

Que su gerencia / jefe, el "SR Network Admin" sabe algo sobre redes reales. -Jgr descontento administrador de red.