802.1X

El estándar IEEE 802.1X define un control de acceso y un protocolo de autenticación basado en puertos que evita que las estaciones de trabajo no autorizadas se conecten a una LAN a través de los puertos de switch acceso público. El servidor de autenticación autentica cada estación de trabajo que está conectada a un puerto del switch antes habilitar cualquier servicio ofrecido por el switch o la LAN.

Con la autenticación 802.1x basada en puertos, los dispositivos de la red tienen funciones específicas, como se muestra en la Figura 1.

Figura 1: Roles de 802.1X

•  El cliente (suplicante): Es generalmente el puerto habilitado 802.1x en el dispositivo que solicita el acceso a los servicios de la LAN y del switch y luego responde a las solicitudes desde el switch. En la Figura 1, el dispositivo es una PC que ejecuta software de cliente que cumple con el estándar 802.1X.
• Switch (autenticador): Controla el acceso físico a la red según el estado de autenticación del cliente. El switch funciona como actúa intermediario (proxy) entre el cliente y el servidor de autenticación. Solicita la identificación de la información del cliente, verifica dicha información al servidor de autenticación y transmite una respuesta al cliente. El switch utiliza un agente de software de RADIUS que es responsable de encapsular y desencapsular las tramas del protocolo de autenticación extensible (EAP) y de interactuar con el servidor de autenticación.
• Servidor de autenticación: realiza la autenticación real del cliente. El servidor de autenticación acepta la identidad del cliente y notifica al switch si el cliente está autorizado para acceder a los servicios de la LAN y del switch. Debido a que el switch actúa como el proxy, el servicio de autenticación es transparente para el cliente. El sistema de seguridad RADIUS con extensiones de EAP es el único servidor de autenticación admitido.

Blogs relacionados 

Si te gusto este articulo comenta y comparte sigue en tu pagina Redes Five.

visitanos en nuestra pagina sobre sistemas operativos y mas Sistemastube.

AAA con RADIUS y TACACS+

Para evitar que usuarios malintencionados obtengan acceso a equipos de red y servicios sensibles, los administradores deben habilitar el control de acceso. El control de acceso limita a las personas o los dispositivos que pueden utilizar recursos específicos. También limita los servicios o las opciones que están disponibles después de que se concede el acceso.

El control de acceso básico en los dispositivos de red se activa mediante la autenticación. Existen diferentes métodos para implementar la autenticación en un dispositivo Cisco, y cada método ofrece varios niveles de seguridad. A continuación, se describen dos métodos comunes:

• Autenticación de contraseña simple: Esto implica el uso de los comandos de configuración password y login para proteger la consola, las líneas vty, y los puertos auxiliares. Lamentablemente, este método es también el método más débil y menos seguro porque no proporciona ninguna responsabilidad. Por ejemplo, cualquier persona que tenga la contraseña puede obtener acceso al dispositivo y modificar la configuración.
• Autenticación local de bases de datos: Esto implica la creación de las cuentas de usuario local con el comando de configuración global username name secret password y luego configurar el comando de configuración de línea login local en la consola, el VTY y los puertos auxiliares. Esto proporciona seguridad adicional, ya que un atacante necesita saber un nombre de usuario y una contraseña. También proporciona más responsabilidad porque el nombre de usuario queda registrado cuando un usuario inicia sesión.

Sin embargo, el método de la base de datos local no escala mucho más allá de algunos dispositivos de red porque las cuentas de usuario deben configurarse localmente en cada dispositivo. Esto no es adecuado en un entorno empresarial grande con varios routers y switches para administrar. Además, la configuración de la base de datos local no proporciona ningún método de autenticación de reserva. Por ejemplo, ¿qué sucede si el administrador olvida el nombre de usuario y la contraseña para ese dispositivo? Sin el método de respaldo disponible para la autenticación, la recuperación de la contraseña se convierte en la única opción.

Una solución mejor y más escalable es lograr que todos los dispositivos remitan a una base de datos de nombres de usuario y contraseñas alojados en un servidor central. Para admitir esto, los dispositivos Cisco admiten el marco de trabajo de autenticación, autorización y auditoría (AAA) que ayuda a asegurar el acceso de los dispositivos. En los dispositivos Cisco, se utilizan dos protocolos de autenticación AAA:

