[lacnog] Desagregacion de rutas

Nicolas Antoniello nantoniello en gmail.com
Mar Mayo 27 18:45:22 BRT 2008


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sobre este tema, y continuando un poco la charla que inicio Roque en  
su presentación de hoy, quería hacer un par de comentarios:

- - La desagregacion en algunos casos creo que no es evitable... por  
ejemplo, del lado de operación, tenemos casos en los que un bloque / 
21 asignado para un pool de direcciones de servicios DSL puede  
generar un trafico entrante de mas de 200 megas. En ese caso, aun  
cuando se tiene un solo carrier Tier-1, si se tienen por ejemplo 4 o  
5 enlaces STM-1 y/o algun STM-4 se tiene que desagregar para evitar  
saturar los enlaces.
Otras posibles soluciones podrían pasar por realizar un bundle (LAG)  
con todos los enlaces, pero en ese caso, se sacrificaría posiblemente  
la redundancia ya que seria casi necesario que los enlaces terminaran  
todo en el mismo equipo del proveedor... o al menos, que los caminos  
sean simétricos con alguna sesión BGP multihop contra un equipo  
equidistante.

- - Parece claro que en caso de que sea necesaria la desagregacion a la  
hora de publicar bloques a los carriers, se lograria que el resto del  
mundo no viera esas rutas si ellas son publicadas utilizando una  
comunidad proporcionada por el proveedor que evite que dichos bloques  
se propaguen al resto del mundo. Obviamente tenemos que publicar al  
proveedor el superbloque correspondiente sin marcarlo con dicha  
comunidad. :)

- - Otro motivante de desagregacion es el mismo caso de múltiples  
enlaces relativamente pequeños en un escenario de multihoming. Por  
ejemplo, cuando se quiere dar cierta preferencia a bloques de  
clientes "gold" frente a clientes "silver" por ejemplo.
Nuevamente podemos publicar los superbloques, pero en el caso de  
multihoming igualmente tendríamos cierta desagregacion entre los  
diferentes carriers pues si publicamos el mismo superbloque por  
ambos, seguramente el protocolo BGP preferira uno de los 2 caminos.
En este sentido, el tema de dejar que BGP haga su trabajo, sin  
ingeniería de trafico provocaría que uno de los carriers  
prácticamente no tuviera trafico... sobre todo si se trata de  
carriers "cercanos", o mas formalmente dicho, que poseen  
prácticamente las mismas rutas con prácticamente igual numero de  
saltos de ASs hacia los orígenes de trafico.

Que opinan?

Saludos,
Nicolas.



On 27/05/2008, at 06:11 PM, Roque Gagliano wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hola,
>
> para comentar sobre mi presentacion recibi algun comentario en el
> piso, les cuento que los datos se hacen desde un router "cliente" sin
> vinculos de peering y con su propio ASN, por lo que no conoce las
> rutas internas de los tier-1, por lo que lo podemos considerar neutral
> respecto a la topologia de cada cliente con algun proveedor de  
> transito.
>
> slds
> r.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.8 (Darwin)
>
> iEYEARECAAYFAkg8eRkACgkQnk+WSgHpbO53jACeMXwMCUiq4GwJ0o6WYppCZQy3
> CDkAmwXHXhuXInCc7OsZgfGsO6UaBvW9
> =fa/d
> -----END PGP SIGNATURE-----
> _______________________________________________
> LACNOG mailing list
> LACNOG en lacnic.net
> https://mail.lacnic.net/mailman/listinfo/lacnog

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iD8DBQFIPIDy1fu3N7aWArMRAjKxAJ0W3zQ6yEODnzu+6HxwlveSbAigrwCeMewf
tobzSAwOSmqt/nWuen4Rf28=
=rBMv
-----END PGP SIGNATURE-----



Más información sobre la lista de distribución LACNOG