<div><div dir="auto">Como anda el soporte de los dispositivos de IoT por ejemplo para manejar 2 (o más direcciones IPv6) ruteablea y el tema de los RAs de dos diferentes gateways ?</div></div><div dir="auto"><br></div><div dir="auto">Me refiero a si es algo que se soporte en la gran mayoría o las implementaciones están más bien pensadas (mal pensadas?) para manejar uno solo?</div><div dir="auto"><br></div><div dir="auto">Saludos,</div><div dir="auto">Nico</div><div dir="auto"><br></div><div dir="auto"><br></div><div><br><div class="gmail_quote"><div dir="ltr">El El sáb, 8 de dic. de 2018 a las 09:15, Fernando Gont <<a href="mailto:fernando@gont.com.ar">fernando@gont.com.ar</a>> escribió:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 7/12/18 16:37, Fernando Frediani wrote:<br>
> Hola a todos<br>
> <br>
> Solución con BGP no viene al caso para esas situaciones pues hablamos de<br>
> enlaces de internet residenciales / comerciales que son la vasta mayoría<br>
> de los utilizados en esos escenarios.<br>
<br>
Si, por eso te mencione otras opciones, ya que en esecenarios simples,<br>
lo de BGP puede llegar a ser prohibitivo.<br>
<br>
<br>
<br>
<br>
> La cuestión de que en el escenario de un enlace de Internet se caiga y<br>
> algunos paquetes seguirán tratando de salir por el enlace del otro ISP<br>
> que tendrá filtro no veo como un problema porque eso sólo ocurría por<br>
> unos instantes lo que daría una sensación temporal de desconexión.<br>
> <br>
> Lo más importante es que el fail-over ocurra de manera automática.<br>
> <br>
> Si la idea del RA con lifetime bajo y prioridad menor funciona, en<br>
> teoría las direcciones IPv6 asignadas a los equipos por la CPE principal<br>
> desaparecerán y quedarán sólo los IPv6 de la otra CPE y consecuentemente<br>
> el gateway-default.<br>
<br>
LO de las prioridades, en principio no lo tengas en cuenta, ya que no<br>
tenes garantias de que todas las implementaciones lo soporten (aunque<br>
esperaria que la mayria si).<br>
<br>
Respecto de los tiempos de los RAs, basicamente tenes dos opciones:<br>
<br>
1) Que los RAs usualmente utilicen un "router lifetime" (por ej., 60<br>
segundos o menos), y que al mismo tiempo se brodcasteen por la red con<br>
mas frecuencia que lo usual (la idea es que cada host tenga la<br>
posibilidad de recibir al menos unos 5 RAs, para considerar las posibles<br>
perdidas de paquetes.. que en entornos cableados pueden no ocurrir, pero<br>
si en entornos inalambricos). En este caso, el ROuter envia entonces RAs<br>
con un "router lifetime" the 60 segundos o menos, y los broadcastea una<br>
veza cada 10 segundos, mas o menos.<br>
Si el enlace se cae, y el router en cuestion toma como politica que<br>
cuando el enlace cae deja de enviar RAs, entonces despues de un maximo<br>
de 60 segundos, este router quedara deshabilitado.<br>
<br>
Para el router de backup tenes dos opciones:<br>
   + o que siempre nevie con RAs con menor prioridad (y asumir que todos<br>
tus sistemas soportan el tema de las prioridades), o,<br>
   +  hacer que mida el funcionamiento del otro enlace por ej. un par de<br>
veces por minuto, y solo empezar a anunciar RAs en tal caso<br>
<br>
<br>
2) La otra opcion es que los tiempos de los RAs sean los de siempre, y<br>
simplemente, al caerse el enlace, broacasteas un RA con un lifetime de<br>
"0" para deshabilitarlo (en lo que respecta al router de backup, sorren<br>
las mismas consideraciones que en el caso anterior).<br>
<br>
<br>
De acuerdo a la estrategia que elijas, puede que pueadas hacerlo<br>
simplemente configurando valores (por ej., tuneando los temporizadores<br>
de los RAs), o puede que tengas que realizar algun script simple.<br>
<br>
<br>
<br>
> Además de esos hipótesis, que otros métodos de fail-over podrían ser<br>
> considerados para tener en IPv6 un escenario similar al que se hace hoy<br>
> con IPv4 en la mayoría de los lugares que poseen 2 enlaces de internet y<br>
> NAT?<br>
<br>
Nota: Cisco implementa NPT (una especie de NAT para IPv6, sin traduccion<br>
de puertos).<br>
<br>
-- <br>
Fernando Gont<br>
e-mail: <a href="mailto:fernando@gont.com.ar" target="_blank">fernando@gont.com.ar</a> || <a href="mailto:fgont@si6networks.com" target="_blank">fgont@si6networks.com</a><br>
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1<br>
<br>
<br>
<br>
_______________________________________________<br>
LACNOG mailing list<br>
<a href="mailto:LACNOG@lacnic.net" target="_blank">LACNOG@lacnic.net</a><br>
<a href="https://mail.lacnic.net/mailman/listinfo/lacnog" rel="noreferrer" target="_blank">https://mail.lacnic.net/mailman/listinfo/lacnog</a><br>
Cancelar suscripcion: <a href="https://mail.lacnic.net/mailman/options/lacnog" rel="noreferrer" target="_blank">https://mail.lacnic.net/mailman/options/lacnog</a><br>
</blockquote></div></div>