• Terminal Access Controller Access-Control System Plus (TACACS+, sistema de control de acceso mediante control del acceso desde terminales [se pronuncia como “tack-axe plus”])
• Remote Authentication Dial-In User Service (RADIUS, servicio de usuario de acceso telefónico de autenticación remota)

Un dispositivo compatible con AAA se puede configurar para remitir a una base de datos de usuarios externa para la autenticación de usuarios, licencias y contabilización. El dispositivo se comunica con el servidor AAA mediante el protocolo TACACS+ o RADIUS. Cada protocolo admite capacidades y funcionalidades diferentes. La selección de TACACS+ o RADIUS depende de las necesidades de la organización. Por ejemplo, un ISP grande puede seleccionar RADIUS porque admite la contabilización detallada necesaria para la facturación de los usuarios. Una organización con varios grupos de usuarios puede seleccionar TACACS+ porque requiere políticas de autorización que se aplican por usuario o por grupo.

Es importante comprender las diferencias entre los protocolos TACACS+ y RADIUS.

Estos son tres factores cruciales para TACACS+:

• Separa la autenticación y la autorización.
• Cifra todas las comunicaciones.
• Utiliza el puerto TCP 49.

A continuación, se enumeran cuatro factores cruciales para RADIUS:

• Combina la autenticación de RADIUS y autorización como un solo proceso.
• Cifra solamente la contraseña.
• Utiliza UDP.
• Admite tecnologías de acceso remoto, 802.1x y el protocolo SIP (Session Initiation Protocol).

Mientras ambos protocolos pueden usarse para la comunicación entre un router y los servidores AAA, TACACS+ se considera el protocolo más seguro. Esto se debe a que se cifran todos los intercambios de protocolos TACACS+, mientras que RADIUS solo cifra la contraseña del usuario. RADIUS no cifra nombres de usuario, información de la cuenta, o cualquier otra información que contenga el mensaje de RADIUS.

Blogs relacionados 

Si te gusto este articulo comenta y comparte sigue en tu pagina Redes Five.

visitanos en nuestra pagina sobre sistemas operativos y mas Sistemastube.

Detección DHCP

Un ataque de suplantación de DHCP se produce cuando un servidor DHCP dudoso se conecta a la red y brinda parámetros de configuración IP falsos a los clientes legítimos. La suplantación de DHCP es peligrosa porque los clientes pueden recibir información de concesión de IP, como servidores DNS maliciosos, puertas de enlace predeterminadas maliciosas y asignaciones IP maliciosas.

Las mejores prácticas de seguridad recomiendan el uso de la detección DHCP para mitigar los ataques de suplantación de DHCP.

La detección DHCP crea y mantiene una base de datos denominada base de datos de enlaces de detección DHCP (también conocida como tabla de enlaces de detección DHCP). Esta base de datos incluye la dirección MAC del cliente, la dirección IP, el tiempo de la concesión de DHCP, el tipo de enlace, el número de VLAN, y la información de interfaz en cada puerto de switch o interfaz no confiables. El administrador de redes debe definir qué puertos son confiables. Al combinar la información en la base de datos de enlace de detección DHCP con los puertos confiables, el switch puede filtrar los mensajes DHCP de fuentes no confiables.

Cuando la detección DHCP se habilita en una interfaz o una VLAN, y un switch recibe un paquete DHCP en un puerto no confiable, el switch compara la información del paquete de origen con la información que se mantiene en la base de datos de enlaces de detección DHCP. El switch negará los paquetes que contengan la siguiente información:

• Mensajes no autorizados del servidor DHCP que provengan de un puerto no confiable.
• Mensajes del cliente DHCP que no cumplan con la base de datos de enlaces de detección DHCP o con los límites de velocidad.
• Paquetes de agente de retransmisión DHCP que incluyan información de la opción 82 proveniente de un puerto no confiable.

