Carrier Netzwerke. sicher, stabil, skalierbar, managebar für alle Netzwerkgrößen und -dienste. menschen.computer.netzwerke

Transkript

1 Carrier Netzwerke based on MikroTik RouterOS 3 sicher, stabil, skalierbar, managebar für alle Netzwerkgrößen und -dienste menschen.computer.netzwerke Bottenbacher Str Kreuztal Tel: Fax: info@meconet.de

2 Inhalt Summary & Begriffs-Definitionen Grundsätzliches, Warum der ganze Aufwand Aus Sicht des Netzbetreibers Aus Sicht des Endkunden Die Netzwerktopologie Die IP-Struktur Ethernet over IP Tunnel für PPPoE Tunnel für HotSpot Zentrale Dienste PPPoE-Server HotSpot-Gateway Die CPE Als W-DSL Modem Als (NAT-) Router Folie 2

3 Summary Demonstration des Netzwerkaufbaus für Wireless Internet Service Provider (WISP) und City-Carrier (CC), die auf Basis von MikroTiks RouterOS sichere, stabile, auf jede Netzwerkgröße skalierbare und einfach managebare Netzwerke aufbauen und betreiben wollen. Grundgedanke bei unserer Ende- Lösung ist es, dass sich das gesamte Netzwerk für Betreiber und Kunden so analog zu einem DSL-Netzwerk verhält, wie nur irgend möglich. Für den Endkunde verhält es sich komplett wie ein solches und er kann jeliches verfügbare DSL-Kundenequipment bei sich anschließen und einsetzen. Die für den Betreiber hierfür notwendigen Konfigurationen innerhalb seines Netzwerks zeigt diese Präsentation. Folie 3

4 Begriffs-Definitionen Backbone Bezeichnet das Trägernetzwerk des Betreibers, welches alle Zugangspunkte mit dem CO verbindet, reine Backbone-Systeme haben keine Verbindung zu CPEs CAP Customer Access Point, ein Zugangspunkt der auf der einen Seite mit dem Backbone verbunden ist und auf der anderen Seite public Access zur Verfügung stellt (Edge Device) CO Central Office oder auch Rechenzentrum des Netzbetreibers COE Central Office Equipment, ist das Equipment welches an zentraler Stelle im Betreibernetz steht CPE - Customer Premises Equipment, ist das Equipment welches in den Räumlichkeiten des Kunden benötigt wird PtP Point to Point Verbindung beschreibt eine dedizierte Punkt zu Punkt Verbindung zwischen z. B. zwei Funkroutern. Wir meinen hierbei immer impliziet, dass hierbei auch dedizierte Funk-Interfaces zum Einsatz kommen PtMP Point to MultiPoint Verbindung führt mehrere abgesetzte Uplinks auf einem Interface an zentraler Stelle zusammen Folie 4

5 Grundsätzliches Folie 5

6 Warum der ganze Aufwand? Grundgedanken aus Betreibersicht Ausfallsicherheit & Stabilität, Bandbreiten-Management Der Backbone kann als geroutetes Netz voll vermascht und damit ausfallsicher mit redundanten Pfaden aufgebaut werden. Auch wenn später PPPoE als Layer2 Protokoll verwendet werden soll. PPPoE verfügt über integrierte Techniken um ein Bandbreiten-Management auf einfachste Art und Weise zur Verfügung zu stellen. PPPoE (Point to Point over Ethernet) ist ein Standard der bei großen Netzwerkbetreibern etabliert ist und clientseitig für alle aktuelle Betriebssysteme PPPoE-Clients zur Verfügung stellt. Weiterhin steht eine vielfältige Auswahl an PPPoE fähigen (NAT-) Routern zur Verfügung. Folie 6

7 Warum der ganze Aufwand? Grundgedanken aus Betreibersicht IP-Management IP-Adressen sollen zentral vorgehalten werden, möglichst nicht in viele kleine Subnetze zerteilt und dann verteilt werden, da beim Aufteilen von IP-Netzen in kleinere Subnetze immer Adressen für weitere Netz- & Broadcast-Adressen verloren gehen. IP-Adressen und Subnetze sollen auf einfachste Art und Weise zum Endkunden gelangen, möglichst ohne weitere Routingeinträge. Das IP-Management muss dynamisch anpassbar sein, je nach Bedarf. PPPoE verfügt über integrierte Techniken um ein IP-Management auf einfachste Art und Weise zur Verfügung zu stellen. Folie 7

8 Warum der ganze Aufwand? Grundgedanken aus Betreibersicht Sicherheit Bestmögliche Absicherung des Backbone-Bereichs gegen Angriffe durch eigene Kunden und aus dem Internet, da Verbindungen durch den Backbone ausschließlich getunnelt durch diesen laufen. Der Backbone ist frei von jeglichen Default-Routen und aus IP-Sicht in sich geschlossen als RFC1918 IP-Netz realisiert. Kein Weg führt aus dem Backbone ins Internet oder zu den Kundennetzen. Innerhalb des Backbones gibt es nur IP-Traffic der eigenen Administratoren, jeglicher Kundentraffic wird per PPPoE duchgetunnelt. Der Backbone kann beliebige IP basierte Verbindungen haben, z. B. Kabel, Funk PtP, Funk PtMP, SFV, VPN u. a. und kann beliebig skaliert werden. Der gesamte Backbone egal wie groß und über welche Medien geführt - ist unsichtbar für den Endkunden Folie 8

