Sdn not just a buzzword
Download as PPTX, PDF0 likes512 views
- SDN is a concept that separates the network control plane from the forwarding plane, allowing for centralized control over the network. It comes in three flavors: Open SDN, SDN with overlays, and SDN via APIs. - SDN is needed because traditional networking has issues like high costs, difficulty managing networks, and inability to adapt to changing traffic patterns. SDN enables more programmable, automated networks that can better serve application needs. - OpenFlow is the main southbound protocol for SDN, allowing controllers to program the forwarding behavior of network elements. It enables centralized traffic engineering and management of network flows. - For SDN to see wider adoption, a "killer app" is
More Related Content
Similar to Sdn not just a buzzword (20)
![SDN Demystified, by Dean Pemberton [APNIC 38]](https://cdn.slidesharecdn.com/ss_thumbnails/sdndemystified1410925639-140917000156-phpapp02-thumbnail.jpg?width=560&fit=bounds)
Sdn not just a buzzword
- 1. Software Defined Networking It’s Not Just a Buzz Word Presentation at San Francisco Juniper Meetup August 25 2015 By Chris Jones @ SDN Essentials
- 2. Who the heck is THIS guy? Chris Jones SDN Engineer, SDN Essentials Juniper Ambassador Juniper Ingenious Champion [email protected] Twitter: @IPv6Freely Certifications JNCIE-ENT #272 CCIE #25655 (R&S) JNCIP-SP JNCIS-SEC JNCIS-QF Publications Day One: Junos for IOS Engineers Day One: Ambassadors’ Cookbook For Enterprise JNCIE-ENT Preparation Workbook 2 Okay, moving on...
- 3. Agenda • The OTHER buzz word in our industry • Some SDN definitions • OpenFlow, Overlays, and APIs… Oh my! • Network today is wonderful… or is it? • Open your mind to the possibilities • That blank box at the top of the block diagrams • Let’s discuss! 3
- 4. Let’s talk about cloud computing No, seriously. 4
- 5. We’ve all seen these… 5
- 6. … but we also know this isn’t the whole story • Not just a server sitting in a datacenter somewhere • Cloud implies pools of resources: storage, networking, and compute • Multi-tenancy is an important aspect • The entire point is that we just don’t care about the physical aspect 6
- 7. Okay, how is this relevant? I’m getting to it! 7
- 8. The classic definition of SDN The physical separation of the network 8 control plane from the forwarding plane, and where a control plane controls several devices.
- 9. Is this definition… 9 Vague? Morphed or Skewed? Entirely meaningless? Let’s clarify!
- 10. To be clear: 10 SDN is not a technology. Like cloud computing, SDN is a concept! However…
- 11. The definition has been skewed by vendors • Everyone seems to have their “SDN strategy” • It doesn’t seem to matter how close to the original definition it may be • It’s become confusing • What is SDN? • What isn’t SDN? • Are protocols used in an SDN solution now considered SDN? • Vendors aren’t helping this • We’re now classifying SDN in one of three flavors 11
- 12. Open SDN • The flavor of SDN that most closely resembles the original vision • Complete separation of control and forwarding • Utilizes some sort of central SDN controller • Simplified forwarding elements • Northbound interface for programmability • Southbound interface protocol usually OpenFlow • Commercial: Brocade, BigSwitch, NEC, HP • Open Source: OpenDaylight, Ryu, NOX, Trema 12 OpenFlow REST API Network Element Forwarding SDN Controller Control Management
- 13. SDN With Overlays • Still separates control from forwarding • Typically implemented in the hypervisor • Creates tunnels between hypervisors and/or physical network devices • VXLAN • GRE • NVGRE • EVPN • Enables multi-tenant Data Centers • Does not address the underlay • Northbound interface for programmability • Southbound interface protocol varies by vendor • Juniper Contrail, VMware NSX, Plumgrid, Nuage 13 Hypervisor Network Plug-in A1 B1 Hypervisor Network Plug-in A2 B2
- 14. SDN via API • Adds an API layer for programmability to existing network elements • Control plane remains distributed • Not... really... SDN, but vendors who use it call it SDN so we have to talk about it • Enables central network policy management • Southbound interface: OpFlex • Stopgap for investment protection • Cisco 14 Traditional Network Element Forwarding Control Management Management API OpFlex
- 15. Okay, so... 15 Hopefully that helps to clarify what SDN is.
- 16. So, why do we need SDN? Good Question! 16
- 17. “ ” In this business we shouldn’t forget what the purpose of the network is: to serve the needs of the application. And the network stopped doing that a while ago. Art Fewell, Network World 17
- 18. A bit more detail, please! • Traditional networking has some issues: • High operational costs • Difficult to manage • Network scalability has always been a problem • Unable to adapt to changing traffic patterns and flows • Decentralized • Monolithic software • Over-provisioning to aim for worst case scenario • L2/L3 load balancing far from perfect • Non-best path forwarding requires some kind of static configuration 18
- 19. Alright, so we have issues. How can SDN help? SDN enables a new way of looking at networks. Here, I’ll show you! 19
- 20. It Starts in the Data Center • The data center is the natural starting point for software defined networking • Overlays solve an immediate need • Tunnels using VXLAN or EVPN provide DCI options • Routing instances on tunnel endpoints (VTEPs) enable multi-tenancy • SDN complements existing orchestration platforms • An increased focus on east/west traffic for applications • Large firewalls hair-pinning traffic north/south is inefficient • Micro-services are becoming more prevalent • Programmability and automation are key in today’s data centers • The network must be reactive to application needs 20
- 21. But what about the underlay? • The underlay is irrelevant to the overlay • However, care must be taken to ensure the underlay does not become the bottleneck • L2 networks do not scale well enough • CLOS IP fabrics allow L3 equal-cost load balancing • The underlay may be a good place for OpenFlow • Some vendors handle both the overlay and underlay, and correlate the two 21
- 22. The WAN is a good place for SDN, too. • Traffic engineering is largely proactive and requires manual configuration • With SDN, reactive TE path computation based on network flows is possible • Path failure recovery can be signaled from a central SDN application and the controller • The central TE server has a full network view and can program paths directly • Eliminates over-provisioning • Google is already doing this 22
- 23. A Brief Overview of OpenFlow But by no means comprehensive! 23
- 24. OpenFlow (Over)simplified • If we started over… • OpenFlow is the southbound interface protocol between SDN controllers and forwarding elements • Enables programmability of the forwarding plane • Forwarding elements (switches) can run in one of two modes: • OpenFlow-only mode means that the switch uses OpenFlow for all forwarding decisions • Hybrid mode means the switch uses OpenFlow on some interfaces and traditional switching on others 24 SDN Controller Forwarding Element OpenFlow
- 25. Flow Matching • OpenFlow versions before 1.2 used simple match fields • Versions 1.2+ use TLVs. Not backwards compatible 25 Ingress Port MAC Src MAC Dst Eth Type VLAN Id VLAN Prior IP Src IP Dst IP Prot IP ToS TCP/ UDP sport TCP/ UDP dport • Match: perform associated action/instruction • No match: drop or forward to controller
- 26. Flow Tables • Prioritized list of Flow Entries • Evaluated in order, execute first match found • Each flow has a timeout (‘idle’ and ‘hard’) 26 Priority Match Fields Actions Stats Timers Priority Match Fields Actions Stats Timers Priority Match Fields Actions Stats Timers Priority Match Fields Actions Stats Timers . . .
- 27. Flow Matching Examples (1 of 2) 27 Ingress Port MAC Src MAC Dst Eth Type VLAN Id VLAN Prior IP Src IP Dst IP Prot IP ToS TCP / UDP sport TCP / UDP dport * * * * * * * * * * *3 Output: Port 5 * * * * * * * * * * * 08:2c:67: 81:3f:06 Output: Port 23 * * * * * * * * * * * 10.2.8.0 /24 Output: Port 82 Action
- 28. Flow Matching Examples (2 of 2) 28 Ingress Port MAC Src MAC Dst Eth Type VLAN Id VLAN Prior IP Src IP Dst IP Prot IP ToS TCP / UDP sport TCP / UDP dport * * * * * * * * * * *08:2c:67: 81:3f:06 Modify-field: VLAN Id = 22 * * * * * * * * * * *85 * * * * * * * * * 80 (HTTP) 0x0800 (IP) 0x06 (TCP) Action Modify-field: VLAN Pri = 7 Modify-field: IP ToS = 0x22
- 29. And how is this useful? The possibilities are endless, really. 29
- 30. What OpenFlow can do… in theory • Think about all the possibilities in a network where there is a single complete view • L2 or L3 routing no longer has to rely on information from neighbors for path computation • Spanning-Tree becomes unnecessary • Routing protocols like OSPF aren’t needed • Applications that forward to multiple end hosts are inherently supported • Okay, so I’m not suggesting these things are going to happen immediately, but… 30
- 31. That leads me to my final point (Time to wake up!) 31
- 32. We need that killer app! 32 Network Element Forwarding SDN Controller Control Orchestration Network Element Forwarding Network Element Forwarding Network Element Forwarding Application 2 ???????? Management Application 1 ?????????
- 33. In closing • Overlays are a great solution in the datacenter, but don’t address many of the current underlay restrictions • Open SDN shows tremendous promise, but will require an open mind and significant re-thinking of how networks are built • There are ways to go about it in a phased approach • Still need a “killer app” in order to provide business case • We’re still a ways away from mass adoption, by all accounts • Automation is an excellent precursor to SDN, and being made possible by our good friends in the DevOps movement 33
- 34. I’d like to hear your thoughts! 34 Not your everyday Q&A I want to hear where you could see SDN being useful to you
- 35. Thank you! Please feel free to contact me: [email protected] 35