This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision Next revision Both sides next revision | ||
start [2020/09/07 18:48] alex [AWMN BGP φίλτρο] |
start [2023/02/17 13:44] 10.2.19.13 [iBGP problem explained] |
||
---|---|---|---|
Line 57: | Line 57: | ||
Ένα από τα βασικά εργαλεία, | Ένα από τα βασικά εργαλεία, | ||
- | ==== broken | + | ===== MikroTik |
**[[https:// | **[[https:// | ||
Line 136: | Line 136: | ||
| | ||
το φίλτρο που έχει προταθεί σαν RFC, το οποίο μπορεί να χρησιμοποιηθεί από όλες τις Ελληνικές ασύρματες κοινότητες που χρησιμοποιούν BGP πάνω στο δίκτυο 10.0.0.0/8 και που καλό είναι να εφαρμόζεται από όλους τους κόμβους κορμού σε κάθε εισερχόμενη και εξερχόμενη peer BGP σύνδεση: | το φίλτρο που έχει προταθεί σαν RFC, το οποίο μπορεί να χρησιμοποιηθεί από όλες τις Ελληνικές ασύρματες κοινότητες που χρησιμοποιούν BGP πάνω στο δίκτυο 10.0.0.0/8 και που καλό είναι να εφαρμόζεται από όλους τους κόμβους κορμού σε κάθε εισερχόμενη και εξερχόμενη peer BGP σύνδεση: | ||
+ | ===== MikroTik v7 C-class BGP aggregate ===== | ||
+ | |||
+ | Στο MikroTik v7, το **C-class** ενός κόμβου **ΔΕΝ** ανακοινώνεται αυτόματα, | ||
+ | |||
+ | Για να ξεπεραστεί το συγκεκριμένο πρόβλημα, | ||
+ | |||
+ | - Περνάμε ένα στατικό route του **C-class** δικτύου μας σαν **blackhole** | ||
+ | - Ενεργοποιούμε το **static** στο BGP, Output Redistribute | ||
+ | - Βεβαιώνουμε πως είναι ενεργοποιημένα, | ||
+ | |||
+ | Παράδειγμα: | ||
+ | |||
+ | εκτελούμε τα παρακάτω βήματα: | ||
+ | |||
+ | Routing --> BGP --> για κάθε νέα BGP σύνδεση ενεργοποιούμε στο Output Redistribute το static | ||
+ | | ||
+ | IP --> Routes --> προσθέτουμε το --> Dst. Address 10.30.30.0/ | ||
+ | | ||
+ | Υπάρχουν δυο ειδών **BGP** συνδέσεις. Η σύνδεση με απομακρυσμένο κόμβο λέγεται **eBGP**. Η σύνδεση με εσωτερικό router στο Local Area Network (LAN) λέγεται **iBGP**. | ||
+ | |||
+ | Το προτεινόμενο **AWMN** in/out φίλτρο μπαίνει **ΜΟΝΟ** στις **eBGP** --> στις εξωτερικές δηλαδή συνδέσεις/ | ||
+ | |||
+ | στις μεταξύ **iBGP** εσωτερικές συνδέσεις (LAN) του κόμβου, | ||
+ | |||
+ | οι σχετικές ρυθμίσεις από τερματικό/ | ||
+ | |||
+ | / | ||
+ | | ||
+ | για κάθε **BGP** σύνδεση, | ||
+ | |||
+ | για παράδειγμα, | ||
+ | |||
+ | / | ||
+ | / | ||
+ | / | ||
+ | / | ||
+ | / | ||
+ | | ||
+ | στις παραπάνω εντολές προσθέτουμε αναλόγως τον τύπο σύνδεσης: | ||
+ | |||
+ | role=ebgp | ||
+ | |||
+ | role=ibgp | ||
+ | |||
+ | επιπλέον πρέπει να ορίσουμε (στις παραπάνω εντολές), | ||
+ | |||
+ | remote.address=10.30.30.254/ | ||
+ | local.address=10.30.30.253 | ||
+ | |||
+ | σαν router id προτιμούμε (αν υπάρχει) την lan/ | ||
+ | | ||
+ | id=10.30.30.1 | ||
+ | | ||
+ | και η τελική εντολή: | ||
+ | | ||
+ | / | ||
+ | |||
+ | *** * Προσοχή ** ! στο τελευταίο βήμα θα πρέπει πάντα να βάζουμε το δίκτυό μας με το **/24** στο τέλος, ανεξάρτητα με το πως το έχουμε σπάσει σε μικρότερα | ||
+ | |||
+ | Σε περιπτώσεις προβλημάτων ασυμμετρίας στο εσωτερικό ενός κόμβου, | ||
+ | |||
+ | nexthop-choice=force-self | ||
+ | |||
+ | // | ||
+ | |||
===== MikroTik terminal setup for SupperQuagga ===== | ===== MikroTik terminal setup for SupperQuagga ===== | ||
- | /routing bgp peer add remote-as=22128 remote-address=10.2.146.10 multihop=yes passive=yes | + | /routing bgp peer add remote-as=22128 remote-address=10.2.146.10 multihop=yes passive=yes |
+ | |||
+ | /routing bgp peer print | ||
+ | |||
+ | για **v7**: | ||
+ | |||
+ | / | ||
+ | |||
+ | / | ||
+ | |||
+ | Παράδειγμα: | ||
+ | ==== MikroTik BGP log filter ==== | ||
+ | Σε περίπτωση που δεν θέλουμε να γεμίζουν τα **logs** με **bgp** μυνήματα από τη SupperQuagga, | ||
+ | |||
+ | /system logging set [find where topics=" | ||
+ | /system logging set [find where topics=" | ||
+ | ===== Quagga setup for SupperQuagga ===== | ||
+ | neighbor 10.2.146.10 remote-as 22128 | ||
+ | neighbor 10.2.146.10 ebgp-multihop | ||
+ | neighbor 10.2.146.10 prefix-list awmn-null in | ||
+ | neighbor 10.2.146.10 prefix-list awmn-bgp out | ||
+ | ! | ||
+ | ip prefix-list awmn-bgp seq 10 permit 10.0.0.0/8 ge 9 le 24 | ||
+ | ip prefix-list awmn-bgp seq 15 permit 10.0.0.0/15 le 32 | ||
+ | ip prefix-list awmn-bgp seq 20 deny any | ||
+ | ip prefix-list awmn-null seq 20 deny any | ||
+ | |||
+ | ===== Bird setup for SupperQuagga ===== | ||
+ | protocol bgp { | ||
+ | export filter awmn; | ||
+ | import none; | ||
+ | |||
+ | local as 3298; | ||
+ | neighbor 10.2.146.10 as 22128; | ||
+ | multihop; | ||
+ | } | ||
+ | |||
+ | η διαδικασία ολοκληρώνεται με ένα email στο alex_παπάκι_ozo.com με το IP και το AS του κάθε ρούτερ που πρόκειται να συμμετάσχει στην SupperQuagga. | ||
+ | |||
+ | **Περί Ασφάλειας** στην SupperQuagga αποστέλλεται ακριβώς και μόνο η ίδια πληροφορία με αυτή που στέλνεται προς τους γειτονικούς κόμβους για το AWMN. Αντίστοιχα η SupperQuagga έχει φίλτρα στα εισερχόμενα για αποκλειστικά και μόνο δίκτυα AWMN. Επιπλέον δεν στέλνει απολύτως καμία πληροφορία προς τις συνδέσεις της, κάτι που διασφαλίζεται και με ένα προαιρετικό φίλτρο none στο IN του BGP μαζί της. | ||
+ | |||
+ | ** Είναι τελείως ακίνδυνη χωρίς να καταναλώνει επιπλέον πόρους στο σύστημα που συμμετέχει σε αυτήν. ** | ||
+ | |||
+ | στατιστικά από την SPQ για το πανελλαδικό BGP [[http:// | ||
+ | |||
+ | Η Supper Quagga τρέχει την έκδοση quagga-1.2.4 η οποία αναβαθμίζεται σε κάθε νέα έκδοση όταν αυτή είναι διαθέσιμη. | ||
+ | |||
+ | Τα εργαλεία της SupperQuagga δίνουν την δυνατότητα για μια πιο εύκολη και σε βάθος ανάλυση σχετικά με το BGP που κυκλοφορεί στις διασυνδεδεμένες μεταξύ τους ασύρματες κοινότητες. Είναι ένα πολυ-εργαλείο που μπορεί μαθησιακά να βοηθήσει στην καλύτερη κατανόηση του πως ακριβώς δουλεύει το BGP, τα προβλήματα και τις δυνατότητες που έχει, πάνω σε ένα πραγματικό και ζωντανό δίκτυο. | ||
+ | |||
+ | αν καταφέρουμε να χαρτογραφήσουμε πιο ορθά το BGP θα έχουμε και μια πιο έγκυρη εικόνα με τους πραγματικούς κόμβους ραχοκοκαλιάς του AWMN | ||
+ | |||
+ | * Μια πολύ ενδιαφέρουσα και χρήσιμη υπηρεσία, | ||
===== Μερικές οδηγίες χρήσης του εργαλείου ===== | ===== Μερικές οδηγίες χρήσης του εργαλείου ===== | ||
Line 146: | Line 262: | ||
ένα ερώτημα προβληματισμός που εγείρεται είναι γιατί αυτοί οι τερματικοί κόμβοι να στέλνουν BGP στην δρομολόγηση και να μην λειτουργούν απλά με ένα static route. Αυτό εξάλλου είναι ορθά και εκτός προδιαγραφών AWMN (δηλαδή τερματικοί κόμβοι & BGP). | ένα ερώτημα προβληματισμός που εγείρεται είναι γιατί αυτοί οι τερματικοί κόμβοι να στέλνουν BGP στην δρομολόγηση και να μην λειτουργούν απλά με ένα static route. Αυτό εξάλλου είναι ορθά και εκτός προδιαγραφών AWMN (δηλαδή τερματικοί κόμβοι & BGP). | ||
- | ===== BGP log φίλτρο ===== | ||
- | Σε περίπτωση που δεν θέλουμε να γεμίζουν τα **logs** με **bgp** μυνήματα από τη SupperQuagga, | ||
- | /system logging set [find where topics=" | ||
- | /system logging set [find where topics=" | ||
===== eBGP & iBGP ===== | ===== eBGP & iBGP ===== | ||
Line 163: | Line 275: | ||
σε αυτές τις εσωτερικές **iBGP** συνδέσεις ΔΕΝ θα πρέπει να βάζουμε **κανένα** φίλτρο, | σε αυτές τις εσωτερικές **iBGP** συνδέσεις ΔΕΝ θα πρέπει να βάζουμε **κανένα** φίλτρο, | ||
- | ===== AWMN BGP φίλτρο ===== | + | |
+ | επιπλέον, | ||
+ | |||
+ | ==== iBGP problem explained | ||
+ | το πρόβλημα με το **iBGP** έχει να κάνει με το σπάσιμο του τοπικού **C-class** σε μικρότερα υποδίκτυα τα οποία χρησιμοποιούμε για τις **WAN** συνδέσεις (**BB** link). σε αυτές τις περιπτώσεις, | ||
+ | |||
+ | επιπλέον, | ||
+ | |||
+ | το **awmn BGP** φίλτρο το χρησιμοποιούμε **ΜΟΝΟ** σε **eBGP** συνδέσεις, | ||
+ | === iBGP troubleshoot === | ||
+ | ένας απλός & σίγουρος τρόπος για να εντοπίσουμε αν υπάρχει πρόβλημα σωστής **iBGP** επικοινωνίας σε έναν κόμβο που τρέχει πάνω από έναν **BGP** speaker είναι, να κάνουμε **ping** σε ένα **IP** ενός **/30** ή **/29** υποδικτύου που έχουμε κόψει από το δικό μας **C-class** για χρήση **wan/BB**, από τους άλλους τοπικούς **BGP** speakers του τοπικού μας δικτύου (αυτούς που **ΔΕΝ** έχουν σε **WAN** σύνδεση αυτό το **wan/BB** υποδίκτυο αλλά οφείλουν να το γνωρίζουν. αν το **ping** λειτουργεί, | ||
+ | ===== AWMN BGP filter | ||
Ακολουθεί το προτεινόμενο φίλτρο καλής χρήσης & προστασίας του **BGP** για το **AWMN** το οποίο επιβάλεται να έχουμε σε κάθε BGP με ασυρματική ζεύξη/ | Ακολουθεί το προτεινόμενο φίλτρο καλής χρήσης & προστασίας του **BGP** για το **AWMN** το οποίο επιβάλεται να έχουμε σε κάθε BGP με ασυρματική ζεύξη/ | ||
Line 173: | Line 296: | ||
add action=accept chain=awmn prefix=10.0.0.0/ | add action=accept chain=awmn prefix=10.0.0.0/ | ||
add action=discard chain=awmn | add action=discard chain=awmn | ||
+ | | ||
+ | για **v7**: | ||
+ | |||
+ | / | ||
+ | / | ||
| | ||
Στην τοποθεσία Routing--> | Στην τοποθεσία Routing--> | ||
Line 178: | Line 306: | ||
Το παραπάνω φίλτρο αποκλείει τις μαύρες τρύπες που ακυρώνουν τον δυναμικό, | Το παραπάνω φίλτρο αποκλείει τις μαύρες τρύπες που ακυρώνουν τον δυναμικό, | ||
- | ===== Σωστή χρήση | + | ===== AWMN NAT/ |
** * * * Προσοχή * * * ** στην χρήση του **NAT/ | ** * * * Προσοχή * * * ** στην χρήση του **NAT/ | ||
Line 214: | Line 342: | ||
- Απενεργοποίηση [[https:// | - Απενεργοποίηση [[https:// | ||
- Απενεργοποίηση [[https:// | - Απενεργοποίηση [[https:// | ||
+ | |||
+ | ===== Mikrotik DNS Setup ===== | ||
+ | |||
+ | /ip dns set allow-remote-requests=yes | ||
+ | |||
+ | Το παρακάτω, | ||
+ | |||
+ | /ip dns set servers=8.8.8.8, | ||
+ | /ip dns static add forward-to=10.19.143.12 regexp=" | ||
+ | |||
+ | Προσθέτουμε τα ονόματα του κόμβου μας (για παράδειγμα, | ||
| | ||
+ | /ip dns static add name=router.soleo.awmn address=10.38.128.5 | ||
+ | | ||
+ | για τις wifi (BB link) συνδέσεις, | ||
+ | | ||
+ | /ip dns static add name=gw-makofo.soleo.awmn address=10.38.128.249 | ||
+ | /ip dns static add name=gw-soleo.makofo.awmn address=10.38.128.250 | ||
+ | | ||
+ | **Προσοχή**, | ||
+ | |||
+ | Αν θέλουμε να δώσουμε **επιπλέον** ονομασίες σε μια **IP**, ο σωστός & προτεινόμενος τρόπος είναι ο πιο κάτω: | ||
+ | |||
+ | /ip dns static add name=alias.soleo.awmn type=CNAME cname=router.soleo.awmn | ||
+ | | ||
+ | με τον παραπάνω τρόπο, όταν δίνουμε (για επίλυση σε όνομα) μια **IP**, για παράδειγμα: | ||
+ | |||
+ | όλες οι επιπλέον ονομασίες ορισμένες σαν **CNAME** θα αντιστοιχούν στον **router.soleo.awmn** δηλαδή --> **10.38.128.5** | ||
+ | | ||
+ | ===== Asymmetric routing & UDP ===== | ||
+ | |||
+ | η ανάπτυξη του **AWMN** δικτύου είναι βασισμένη σε κόμβους με πολλαπλές συνδέσεις, | ||
+ | |||
+ | There is nothing tinc can do here. Either make sure you don't do | ||
+ | asymetric routing, or change your firewall rules to not do stateful | ||
+ | filtering of TCP connections | ||
+ | | ||
+ | ανατρέχοντας στις [[https:// | ||
+ | |||
+ | /ip firewall filter | ||
+ | add chain=input connection-state=invalid action=drop comment=" | ||
+ | add chain=input connection-state=established, | ||
+ | ** | ||
+ | //__Such a rule set must not be applied on routers with asymmetric routing, because asymmetrically routed packets may be considered invalid and dropped__// | ||
+ | |||
+ | οπότε αν θέλουμε το **DNS** που τρέχουμε να λειτουργεί σε **όλο** το δίκτυο, | ||
+ | |||
+ | /ip firewall filter | ||
+ | del chain=input connection-state=established, | ||
+ | del chain=input connection-state=invalid action=drop comment=" | ||
+ | | ||
+ | το παρακάτω παράδειγμα δείχνει καθαρά το πρόβλημα: | ||
+ | |||
+ | In BGP | ||
+ | 5 7413 8345 7430 9936 3298 | ||
+ | 5 7413 11087 7430 9936 3298 | ||
+ | | ||
+ | ο κόμβος 7413 μπορεί να πάρει udp/dns αποκρίσεις & στην περίπτωση που ο κόμβος 3298 είχε stateful firewall, μια και η εισερχόμενη διαδρομή είναι ίδια με την εξερχόμενη (δηλαδή μέσα από τον κόμβο 9936) | ||
+ | |||
+ | ο κόμβος 3298 όμως ΔΕΝ μπορεί να λάβει udp/dns αποκρίσεις διότι το stateful firewall του κόμβου 7413 κόβει κάθε connectionless (udp) κίνηση που έχει ασυμμετρία. στην προκειμένη ο 3298 διαλέγει την συγκεκριμένη διαδρομή προς 7413 | ||
+ | |||
+ | 3298 9936 7430 8345 7413 | ||
+ | | ||
+ | ενώ ο κόμβος 7413 την διαδρομή: | ||
+ | |||
+ | 7413 11087 7430 9936 3298 | ||
+ | | ||
+ | ===== BGPmap Tips & Tricks ===== | ||
+ | | ||
+ | ==== 3D map @ AWMN ==== | ||
+ | |||
+ | - πάμε στο http:// | ||
+ | - στο δεξί δεξί menu κάτω εκεί που λέει Search Node βάζουμε (παράδειγμα) virtual & πατάμε enter | ||
+ | - θα μας ανοίξει από κάτω (δεξιά) ένα menu, στο κάτω μέρος πατάμε το View node in 3D mode | ||
+ | - κάτω δεξιά πατάμε την υδρόγειο για να μας ανοίξει το 3D | ||
+ | - η ρόδα του ποντικιού, | ||
+ | - το αριστερό κουμπί του ποντικιού ελέγχει την οριζόντια πλοήγηση | ||
+ | - το αριστερό κουμπί του ποντικιού με το Ctrl πατημένο ελέγχει την κάθετη πλοήγηση | ||
+ | |||
+ | //happy 3D flying// | ||
+ | |||
+ | ==== BGP Trace ==== | ||
+ | |||
+ | - στο δεξί παράθυρο (Control center), πηγαίνουμε στο Trace Route | ||
+ | - βάζουμε είτε με όνομα κόμβου είτε με αριθμό AS τους κόμβους που μας ενδιαφέρει να εξετάσουμε | ||
+ | - πατάμε την ένδειξη Show route | ||
+ | |||
+ | η παραπάνω διαδικασία: | ||
+ | |||
+ | - θα απαριθμήσει τους κόμβους από τους οποίους περνάει η σύνδεση αυτών των δυο κόμβων | ||
+ | - θα αποτυπώσει πάνω στον χάρτη με μπλε χρώμα τις παραπάνω διαδρομές | ||
+ | - στο δεξί μενού με την ένδειξη Possible Route(s), θα εμφανίσει την διαδρομή με όλα τα AS (κόμβους) που μεσολαβούν | ||
+ | |||
+ | πατώντας σε κάθε AS κόμβο, η πλοήγηση μεταφέρεται αυτόματα στον συγκεκριμένο κόμβο για περαιτέρω εξέταση | ||