9 Warum der ganze Aufwand? Grundgedanken aus Betreibersicht Sicherheit & Kundenanbindung Einfach und effektive Absicherung der Netz-Zugangspunkte, da nur das Tunnelprotokoll PPPoE von den CPEs auf und durch die Zugangspunkte notwendig ist. Abschluss des Netzwerks beim Kunden mit definiertem Equipment (W-DSL Modem = Wie DSL Modem) welches in der Hoheit des Netzbetreibers steht minimiert Probleme und Support und gewährleistet einen normierten Übergabepunkt und eine einheitliche Konfiguration & Management der CPEs durch den Netzbetreiber. Verwendung von handelsüblichen DSL-CPE Equipment um den Support für Endkunden zu minimieren. Support zu allen gängigen DSL-Router und der Funktionen findet der Endkunde im Internet. Der Betreiber kann auf einfache und normierte Art und Weise entweder nur das W-DSL Modem oder auch einen komplette DSL-Router (besser PPPoE-Router) zum gleichen Preis seinen Kunden zur Verfügung stellen. Folie 9

10 Warum der ganze Aufwand? Grundgedanken aus Endkundensicht Das Betreibernetzwerk verhält sich zu 100% wie ein DSL-Netzwerk, d. h. dem Endkunden stehen nahezu beliebige Endgeräte (CPEs) zum Anschluss an das Betreibernetz zur Verfügung. Der Endkunde ist optimal gegen andere Kunden geschützt. Der Endkunde kann dynamische oder statische IP-Adressen oder auch ganze IP-Subnetze auf sein Tunnelende geroutet bekommen. Folie 10

11 die Netzwerktopologie Folie 11

12 Der schematische Netzaufbau Customer-Access Bereich mit Einwahl & Festanbindung Customer-Access Bereich mit vielfältigen Anbindungsoptionen Ethernet SFV ISDN/DSL Dial-In Analog V.90 Digital 64/128 Privat Kunden asymmetrischer PPPoE-Uplink, dynamische IP Business Kunden, symetrischer PPPoE-Uplink, feste IP/Subnetu Internet HotSpot-User dynamische IP Public Internet ISP Uplink vorhandener ISP Backbone WISP Backbone Folie 12

13 Grundvoraussetzungen zum Netzwerk-Design Integrierbar in jede vorhandene Infrastruktur beim Netzbetreiber. Erweiterung der bestehenden Infrastruktur um einen weiteren Access- Bereich um weitere Kunden anbinden zu können. Als einziges Trägermedium kommt IP zum Einsatz, wobei es keine Rolle spielen darf, wie die einzelnen Links physikalisch beschaffen sind. Folie 13

14 Der Netzaufbau im Detail CAP-2 RADIUS Internet ISDN ISP-Backbone access line CAP-1 OSPF Backbone mit PtP-Links PPPoE Server HotSpot Server CAP-3 Public Internet CO WISP-Backbone CPE Folie 14

15 die IP-Struktur Folie 15

16 Der Netzaufbau im Detail die IP-Struktur Internet CO Zum Internet muss immer die Default-Route zeigen, in unserem Beispiel ist das Internet eingeschränkt auf das Netzwerk /8. Das COE verfügt i. d. R. über öffentliche IP-Adressen, als Platzhalter für diese verwenden wir in unserem Beispiel die folgende Netze COE /24 IP-Pool für PPPoE-Clients /24 IP-Pool für HotSpot-User /24 Diese Netze könnten auch Verwendung finden, wenn alles per NAT ins Internet übergeben wird. Backbone Der Backbone verwendet die RFC1918 Netzwerke 10.x.y.0/z. Wobei wir jedem CAP ein komplettes C-Netz in der Form 10.0.x.0/24 zuweisen. Für die notwendigen Transfernetze zwischen den Routern verwenden wir /29 Netze, da diese auch Platz für jeweils 2 Router auf jeder Seite unter der Verwendung von VRRP bieten. Mit den Transfernetzen beginnen wir ganz oben in der Art /29 und gehen dann immer ein Netz zurück. Folie 16

17 Der Netzaufbau im Detail die IP-Struktur CAP Jeder CAP erhält auf einem Localloop-Interface immer die 10.x.y.1/30, in unserem Beispiel sind das somit die Adressen CAP /30 CAP /30 CAP /30 Jeder CAP verwendet das Netzwerk 10.0.x.128/25 auf seinen Access- Interfacen, wobei der jeweilige CAP immer die 10.0.x.129/25 selbst hat. In unserem Beispiel sind die Adressen 10.0.x in einem DHCP-Pool aus dem die CPEs per DHCP-Client ihre Management-Adresse beziehen. Selbstverständlich kann diese IP-Adressierung auch statisch erfolgen oder ganz unterbleiben, was wir nicht empfehlen, da dann das Management der CPEs lediglich per MAC-Telnet möglich ist. Folie 17

