Cisco-Router-Konfiguration für ISP/Wholesale: Routing-Policies & Skalierbarkeit

In ISP- und Wholesale-Netzen ist die Cisco-Router-Konfiguration vor allem eine Policy- und Skalierungsaufgabe: Routing-Policies müssen präzise steuern, welche Präfixe angenommen und announced werden, wie Traffic-Engineering umgesetzt wird und wie sich das Netzwerk bei Wachstum stabil verhält. Im Gegensatz zu Enterprise-Edges steht nicht „ein Standort“, sondern ein großer Routing-Scope mit vielen Peers, VRFs, Kunden und strengen Betriebsstandards im Fokus. Dieser Leitfaden zeigt Best Practices für BGP-Policies, Skalierbarkeit und betriebsfähige Cisco-Konfigurationen.

ISP/Wholesale-Spezifika: Was sich technisch unterscheidet

Wholesale-Umgebungen arbeiten mit vielen Peers und Kunden, oft in VRFs, und müssen große Routing-Tabellen sowie hohe Session-Zahlen sicher beherrschen. Die wichtigste Regel lautet: Nichts ohne Filter, Limits und klare Policy.

• Viele eBGP-Sessions: Upstreams, Peering, Kunden (CE/PE)
• Routing-Skalierung: große Tabellen, schnelle Konvergenz, stabile Flap-Resistenz
• Policy-Steuerung: Communities, LocalPref, MED, AS-Path, Prefix-Limits
• Isolation: VRFs für Kunden/Services, kontrollierte Route-Leaks
• Betrieb: 24×7 Monitoring, standardisierte Templates, Change-/Rollback-Prozesse

Policy-Grundprinzipien: „Default deny“ für Routen

Bei ISPs ist ein Routenleck ein Hochrisikoereignis. Daher gilt: Jede Route muss explizit erlaubt sein (Prefix-List/Route-Map). Zusätzlich gehören Prefix-Limits und Hygiene-Maßnahmen zur Pflicht.

• Inbound: nur erlaubte Präfixe akzeptieren, Bogons filtern
• Outbound: nur autorisierte Präfixe announcen (keine „le 32“ ohne Grund)
• Prefix-Limits: harte Obergrenzen pro Peer/Kunde
• Route-Maps: Policy-Attribute setzen (LocalPref, Communities)
• Dokumentation: Policy pro Peer/Kunde nachvollziehbar

BGP-Baseline für Skalierbarkeit: Hygiene und Monitoring

Skalierbarkeit beginnt mit einem konsistenten BGP-Grundgerüst: Logging, Session-Hygiene, konsistente Update-Quellen (Loopback), klare Descriptions und aussagekräftige Monitoring-Checks.

• Neighbor-Descriptions, klare Naming-Standards
• Neighbor-Change-Logging, sinnvolle Timer nach Design
• Update-Source (Loopback) bei iBGP/Route-Reflector-Designs
• Soft-Reconfiguration/Route Refresh (plattformabhängig) für Wartbarkeit

Beispiel: BGP-Hygiene (Auszug)

router bgp 65000
 bgp log-neighbor-changes
 neighbor 192.0.2.1 description UPSTREAM-ISP1
 neighbor 198.51.100.2 description PEERING-IXP
 neighbor 203.0.113.9 description CUSTOMER-ACME

Inbound-Policies: Bogons, Prefix-Filter und Limits

Inbound müssen Sie schützen: Bogons/Private Adressen aus dem Internet gehören verworfen, ebenso ungewollte Default-Routen oder zu lange Präfixe. Für Kunden müssen nur deren zugewiesene Präfixe akzeptiert werden.

Beispiel: Inbound Prefix-Policy für einen Kunden (nur autorisierte Netze)

ip prefix-list CUST-ACME-IN seq 10 permit 203.0.113.0/24
ip prefix-list CUST-ACME-IN seq 20 deny 0.0.0.0/0 le 32
route-map RM-CUST-ACME-IN permit 10

match ip address prefix-list CUST-ACME-IN

Beispiel: Prefix-Limit (Schutz gegen Route-Flooding)

router bgp 65000
 neighbor 203.0.113.9 remote-as 65010
 neighbor 203.0.113.9 maximum-prefix 50 90 restart 5
 neighbor 203.0.113.9 route-map RM-CUST-ACME-IN in

Outbound-Policies: Nur freigegebene Präfixe announcen

Outbound ist bei ISPs besonders kritisch. Grundregel: Announce nur aus einer autorisierten Source of Truth (z. B. Aggregat-/Kundenlisten), niemals „alles, was im Routing ist“. Prefix-Listen sind Pflicht.

Beispiel: Outbound Prefix-List + Route-Map

ip prefix-list OUT-AUTH seq 10 permit 198.51.100.0/24
ip prefix-list OUT-AUTH seq 20 permit 203.0.113.0/24
ip prefix-list OUT-AUTH seq 99 deny 0.0.0.0/0 le 32
route-map RM-OUT-AUTH permit 10

match ip address prefix-list OUT-AUTH

Beispiel: Outbound-Policy an Upstream binden

router bgp 65000
 neighbor 192.0.2.1 remote-as 65001
 neighbor 192.0.2.1 route-map RM-OUT-AUTH out

Traffic Engineering: LocalPref, Communities und AS-Path

In ISP/Wholesale steuern Sie Traffic über Attribute. Üblich ist: Inbound-Steuerung über LocalPref (welcher Upstream bevorzugt), Outbound-Steuerung über Communities an Upstreams (provider-spezifisch) oder AS-Path-Prepending.

Beispiel: LocalPref setzen (Upstream-Priorisierung)

route-map RM-UPSTREAM1-IN permit 10
 set local-preference 200