Nota: La opción 82 proporciona seguridad y se utiliza para enviar información sobre los clientes DHCP a servidor DHCP. Sin embargo, un puerto no confiable no debe recibir paquetes de opción 82.

En una red grande, la creación de la base de datos de enlaces de detección DHCP puede llevar tiempo una vez que se habilita. Por ejemplo, la detección DHCP puede tardar 2 días para completar la base de datos, si el tiempo de la concesión de DHCP es de 4 días.

La detección DHCP reconoce dos tipos de puertos:

• Puertos de confianza de DHCP: Solo se puede confiar en los puertos conectados a servidores DHCP corriente arriba. Estos puertos deben generar tráfico a los servidores DHCP que respondan con mensajes de DHCP Offer y DHCP Ack. Los puertos confiables se deben identificar explícitamente en la configuración.
• Puertos no confiables: estos puertos se conectan a los hosts que no deben proporcionar mensajes de servidor DHCP. De manera predeterminada, todos los puertos de switch no son confiables.

En la Figura 1, se presenta un ejemplo visual que muestra cómo los puertos de detección DHCP se deben asignar en una red.

Figura 1: Identificación de los puertos confiables y no confiables de detección DHCP

Observe cómo los puertos confiables siempre conducen al servidor de DHCP legítimo, mientras que el resto de los puertos (es decir, los puertos de acceso que se conectan a los terminales) no son confiables de manera predeterminada.

Blogs relacionados 

Si te gusto este articulo comenta y comparte sigue en tu pagina Redes Five.

visitanos en nuestra pagina sobre sistemas operativos y mas Sistemastube.

Solución de problemas de ACL escenario 3

Solución de problemas de ACL de IPv6 (escenario 3)

Este escenario de solución de problemas de ACL de IPv6 utiliza la topología que se muestra en la Figura 1.

Figura 1: Topología de ACL de IPv6 para el escenario 3

R1 está configurada con una ACL de IPv6 llamada DENY-ACCESS que debe aplicar la siguiente política para la LAN del R3:

• Permitir acceso a la red :11 desde la red :30
• Denegar acceso a la red :10

El Ejemplo 1 muestra la configuración y la aplicación de ACL de IPv6.

Ejemplo 1: Verifique la configuración de ACL de IPv6 y la aplicación de la interfaz

R1# show access-list IPv6 access list DENY-ACCESS     permit ipv6 any 2001:DB8:CAFE:11::/64 sequence 10     deny ipv6 any 2001:DB8:CAFE:10::/64 sequence 20 Comando show running-config de comandos R1# | interfaz GigabitEthernet0/1 de la sección interface GigabitEthernet0/1  no ip address  duplex auto  speed auto  ipv6 address FE80::1 link-local  ipv6 address 2001:DB8:CAFE:11::1/64  ipv6 eigrp 1  ipv6 traffic-filter DENY-ACCESS out R1#

La ACL DENY-ACCESS debe permitir el acceso a la red:11 desde la red :30 y denegar el acceso a la red :10. Sin embargo, después de aplicar la ACL a la interfaz: la red 10 aún es accesible desde la red :30.

Solución:  En esta situación, el problema no tiene que ver con la manera en la que se escribieron las declaraciones de las ACL, sino con la ubicación de la ACL. Dado que las ACL de IPv6 deben configurarse con un origen y un destino, debe aplicarse lo más cerca posible del origen del tráfico. La ACL DENY-ACCESS se aplicó en la dirección saliente en la interfaz R1 G0/1 que está más cerca del destino. Como resultado, el tráfico a la red :10 no se ve no se ve afectado porque alcanza la red :10 a través de la otra interfaz de la red LAN, G0/0. Puede aplicar la ACL entrante en la interfaz S0/0/0 del R1. Sin embargo, porque tenemos control sobre el R3, la mejor ubicación sería configurar y aplicar la ACL lo más cerca posible del origen del tráfico. El ejemplo 2 muestra la eliminación de la ACL en el R1 y la configuración y la aplicación correctas de la ACL en el R3.

Ejemplo 2: Elimine la ACL en el R1; configure y aplique la ACL en el R2