18 Der Netzaufbau im Detail die IP-Struktur Uplink Carrier 1 Gateway des Netzbetreibers mit installiertem -> PPPoE-AC -> HotSpot-GW RADIUS OSPF Backbone mit PtP-Links CAP-2 CPE bekommt per DHCP die notwendige Management- IP Internet /8 Uplink Carrier 2 PPPoE Server HotSpot Server Bei größeren Installationen Sollten AC und HotSpot-GW eigenständige Devices sein. Ein externer RADIUS wird in dieser Demo nicht verwendet, ist aber möglich. CAP-1 CAP mit jeweils doppelter Netzanbindung und DHCP-Server für die CPEs CAP-3 Public Internet CO WISP-Backbone CPE HotSpot-User kommt automatisch ins HotSpot- Netz und erhält per DHCP eine IP-Adresse Folie 18

19 Der Netzaufbau im Detail die IP-Struktur /29 Internet / /29 zum CO: /24 PPPoE-SRV: /24 HotSpot-SRV: /24 Pools: PPPoE: HotSpot: auf Wlan1 zu CAP1: /29 auf Wlan2 zu CAP3: /29 Localloop-Adresse: /30 Customer Access: /25 DHCP-Pool CA: Routen & OSPF: Default-Route, statische Routen: keine Mitglied in OSPF-Area backbone CAP-1 zum CO: /24 auf Wlan1 zu CAP2: /29 auf Wlan2 zu CAP3: /29 Localloop-Adresse: /30 Customer Access: /25 DHCP-Pool CA: Routen & OSPF: Default-Route, statische Routen: keine Mitglied in OSPF-Area backbone auf Wlan1 zu CAP2: /29 auf Wlan2 zu CAP3: /29 Localloop-Adresse: /30 Customer Access: /25 DHCP-Pool CA: Routen & OSPF: Default-Route, statische Routen: keine Mitglied in OSPF-Area backbone CAP-2 CAP-3 Public Internet CO WISP-Backbone CPE CPE bekommt per DHCP die Management-IP aus dem Pool des jeweiligen CAPs HotSpot-User bekommt seine IP direkt aus dem zentralen IP-Pool des HotSpot-Servers Folie 19

20 Der Netzaufbau im Detail die IP-Struktur Durch den gerouteten, per OSPF vermaschten Backbone ist auf einfachste Art und Weise sichergestellt, dass jeder CAP doppelt angebunden ist. Sollte ein Link aus welchem Grund auch immer down gehen, berechnet das OSPF das Routing binnen kürzester Zeit neu und alle CAPs sind wieder erreichbar und funktionsfähig. In unserem Beispiel werden im Backbone nur WLAN PtP Links verwendet, es könnten natürlich auch leased lines (Standard Fest Verbindung jeglicher Art), VPN-Verbindungen oder andere, wie auch immer geartete, IP-Verbindungen zum Einsatz kommen. Die Localloop-Adresse ist eine Adresse an einem Interface, das niemals den Status down haben kann. Bei Mikrotik realisiert man ein derartiges Interface einfach über eine Bridge ohne jegliche Ports. Folie 20

21 Der Netzaufbau im Detail die IP-Struktur > interface bridge print Flags: X - disabled, R - running 0 R name="bridge1_local" mtu=1500 arp=enabled mac-address =00:00:00:00:00:00 protocol-mode=none priority=0x8000 auto-mac=yes admin-mac=00:00:00:00:00:00 max-message-age=20s forward-delay=15s transmit-hold-count=6 ageing-time=5m [admin@cap-1] > interface bridge port print Flags: X - disabled, I - inactive, D - dynamic # INTERFACE BRIDGE PRIORITY PATH-COST Dadurch wird erreicht, dass ein daran gebundenes IP-Interface immer up ist. Egal über welches Interface des Systems die IP-Daten fließen. So steht uns eine feste IP-Adresse pro CAP zur Verfügung, auf die notwendigen Tunnel terminiert werden können, unabhängig vom Status der Uplink-Interfaces des Systems. Folie 21

22 Ethernet over IP Folie 22

23 Der Netzaufbau im Detail die notwendigen Tunnel für PPPoE Wie kommt nun Layer2 Traffic der für die PPPoE-Tunnel der Endkunden und für die HotSpot-User benötigt wird über einen kompletten Layer3 Backbone? Die Lösung ist ganz einfach und setzt auf Mikrotiks EoIP (Ethernet over IP) Protokoll auf. EoIP stellt mit Hilfe des GRE-Protokolls einen Ethernet- Tunnel über IP zur Verfügung, wobei das EoIP-Tunnelinterface ein virtuelles Ethernet-Interface auf dem jeweiligen System darstellt, welches wie ein physikalisches Ethernet-Interface verwendet werden kann. Somit kann jedes Ethernet-Protokoll z. B. über eine beliebige IP- Verbindung gebridget werden. Folie 23

