Vendor-übergreifendes Design: Interoperabilität in Telco Topologien sicherstellen

Vendor-übergreifendes Design ist in Telco-Topologien längst kein „Nice-to-have“ mehr, sondern eine strategische Notwendigkeit: Liefersicherheit, Innovationsgeschwindigkeit, Kostenkontrolle und regulatorische Anforderungen führen dazu, dass Carrier-Netze häufig aus mehreren Herstellern bestehen. Gleichzeitig ist Interoperabilität kein Selbstläufer. In der Praxis entstehen die teuersten Probleme nicht beim ersten Lab-Test, sondern im Betrieb: unterschiedliche Default-Timer, abweichende Interpretationen von Standards, unvollständige Feature-Implementierungen, proprietäre Erweiterungen, Telemetry-Formate, oder schlicht Unterschiede in der Hardware-Architektur (Queueing, TCAM, PPS-Handling). Ein sauberer Multi-Vendor-Ansatz beginnt deshalb nicht bei der Ausschreibung, sondern bei der Topologie: Wo dürfen Herstellergrenzen liegen? Welche Protokolle müssen wirklich interoperabel sein? Welche Features sind „must have“ vs. „nice to have“? Und wie stellen Sie sicher, dass Änderungen, Upgrades und Failure-Fälle in einem heterogenen Netz nicht zu unvorhersehbaren Effekten führen? Professionelles vendor-übergreifendes Design bedeutet: standardisierte Blueprints, klare Interface-Verträge (IGP/BGP/SR/EVPN, QoS, MTU), kontrollierte Feature-Sets, konsequente Observability, sowie Test- und Rollout-Methoden (Canary, progressive Wellen, Rollback), die Interop-Risiken früh erkennen. Dieser Artikel zeigt, wie Sie Interoperabilität in Telco Topologien systematisch sicherstellen – technisch, topologisch und operativ – ohne in Komplexitäts-Explosion oder Vendor-Lock-in 2.0 zu geraten.

Warum Multi-Vendor in Telco-Netzen schwer ist

Auf dem Papier sprechen alle „OSPF“, „BGP“, „MPLS“ oder „EVPN“. In der Realität gibt es Unterschiede: Protokolloptionen sind unterschiedlich aktiviert, Defaults variieren, bestimmte Corner Cases sind nur bei einem Hersteller sauber gelöst, und viele Betriebsfeatures (Telemetry, Logging, Protection Mechanisms) sind nicht standardisiert. Zudem sind Telco-Topologien groß: Ein kleiner Unterschied in Konvergenzverhalten oder Queueing kann im N-1-Fall plötzlich SLA-relevant werden.

• Standards sind oft „Optionen“: Zwei Geräte können standardkonform sein und trotzdem anders interagieren, weil optionale Teile anders implementiert sind.
• Defaults und Timer: Hello/Dead-Timer, BFD-Profile, BGP Keepalive/Hold, Dampening – Abweichungen erzeugen Flaps.
• Hardware-Realität: PPS, Buffering, Queue-Scheduling, TCAM-Profile und ECMP-Hashing sind sehr unterschiedlich.
• Operations & Tooling: Automatisierung, Telemetry und Troubleshooting unterscheiden sich; das erhöht OPEX.

Leitprinzip: Multi-Vendor ist ein Design- und Betriebsprogramm

Interoperabilität entsteht nicht durch „wir kaufen zwei Hersteller“, sondern durch eine bewusst reduzierte, getestete und operationalisierte Feature-Menge.

Topologie zuerst: Wo Herstellergrenzen sinnvoll sind

Ein häufiger Fehler ist, Herstellergrenzen „zufällig“ entlang Beschaffung oder Regionen zu ziehen. Besser ist ein topologischer Ansatz: Setzen Sie Herstellergrenzen dort, wo die Schnittstellen am stabilsten und am besten standardisiert sind – und vermeiden Sie sie dort, wo komplexe, herstellerspezifische Feature-Interaktionen passieren.

