Ejemplos de implementación de políticas mediante BGP communities en NIXVAL-IXP

Ejemplos de implementación de políticas mediante BGP communities en NIXVAL-IXP

 

A continuación presentamos ejemplos de implementación de políticas mediante BGP communities en la conexión a los route-servers de NIXVAL-IXP.

Las políticas soportadas son las siguientes:

 

0:<peerAS> No anunciar prefijo a <peerAS>
57542:<peerAS>                      Anunciar prefijo a <peerAS>
0:57542 No anunciar a ningún peer
57542:57542 Anunciar a todos los peers

 

Las 2 últimas políticas se utilizan para, en combinación con con las otras dos, implementar los anuncios a un único peer o a todos los participantes menos uno.

La aplicación de las políticas se haría de la siguiente forma para los distintos escenarios:

 

  • Queremos que nuestro prefijo X.X.X.X/24 no se anuncie al ASN 1234:
    • Anunciamos el prefijo X.X.X.X/24 con la community 0:1234
  • Queremos que nuestro prefijo  X.X.X.X/24 se anuncie únicamente al ASN 1234:
    • Anuncio X.X.X.X/24 con la combinación de communities 57542:1234, 0:57542
  • Queremos que nuestro prefijo X.X.X.X/24 se anuncie a todos los participantes excepto al ASN 1234
    • Anuncio X.X.X.X/24 con la combinación de communities 0:1234, 5742:5742

 

 

A continuación un ejemplo simplificado para la configuración de routers CISCO para conectarse a los route-servers de NIXVAL-IXP  e implementar un filtro de salida que anuncia las communities requeridas para que el contenido de un filtro se anuncie exclusivamente al AS 1234:

router bgp 57542
	no bgp enforce-first-as    #(IMPRESCINDIBLE!!)
	neighbor nixvalixp peer-group
	neighbor nixvalixp remote-as 57542
	neighbor nixvalixp route-map nixvalixp_out out
        neighbor nixvalixp maximum-prefix 20000
	neighbor 213.162.194.1 peer-group nixvalixp
	neighbor 213.162.194.2 peer-group nixvalixp
route-map nixvalixp_out
	match as-path 10       #(filtro de salida que se utilice, prefix-list, etc...)
	set community 57542:1234 0:57542
Caida de Google de ayer

Caida de Google de ayer

Artículo en Wired sobre la caída de Google de ayer.

El gráfico, publicado en Wired y cortesía de Arbor Networks, que es capaz de tener información sobre el tráfico agregado de Google en 10 TierI/II ISPs. Se entiende que esta es buena parte del tráfico de Google, aunque 35 Gbps no parece mucho. De hecho, más de un proveedor de tránsito IP en NIXVAL tiene capacidades de 40 Gbps.

La confianza del mercado de colocation

El último número de DatacenterDynamics Focus repasa el estado del mercado de colocation europeo. El título es significativo: “The Enduring Confidence of Colocation”. En él se resume la tendencia al desarrollo anticíclico del mercado de la colocation en el mundo, todavía en auge y expansión a pesar de la crisis.

Los artículos constatan un encarecimiento del precio de colocation del rack, así como la constatación de que el factor determinante del precio es la energía en lugar del espacio físico. kW en lugar de m2, con la introducción en todos los países europeos de nuevos productos que reflejan el coste de la disponibilidad de mayores densidades de potencia por rack.
Los precios medios de alojamiento sin energía en Europa varían desde los 673 €/mes de Alemania a los 1300 €/mes de Dinamarca, con UK – el mercado europeo de referencia – en 1024 €/mes. El informe subraya un incremento de precios de un 8,5% de media en Europa.
Por nuestra parte en NIXVAL mantenemos nuestro esquema actual de precios, en el que hemos trasladado la estructura de costes del negocio de la colocation en modalidad alojamiento neutral:  beneficiarse de los precios de ancho de banda gracias a la concentración de infraestructuras de red, y garantizar la disponibilidad 24×7 de las infraestructuras de housing a precios muy competitivos.