24 Der Netzaufbau im Detail die notwendigen Tunnel für PPPoE Wichtige Anmerkungen zur Arbeit mit EoIP-Tunneln EoIP-Tunnel sind nicht bidirektional. Es muss immer auf beiden beteiligten Systemen der EoIP-Tunnel zum jeweiligen Peer eingerichtet werden. Beide müssen die gleiche Tunnel-ID verwenden, die ansonsten einzigartig sein muss. Das Interface auf dem Remote-System, zu dem der EoIP-Tunnel konfiguriert wird, darf nicht mit dem EoIP-Tunnel zusammen in einer Bridge verwendet werden. Die MAC-Adressen für die EoIP-Interfaces (Tunnelenden) müssen per Hand vergeben werden. Der hierfür gültige Bereich ist von 00:00:5E:80:00:00 bis 00:00:5E:FF:FF:FF. Es funktiniert auch mit anderen MAC-Adressen, kann dann aber unerklärliche Fehler produzieren. Die MTU sollte auf 1500 Byte gesetzt sein, um ohne Fragmentierung Ethernet-Pakete über den Tunnel bridgen zu können. Folie 24

25 Der Netzaufbau im Detail die notwendigen Tunnel für PPPoE CAP-2 PPPoE Server EoIP-Tunnel CPE bekommt per DHCP die notwendige Management- IP Internet /8 CAP-1 CAP-3 Public Internet CO WISP-Backbone CPE Folie 25

26 Der Netzaufbau im Detail die notwendigen Tunnel für PPPoE Im Detail auf dem zentralen AC (Access Concentrator) Bridge1_ca EoIP-Tunnel zu CAP 1 EoIP-Tunnel zu CAP 2 EoIP-Tunnel zu CAP 3 EoIP-Tunnel zu CAP n [admin@inet-gw] > interface bridge print Flags: X - disabled, R - running 0 R name="bridge1_ca" mtu=1500 arp=enabled mac-address=00:00:5e:80:00:00 protocol-mode=none priority=0x8000 auto-mac=yes admin-mac=00:00:00:00:00:00 max-message-age=20s forward-delay=15s transmit-hold-count=6 ageing-time=5m [admin@inet-gw] > interface bridge port print Flags: X - disabled, I - inactive, D - dynamic # INTERFACE BRIDGE PRIORITY PATH-COST 0 eoip-tunnel_ap1_ca bridge1_ca 0x eoip-tunnel_ap2_ca bridge1_ca 0x eoip-tunnel_ap3_ca bridge1_ca 0x80 10 Folie 26

27 Der Netzaufbau im Detail die notwendigen Tunnel für PPPoE Im Detail auf dem zentralen AC (Access Concentrator) Auf dem AC wird ein EoIP-Tunnel direkt zu jedem CAP konfiguriert IP-Adresse auf CAP für Tunnel-Peer: Localloop-Adresse Auf dem AC kommen alle lokalen EoIP-Tunnel Interfaces in eine Bridge, auf die dann der zuständige PPPoE-Server konfiguriert wird. Um den AC bestmöglich zu schützen, lassen Bridge-Filter nur den notwendigen PPPoE-Traffic (Protokoll 0x8863 [PPPoE-Discovery] & 0x8864 [PPPoE-Session]) durch die Bridge auf den AC zu. Jeglicher anderer Traffic aus und in die EoIP-Tunnel wird geblockt. Folie 27

28 Der Netzaufbau im Detail die notwendigen Tunnel für PPPoE Im Detail auf den CAP (Zugangspunkten für Endkunden) > interface bridge print Flags: X - disabled, R - running 1 R name="bridge2_ca" mtu=1500 arp=enabled mac-address=00:00:5e:80:00:01 protocol-mode=none priority=0x8000 auto-mac=yes admin-mac=00:00:00:00:00:00 max-message-age=20s forward-delay=15s transmit-hold-count=6 ageing-time=5m Flags: X - disabled, I - inactive, D - dynamic # INTERFACE BRIDGE PRIORITY PATH-COST 0 eoip-tunnel_ap1_ca bridge2_ca 0x wlan3 bridge2_ca 0x80 10 EoIP-Tunnel zu AC Bridge2_ca Folie 28

29 Der Netzaufbau im Detail die notwendigen Tunnel für PPPoE Im Detail auf den CAP (Zugangspunkten für Endkunden) Auf jedem CAP wird ein korrespondierender EoIP-Tunnel zum AC konfiguriert IP-Adresse auf AC für Tunnel-Peer: Auf dem CAP kommt der EoIP-Tunnel zum AC sowie alle Interfaces die für Customer Access zuständig sind in eine Bridge. Hierbei können verschiedene Interfaces wie z. B. WLAN und Ethernet verwendet werden, falls z. B. ein Kunde am Standort des CAPs direkt per Kabel mit angebunden werden soll. Um die CAPs gegen ungewollten Traffic abzusichern, werden Filter eingesetzt, die nur PPPOE-Traffic von den CPEs und administrativen Traffic aus dem CO- Netz auf die CPEs zulassen. Folie 29