R1(config)# no ipv6 access-list DENY-ACCESS R1(config)# interface g0/1 R1(config-if)# no ipv6 traffic-filter DENY-ACCESS out R1(config-if)# !----------------------------------------------------- R3(config)# ipv6 access-list DENY-ACCESS R3(config-ipv6-acl)# permit ipv6 any 2001:DB8:CAFE:11::/64 R3(config-ipv6-acl)# deny ipv6 any 2001:DB8:CAFE:10::/64 R3(config-ipv6-acl)# exit R3(config)# interface g0/0 R3(config-if)# ipv6 traffic-filter DENY-ACCESS in R3(config-if)#

Blogs relacionados 

Si te gusto este articulo comenta y comparte sigue en tu pagina Redes Five.

visitanos en nuestra pagina sobre sistemas operativos y mas Sistemastube.

Solución de problemas de ACL escenario 2

Solución de problemas de ACL de IPv6 (situación 2)

Este escenario de solución de problemas de ACL de IPv6 utiliza la topología que se muestra en la Figura 1.

Figura 1: Topología de ACL de IPv6 para el escenario 2

R3 está configurada con una ACL de IPv6 llamada RESTRICTED-ACCESS que debe aplicar la siguiente política para la LAN del R3:

• Permitir acceso a la red :10.
• Denegar acceso a la red :11.
• Permitir acceso de SSH a la PC en 2001:DB8:CAFE:11::11.

Sin embargo, después de configurar la ACL, la PC3 no puede llegar a la red 10 o la red 11, y no puede utilizar SSH en el host en 2001:DB8:CAFE:11::11.

Solución: En esta situación, el problema no se debe a cómo se aplicó la ACL. En la interfaz, la ACL no se escribe mal y la dirección y la ubicación son correctas, como se muestra en el Ejemplo 1.

Ejemplo 1: Verifique la configuración de la interfaz de ACL de IPv6

R3# show running-config | section interface GigabitEthernet0/0 interface GigabitEthernet0/0  no ip address  duplex auto  speed auto  ipv6 address FE80::3 link-local  ipv6 address 2001:DB8:1:30::1/64  ipv6 eigrp 1  ipv6 traffic-filter RESTRICTED-ACCESS in R3#

Una mirada más detallada a la ACL de IPv6 que se muestra en el ejemplo 2 revela que el problema está en el pedido y los criterios de las reglas de ACE.

Ejemplo 2: Verifique las declaraciones de ACL de IPv6

R3# show ipv6 access-list IPv6 access list RESTRICTED-ACCESS     permit ipv6 any host 2001:DB8:CAFE:10:: sequence 10     deny ipv6 any 2001:DB8:CAFE:11::/64 sequence 20     permit tcp any host 2001:DB8:CAFE:11::11 eq 22 sequence 30 R3#

La primera declaración de permiso debería permitir el acceso a la red :10. Sin embargo, el administrador configuró una instrucción de host y no especificó un prefijo. En este caso, se otorga acceso únicamente a 2001:DB8:CAFE:10:: se permite el host. Para corregir este problema, elimine el argumento de host y cambie el prefijo /64 a. Puede hacer esto sin eliminar la ACL reemplazando el ACE mediante el número de secuencia 10, como se muestra en el Ejemplo. 3.

Ejemplo 3: Reemplace la instrucción de host de ACL de IPv6

R3(config)# ipv6 access-list RESTRICTED-ACCESS R3(config-ipv6-acl)# permit ipv6 any 2001:db8:cafe:10::/64 sequence 10 R3(config-ipv6-acl)# end R3# show access-list IPv6 access list RESTRICTED-ACCESS     permit ipv6 any 2001:DB8:CAFE:10::/64 sequence 10     deny ipv6 any 2001:DB8:CAFE:11::/64 sequence 20     permit tcp any host 2001:DB8:CAFE:11::11 eq 22 sequence 30 R3#

