Meraki-Lizenzen: Das Modell entscheidet, nicht der Preis

Zusätzliche Lizenzen vorab planen: Mit dem Co-Term-Rechner direkt die neue Laufzeit simulieren. Für die Beschaffung entscheidet außerdem, welches Lizenzmodell die Organisation trägt: Es bestimmt, wann Sie verlängern, welche Netze einen Termin teilen und was nach Ablauf und Kulanzfrist passiert. Und es lässt sich nicht beliebig wechseln.

Drei Modelle, von denen zwei zur Wahl stehen

Meraki dokumentiert drei Lizenzmodelle: Subscription, Co-Termination und Per-Device Licensing (PDL). Das dritte ist praktisch geschlossen — für Kunden, die in Regionen mit verfügbarer Subscription-Lizenzierung auf dieses Modell wechseln möchten, steht es nicht mehr zur Verfügung. Bestehende PDL-Organisationen laufen weiter, für eine Neuentscheidung bleiben also Subscription und Co-Termination.

Co-Termination: ein Datum für alles

Co-Termination führt jede Lizenz einer Organisation auf dasselbe Ablaufdatum. Meraki beschreibt die Rechnung offen: Alle aktiven Lizenzen werden zusammengemittelt und durch das Lizenzlimit der Geräte in der Organisation geteilt. Das Ergebnis ist die verbleibende Laufzeit — für alle Geräte gleichzeitig.

Für ein Filialnetz, das über Jahre wächst, ist das die entscheidende Eigenschaft: Zusätzliche Lizenzen für einen neuen Standort können das gemeinsame Datum verändern. Das ist kein Fehler, sondern der Zweck des Modells — ein Termin, eine Verlängerung, eine Rechnung. Es heißt aber auch, dass sich der Verlängerungszeitpunkt einer Organisation im Wachstum laufend bewegt und nicht einmal jährlich festgezurrt werden kann.

Co-Term-Rechner: das gemeinsame Datum vorab simulieren

Merakis eigener Lizenzrechner liegt im Dashboard hinter der Anmeldung — hilfreich im Betrieb, unerreichbar in der Angebotsphase. Für die Größenordnung vor dem Kauf genügt die dokumentierte Rechnung, und genau die bildet dieser Rechner ab: Bestandspositionen mit ihren Restlaufzeiten, neue Lizenzen mit voller Laufzeit.

Subscription: Laufzeit je Netz statt je Organisation

Subscription verschiebt die Lizenzierung von der Organisation auf die Netzebene. Ein Netz ist jeweils genau einer Subscription zugeordnet; mehrere Netze derselben Organisation können dieselbe Subscription nutzen. Ein eigener Standort hat deshalb nicht automatisch einen eigenen Vertragstermin. Unterschiedliche MX-Stufen sind innerhalb einer Organisation unter verschiedenen Subscriptions möglich.

• Laufzeit 36 bis 84 Monate, mit selbst bestimmtem Start- und Enddatum — der Termin folgt Ihrem Vertragsjahr, nicht dem Zufall der Einlösereihenfolge.
• Abrechnung monatlich, quartalsweise, jährlich oder vorausbezahlt statt ausschließlich im Voraus.
• Feature-Stufen sind wechselbar, ohne die Lizenzstruktur neu aufzubauen.
• Verfügbar weltweit außer in Russland und Belarus. Für Indien und Kanada nennt Cisco den Kauf über lokale Preislisten, Claiming und Verwaltung aber derzeit nur auf meraki.com, nicht auf meraki.in oder meraki.ca.

Essentials oder Advantage: die Stufenfrage

Innerhalb der Subscription-Lizenzierung folgt die zweite Entscheidung: die Feature-Stufe — Essentials oder Advantage, gewählt je Netz und Produktklasse (Wireless, Switching, Security/SD-WAN). Die Begriffe gehören zum Subscription-Vokabular; unter Co-Termination heißen die MX-Editionen stattdessen Enterprise, Advanced Security und Secure SD-WAN Plus. Wer beide Namenswelten in einem Angebot mischt, vergleicht Äpfel mit Birnen.

An der MX zeigt sich, was die Stufe trennt: Advantage bündelt unter anderem die ThousandEyes-Integration samt Internet-Ausfallanalyse, Adaptive Policy (SGT-Zuweisung), SD-Internet-Steuerung sowie Web-App-, WAN- und VoIP-Health — Essentials führt die Kernfunktionen. Eine Ausnahme dokumentiert Meraki ausdrücklich: Die vMX unterstützt die Advantage-Stufe nicht; ein Netz mit beanspruchter vMX kann sie für diese Produktklasse nicht setzen.

• Stufe je Netz und Produktklasse — die Zentrale kann Advantage fahren, während die Filiale mit Essentials auskommt, in derselben Organisation.
• Aufstieg ohne Umbau: Der Wechsel von Essentials auf Advantage ist ein dokumentierter Upgrade-Pfad, kein neues Lizenzprojekt.
• 30-Tage-Advantage-Trial je Netz und Produktklasse, kostenfrei. Danach fällt die Klasse automatisch auf Essentials zurück — Verkehr und Basisverwaltung laufen weiter, nur die Advantage-Funktionen enden. Ein neuer Versuch derselben Klasse ist erst nach 45 Tagen möglich.

Was bei Ablauf passiert — hier hört die Ähnlichkeit auf