30 Der Netzaufbau im Detail die notwendigen Tunnel für HotSpot- Dienste Mit sehr geringen Aufwand hat der Netzbetreiber die Möglichkeit, an jedem Standort eines CAPs auch zusätzlich einen professionellen HotSpot-Dienst für Nomadische- oder Gelegenheits-Benutzer zu betreiben. Der Gesamtaufwand pro CAP beschränkt sich hierbei auf ein 2.4 GHZ Interface (kann auch ein virtueller AP sein), Kabel, Überspannungsschutz und Antenne, der Konfiguration eines weiteren EoIP-Tunnels auf ein zentrales HotSpot-Gateway im CO sowie der Betrieb eines selbigen im CO. Die Lösung erfolgt analog zu der Konfiguration der EoIP-Tunnel für PPPoE, aber getrennt von dieser. Folie 30

31 Der Netzaufbau im Detail die notwendigen Tunnel für HotSpot- Dienste CAP-2 HotSpot Server EoIP-Tunnel Internet /8 CAP-1 HotSpot-User kommt automatisch ins HotSpot- Netz und erhält per DHCP eine IP-Adresse CAP-3 Public Internet CO WISP-Backbone CPE Folie 31

32 Der Netzaufbau im Detail die notwendigen Tunnel für HotSpot- Dienste Im Detail auf dem zentralen HS-GW (HotSpot-Gateway) Bridge2_hs EoIP-Tunnel zu CAP 1 EoIP-Tunnel zu CAP 2 EoIP-Tunnel zu CAP 3 EoIP-Tunnel zu CAP n [admin@inet-gw] > interface bridge print Flags: X - disabled, R - running 1 R name="bridge2_hs" mtu=1500 arp=enabled mac-address=00:00:5e:80:00:06 protocol-mode=none priority=0x8000 auto-mac=yes admin-mac=00:00:00:00:00:00 max-message-age=20s forward-delay=15s transmit-hold-count=6 ageing-time=5m [admin@inet-gw] > interface bridge port print Flags: X - disabled, I - inactive, D - dynamic # INTERFACE BRIDGE PRIORITY PATH-COST 3 eoip-tunnel_ap1_hs bridge2_hs 0x eoip-tunnel_ap2_hs bridge2_hs 0x eoip-tunnel_ap3_hs bridge2_hs 0x80 10 Folie 32

33 Der Netzaufbau im Detail die notwendigen Tunnel für HotSpot- Dienste Im Detail auf dem zentralen HS-GW (HotSpot-Gateway) Auf dem HS-GW wird ein EoIP-Tunnel direkt zu jedem CAP konfiguriert IP-Adresse auf CAP für Tunnel-Peer: Localloop-Adresse Auf dem HS-GW kommen alle lokalen EoIP-Tunnel Interfaces in eine Bridge, auf die dann das zuständige HotSpot-Gateway konfiguriert wird. Mit Filtern kann eine direkte Kommunikation der HotSpot-User untereinander unterbunden werden. Folie 33

34 Der Netzaufbau im Detail die notwendigen Tunnel für HotSpot- Dienste Im Detail auf den CAP (Zugangspunkten für Endkunden) > interface bridge print Flags: X - disabled, R - running 2 R name="bridge3_hs" mtu=1500 arp=enabled mac-address=00:00:5e:80:00:07 protocol-mode=none priority=0x8000 auto-mac=yes admin-mac=00:00:00:00:00:00 max-message-age=20s forward-delay=15s transmit-hold-count=6 ageing-time=5m Flags: X - disabled, I - inactive, D - dynamic # INTERFACE BRIDGE PRIORITY PATH-COST 2 eoip-tunnel_ap1_hs bridge3_hs 0x wlan4 bridge3_hs 0x80 10 EoIP-Tunnel zu AC Bridge3_hs Folie 34

35 Der Netzaufbau im Detail die notwendigen Tunnel für HotSpot- Dienste Im Detail auf den CAP (Zugangspunkten für Endkunden) Auf jedem CAP wird ein korrespondierender EoIP-Tunnel zum HS-GW konfiguriert IP-Adresse auf HS-GW für Tunnel-Peer: Auf dem CAP kommt der EoIP-Tunnel zum AC sowie alle Interfaces die für den HotSpot zuständig sind in eine Bridge. Hierbei können verschiedene Interfaces wie z. B. WLAN und Ethernet verwendet werden, falls z. B. ein Internet Cafe am Standort des CAPs direkt per Kabel mit angebunden werden soll. Um die CAPs gegen ungewollten Traffic abzusichern, werden Filter eingesetzt, die nur Traffic vom und zum HotSpot-Gateway zulassen. Folie 35