• Core/Transport vs. Edge/Services trennen: Der Core sollte „boring“ sein: IGP, MPLS/SR, BFD, FRR – möglichst standardnah.
• Interconnect Edge als eigene Rolle: Peering/Transit-Policies können vendor-spezifisch sein; kapseln Sie das in Edge-Domänen.
• DC/EVPN-Domänen bewusst schneiden: EVPN/Overlay ist interoperabel, aber in Details anspruchsvoll; Multi-Vendor besser pro Fabric-Domäne testen.
• Service-Edges isolieren: CGNAT/Firewall/DDoS sind häufig stark vendor- bzw. featureabhängig; klare Service-Domänen reduzieren Risiko.

Designregel: Herstellergrenzen an „stabilen Verträgen“ platzieren

Ein stabiler Vertrag ist z. B. „BGP über eBGP an einer klaren Edge-Kante“ oder „IP/MPLS-Transport mit klaren Label- und IGP-Regeln“. Ein instabiler Vertrag ist oft „komplexe Overlay-Edge-Funktionen mit vielen vendor-spezifischen Defaults“.

Interoperabilitäts-Blueprint: Das minimale, getestete Feature-Set

Der wichtigste Hebel für Multi-Vendor-Erfolg ist ein „Interop Blueprint“: eine definierte, reduzierte Menge an Protokollen, Optionen und Parametern, die netzweit gilt. Alles außerhalb dieses Blueprints ist entweder verboten oder braucht ein explizites Engineering-Review. So verhindern Sie, dass jede Region „ihr eigenes Netz“ baut.

• IGP Standard: OSPF oder IS-IS mit klaren Areas/Levels, Metrikmodell, Authentisierung, LSA/LSP-Policies.
• BGP Standard: iBGP/eBGP, RR-Design, Next-Hop-Regeln, Communities, Max-Prefix, Graceful Restart Policy.
• MPLS/SR Standard: SRGB/SIDs (bei SR), Label-Policies, FRR/TI-LFA Anforderungen, MTU-Overhead.
• EVPN/VXLAN Standard: Route Types, DF-Handling, Multihoming-Modell, ARP/ND-Proxy, MTU und ECN/DSCP Mapping.
• QoS Standard: Klassenmodell, Marking, Queueing/Policing an definierten Engpässen, WRED/Buffer-Policies.

Anti-Pattern: „Jeder Vendor darf seine Best Practices ausrollen“

Vendor-Best-Practice-Dokumente sind wertvoll, aber im Multi-Vendor-Netz brauchen Sie eine gemeinsame „Netz-Best-Practice“. Sonst kollidieren Optimierungen.

IGP Interoperabilität: OSPF/IS-IS, Auth, Summarization und Timer

IGPs sind im Core das Stabilitätsfundament. Interop-Probleme entstehen selten bei Grundfunktion, sondern bei Details: Authentisierung, MTU, LSA/LSP-Handling, Segmentierung, BFD-Kopplung und Konvergenz-Tuning. Multi-Vendor-IGP-Design sollte konservativ und explizit sein: identische Timerprofile, klare Area/Level-Grenzen und klare Summarization-Regeln.

• Timer-Profile harmonisieren: Hello/Dead, SPF-Timer, LSA/LSP-Throttling – explizit konfigurieren, nicht Defaults vertrauen.
• BFD konsistent: Profile und Detection-Time; vermeiden Sie Profile, die nur ein Vendor stabil unterstützt.
• Summarization bewusst: Aggregation reduziert LSA/LSP-Last, kann aber Failure Visibility beeinflussen; topologisch passend planen.
• MTU/Adjacency: MTU-Mismatches sind ein Klassiker; End-to-end MTU-Standards und Checks sind Pflicht.

Designregel: IGP „boring by default“

Je weniger exotische IGP-Optimierungen, desto stabiler Interop. Performance gewinnen Sie eher über Topologie (ECMP, FRR) als über aggressive Timer.

BGP Interoperabilität: RR-Topologie, Communities und Failure Domains

BGP ist das Policy-Werkzeug und damit besonders anfällig für Drift. Multi-Vendor erfordert hier klare Standardisierung: Community-Schemata, LocalPref-Modelle, Max-Prefix, Route-Policies, und eine RR-Topologie, die Partitionen überlebt. Zudem unterscheiden sich Implementierungen bei Graceful Restart, Add-Path, Multipath und bei bestimmten Best-Path-Tiebreakern.

