[lacnog] Desagregacion de rutas

[Roque Gagliano]

Hola nico.


On May 27, 2008, at 6:45 PM, Nicolas Antoniello wrote:

> -----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.

totalmente de acuerdo en que hay situaciones en que es necesario  
desagregar para tener enlaces hot-hot.

Ahora en el ejemplo que tu das es posible realizar configuraciones con  
comunidades BGP (particularmente no-export) para que la desagregación  
sea local entre el proveedor y su upstream, pero no se disemine al  
resto del mundo.

Ejemplo, tienes un /21 que ocupa 200 megas y dos enlaces STM-1.  
Anuncias 1x/22 en cada enlace (uno en cada uno) con comunidad "no  
export" correspondiente y un /21 sin esa comunidad.

El upstream ve los /22, pero el resto del mundo solo el /21. El resto  
del mundo solo sabe como llegar al /21, cuando los paquetes lleguen al  
upstream, el decide por longest-match por el enlace que tiene el /22  
pertinente.

Esto no ocupa todos los casos, el mensaje que quería transmitir es...  
ponga la agregación como una meta en sus anuncios, por que tu upstream  
te permita publicar /24, no quiere decir que lo vas a hacer.

> 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. :)
>

eso es lo que comente antes.

> - - 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-----
> _______________________________________________
> LACNOG mailing list
> LACNOG en lacnic.net
> https://mail.lacnic.net/mailman/listinfo/lacnog

------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20080527/f487b6a1/attachment.html>
------------ próxima parte ------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20080527/f487b6a1/attachment.sig>