36 Der Netzaufbau im Detail alle EoIP-Tunnel für PPPoE & HotSpot PPPoE CAP-2 PPPoE Server PPPoE HotSpot CPE bekommt per DHCP die notwendige Management- IP Internet /8 HotSpot Server HotSpot CAP-1 PPPoE HotSpot-User kommt automatisch ins HotSpot- Netz und erhält per DHCP eine IP-Adresse HotSpot CAP-3 Public Internet CO WISP-Backbone CPE Folie 36

37 zentrale Dienste Folie 37

38 Der Netzaufbau im Detail die zentralen Server-Dienste In unserem Beispiel laufen die zentralen Serverdienste auf dem Gateway zum Internet mit. Eine derartige Konfiguration ist praktikabel bei Netzen mit bis zu ca Endkunden. Bei größeren Netzen sollten beide Serverdienste auf separaten Systemen laufen. In diesem Fall ändert sich lediglich die lokale IP-Adresse der Systeme im CO. Bitte beachten Sie, dass dann die EoIP-Tunnel auf den CPAs entsprechend geändert werden müssen. Somit ist eine Skalierbarkeit der Gesamtumgebung gegeben. Man kann problemlos mit nur einem zentralen System starten und PPPoE- und HotSpot-Server später bei Bedarf einzeln auslagern, ohne das hierfür grundlegende Änderungen am Netzwerkdesign oder größere Umbaumaßnahmen notwendig werden. Folie 38

39 Der Netzaufbau im Detail die zentralen Server-Dienste Der PPPoE-Server Läuft auf der Bridge mit den EoIP-Tunneln zu den Customer Access Interfacen der CAPs. Routet auch wenn PPPoE ein Layer2 Protokoll ist! D. h. links und rechts vom PPPoE-Server müssen unterschiedliche IP-Netze sein, notfalls kann mit Proxy- ARP auf der Bridge gearbeitet werden, dies sollte aber nur als Notlösung in Betracht gezogen werden. > ip route print detail Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, B - blackhole, U - unreachable, P - prohibit 4 ADC dst-address= /32 pref-src= interface=<pppoe-pppoe-1> distance=0 scope=10 Zeigt die dynamisch generierte Route auf dem AC, nachdem sich der User pppoe-1 eingewählt hat und die IP-Adresse bekommen hat. Folie 39

40 Der Netzaufbau im Detail die zentralen Server-Dienste Der PPPoE-Server ether /24 PPPoE Server Bridge1_ca EoIP-Tunnel zu CAP 1 EoIP-Tunnel zu CAP 2 EoIP-Tunnel zu CAP 3 EoIP-Tunnel zu CAP n Die lokale IP-Adresse des PPPoE-Servers wird über die PPPoE-Server- Profile zugewiesen. Diese IP-Adresse sollte sich nicht im gleichen Subnetz befinden wie die IP-Adressen hinter den PPPoE-Tunneln, da über diese Adresse in die Tunnel geroutet wird! Folie 40

41 Der Netzaufbau im Detail die zentralen Server-Dienste Der PPPoE-Server Die Grundkonfiguration des PPPoE-Servers. > interface pppoe-server server print Flags: X - disabled 0 service-name="" interface=bridge1_ca max-mtu=1480 max-mru=1480 mrru=disabled authentication=pap,chap,mschap1,mschap2 keepalive-timeout=10 one-session-perhost=yes max-sessions=0 default-profile=pppoe-default [admin@inet-gw] > ppp profile print Flags: * - default 1 name="pppoe-default" local-address= remote-address=pool_pppoe bridge=bridge1_ca use-compression=no use-vj-compression=no use-encryption=yes only-one=yes change-tcp-mss=yes dns-server= , Folie 41

42 Der Netzaufbau im Detail die zentralen Server-Dienste Der PPPoE-Server Bandbreiten-Management Bandbreitenlimits können in entsprechenden Profilen hinterlegt werden und dann den einzelnen Benutzern in der User-Konfiguration hinzugefügt werden > ppp profile print Flags: * - default 2 name="pppoe-2mdown/512kup" local-address= remote-address=pool_pppoe bridge=bridge1_ca idle-timeout=30m use-compression=no use-vj-compression=no useencryption=yes only-one=yes change-tcp-mss=yes rate-limit=512k/2m dns-server= , [admin@inet-gw] > ppp secret print Flags: X - disabled # NAME SERVICE CALLER-ID PASSWORD PROFILE REMOTE-ADDRESS 0 pppoe-1 pppoe pppoe-1 PPPoE-2Mdown/512kup Folie 42

43 Der Netzaufbau im Detail die zentralen Server-Dienste Das Bandbreitenmanagement unter PPPoE wird komplett vom System nach den Vorgaben aus der Benutzerkonfiguration über Simple Queues geregelt. Es ist nichts weiter notwendig als dem Benutzer (direkt oder indirekt über ein Profil) die gewünschte Bandbreite mitzugeben. Somit sind synchrone und asynchrone Geschwindigkeiten mit beliebigen Parametern möglich. Der Netzbetreiber kann seine eigenen Bandbreiten einfach und schnell im System hinterlegen und den Endkunden auf einfachste Art und Weise per Profil zuweisen. Folie 43