El segundo error en la ACL es el orden de las dos siguientes afirmaciones. La política especifica que los hosts en la LAN del R3 deben poder utilizar SSH en el host 2001:DB8:CAFE:11::11. Sin embargo, la declaración deny para la red :11 se encuentra antes de la declaración permit. Por lo tanto, todos los intentos para acceder al: se deniega la red 11 antes de que la instrucción que permite el acceso de SSH puede evaluarse. Una vez que se establece una coincidencia, no se analizan otras sentencias. Para corregir este problema, necesitará eliminar las sentencias primero y, luego, ingresarlas en el orden correcto, como se muestra en el Ejemplo. 4.

Ejemplo 4: Reordene las declaraciones de ACL de IPv6

R3(config)# ipv6 access-list RESTRICTED-ACCESS R3(config-ipv6-acl)# no deny ipv6 any 2001:DB8:CAFE:11::/64 R3(config-ipv6-acl)# no permit tcp any host 2001:DB8:CAFE:11::11 eq 22 R3(config-ipv6-acl)# permit tcp any host 2001:DB8:CAFE:11::11 eq 22 R3(config-ipv6-acl)# deny ipv6 any 2001:DB8:CAFE:11::/64 R3(config-ipv6-acl)# end R3# show access-list IPv6 access list RESTRICTED-ACCESS     permit ipv6 any 2001:DB8:CAFE:10::/64 sequence 10     permit tcp any host 2001:DB8:CAFE:11::11 eq 22 sequence 20     deny ipv6 any 2001:DB8:CAFE:11::/64 sequence 30 R3#

Blogs relacionados 

Si te gusto este articulo comenta y comparte sigue en tu pagina Redes Five.

visitanos en nuestra pagina sobre sistemas operativos y mas Sistemastube.

Solución de problemas de ACL escenario 1

Solución de problemas de ACL de escenario 1

Este escenario de solución de problemas de las ACL de IPv6 utiliza la topología que se muestra en la Figura 1.

Figura 1: Topología de una ACL de IPv6 para el escenario 1

R1 está configurada con una ACL de IPv6 para denegar el acceso FTP desde la red :10 a la red :11. Sin embargo, después de configurar la ACL, la PC1 todavía puede conectarse al servidor FTP que se ejecuta en la PC2. Al consultar el resultado del comando access-list show ipv6 en el Ejemplo 1, se muestran las coincidencias para la declaración de permiso, pero no se muestran las declaraciones de negación.

Ejemplo 1: Verifique las declaraciones de la ACL de IPv6

R1# show ipv6 access-list IPv6 access list NO-FTP-TO-11     deny tcp any 2001:DB8:CAFE:11::/64 eq ftp sequence 10     deny tcp any 2001:DB8:CAFE:11::/64 eq ftp-data sequence 20     permit ipv6 any any (11 matches) sequence 30 R1#

Solución: Los ACE en las ACL no muestran ningún problema en el orden o en los criterios de las reglas. El siguiente paso es ver cómo se aplica la ACL en la interfaz utilizando ipv6 traffic-filter. ¿La ACL se aplicó utilizando el nombre correcto, la interfaz correcta y la dirección correcta? Para revisar errores de configuración de interfaz, visualice la configuración en ejecución, como se muestra en el Ejemplo. 2.

Ejemplo 2: Verifique la configuración de la interfaz de la ACL de IPv6

R1# show running-config | begin interface G interface GigabitEthernet0/0  no ip address  ipv6 traffic-filter NO-FTP-TO-11 out  duplex auto  speed auto  ipv6 address FE80::1 link-local  ipv6 address 2001:DB8:1:10::1/64  ipv6 eigrp 1 <resultado omitido> R1#

La ACL se aplicó con el nombre correcto, pero con una dirección incorrecta. La dirección in o out se toma desde la perspectiva del router, lo cual significa que la ACL actualmente se aplica al tráfico antes de que se reenvíe desde la interfaz G0/0 e ingrese en la red :10. Para corregir el problema, elimine ipv6 traffic-filter NO-FTP-TO-11 out y reemplácelo con ipv6 traffic-filter NO-FTP-TO-11 in, como se muestra en el Ejemplo 3.

Ejemplo 3: Comandos para corregir una ACL de IPv6 mal aplicada