• RR-Design standardisieren: Hierarchische RRs, klare Cluster-IDs, Redundanz über Failure Domains.
• Community Contract: Einheitliche Bedeutung (z. B. no-export, blackhole, prepend, region-tag), keine vendor-spezifischen Sonderlogiken.
• Max-Prefix & Guardrails: Schutz vor Leaks und Prefix-Explosion; identische Schwellen und Runbooks.
• Feature-Disziplin: Add-Path, diverse Multipath-Optionen, GR/LLGR nur, wenn in Interop-Tests nachweislich stabil.

Anti-Pattern: RR-Mix ohne klare Governance

Wenn RRs von Vendor A anders filtern oder Communities anders behandeln als Vendor B, entstehen „zwei Wahrheiten“ im Netz. Das ist operativ sehr teuer.

SR-MPLS/SRv6 und FRR: Interop-Tiefe bewusst begrenzen

Segment Routing und FRR-Mechanismen sind leistungsfähig, aber in Details komplex. Interoperabilität ist möglich, jedoch nur mit sehr klaren Festlegungen: SRGB-Konsistenz, SID-Zuordnung, TI-LFA-Anforderungen, und – bei SRv6 – Header-Overhead und uSID/Micro-SID-Strategien. Multi-Vendor-Design sollte hier schrittweise vorgehen: erst Underlay stabil, dann Policies, dann fortgeschrittene Features.

• SRGB/SID Consistency: Einheitliche SRGB-Bereiche, klare Node-/Adj-SID-Strategien, dokumentiert.
• FRR/TI-LFA Mindestanforderungen: Welche Failure Cases müssen abgedeckt sein? Welche Topologiebedingungen gelten?
• Policy Distribution: SR Policies nur über getestete Controller/Mechanismen, nicht ad hoc pro Vendor.
• SRv6 Overhead: MTU-Plan, PMTUD/MSS, klare Profile, sonst drohen Blackholes.

Designregel: FRR ist nur so gut wie die Topologie

TI-LFA braucht passende Topologie. In Multi-Vendor-Setups sollten Sie Coverage messbar machen (welche Links/Nodes sind geschützt), statt auf implizite Annahmen zu vertrauen.

EVPN/VXLAN Multi-Vendor: Fabric-Domänen, DF-Handling und MTU

EVPN ist standardisiert, aber Multi-Vendor-Interop ist im Detail anspruchsvoll: DF-Wahl bei Multihoming, MAC/IP-Advertisement-Handling, ARP/ND-Proxy-Verhalten, ECMP und Flooding-Mechaniken. Ein bewährtes Pattern ist, EVPN-Fabrics als klar abgegrenzte Domänen zu behandeln: innerhalb der Domäne können Sie multi-vendor sein, aber nur nach strengen Tests; zwischen Domänen verwenden Sie stabile L3-Grenzen.

• Domänengrenzen: EVPN-Fabric als eigene Failure Domain, klare Northbound-L3-Interconnects.
• Multihoming-Modell festlegen: ESI-LAG oder andere Modelle; Interop-Tests für DF und Split-Horizon.
• ARP/ND-Proxy: Einheitliche Settings, sonst entstehen unklare Flooding/Reachability-Probleme.
• MTU-End-to-End: VXLAN/EVPN Overhead plus ggf. MPLS/SR; konsistent planen und überwachen.

Anti-Pattern: EVPN „über alles spannen“

Große L2-Stretch-Domänen erhöhen Failure Domains und Interop-Risiken. Besser sind kleinere EVPN-Domänen mit klaren L3-Grenzen und kontrolliertem DCI.

QoS, ECMP und Hardware-Unterschiede: Der unterschätzte Interop-Risikofaktor

Viele Interop-Probleme sind keine Protokollprobleme, sondern Hardware-/Forwardingprobleme: unterschiedliche Hashing-Algorithmen, Queue-Modelle, Buffergrößen, WRED-Verhalten und Scheduler. In Telco-Netzen kann das im N-1-Fall entscheiden, ob SLOs gehalten werden. Vendor-übergreifendes Design muss daher „Datenebene-Contracts“ definieren: welche DSCP-Werte gelten, welche Klassen, welche Mindestbandbreiten, welche Engpässe.