44 Der Netzaufbau im Detail die zentralen Server-Dienste Das System legt die folgende Simple Queue dynamisch nach dem Login des Users pppoe-1 für diesen an: Das rechte Bild zeigt das aktive Queuing bei einem Download des Users. Folie 44

45 Der Netzaufbau im Detail die zentralen Server-Dienste In der Queue-Übersicht zeigt das rote Icon vor dem User, dass diese Queue bis zum Limit ausgelastet ist. Folie 45

46 Der Netzaufbau im Detail die zentralen Server-Dienste Die Interface-Statistik zu diesem PPPoE-Interface verdeutlicht das aktive Bandbreitenmanagement ebenfalls sehr eindrucksvoll. Einfacher kann die Kontrolle der einzelnen Bandbreiten pro Kunde für den Netzbetreiber nicht sein, als ein einfacher Eintrag in einem Profil, oder per RADIUS. Die Angabe der TXund RX-Rate sind in der Winbox vertauscht! Reihenfolge: RX/TX Aus Sicht des AC! (Stand bis 3.0RC4) Folie 46

47 Der Netzaufbau im Detail die zentralen Server-Dienste Der PPPoE-Server IP-Management > ppp profile print Flags: * - default 2 name="pppoe-2mdown/512kup" local-address= remote-address=pool_pppoe bridge=bridge1_ca idle-timeout=30m use-compression=no use-vj-compression=no useencryption=yes only-one=yes change-tcp-mss=yes rate-limit=512k/2m dns-server= , [admin@inet-gw] > ppp secret print detail Flags: X - disabled 4 name="subnetz" service=pppoe caller-id="" password="subnetz" profile=pppoe-2mdown/512kup remote-address= routes=" /29" limit-bytes-in=0 limit-bytes-out=0 IP-Subnetze können ebenfalls über die Benutzerkonfiguration übergeben werden. Hier wird das Subnetz /29 über die Remote IP- Adresse durch den PPPoE-Tunnel geroutet. Folie 47

48 Der Netzaufbau im Detail die zentralen Server-Dienste Bei der Einwahl des PPPoE-Users subnetz generiert das System die notwendigen Routen dynamisch. Das gesamte IP-Management für die Kunden wird somit zentral gesteuert. Es müssen nicht unzählige Routen durch den Backbone bis zum Ziel gepflegt werden. Folie 48

49 Der Netzaufbau im Detail die zentralen Server-Dienste Der HotSpot-Server Läuft auf der Bridge mit den EoIP-Tunneln zu den HotSpot Access Interfacen der CAPs. Das HotSpot-Netzwerk ist durch seine eignen Layer2 Tunnel komplett isoliert von den fest angebundenen Kunden. Kann ausgehen NAT für die HotSpot-User machen, kann aber auch mit öffentlichen IP-Adressen für die HotSpot-User arbeiten. Je nach Bedarf und den Möglichkeiten, die der Betreiber den Benutzern einräumen will. In dieser Präsentation gehen wir nicht weiter auf den HotSpot ein, da dieser alleine eine komplette Präsentation ausfüllen würde. Folie 49

50 die CPE Folie 50

51 Die CPE Die CPE kann bei gleicher Hardware - grundsätzlich in zwei unterschiedlichen Modi betrieben werden Als W-DSL Modem (Wie DSL Modem) In diesem Modus verhält sich die CPE wie ein DSL Modem bei DSL, d. h. der Kunde kann einen beliebigen DSL-Router (besser: PPPoE-Router) oder einen Client mit PPPoE-Client hinter der CPE verwenden und sich mit den überlassenen PPPoE- Zugangsdaten am Netz des Betreibers anmelden. Als Router mit oder ohne NAT für den Kunden Der Betreiber kann damit werben, dass er alles zur Verfügung stellt, und der Kunde keinerlei eigenes Equipment benötigt. In diesem Fall werden die PPPoE- Zugangsdaten auf der CPE eingetragen und der integrierte PPPoE-Client aktiviert. Die CPE kann hierbei NAT für den Kunden machen, oder auch transparent routen. Als Mehrwert kann der Betreiber dem Kunden auf diese Art und Weise z. B. managed Security Dienste gegen Entgelt anbieten, ohne in weitere Hardware investieren zu müssen. Folie 51

