# Θεματολογία δικτύου > Δρομολόγηση >  Routing και Internet (default) gw

## Achille

Μιας και πλεον έχουμε αρχίσει να έχουμε πολλαπλές διαδρομές προς το Internet, γίνεται επιτακτική η ανάγκη να βρούμε τρόπο να τις διαχειριστούμε.
Να σημειώσω καταρχάς πως δεν θεωρώ λύση τους proxy servers. Δεν γίνεται κάθε φορά που θέλω να διαλέξω κάτι διαφορετικό να πρέπει να το κάνω σε 10 μεριές σε κάθε PC. Θέλω μια λύση αυτόματη, που θα διαλέγει το καλύτερο gateway (ή έστω σε πρώτη φάση ένα που να δουλεύει) χωρίς να πρέπει να μπω σε 5 routers και να το αλλάξω με το χέρι.

Τα πρώτα πειράματα που έκανα, δείχνουν ότι η zebra έχει δυνατότητα να στέλνει στα routing tables το default gw, αν μπει με στατικό τρόπο. Για να το πάρει η άλλη πλευρά όμως και να το χρησιμοποιήσει, πρέπει
α) Να έχει access-list σαν την παρακάτω:

access-list new deny 192.168.0.0/16
access-list new deny 172.16.0.0/12
access-list new permit any

β) Να μην έχει κάποιο default gw με στατικό τρόπο

Τα προβλήματα που εμφανίζονται λοιπόν είναι τα εξής:

1) Πώς θα προστατέψουμε το δίκτυο από άσχετα routes που μπορεί να στέλνει ο καθένας; 
Πχ αν κάνω λάθος configuration και βάλω να στέλνει το connected route του dialup μου, τότε πχ θα εμφανίζεται στα routing tables μας το εξής:

62.103.3.179 sfera.achille.awmn 255.255.255.255

Μικρό το κακό θα μου πείτε, μιας και είναι point to point και είναι μικρή η πιθανότητα κάποιος να θέλει να μιλήσει με τον dialup router της OTEnet, δεν παύει όμως να δημιουργεί πρόβλημα

2) Πώς θα μοιράσουμε τις γραμμές με αναλογικό τρόπο;
Το RIP σίγουρα δεν μας κάνει, αφού το μόνο που μπορούμε να καταφέρουμε, είναι να "βγάζουμε" τον καθένα από εκεί που είναι πιο κοντά από άποψη hops. Δεν λαμβάνει υπόψιν το μέγεθος της γραμμής ή την χρησιμοποίησή της.

3) Πώς θα καταργείται ένα default gw όταν για κάποιο λόγο σταματήσει να δουλεύει;
Για παράδειγμα πέφτει η DSL που σερβίρει το Internet, τι θα γίνει με το default gw που είναι στατικό και θα συνεχίσει να στέλνεται προς όλες τις κατευθύνσεις; Είναι πρακτικό να φτιάξουμε ένα script που θα ping-άρει κάποιο Internet host, και όταν τα πακέτα χάνονται να αφαιρεί αυτόματα το static entry;

Και πάμε τώρα στο extra πλεονέκτημα αυτής της μεθόδου. Μπορούμε να δώσουμε με static route μια διέξοδο για συγκεκριμένα IPs. Για παράδειγμα μπορούμε να βάλουμε το forum σε ένα μέρος που να έχει και wireless conectivity, και να στέλνουμε μέσω routing τις ΠΡΑΓΜΑΤΙΚΕΣ IP του στο AWMN. Έτσι θα δουλεύει κανονικά και το Internet DNS, δηλαδή βάζεις τον browser σου στο "www.awmn.gr" και θα σε βγάζει ασύρματα στις πραγματικές IP του server του forum, χωρίς να χρειάζονται τεχνάσματα στο DNS για να αντιστοιχίσουμε AWMN IPs στον server του forum.

