Mikrotik and VLANs

[deniSun]

Ε ο global τρόπος υπάρχει και το ROS κανονίζει και για hw-offload αν είναι δυνατόν. Το Bridge VLAN filtering. Μπορείς να το κάνεις σε όλες τις συσκευές και το κάνεις με τον ίδιο ακριβώς τρόπο.
Τα παρατράγουδα αρχίζουν αν πας να δουλέψεις με το Switch menu σε CRS1xx και πιο παλια RB.

Με σωστή επιλογή όμως των συσκευών μας, μπορούμε να έχουμε συσκευές μόνο με Bridge VLAN filtering.
Και γω σιγά σιγά προς τα κει πήγα, απλά και μόνο για να μην έχω πολλά διαφορετικά config για το ίδιο LAN.

Εμένα με μπερδεύει πολύ η λογική που χρησιμοποιείται στο conf για τα tag/untag και τα admit.

[glf]

Θα έλεγα ότι η φιλοσοφία των "σωστών" vendor είναι ακριβώς να κάνουν εύκολα GUI που να βοηθάνε το χρήστη να κάνει ρυθμίσεις με "ημιαυτόματο" τρόπου που είναι ολόσωστη πρακτική.
Και μετά είναι η φιλοσοφία του ROS που το μόνο "ημιαυτόματο" είναι το ... Quick Set αλλά και πάλι παραείναι.. αυτόματο οπότε οι πιο πολλοί δεν το ακουμπάμε αν δώσουμε αρκετές custom ρυθμίσεις.
Οπότε μένουμε με ένα τρόπο ρυθμίσεων που το μόνο που κάνει είναι expose το hardware προς το χρήστη. Η φιλοσοφία είναι ο χρήστης να.. προσαρμοστεί στις ανάγκες του hardware και των protocols. Οπότε ναι, η λογική για να κάνεις κάποια πράγματα είναι τελείως διαφορετική.

Πχ και γω τον πρώτο καιρό αναρωτιώμουν γιατί εκεί να ρυθμίζουμε VLAN ID και αλλού να ρυθμίζουμε PVID. Ε, γιατί έτσι το περιγράφει το πρώτυπο! Αλλά αυτό δεν είναι λογική user friendly. Αυτό είναι "Built by network engineers for network engineers". lol