52 Die CPE als W-DSL Modem Hierzu bedarf es keiner großen Konfiguration, einfach das WLAN- Interface mit dem Ethernet-Interface in eine Bridge konfigurieren. > interface wireless print Flags: X - disabled, R - running 0 R name="wlan1" mtu=1500 mac-address=00:12:17:5d:16:89 arp=enabled interface-type=atheros AR5213 mode=station-pseudobridge ssid=" frequency=5660 band=5ghz scanlist= antenna-mode=ant-a wds-mode=disabled wds-default-bridge=none wds-ignore-ssid=no default-authentication=yes default-forwarding=yes default-ap-tx-limit=0 defaultclient-tx-limit=0 hide-ssid=no security-profile=wpa2-ca compression=no [admin@client-2] > interface bridge print Flags: X - disabled, R - running 0 R name="bridge1_pppoe" mtu=1500 arp=enabled mac-address=00:0c:42:15:36:4e protocolmode=none priority=0x8000 auto-mac=yes admin-mac=00:00:00:00:00:00 max-message-age=20s forward-delay=15s transmit-hold-count=6 ageing-time=5m [admin@client-2] > interface bridge port print Flags: X - disabled, I - inactive, D - dynamic # INTERFACE BRIDGE PRIORITY PATH-COST 0 ether1 bridge1_pppoe 0x wlan1 bridge1_pppoe 0x80 10 Folie 52

53 Die CPE als W-DSL Modem Die IP-Adresse für den Management-Traffic bekommt die CPE nach erfolgreichem WLAN Connect per DHCP (kann auch statisch erfolgen). > ip dhcp-client print detail Flags: X - disabled, I - invalid 0 interface=bridge1_pppoe host-name="client-2" client-id="client-2" add-default-route=yes use-peer-ntp=yes status=bound address= /25 gateway= dhcp-server= primary-ntp= expires-after=39m53s Nun kann der Endkunde hinter dem W-DSL Modem einen beliebigen PPPoE-Client verwenden und der Betreiber hat administrativen Zugriff auf das System. Folie 53

54 Die CPE als W-DSL Modem Um die CPE gegen den Kunden abzuschotten kommen Bridge-Filter zum Einsatz, die nur PPPoE-Traffic durch das System durchlassen und alles andere von Kundenseite her blocken. Somit kann der Endkunde auch z. B. mit der Winbox nicht mehr auf die CPE zugreifen. > interface bridge filter print Flags: X - disabled, I - invalid, D - dynamic 0 ;;; allow PPPoE-Discovery from ether1 chain=forward out-interface=wlan1 action=accept in-interface=ether1 mac-protocol=0x ;;; allow PPPoE-Session from ether1 chain=forward out-interface=wlan1 action=accept in-interface=ether1 mac-protocol=0x ;;; Block all other from ether1 chain=forward action=drop in-interface=ether1 3 ;;; Block all other from ether1 chain=input action=drop in-interface=ether1 Folie 54

55 Die CPE als (NAT-) Router Hierzu baut die CPE per PPPoE-Client über das WLAN-Interface den PPPoE-Tunnel zum AC auf und routet per NAT oder transparent den Kundentraffic durch den Tunnel. Diese Konfiguration ist auch mit RouterOS < 3.0 möglich. 0 R name="wlan1" mtu=1500 mac-address=00:12:17:5d:18:61 arp=enabled interface-type=atheros AR5213 radio-name="client-1" mode=station ssid=" frequency-mode=regulatory-domain country=germany antennagain=15 band=5ghz scan-list= ack-timeout=dynamic tx-power-mode=default default-authentication=no default-forwarding=yes proprietary-extensions=post security-profile=wpa2-ca [admin@client-1] > interface pppoe-client print detail Flags: X - disabled, R - running 0 R name="pppoe-out1" max-mtu=1480 max-mru=1480 interface=wlan1 user="router-1" password="router-1" profile=default service-name="" ac-name="" add-default-route=yes dial-on-demand=no use-peer-dns=yes allow=pap,chap,mschap1,mschap2 Folie 55

56 Die CPE als (NAT-) Router Hierbei muss allerdings die CPE per statischer IP-Adresse an einen CAP angebunden sein, da per DHCP eine Default-Route übergeben werden kann, die hier nicht brauchbar ist und OSPF nicht eingesetzt werden kann, da die Router-ID, die der IP-Adresse der jeweiligen CPE entspricht, sich bei DHCP ändert. Somit muss diese CPE fest auf einen CAP gebunden sein. > interface wireless connect-list print detail Flags: X - disabled 0 interface=wlan1 connect=yes mac-address=00:12:17:5d:1f:61 ssid=" min-signal-strength=-120 area-prefix="" security-profile=wpa2-ca Folie 56

57 Die CPE als (NAT-) Router Damit auf die CPE zu managementzwecken zugegriffen werden kann, benötigt diese noch eine statische Route. > ip route print Flags: B - blackhole, U - unreachable, P - prohibit, X - disabled, A - active, D -dynamic, C -connect, S -static, r -rip, b -bgp, o -ospf # DST-ADDRESS PREF-SRC G GATEWAY DIS INTERFACE 0 AD /0 r pppoe-out1 1 AS /24 r wlan1 2 ADC / pppoe-out1 3 ADC / wlan1 4 ADC / ether1 Zur Absicherung der CPE wird per Input-Filter jeglicher Zugriff aus dem Kundennetz auf die CPE geblockt. Folie 57

58 Wir bedanken uns für Ihre Aufmerksamkeit Folie 58