Και ένα πιθανό πρόβλημα στο (2) αν χρησιμοποιήσουμε κάποιο Load Balancing πρωτόκολλο, πχ OSPF.
Αν οι συνδέσεις γίνονται μέσω NAT, θα πρέπει το load-balancing να γίνεται σε επίπεδο σύνδεσης και όχι σε επίπεδο πακέτου! Αν δυο πακέτα σταλούν από διαφορετικές gw, θα έχουν και διαφορετικές IPs, με αποτέλεσμα να μην θεωρούνται από το αντίθετο άκρο σαν μια σύνδεση, και η σύνδεση να μην λειτουργεί. Γίνεται αυτό να υλοποιηθεί στο OSPF; Δηλαδή είτε από κάθε IP του εσωτερικού δικτύου να διαλέγει πάντα μια διαδρομή για τα πακέτα της προς τον ίδιο προορισμό, είτε να το κάνει σε επίπεδο σύνδεσης, δηλαδή να κάνει και connection tracking; (Το δεύτερο είμαι σχεδόν σίγουρος ότι δεν γίνεται).

Με συγχωρείτε για το μέγεθος του post, αλλά πιστεύω ότι αυτά που λέω είναι ουσιαστικά και πρέπει να μας απασχολήσουν.

----------


## kouk

> 3) Πώς θα καταργείται ένα default gw όταν για κάποιο λόγο σταματήσει να δουλεύει;
> Για παράδειγμα πέφτει η DSL που σερβίρει το Internet, τι θα γίνει με το default gw που είναι στατικό και θα συνεχίσει να στέλνεται προς όλες τις κατευθύνσεις; Είναι πρακτικό να φτιάξουμε ένα script που θα ping-άρει κάποιο Internet host, και όταν τα πακέτα χάνονται να αφαιρεί αυτόματα το static entry;


πρακτικό μου φαίνεται.. λίγο χακιά αλλά άμα δουλεύει τι μας πειράζει;




> Και ένα πιθανό πρόβλημα στο (2) αν χρησιμοποιήσουμε κάποιο Load Balancing πρωτόκολλο, πχ OSPF.
> Αν οι συνδέσεις γίνονται μέσω NAT, θα πρέπει το load-balancing να γίνεται σε επίπεδο σύνδεσης και όχι σε επίπεδο πακέτου! Αν δυο πακέτα σταλούν από διαφορετικές gw, θα έχουν και διαφορετικές IPs, με αποτέλεσμα να μην θεωρούνται από το αντίθετο άκρο σαν μια σύνδεση, και η σύνδεση να μην λειτουργεί. Γίνεται αυτό να υλοποιηθεί στο OSPF; Δηλαδή είτε από κάθε IP του εσωτερικού δικτύου να διαλέγει πάντα μια διαδρομή για τα πακέτα της προς τον ίδιο προορισμό, είτε να το κάνει σε επίπεδο σύνδεσης, δηλαδή να κάνει και connection tracking; (Το δεύτερο είμαι σχεδόν σίγουρος ότι δεν γίνεται).


Ναι, το δεύτερο μου φαίνεται απίθανο. Ώσοναφορα το πρώτο πάλι απίθανο μου φαίνεται, γιατί το routing πρωτόκολλο θα πρέπει να καταλάβει την διαφορά μεταξύ των δύο περιπτώσεων:
1. ένα gateway παύει να είναι το πιο συμφέρον βάση των μετρικών. Η επιθυμητή συμπεριφορά είναι να συνεχίσουν τα πακέτα ενός host που έβγαινε από εκεί να βγαίνουν από το ίδιο gateway για να κρατηθούν ζωντανές οι συνδέσεις (άν γίνεται κάτι τέτοιο στο OSFP εν πάσει περίπτωση)
2. ένα gateway πέφτει. Η σωστή συμπεριφορά είναι να δρομολογηθούν όλα τα πακέτα αλλού (τερματίζοντας τις συνδέσεις που ούτως ή άλλως δεν μπορούν να συνεχίσουν πιά)