• ECMP Hash Contract: Welche Headerfelder werden gehasht? Wie wird LAG/ECMP Imbalance gemessen?
• QoS Class Model: Einheitliches Marking und Mapping; klare Regeln für Remarking an Domain-Grenzen.
• Buffer/Queue Expectations: Keine Annahmen aus einem Vendor auf den anderen übertragen; messen statt glauben.
• PPS/CPS Limits: Besonders wichtig für DDoS, Telemetry und Control-Plane-Schutz; CoPP-Profil pro Rolle.

Designregel: QoS gehört an Engpässe, nicht „überall gleich“

In Multi-Vendor-Netzen ist „überall identische QoS“ selten realistisch. Besser: ein einheitliches Klassenmodell, aber rollenbasierte Implementierung und klare Engpasspunkte.

Management und Telemetry: gNMI, Streaming, Syslog und Datenmodelle

Ein Multi-Vendor-Netz wird operational schnell teuer, wenn Management- und Telemetry-Standards fehlen. CLI und proprietäre APIs skalieren schlecht über Hersteller hinweg. Bewährt sind standardisierte Datenmodelle (OpenConfig, IETF YANG), gNMI/gRPC-Telemetry, sowie einheitliche Logformate und Korrelation (Change-IDs, Standortlabels). Wichtig ist auch: Telemetry muss topologisch „WAN-aware“ sein (Sampling, Batching), besonders bei Remote PoPs.

• Unified Telemetry Contract: Welche Metriken sind Pflicht (Queue-Drops, Portauslastung, BGP Health, CPU), in welchen Einheiten?
• gNMI/gRPC Streaming: Standardisierte Paths, Samplingraten, Backpressure-Strategien.
• Config-as-Code: Vendor-spezifische Templates, aber gemeinsame Absicht (Intent) und gemeinsame Validierung.
• Observability Labels: Region/PoP/Rolle/Linkklasse als Pflichtlabels, damit Interop-Probleme lokalisierbar sind.

Anti-Pattern: Multi-Vendor ohne einheitliches Datenmodell

Wenn jede Plattform andere Metriken liefert und anders benannt ist, werden SLOs und Troubleshooting unzuverlässig. Ein Telemetry-Contract ist so wichtig wie ein Routing-Contract.

Interop-Testing: Lab ist Pflicht, aber nicht genug

Interoperabilität muss getestet werden – und zwar nicht nur „Sessions up“. Entscheidend sind Failure Cases: Link down, Node down, RR-Ausfall, DCI-Partition, MTU-Grenzfälle, QoS unter Last, ECMP-Rehashing, und Upgrade-Szenarien. Ein gutes Testprogramm kombiniert Lab-Tests (deterministisch) mit Canary-Rollouts (realistische Last) und Failure Scenario Workshops (Methodik).

• Golden Lab: Reproduzierbare Topologien, standardisierte Testcases, Version-Matrix (SW/HW).
• Failure Scenarios: N-1/N-2, FRR/TI-LFA Coverage, BGP/IGP Konvergenz, Queue-Drops im Failover.
• Interconnect Tests: Prefix-Guardrails, Max-Prefix, Policy-Leaks, RS/Bilateral Verhalten.
• Canary in Produktion: Kleine Domains als reale Validierung, mit SLO-Gates und Rollback.

Designregel: „Expected vs. Observed“ dokumentieren

Jeder Test muss festhalten: erwartete Pfade/Timer/Policies und beobachtetes Verhalten. Das macht Interop-Probleme auditierbar und verhindert, dass Wissen nur im Kopf einzelner Experten bleibt.

Progressive Rollouts und Rollback: Multi-Vendor ohne Change-Drama

Vendor-übergreifende Netze verändern sich ständig: neue Releases, neue Hardware, neue Features. Deshalb ist Change Risk Management essenziell: Canary, progressive Rollouts, Freeze-Phasen und schnelle Rollbacks. Ein Multi-Vendor-Rollout ist nicht nur „Upgrade“, sondern auch Interop-Validierung unter Last.

• Canary Sites: Repräsentative PoPs/Links, die echte Last sehen, aber begrenzten Blast Radius haben.
• Wellen: Regionweise Rollouts mit Stop/Go Gates auf Basis von SLOs und Root-Cause KPIs.
• Rollback-Readiness: Reversibilität als Designkriterium; keine „one-way“ Änderungen ohne Plan.
• Version-Matrix Governance: Definierte, unterstützte Kombinationen (Vendor A x Vendor B), keine Wildwüchse.

