====== BGP hacks & tools ====== [[http://spq.ozo.com/ | SupperQuagga ]] is an attempt to ease the process of BGP troubleshooting with live multi-node passive peering, offering accurate network mapping, and a comprehensive variety of bgp forensics tools around the **AWMN** routing. [[http://spq.ozo.com/ | SupperQuagga]] is further powering [[http://bgpmap.ozo.com/ | BGPmap]], [[http://bgpnms.ozo.com/ | BGPnms]] & [[http://dev.ozo.com/live/ |AWMN Dancing BGP]]. ===== AWMN, an open & free wireless network ===== **AWMN**, established back in 2002 is a small Internet that is run & managed by its users only. No commercial companies or government/academic foundations are involved. It's a purely amateur initiative, ideal for, besides the zero-cost connectivity, experimenting & learning playground. It also serves as a magnet in maintaining a verity of different people [[http://www.awmn.net/album.php?albumid=140218&attachmentid=35950 | together]]. The audience & the community of this initiative, is exclusively Hellenic thereof further language use will be switched to Greek. Το **AWMN** ξεκίνησε το 2002 και είναι ένα μικρό Internet αποτελούμενο από τους χρήστες του και μόνο. Δεν υπάρχουν εμπορικοί, κρατικοί ή ακαδιμαικοί οργανισμοί, μεσάζοντες ή εταιρίες. Είναι ένα καθαρά ερασιτεχνικό εγχείρημα, ιδανικό, πέρα από το μηδενικό κόστος διασυνδεσιμότητας, για πειραματισμό και εκμάθηση. Επιπλέον [[http://www.awmn.net/album.php?albumid=140218&attachmentid=35950 | συγκεντρώνει & συσπειρώνει]] ένα μεγάλο εύρος διαφορετικών ανθρώπων. ====== Ιστορικό ====== ===== Supper Quagga Day 1 ===== **Οι παρακάτω οδηγίες δεν ισχύουν πλέον. αποτελούν αρχειακό υλικό.** To: awmn@googlegroups.com Date: 2016-01-14 08:41 supper quagga: προσπάθεια εντοπισμού φαντασμάτων και λανθασμένων ρυθμίσεων στο BGP του AWMN, άλλη μια νέα υπηρεσία powered by http://www.stats.awmn & http://www.routers.awmn/ http://www.routers.awmn/index.php?section=lg&bgp_router=383&bgp_command=1&filter_neig_ip=&filter_as_operator=&filter_asn=&filter_prefix= για μπρίκι: - βάζεις για γείτονα στο BGP τον 10.2.19.3 - AS 3298 - επιλέγεις multihop - φίλτρο στην έξοδο/out το ίδιο που βάζουμε με τους γείτονες για το awmn - φίλτρο στην είσοδο/in none για quagga: ip prefix-list awmn-null seq 20 deny any neighbor 10.2.19.3 remote-as 3298 neighbor 10.2.19.3 ebgp-multihop neighbor 10.2.19.3 prefix-list awmn-null in στείλε μου IP & AS από τους router που θα συμμετάσχουν στην supper quagga να τους προσθέσω καμιά ευαίσθητη εσωτερική πληροφορία δεν "διαρρέει" αφού ότι ανακοινώνεις στο BGP στο AWMN απλά το περνάς και στην supper quagga και απαγορεύεις να σου περάσει τίποτα πίσω !! προώθησέ το παντού, είναι για καλό σκοπό !! όσοι περισσότεροι τόσο καλύτερα !! ====== MikroTik broken software ====== Αν και οι περισσότεροι εναπομείναντες του AWMN θεωρούν πως η MikroTik βοήθησε το δίκτυο στην εξάπλωσή του, στην ουσία το τίναξε στον αέρα. Εξουδετέρωσε το αρχικό πνεύμα συνεργασίας με οδηγούς γύρω από ανοιχτές πλατφόρμες, αρχιτεκτονικές και λογισμικό και ώθησε τον κόσμο σε black boxes τα οποία πολλές φορές είχαν προβλήματα που όπως θα δούμε πήραν πάνω από 4-5 χρόνια να λυθούν, ενώ άλλα παραμένουν και καταδυναστεύουν το δίκτυο μέχρι και σήμερα. Το μεγαλύτερο πρόβλημα, το οποίο παραμένει μέχρι σήμερα, έχει να κάνει με τον τρόπο που η MikroTik διαχειρίζεται το IP routing ειδικά στο BGP που χρησιμοποιούμε στο AWMN. Αυτό το πρόβλημα δημιούργησε τουλάχιστον τρία με τέσσερα blackout στην δρομολόγηση με το BGP να σκάει από άκρη σε άκρη σε όλο το δίκτυο. Σήμερα παραμένει να διατηρεί διαδρομές οι οποίες δεν είναι ενεργές και τις οποίες αποκαλούμε φαντάσματα. το Ιστορικό ξεκινά από το 2007. Στο forum της MikroTik [[https://forum.mikrotik.com/viewtopic.php?f=14&t=57781|υπάρχει μια ενότητα]] που ξεκινά το 2011 και η οποία μετά από τρία χρόνια, το 2014 δεν έχει λυθεί. Το πρόβλημα μεταφέρεται [[https://forum.mikrotik.com/viewtopic.php?f=14&t=78107|σε άλλη ενότητα]] η οποία ξεκινά το 2013 και συνεχίζεται μέχρι το 2019 χωρίς ακόμη να έχουν λυθεί τα αναφερόμενα προβλήματα. Ένα από τα βασικά εργαλεία, μεταξύ άλλων, που παρέχει η [[http://www.ozo.com/lgsp|SupperQuagga]] είναι ο εντοπισμός της πηγής δημιουργίας τέτοιων φαντασμάτων με το [[http://www.ozonet.awmn/lgsp/?command=ghost-detector&protocol=ipv4&query=&router=supperquagga|bgp ghost-detector]]. ===== MikroTik software issues [forum archives] ===== **[[https://forum.mikrotik.com/viewtopic.php?f=14&t=57781|Stuck Routes on Route Cache]]** gustkiller Tue Dec 20, 2011 11:57 pm Hi, Every now and them we got that problem. Today another AS network engineer called me becouse his IP prefix couldnt reach our prefixes. After troubleshooting he told me that they lost they connection in a national wide IXP and when doing a traceroute from our bgp router, the next hop showed was our IXP ip address. After checking the routes, we're receiving their routes via another service provider but RouterOS were trying to get to them via a cached route that doesnt even exists anymore. To fix the problem we have to disable the IXP interface on our router and them reenable it. After that RouterOS finnaly forgot the route and them everything started to work. Anyone more having that problem? Is there any command to clear routing cache? Thanks! ... Pengu1n Mon Oct 13, 2014 11:25 am Is there any news about fixing this bug? Still have problems with CCR1016-12G and RB751G-2HnD on 6.20 We are using OSPF and IPSEC. **[[https://forum.mikrotik.com/viewtopic.php?f=14&t=78107|ip route cache BUG]]** ujin Tue Oct 22, 2013 2:13 pm The problem is following: The oldest entries are not flushed from cache. During one day we got: /ip route cache print cache-size: 52442 max-cache-size: 65536 This bug is observed only on OS version 6.x. OS version 5.x did not have such issue. Please provide workaround HOW TO FLUSH CACHE. ... cgood Fri Mar 15, 2019 12:05 pm >> Currently it is known that OVPN interface reconnects are responsible for route cache leaks. Hello, how to fix this issue? Mikrotik CHR -> ip route cache full 512k .. OVPN/L2TP server ====== SupperQuagga Introduction ====== η Supper Quagga ή αλλιώς: BGP αξονικός τομογράφος του AWMN, γεννήθηκε ως ανάγκη να έχουμε μια καλύτερη εικόνα του τι πραγματικά συμβαίνει στην δρομολόγηση BGP του δικτύου μας. Αποτελεί ένα επιπλέον εργαλείο που στόχο έχει να βοηθήσει στον εντοπισμό λανθασμένων ρυθμίσεων η άλλων προβλημάτων στο BGP που όλοι τρέχουμε και περνάει από τους κόμβους μας. * Η στήριξή της Supper Quagga με την συμμετοχή κόμβων σε αυτήν, είναι ιδιαίτερα σημαντική για την εγκυρότητα και αποτελεσματικότητα της εικόνας του δικτύου. Καλούμε τον κάθε ένα που ενδιαφέρεται για την καλή λειτουργία του δικτύου να συμμετέχει σε αυτήν με την απλή διαδικασία που ακολουθεί παρακάτω. * __**ΕΓΚΑΤΑΣΤΑΣΗ:**__ τα στοιχεία της Supper Quagga είναι: για MikroTik, δημιουργούμε ένα νέο peer στο BGP με την ονομασία supperquagga με τα ακόλουθα στοιχεία: IP: 10.2.146.10 AS: 22128 multihop είναι σημαντικό να επιλεχθεί το πεδίο multihop. !!--> προσοχή το συγκεκριμένο πεδίο πρέπει να είναι ενεργό ΜΟΝΟ για τον peer supperquagga Προαιρετικά εισάγουμε τα παρακάτω φίλτρα: !!--> δεν αποτελεί απαραίτητη προϋπόθεση filter-in: none filter-out: awmn (μόνο αν το έχουμε ενεργό για κάθε wifi λινκ) το φίλτρο που έχει προταθεί σαν RFC, το οποίο μπορεί να χρησιμοποιηθεί από όλες τις Ελληνικές ασύρματες κοινότητες που χρησιμοποιούν BGP πάνω στο δίκτυο 10.0.0.0/8 και που καλό είναι να εφαρμόζεται από όλους τους κόμβους κορμού σε κάθε εισερχόμενη και εξερχόμενη peer BGP σύνδεση: ** δεν αποτελεί απαραίτητη προϋπόθεση ** ===== MikroTik v7 C-class BGP aggregate ===== Στο MikroTik v7, το **C-class** ενός κόμβου **ΔΕΝ** ανακοινώνεται αυτόματα, όταν το έχουμε χωρίσει σε μικρότερα **subnets**. Η σχετική αναφορά της Mikrotik βρίσκεται [[https://help.mikrotik.com/docs/display/ROS/Moving+from+ROSv6+to+v7+with+examples#MovingfromROSv6tov7withexamples-Networks|εδώ]]. Για να ξεπεραστεί το συγκεκριμένο πρόβλημα, θα πρέπει να ακολουθηθούν τα παρακάτω βήματα: - Περνάμε ένα στατικό route του **C-class** δικτύου μας σαν **blackhole** - Ενεργοποιούμε το **static** στο BGP, Output Redistribute - Βεβαιώνουμε πως είναι ενεργοποιημένα, στα εξωτερικά **ΜΟΝΟ** λινκ (**eBGP**), σε in/out το προτεινόμενο **AWMN** φίλτρο Παράδειγμα: έστω πως το **C-class** δίκτυό μας είναι το: 10.30.30.0/24 εκτελούμε τα παρακάτω βήματα: Routing --> BGP --> για κάθε νέα BGP σύνδεση ενεργοποιούμε στο Output Redistribute το static IP --> Routes --> προσθέτουμε το --> Dst. Address 10.30.30.0/24 & ενεργοποιούμε ΜΟΝΟ το Blackhole Υπάρχουν δυο ειδών **BGP** συνδέσεις. Η σύνδεση με απομακρυσμένο κόμβο λέγεται **eBGP**. Η σύνδεση με εσωτερικό router στο Local Area Network (LAN) λέγεται **iBGP**. Το προτεινόμενο **AWMN** in/out φίλτρο μπαίνει **ΜΟΝΟ** στις **eBGP** --> στις εξωτερικές δηλαδή συνδέσεις/λινκ του κόμβου. στις μεταξύ **iBGP** εσωτερικές συνδέσεις (LAN) του κόμβου, δεν περνάμε **ΚΑΝΕΝΑ** φίλτρο. οι σχετικές ρυθμίσεις από τερματικό/ssh είναι: /routing/bgp/connection/set output.redistribute=static,bgp hold-time=30s keepalive-time=10s numbers=0 για κάθε **BGP** σύνδεση, θα πρέπει να ορίσουμε τα παραπάνω αλλάζοντας το numbers= για παράδειγμα, αν έχουμε ένα router με **πέντε** (**5**) BGP συνδέσεις, θα πρέπει να δώσουμε την εντολή στην παρακάτω μορφή: /routing/bgp/connection/set output.redistribute=static,bgp hold-time=30s keepalive-time=10s numbers=0 /routing/bgp/connection/set output.redistribute=static,bgp hold-time=30s keepalive-time=10s numbers=1 /routing/bgp/connection/set output.redistribute=static,bgp hold-time=30s keepalive-time=10s numbers=2 /routing/bgp/connection/set output.redistribute=static,bgp hold-time=30s keepalive-time=10s numbers=3 /routing/bgp/connection/set output.redistribute=static,bgp hold-time=30s keepalive-time=10s numbers=4 στις παραπάνω εντολές προσθέτουμε αναλόγως τον τύπο σύνδεσης: role=ebgp role=ibgp επιπλέον πρέπει να ορίσουμε (στις παραπάνω εντολές), για κάθε σύνδεση, τα σχετικά παρακάτω πεδία: remote.address=10.30.30.254/32 local.address=10.30.30.253 σαν router id προτιμούμε (αν υπάρχει) την lan/ethernet IP του router: id=10.30.30.1 και η τελική εντολή: /ip/route/add blackhole dst-address=10.30.30.0/24 *** * Προσοχή ** ! στο τελευταίο βήμα θα πρέπει πάντα να βάζουμε το δίκτυό μας με το **/24** στο τέλος, ανεξάρτητα με το πως το έχουμε σπάσει σε μικρότερα Σε περιπτώσεις προβλημάτων ασυμμετρίας στο εσωτερικό ενός κόμβου, βοηθάει στο μεταξύ **iBGP** τοπικών router, να ενεργοποιηθεί η επιλογή: nexthop-choice=force-self //Ευχαριστώ τον Δημήτρη (**dgi**) για την πρόσβαση σε MikroTik v7 για τις σχετικές δοκιμές// ===== MikroTik terminal setup for SupperQuagga ===== /routing bgp peer add remote-as=22128 remote-address=10.2.146.10 multihop=yes passive=yes name=spq hold-time=180s keepalive-time=60s /routing bgp peer print για **v7**: /routing/bgp/connection add remote.as=22128 as=local_awmn_AS local.address=local_lan_ethernet_ip local.role=ebgp remote.address=10.2.146.10 multihop=yes listen=yes name=spq /routing/bgp/connection/print Παράδειγμα: κόμβος 3298, δίκτυο 10.2.19.0/24. as=3298 local.address=10.2.19.65 **! ! !** --> σαν **router id** προτιμούμε (αν υπάρχει) την lan/ethernet IP του router ==== MikroTik BGP log filter ==== Σε περίπτωση που δεν θέλουμε να γεμίζουν τα **logs** με **bgp** μυνήματα από τη SupperQuagga, οι παρακάτω εντολές φιλτράρουν τα συγκεκριμένα μυνήματα από τα log /system logging set [find where topics="error"] topics="error,!bgp" /system logging set [find where topics="info"] topics="info,!bgp" ===== 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://nmsbgp.ozo.com/|nmsBGP]]. Η Supper Quagga τρέχει την έκδοση quagga-1.2.4 η οποία αναβαθμίζεται σε κάθε νέα έκδοση όταν αυτή είναι διαθέσιμη. Τα εργαλεία της SupperQuagga δίνουν την δυνατότητα για μια πιο εύκολη και σε βάθος ανάλυση σχετικά με το BGP που κυκλοφορεί στις διασυνδεδεμένες μεταξύ τους ασύρματες κοινότητες. Είναι ένα πολυ-εργαλείο που μπορεί μαθησιακά να βοηθήσει στην καλύτερη κατανόηση του πως ακριβώς δουλεύει το BGP, τα προβλήματα και τις δυνατότητες που έχει, πάνω σε ένα πραγματικό και ζωντανό δίκτυο. αν καταφέρουμε να χαρτογραφήσουμε πιο ορθά το BGP θα έχουμε και μια πιο έγκυρη εικόνα με τους πραγματικούς κόμβους ραχοκοκαλιάς του AWMN * Μια πολύ ενδιαφέρουσα και χρήσιμη υπηρεσία, που βασίζεται στα δεδομένα της Supper Quagga, ζωντανής απεικόνισης και χαρτογράφησης όλων των Πανελλαδικών Ασύρματων κοινοτήτων που έχουν διασυνδεθεί μεταξύ τους είναι το [[http://bgpmap.ozo.com/|BGPmap]] που με πολύ όρεξη και ώρες εργασίας έφτιαξε συντηρεί ναι αναπτύσσει ο κόμβος #9895 geolos τον οποίο ευχαριστώ θερμά για την υποστήριξη και προσφορά του στην κοινότητά μας ===== Μερικές οδηγίες χρήσης του εργαλείου ===== μέσα από το γραφικό περιβάλλον της [[http://spq.ozo.com/|Supper Quagga]] μπορούμε να έχουμε μια γρήγορη και εύκολη εικόνα με το ποιοι κόμβοι ανεβοκατεβαίνουν πολλές φορές μέσα στην ημέρα δημιουργώντας πιθανά προβλήματα στην δρομολόγηση. αυτό που παρατηρεί κάποιος εξετάζοντας το φαινόμενο των [[http://www.ozonet.awmn/lgsp/?command=top-flappers&protocol=ipv4&query=&router=supperquagga|flaps στο BGP]] είναι ότι συνήθως πρόκειται για τερματικούς κόμβους που δεν επηρεάζουν τη γενικότερη δρομολόγηση του δικτύου (απλά ρυπαίνουν το BGP με την προβληματική συμπεριφορά τους). ένα ερώτημα προβληματισμός που εγείρεται είναι γιατί αυτοί οι τερματικοί κόμβοι να στέλνουν BGP στην δρομολόγηση και να μην λειτουργούν απλά με ένα static route. Αυτό εξάλλου είναι ορθά και εκτός προδιαγραφών AWMN (δηλαδή τερματικοί κόμβοι & BGP). ===== eBGP & iBGP ===== το **BGP** έχει δυο κατηγορίες: **eBGP** & **iBGP** το **eBGP** σημαίνει external **BGP** και είναι αυτό που συνδέουμε τον κόμβο μας με άλλους απομακρυσμένους κόμβους (τα **BB** λινκ που λέμε). σε αυτού του είδους τις συνδέσεις **και ΜΟΝΟ** περνάμε το προτεινόμενο **awmn BGP** φιλτρο. το **iBGP** σημαίνει internal **BGP** και είναι αυτό που συνδέουμε δικούς μας εσωτερικούς **router** στον **ίδιο** κόμβο μεταξύ τους δηλαδή για παράδειγμα, έχουμε ένα **alix**, ένα **rb433AH** & ένα **groove** και τρέχουμε σε κάθε ένα από αυτά **BGP** τα οποία συνδέουμε μεταξύ τους (αυτή η μεταξύ τους τοπική σύνδεση την αποκαλούμε **iBGP** --> εσωτερική, internal) σε αυτές τις εσωτερικές **iBGP** συνδέσεις ΔΕΝ θα πρέπει να βάζουμε **κανένα** φίλτρο, ούτε το **awmn BGP** φίλτρο επιπλέον, καλό είναι να ενεργοποιούμε στο **BGP** την επιλογή **Redistribute connected** & **client-to-client-reflection** ==== iBGP problem explained ==== το πρόβλημα με το **iBGP** έχει να κάνει με το σπάσιμο του τοπικού **C-class** σε μικρότερα υποδίκτυα τα οποία χρησιμοποιούμε για τις **WAN** συνδέσεις (**BB** link). σε αυτές τις περιπτώσεις, όταν έχουμε πάνω από εναν κεντρικό **BGP** speaker στον κόμβο (**LAN**), συνήθως οι άλλοι **BGP** routers αγνοούν την ύπαρξη του τοπικού **wan/BB** υποδικτύου. παλιά, αυτό αντιμετωπίζονταν με την παράλληλη χρήση ενός **IGP** routing όπως το **OSPF**, **RIP** ή & **static** routes. πλέον, οι σύγχρονες **BGP** εκδόσεις, έχουν την δυνατότητα να ανακοινώνουν αυτά τα εσωτερικά υποδίκτυα, αρκεί να μην φιλτράρεται η συγκεκριμένη πληροφορία. οπότε σε αυτές τις περιπτώσεις, δεν θα πρέπει να εισάγουμε **κανένα** φίλτρο μεταξύ των τοπικών **BGP** συνδέσεων στο **LAN** ενός κόμβου. επιπλέον, στους **router** πάνω στο **LAN** μεταξύ τους, ορίζουμε το **next-hop** σαν **force-self** & ΟΧΙ **default** το **awmn BGP** φίλτρο το χρησιμοποιούμε **ΜΟΝΟ** σε **eBGP** συνδέσεις, αυτές με άλλους απομακρυσμένους κόμβους, ώστε να μην ανακοινώνουμε στο γενικό **BGP** υποδίκτυα μικρότερα του **C-class**, και γενικά να θωρακίζουμε/φιλτράρουμε την πληροφορία του **BGP** από λανθασμένες ρυθμίσεις ή κακόβουλες ενέργειες. === iBGP troubleshoot === ένας απλός & σίγουρος τρόπος για να εντοπίσουμε αν υπάρχει πρόβλημα σωστής **iBGP** επικοινωνίας σε έναν κόμβο που τρέχει πάνω από έναν **BGP** speaker είναι, να κάνουμε **ping** σε ένα **IP** ενός **/30** ή **/29** υποδικτύου που έχουμε κόψει από το δικό μας **C-class** για χρήση **wan/BB**, από τους άλλους τοπικούς **BGP** speakers του τοπικού μας δικτύου (αυτούς που **ΔΕΝ** έχουν σε **WAN** σύνδεση αυτό το **wan/BB** υποδίκτυο αλλά οφείλουν να το γνωρίζουν. αν το **ping** λειτουργεί, τότε δεν υπάρχει το **iBGP** πρόβλημα. σε διαφορετική περίπτωση, το πρόβλημα υπάρχει & θα πρέπει να διερευνηθεί & λυθεί. ===== AWMN BGP filter ===== Ακολουθεί το προτεινόμενο φίλτρο καλής χρήσης & προστασίας του **BGP** για το **AWMN** το οποίο επιβάλεται να έχουμε σε κάθε BGP με ασυρματική ζεύξη/λινκ. Ανοίγουμε ένα Terminal δίνουμε τις παρακάτω εντολές: /routing filter add action=discard chain=awmn bgp-as-path-length=!0-28 add action=accept chain=awmn prefix=10.0.0.0/8 prefix-length=24 add action=accept chain=awmn prefix=10.0.0.0/15 prefix-length=32 add action=discard chain=awmn για **v7**: /routing filter rule add chain=awmn rule="if (dst in 10.0.0.0/8 && dst-len==24 && bgp-path-len<27) { accept; }" /routing filter rule add chain=awmn rule="if (dst in 10.0.0.0/15 && dst-len==32 && bgp-path-len<27) { accept; }" * **Ενημέρωση 9 Δεκέμβρη 2023** * * * * {!} * * * Οι παραπάνω αρχικοί κανόνες δεν δείχνουν να δουλεύουν για την **v7** . Οι παρακάτω **ενημερωμένοι** κανόνες δοκιμάστηκαν και λειτουργούν. θα πρέπει να γίνει ένας διαχωρισμός σε δυο κανόνες, **awmn-in** & **awmn-out**. Επιπλέον αφαιρούμε το φίλτρο **anycast**, μια υπηρεσία που ήταν πειραματική στις μέρες του 2005-2009 ενώ ποτέ δεν δούλεψε ικανοποιητικά. Σήμερα, εν έτει 2023, η αποδοχή της στα φίλτρα αποτελεί κενό ασφάλειας, οπότε και αφαιρείται. /routing filter rule add chain=awmn-in rule="if (dst in 10.0.0.0/8 && dst-len==24 && bgp-path-len<27) { accept; }" /routing filter rule add chain=awmn-out rule="if (dst in 10.0.0.0/8 && dst-len==24) { accept; }" Στην τοποθεσία Routing-->BGP-->Peers, σε κάθε **ασυρματική** σύνδεση, **όχι** με τους τοπικούς μας άλλους router, επιλέγουμε για φίλτρο IN και OUT την επιλογή awmn. Το παραπάνω φίλτρο αποκλείει τις μαύρες τρύπες που ακυρώνουν τον δυναμικό, ζωντανό & διάφανο χαρακτήρα του **BGP**, καταπολεμά σε ένα ικανοποιητικό βαθμό το μεγαλύτερο μέρος των φαντασμάτων, ενώ προστατεύει & θωρακίζει από κακόβουλες ενέργειες ή ακούσιες λανθασμένες ρυθμίσεις. ** Δεν αποτελεί απαραίτητη προϋπόθεση ** αλλά η χρήση του συνιστάται. ===== AWMN NAT/Masquerade setup ===== ** * * * Προσοχή * * * ** στην χρήση του **NAT/Masquerade** στο **IP**-->**Firewall**-->**NAT** αν το IP/δύκτιο που θέλουμε να κάνουμε NAT δεν είναι 10ρι τότε ο κανόνας είναι: src=!10.0.0.0/8 (dst=0.0.0.0/0 ή κενό) αν έχουμε 10ρι που θέλουμε να κάνουμε NAT τότε ο κανόνας είναι: src=10.0.0.0/8 dst=!10.0.0.0/8 ο πρώτος κανόνας εξασφαλίζει το NAT σε δίκτυο/IP που **ΔΕΝ** ανήκει σε 10ρι να γίνεται NAT προς οποιοδίποτε δίκτυο. ο δεύτερος κανόνας εξασφαλίζει το NAT σε δίκτυο/IP που ανήκει σε 10ρι & θέλουμε να **ΜΗΝ** γίνεται NAT όταν απευθύνεται σε 10ρι δίκτυο, αλλά να γίνεται NAT όταν θέλει να πάει σε **ΟΧΙ** 10ρι δίκτυο. στο **src** είναι **καλό & σωστότερο** να ορίζονται τα συγκεκριμένα δίκτυα που μας αφορούν. Αν δεν υπάρχει η δυνατότητα να καθοριστούν συγκεκριμένα τα δίκτυα src=, τότε οι παραπάνω δυο γενικοί κανόνες, εξασφαλίζουν την απρόσκοπτη & σωστή διεύλευση της 10.0.0.0/8 κίνησης. ===== cloud.mikrotik.com DNS Storm ===== Σε πολλές περιπτώσεις, MikroTik δρομολογητές με default ρυθμίσεις, δημιουργούν πολύ ενοχλήτικές & άχρηστες καταγίδες σε χρήση DNS 12:32:38.113564 IP 10.37.52.254.5678 > 10.2.19.1.53: 41094+ A? cloud.mikrotik.com. (36) 12:32:38.113618 IP 10.2.19.1.53 > 10.37.52.254.5678: 41094 1/0/0 A 159.148.147.229 (52) 12:32:39.113797 IP 10.37.52.254.5678 > 10.2.19.1.53: 41094+ A? cloud.mikrotik.com. (36) 12:32:39.113857 IP 10.2.19.1.53 > 10.37.52.254.5678: 41094 1/0/0 A 159.148.147.229 (52) 12:32:40.112605 IP 10.37.52.254.5678 > 10.2.19.1.53: 41094+ A? cloud.mikrotik.com. (36) 12:32:40.112668 IP 10.2.19.1.53 > 10.37.52.254.5678: 41094 1/0/0 A 159.148.147.229 (52) Κάποιες προτεινόμενες λύσεις στο συγκεκριμένο πρόβλημα είναι οι ακόλουθες: - Απενεργοποίηση [[https://wiki.mikrotik.com/wiki/Manual:Detect_internet | Detect Internet]] /interface detect-internet set detect-interface-list=none - Απενεργοποίηση [[https://wiki.mikrotik.com/wiki/Manual:IP/Cloud#DDNS | DDNS service]] /ip cloud set ddns-enabled=no - Απενεργοποίηση [[https://wiki.mikrotik.com/wiki/Manual:IP/Cloud#Update_time | Update time]] /ip cloud set update-time=no - Απενεργοποίηση [[https://wiki.mikrotik.com/wiki/Manual:System/Time#Clock_and_Time_zone_configuration | time-zone-autodetect]] /system clock set time-zone-autodetect=no ===== Mikrotik DNS Setup ===== /ip dns set allow-remote-requests=yes Το παρακάτω, στέλνει **ΟΛΕΣ** τις **Internet** διευθύνσεις στους Internet servers & **ΟΛΕΣ** τις **AWMN** διευθύνσεις στον **wind.awmn** server /ip dns set servers=8.8.8.8,8.8.4.4,1.1.1.1 /ip dns static add forward-to=10.19.143.12 regexp=".*\\.awmn\$" Προσθέτουμε τα ονόματα του κόμβου μας (για παράδειγμα, κόμβος soleo 10.38.128.0/24) ως εξής: /ip dns static add name=router.soleo.awmn address=10.38.128.5 για τις wifi (BB link) συνδέσεις, ακολουθούμε το παρακάτω πρότυπο (**gw-**όνομα-απέναντι-κόμβου)): /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** address σε όνομα ( name= ) ώστε να γίνεται σωστά η επίλυση της **IP** σε όνομα προκειμένου να **ΜΗΝ** δημιουργείται πρόβλημα στις περισσότερες εφαρμογές που πλέον το απαιτούν για λόγους ασφαλείας Αν θέλουμε να δώσουμε **επιπλέον** ονομασίες σε μια **IP**, ο σωστός & προτεινόμενος τρόπος είναι ο πιο κάτω: /ip dns static add name=alias.soleo.awmn type=CNAME cname=router.soleo.awmn με τον παραπάνω τρόπο, όταν δίνουμε (για επίλυση σε όνομα) μια **IP**, για παράδειγμα: **10.38.128.5**, η απάντηση θα είναι **ΠΑΝΤΑ** μια & μοναδική (όπως απαιτείται κατά τα πρότυπα) --> **router.soleo.awmn** όλες οι επιπλέον ονομασίες ορισμένες σαν **CNAME** θα αντιστοιχούν στον **router.soleo.awmn** δηλαδή --> **10.38.128.5** ===== Asymmetric routing & UDP ===== η ανάπτυξη του **AWMN** δικτύου είναι βασισμένη σε κόμβους με πολλαπλές συνδέσεις, με αποτέλεσμα πολλές φορές να υπάρχει **ασυμμετρία** σε αρκετές διαδρομές μέσα σε αυτό. η χρήση **stateful** filtering δημιουργεί πρόβλημα στο **DNS** το οποίο λειτουργεί σε **UDP**. ο δημιουργός του **tinc-vpn** [[http://www.tinc-vpn.org/pipermail/tinc/2015-September/004225.html|εξέφρασε]] σχετικά το παρακάτω: 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://help.mikrotik.com/docs/display/ROS/Basic+Concepts|βασικές οδηγίες ρύθμισης & λειτουργίας firewall της Mikrotik]] έχουμε την παρακάτω υπενθύμιση: /ip firewall filter add chain=input connection-state=invalid action=drop comment="Drop Invalid connections" add chain=input connection-state=established,related,untracked action=accept comment="Allow Established/Related/Untracked connections ** //__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,related,untracked action=accept comment="Allow Established/Related/Untracked connections del chain=input connection-state=invalid action=drop comment="Drop Invalid connections" το παρακάτω παράδειγμα δείχνει καθαρά το πρόβλημα: 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://bgpmap.ozo.com/ - στο δεξί δεξί menu κάτω εκεί που λέει Search Node βάζουμε (παράδειγμα) virtual & πατάμε enter - θα μας ανοίξει από κάτω (δεξιά) ένα menu, στο κάτω μέρος πατάμε το View node in 3D mode - κάτω δεξιά πατάμε την υδρόγειο για να μας ανοίξει το 3D - η ρόδα του ποντικιού, κάνει zoom in/out - το αριστερό κουμπί του ποντικιού ελέγχει την οριζόντια πλοήγηση - το αριστερό κουμπί του ποντικιού με το Ctrl πατημένο ελέγχει την κάθετη πλοήγηση //happy 3D flying// ==== BGP Trace ==== - στο δεξί παράθυρο (Control center), πηγαίνουμε στο Trace Route - βάζουμε είτε με όνομα κόμβου είτε με αριθμό AS τους κόμβους που μας ενδιαφέρει να εξετάσουμε - πατάμε την ένδειξη Show route η παραπάνω διαδικασία: - θα απαριθμήσει τους κόμβους από τους οποίους περνάει η σύνδεση αυτών των δυο κόμβων - θα αποτυπώσει πάνω στον χάρτη με μπλε χρώμα τις παραπάνω διαδρομές - στο δεξί μενού με την ένδειξη Possible Route(s), θα εμφανίσει την διαδρομή με όλα τα AS (κόμβους) που μεσολαβούν πατώντας σε κάθε AS κόμβο, η πλοήγηση μεταφέρεται αυτόματα στον συγκεκριμένο κόμβο για περαιτέρω εξέταση