Ervaringen met OpenFlow bij Universiteit Twente SURFnet, 30 juni 2016

Transcriptie

1 Ervaringen met OpenFlow bij Universiteit Twente SURFnet, 3 juni

2 Introductie Over mij Jeroen van Ingen Werkzaam bij Universiteit Twente en bij Quarantainenet UT: Senior netwerkbeheerder Focus op: Automatiseren beheer Troubleshooten complexe storingen Evaluatie nieuwe technieken Quarantainenet Software developer Focus op: Aansturing switches, WLAN controllers en accesspoints door Qmanage (device-specifieke modules) Januari augustus Veel affiniteit met Open Source Voorkeur voor zelf doen : de beste manier om te leren is door te doen

3 3 Waarom OpenFlow? /3 Klassieke switching en routing Layer : klassieke switching (per VLAN): Alleen MAC-adressen relevant Geen manipulatie van packets Waar zit wat (hosts) bijgehouden aan de hand van source MAC Forwarding van frames alleen gebaseerd op destination MAC laatste input port van source X bepaalt effectief de output poort voor destination X Layer 3: klassieke routing (per VRF) Alleen IP-adressen relevant (mits packets op L geadresseerd aan router!) Manipulatie van packets: rewrite van destination MAC Waar zit wat (subnets) bijgehouden door statische configuratie en routing protocols Forwarding van packets alleen gebaseerd op destination IP Source IP is niet relevant voor forwarding decision Aan elkaar lijmen van Layer en Layer 3: ARP voor IPv4 en ND voor IPv

4 4 Waarom OpenFlow? /3 Klassieke benadering is krachtig maar beperkend Layering van protocollen is erg krachtig Maakt ze (in principe) stuk voor stuk vervangbaar TCP en UDP kunnen net zo makkelijk over IPv4 als IPv IPv4 en IPv kunnen zowel over gewoon Ethernet (8.3) als WiFi (8.) als cellular technieken (GPRS, 3G/4G) IPv4 kan ook over IPv4 of over IPv, en omgekeerd: tunneling Zelfs transport van IP datagrams met postduiven is mogelijk (IPv4: RFC 49, IPv: RFC4) Switches en routers zijn ontworpen langs de lijnen van die protocollen Scaling/sizing is vaak per layer te bepalen Door de jaren heen wel meer awareness tussen layers: ACLs die zowel op Layer 3 als Layer 4 velden kunnen matchen Hardware NAT voor rewrite van Layer 3 en Layer 4 velden Vrijwel iedere optie bovenop klassiek switching en routing wordt door vendor beschouwd als een feature Standard ACLs vs Extended ACLs Hardware NAT Policy Based Routing DHCP Snooping, Dynamic ARP Inspection, etc Vendoren maken strategische keuzes in welke features ze implementeren, los van hardware capabilities

5 5 Waarom OpenFlow? 3/3 Ethernet, IPv4/IPv en TCP/UDP domineren Zeker in een LAN is vrijwel al het verkeer TCP of UDP Over IPv4 of IPv Over Ethernet Uiteindelijk gaat het niet om de losse protocollen, maar om goede werking van applicaties Dirigeren van verkeersstromen Meer flexibiliteit als stricte layering in een switch wordt losgelaten Zonder stricte layering: Protocollen niet makkelijk los vervangbaar In x packets matchen op verschillende velden, inclusief wildcards Manipulaties uitvoeren op packet in verschillende layers tegelijk Dingen mogelijk die met layering niet zouden kunnen, of specifiek als feature door de vendor geimplementeerd moeten worden op een router of switch Scaling wel moeilijker voorspelbaar!

6 OpenFlow op de UT / Initiele inzet: onderzoek Campus Challenge In 3 enkele Pica8 switches aangeschaft voor OpenFlow testbed 5x P-395 (G/G), x P-39 (G/4G) (extra P-39 sinds 5) Primair bedoeld voor onderzoek naar dynamische lichtpaden, onderdeel Campus Challenge SURFnet Met zo min mogelijk aanpassingen aan het netwerk, mogelijk maken om Layer paden te tunnelen over een routed (Layer 3) core Pica8 switches zijn betaalbaar en kunnen veel OpenFlow matching en actions in hardware Andere merken apparatuur in 3 nog veel beperkingen langs de lijnen van layers Vroeg ingestapt, dus diverse bugs en crashes gezien Uiteindelijk teveel beperkingen voor ons doel Idee was om dynamische tunnels te bouwen met OpenFlow het juiste verkeer in & uit de tunnels dirigeren Zo transparant mogelijk, alles hardware switched, alleen controller nodig voor setup & teardown van lichtpad transparant op een lichtpad impliceert behoud van Layer adressering, dwz behoud van MAC-adressen GRE tunneling wel mogelijk op P-395, maar niet voor complete frames, alleen IP over GRE

7 7 OpenFlow op de UT / Tweede inzet: combineren van port mirrors UT heeft mirror ( SPAN ) sessie op iedere SURFnet link Data gebruikt voor security monitoring en onderzoek Redundantie: border routers Iedere router x 4 Gbps en x Gbps uplink Via BGP effectief altijd maar van de 4 links met serieus verkeer Monitoring moet dus vanaf locaties en heeft gebruikers Handiger om monitor sessies eerst te combineren Na combinatie weer distribueren naar collectors

