<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Καλημέρα/σπέρα,<br>
<br>
επανέρχομαι στο θέμα και στο Link που είχε στείλει ο Σπύρος <br>
(<a class="moz-txt-link-freetext" href="https://www.bgpmon.net/massive-route-leak-cause-internet-slowdown/">https://www.bgpmon.net/massive-route-leak-cause-internet-slowdown/</a>)<br>
<br>
Μέσα φαίνεται λοιπόν οτι υπάρχουν δύο ανεξάρτητες αμέλειες δύο ISPs
<br>
η μία είναι της Malaysia Telecom και η άλλη της Level 3..<br>
(<span style="color: rgb(71, 71, 71); font-family: 'Lucida Sans',
'Lucida Grande', 'Lucida Sans Unicode', sans-serif; font-size:
14px; font-style: normal; font-variant: normal; font-weight:
normal; letter-spacing: normal; line-height: 21px; orphans: auto;
text-align: start; text-indent: 0px; text-transform: none;
white-space: normal; widows: 1; word-spacing: 0px;
-webkit-text-stroke-width: 0px; display: inline !important; float:
none; background-color: rgb(255, 255, 255);">Level3 erroneously
accepted these prefixes and announced these to their peers and
customers... και<br>
The 176,000 leaked prefixes are likely all Telekom Malaysia’s
customer prefixes combined with routes they learned from peers. )<br>
Προσωπικά πιστεύω οτι όταν το λάθος "σκάσει" στον Tier1 provider
θα επακολουθήσουν αυτά που είδαμε και οπως σωστά είπε ο Φαίδων δεν
μπορεί να κάνει κάτι η Level3 (προληπτικά) μπορεί να μην βοηθά και
η υφιστάμενη κατάσταση της τεχνολογίας.<br>
<br>
Απο την πλευρά της η Malaysia telecom πραγματικά θα μπορούσε να
κάνει κάτι αλλά έχει αμελήσει. <br>
Αρα το θέμα είναι τι κάνουν οι Tier2/1 providers για να μην
δημιουργήσουν τέτοιες καταστάσεις. <br>
<br>
Αυτό θα ήθελα να ρωτήσω τα μέλη αυτής της λίστας ως
τεχνικοί-μηχανικοί των εγχώριων ISP εφόσον αυτό δεν αφορά
επιχειρηματικά μυστικά. Τι μέτρα έχουν in place ?<br>
<br>
Εχω την εντύπωση λοιπόν οτι κάθε Tier2/1 για να μπορέσει να
εφαρμόσει τεχνικές αποφυγής leaking χρειάζεται να κάνει ένα
διαχωρισμό των announcements σε α) δικά της β) πελατών γ) dual
homed πελατών της και να εφαρμόζει διαφορετικές τεχνικές.<br>
<br>
Χαιρετισμούς,<br>
Δημήτρης<br>
<br>
</span><br>
<div class="moz-cite-prefix">On 13/6/2015 1:56 μμ, Faidon Liambotis
wrote:<br>
</div>
<blockquote cite="mid:557C0C41.3030202@tty.gr" type="cite">On
06/13/15 12:45, Andreas Polyrakis wrote:
<br>
<blockquote type="cite">Εκτός από το strict filtering που σωστά
αναφέρθηκε -- το οποίο δεν
<br>
δουλεύει τόσο καλά εκτός RIPE region ή για "μεγάλα" peerings --
υπάρχει
<br>
και το RPKI. Το RPKI δεν είναι επίσης πανάκεια· δεν
αντιμετωπίζει καλά
<br>
κακόβουλες ανακοινώσεις, ούτε leaking, αλλά βοηθάει πολύ σε
<br>
misconfigurations ή typos.
<br>
</blockquote>
<br>
Ναι, όπως λες όμως... δεν βοήθησε καθόλου εδώ. Τα routes που
ανακοινώνονταν διατηρούσαν το origin τους (π.χ. 3549 4788 15169)
και ως εκ τούτου το RPKI δεν προστάτευσε κανέναν από αυτούς που
έχουν ενεργοποιήσει validation.
<br>
<br>
Φ.
<br>
<br>
<br>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
------------------------
Dimitrios K. Kalogeras
Electrical Engineer Ph.D.
Network Engineer
Netmode NTUA Lab
_____________________________________
skype: aweboy
voice: +30-210-772 1448
fax: +30-210-772 1866
e-mail: <a class="moz-txt-link-abbreviated" href="mailto:D.Kalogeras@noc.ntua.gr">D.Kalogeras@noc.ntua.gr</a>
</pre>
</body>
</html>