<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<div>
<p dir="ltr">Mi inserisco anche se noi non riscontriamo questi problemi (al momento).</p>
<p dir="ltr">Mi interessa capire la problematica per riuscire a diagnosticarla nel caso si verifichi.</p>
<p dir="ltr">Utente Alice ADSL A non raggiunge x.y.z.k ma raggiunge x.y.z.(k+1)</p>
<p dir="ltr">Nello stesso momento, un altro utente Alice ADSL raggiunge x.y.z.k ?</p>
<p dir="ltr">Il problema sembra verificarsi solo quando si passa da un nodo specifico di ingresso verso la rete di Telecom IT o da qualsiasi nodo?</p>
<p dir="ltr">Perché a me, probabilmente ignorando alcuni aspetti tecnici, pare strano che si tratti di un problema di routing se non si raggiunge un IP ma si raggiunge quello adiacente.</p>
<p dir="ltr">Non so se è tecnicamente valida, ma non è possibile che in TI ci sia un "firewall" che blocca alcuni IP esterni a TI, che non hanno il peering diretto, che generano tanto traffico verso TI?<br>
</p>
<p dir="ltr">Emanuele (Mobile)</p>
<div class="x_quote">Il 16/dic/2014 11:53 Andrea Costantino <costan@amg.it> ha scritto:<br type="attribution">
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">Questa è la giusta punizione per il depeering massivo di TI (AS3269). Stanno<br>
saturando il loro transito principale. TIS non ha problemi, solo TI, perché<br>
avranno una delle interconnessioni di Milano a tappo.. Forse riesco a<br>
trovare un modo di far fare un check, ma comunque non credo che tanto<br>
facilmente ammetteranno i problemi.<br>
<br>
La soluzione? Dite a tutti i vostri amici (competenti o no) che Telecom è il<br>
male, fanno strategie contro la net neutrality (fategli l'esempio del medico<br>
che decide se curare i pazienti solo se danno la carta di credito,<br>
capiranno..) e alla fine hanno la rete incozzata perché non sono buoni<br>
nemmeno a tirare fili con una controllata, e si incartano sulle loro stesse<br>
procedure e strategie.<br>
<br>
Se non fossi allergico a facebook farei un gruppo di rant in cui postare i<br>
traceroute e chiedergli spiegazioni..<br>
<br>
<br>
<br>
-----Messaggio originale-----<br>
Da: itnog [<a href="mailto:itnog-bounces@lists.itnog.it">mailto:itnog-bounces@lists.itnog.it</a>] Per conto di Lukas Tribus<br>
Inviato: martedì 16 dicembre 2014 09:41<br>
A: Marco d'Itri<br>
Cc: itnog@lists.itnog.it<br>
Oggetto: Re: [ITNOG] problemi verso AS3269<br>
<br>
> In compenso, da venerdì mattina fino a questo istante è ricomparso il<br>
> solito problema che causa blackholing tra coppie di IP<br>
<br>
Stessa cosa qua (20811), stiamo consegnando il traffico tramite 3356<br>
e/o 3257 a 6762 verso 3269.<br>
<br>
<br>
<br>
> al confine tra 3269 e 6762.<br>
<br>
Confermo, l'interruzione del traffico ieri avveniva in direzione<br>
3269 --> 6762 (non vice-versa, dove spesso c'è congestione essendo<br>
eyeball 3269) e nel traceroute dopo l'ip privato. Il next-hop dopo<br>
questo ip privato in condizioni normali (o altri indirizzi IP) è<br>
di 6762.<br>
<br>
<br>
Lukas<br>
<br>
<br>
<br>
-- <br>
Mailing list info: <a href="http://lists.itnog.it/listinfo/itnog">http://lists.itnog.it/listinfo/itnog</a><br>
<br>
<br>
-- <br>
Mailing list info: <a href="http://lists.itnog.it/listinfo/itnog">http://lists.itnog.it/listinfo/itnog</a><br>
</div>
</span></font>
</body>
</html>