[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