R1(config)# interface g0/0 R1(config-if)# no ipv6 traffic-filter NO-FTP-TO-11 out R1(config-if)# ipv6 traffic-filter NO-FTP-TO-11 in R1(config-if)# end R1#

Ahora los intentos de PC1 para acceder al servidor FTP se rechazan, como se muestra en el Ejemplo 4.

Ejemplo 4: Verifique que la ACL ahora esté bloqueando el acceso al servidor FTP

R1# show ipv6 access-list IPv6 access list NO-FTP-TO-11     deny tcp any 2001:DB8:CAFE:11::/64 eq ftp (37 matches) sequence 10     deny tcp any 2001:DB8:CAFE:11::/64 eq ftp-data sequence 20     permit ipv6 any any (11 matches) sequence 30

Blogs relacionados 

Si te gusto este articulo comenta y comparte sigue en tu pagina Redes Five.

visitanos en nuestra pagina sobre sistemas operativos y mas Sistemastube.

Verificación del protocolo eBGP

Se pueden usar tres comandos pueden usarse para verificar el protocolo eBGP, como se muestra en la Tabla 1.

Tabla 1: Comandos de verificación de BGP

Comando	Descripción
Router# show ip route	Verifique que las rutas publicadas por el vecino BGP se encuentren presentes en la tabla de routing IPv4.
Router# show ip bgp	Verifique que las redes IPv4 recibidas y publicadas se encuentren en la tabla de BGP.
Router# show ip bgp summary	Verifique los vecinos BGP IPv4 y otra información de BGP.

En la figura 1, se muestra la topología de configuración de eBGP.

Figura 1: Topología de configuración de eBGP

El ejemplo 1 muestra el resultado de la tabla de routing IPv4 de la Empresa A.

Ejemplo 1: Tabla de routing IPv4 de la Empresa A

Company-A# show ip route Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP <resultado omitido> Gateway of last resort is 209.165.201.1 to network 0.0.0.0 B*    0.0.0.0/0 [20/0] via 209.165.201.1, 00:36:03       10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks C        198.133.219.0/24 is directly connected, GigabitEthernet0/0 L        198.133.219.1/32 is directly connected, GigabitEthernet0/0       209.165.201.0/24 is variably subnetted, 2 subnets, 2 masks C        209.165.201.0/27 is directly connected, GigabitEthernet0/1 L        209.165.201.2/32 is directly connected, GigabitEthernet0/1 Company-A#

Observe cómo el código de origen B identifica que la ruta fue aprendida mediante el BGP. Específicamente, en este ejemplo, la Empresa A recibió una ruta predeterminada publicada por BGP desde ISP-1.

El Ejemplo 2 muestra el resultado de la tabla de BGP de la Empresa A.

Ejemplo 2: Tabla de BGP de la empresa A

Company-A# show ip bgp BGP table version is 3, local router ID is 209.165.201.2 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,               r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,               x best-external, a additional-path, c RIB-compressed, Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found      Network          Next Hop            Metric LocPrf Weight Path  *>  0.0.0.0          209.165.201.1            0             0 65001 i  *>  198.133.219.0/24 0.0.0.0                  0         32768 i Company-A#

La primera entrada 0.0.0.0 con un salto siguiente 209.165.201.1 es la ruta predeterminada publicada por ISP-1. La ruta del AS muestra el AS simple de 65001 porque la red 0.0.0.0/0 publicada por el ISP-1, surgió del mismo AS. La mayoría de las entradas de la tabla de BGP muestran los números del sistema autónomo múltiple en la ruta y detallan la secuencia de números de AS necesarios para llegar a la red de destino.

La segunda entrada 198.133.219.0/24 es la red publicada por el router de la empresa A al ISP-1. La dirección del siguiente salto de 0.0.0.0 indica que la red 198.133.219.0/24 se originó en este router.

El ejemplo 3 muestra el estado de conexión de BGP en la Empresa A.

Ejemplo 3: Conexiones de BGP de la Empresa A