Αν αποφασίσουμε οτί το #2 δεν το υποστηρίζουμε, τότε ουσιαστικά απενεργοποιούμε το OSFP για τα default gateways, οπότε μπορεί απλά ο καθένας να βάζει στατικά το δικό του προτιμότερο default gateway με trial and error.

Ίσως ενδιαφέρουν για την περίπτωση μας τα παρακάτω κείμενα:

http://www.faqs.org/rfcs/rfc2663.html
έχει στο κεφάλαιο 4 κάτι για Multihomed NAT

http://www.globecom.net/ietf/draft/draf ... mt-02.html
γενικότερα περί multihoming

http://www.academ.com/nanog/feb1998/nat/sld001.htm
αυτό φαίνεται σαν αυτό που θέλουμε, αλλά δεν το έχω διαβάσει.

----------


## Achille

Διάβασα τα links που έστειλες, αλλά δεν νομίζω ότι κατάφερα να βρω κάτι αντίστοιχο με αυτό που κάνουμε εμείς (στο πρώτο έλεγε αυτό που θέλουμε να κάνουμε, όχι όμως κάποια ένδειξη για το πως μπορεί να υλοποιηθεί).

Πάντως αν μπορούμε να "πείσουμε" το OSPF να μην κάνει load sharing, εκτός από το 10.x, και υλοποιήσουμε ένα μηχανισμό που να ελέγχει την κατάσταση του Internet στον border router, μπορούμε να έχουμε high availability με απολύτως αυτόματο τρόπο.

Νομίζω ότι δεν είναι και άσχημα σαν πρώτη φάση  :: 

Επίσης μελλοντικά, μπορούμε να υλοποιήσουμε δικό μας τρόπο distribution για το default gw, ανεξάρτητο από το OSPF, ώστε να λαμβάνει υπόψιν του τις παραμέτρους που εμείς θέλουμε.

----------


## Renos

Achille, αν δεν κανω λαθος, στο τελευταιο meeting (kouk αυτο δεν παει στα ελληνικα... ) ειχαμε συζητησει για "μοιρασμα" της DLS σε εκταση "γειτονιας". Κατι το οποιο μπορει να σημαινει επιπεδο ΑΡ. Δηλαδη ενα AP με 4-5-6 clients παιρνει την DSL και την μοιραζει μονο σε αυτους. Οι συγκεκριμενοι clients εχουν δικαιωμα να χρησιμοποιουν εκεινη την Internet συνδεση μονο και φυσικα εχουν υποχρεωση να συμβαλουν στην συνδρομη της (μονο αν επιθυμουν να εχουν Internet). Θετουν σαν default GW τον router του AP και δεν ασχολουνται παραπανω.

Διορθωσε με αν κανω λαθος, αλλα νομιζω οτι προσπαθεις να βγαλεις ενα πλανο κοινης χρησης της DSL και ενα σχεδιο λειτουργίας του ολου συστήματος οταν αυτη θα ειναι διαθεσιμη κατα καιρούς από διάφορα σημεία στο AWMN.

Εγω πιστευω οτι θα πρεπει να μεινουμε σε οσα προτεινε ο Δαμιανος (σχετικα με DSL και Internet) και να συγκεντρωθουμε στο πως θα βγει ενα πλανο πανω σε αυτην την προταση.

----------


## ocean

> 3) Πώς θα καταργείται ένα default gw όταν για κάποιο λόγο σταματήσει να δουλεύει;
> Για παράδειγμα πέφτει η DSL που σερβίρει το Internet, τι θα γίνει με το default gw που είναι στατικό και θα συνεχίσει να στέλνεται προς όλες τις κατευθύνσεις; Είναι πρακτικό να φτιάξουμε ένα script που θα ping-άρει κάποιο Internet host, και όταν τα πακέτα χάνονται να αφαιρεί αυτόματα το static entry;


Αχιλλέα γειά,

