Hispanopedia Wiki
Articulo de referencia

Protocolo de puerta de enlace fronteriza

{{cite web |title=History for rfc1105 |date=June 1989 |url=https://datatracker.ietf.org/doc/rfc1105/history/ |publisher=[[IETF]] |access-date=1 December 2023}} "},"based on":{"w...

Hispanopedia WikiContenido en espanolLectura gratuita

El Protocolo de puerta de enlace de frontera ( BGP ) es un protocolo de puerta de enlace exterior estandarizado diseñado para intercambiar información de enrutamiento y accesibilidad entre sistemas autónomos (AS) en Internet . [ 2 ] BGP se clasifica como un protocolo de enrutamiento de vector de ruta , [ 3 ] y toma decisiones de enrutamiento basadas en rutas, políticas de red o conjuntos de reglas configurados por un administrador de red .

El protocolo BGP utilizado para el enrutamiento dentro de un sistema autónomo se denomina Protocolo de puerta de enlace de borde interior ( iBGP ). En cambio, la aplicación de Internet de este protocolo se denomina Protocolo de puerta de enlace de borde exterior ( EBGP ).

Historia

En enero de 1989, en la 12.ª reunión del IETF en Austin, Texas , Yakov Rekhter , Len Bosack y Kirk Lougheed se reunieron para diseñar lo que finalmente se convertiría en el Protocolo de Puerta de Enlace Fronteriza (BGP). El diseño inicial del BGP se registró en dos servilletas, por lo que a menudo se le conoce como el «Protocolo de las Dos Servilletas». [ 4 ] El diseño de las servilletas se amplió a tres hojas de papel manuscritas a partir de las cuales se desarrolló rápidamente la primera implementación interoperable del BGP. Una fotocopia de estas tres hojas de papel cuelga ahora en la pared de un área de desarrollo de protocolos de enrutamiento en Cisco Systems en Milpitas, California . Ese mismo año, se publicó el RFC 1105 [ 5 ] , y el protocolo BGP (en varias formas) se ha utilizado en Internet desde 1994. [ 6 ] 

Medio año después de la publicación inicial, la definición del protocolo se modificó en 1990 con la publicación del RFC 1136 [ 7 ] . En octubre de 1991, la versión 3 de BGP se definió en el RFC 1267 [ 8 ] , dejando obsoletas las dos versiones anteriores. En 1994, la versión actual (BGP4) se publicó como RFC 1654 [ 9 ] . Su definición fue reemplazada en marzo de 1995 por el RFC 1771 [ 10 ] . En enero de 2006, se publicó el RFC 4271 [ 11 ] , que actualmente es la definición más reciente de BGP4 (aunque ha sido actualizada por muchos otros RFC).     

RFC 4271 corrigió errores, aclaró ambigüedades y actualizó la especificación con prácticas comunes de la industria. La principal mejora de BGP4 fue la compatibilidad con el enrutamiento entre dominios sin clases (CIDR) y el uso de agregación de rutas para reducir el tamaño de las tablas de enrutamiento . En su forma nativa, el protocolo BGP4 solo puede funcionar con direcciones IPv4. Desde la publicación de RFC 2283 [ 12 ] en 1998, se puede transportar información de enrutamiento sobre una amplia gama de "familias de direcciones" ( IPv4 , IPv6 , IPX , etc.). Las "Extensiones multiprotocolo" se actualizaron en 2000 con RFC 2858 [ 13 ] y finalmente en 2007 con RFC 4760 [ 14 ] . Con estas extensiones, el protocolo también se conoce como BGP multiprotocolo (MP-BGP).   

Operación

Los vecinos BGP, denominados pares, se establecen mediante configuración manual entre enrutadores para crear una sesión TCP en el puerto 179. Un enrutador BGP envía mensajes de mantenimiento de conexión de 19 bytes cada 30 segundos (valor predeterminado del protocolo, configurable) para mantener la conexión. [ 15 ] Entre los protocolos de enrutamiento, BGP es único por utilizar TCP como protocolo de transporte.

Cuando BGP se ejecuta entre dos pares en el mismo sistema autónomo (AS), se denomina BGP interno ( iBGP o Protocolo de puerta de enlace de borde interior ). Cuando se ejecuta entre sistemas autónomos diferentes, se denomina BGP externo ( eBGP o Protocolo de puerta de enlace de borde exterior ). Los enrutadores en el límite de un AS que intercambian información con otro AS se denominan enrutadores de borde o simplemente pares eBGP , y normalmente se conectan directamente, mientras que los pares iBGP pueden interconectarse a través de otros enrutadores intermedios. También son posibles otras topologías de implementación , como ejecutar el intercambio de pares eBGP dentro de un túnel VPN , lo que permite que dos sitios remotos intercambien información de enrutamiento de forma segura y aislada.

La principal diferencia entre el establecimiento de rutas mediante iBGP y eBGP radica en la forma en que las rutas recibidas de un par se propagan normalmente, por defecto, a otros pares:

  • Las nuevas rutas aprendidas de un par eBGP se vuelven a anunciar a todos los pares iBGP y eBGP.
  • Las nuevas rutas aprendidas de un par iBGP se vuelven a anunciar únicamente a todos los pares eBGP.

Estas reglas de propagación de rutas requieren, en la práctica, que todos los pares iBGP dentro de un sistema autónomo estén interconectados en una malla completa con sesiones iBGP.

La propagación de rutas se puede controlar en detalle mediante el mecanismo de mapas de ruta . Este mecanismo consta de un conjunto de reglas. Cada regla describe, para las rutas que cumplen ciertos criterios, la acción que se debe tomar. Esta acción podría consistir en descartar la ruta o en modificar algunos de sus atributos antes de insertarla en la tabla de enrutamiento.

Negociación de prórrogas

Durante el intercambio de mensajes OPEN, los hablantes BGP pueden negociar capacidades opcionales de la sesión, [ 16 ] incluyendo extensiones multiprotocolo [ 17 ] y varios modos de recuperación. Si las extensiones multiprotocolo para BGP se negocian en el momento de la creación, el hablante BGP puede anteponer a la información de accesibilidad de la capa de red (NLRI) que anuncia un prefijo de familia de direcciones. Estas familias incluyen IPv4 (predeterminado), IPv6, redes privadas virtuales IPv4/IPv6 y BGP multicast. Cada vez más, BGP se utiliza como un protocolo de señalización generalizado para transportar información sobre rutas que pueden no formar parte de Internet global, como las VPN. [ 18 ]

Para tomar decisiones en sus operaciones con pares, un par BGP utiliza una máquina de estados finitos (FSM) simple que consta de seis estados: Inactivo, Conectado, Activo, OpenSent, OpenConfirm y Establecido. Para cada sesión entre pares, una implementación BGP mantiene una variable de estado que indica en cuál de estos seis estados se encuentra la sesión. BGP define los mensajes que cada par debe intercambiar para cambiar la sesión de un estado a otro.

El primer estado es el estado Inactivo. En este estado, BGP inicializa todos los recursos, rechaza todos los intentos de conexión BGP entrantes e inicia una conexión TCP con el par. El segundo estado es Conectar. En el estado Conectar, el enrutador espera a que se complete la conexión TCP y, si tiene éxito, pasa al estado OpenSent. Si no tiene éxito, inicia el temporizador ConnectRetry y, al expirar, pasa al estado Activo. En el estado Activo, el enrutador reinicia el temporizador ConnectRetry a cero y regresa al estado Conectar. En el estado OpenSent, el enrutador envía un mensaje Open y espera una respuesta para pasar al estado OpenConfirm. Se intercambian mensajes Keepalive y, tras su correcta recepción, el enrutador pasa al estado Establecido. En el estado Establecido, el enrutador puede enviar y recibir mensajes Keepalive, Update y Notification desde y hacia su par.

  • Estado inactivo :
    • Rechazar todas las conexiones BGP entrantes.
    • Iniciar la inicialización de los disparadores de eventos.
    • Inicia una conexión TCP con su par BGP configurado.
    • Escucha una conexión TCP de su par.
    • Cambia su estado a Conectar.
    • Si se produce un error en cualquier etapa del proceso FSM, la sesión BGP finaliza inmediatamente y vuelve al estado inactivo. Algunas de las razones por las que un enrutador no pasa del estado inactivo son:
      • El puerto TCP 179 no está abierto.
      • Un puerto TCP aleatorio superior al 1023 no está abierto.
      • La dirección del par está configurada incorrectamente en cualquiera de los enrutadores.
      • El número de sistema autónomo (AS) está configurado incorrectamente en cualquiera de los enrutadores.
  • Estado de conexión :
    • Espera a que finalice con éxito la negociación TCP con el otro extremo.
    • BGP no permanece mucho tiempo en este estado si la sesión TCP se ha establecido correctamente.
    • Envía un mensaje abierto al otro extremo y cambia el estado a OpenSent.
    • Si se produce un error, BGP pasa al estado Activo. Algunas de las razones del error son:
      • El puerto TCP 179 no está abierto.
      • Un puerto TCP aleatorio superior al 1023 no está abierto.
      • La dirección del par está configurada incorrectamente en cualquiera de los enrutadores.
      • El número de sistema autónomo (AS) está configurado incorrectamente en cualquiera de los enrutadores.
  • Estado activo :
    • Si el enrutador no pudo establecer una sesión TCP exitosa, entonces pasa al estado Activo.
    • La máquina de estados finitos BGP intenta reiniciar otra sesión TCP con el par y, si tiene éxito, envía un mensaje Open al par.
    • Si vuelve a fallar, la máquina de estados finitos (FSM) se reinicia al estado inactivo.
    • Los fallos repetidos pueden provocar que un enrutador alterne entre los estados Inactivo y Activo. Algunas de las razones para ello son:
      • El puerto TCP 179 no está abierto.
      • Un puerto TCP aleatorio superior al 1023 no está abierto.
      • Error de configuración de BGP.
      • Congestión de la red .
      • Interfaz de red inestable.
  • Estado de OpenSent :
    • La máquina de estados finitos BGP (FSM) espera un mensaje de apertura de su par.
    • Una vez recibido el mensaje, el enrutador comprueba la validez del mensaje Open.
    • Si se produce un error, es porque alguno de los campos del mensaje Open no coincide entre los pares, por ejemplo, una discrepancia en la versión de BGP, que el enrutador de interconexión espera un My AS diferente, etc. En ese caso, el enrutador envía un mensaje de notificación al par indicando el motivo del error.
    • Si no hay ningún error, se envía un mensaje Keepalive, se configuran varios temporizadores y el estado cambia a OpenConfirm.
  • Estado de OpenConfirm :
    • El nodo está a la espera de un mensaje Keepalive de su par.
    • Si se recibe un mensaje Keepalive y no ha expirado ningún temporizador antes de la recepción de dicho mensaje, BGP pasa al estado Established.
    • Si un temporizador expira antes de que se reciba un mensaje Keepalive, o si se produce un error, el enrutador vuelve al estado Inactivo.
  • Estado establecido :
    • En este estado, los pares envían mensajes de actualización para intercambiar información sobre cada ruta que se anuncia al par BGP.
    • Si se produce algún error en el mensaje de actualización, se envía un mensaje de notificación al par y BGP vuelve al estado inactivo.

Conectividad del enrutador y rutas de aprendizaje

En la configuración más simple, todos los enrutadores dentro de un mismo sistema autónomo (AS) que participan en el enrutamiento BGP deben configurarse en una malla completa: cada enrutador debe configurarse como par con todos los demás. Esto genera problemas de escalabilidad, ya que el número de conexiones necesarias crece cuadráticamente con el número de enrutadores involucrados. Para mitigar este problema, BGP implementa dos opciones: reflectores de ruta (RFC 4456) y confederaciones BGP (RFC 5065). La siguiente descripción del procesamiento básico de actualizaciones asume una malla iBGP completa.

Un enrutador BGP determinado puede aceptar actualizaciones de información de accesibilidad de capa de red (NLRI) de múltiples vecinos y anunciar NLRI al mismo conjunto de vecinos, o a uno diferente. El proceso BGP mantiene varias bases de información de enrutamiento :

  • RIB: tabla base de información de enrutamiento principal de los enrutadores.
  • Loc-RIB: La base de información de enrutamiento local BGP mantiene su propia tabla de enrutamiento maestra separada de la tabla de enrutamiento principal del enrutador.
  • Adj-RIB-In: Para cada vecino, el proceso BGP mantiene una base de información de enrutamiento adyacente conceptual, incoming , que contiene el NLRI recibido del vecino.
  • Adj-RIB-Out: Para cada vecino, el proceso BGP mantiene una base de información de enrutamiento adyacente conceptual, saliente , que contiene el NLRI enviado al vecino.

El almacenamiento físico y la estructura de estas tablas conceptuales los decide el implementador del código BGP. Su estructura no es visible para otros enrutadores BGP, aunque normalmente se pueden consultar con comandos de administración en el enrutador local. Es bastante común, por ejemplo, almacenar la tabla de enrutamiento Adj-RIB-Iny Adj-RIB-Outla tabla de enrutamiento Loc-RIBjuntas en la misma estructura de datos , con información adicional adjunta a las entradas de la tabla de enrutamiento. La información adicional le indica al proceso BGP cosas como si las entradas individuales pertenecen a la tabla de Adj-RIBsenrutamiento para vecinos específicos, si el proceso de selección de ruta entre pares hizo que las políticas recibidas fueran elegibles para la tabla de enrutamiento Loc-RIB, y si Loc-RIBlas entradas son elegibles para ser enviadas al proceso de administración de la tabla de enrutamiento del enrutador local.

BGP envía las rutas que considera óptimas al proceso principal de la tabla de enrutamiento. Dependiendo de la implementación de dicho proceso, la ruta BGP no siempre se selecciona. Por ejemplo, un prefijo conectado directamente, aprendido del propio hardware del enrutador, suele ser el preferido. Mientras la interfaz de esa ruta conectada directamente esté activa, la ruta BGP hacia el destino no se añadirá a la tabla de enrutamiento. Una vez que la interfaz se desactiva y no hay más rutas preferidas, la ruta Loc-RIB se instalará en la tabla de enrutamiento principal.

BGP transporta la información con la que las reglas dentro de los enrutadores que utilizan BGP pueden tomar decisiones de política. Parte de la información transportada que está explícitamente destinada a ser utilizada en decisiones de política es:

Proceso de selección de ruta

El estándar BGP especifica varios factores de decisión, más que cualquier otro proceso de enrutamiento común, para seleccionar los NLRI que se incluirán en la Loc-RIB. El primer criterio para evaluar un NLRI es que su atributo de siguiente salto debe ser alcanzable (o resoluble). En otras palabras, debe existir una ruta activa, ya presente en la tabla de enrutamiento principal del enrutador, hacia el prefijo en el que la dirección del siguiente salto sea alcanzable.

A continuación, para cada vecino, el proceso BGP aplica diversos criterios estándar y específicos de la implementación para decidir qué rutas deben incluirse en la tabla de enrutamiento de adyacencia (Adj-RIB-In). El vecino puede enviar varias rutas posibles a un destino, pero la primera prioridad se establece a nivel de vecino. Solo se instalará una ruta a cada destino en la Adj-RIB-In conceptual. Este proceso también eliminará de la Adj-RIB-In las rutas que el vecino retire.

Cuando cambia un Adj-RIB-In conceptual, el proceso principal de BGP decide si alguna de las nuevas rutas del vecino tiene preferencia sobre las rutas que ya se encuentran en el Loc-RIB. De ser así, las reemplaza. Si un vecino retira una ruta y no existe otra ruta hacia ese destino, la ruta se elimina del Loc-RIB y BGP deja de enviarla al gestor principal de la tabla de enrutamiento. Si el enrutador no tiene una ruta hacia ese destino desde ninguna fuente que no sea BGP, la ruta retirada se eliminará de la tabla de enrutamiento principal.

Mientras persista el empate , el proceso de selección de ruta pasa al siguiente paso.

La preferencia local, el peso y otros criterios pueden ser manipulados por la configuración local y las capacidades del software. Dicha manipulación, aunque de uso común, está fuera del alcance del estándar. Por ejemplo, el atributo de comunidad (véase más abajo) no se utiliza directamente en el proceso de selección de BGP. El proceso de vecino BGP puede tener una regla para establecer la preferencia local u otro factor basado en una regla programada manualmente para establecer el atributo si el valor de la comunidad coincide con algún criterio de coincidencia de patrones. Si la ruta se aprendió de un par externo, el proceso BGP por vecino calcula un valor de preferencia local a partir de las reglas de política local y luego compara la preferencia local de todas las rutas del vecino.

Comunidades

Las comunidades BGP son etiquetas de atributos que se pueden aplicar a prefijos entrantes o salientes para lograr un objetivo común. [ 21 ] Si bien es común decir que BGP permite a un administrador establecer políticas sobre cómo los ISP manejan los prefijos, esto generalmente no es posible, estrictamente hablando. Por ejemplo, BGP de forma nativa no tiene un concepto que permita que un AS le diga a otro AS que restrinja la publicidad de un prefijo solo a clientes de interconexión norteamericanos. En cambio, un ISP generalmente publica una lista de comunidades conocidas o propietarias con una descripción para cada una, lo que esencialmente se convierte en un acuerdo sobre cómo se deben tratar los prefijos.

Algunos ejemplos de comunidades comunes son:

Un ISP podría indicar que cualquier ruta recibida de los clientes con los siguientes ejemplos:

  • Para clientes de Norteamérica (Costa Este) 3491:100
  • Para clientes de Norteamérica (Costa Oeste) 3491:200

El cliente simplemente ajusta su configuración para incluir la comunidad o comunidades correctas para cada ruta, y el ISP es responsable de controlar a quién se anuncia el prefijo. El usuario final no tiene capacidad técnica para garantizar que el ISP siga las acciones correctas, aunque los problemas en este ámbito suelen ser raros y accidentales. [ 23 ] [ 24 ]

Es una táctica común que los clientes finales utilicen comunidades BGP (normalmente ASN:70,80,90,100) para controlar la preferencia local que el ISP asigna a las rutas anunciadas, en lugar de utilizar MED (el efecto es similar). El atributo de comunidad es transitivo, pero las comunidades aplicadas por el cliente rara vez se propagan fuera del siguiente AS. No todos los ISP divulgan sus comunidades al público. [ 25 ]

Atributo de comunidad extendida BGP

El atributo de comunidad extendida BGP se añadió en 2006, [ 26 ] con el fin de ampliar el rango de dichos atributos y proporcionar una estructuración de atributos de comunidad mediante un campo de tipo. El formato extendido consta de uno o dos octetos para el campo de tipo, seguidos de siete o seis octetos para el contenido del atributo de comunidad correspondiente. La IANA administra el registro de tipos de comunidades extendidas BGP. [ 27 ]

El atributo Comunidades Extendidas es un atributo BGP transitivo y opcional. Un bit en el campo Tipo dentro del atributo determina si la comunidad extendida codificada es transitiva o no transitiva. Por lo tanto, el registro IANA proporciona diferentes rangos de números para los tipos de atributos. Debido a la amplitud del rango de atributos, su uso puede ser muy variado. El RFC 4360 define, a modo de ejemplo, la "Comunidad Extendida Específica de AS de Dos Octetos", la "Comunidad Extendida Específica de Dirección IPv4", la "Comunidad Extendida Opaca", la "Comunidad de Destino de Ruta" y la "Comunidad de Origen de Ruta". Varios borradores de QoS de BGP también utilizan esta estructura de atributo Comunidad Extendida para la señalización de QoS entre dominios. [ 28 ]

Con la introducción de los números AS de 32 bits, algunos problemas se hicieron evidentes de inmediato con el atributo de comunidad que solo define un campo ASN de 16 bits, lo que impide la coincidencia entre este campo y el valor ASN real. Desde 2014, las comunidades extendidas son compatibles con los ASN de 32 bits. [ 29 ] Para acomodar los números AS de 32 bits en las comunidades BGP, se definió un atributo de Comunidad Grande de 12 bytes, [ 30 ] [ 31 ] dividido en tres campos de 4 bytes cada uno (AS:función:parámetro). [ 32 ]

Discriminadores de múltiples salidas

Los MED, definidos en el estándar principal de BGP, tenían como objetivo mostrar a otro AS vecino la preferencia del AS anunciante respecto a cuál de varios enlaces se prefiere para el tráfico entrante. Otra aplicación de los MED es anunciar el valor, generalmente basado en el retardo, que varios AS presentes en un IXP imponen para enviar tráfico a un destino determinado.

Algunos enrutadores (como Juniper) utilizarán la métrica de OSPF para configurar MED.

Ejemplos de MED utilizado con BGP al exportarlo a BGP en Juniper SRX

# ejecutar show ospf route Topología predeterminada Tabla de rutas: Prefijo Ruta Ruta NH Métrica Siguiente salto Siguiente salto  Tipo Tipo Tipo Interfaz Dirección/LSP 10.32.37.0/24 Inter Descartar IP 16777215 10.32.37.0/26 Intra Red IP 101 ge-0/0/1.0 10.32.37.241 10.32.37.64/26 Intra Red IP 102 ge-0/0/1.0 10.32.37.241 10.32.37.128/26 Intra Red IP 101 ge-0/0/1.0 10.32.37.241# mostrar ruta advertising-protocol bgp 10 .32.94.169  Prefijo Siguiente salto MED Lclpref Ruta AS * 10.32.37.0/24 Self 16777215 I * 10.32.37.0/26 Self 101 I * 10.32.37.64/26 Self 102 I * 10.32.37.128/26 Self 101 I

Formato del paquete

Formato del encabezado del mensaje

Todos los mensajes BGP comparten el siguiente formato de encabezado.

Marcador : 128 bits
Incluido por compatibilidad, DEBE configurarse a todos los valores en uno.
Longitud : 16 bits
Longitud total del mensaje en octetos, incluyendo la cabecera.
Tipo : 8 bits
Tipo de mensaje BGP. Se definen los siguientes valores:
  • Abierto (1)
  • Actualización (2)
  • Notificación (3)
  • Mantener vivo (4)
  • Actualización de ruta (5)

Paquete abierto

Con un paquete abierto , se puede iniciar una sesión BGP.

Versión : 8 bits
Versión de BGP utilizada.
Mi AS : 16 bits
Número del sistema autónomo del remitente .
Tiempo de retención : 16 bits
Temporizador de tiempo de espera, utilizado para calcular los mensajes KeepAlive. Valor predeterminado: 90 segundos.
Identificador BGP : 32 bits
Contiene la dirección IP del remitente.
Longitud de los parámetros : 8 bits
Longitud total del campo Parámetros en octetos. Si este campo (obligatorio) [ 11 ] : §4.2 es cero, no hay parámetros en el mensaje.
Parámetros : variable
Parámetros opcionales. Este campo se utiliza para comunicar las capacidades que el remitente de este paquete tiene al par. [ 33 ] IANA mantiene una lista de todas las capacidades .

Ejemplo de mensaje abierto

Tipo: Mensaje abierto (1) Versión: 4 Mi AS: 64496 Tiempo de espera: 90 Identificador BGP: 192.0.2.254 Longitud de los parámetros opcionales: 16 Parámetros opcionales: Capacidad: Capacidad de extensiones multiprotocolo (1) Capacidad: Capacidad de actualización de ruta (2) Capacidad: Capacidad mejorada de actualización de ruta (70)

Paquete de actualización

Solo se envían los cambios. Después del intercambio inicial, solo se envían las diferencias (agregar/cambiar/eliminar).

Longitud de las rutas retiradas : 16 bits
Longitud de las siguientes rutas retiradas. Puede ser cero si no se retira ninguna ruta.
Rutas retiradas : variable
Una lista de rutas retiradas, especificadas como una serie de tuplas <longitud, prefijo> .
Longitud total del atributo de ruta : 16 bits
Longitud de los siguientes atributos de ruta. Puede ser cero si no hay atributos.
Atributos de ruta : variable
Lista de atributos de ruta, especificados como una serie de estructuras TLV .
Información de accesibilidad de la capa de red  (NLRI) : variable
Información de accesibilidad, especificada como una serie de tuplas <longitud, prefijo>. La longitud de este campo se puede calcular como: Longitud - 23 - Longitud de rutas retiradas - Longitud total del atributo de ruta .

Ejemplo de mensaje de ACTUALIZACIÓN

Tipo: Mensaje de ACTUALIZACIÓN (2) Longitud de las rutas retiradas: 0 Longitud total del atributo de ruta: 25 Atributos de ruta ORIGEN: IGP AS_PATH: 64500 SIGUIENTE SALTO: 192.0.2.254 DISCO DE SALIDA MÚLTIPLE: 0 Información de accesibilidad de la capa de red (NLRI) 192.0.2.0/27 192.0.2.32/27 192.0.2.64/27

Notificación

Si se produce un error, es porque uno de los campos del mensaje OPEN o UPDATE no coincide entre los pares. Por ejemplo: discrepancia en la versión de BGP, o el enrutador de interconexión espera un 'My AS' diferente. El enrutador envía entonces un mensaje de notificación al par indicando el motivo del error. Un error en la comunicación suele provocar la finalización de la sesión BGP. Para evitar que se produzca una cascada de sesiones terminadas debido a un único error, lo que puede ocurrir en escenarios complejos con enrutadores de capacidades limitadas, se realizan esfuerzos adicionales para aislar el problema y mantener la mayoría de las sesiones activas. [ 34 ]

Código de error : 8 bits
Un valor que indica el tipo o el origen del error.
Subcódigo de error : 8 bits
Un valor que especifica qué error se produjo.
Datos : variable
Datos opcionales para ayudar a diagnosticar el problema.

Ejemplo de mensaje de NOTIFICACIÓN

Tipo: Mensaje de NOTIFICACIÓN (3) Código de error principal: OPEN Mensaje de error (2) Código de error menor (mensaje abierto): Par AS incorrecto (2) Par defectuoso AS: 65200

Mantenerse vivo

Los mensajes KeepAlive son enviados periódicamente por ambos pares de una sesión para verificar que el par remoto sigue activo. Deben enviarse a intervalos de un tercio del tiempo holdtime.

Un paquete keep-alive no contiene datos.

Actualización de ruta

Una adición a los tipos de mensajes BGP iniciales es route-refresh, que permite una actualización suave de Adj-RIB-in, sin restablecer la conexión. [ 35 ]

Antes de utilizar esta función, debe especificarse la capacidad «Actualización de ruta (2)» en el mensaje «Abrir». Se pueden obtener actualizaciones de enrutamiento más precisas si también se especifica la capacidad «Actualización de ruta mejorada (70)».

Identificador de familia de direcciones  (AFI) : 16 bits
Un identificador para la familia de direcciones ( IPv4 , IPv6 , IPX , AppleTalk , etc.). Esta lista es mantenida por IANA .
Subtipo de mensaje : 8 bits
Este campo indica qué tipo de mensaje de actualización de ruta es este. [ 36 ]
Identificador de familia de direcciones subsiguiente : 8 bits
Este campo proporciona información adicional sobre el tipo de información de accesibilidad de la capa de red (NLRI) que contiene el atributo. Valores: 1 (unicast); 2 (multicast); 3 (ambos).
Información de accesibilidad de la capa de red  (NLRI) : variable
Información de accesibilidad, especificada como una serie de tuplas <longitud, prefijo>.

Ejemplo de mensaje ROUTE-REFRESH

Tipo: Mensaje ROUTE-REFRESH (5) Identificador de familia de direcciones (AFI): IPv4 (1) Subtipo: Solicitud de actualización de ruta normal (0) Identificador de familia de direcciones subsiguiente (SAFI): Unicast (1)

Escalabilidad interna

BGP es "el protocolo de enrutamiento más escalable de todos". [ 37 ]

Un sistema autónomo con BGP interno (iBGP) requiere que todos sus pares iBGP se conecten entre sí en una malla completa (donde todos se comunican directamente con todos). Esta configuración de malla completa exige que cada enrutador mantenga una sesión con todos los demás. En redes grandes, este número de sesiones puede degradar el rendimiento de los enrutadores, ya sea por falta de memoria o por altos requisitos de procesamiento de la CPU.

reflectores de ruta

Los reflectores de ruta (RR) reducen el número de conexiones necesarias en un sistema autónomo (AS). Un único enrutador (o dos para redundancia) puede funcionar como RR: los demás enrutadores del AS solo necesitan configurarse como pares. Un RR ofrece una alternativa al requisito lógico de malla completa de iBGP. El objetivo del RR es la concentración. Varios enrutadores BGP pueden establecer conexiones con un punto central, el RR ( que actúa como servidor RR ), en lugar de establecer conexiones con todos los demás enrutadores en una malla completa. Todos los demás enrutadores iBGP se convierten en clientes RR. [ 38 ]  

Este enfoque, similar a la función DR/BDR de OSPF , proporciona a las grandes redes una mayor escalabilidad para iBGP. En una red iBGP totalmente mallada de 10 enrutadores, se necesitan 90 instrucciones CLI individuales (distribuidas entre todos los enrutadores de la topología) solo para definir el AS remoto de cada par: esto se convierte rápidamente en un quebradero de cabeza para su gestión. Una topología RR puede reducir estas 90 instrucciones a 18, ofreciendo una solución viable para las grandes redes administradas por los ISP.

Un RR es un punto único de fallo , por lo que se puede configurar al menos un segundo RR para proporcionar redundancia. Al ser un par adicional para los otros 10 enrutadores, duplica aproximadamente el número de instrucciones CLI, requiriendo 11 × 2 − 2 = 20 instrucciones adicionales en este caso. En un entorno BGP multipath, el RR adicional también puede beneficiar a la red al aumentar el rendimiento del enrutamiento local si los RR actúan como enrutadores tradicionales en lugar de simplemente como un servidor RR dedicado.

Tanto los RR como las confederaciones reducen el número de pares iBGP para cada enrutador y, por lo tanto, disminuyen la sobrecarga de procesamiento. Los RR son una técnica que optimiza el rendimiento, mientras que las confederaciones también pueden utilizarse para implementar políticas más específicas.

Normas

Una configuración típica de una implementación de BGP RR. [ 39 ] : §6

Los servidores RR propagan las rutas dentro del AS basándose en las siguientes reglas:

  • Las rutas siempre se reflejan a los pares eBGP.
  • Las rutas nunca se reflejan en el origen de la ruta.
  • Si se recibe una ruta de un par que no es cliente, se debe reflejar a los pares cliente.
  • Si se recibe una ruta de un par cliente, se debe reflejar tanto a los pares cliente como a los que no lo son.

Grupo

Un enrutador de recursos (RR) y sus clientes forman un clúster . El ID del clúster se adjunta a cada ruta que el RR anuncia a sus pares, ya sean clientes o no clientes. El ID del clúster es un atributo BGP acumulativo y no transitivo, y cada RR debe anteponer el ID del clúster local a la lista de clústeres para evitar bucles de enrutamiento.

Confederación

Las confederaciones son conjuntos de sistemas autónomos. En la práctica común, [ 40 ] solo uno de los números de AS de la confederación es visible para Internet en su conjunto. Las confederaciones se utilizan en redes muy grandes donde un AS grande puede configurarse para abarcar AS internos más pequeños y manejables.

El sistema autónomo (AS) confederado está compuesto por múltiples sistemas autónomos. Cada AS confederado, por sí solo, cuenta con iBGP completamente mallado y conexiones con otros AS dentro de la confederación. Aunque estos AS tienen pares eBGP con otros AS dentro de la confederación, intercambian enrutamiento como si utilizaran iBGP. De esta forma, la confederación conserva la información de siguiente salto, métrica y preferencia local. Para el mundo exterior, la confederación se presenta como un único AS. Con esta solución, se pueden resolver los problemas de tránsito de AS de iBGP, ya que iBGP requiere una malla completa entre todos los enrutadores BGP: un gran número de sesiones TCP y una duplicación innecesaria del tráfico de enrutamiento.

Las confederaciones pueden utilizarse junto con reflectores de ruta. Tanto las confederaciones como los reflectores de ruta pueden estar sujetos a oscilaciones persistentes a menos que se sigan reglas de diseño específicas que afectan tanto a BGP como al protocolo de enrutamiento interno. [ 41 ]

Estas alternativas pueden generar sus propios problemas, entre ellos los siguientes:

  • oscilación de ruta
  • enrutamiento subóptimo
  • aumento del tiempo de convergencia de BGP [ 42 ]

Además, los reflectores de ruta y las confederaciones BGP no se diseñaron para facilitar la configuración de los enrutadores BGP. Sin embargo, son herramientas comunes para los arquitectos de redes BGP experimentados. Estas herramientas se pueden combinar, por ejemplo, en una jerarquía de reflectores de ruta.

Estabilidad

Las tablas de enrutamiento gestionadas por una implementación BGP se ajustan continuamente para reflejar los cambios reales en la red, como la caída y reactivación de enlaces o enrutadores. En la red en su conjunto, es normal que estos cambios ocurran casi continuamente, pero para un enrutador o enlace en particular, se espera que sean relativamente infrecuentes. Si un enrutador está mal configurado o gestionado, puede entrar en un ciclo rápido entre estados de inactividad y actividad. Este patrón de retirada y reanuncia repetida, conocido como fluctuación de ruta , puede causar una actividad excesiva en todos los demás enrutadores que conocen la entidad en ciclo, ya que la misma ruta se inyecta y retira continuamente de las tablas de enrutamiento. El diseño de BGP es tal que la entrega de tráfico puede no funcionar mientras se actualizan las rutas. En Internet, un cambio de enrutamiento BGP puede causar interrupciones durante varios minutos.

Una característica conocida como amortiguación de fluctuaciones de ruta está integrada en muchas implementaciones de BGP, [ 43 ] en un intento de mitigar los efectos de las fluctuaciones de ruta. Sin amortiguación, la actividad excesiva puede causar una carga de procesamiento pesada en los enrutadores, lo que a su vez puede retrasar las actualizaciones en otras rutas y, por lo tanto, afectar la estabilidad general del enrutamiento. Con la amortiguación, la fluctuación de una ruta se decae exponencialmente . En el primer caso, cuando una ruta deja de estar disponible y reaparece rápidamente, la amortiguación no surte efecto, para mantener los tiempos de conmutación por error normales de BGP. En el segundo caso, BGP rechaza ese prefijo durante un cierto período de tiempo; los casos posteriores se ignoran exponencialmente más largos. Después de que las anomalías hayan cesado y haya transcurrido un período de tiempo adecuado para la ruta problemática, los prefijos se pueden restablecer con un nuevo comienzo. La amortiguación también puede mitigar los ataques de denegación de servicio .

También se sugiere que la amortiguación de fluctuaciones de ruta es una característica más deseable si se implementa en sesiones de protocolo de puerta de enlace de borde exterior (sesiones eBGP o simplemente pares externos) y no en sesiones de protocolo de puerta de enlace de borde interior (sesiones iBGP o simplemente pares internos). [ 43 ] : §4 Con este enfoque, cuando una ruta fluctúa dentro de un sistema autónomo, no se propaga a los AS externos ; la fluctuación de una ruta a un eBGP causará una cadena de fluctuaciones para esa ruta en particular a lo largo de la red troncal. Este método también evita con éxito la sobrecarga de la amortiguación de fluctuaciones de ruta para las sesiones iBGP. 

Investigaciones posteriores han demostrado que la amortiguación de flaps puede, en algunos casos, alargar los tiempos de convergencia y provocar interrupciones en la conectividad incluso cuando los enlaces no presentan flaps. [ 44 ] [ 45 ] Además, dado que los enlaces troncales y los procesadores de enrutadores se han vuelto más rápidos, algunos arquitectos de redes han sugerido que la amortiguación de flaps podría no ser tan importante como antes, ya que los enrutadores pueden gestionar los cambios en la tabla de enrutamiento mucho más rápido. [ 43 ] Esto ha llevado al Grupo de Trabajo de Enrutamiento de RIPE a escribir: «Con las implementaciones actuales de la amortiguación de flaps de BGP, no se recomienda su aplicación en redes de ISP. Si se implementa la amortiguación de flaps, el ISP que opera esa red causará efectos secundarios a sus clientes y a los usuarios de Internet del contenido y los servicios de sus clientes. Estos efectos secundarios probablemente serían peores que el impacto causado por simplemente no ejecutar la amortiguación de flaps en absoluto». [ 46 ]

Crecimiento de la tabla de enrutamiento

Crecimiento de la tabla BGP en Internet
Número de AS en Internet frente al número de AS registrados

Uno de los mayores problemas a los que se enfrenta BGP, y de hecho la infraestructura de Internet en su conjunto, es el crecimiento de la tabla de enrutamiento de Internet. Si la tabla de enrutamiento global crece hasta el punto en que algunos enrutadores más antiguos y menos potentes no pueden gestionar los requisitos de memoria o la carga de CPU necesarios para mantenerla, dejarán de ser puertas de enlace eficaces entre las partes de Internet que conectan. Además, y quizás aún más importante, las tablas de enrutamiento más grandes tardan más en estabilizarse tras un cambio importante en la conectividad, lo que provoca que el servicio de red sea poco fiable, o incluso inaccesible, durante ese período.

Hasta finales de 2001, la tabla de enrutamiento global crecía exponencialmente , amenazando con una eventual interrupción generalizada de la conectividad. Para evitarlo, los proveedores de servicios de Internet (ISP) colaboraron para mantener la tabla de enrutamiento global lo más pequeña posible mediante el uso de enrutamiento entre dominios sin clases (CIDR) y la agregación de rutas . Si bien esto ralentizó el crecimiento de la tabla de enrutamiento a un proceso lineal durante varios años, con la creciente demanda de multihoming por parte de las redes de usuarios finales, el crecimiento volvió a ser superlineal a mediados de 2004.

512.000 días

En 2014 se produjo un desbordamiento similar al del problema del año 2000 en aquellos modelos que no se habían actualizado correctamente.

Si bien una tabla BGP IPv4 completa a partir de agosto de 2014(512k día) [ 47 ] [ 48 ] era más de 512 000 prefijos, [ 49 ] muchos enrutadores antiguos tenían un límite de 512k (512 000–524 288) [ 50 ] [ 51 ] entradas de la tabla de enrutamiento. El 12 de agosto de 2014, las interrupciones resultantes de tablas llenas afectaron a eBay , LastPass y Microsoft Azure , entre otros. [ 52 ] Varios enrutadores Cisco de uso común tenían TCAM , una forma de memoria direccionable por contenido de alta velocidad , para almacenar rutas anunciadas por BGP. En los enrutadores afectados, la TCAM se asignaba por defecto como 512k rutas IPv4 y 256k rutas IPv6. Si bien el número de rutas IPv6 anunciadas reportadas fue de solo alrededor de 20 000, el número de rutas IPv4 anunciadas alcanzó el límite predeterminado, lo que provocó un efecto de desbordamiento , ya que los enrutadores intentaron compensar el problema utilizando enrutamiento por software lento (en lugar de enrutamiento por hardware rápido a través de TCAM). El método principal para abordar este problema implica que los operadores cambien la asignación de TCAM para permitir más entradas IPv4 reasignando parte de la TCAM reservada para rutas IPv6, lo que requiere reiniciar la mayoría de los enrutadores. El problema de los 512 000 fue predicho por varios profesionales de TI. [ 53 ] [ 54 ] [ 55 ]

Las asignaciones reales, que impulsaron el número de rutas por encima de 512 000, fueron el anuncio de aproximadamente 15 000 nuevas rutas en un corto período de tiempo, a partir de las 07:48 UTC. Casi todas estas rutas apuntaban a los sistemas autónomos 701 y 705 de Verizon , creados como resultado de la desagregación de bloques más grandes, introduciendo miles de nuevas rutas / 24 y haciendo que la tabla de enrutamiento alcanzara las 515 000 entradas. Las nuevas rutas parecen haberse reagregado en 5 minutos, pero la inestabilidad en Internet aparentemente continuó durante varias horas. [ 56 ] Incluso si Verizon no hubiera provocado que la tabla de enrutamiento superara las 512 000 entradas en el breve pico, esto habría ocurrido pronto debido al crecimiento natural.

La agregación de rutas se utiliza a menudo para mejorar la agregación de la tabla de enrutamiento global BGP, reduciendo así el tamaño necesario de la tabla en los enrutadores de un sistema autónomo (AS). Supongamos que al AS1 se le ha asignado el gran espacio de direcciones 172.16.0.0 / 16 , que se contaría como una ruta en la tabla, pero debido a los requisitos del cliente o a fines de ingeniería de tráfico, el AS1 quiere anunciar rutas más pequeñas y específicas: 172.16.0.0 / 18 , 172.16.64.0 / 18 y 172.16.128.0 / 18. El prefijo 172.16.192.0 / 18 no tiene ningún host, por lo que el AS1 no anuncia una ruta específica 172.16.192.0 / 18. Todo esto cuenta como que el AS1 anuncia cuatro rutas.

AS2 verá las cuatro rutas de AS1 ( 172.16.0.0/16 , 172.16.0.0/18 , 172.16.64.0/18 y 172.16.128.0/18 ) y depende de la política de enrutamiento de AS2 decidir si toma o no una copia de las cuatro rutas o, dado que 172.16.0.0/16 se superpone a todas las demás rutas específicas, simplemente almacena el resumen , 172.16.0.0/16 .

Si AS2 quiere enviar datos al prefijo 172.16.192.0 / 18 , se enviarán a los enrutadores de AS1 en la ruta 172.16.0.0 / 16. En AS1, se descartarán o se devolverá un mensaje ICMP de destino inalcanzable, según la configuración de los enrutadores de AS1.

Si AS1 decide posteriormente eliminar la ruta 172.16.0.0 / 16 , dejando 172.16.0.0 / 18 , 172.16.64.0 / 18 y 172.16.128.0 / 18 , el número de rutas que anuncia AS1 se reduce a tres. Dependiendo de la política de enrutamiento de AS2, almacenará una copia de las tres rutas, o agregará 172.16.0.0 / 18 y 172.16.64.0 / 18 a 172.16.0.0 / 17 , reduciendo así el número de rutas que almacena AS2 a dos ( 172.16.0.0 / 17 y 172.16.128.0 / 18 ).

Si AS2 ahora quiere enviar datos al prefijo 172.16.192.0 / 18 , se descartarán o se enviará un mensaje ICMP de destino inalcanzable a los enrutadores de AS2 (no a AS1 como antes), porque 172.16.192.0 / 18 no está en la tabla de enrutamiento.

Agotamiento del número AS y ASN de 32 bits

En 1995, la primera especificación BGP-4 codificó los números AS en 16 bits, [ 10 ] para 64 510 posibles números AS públicos. [ a ] ​​En 2011, solo quedaban disponibles 15 000 números AS, y las proyecciones [ 57 ] preveían un agotamiento total de los números AS disponibles en septiembre de 2013.

Ya en 2007, la codificación AS se extendió de 16 a 32 bits, [ 58 ] mientras se conservaba el rango AS de 16 bits (0 a 65535) y sus números AS reservados. Esto ahora permite hasta 4 mil millones de números AS disponibles. También se define un rango AS privado adicional. [ 59 ] [ b ] Para permitir el recorrido de grupos de enrutadores que no pueden administrar esos nuevos ASN, se utiliza el nuevo atributo AS4_PATH (transitivo opcional) y el ASN especial de 16 bits AS_TRANS (AS23456). [ 61 ] Las asignaciones de ASN de 32 bits comenzaron en 2007.

Balanceo de carga

Otro factor que contribuye al crecimiento de la tabla de enrutamiento es la necesidad de balanceo de carga en redes con múltiples conexiones . No es tarea sencilla equilibrar el tráfico entrante a una red con múltiples conexiones a través de sus múltiples rutas de entrada, debido a las limitaciones del proceso de selección de rutas BGP. En una red con múltiples conexiones, si anuncia los mismos bloques de red a todos sus pares BGP, es posible que uno o varios de sus enlaces entrantes se congestionen mientras que los demás permanezcan infrautilizados, ya que las redes externas seleccionaron ese conjunto de rutas congestionadas como óptimas. Al igual que la mayoría de los protocolos de enrutamiento, BGP no detecta la congestión.

Para solucionar este problema, los administradores BGP de esa red multihomed pueden dividir un gran bloque de direcciones IP contiguas en bloques más pequeños y ajustar el anuncio de ruta para que diferentes bloques parezcan óptimos en diferentes rutas, de modo que las redes externas elijan una ruta diferente para alcanzar distintos bloques de esa red multihomed. En estos casos, aumentará el número de rutas que se muestran en la tabla BGP global.

Un método para solucionar el problema de la tabla de enrutamiento asociado al balanceo de carga consiste en implementar pasarelas BGP/LISP ( Locator/Identifier Separation Protocol ) en un punto de intercambio de Internet para permitir la ingeniería de tráfico de entrada a través de múltiples enlaces. Esta técnica no aumenta el número de rutas visibles en la tabla BGP global.

Seguridad

Por diseño, los enrutadores que ejecutan BGP aceptan rutas anunciadas por otros enrutadores BGP de forma predeterminada. Esto permite el enrutamiento automático y descentralizado del tráfico a través de Internet, pero también deja a Internet potencialmente vulnerable a interrupciones accidentales o maliciosas, conocidas como secuestro de BGP . Debido al grado de integración de BGP en los sistemas centrales de Internet y a la cantidad de redes diferentes operadas por diversas organizaciones que conforman Internet, corregir esta vulnerabilidad (por ejemplo, mediante la introducción del uso de claves criptográficas para verificar la identidad de los enrutadores BGP) es un problema técnica y económicamente complejo. [ 62 ]

Extensiones

Las extensiones multiprotocolo para BGP (MBGP), también conocidas como BGP multiprotocolo o BGP multidifusión y definidas en la RFC 4760 , son una extensión de BGP que permite distribuir en paralelo diferentes tipos de direcciones (conocidas como familias de direcciones). Mientras que el BGP estándar solo admite direcciones unicast IPv4, el BGP multiprotocolo admite direcciones IPv4 e IPv6, así como variantes unicast y multicast de cada una. El BGP multiprotocolo permite intercambiar información sobre la topología de los enrutadores IP con capacidad multidifusión de forma independiente de la topología de los enrutadores unicast IPv4 normales. De este modo, permite una topología de enrutamiento multicast distinta de la topología de enrutamiento unicast. Si bien MBGP permite el intercambio de información de enrutamiento multicast entre dominios, se necesitan otros protocolos, como la familia Protocol Independent Multicast, para construir árboles y reenviar el tráfico multicast. El protocolo BGP multiprotocolo también se utiliza ampliamente en el caso de las VPN MPLS L3 para intercambiar etiquetas VPN aprendidas para las rutas desde los sitios de los clientes a través de la red MPLS, con el fin de distinguir entre diferentes sitios de clientes cuando el tráfico de otros sitios de clientes llega al enrutador de borde del proveedor para su enrutamiento. 

Otra extensión de BGP es el enrutamiento multipath . Normalmente, esto requiere que el MED, el peso, el origen y la ruta AS sean idénticos, aunque algunas implementaciones permiten flexibilizar la comprobación de la ruta AS para que solo se espere una longitud de ruta igual en lugar de que los números AS reales de la ruta coincidan. Esto se puede ampliar aún más con funciones como dmzlink-bw de Cisco, que permite una proporción de compartición de tráfico basada en los valores de ancho de banda configurados en los enlaces individuales.

Por defecto, BGP solo admite el anuncio de una única ruta óptima seleccionada localmente a sus vecinos mediante sus mensajes Update. El RFC 7911 define la extensión ADD-PATH , que permite a un dispositivo BGP anunciar múltiples rutas para el mismo destino a sus pares. Una aplicación de esto se da al usar reflectores de ruta (RR), ya que el RR puede anunciar todas las rutas conocidas a sus clientes, en lugar de enviar solo una ruta seleccionada en función de su proceso de decisión local, que probablemente no sea la mejor ruta para todos sus clientes. 

Usos

BGP4 es el estándar para el enrutamiento de Internet y la mayoría de los proveedores de servicios de Internet (ISP) lo requieren para establecer rutas entre sí. Las redes IP privadas de gran tamaño utilizan BGP internamente. Un ejemplo de uso es la unión de varias redes OSPF ( Open Shortest Path First ) de gran tamaño cuando OSPF por sí solo no alcanza la escala necesaria. Otra razón para usar BGP es la multiconexión de una red para una mayor redundancia, ya sea a múltiples puntos de acceso a un único ISP o a varios ISP.

Implementaciones

Los routers, especialmente los pequeños destinados a oficinas pequeñas o domésticas (SOHO), pueden no incluir compatibilidad con BGP. Otros routers comerciales pueden requerir una imagen ejecutable de software específica compatible con BGP o una licencia que lo habilite. Los dispositivos comercializados como conmutadores de capa 3 tienen menos probabilidades de ser compatibles con BGP que los comercializados como routers , pero muchos conmutadores de capa 3 de gama alta pueden ejecutar BGP.

Los productos comercializados como conmutadores pueden tener una limitación de tamaño en las tablas BGP mucho menor que la de una tabla de Internet completa más las rutas internas. Estos dispositivos pueden ser perfectamente razonables y útiles cuando se utilizan para el enrutamiento BGP de una parte más pequeña de la red, como un sistema autónomo (AS) de confederación que representa a varias empresas pequeñas conectadas por una red troncal BGP , o una pequeña empresa que anuncia rutas a un ISP pero solo acepta una ruta predeterminada y quizás un pequeño número de rutas agregadas.

Un enrutador BGP utilizado únicamente para una red con un único punto de entrada a Internet puede tener una tabla de enrutamiento mucho más pequeña (y, por lo tanto, menores requisitos de RAM y CPU) que una red con múltiples conexiones. Incluso una configuración simple de múltiples conexiones puede tener una tabla de enrutamiento de tamaño moderado. La cantidad real de memoria requerida en un enrutador BGP depende de la cantidad de información BGP intercambiada con otros enrutadores BGP y de la forma en que el enrutador en particular almacena dicha información. El enrutador puede tener que mantener más de una copia de una ruta para poder gestionar diferentes políticas de anuncio y aceptación de rutas a un sistema autónomo (AS) vecino específico. El término " vista" se utiliza a menudo para referirse a estas diferentes relaciones de políticas en un enrutador en funcionamiento.

Si una implementación de enrutador requiere más memoria por ruta que otra, esto puede ser una decisión de diseño legítima, donde se prioriza la velocidad de procesamiento sobre la memoria. Tabla BGP completa de IPv4 a septiembre de 2025.es más de un millón de prefijos. [ 63 ] [ 49 ] Los grandes ISP pueden agregar otro 50% para rutas internas y de clientes. Nuevamente, dependiendo de la implementación, se pueden mantener tablas separadas para cada vista de un AS par diferente.

Entre las implementaciones de BGP gratuitas y de código abierto más destacadas se incluyen:

Los sistemas para probar la conformidad con BGP, el rendimiento bajo carga o bajo estrés provienen de proveedores como:

Véase también

Notas

  1. ↑ Los números ASN del 64512 al 65534 estaban reservados para uso privado y los números 0 y 65535 están prohibidos.
  2. ↑ Los ASN 4200000000 a 4294967294 son privados y el 4294967295 está prohibido. [ 60 ]

Documentos de estándares para BGP-4

  • RFC 1772 – " Aplicación del protocolo de puerta de enlace de frontera en Internet " , [ 65 ] Borrador de estándar. 
  • RFC 1997 – " Atributo de comunidades BGP " , [ 21 ] Estándar propuesto. 
  • RFC 2439 – " Amortiguación de flaps de ruta BGP " , [ 43 ] Estándar propuesto. 
  • RFC 2918 – " Capacidad de actualización de ruta para BGP-4 " , [ 35 ] Estándar propuesto. 
  • RFC 3765 – " Comunidad NOPEER para el control del alcance de ruta del protocolo de puerta de enlace de frontera (BGP), " [ 66 ] Informativo. 
  • RFC 4271 – " Protocolo de puerta de enlace de frontera 4 (BGP-4), " [ 11 ] Borrador de estándar. 
  • RFC 4272 – " Análisis de vulnerabilidades de seguridad de BGP " , [ 67 ] Informativo. 
  • RFC 4273 – " Definiciones de objetos gestionados para BGP-4, " [ 68 ] Estándar propuesto. 
  • RFC 4274 – " Análisis del protocolo BGP-4 " , [ 15 ] Informativo. 
  • RFC 4275 – " Encuesta de implementación de MIB BGP-4 " , [ 69 ] Informativo. 
  • RFC 4276 – " Informe de implementación de BGP-4, " [ 70 ] Informativo. 
  • RFC 4277 – " Experiencia con el protocolo BGP-4 " , [ 71 ] Informativo. 
  • RFC 4278 – " Variación de madurez de estándares con respecto a la opción de firma TCP MD5 (RFC 2385) y la especificación BGP-4 " , [ 72 ] Informativo. 
  • RFC 4360 – " Atributo de comunidades extendidas BGP " , [ 26 ] Estándar propuesto. 
  • RFC 4456 – " Reflexión de ruta BGP: una alternativa a BGP interno de malla completa (IBGP), " [ 39 ] Borrador de estándar. 
  • RFC 4724 – " Mecanismo de reinicio elegante para BGP " , [ 73 ] Estándar propuesto. 
  • RFC 4760 – " Extensiones multiprotocolo para BGP-4 " , [ 14 ] Estándar propuesto. 
  • RFC 5065 – " Confederaciones de sistemas autónomos para BGP " , [ 40 ] Borrador de estándar. 
  • RFC 5492 – " Anuncio de capacidades con BGP-4, " [ 33 ] Borrador de estándar. 
  • RFC 5701 – " Atributo de comunidad extendida BGP específico de la dirección IPv6 " , [ 74 ] Estándar propuesto. 
  • RFC 6793 – " Soporte BGP para el espacio de números de sistema autónomo (AS) de cuatro octetos " , [ 61 ] Estándar propuesto. 
  • RFC 7153 – " Registros IANA para comunidades extendidas BGP " , [ 29 ] Estándar propuesto. 
  • RFC 7313 – " Capacidad mejorada de actualización de rutas para BGP-4 " , [ 36 ] Estándar propuesto. 
  • RFC 7606 – " Manejo de errores revisado para mensajes BGP UPDATE " , [ 34 ] Estándar propuesto. 
  • RFC 7911 – " Anuncio de múltiples rutas en BGP " , [ 75 ] Estándar propuesto. 
  • RFC 8092 – " Atributo de comunidades grandes de BGP " , [ 30 ] Estándar propuesto. 
  • RFC 8195 – " Uso de comunidades grandes de BGP " , [ 31 ] Informativo. 
  • RFC 8642 – " Comportamiento de la política para comunidades BGP conocidas " , [ 76 ] Estándar propuesto. 
  • RFC 8955 – “ Difusión de reglas de especificación de flujo ” , [ 77 ] Norma propuesta. 
  • RFC 9552 – " Distribución de información de ingeniería de tráfico y estado de enlace mediante BGP " , [ 78 ] Estándar propuesto. 

Referencias

  1. ↑ "Historial de rfc1105" . IETF . Junio ​​de 1989. Consultado el 1 de diciembre de 2023 .
  2. ↑ "BGP: Explicación del protocolo de puerta de enlace de frontera" . Orbit-Computer Solutions.Com . Archivado del original el 28 de septiembre de 2013. Consultado el 8 de octubre de 2013 .
  3. ↑ Sobrinho, João Luís (2003). "Enrutamiento de red con protocolos de vector de ruta: teoría y aplicaciones" (PDF) . Archivado (PDF) desde el original el 14 de julio de 2010 . Consultado el 16 de marzo de 2018 .
  4. ↑ Jabloner, Paula (2015-03-04). "El protocolo de las dos servilletas" . Museo de Historia de la Computación . Recuperado el 2024-10-01 .
  5. ↑ K. Lougheed; Y. Rekhter (abril de 1989). Un protocolo de puerta de enlace de frontera (BGP) . Grupo de trabajo de redes. doi : 10.17487/RFC1105 . RFC 1105 .Obsoleto. Obsoleto según RFC 1136 . 
  6. ↑ "Historia del protocolo Border Gateway" . blog.datapath.io . Archivado del original el 29 de octubre de 2020.
  7. ↑ K. Lougheed; Y. Rekhter (junio de 1990). Un protocolo de puerta de enlace de frontera (BGP) . Grupo de trabajo de redes. doi : 10.17487/RFC1136 . RFC 1136 .Histórico. Obsoleto según RFC 1267. Obsoleto según RFC 1136 .  
  8. ↑ K. Lougheed; Y. Rekhter (octubre de 1991). Un protocolo de puerta de enlace de frontera 3 (BGP-3) . Grupo de trabajo de redes. doi : 10.17487/RFC1267 . RFC 1267 .Histórico. Obsoletos RFC 1136 . 
  9. ↑ Y. Rekhter ; T. Li, eds. (julio de 1994). Un protocolo de puerta de enlace de frontera 4 (BGP-4) . Grupo de trabajo de redes. doi : 10.17487/RFC1654 . RFC 1654 .Obsoleto. Obsoleto según RFC 1771 . 
  10. 1 2 Y. Rekhter ; T. Li (marzo de 1995). Un protocolo de puerta de enlace de frontera 4 (BGP-4) . Grupo de trabajo de redes. doi : 10.17487/RFC1771 . RFC 1771 .Obsoleto. Obsoleto según RFC 4271. Obsoleto según RFC 1654 .  
  11. 1 2 3 4 Y. Rekhter ; T. Li; S. Hares, eds. (enero de 2006). Un protocolo de puerta de enlace de frontera 4 (BGP-4) . Grupo de trabajo de redes. doi : 10.17487/RFC4271 . RFC 4271 .Borrador de estándar. Sustituye a RFC 1771. Actualizado por RFC 6286 , 6608 , 6793 , 7606 , 7607 , 7705 , 8212 , 8654 y 9072 .  
  12. ↑ T. Bates; R. Chandra; D. Katz; Y. Rekhter (enero de 1998). Extensiones multiprotocolo para BGP-4 . Grupo de trabajo de redes. doi : 10.17487/RFC2283 . RFC 2283 .Obsoleto. Obsoleto según RFC 2858 . 
  13. ↑ T. Bates; Y. Rekhter ; R. Chandra; D. Katz (mayo de 2000). Extensiones multiprotocolo para BGP-4 . Grupo de trabajo de redes. doi : 10.17487/RFC2858 . RFC 2858 .Obsoleto. Deja obsoleto el RFC 2283. Obsoleto por el RFC 4760 .  
  14. 1 2 T. Bates; R. Chandra; Y. Rekhter (enero de 2007). Extensiones multiprotocolo para BGP-4 . Grupo de trabajo de redes IETF . doi : 10.17487/RFC4760 . RFC 4760 .Estándar propuesto. Actualizado por RFC 7606. Sustituye a RFC 2858 .  
  15. 1 2 D. Meyer; K. Patel (enero de 2006). Análisis del protocolo BGP-4 . Grupo de trabajo de redes. doi : 10.17487/RFC4274 . RFC 4274 .Informativo.
  16. ↑ R. Chandra; J. Scudder (mayo de 2000). Anuncio de capacidades con BGP-4 . IETF . doi : 10.17487/RFC2842 . RFC 2842 .
  17. ↑ T. Bates; et al. (junio de 2000). Extensiones multiprotocolo para BGP-4 . IETF . doi : 10.17487/RFC2858 . RFC 2858 . 
  18. ↑ E. Rosen; Y. Rekhter (abril de 2004). VPN BGP/MPLS . IETF . doi : 10.17487/RFC2547 . RFC 2547 .
  19. ↑ "Algoritmo de selección de la mejor ruta BGP " . Cisco.com .
  20. ↑ "Comprensión de la selección de rutas BGP" . Juniper.com .
  21. 1 2 R. Chandra; P. Traina; T. Li (agosto de 1996). Atributo de comunidades BGP . Grupo de trabajo de redes. doi : 10.17487/RFC1997 . RFC 1997 .Norma propuesta. Actualizada por RFC 7606 y 8642 . 
  22. ↑ "Comunidades conocidas del Protocolo de puerta de enlace de frontera (BGP)" . www.iana.org . Consultado el 4 de diciembre de 2022 .
  23. ↑ "Soporte de la comunidad BGP | iFog GmbH" . ifog.ch. Consultado el 4 de diciembre de 2022 .
  24. ↑ "Comunidades BGP" . retn.net . Consultado el 4 de diciembre de 2022 .
  25. ↑ "Guías de la comunidad BGP" . Consultado el 13 de abril de 2015 .
  26. 1 2 S. Sangli; D. Tappan; Y. Rekhter (febrero de 2006). Atributo de comunidades extendidas BGP . Grupo de trabajo de redes. doi : 10.17487/RFC4360 . RFC 4360 .Norma propuesta. Actualizada por RFC 7153 y 7606 . 
  27. ↑ "Comunidades extendidas del Protocolo de puerta de enlace de frontera (BGP)" . www.iana.org . Consultado el 4 de diciembre de 2022 .
  28. ↑ Borradores del IETF sobre QoS señalizada por BGP. Archivado el 23 de febrero de 2009 en Wayback Machine , Thomas Knoll, 2008.
  29. 1 2 E. Rosen; Y. Rekhter (marzo de 2014). Registros IANA para comunidades extendidas BGP . Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC7153 . ISSN 2070-1721 . RFC 7153 . Estándar propuesto. Actualizado por RFC 9184. Actualiza RFC 4360 y 5701 .  
  30. 1 2 K. Patel; I. Bagdonas; N. Hilliard (febrero de 2017). J. Heitz; J. Snijders (eds.). Atributo de comunidades grandes de BGP . Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC8092 . RFC 8092 .Norma propuesta.
  31. 1 2 J. Snijders; J. Heasley; M. Schmidt (junio de 2017). Uso de comunidades grandes de BGP . Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC8195 . RFC 8195 .Informativo.
  32. ↑ "Grandes comunidades BGP" . Consultado el 27 de noviembre de 2021 .
  33. 1 2 J. Scudder; R. Chandra (febrero de 2009). Anuncio de capacidades con BGP-4 . Grupo de trabajo de redes. doi : 10.17487/RFC5492 . RFC 5492 .Borrador de estándar. Sustituye a RFC 3392. Actualizado por RFC 8810 .  
  34. 1 2 P. Mohapatra; K. Patel (agosto de 2015). E. Chen; J. Scudder (eds.). Manejo de errores revisado para mensajes BGP UPDATE . Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC7606 . ISSN 2070-1721 . RFC 7606 . Estándar propuesto. Actualiza RFC 1997 , 4271 , 4360 , 4456 , 4760 , 5543 , 5701 y 6368 . 
  35. 1 2 E. Chen (septiembre de 2000). Capacidad de actualización de rutas para BGP-4 . Grupo de trabajo de redes. doi : 10.17487/RFC2918 . RFC 2918 .Norma propuesta. Actualizada por RFC 7313 . 
  36. 1 2 K. Patel; E. Chen; B. Venkatachalapathy (julio de 2014). Capacidad mejorada de actualización de rutas para BGP-4 . Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC7313 . ISSN 2070-1721 . RFC 7313 . Norma propuesta. Actualiza la RFC 2918 . 
  37. ↑ "Protocolo de puerta de enlace de frontera (BGP)" . Cisco.com .
  38. ↑ T. Bates; et al. (abril de 2006). BGP Route Reflection: An Alternative to Full Mesh Internal BGP (iBGP) . IETF . RFC 4456 .  
  39. 1 2 T. Bates; E. Chen; R. Chandra (abril de 2006). Reflexión de ruta BGP: una alternativa a BGP interno de malla completa (IBGP) . Grupo de trabajo de redes. doi : 10.17487/RFC4456 . RFC 4456 .Borrador de norma. Actualizado por RFC 7606. Sustituye a RFC 2796 y 1966 .  
  40. 1 2 P. Traina; D. McPherson; J. Scudder (agosto de 2007). Confederaciones de sistemas autónomos para BGP . Grupo de trabajo de redes. doi : 10.17487/RFC5065 . RFC 5065 .Borrador de estándar. Actualizado por RFC 9774. Sustituye a RFC 3065 .  
  41. ↑ D. McPherson; V. Gill; D. Walton; A. Retana (agosto de 2002). Condición de oscilación de ruta persistente del protocolo de puerta de enlace de frontera (BGP) . Grupo de trabajo de redes. doi : 10.17487/RFC3345 . RFC 3345 .Informativo.
  42. ↑ S. Hares; P. Krishnaswamy; M. Lepp (junio de 2005). H. Berkowitz; E. Davies (eds.). Terminología para la evaluación comparativa de la convergencia de dispositivos BGP en el plano de control . IETF . doi : 10.17487/RFC4098 . RFC 4098 .Informativo.
  43. 1 2 3 4 C. Villamizar; R. Chandra; R. Govindan (noviembre de 1998). Amortiguación de flaps de ruta BGP . Grupo de trabajo de redes. doi : 10.17487/RFC2439 . RFC 2439 .Norma propuesta.
  44. ↑ "La amortiguación de las fluctuaciones de ruta exacerba la convergencia del enrutamiento de Internet" (PDF) . Noviembre de 1998. Archivado (PDF) del original el 9 de octubre de 2022.
  45. ↑ Zhang, Beichuan; Pei Dan; Daniel Massey; Lixia Zhang (junio de 2005). "Interacción del temporizador en la amortiguación de aleteo de ruta" (PDF) . 25.ª Conferencia Internacional IEEE sobre Sistemas de Computación Distribuida . Recuperado el 26 de septiembre de 2006. Demostramos que el diseño de amortiguación actual conduce al comportamiento deseado solo bajo aleteo de ruta persistente. Cuando el número de aleteos es pequeño, la dinámica de enrutamiento global se desvía significativamente del comportamiento esperado con un retraso de convergencia más largo.
  46. ↑ "Recomendaciones del Grupo de Trabajo de Enrutamiento de RIPE sobre la amortiguación de flaps de ruta" . Centro de Coordinación de la Red RIPE. 10 de mayo de 2006. Consultado el 4 de diciembre de 2013 .
  47. ↑ "Procedimientos de ajuste de asignación de TCAM para routers y switches de las series CAT 6500 y 7600" . Cisco .
  48. ↑ Cowie, Jim (13 de agosto de 2014). "Internet afecta a medio millón de rutas: posibles interrupciones la próxima semana" . renesys.com . Archivado del original el 13 de agosto de 2014.
  49. 1 2 "Informes BGP" . potaroo.net .
  50. ↑ "Procedimientos de ajuste de asignación de TCAM para routers y switches de las series CAT 6500 y 7600" . Cisco . 9 de marzo de 2015.
  51. ↑ Jim Cowie. "Internet llega a medio millón de rutas: posibles interrupciones la próxima semana" . Dyn Research . Archivado del original el 17 de agosto de 2014. Consultado el 2 de enero de 2015 .
  52. ↑ Garside, Juliette; Gibbs, Samuel (14 de agosto de 2014). "La infraestructura de Internet 'necesita actualizarse o habrá más apagones'"." . The Guardian . Consultado el 15 de agosto de 2014 .
  53. ↑ "Informe BOF" (PDF) . www.nanog.org. Archivado (PDF) del original el 09/10/2022 . Consultado el 17/12/2019 .
  54. ↑ Greg Ferro (26 de enero de 2011). "TCAM : una mirada más profunda y el impacto de IPv6" . EtherealMind . 
  55. ↑ "El sitio de agotamiento de IPv4 " . ipv4depletion.com
  56. ↑ "¿Qué causó el problema de Internet de hoy?" . bgpmon.net .
  57. ↑ Informe sobre el sistema autónomo de 16 bits , Geoff Huston (científico), 2011 (original archivado en https://web.archive.org/web/20110906085724/http://www.potaroo.net/tools/asn16/ )
  58. ↑ Q. Vohra; E. Chen (mayo de 2007). Soporte BGP para espacio de números AS de cuatro octetos . Grupo de trabajo de redes. doi : 10.17487/RFC4893 . RFC 4893 .Obsoleto. Obsoleto según RFC 6793 . 
  59. ↑ J. Mitchell (julio de 2013). Reserva de sistema autónomo (AS) para uso privado . Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC6996 . ISSN 2070-1721 . BCP 6. RFC 6996 . Mejores prácticas actuales 6. Actualizaciones RFC 1930 . 
  60. ↑ J. Haas; J. Mitchell (julio de 2014). Reserva de los últimos números de sistema autónomo (AS) . Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC7300 . ISSN 2070-1721 . BCP 6. RFC 7300 . Mejores prácticas actuales 6. Actualizaciones RFC 1930 . 
  61. 1 2 Q. Vohra; E. Chen (diciembre de 2012). Soporte BGP para el espacio de números de sistema autónomo (AS) de cuatro octetos . Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC6793 . ISSN 2070-1721 . RFC 6793 . Estándar propuesto. Sustituye a RFC 4893. Actualiza RFC 4271 .  
  62. ↑ Craig Timberg (31 de mayo de 2015). "Una solución rápida para un problema inicial de Internet sigue vigente un cuarto de siglo después" . The Washington Post . Consultado el 1 de junio de 2015 .
  63. ↑ "Informe de tabla de enrutamiento IPv4 - Japón (Global) vista - bgp-stats" . orbit.apnic.net . APNIC . Consultado el 20 de septiembre de 2025 .
  64. ↑ "Zebra - Proyecto GNU - Fundación del Software Libre" .
  65. ↑ Y. Rekhter ; P. Gross (marzo de 1995). Aplicación del protocolo Border Gateway en Internet . Grupo de trabajo de redes. doi : 10.17487/RFC1772 . RFC 1772 .Proyecto de Norma. Obsoletos RFC 1655 . 
  66. ↑ G. Huston (abril de 2004). Comunidad NOPEER para el control del alcance de ruta del protocolo de puerta de enlace de frontera (BGP) . Grupo de trabajo de redes. doi : 10.17487/RFC3765 . RFC 3765 .Informativo.
  67. ↑ S. Murphy (enero de 2006). Análisis de vulnerabilidades de seguridad de BGP . Grupo de trabajo de redes. doi : 10.17487/RFC4272 . RFC 4272 .Informativo.
  68. ↑ J. Haas; S. Hares, eds. (enero de 2006). Definiciones de objetos gestionados para BGP-4 . Grupo de trabajo de redes. doi : 10.17487/RFC4273 . RFC 4273 .Norma propuesta. Sustituye a las RFC 1657 y 1269 . 
  69. ↑ S. Hares; D. Hares (enero de 2006). Encuesta de implementación de MIB de BGP-4 . Grupo de trabajo de redes. doi : 10.17487/RFC4275 . RFC 4275 .Informativo.
  70. ↑ S. Hares; A. Retana (enero de 2006). Informe de implementación de BGP-4 . Grupo de trabajo de redes. doi : 10.17487/RFC4276 . RFC 4276 .Informativo.
  71. ↑ D. McPherson; K. Patel (enero de 2006). Experiencia con el protocolo BGP-4 . Grupo de trabajo de redes. doi : 10.17487/RFC4277 . RFC 4277 .Informativo.
  72. ↑ S. Bellovin ; A. Zinin (enero de 2006). Variación en la madurez de los estándares con respecto a la opción de firma TCP MD5 (RFC 2385) y la especificación BGP-4 . Grupo de trabajo de redes. doi : 10.17487/RFC4278 . RFC 4278 .Informativo.
  73. ↑ S. Sangli; E. Chen; R. Fernando; J. Scudder; Y. Rekhter (enero de 2007). Mecanismo de reinicio elegante para BGP . Grupo de trabajo de redes IETF . doi : 10.17487/RFC4724 . RFC 4724 .Estándar propuesto. Actualizado por RFC 8538. Actualiza RFC 4271 .  
  74. ↑ Y. Rekhter (octubre de 2009). Atributo de comunidad extendida BGP específico de la dirección IPv6 . Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC5701 . RFC 5701 .Norma propuesta. Actualizada por RFC 7153 y 7606 . 
  75. ↑ D. Walton; A. Retana; E. Chen; J. Scudder (julio de 2016). Anuncio de rutas múltiples en BGP . Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC7911 . RFC 7911 .Norma propuesta.
  76. ↑ J. Borkenhagen; R. Bush; R. Bonica; S. Bayraktar (agosto de 2019). Comportamiento de las políticas para comunidades BGP conocidas . Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC8642 . ISSN 2070-1721 . RFC 8642 . Norma propuesta. Actualiza la RFC 1997 . 
  77. ↑ C. Loibl; S. Hares; R. Raszuk; D. McPherson; M. Bacher (diciembre de 2020). Difusión de reglas de especificación de flujo . Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC8955 . ISSN 2070-1721 . RFC 8955 . Norma propuesta. Actualizada por RFC 8956 , 9117 y 9184. Sustituye a RFC 5575 y 7674 .  
  78. ↑ K. Talaulikar, ed. (diciembre de 2023). Distribución de información de ingeniería de tráfico y estado de enlace mediante BGP . Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC9552 . ISSN 2070-1721 . RFC 9552 . Norma propuesta. Sustituye a las RFC 7752 y 9029 . 

Lecturas adicionales

  • "Protocolo de puerta de enlace de frontera (BGP)" , Manual de tecnología IOS , Cisco Systems , archivado del original el 8 de julio de 2011.
  • Van Beijnum, Iljitsch (2002). BGP . O'Reilly Media Inc. ISBN 978-0-596-00254-1. Consultado el 31 de diciembre de 2025 .
  • Recursos de enrutamiento BGP (incluye una sección dedicada a BGP y la seguridad central de los ISP )
  • Estadísticas de la tabla BGP
Lecturas relacionadas
6 articulos
EnrutamientoEnrutamientoEl enrutamiento es el proceso de seleccionar una ruta para el tráfico en una red o entre varias redes. En términos generales, el enrutamiento se re...Sistema autónomo (Internet)Sistema autónomo (Internet)Un sistema autónomo ( AS ) es una colección de prefijos de enrutamiento de Protocolo de Internet (IP) conectados bajo el control de uno o más opera...InternetInternetInternet (o internet ) [a] es el sistema global de redes de computadoras interconectadas que utiliza el conjunto de protocolos de Internet (TCP/IP)...Administrador de redAdministrador de redUn administrador de red es una persona designada en una organización cuya responsabilidad incluye el mantenimiento de las infraestructuras informát...Austin, TexasAustin, TexasAustin ( / ˈɔːs tɪn /​​​​ ⓘ AW-stin)[7]es lacapitaldelestado estadounidensedeTexasy lasedey ciudad más poblada delcondado de Travis, con partes que...Yakov RekhterYakov Rekhter es un reconocido diseñador de protocolos de red y programador de software. Participó activamente en el desarrollo del protocolo de in...