Company-A# show ip bgp summary BGP router identifier 209.165.201.2, local AS number 65000 BGP table version is 3, main routing table version 3 2 network entries using 288 bytes of memory 2 path entries using 160 bytes of memory 2/2 BGP path/bestpath attribute entries using 320 bytes of memory 1 BGP AS-PATH entries using 24 bytes of memory 0 BGP route-map cache entries using 0 bytes of memory 0 BGP filter-list cache entries using 0 bytes of memory BGP using 792 total bytes of memory BGP activity 2/0 prefixes, 2/0 paths, scan interval 60 secs Neighbor       V       AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd 209.165.201.1  4    65001      66      66        3    0    0 00:56:11           1 Company-A#

La primera línea muestra la dirección IPv4 local utilizada para establecer una interconexión con otro vecino de BGP y el número local de AS de este router. Aparecerá la dirección y el número de AS del vecino BGP remoto en la parte inferior del resultado.

Blogs relacionados 

Si te gusto este articulo comenta y comparte sigue en tu pagina Redes Five.

visitanos en nuestra pagina sobre sistemas operativos y mas Sistemastube.

Opciones de BGP

El BGP es utilizado por los sistemas autónomos para publicar las redes que se originaron dentro del AS o, en el caso de los ISP, las redes que se originaron en otros sistemas autónomos.

Por ejemplo, una empresa que se conecta al ISP utilizando BGP publicaría sus direcciones de red en su ISP. El ISP luego publicaría dichas redes en otros ISP (pares BGP). Finalmente, el resto de los sistemas autónomos en Internet aprenden sobre las redes originadas inicialmente por la empresa.

Existen tres maneras comunes mediante las cuales una organización puede elegir implementar el BGP en un entorno de alojamientos múltiples:

---

Ruta predeterminada solamente

El ISP publica una ruta predeterminada en la empresa A, como se muestra en la Figura 1. Las flechas indican que el valor predeterminado está configurado en los ISP, no en la empresa A. Este es el método más simple para implementar el BGP. Sin embargo, debido a que la empresa recibe una sola ruta predeterminada de ambos ISP, se puede producir el routing por debajo del nivel óptimo. Por ejemplo, la empresa A puede elegir usar la ruta predeterminada desde ISP-1 cuando envía paquetes a una red de destino en los ISP-2 AS.

Figura 1: Ruta predeterminada solamente

---

Ruta predeterminada y rutas del ISP

Los ISP publican su ruta predeterminada y su red en la empresa A, como se muestra en la Figura 2. Esta opción permite que la empresa A reenvíe el tráfico al ISP correspondiente para las redes anunciadas por ese ISP. Por ejemplo, la empresa A elegiría el ISP-1 para redes publicadas por el ISP-1. Para todas las demás redes, se puede usar una de las dos rutas predeterminadas, lo que significa que el routing por debajo del nivel óptimo aún puede tener lugar para el resto de las rutas de Internet.

Figura 2: Ruta predeterminada y rutas del ISP

---

Todas las rutas de Internet

Los ISP publican todas las rutas de Internet a la empresa A, como se muestra en la Figura 3. Debido a que la empresa A recibe todas las rutas de Internet de ambos ISP, la empresa A puede determinar qué ISP utilizará como la mejor ruta para reenviar tráfico hacia cualquier red. Si bien esto resuelve el problema del routing por debajo del nivel óptimo, el router BGP de la empresa A debe contener todas las rutas de Internet, que son actualmente las rutas a más de 550 000 redes.

Figura 3: Todas las rutas de Internet

Blogs relacionados 

Si te gusto este articulo comenta y comparte sigue en tu pagina Redes Five.

visitanos en nuestra pagina sobre sistemas operativos y mas Sistemastube.

Cuándo no se debe utilizar BGP

El BGP no debe utilizarse cuando existe al menos una de las siguientes condiciones:

• Hay una sola conexión a Internet u otro AS. Esto se conoce como “alojamiento simple”. En este caso, la empresa A puede ejecutar un IGP con el ISP o tanto la empresa A y como el ISP utilizarán rutas estáticas, como se muestra en la Figura 1. Aunque esto se recomienda solo en situaciones inusuales, en este curso, configurará un BGP de alojamiento simple.
• Cuando hay una comprensión limitada del BGP.  Una configuración incorrecta de un router BGP puede producir errores de gran alcance más allá del AS local, y esto puede tener un impacto negativo en los routers en Internet.