Ενα τέτοιο scrip δουλεύει εδω και αρκετό καιρό στό squid.ocean.awmn, για να αλλάζει το default route, αν "πέσει" η dsl του racer ετσι ώστε να στέλνει τα πακέτα μέσα απο τον Κλαδάκη. 
Το χαρίζω ευχαριστως στο awmn και σε οποιονδήποτε άλλο του φανεί χρήσιμο:


```
#!/usr/local/bin/bash
# 

# Gateway addresses
GATEWAY1="10.21.120.66"
GATEWAY2="10.19.141.1"

# Check Frequency
PAUSE=3

PATH=/bin:/usr/bin:/usr/local/bin:/sbin:/usr/sbin:/usr/local/sbin

# How many pings should we miss before changing gateway
THRESHOLD=8

# Miss counter
MISSED=0

while true; do
          if ! ping -c 1 -t 3 $GATEWAY1 > /dev/null; then
                ((MISSED++))
          else
                if [ $MISSED -gt $THRESHOLD ]; then
                      # Εδώ βάζουμε τα actions Που πρέπει να γίνουν
                      # αν το gateway 1 επανέλθει στα φυσιολογικά
                      # π.χ. αλλαγή default gateway, restart τη zebra
                      # και οτι άλλο κρίνουμε απαραίτητο
                      route change default $GΑΤΕWΑΥ1
                      MISSED=0
                fi;
          fi;

          if [ $MISSED -eq $THRESHOLD ]; then
                # Εδώ βάζουμε τα actions Που πρέπει να γίνουν
                # αν το gateway 1 δεν παίζει
                # π.χ. αλλαγή default gateway, restart τη zebra
                # και οτι άλλο κρίνουμε απαραίτητο
                route change default $GATEWAY2
          fi
          sleep $PAUSE;
done

exit 0
```

Παραλλαγή αυτού του script παίζει (έπεζε) στην lola του Κλαδάκη, για να κάνει restart την zebra του κάθε φορά που έπεφτε το link του με τον Τάσσο με ικανοποιητικά αποτελέσματα.

Μιά παρατήρηση για τη χρήση του script:
Ολα καλά αν ο router σου ειναι unixaki, με zebra... τι γίνεται ομως αν είναι cisco (π.χ. κλαδάκης) ;

Τώρα μερικές σκέψεις για τα υπόλοιπα που είπες:



> Να σημειώσω καταρχάς πως δεν θεωρώ λύση τους proxy servers. Δεν γίνεται κάθε φορά που θέλω να διαλέξω κάτι διαφορετικό να πρέπει να το κάνω σε 10 μεριές σε κάθε PC. Θέλω μια λύση αυτόματη, που θα διαλέγει το καλύτερο gateway (ή έστω σε πρώτη φάση ένα που να δουλεύει) χωρίς να πρέπει να μπω σε 5 routers και να το αλλάξω με το χέρι


Συμφωνώ και επαυξάνω, όμως τα proxies δεν ειναι "κακά" πράγματα. Κάνουν οικονομία στο bandwidth, μειώνουν τα download times, μπορούν να φιλτράρουν διάφορα "κακά" πράγματα αν θέλει κανείς και εν παση περιπτώσει δεν βλέπω μειονεκτήματα απο την χρήση τους.
Συμφωνώ βέβαια οτι το να κάνεις manual configuration στα μηχανήματα σου να χρησιμοποιούν proxy ειναι μπελάς, αλλα δεν ειναι απαραίτητο να γίνει ετσι. Για παράδειγμα, στο squid.ocean.awmn το proxy ειναι transparent, πράγμα που σημαίνει οτι ειτε βάλεις είτε δεν βάλεις proxy στον browser σου αν το πακέτο περάσει απο εκεί θα πάει υποχρεωτικά στον proxy.

το "οραμα"  ::  μου για το awmn σε σχέση με τα proxies είναι να δημιουργηθεί ενα "proxy grid" κατα προτίμηση με χρήση squid, μια και θεωρώ ανεπιφύλακτα οτι ειναι το καλύτερο proxy application και είναι φιαγμένο για αυτή την δουλειά (proxy hierarchies, ICP και WCCP υποστήρηξη κλπ).