route-map RM-UPSTREAM2-IN permit 10

set local-preference 150
router bgp 65000

neighbor 192.0.2.1 route-map RM-UPSTREAM1-IN in

neighbor 192.0.2.5 route-map RM-UPSTREAM2-IN in

Beispiel: AS-Path-Prepend für Outbound-TE (vereinfachtes Muster)

route-map RM-PREPEND-ISP2 permit 10
 match ip address prefix-list OUT-AUTH
 set as-path prepend 65000 65000 65000
router bgp 65000

neighbor 192.0.2.5 route-map RM-PREPEND-ISP2 out

Skalierbarkeit mit iBGP und Route Reflectors

Ab einer gewissen Größe ist Full-Mesh iBGP nicht mehr praktikabel. Route Reflectors (RR) reduzieren Sessions, erfordern aber saubere Designregeln (Cluster-IDs, Redundanz, klare RR-Client-Definitionen).

• RR-Paar (redundant) statt Single Point of Failure
• Klare RR-Client-Gruppen (PoPs, Regionen, Services)
• Next-Hop-Handling konsistent, IGP für Loopbacks stabil
• Monitoring: BGP Session Count, Updates, Flaps

Beispiel: iBGP mit Loopback (konzeptionelles Muster)

interface Loopback0
 ip address 10.255.255.1 255.255.255.255
router bgp 65000

neighbor 10.255.255.2 remote-as 65000

neighbor 10.255.255.2 update-source Loopback0

VRF und Wholesale: Mandantentrennung und kontrollierte Route-Leaks

Wholesale-Services werden häufig über VRFs bereitgestellt. Wichtig ist, dass Routen nur gezielt zwischen VRFs geleakt werden (z. B. Shared Services), sonst entstehen Sicherheits- und Stabilitätsrisiken.

• VRF pro Kunde/Service (Isolation)
• Gezieltes Route-Leaking nur nach definiertem Policy-Plan
• Separate Monitoring- und Logging-Views pro VRF

Stabilität: Flap-Dämpfung, Konvergenz und Change-Sicherheit

In großen Netzen sind Flaps teuer. Stabilität entsteht durch klare Timer-Strategien, konsequentes Troubleshooting, und Change-Prozesse mit Pre-/Post-Checks. Jede Policy-Änderung muss getestet und rollbar sein.

• Prefix-Limits und Session-Health verhindern Eskalationen
• Route-Änderungen müssen nachvollziehbar geloggt werden
• Pre-/Post-Checks als Pflichtbestandteil jedes Changes
• Rollback: sofortige Rückkehr zur letzten stabilen Policy

Pre-/Post-Checks für BGP-Policy-Changes

show bgp summary
show bgp ipv4 unicast
show ip route summary
show logging | last 50

Monitoring und Alerting: Was im ISP-Betrieb zwingend alarmiert

Im ISP/Wholesale-Betrieb sind BGP-Events und Routenanzahlen zentrale Signale. Monitoring sollte nicht nur „Session up/down“, sondern auch Anomalien wie Routenanstiege, häufige Flaps und Prefix-Limit-Hits melden.

• BGP Neighbor down/flapping (kritisch)
• Routenanzahl pro Peer: plötzlicher Anstieg/Abfall (Anomalie)
• Maximum-prefix Warnungen und Drops
• CPU/Memory-Spikes bei Updates/Convergence
• Interface-Errors/Drops auf Peering-Links

Operative CLI-Checks (Runbook)

show bgp summary
show bgp ipv4 unicast
show bgp neighbors
show processes cpu sorted
show interfaces counters errors

Dokumentation und Deliverables: Policy als Betriebsmittel

Im Wholesale-Kontext ist Policy das Produkt. Deshalb müssen Policies dokumentiert, versioniert und auditiert werden. Eine „Config ohne Policy-Doku“ ist im Betrieb nicht tragfähig.

• Peer-/Kunden-Steckbriefe: ASN, IPs, Prefixe, Limits, Communities
• Inbound/Outbound-Policies: Prefix-Lists, Route-Maps, Attribute-Logik
• Monitoring-Regeln: Schwellenwerte, Alarmierung, Eskalationspfade
• Change-Runbooks: Pre-/Post-Checks, Rollback-Plan
• Versionierung: Git/Repo, Ticket-ID, Review-Freigaben

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab (CCNA)

Hallo! Ich bin ein CCNA-Network Engineer und unterstütze Sie bei Cisco Router- und Switch-Konfigurationen – inklusive eines vollständigen Cisco Packet-Tracer-Labs (.pkt). Ideal für Lern-/Übungsszenarien, Validierung oder eine saubere Demo-Topologie.

Was ich (je nach Paket) umsetze

• Switching: VLANs, Trunking (802.1Q), Port-Zuweisung, STP-Basics (PortFast/BPDU Guard wo sinnvoll)

• Routing: Default/Static Routing oder OSPF, Inter-VLAN Routing (Router-on-a-Stick)

• Services: DHCP (Pools/Scopes), NAT/PAT für Internet-Simulation

• Optional Security: Basic ACLs und SSH-Hardening

• Test & Verifikation: Ping/Traceroute + wichtige Show-Commands (mit erwarteten Ergebnissen)

Sie erhalten

• ✅ Packet Tracer .pkt Datei

• ✅ Saubere Konfigurations-Notizen pro Gerät

• ✅ Verifikations-Checkliste + erwartete Outputs

• ✅ Kurze Dokumentation (wie die Topologie funktioniert)

Bitte schreiben Sie mir vor der Bestellung, damit wir Scope, Packet-Tracer-Version, Geräteanzahl und Deadline klären.

Konfiguriere Cisco Router & Switches | Cisco Packet-Tracer-Labs. Finden Sie mich auf Fiverr.