Nota: Existen algunas situaciones de alojamiento simple donde el BGP puede ser apropiado, como la necesidad de una política de routing específica. Sin embargo, las políticas de routing están más allá del alcance de este curso.

Figura 1: Topología de alojamiento simple

Blogs relacionados 

Si te gusto este articulo comenta y comparte sigue en tu pagina Redes Five.

visitanos en nuestra pagina sobre sistemas operativos y mas Sistemastube.

Configuración de BGP

La Figura 1 muestra una topología de BGP de alojamiento simple. Utilizando el protocolo eBGP, la empresa A en AS 65000 publicará su red 198.133.219.0/24 en ISP-1 a AS 65001. El ISP-1 anunciará una ruta predeterminada en las actualizaciones de eBGP a la empresa A.

Nota: El protocolo BGP normalmente no es necesario en AS de alojamiento simple. Se utiliza aquí para proporcionar un ejemplo de configuración sencilla.

Figura 1: Topología de Configuración de eBGP

El ejemplo 1 muestra la configuración de BGP para la empresa A. Los clientes utilizarán generalmente el espacio privado para la dirección postal IPv4 para los dispositivos internos dentro de su propia red. Luego, el router de la empresa A utiliza NAT para traducir estas direcciones privadas IPv4 privadas a una de sus direcciones IPv4 públicas, publicadas por el protocolo BGP en el ISP.

Ejemplo 1: configuración del protocolo eBGP para la empresa A

Company-A(config)# router bgp 65000 Company-A(config-router)# neighbor 209.165.201.1 remote-as 65001 Company-A(config-router)# network 198.133.219.0 mask 255.255.255.0

El comando router bgp habilita el BGP e identifica el número de AS para la empresa A. Un router sólo puede pertenecer a una sola AS, de modo que solo puede ejecutase un único proceso de BGP en un router.

El comando neighbor identifica el par de BGP y su número de AS. Observe que el AS del ISP es diferente que el número de AS de la empresa A. Esto le informa al proceso de BGP que el vecino está en un AS diferente y que, por lo tanto, se trata de un vecino de BGP externo.

La opción mask debe utilizarse cuando la red que se publica es diferente a su equivalente con clase. En este ejemplo, 198.133.219.0/24 es equivalente a una red Clase C. Las redes Clase C tienen una máscara de subred /24, así que, en este caso, la opción mask no se requiere.  Si el cliente A estuviera anunciando la red 198.133.0.0/16, sería necesaria la opción mask. De lo contrario, el protocolo BGP publicaría de red con una máscara /24 con clase.

El comando network introduce la dirección-red en la tabla local de BGP. La tabla de BGP contiene todas las rutas aprendidas a través del BGP o publicadas mediante el BGP. El eBGP luego publicará la dirección-red a sus vecinos de eBGP.

Nota: A diferencia de un protocolo IGP, la dirección-red utilizada en el comando network no tiene que ser una red conectada directamente. El router sólo necesita tener una ruta hacia esta red en su tabla de routing.

El ejemplo 2 muestra la configuración de BGP para el ISP-1.

Ejemplo 2: configuración del protocolo eBGP en el ISP-1

ISP-1(config)# router bgp 65001 ISP-1(config-router)# neighbor 209.165.201.2 remote-as 65000 ISP-1(config-router)# network 0.0.0.0

Los comandos de eBGP en el router ISP-1 son similares a la configuración en la empresa A. Observe cómo el comando network 0.0.0.0 de la red para anunciar una red predeterminada a la empresa A.

Nota: Si bien el comando network 0.0.0.0 es una opción de configuración válida de BGP, hay mejores maneras para anunciar una ruta predeterminada en el EBGP. Sin embargo, estos métodos están más allá del alcance de este curso.

Blogs relacionados 

Si te gusto este articulo comenta y comparte sigue en tu pagina Redes Five.

visitanos en nuestra pagina sobre sistemas operativos y mas Sistemastube.