English · Ελληνικά
Η τελική εξέταση της σειράς. Πάρε το campus που έχτισες στο part 24, δώσ' το σε έναν συνάδελφο (ή στον μελλοντικό σου εαυτό), και άσ' τον να φυτέψει αυτά τα οκτώ σφάλματα ενώ δεν κοιτάς. Μετά κάτσε με τα tickets — «οι επισκέπτες δεν βγαίνουν online στη δυτική πτέρυγα» — και βρες τα όλα, χρησιμοποιώντας μόνο show commands και μια μέθοδο. Αυτό είναι το πιο κοντινό που φτάνει ένα lab σε μια πραγματική Τρίτη.
Το να χτίσεις ένα δίκτυο σου μαθαίνει εντολές. Το να το διορθώσεις σου μαθαίνει το δίκτυο. Το troubleshooting είναι πρόβλημα αναζήτησης, και οι ερασιτέχνες ψάχνουν άσχημα — πηδάνε στο επίπεδο που διάβασαν τελευταίο, αλλάζουν τρία πράγματα ταυτόχρονα, και δεν μπορούν μετά να πουν ποιο ήταν το σφάλμα. Οι επαγγελματίες συμπιέζουν τον χώρο αναζήτησης μεθοδικά: ποιοι χρήστες, ποια VLAN, ποιο switch, ποιο επίπεδο; Κάθε απάντηση μισεύει την επικράτεια.
Αυτό το σενάριο σου δίνει οκτώ σφάλματα φυτεμένα στο campus του part-24, παρουσιασμένα όπως τα παρουσιάζει η πραγματικότητα — ως παράπονα χρηστών, όχι config diffs. Για το καθένα: το ticket, το περπάτημα διάγνωσης με πραγματικό command output, η ρίζα αιτίας, η διόρθωση, και η συνήθεια που πρέπει να κρατήσεις. Κάν' το τίμια: φόρτωσε το σωσμένο σου αρχείο part-24, βάλε κάποιον (ή έναν τυχαίο αριθμό και αυτή τη λίστα) να το σπάσει, και δούλεψε τα tickets πριν διαβάσεις κάθε απάντηση.
01
Πριν από κάθε εντολή: μετάτρεψε το παράπονο σε ένα σύνορο. Τι δουλεύει, τι δεν δουλεύει, και πού είναι η γραμμή ανάμεσά τους; Το σφάλμα ζει πάντα πάνω στη γραμμή.
Τρεις ερωτήσεις μετατρέπουν ένα ασαφές ticket σε ένα εντοπισμένο σφάλμα:
1. Scope — ένας χρήστης, οι χρήστες ενός switch, ένα VLAN παντού, ή όλοι; Ένας χρήστης = πρόβλημα port. Ένα switch = αυτό το switch ή τα uplinks του. Ένα VLAN σε πολλά switches = SVI/gateway/DHCP για εκείνο το VLAN. Όλοι = edge ή core. Έχεις εξαλείψει ~80% του δικτύου πριν αγγίξεις πληκτρολόγιο.
2. Επιπεδο — περπάτα από κάτω προς τα πάνω, και σταμάτα στο πρώτο σπασμένο επίπεδο: link light (show interfaces status) → μέλος VLAN → φτάνει το gateway του; → έχει lease DHCP; → φτάνει το internet; Κάθε τεστ υποθέτει ότι πέρασαν αυτά από κάτω του.
3. Τι αλλαξε; — τα δίκτυα δεν σαπίζουν· αλλάζονται. Το show logging είναι ό,τι πιο κοντινό σε ομολογία θα πάρεις.
Ο σιδερένιος κανόνας όταν αρχίζεις να διορθώνεις: άλλαξε ένα πράγμα, ξανατέσταρε, γράψ' το. Διόρθωσε δύο πράγματα ταυτόχρονα και κάτι αρχίζει να δουλεύει, και δεν έμαθες τίποτα — χειρότερα, μία από τις δύο αλλαγές σου μπορεί να είναι ένα νέο λανθάνον σφάλμα. Σε Packet Tracer αυτή η πειθαρχία μοιάζει σχολαστική. Στις 2 το πρωί σε ένα production switch είναι η διαφορά ανάμεσα σε μια αναφορά incident και ένα δεύτερο incident.
02
Τα δύο μικρότερα scopes — ένας μεμονωμένος χρήστης, μετά οι επισκέπτες ενός switch. Σφάλματα access-layer, βρισκόμενα από το access layer.
ACC-1# show interfaces status | include Fa0/7 Fa0/7 room114 connected 100 a-full a-100 10/100BaseTX ↑ VLAN 100; Το VLAN του staff είναι το 10. ACC-1# show vlan brief | include 100 100 VLAN0100 active Fa0/7 ← το VLAN 100 υπάρχει αλλά δεν κάνει route πουθενά — ένα access VLAN με typo, κλασικό fat-finger ACC-1(config)# interface Fa0/7 ACC-1(config-if)# switchport access vlan 10 ← διορθώθηκε· το PC τραβά DHCP ακαριαία
Ρίζα αιτίας: switchport access vlan 100 αντί για 10. Το IOS «βοηθητικά» δημιούργησε το VLAN 100 όταν ανατέθηκε, οπότε τίποτα δεν κατέγραψε καν σφάλμα. Συνηθεια: μετά από κάθε αλλαγή port, show interfaces status — η στήλη VLAN πιάνει typos που τα μάτια σου προσπέρασαν σε config mode.
ACC-2# show interfaces status err-disabled Port Name Status Reason Fa0/18 err-disabled bpduguard ACC-2# show logging | include Fa0/18 %SPANTREE-2-BLOCK_BPDUGUARD: Received BPDU on port Fa0/18 with BPDU Guard enabled. Disabling port. # Το box του εργολάβου ήταν ένα φτηνό switch — μιλούσε STP, το BPDU Guard πυροδοτήθηκε. # Αφαίρεσε τη συσκευή που φταίει, μετά: ACC-2(config)# interface Fa0/18 ACC-2(config-if)# shutdown ACC-2(config-if)# no shutdown ← το err-disabled χρειάζεται χειροκίνητο bounce
Ρίζα αιτίας: καμία — το δίκτυο δούλεψε. Το BPDU Guard (part 6) έκανε ακριβώς τη δουλειά του όταν εμφανίστηκε ένα rogue switch· το «σφάλμα» είναι ότι κανείς δεν ήξερε τι σημαίνει err-disabled. Συνηθεια: το show interfaces status err-disabled ανήκει στις πρώτες πέντε εντολές σου σε κάθε ticket «port ξαφνικά νεκρό», και η στήλη Reason κατονομάζει την ένοχη προστασία.
03
Scope: «ένα VLAN, ένα switch» και «περίεργος θόρυβος στα logs». Και τα δύο είναι κακές ρυθμίσεις trunk — το μέρος όπου ένα σφάλμα μπορεί να κρυφτεί επειδή οι περισσότερη κίνηση ακόμα ρέει.
Οι επισκέπτες (VLAN 20) δουλεύουν στο ACC-1, αποτυγχάνουν στο ACC-2 — αλλά το staff στο ACC-2 είναι μια χαρά. Ένα VLAN, ένα switch, τα άλλα VLAN υγιή: αυτό είναι trunk που κουβαλά μερική λίστα VLAN.
ACC-2# show interfaces trunk Port Vlans allowed on trunk Gi0/1 10,30,99 ← λείπει το 20. Κάποιος «καθάρισε» την allowed list και έριξε το GUEST. Gi0/2 10,20,30,99 ← το uplink του CORE-2 το έχει ακόμα — αλλά το STP μπλοκάρει εκείνο το path σε steady state, άρα άτυχο ACC-2(config)# interface Gi0/1 ACC-2(config-if)# switchport trunk allowed vlan add 20 ← ADD, όχι απλή λίστα!
Ρίζα αιτίας: μια επεξεργασμένη allowed-VLAN list. Πρόσεξε ότι η διόρθωση χρησιμοποιεί add — το να πληκτρολογήσεις switchport trunk allowed vlan 20 θα αντικαθιστούσε ολόκληρη τη λίστα με μόνο το 20 και θα έριχνε μαζί τα άλλα τρία VLAN. Αυτή η μία λέξη που λείπει έχει προκαλέσει πραγματικά outages παντού. Συνηθεια: όταν ένα VLAN πεθαίνει σε ένα switch, show interfaces trunk πριν από οτιδήποτε άλλο.
%CDP-4-NATIVE_VLAN_MISMATCH: Native VLAN mismatch discovered on GigabitEthernet0/2 (99), with CORE-2 GigabitEthernet1/0/2 (1). # Το downlink του CORE-2 ξαναχτίστηκε και έχασε τη ρύθμιση native-vlan του: CORE-2(config)# interface GigabitEthernet1/0/2 CORE-2(config-if)# switchport trunk native vlan 99
Ρίζα αιτίας: native VLAN 99 στη μία άκρη, 1 στην άλλη. Frames χωρίς tag — μαζί με κάποια κίνηση ελέγχου — περνάνε το trunk και προσγειώνονται σε διαφορετικά VLAN σε κάθε πλευρά. Σήμερα είναι θόρυβος στα logs· τη μέρα που κάποιος πραγματικά χρησιμοποιήσει εκείνα τα VLAN, γίνεται διαρροή ανάμεσα σε segments που κανένα ACL δεν την είδε να έρχεται. Συνηθεια: προειδοποιήσεις που «δεν χαλάνε τίποτα» είναι σφάλματα με καθυστερημένο φυτίλι. Διόρθωσέ τες τη μέρα που εμφανίζονται.
04
Scope: ένα VLAN παντού, ή διαλείπον το παν. Όταν το access layer βγαίνει καθαρό, υποψιάσου τα πράγματα που πρέπει να συμφωνούν και τα δύο cores — HSRP και το DHCP relay.
CORE-1# show standby brief Interface Grp Pri P State Active Standby Virtual IP Vl10 10 110 P Active local unknown 10.10.10.1 ↑ το CORE-1 δεν βλέπει τον peer του… CORE-2# show standby brief Vl10 10 90 P Active local unknown 10.10.10.1 # Και τα ΔΥΟ διεκδικούν Active για το ίδιο VIP = split brain. Τα HSRP hellos δεν # περνάνε το interlink. Είναι ακόμα επιτρεπτό το VLAN 10 στο Po1; CORE-1# show interfaces trunk | include Po1 Po1 20,30,99 ← το VLAN 10 κλαδεύτηκε από το port-channel! CORE-1(config)# interface Port-channel1 CORE-1(config-if)# switchport trunk allowed vlan add 10
Ρίζα αιτίας: το VLAN 10 έπεσε από το trunk interlink, οπότε τα δύο cores σταμάτησαν να ακούνε το ένα τα HSRP hellos του άλλου σε εκείνο το VLAN και και τα δύο έγιναν active — διπλό virtual MAC, χάος ARP, διαλείπον το παν. Συνηθεια: «δύο Actives» στο show standby brief ποτέ δεν σημαίνει ότι το HSRP είναι χαλασμένο· σημαίνει ότι είναι χαλασμένο το path ανάμεσα στους peers. Κυνήγα το trunk, όχι το πρωτόκολλο.
CORE-2# show running-config interface vlan 30 interface Vlan30 ip address 10.10.30.3 255.255.255.0 standby 30 ip 10.10.30.1 standby 30 priority 110 standby 30 preempt # Κανένα ip helper-address — και το CORE-2 είναι το ACTIVE gateway για VLAN 30, # άρα είναι ο router που λαμβάνει (και ρίχνει) το DISCOVER κάθε τηλεφώνου. CORE-2(config)# interface vlan 30 CORE-2(config-if)# ip helper-address 10.255.0.5
Ρίζα αιτίας: ο relay έγινε config στο CORE-1 (standby για VLAN 30) αλλά ξεχάστηκε στο CORE-2 (active). Τα broadcasts πεθαίνουν στο active gateway· ένα relay στο standby δεν βοηθά κανέναν. Μια αυτο-ανατεθειμένη διεύθυνση 169.254.x.x είναι πάντα η ίδια πρόταση: «το DHCP broadcast μου δεν πήρε απάντηση» — το σφάλμα είναι το relay, το trunk προς τον DHCP server, ή το pool, με αυτή τη σειρά πιθανότητας. Συνηθεια: ό,τι είναι config ανά SVI πρέπει να υπάρχει και στα δύο cores — έλεγξε με show run | include helper στο καθένα.
05
Scope: «φτάνουμε τα πάντα εσωτερικά, αλλά όχι το internet» — το σύνορο είναι το EDGE, και οι δύο συνήθεις ύποπτοι εκεί είναι το NAT και το route επιστροφής.
# Από τηλέφωνο: το ping 10.255.0.1 δουλεύει (internal routing μια χαρά), το 8.8.8.8 πεθαίνει. # Στο EDGE — μεταφράζει καν το NAT το VLAN 30; EDGE# show ip nat translations | include 10.10.30 (τίποτα) EDGE# show access-list 1 Standard IP access list 1 10 permit 10.10.10.0, wildcard bits 0.0.0.255 (8231 matches) 20 permit 10.10.20.0, wildcard bits 0.0.0.255 (5044 matches) # Το ACL NAT απαριθμεί subnets — και το VLAN 30 προστέθηκε στο δίκτυο # αφού γράφτηκε το ACL. Τα πακέτα κάνουν route στο EDGE, αποτυγχάνουν στο ACL, βγαίνουν # ΧΩΡΙΣ ΜΕΤΑΦΡΑΣΗ με source 10.x, και ο ISP τα ρίχνει σιωπηλά. EDGE(config)# access-list 1 permit 10.10.30.0 0.0.0.255
Ρίζα αιτίας: ένα ACL NAT γραμμένο ως λίστα συγκεκριμένων subnets αντί για το summary 10.10.0.0 0.0.255.255 από το part 24 — οπότε κάθε μελλοντικό VLAN γεννιέται σπασμένο. Συνηθεια: «το εσωτερικό δουλεύει, το internet όχι, για ένα subnet» είναι πρόβλημα scope NAT μέχρι αποδείξεως του εναντίου, και το show ip nat translations φιλτραρισμένο κατά subnet το ξεκαθαρίζει σε μία εντολή.
EDGE# show ip route | include 10.10.0.0 S 10.10.0.0/16 [1/0] via 10.255.0.2 S 10.10.0.0/16 [1/0] via 10.255.0.9 ← .9; Τα core links μας είναι .2 και .6 — ένα next-hop με typo από το σαββατοκύριακο # Οι μισές από την κίνηση επιστροφής του EDGE (το ECMP εναλλάσσει flows) γίνονται route σε ένα # next-hop που δεν απαντά ARP για τίποτα. Αυτά τα flows πεθαίνουν· τα υπόλοιπα δουλεύουν. EDGE(config)# no ip route 10.10.0.0 255.255.0.0 10.255.0.9 EDGE(config)# ip route 10.10.0.0 255.255.0.0 10.255.0.6
Ρίζα αιτίας: ένα static με fat-finger κατά το maintenance. Η σκληρή λεπτομέρεια: με ECMP, οι μισές ροές ακόμα δουλεύουν, οπότε το δίκτυο φαίνεται «αργό και ασταθές» αντί για «κάτω», και όλοι κατηγορούν το Wi-Fi για μια μέρα. Συνηθεια: «διαλείπον ανά session, σταθερό ανά session» ουρλιάζει ένα από πολλά ίσα paths είναι χαλασμένο. Έλεγξε κάθε next-hop ECMP· ένα route που εγκαθίσταται δεν είναι route που δουλεύει.
06
Οκτώ tickets αποσταγμένα στον πίνακα αντανακλαστικού. Η πρώτη εντολή δεν βρίσκει κάθε σφάλμα — εξαλείφει τις μισές πιθανότητες σε δέκα δευτερόλεπτα, που είναι καλύτερο.
| Συμπτωμα | Πρωτη εντολη & τι εξαλειφει |
|---|---|
| Ένας χρήστης νεκρός | show interfaces status — link, speed/duplex, και η στήλη VLAN (ticket 1) |
| Port ξαφνικά νεκρό μετά από σύνδεση κάποιου | show interfaces status err-disabled — προστασίες που πυροδοτήθηκαν, με όνομα (ticket 2) |
| Ένα VLAN νεκρό σε ένα μόνο switch | show interfaces trunk — allowed lists σε κάθε uplink (ticket 3) |
| Θόρυβος logs Native-VLAN | show interfaces trunk και στις δύο άκρες — οι στήλες native πρέπει να ταιριάζουν (ticket 4) |
| Όλοι διαλείπον / περίεργο ARP | show standby brief και στα ΔΥΟ cores — δύο Actives = σπασμένο path peer (ticket 5) |
| Clients σε 169.254.x.x | show run interface vlan N στο ACTIVE core — υπάρχει helper-address; (ticket 6) |
| Εσωτερικό μια χαρά, internet νεκρό, ένα subnet | show ip nat translations | include <subnet> — scope NAT (ticket 7) |
| Ασταθές ανά flow μετά από αλλαγή | show ip route — επαλήθευσε ότι κάθε next-hop ECMP όντως υπάρχει (ticket 8) |
Η καλύτερη εκδοχή αυτού του lab είναι ανταγωνιστική: δύο άτομα, ένα αρχείο Packet Tracer. Ο καθένας φυτεύει δύο σφάλματα από αυτή τη λίστα (ή εφευρίσκει άλλα στο ίδιο πνεύμα — μόνο config, χωρίς διαγραμμένα καλώδια), σώζει, και ανταλλάσσει. Βαθμολόγησε με tickets κλεισμένα ανά τριάντα λεπτά, και απαίτησε γραπτή ρίζα αιτίας για το καθένα — «το ξαναφόρτωσα και δουλεύει τώρα» βαθμολογείται μηδέν. Αυτό, όχι τυχαία, είναι ακριβώς πώς κάνω interview network engineers.
Συμπερασματα
allowed vlan add.Το «κάν' το reboot και δες» δεν είναι troubleshooting. Όταν ένα δίκτυο επιχείρησης κουτσαίνει, κάνω διάγνωση ρίζας αιτίας και παραδίδω γραπτή αναφορά για το τι πραγματικά έφταιγε και τι ακριβώς άλλαξε για να διορθωθεί.
Κλεισε μια Discovery Call →