Anti-Pattern: Versionsprünge ohne Interop-Matrix

Wenn Geräte in einer Domäne auf zufällig verteilten Versionen laufen, wird jedes Problem zu einer Interop-Detektivarbeit. Eine unterstützte Matrix reduziert Risiko und Diagnosezeit.

Vendor Lock-in vermeiden ohne „Lowest Common Denominator“-Netz

Ein häufiger Reflex ist, Multi-Vendor nur mit dem kleinsten gemeinsamen Nenner zu betreiben. Das reduziert zwar Interop-Risiko, kann aber Innovation und Effizienz bremsen. Ein besserer Ansatz ist „Standard Core, differenzierte Domains“: Im Core und an klaren Verträgen bleiben Sie standardnah; in abgegrenzten Domänen (z. B. DC Fabric, DDoS Scrubbing, Service Edge) können Sie gezielt vendor-spezifische Stärken nutzen – aber mit klaren Grenzen und Tests.

• Standard im Transport: IGP/BGP/MPLS/SR konservativ, stark standardisiert.
• Innovation in Domains: EVPN-Fabric, DDoS, CGNAT, Observability als abgegrenzte Domänen mit eigenen Blueprints.
• Klare Northbound Interfaces: L3-Grenzen, stabile eBGP-Verträge, definierte Communities.
• Operational Contracts: Telemetry- und Config-Contracts vereinheitlichen, nicht nur Protokolle.

Designregel: Interop durch klare Grenzen, nicht durch Verzicht

Sie müssen nicht alles gleich machen, aber Sie müssen klar definieren, wo Unterschiede erlaubt sind und wie diese Unterschiede operational beherrscht werden.

Typische Fallstricke und wie man sie vermeidet

• Timer- und Default-Drift: Lösung: explizite Profile für IGP/BGP/BFD, keine Defaults, regelmäßige Audits.
• QoS/ECMP inkonsistent: Lösung: Klassenmodell + rollenbasierte Implementierung, Imbalance- und Drop-Monitoring.
• EVPN-Interop unerwartet fragil: Lösung: Fabrics als Domänen, DF/Multihoming testen, klare L3-Grenzen.
• RR-Design zu komplex: Lösung: hierarchische RR-Topologie, Failure Domains, konsistente Policy Distribution.
• Telemetry-Chaos: Lösung: gNMI/OpenConfig Contracts, Pflichtmetriken, Limits und Backpressure.
• Upgrades ohne Matrix: Lösung: unterstützte Version-Matrix, Canary, progressive Rollouts, Rollback.
• Zu viele Sonderfälle: Lösung: Blueprints, Governance, Ausnahmeprozesse mit Ablaufdatum.

Praktische Leitlinien: Interoperabilität in Telco Topologien sicherstellen

• Topo-Rollen definieren: Core/Transport, Interconnect Edge, Service Edge, DC Fabric – klare Domänengrenzen statt Mischbetrieb.
• Interop Blueprint erstellen: Minimales, getestetes Feature-Set (IGP/BGP/SR/EVPN, QoS, MTU) als verbindlicher Vertrag.
• Timer und Defaults explizit setzen: Einheitliche Profile für IGP/BGP/BFD, keine impliziten Vendor-Defaults.
• Guardrails verpflichtend: Max-Prefix, Policy-Whitelists, Exportfilter, CoPP – schützt Control Plane und begrenzt Blast Radius.
• QoS und ECMP als Datenebenen-Contract: Einheitliche Klassen, klare Engpässe, Imbalance/Drops messen.
• Unified Telemetry Contract: gNMI/OpenConfig/IETF YANG, Pflichtmetriken, Sampling/Batching, klare Labels.
• Testprogramm etablieren: Golden Lab + Failure Scenarios + Canary in Produktion; Expected vs. Observed dokumentieren.
• Progressive Rollouts nutzen: Canary → Batch → Wellen, Freeze-Phasen, objektive Go/No-Go Gates.
• Version-Matrix steuern: Unterstützte Kombinationen definieren, Wildwuchs verhindern, Upgrades planbar machen.
• Ausnahmen kontrollieren: Sonderfälle nur mit Review, Dokumentation und Ablaufdatum, damit Komplexität nicht explodiert.