> 2) Πώς θα μοιράσουμε τις γραμμές με αναλογικό τρόπο; 
> ... αν χρησιμοποιήσουμε κάποιο Load Balancing πρωτόκολλο, πχ OSPF ...


Βλέπω το OSPF σαν μιά καλή (ισως την βιοσιμώτερη) λύση... αλλα απο impementation τι γίνεται. Δεν είναι το OSPF πιο βαρύ/δύσκολο στο configuration/πιο απαιτητηκό στα resources ; - Μην ξεχνάς οτι μεγάλο μέρος του πληθυσμού του awmn χρησιμοποιεί για routers παλιά PC με μικρούς επεξεργαστές και λίγη μνήμη. Μπορούν αυτά τα μηχανάκια να σηκώσουν OSPF ;

Μήπως αξίζει τον κόπο να ρίξουμε μια ματια στο "multipath routing" οπου αυτό υποστήρίζεται ;

Ηλίας

----------


## Achille

> Μιά παρατήρηση για τη χρήση του script:
> Ολα καλά αν ο router σου ειναι unixaki, με zebra... τι γίνεται ομως αν είναι cisco (π.χ. κλαδάκης) ;


Μπορεί ο daemon να τρέχει σε ένα pc ανεξάρτητο από τον router και να αλλάζει τα δεδομένα του με telnet ή snmp. Το θέμα είναι τι γίνεται όταν αλλάξει το default gw και θες να τεστάρεις αν επανήλθε...πιστεύω ότι με κάποιο static route θα γίνεται δουλειά.




> Συμφωνώ και επαυξάνω, όμως τα proxies δεν ειναι "κακά" πράγματα. Κάνουν οικονομία στο bandwidth, μειώνουν τα download times, μπορούν να φιλτράρουν διάφορα "κακά" πράγματα αν θέλει κανείς και εν παση περιπτώσει δεν βλέπω μειονεκτήματα απο την χρήση τους.


Δεν είπα ότι είναι μειονέκτημα, κάθε άλλο.
Απλά δεν είναι λύση. Internet δεν είναι μόνο το web έτσι και αλλιώς  :: 
Αν έχουμε λύση σε επίπεδο routing, μπορούμε όπως είπες να υλοποιήσουμε transparent proxies και να κάνουμε τη δουλειά μας  :: 




> Βλέπω το OSPF σαν μιά καλή (ισως την βιοσιμώτερη) λύση... αλλα απο impementation τι γίνεται. Δεν είναι το OSPF πιο βαρύ/δύσκολο στο configuration/πιο απαιτητηκό στα resources ; - Μην ξεχνάς οτι μεγάλο μέρος του πληθυσμού του awmn χρησιμοποιεί για routers παλιά PC με μικρούς επεξεργαστές και λίγη μνήμη. Μπορούν αυτά τα μηχανάκια να σηκώσουν OSPF ;


Ναι και ναι. Για το configuration, θα μάθουμε και θα εκπαιδεύσουμε.
Για τις απαιτήσεις σε resources, δεν γνωρίζω να σου πω. Αν δεν δοκιμάσουμε πάντως, δεν θα μάθουμε.
Από ότι μου είπε ο mindfox πάντως δεν είναι το ίδιο βαρύ σε όλες τις περιπτώσεις, το backbone είναι αυτό που θα τραβήξει το μεγάλο ζόρι.
Έπειτα η αγορά κάποιου PII Class μηχανήματος είναι πλέον πολύ φτηνή, και με 128ΜΒ RAM δε νομίζω να τίθεται θέμα...



> Μήπως αξίζει τον κόπο να ρίξουμε μια ματια στο "multipath routing" οπου αυτό υποστήρίζεται ;


Link?

----------


## ocean

> Αρχική Δημοσίευση από ocean
> 
> Μήπως αξίζει τον κόπο να ρίξουμε μια ματια στο "multipath routing" οπου αυτό υποστήρίζεται ;
> 
> 
> Link?


