<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Αντρέα,<br>
    <br>
    <div class="moz-cite-prefix">On 16/6/2015 5:32 μμ, Andreas Polyrakis
      wrote:<br>
    </div>
    <blockquote cite="mid:55803367.6090606@noc.grnet.gr" type="cite">
      <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
      <div class="moz-cite-prefix">On 06/16/2015 04:38 PM, Dimitris
        Kalogeras wrote:<br>
      </div>
      <blockquote cite="mid:558026D2.3040808@noc.ntua.gr" type="cite">
        <meta content="text/html; charset=utf-8"
          http-equiv="Content-Type">
         Καλημέρα/σπέρα,<br>
        <br>
        επανέρχομαι στο θέμα και στο Link που είχε στείλει ο Σπύρος <br>
        (<a moz-do-not-send="true" 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>
        </span></blockquote>
      <br>
      Για το ΕΔΕΤ:<br>
      - Prefix filtering στα εισερχόμενα από τους πελάτες (route objects
      με origin από το AS (ή AS-SET) του πελάτη ή no export για more
      specific των route objects)<br>
      - AS-Path filtering στο GR-IX (παλιότερα κάναμε ό,τι και στους
      πελάτες, τώρα όχι λόγω τεχνικών δυσκολιών. Ίσως το επαναφέρουμε
      στο μέλλον)<br>
      - no filtering στον upstream<br>
      <br>
      Τα φίλτρα μας φτιάχνονται αυτόματα για v4 με RtConfig (...δηλαδή
      φτιάχνουμε όλο το φίλτρο, όχι μόνο το prefix/as list...αλλά
      δυστυχώς το εργαλείο έχει εγκαταλειφθεί και κάποια στιγμή θα το
      εγκαταλείψουμε και εμείς...). Για το v6 με το χέρι (δεν
      υποστηρίζεται σωστά από το rtconfig).<br>
      <br>
    </blockquote>
    OK to rt config δεν υποστηριζει τα routemaps αλλά υποστηριζεται η
    λειτουργία σε IPv6 από το peval οποτε εάν δεν προστίθεται νέο
    peering και αλλάζει απλά ο αριθμός των route objects (- πιο σύνηθες
    για τα δεδομένα της Ελλάδας) τοτε είναι οκ για τις ανάγκες.<br>
    <br>
    Αντρέα,<br>
     έχετε κάποιο τρόπο σύγκρισης να ελέγχετε οτι αυτό που έχετε στο
    δρομολογητή είναι το σωστό ? οποτε εάν γίνει λάθος<br>
    να μην σας εοδοποιήσουν άλλοι, αλλά να το πάρετε χαμπάρι μόνοι σας ?<br>
    <br>
    Χαιρετισμούς,<br>
    Δημήτρης<br>
    <blockquote cite="mid:55803367.6090606@noc.grnet.gr" type="cite"> <br>
      <blockquote cite="mid:558026D2.3040808@noc.ntua.gr" type="cite"><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);"> <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 moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:D.Kalogeras@noc.ntua.gr">D.Kalogeras@noc.ntua.gr</a>

</pre>
      </blockquote>
      <br>
      <br>
      <pre class="moz-signature" cols="72">-- 
-----------------------------------------------------------------------
Andreas Polyrakis - <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:apolyr@noc.grnet.gr">apolyr@noc.grnet.gr</a>
GRNET NOC Technical Manager
Greek Research & Technology Network - <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://www.grnet.gr">http://www.grnet.gr</a>
56, Mesogion Av., Ampelokipi, 11527 Athens, Greece
Mobile: +30 6972832445    Office: +30 2107474249   Fax: +30 2107474490
-----------------------------------------------------------------------
</pre>
    </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>