Beide Modelle gewähren bei Nichteinhaltung zunächst eine Kulanzfrist von 30 Tagen. Danach verhalten sie sich grundlegend verschieden, und dieser Unterschied ist der eigentliche Grund, das Modell bewusst zu wählen.

Unter Co-Termination und PDL wird die betroffene Hardware nicht mehr betriebsfähig: Sie lässt sich nicht mehr konfigurieren, und die Netzprodukte lassen keinen Verkehr mehr ins Internet. Ein verpasstes Datum ist damit ein Ausfall.

Unter Subscription läuft das Netz weiter. Organisationen, die außerhalb der Konformität und über die 30 Tage hinaus sind, funktionieren weiter und leiten Datenverkehr weiter — Meraki stellt das ausdrücklich der Abschaltung des Vorgängermodells gegenüber. Stattdessen greifen automatisierte Maßnahmen, die den nicht konformen Geräten die Verwaltbarkeit entziehen, nach dem Prinzip „last in, first out“.

Lizenzverlängerung und Hardware-Lifecycle gemeinsam planen

Lizenzablauf, End-of-Sale (EOS) und End-of-Support (EOST) sind getrennte Termine. EOS bezeichnet den letzten Bestelltermin eines Produkts; EOST das Ende seiner aktiven Herstellerunterstützung. Ein vorhandenes Gerät erreicht mit EOS weder sein Lizenzende noch automatisch einen Abschalttermin. Eine verlängerte Lizenz verschiebt umgekehrt kein EOST. Für den Hardwareplan zählt die konkrete Produktankündigung, nicht eine pauschale Lebensdauer.

1. 01

   Planung mit klarer Zuständigkeit führen

   Organisation, Netze, Lizenzmodell, Subscription-Zuordnung, Produktklasse und Stufe, Gerätetypen und Mengen, Ablaufdatum, EOS/EOST-Quelle, Ersatztermin und Verantwortliche erfassen. Das ist eine eigene Planungsliste; einen automatischen Lifecycle-Gesamtreport im Dashboard setzt sie nicht voraus.

2. 02

   Mengen und Ersatz vor dem Angebot klären

   Unter Co-Termination aktuellen Bestand und Lizenzlimits je Gerätetyp abgleichen. Ein als Renewal eingelöster Schlüssel ersetzt die bisherigen Limits; fehlende Positionen können die Organisation aus der Konformität bringen. Bei Subscription die tatsächlich zugeordneten Netze und benötigten Mengen zugrunde legen.

3. 03

   Vorlauf mit einem Ergebnis verbinden

   Als eigene Planungsregel etwa 120 Tage vorher Bestand und Hardwareplan prüfen, 90 Tage vorher Angebot und Budget entscheiden und 30 Tage vorher die Verlängerung abschließen. Diese Abstände sind eine Arbeitshilfe, keine Cisco-Fristen. Beschaffungs- und Umbauzeiten können mehr Vorlauf verlangen.

4. 04

   Den erledigten Vorgang nachweisen

   Nach der Verlängerung tatsächliche Laufzeit, Mengen und Zuordnung mit der Bestellung abgleichen, die bestätigten Werte samt Prüfdatum festhalten und den nächsten Termin setzen. Hardwareersatz bekommt einen eigenen Auftrag und eine eigene Abnahme.

Ausgefülltes Beispiel: drei Standorte, zwei Subscriptions

Die konkrete Entscheidung im Beispiel: SUB-A umfasst 18 APs in zwei Netzen, SUB-B weitere vier. Die geplante Verlängerung von SUB-A bis 31.03.2030 braucht einen Ersatzplan für Generation A vor Ende 2028; die Lizenz wäre kein Beleg für Hardwareunterstützung bis zum Vertragsende. Unter Co-Termination wäre die Rechnung anders: Alle Lizenzen dieser Organisation liefen auf ein gemeinsames Datum. Neue Lizenzpositionen für einen Ausbau lassen sich im Rechner vorplanen; für eine Bestellung bleiben die tatsächlichen Lizenzdaten maßgeblich.

Was daraus für die Beschaffung folgt

1. 01

   Modell vor Hardware entscheiden

   Weil Subscription-Schlüssel in einer aktiven Alt-Modell-Organisation nicht eingelöst werden können und der Weg von PDL zu Subscription endgültig ist, ist das keine Frage für später.

2. 02

   Wachstum durchrechnen, nicht den Ist-Stand

   Unter Co-Termination wirken zusätzliche Lizenzpositionen auf das gemeinsame Datum. Wer in drei Jahren doppelt so viele Standorte hat, sollte wissen, wo der Termin dann liegt.

3. 03

   Das Ablaufverhalten schriftlich festhalten

   Ob bei Ablauf der Verkehr stoppt oder die Verwaltung, gehört ins Angebot und ins Betriebshandbuch — nicht in die Erinnerung eines Einzelnen.

4. 04

   Vorlauf einplanen, nicht Kulanz

   Die 30 Tage sind ein Sicherheitsnetz, kein Verfahren. Ein Verlängerungsvorgang, der erst mit der Warnmeldung beginnt, ist schon zu spät angesetzt.

Wie wir Lizenzlaufzeiten im laufenden Betrieb führen — zusammengeführte Termine, geplante Verlängerungen, Vorlauf vor jeder Frist — steht unter Cisco Meraki. Was an Struktur dazugehört, sobald es um viele Standorte geht — Templates, Claiming und die Reihenfolge — behandelt der Beitrag zum Meraki-Rollout über viele Standorte.