Λοιπόν, μετά απο αρκετό ψάξιμο στο web, διάβασμα αρκετών papers, κλπ κλπ κατέληξα στο συμπέρασμα οτι το "multipath routing" (τουλάχιστον στα Unixοειδή λειτουργικά συστήματα που συνήθως χρησιμοποιούμε στο awmn) δεν είναι αρκετά ώριμο ώστε να μας δώσει λύση στο συγκεκριμένο θέμα.  ::  

Για όποιον ενδιαφέρεται βέβαια παραθέτω μερικά ενδιαφέροντα resources:

Patches για Multipath routing σε FreeBSD 4.8-Stable:

http://www.dsm.fordham.edu/~tanzer/multipath/

Εμπειρία με το παραπάνω patch: Το έβαλα και δουλεύει μεν, αλλα είναι ψιλοάχρηστο δε, γιατί βασίζεται σε συνεχώς μειούμενο counter για να επιλέξει το επόμενο default route. - Αποτέλεσμα να παίζει για πράγματα οπως web και ping, αλλα για session applications (π.χ. ssh) να τα παίζει....

Πιό επίσημο Multipath για *BSD
http://www.kame.net

Αν και το Kame είναι κυρίως για IPv6 και IPSec έχει υποστήρηξη για multipath routing ( http://www.kame.net/dev/cvsweb2.cgi/...-cvsweb-markup )

Εμπειρία με το patch: Δεν το έχω δοκιμάσει ακομα ....  ::  

Linux:

multipath me iproute2 - δεν εχω εμπειρία σε Linux αλλά βρήκα τα εξής:

Linux Advanced Routing & Traffic Control: 
http://lartc.org

Load Balacing 2 ADSL - Linux (Στά Γαλλικά, αλλά κατανοητό -PDF)
http://www.rtfm.be/vjamart/computing...dbalancing.pdf

*Τέλος Θα πρέπει να επισημάνω το εξής πολύ σημαντικό κατα την γνώμη μου*

*To RIP (Και το RIPv2) έχουν περιορισμό στο hop count maximum 16 hops!!!*

Δείτε εδω σχετικά: http://www.cisco.com/univercd/cc/td/...rp.htm#xtocid1

*Αρα ετσι και αλλοιώς με την δεδομένη ανάπτυξη του δικτύου και ασχετα απο άλλους λόγους θα πρέπει να άλλάξουμε routing protocol !!!*

Υ.Γ Sorry για το μέγεθος του post (πάλι) αλλά νομίζω οτι αυτό είναι ενα πολύ σημαντικό (και ενδιαφέρον) θέμα

----------


## sdd

Για οσους ενδιαφερονται για OSFP routing σε δικτυα με HostAP, υπενθυμιζω το λινκ αυτο

http://www.sown.org.uk/






Χρησιμοποιει πυκνη δικτυωση

http://www.sown.org.uk/index.php/SownMeshing

με ενα δικο τους δαιμονα ---- "...a little Daemon called Aladin which can be used to automatically assign IP addresses to the WDS links, you can download it from http://www.sown.org.uk/aladin.tar.gz. This is important as we need IP's to do the routing.."



Η τοπολογια εξηγειται εδω

http://www.sown.org.uk/index.php/Topology

oσο για τη πολυπλοκοτητα του να γινει configured to Zebra/OSFP, συμφωνα με αυτους, ειναι πολυ μικρη

http://www.sown.org.uk/index.php/Routing



Κανουν ακομα και transparent migration between access points, με το δικο τους λογισμικο

http://www.sown.org.uk/index.php/TransparentMobility


Ενα ενδιαφερον σημειο ειναι οτι απλα Αccess Ρoints, με WDS, μπορουν χωρις διαδικασιες να μπουν στο δiκτυο αυτο
"...automatic WDS means that neighbouring nodes are automatically given a WDS link without you having to manually enter their MAC address"
Για τα υπολοιπα, χρειαζετα καποιο απλο configuration.

----------