Απλά σε κάποιους (μα###ες) μας αρέσει γιατί ταυτόχρονα μαθαίνουμε και το under the hood για τα δίκτυα.

- - - Updated - - -

Και για να αφήσω και κάτι χρήσιμο που έχω κρατήσει στις σημειώσεις

Essentially there are two sections of configuration:

ingress section under /interface bridge port
egress section under /interface bridge vlan

They are not entirely independent of each other though.

Interesting properties of ingress section:

pvid=
sets VLAN ID with which untagged frames are tagged on ingress
frame-types=
security property, which sets (part of) ingress filtering ... frames of wrong type are dropped on ingress.
ingress-filtering=
security propery which ties ingress section with egress section of configuration. If this property is set, then frames with VLAN IDs not in the list of allowed VLANs for egress are dropped.
The list of allowed VLAN IDs is derived from properties described in the next paragraph.

Interesting properties of egress section:

tagged=
frames tagged with VLAN ID will be allowed to egress through ports members of this list and will remain tagged on egress
untagged=
frames tagged with this VLAN ID will be allowed to egress through ports members of this list and will get untagged on egress
If a bridge port has pvid property set (see previous paragraph), then it's automatically added to this list. Doesn't hurt to add it explicitly though, it makes configuration export more self-descriptive.

Bridge ports don't care about other ports members of bridge. Port simply tags ingress frame with PVID value (or untags it on egress) and applies appropriate filters. Then port hands off frame to bridge.
The bridge has to deal with the frame. If ingress port is the lone member of VLAN, then bridge can't find any egress port (frame is never sent out through ingress port), so bridge drops the frame.

Συμβουλές

- Manage VLANs one by one, not grouped
- Activate the ingress-filtering and the appropriate frame-types in the ports (MT7621 μόνο το στάνταρ VLAN frame κάνει HW accelerate)
- In the access ports (untagged) the PVID should be selected on the bridge port options

Για management VLAN

- Without a good reason for it, don’t select untagged VLAN on the VLAN management
- On the bridge, enable vlan-filtering and change the PVID to the management VLAN

Για τα frame-types

Bridge ports with frame-types set to admit-all or admit-only-untagged-and-priority-tagged will be automatically added as untagged ports for the pvid VLAN. If you have a port in a VLAN-filtered bridge whose ingress "frame-types" is "admit-only-untagged-and-priority-tagged" (a pure access port), then you should/must not mention that port in any /interface bridge vlan entries (because it will be dynamically added to the "current-untagged" list of the /interface bridge vlan entry of its pvid).
On the other hand, if you have a port in a VLAN-filtered bridge whose ingress "frame-types" is "admit-only-vlan-tagged" (a pure trunk port), you should set its pvid to 1.

[deniSun]

Έστω ότι θέλουμε να υλοποιήσουμε το παραπάνω δίκτυο που το χρησιμοποιεί η ΜΤ ως παράδειγμα.
Δεν το αναλύει κάπου οπότε συμπεραίνω τα παρακάτω:
1. Από την ether3 θέλουμε να περνάει μόνο κίνηση με 30 και untag (στην ουσία κόβει όλα τα υπόλοιπα tagαρισμένα)
2. Ομοίως και στην ether2 όπου θέλουμε να περνάει το 20 με τους παραπάνω ανάλογους περιορισμούς.
3. Στην ether1 τώρα θέλουμε να περνάνε τα 99, 30, 20 και η untagάριστη κίνηση.
4. Φαντάζομαι ότι ορίζοντας vlans και έχοντας πχ στην 1 το 99.Χ, στην 2 το 20.Χ και στην 3 το 30.Χ
δεν χρειάζεται να δηλώσω δρομολογήσεις κλπ στο sw.
Θα βρίσκει μόνο του σε ποια θύρα θα στείλει τα πακέτα.
5. Αν το καταλαβαίνω σωστά το σχήμα ο ρούτερ επικοινωνεί με το sw με 99 ή untag και μετά προσθέτει πχ στην 2 το 20 και επικοινωνεί με την εκεί μονάδα μέσω 20.
Αν θέλει κάποια συσκευή από το 22 να επικοινωνήσει με τον router, φτάνει στο sw με 20 και στο ρούτερ πάλι με 20.

Στην υλοποίηση με bridge στην πρώτη περίπτωση όπως περιγράφεται εδώ έχουμε:

/interface bridge port
add bridge=bridge1 interface=ether1 frame-types=admit-only-vlan-tagged
add bridge=bridge1 interface=ether2 pvid=20 frame-types=admit-only-untagged-and-priority-tagged
add bridge=bridge1 interface=ether3 pvid=30 frame-types=admit-only-untagged-and-priority-tagged

Λογικά θα μπορούσε να οριστεί το vlan id και στο interface > vlan για κάθε πόρτα αλλά προφανώς χρειαζόμαστε τους περιορισμούς στο frame-types.
Για το 20 και 30 γίνεται κατανοητό.
Για το ether1 γιατί λέει ότι θα περνάει μόνο tagαρισμένη κίνηση αφού στο σχήμα φαίνεται ότι περνάει προς τα 20 και 30 και untag (η γκρι διαγράμμιση).
Αν έχει και άλλες ether οκ, αλλά αν έχει μόνο τρεις τότε πως θα φτάσει στην 2 και 3 untagάριστη κίνηση αφού από την 3 tagάρεις τα πακέτα και από την 1 δεν δέχεσαι untag;

/interface bridge
add name=bridge1 frame-types=admit-only-vlan-tagged

Αν λοιπόν δεν έχεις άλλες θύρες τότε τι ρόλο παίζει η παραπάνω εντολή;
Λογικά δεν αφήνει τίποτε να κινείται στο bridge αν δεν είναι tagαρισμένο.
Αυτό θα καταργούσε το untag στις 2 και 3 αλλά και στην 1.
Οπότε οι δηλώσεις των frame types στην 2 και 3 είναι περιττές για untag όπως επίσης και στην 1 ότι θα δέχεται μόνο tagαρισμένη κίνηση.

/interface bridge vlan
add bridge=bridge1 tagged=ether1 vlan-ids=20
add bridge=bridge1 tagged=ether1 vlan-ids=30
add bridge=bridge1 tagged=ether1,bridge1 vlan-ids=99
/interface vlan
add interface=bridge1 vlan-id=99 name=MGMT

Από την στιγμή που δηλώνει ότι το bridge θα έχει id 99 χρειάζεται να πει παραπάνω στο tagged και για την ether1 και για το bridge;
Δεν θα αρκούσε μόνο το παρακάτω;

add bridge=bridge1 tagged=ether1 vlan-ids=99

Από την πλευρά του ρούτερ χρειάζονται ανάλογες ρυθμίσεις ώστε να δέχεται τα αντίστοιχα vlans;

[minas]

Να επισημάνω πάντως ότι το SwOS στα Mikrotik έχει την λογική των περισσότερων vendors, αλλά και πολύ λιγότερες δυνατότητες από το ROS.

[deniSun]

Να επισημάνω πάντως ότι το SwOS στα Mikrotik έχει την λογική των περισσότερων vendors, αλλά και πολύ λιγότερες δυνατότητες από το ROS.

Δεν το έχω δοκιμάσει ποτέ.