8 8 OpenFlow op de UT 3/ Port mirrors plaatje

9 9 OpenFlow op de UT 4/ Port mirrors simpele flow config duration= s, n_packets= , n_bytes= , in_port=5 actions=mod_vlan_vid:,output:5 7 dagen, 7 petabytes (!) in_port= actions=mod_vlan_vid:,output:34,output:35 in_port=47,dl_vlan= actions=mod_vlan_vid:,output:34,output:35

10 OpenFlow op de UT 5/ Uitbreiding: mirrordata reprocessing Vakgroep Design and Analysis of Communication Systems (DACS) Doen oa onderzoek naar Flow based anomaly detection Bijvoorbeeld detecteren van SSH attacks vanuit NetFlow data Detectie van mogelijke DDoS op een router zelf Cisco routers ondersteunen NetFlow en scripttaal TCL Kan je scripts schrijven op een router, die automatisch een DDoS detecteren, aan de hand van NetFlow analyse op de router zelf? Nodig voor onderzoek: Een router die genoeg verkeer verwerkt Liefst real world traffic, geen synthetisch/gegenereerd verkeer Losse opstelling, bij fouten geen verstoring van productie

11 OpenFlow op de UT / mirrordata reprocessing plaatje in_port= actions=mod_vlan_vid:,mod_dl_dst::d:: b5:3:,output:34

12 Toekomstplannen OpenFlow op de UT /3 Verbeteren mirror-setup OpenFlow gebruiken voor verwerken van port mirrors is eenvoudig Statische configuratie, relatief simpele eisen aan hardware Mirrors van 4G + G gaan momenteel een G poort uit Oversubscription van uitgaande poort Destination kan wel 4G interface worden, maar dure hardware Onverwachte performance hit Geen SPAN meer gebruiken, maar passieve optische taps Gebruikt geen dure resources op Cisco routers Geen enkele performance hit op Cisco routers Iets meer poorten nodig aan OpenFlow-zijde, maar dan nog steeds goedkoper

13 3 Toekomstplannen OpenFlow op de UT /3 Meer testen met HP/Aruba switches UT gebruikt Aruba (voorheen HP) switches voor distributie en access Hardware die we in 3 hadden ondersteunde wel OpenFlow, maar met veel beperkingen Inmiddels steeds meer hardware met nieuwere generaties ASICs, steeds minder beperkingen mbt OpenFlow Leuke feature: Service Insertion Tunnels Hardware tunneling van packets van/naar ander device Zou veel beter moeten performen dan een packet-in / packet-out

14 4 Toekomstplannen OpenFlow op de UT 3/3 UDP performance testing? OAM? MDNS/Bonjour gateway? Klachten over traag netwerk Zou je OpenFlow kunnen gebruiken als een soort packet reflector om round trip times te meten, zonder CPU overhead aan de reflector kant? Cisco core, HP distributie/edge HP implementeert een linktest protocol, dat Layer connectiviteit tussen twee switches per VLAN kan testen Gebaseerd op een oud Xerox protocol Cisco reageerde hierop in de 5/Sup7, maar dat was geen gedocumenteerde feature; niet meer ondersteund in SupT OAM-protocollen op Cisco weer niet ondersteund door HP Mogelijk alsnog te realiseren via OpenFlow? Protocollen die niet gemaakt zijn voor routed netwerken toch werkend krijgen Bonjour gateway tussen VLANs Kan inmiddels met HP switches als de switch beide VLANs voert Dat is op de UT niet altijd het geval: VLANs van wireless clients niet beschikbaar buiten datacenter Gatewayfunctie op een OpenFlow controller?

15 5 Visie tav OpenFlow op de UT Ervaringen uit de praktijk, inzichten vanuit theorie Specificatie is in de basis erg mooi en biedt veel flexibiliteit voor bepalen hoe packets behandeld moeten worden Lijkt? Is? Geschreven vanuit software-perspectief Echte hardware heeft altijd beperkingen Zuiver OpenFlow, zonder fallback naar klassiek routing of switching, schaalt niet Is qua hardware-eisen vergelijkbaar met een router die wirespeed oneindig veel routes kan leren en extreem lange ACLs kan verwerken die zowel L als L3 als L4 operaties bevatten Vereist ofwel extreem grote TCAMs ( duur tot onbetaalbaar ) ofwel flinke TCAMs en complexe pipelines ( prijzig tot duur en hoge complexiteit in hardware ) met vergrote kans op bugs, onverwachte feature-interactie / beperkingen Twijfelachtig hoe goed de belofte whitelabel switches zal uitkomen OpenFlow kan helpen in situaties waar je iets bijzonders wil, bovenop klassiek routing of switching Is dus mooi als aanvulling in de toolbox, maar geen vervanging (in de use cases voor een campusnetwerk)

16 Vragen? En ruimte voor discussie ;-)