SlideShare a Scribd company logo

btNOG 5: Network Automation

•
•
APNIC
APNIC

Senior Network Analyst Tashi Phuntsho gives an overview of network automation at the fifth Bhutan Network Operators Group (btNOG 5) meeting on 4 June 2018.

Related slideshows

SDN :: Software Defined Networking –2017 Executive Overview
SDN :: Software Defined Networking –2017 Executive OverviewSDN :: Software Defined Networking –2017 Executive Overview
SDN :: Software Defined Networking –2017 Executive Overview
 
Demystifying Orchestration and Assurance Across SDN NFV CE2.0
Demystifying Orchestration and Assurance Across SDN NFV CE2.0Demystifying Orchestration and Assurance Across SDN NFV CE2.0
Demystifying Orchestration and Assurance Across SDN NFV CE2.0
 
The History and Evolution of SDN
The History and Evolution of SDNThe History and Evolution of SDN
The History and Evolution of SDN
 
1 of 28
Download to read offline
SDN ~ Network Automation btNOG5 - Thimphu 4 June 2018 Tashi Phuntsho (tashi@apnic.net)
Routers 2 • Two key roles: Packet forwarding Determining network paths
Today’s router 3 Other Hardware Network Interfaces CPUs ASICs NPUs Switch Fabric Control Memory (T)CAM FIB Management CLI SNMP High Availability Resiliency Protocols Network Layer RIBRouting Protocols Services Layer IP L2 L3 Application Layer (DPI etc) QoS Queue Management Hardware Redundancy Traffic Managers Packet Memory Scheduling Algorithms Security AAA CPU Protection Accounting
How did we get here? 4 Distribution of complexity Backwards compatibility Unanticipated applications Need for higher performance • ‘End-to-end principle’ • Better scaling • Survivability; spreading of risk • “Flag days” not realistic • Short-term, incremental evolution of technology; no major overhaul in last 20-30 years • Networking is a victim of its own success • New complex applications have been delivered on top of existing capabilities • Tight coupling between different planes seen as critical for delivering higher performance
Clean Slate Project (1) 5 With what we know today, if we were to start with a clean slate, how would we design a global communications infrastructure? Two research questions: How should the Internet look in 15 years from now?
Clean Slate Project (2) 6 • One of the flagship projects was ‘Internet Infrastructure: OpenFlow and Software Defined Networking’ • Seminal paper on ... kicked off the SDN movement and the network world would never be the same again
OpenFlow: The Problem • Initial Problem: – A mechanism was required to run experimental network protocols. – Open software/hardware platforms did not provide the performance – commercial routers/switches were too closed and inflexible. 7 Hardware Software Tight coupling Closed system – only functionalities exposed by vendors available Challenge: how to influence forwarding behaviour in non-native ways?
OpenFlow: The Solution (1) 8 FROM TO Routing/Bridging Protocols, RIBs, routing policy and logic Forwarding Tables Abstracted Flow Table Secure Channel OpenFlow Protocol Control Plane Data Plane Data Plane OpenFlow Controller Control Plane Control Plane Data Plane Protocols and algorithms to calculate network paths – interoperable Forwarding frames/packets based on paths calculated by control plane – hw dependent
OpenFlow: The Solution (2) 9 Secure Channel Abstracted Flow Table OpenFlow Controller OpenFlow Protocol Data Plane Control Plane The solution? A compromise: • that allowed forwarding behaviour to be influenced without opening up network software – The control process would run on a controller – Decisions would be pushed down to the data plane running on the network element
10 Secure Channel Abstracted Flow Table OpenFlow Controller OpenFlow Protocol Control Plane * Ingress Port, Ethernet SA, Ethernet DA,VLAN ID,VLAN PCP, IP SA, IP DA, IP Proto, IPToS, Source L4 Port, Dest L4 Port etc…. Adds, deletes and modifies flow table entries Header Fields* Actions Counters Flow 1 Forward to port 1/1 Flow 2 Drop Flow n Send to controller Switch forwards traffic: by matching against header fields and executing corresponding actions OpenFlow: How it works (1)
OpenFlow: How it works (2) 11 Secure Channel Abstracted Flow Table OpenFlow Controller OpenFlow Protocol Control Plane Secure Channel Abstracted Flow Table Secure Channel Abstracted Flow Table . . . Switch 1 Switch 2 Switch n OpenFlow Protocol One controller manages many switches
OpenFlow: Today • Initially synonymous with SDN • Today, just one of the many protocols within the greater SDN framework • However, responsible for the most radical shift in networking – spark that lit the fuse J 12
OpenFlow: Implications • Two primary implications: 13 The control plane is physically decoupled from the data plane The control plane is consolidated and centralised: a single control plane controls multiple data planes (previously a 1:1 correspondence).
Aside: Data/control plane separation challenges 14 Scalability The control element now needs to be scaled to support a very large number of forwarding elements Reliability The controller can NOT be a single point of failure Consistency When multiple controllers are used (redundancy), consistency has to be assured across multiple replicas
The birth of SDN 15 The separation of control and data plane was not an objective in itself but a compromise approach taken by OpenFlow Ushered a new era of programmability that has been vastly enhanced with new architectures and capabilities The term‘SDN’ itself - an article about the OpenFlow project at Stanford (http://www2.technologyreview.com/news/412194/tr10-software-defined-networking/)
SDN - Emergence & Evolution 16 • OpenFlow was a starting point… – era of programmability • But a complete decoupling of the control and data plane? – impractical – Difficult to solve all the problems the industry had spent decades solving and refining: resiliency, scalability, convergence, redundancy.. • SDN architecture today – Hybrid: some control elements still remain distributed while others are centralised – Many different architectural models (from OF concept) • All aspire to achieve the goals of agility and network programmability
Hybrid model of SDN 17 Proportion of centralisation of control plane Data Plane Today’s model Control plane is fully distributed (collocated with the data plane) 0% 100% OpenFlow model Control plane is completely de-coupled from the data plane Hybrid model Certain control functions are centralised while others continue to be distributed with the data plane
Defining SDN 18 ONF: The physical separation of the control plane from the forwarding plane, and where a control plane controls several devices. Too narrow… Automation through enhanced programmability and open interfaces Dis-aggregation and abstraction Centralisation of control functions with real-time network visibility SDN is … A new approach to networking that provides greater agility and flexibility by:
Architectural Framework (1) 19 ITU-T Y.3300 SDN Controllers SDN Applications Network Resources Application control interface Resource control interface
20 Application Plane Application Service Network Services Abstraction Layer Control Plane Service App Control Abstraction Layer (CAL) Management Plane App Mgmt.Abstraction Layer (MAL) Service Interface Device & Resource Abstraction Layer (DAL) Forwarding Plane App Operational Plane Network Device CP Southbound Interface MP Southbound Interface RFC 7426 Architectural Framework (2)
21 Application Plane Application Service Topology Discovery & Management Network Devices – IP/MPLS/Transport Southbound Interfaces REST/RESTCONF/NETCONF/XMPP Control Plane (controller) Traffic Engineering Route selection & failover Resource Management BGP-LS PCE-Pi2RS SNMP MIBs OpenFlow YANG Configuration Open Flow SNMP NETCONF Data Plane (w ith som e distributed control plane elem ents) BGP PCCRIBs/FIBs Segm ent Routing RSVP-TE East/West- bound interfaces IPFIX Northbound Interfaces Note: designations of north-bound and south-bound are relative to the control plane (“controller”) Device & Resource Abstraction Layer (DAL) Network Services Abstraction Layer Architectural Framework (3) ForCES
Evolution NOT Revolution • Despite the hype, SDN is an evolution of current network technologies • No one protocol that defines SDN – it is a new architectural framework for data networks • Protocols/technologies that enable: – centralising control plane – abstracting networks and topologies – enhancing programmability via standard interfaces are considered a part of the SDN framework of technologies 22
Open source projects 23 • NOX/POX • Beacon • OpenDayLight (ODL) • Open Network Operating System (ONOS) • Ryu • OpenContrail • Floodlight • ……………
Deployment Example 24
EOLO’s BLU Project • Their own router - BLUrouter – TileGX architecture (72 core CPU) – Low power • Their own Router OS – BLUos – based on 6WINDGate – Customisation: RFC3107 (label distribution) in Quagga (BGP) • Their own controller – BLU-GW – limit human error – Parallel execution of commands, schedulers, config-rollback
BLU Project – Stage 1 • OpenFlow rules for MPLS label switching • RFC3107 for traffic labelling (downstream) • Problems: – OpenFlow granularity issues • Change of single flow required all BLUs along the path to be reprogrammed • Upgrades are atomic - high risk of inconsistent nw states – no fallback!
BLU Project – Stage 2 • Segment Routing + RFC3107 for traffic labelling – MPLS dataplane for now… – IGP as fallback (distributed control function) Contact them: blu@eolo.it
28 TASHI DELEK

More Related Content

btNOG 5: Network Automation

  • 1. SDN ~ Network Automation btNOG5 - Thimphu 4 June 2018 Tashi Phuntsho (tashi@apnic.net)
  • 2. Routers 2 • Two key roles: Packet forwarding Determining network paths
  • 3. Today’s router 3 Other Hardware Network Interfaces CPUs ASICs NPUs Switch Fabric Control Memory (T)CAM FIB Management CLI SNMP High Availability Resiliency Protocols Network Layer RIBRouting Protocols Services Layer IP L2 L3 Application Layer (DPI etc) QoS Queue Management Hardware Redundancy Traffic Managers Packet Memory Scheduling Algorithms Security AAA CPU Protection Accounting
  • 4. How did we get here? 4 Distribution of complexity Backwards compatibility Unanticipated applications Need for higher performance • ‘End-to-end principle’ • Better scaling • Survivability; spreading of risk • “Flag days” not realistic • Short-term, incremental evolution of technology; no major overhaul in last 20-30 years • Networking is a victim of its own success • New complex applications have been delivered on top of existing capabilities • Tight coupling between different planes seen as critical for delivering higher performance
  • 5. Clean Slate Project (1) 5 With what we know today, if we were to start with a clean slate, how would we design a global communications infrastructure? Two research questions: How should the Internet look in 15 years from now?
  • 6. Clean Slate Project (2) 6 • One of the flagship projects was ‘Internet Infrastructure: OpenFlow and Software Defined Networking’ • Seminal paper on ... kicked off the SDN movement and the network world would never be the same again
  • 7. OpenFlow: The Problem • Initial Problem: – A mechanism was required to run experimental network protocols. – Open software/hardware platforms did not provide the performance – commercial routers/switches were too closed and inflexible. 7 Hardware Software Tight coupling Closed system – only functionalities exposed by vendors available Challenge: how to influence forwarding behaviour in non-native ways?
  • 8. OpenFlow: The Solution (1) 8 FROM TO Routing/Bridging Protocols, RIBs, routing policy and logic Forwarding Tables Abstracted Flow Table Secure Channel OpenFlow Protocol Control Plane Data Plane Data Plane OpenFlow Controller Control Plane Control Plane Data Plane Protocols and algorithms to calculate network paths – interoperable Forwarding frames/packets based on paths calculated by control plane – hw dependent
  • 9. OpenFlow: The Solution (2) 9 Secure Channel Abstracted Flow Table OpenFlow Controller OpenFlow Protocol Data Plane Control Plane The solution? A compromise: • that allowed forwarding behaviour to be influenced without opening up network software – The control process would run on a controller – Decisions would be pushed down to the data plane running on the network element
  • 10. 10 Secure Channel Abstracted Flow Table OpenFlow Controller OpenFlow Protocol Control Plane * Ingress Port, Ethernet SA, Ethernet DA,VLAN ID,VLAN PCP, IP SA, IP DA, IP Proto, IPToS, Source L4 Port, Dest L4 Port etc…. Adds, deletes and modifies flow table entries Header Fields* Actions Counters Flow 1 Forward to port 1/1 Flow 2 Drop Flow n Send to controller Switch forwards traffic: by matching against header fields and executing corresponding actions OpenFlow: How it works (1)
  • 11. OpenFlow: How it works (2) 11 Secure Channel Abstracted Flow Table OpenFlow Controller OpenFlow Protocol Control Plane Secure Channel Abstracted Flow Table Secure Channel Abstracted Flow Table . . . Switch 1 Switch 2 Switch n OpenFlow Protocol One controller manages many switches
  • 12. OpenFlow: Today • Initially synonymous with SDN • Today, just one of the many protocols within the greater SDN framework • However, responsible for the most radical shift in networking – spark that lit the fuse J 12
  • 13. OpenFlow: Implications • Two primary implications: 13 The control plane is physically decoupled from the data plane The control plane is consolidated and centralised: a single control plane controls multiple data planes (previously a 1:1 correspondence).
  • 14. Aside: Data/control plane separation challenges 14 Scalability The control element now needs to be scaled to support a very large number of forwarding elements Reliability The controller can NOT be a single point of failure Consistency When multiple controllers are used (redundancy), consistency has to be assured across multiple replicas
  • 15. The birth of SDN 15 The separation of control and data plane was not an objective in itself but a compromise approach taken by OpenFlow Ushered a new era of programmability that has been vastly enhanced with new architectures and capabilities The term‘SDN’ itself - an article about the OpenFlow project at Stanford (http://www2.technologyreview.com/news/412194/tr10-software-defined-networking/)
  • 16. SDN - Emergence & Evolution 16 • OpenFlow was a starting point… – era of programmability • But a complete decoupling of the control and data plane? – impractical – Difficult to solve all the problems the industry had spent decades solving and refining: resiliency, scalability, convergence, redundancy.. • SDN architecture today – Hybrid: some control elements still remain distributed while others are centralised – Many different architectural models (from OF concept) • All aspire to achieve the goals of agility and network programmability
  • 17. Hybrid model of SDN 17 Proportion of centralisation of control plane Data Plane Today’s model Control plane is fully distributed (collocated with the data plane) 0% 100% OpenFlow model Control plane is completely de-coupled from the data plane Hybrid model Certain control functions are centralised while others continue to be distributed with the data plane
  • 18. Defining SDN 18 ONF: The physical separation of the control plane from the forwarding plane, and where a control plane controls several devices. Too narrow… Automation through enhanced programmability and open interfaces Dis-aggregation and abstraction Centralisation of control functions with real-time network visibility SDN is … A new approach to networking that provides greater agility and flexibility by:
  • 20. 20 Application Plane Application Service Network Services Abstraction Layer Control Plane Service App Control Abstraction Layer (CAL) Management Plane App Mgmt.Abstraction Layer (MAL) Service Interface Device & Resource Abstraction Layer (DAL) Forwarding Plane App Operational Plane Network Device CP Southbound Interface MP Southbound Interface RFC 7426 Architectural Framework (2)
  • 21. 21 Application Plane Application Service Topology Discovery & Management Network Devices – IP/MPLS/Transport Southbound Interfaces REST/RESTCONF/NETCONF/XMPP Control Plane (controller) Traffic Engineering Route selection & failover Resource Management BGP-LS PCE-Pi2RS SNMP MIBs OpenFlow YANG Configuration Open Flow SNMP NETCONF Data Plane (w ith som e distributed control plane elem ents) BGP PCCRIBs/FIBs Segm ent Routing RSVP-TE East/West- bound interfaces IPFIX Northbound Interfaces Note: designations of north-bound and south-bound are relative to the control plane (“controller”) Device & Resource Abstraction Layer (DAL) Network Services Abstraction Layer Architectural Framework (3) ForCES
  • 22. Evolution NOT Revolution • Despite the hype, SDN is an evolution of current network technologies • No one protocol that defines SDN – it is a new architectural framework for data networks • Protocols/technologies that enable: – centralising control plane – abstracting networks and topologies – enhancing programmability via standard interfaces are considered a part of the SDN framework of technologies 22
  • 23. Open source projects 23 • NOX/POX • Beacon • OpenDayLight (ODL) • Open Network Operating System (ONOS) • Ryu • OpenContrail • Floodlight • ……………
  • 25. EOLO’s BLU Project • Their own router - BLUrouter – TileGX architecture (72 core CPU) – Low power • Their own Router OS – BLUos – based on 6WINDGate – Customisation: RFC3107 (label distribution) in Quagga (BGP) • Their own controller – BLU-GW – limit human error – Parallel execution of commands, schedulers, config-rollback
  • 26. BLU Project – Stage 1 • OpenFlow rules for MPLS label switching • RFC3107 for traffic labelling (downstream) • Problems: – OpenFlow granularity issues • Change of single flow required all BLUs along the path to be reprogrammed • Upgrades are atomic - high risk of inconsistent nw states – no fallback!
  • 27. BLU Project – Stage 2 • Segment Routing + RFC3107 for traffic labelling – MPLS dataplane for now… – IGP as fallback (distributed control function) Contact them: blu@eolo.it