Showing posts with label OpenStack. Show all posts
Showing posts with label OpenStack. Show all posts
OVS and OVN
Let's understand first OVS and OVN
Limitation of OpenStack networking
- L2 population,
- local ARP responder,
- L2 Gateway and
- DVR
https://networkop.co.uk/blog/2016/10/13/os-dvr/
https://networkop.co.uk/blog/2016/05/21/neutron-l2gw/
https://networkop.co.uk/blog/2016/05/06/neutron-l2pop/
- L2 population,
- local ARP responder,
- L2 Gateway and
- DVR
https://networkop.co.uk/blog/2016/10/13/os-dvr/
https://networkop.co.uk/blog/2016/05/21/neutron-l2gw/
https://networkop.co.uk/blog/2016/05/06/neutron-l2pop/
OVN is
- a distributed SDN controller
- implementing virtual networks
- with the help OVS.
- a distributed SDN controller
- implementing virtual networks
- with the help OVS.
OVN provides
- L2/L3 Virtual networking
- firewall service
- L2/L3 Virtual networking
- firewall service
Architecture Same as VMWare's NSX
* dedicated Linux bridge between the VM and the OVS integration bridge for implementation of security group
* dedicated NS for DHCP agent
* dedicated NS for routing
* NAT = network namespaces + iptables + proxy-ARP.
OVN implements inside a single OVS bridge:
- security groups,
- distributed virtual routing,
- NAT and
- distributed DHCP server
- security groups,
- distributed virtual routing,
- NAT and
- distributed DHCP server
Flow/path
Neutron data model ->
OVN ML2 plugin ->
OVN Northbond DB (DB Node) : QoS, NAT and ACL settings ->
OVN northd (DB Node) ->
OVN southbond DB (DB Node): L2 Datapath and L3 Datapath ->
OVN Controller (Worker Node): Distributed SDN Contoller ->
local OVS over openflow. (Worker Node)
Network: a virtual L2 broadcast domain
Subnet: attached to the network.
Router: provides connectivity between all directly connected subnets
Port: VM’s point of attachment to the subnet
OVN ML2 plugin ->
OVN Northbond DB (DB Node) : QoS, NAT and ACL settings ->
OVN northd (DB Node) ->
OVN southbond DB (DB Node): L2 Datapath and L3 Datapath ->
OVN Controller (Worker Node): Distributed SDN Contoller ->
local OVS over openflow. (Worker Node)
Network: a virtual L2 broadcast domain
Subnet: attached to the network.
Router: provides connectivity between all directly connected subnets
Port: VM’s point of attachment to the subnet
OpenStack Services and OpenStack Distributions
Compute
* NOVA Compute Service
- Main part of IaaS
ZUN Containers Service
QINLING Functions Service
Bare Metal
IRONIC Bare Metal Provisioning Service
- Preboot eXecution Environment PXE
- Intelligent Platform Management Interface IPMI
- can extend with vendor specific plugin
CYBORG Accelerators resource management
Storage
SWIFT Object store
-scalable redundant storage system
* CINDER Block Storage
MANILA Shared filesystems
Networking
NEUTRON Networking
- old name Quantum
OCTAVIA Load balancer
DESIGNATE DNS service
- old name Moniker
Shared Services
* KEYSTONE Identity service
- common authentication system
- Can integrate with LDAP
* GLANCE Image service
- It can use SWIFT
- Heat and Nova interface with Glance
BARBICAN Key management
KARBOR Application Data Protection as a Service
SEARCHLIGHT Indexing and Search
- Integrated with Horizon and CLI
Orchestration
* HEAT Orchestration
- OpenStack-native REST API
- CloudFormation-compatible Query API
SENLIN Clustering service
MISTRAL Workflow service
ZAQAR Messaging Service
- Messages between various components of SaaS and mobile Apps.
- old name Marconi
BLAZAR Resource reservation service
AODH Alarming Service
- rule based
- defined rules against metric
- defined rules against event data
Workload Provisioning
MAGNUM Container Orchestration Engine Provisioning
- K8s
- Apache Mesos
- Docker Swarm
SAHARA Big Data Processing Framework Provisioning
- Elastic MapReduce
- To provision Hadoop cluster
- old name Savanna
TROVE Database as a Service
- Rational DB
- Non-rational DB
- old name RedDwarf
Application Lifecycle
MASAKARI Instances High Availability Service
MURANO Application Catalog
SOLUM Software Development Lifecycle Automation
FREEZER Backup, Restore, and Disaster Recovery
API Proxies
EC2API EC2 API proxy
Web Frontend
* HORIZON Dashboard
- native OpenStack API
- EC2 compatibility API.
Telemetry
Ceilometer
- Single Point of Contact for billing system
Gnocchi
RCA
Vitrage
- for organizing, analyzing and expanding OpenStack alarms & events, yielding insights regarding the root cause of problems and deducing their existence before they are directly detected
Services marked with * are main services
Distributions
* NOVA Compute Service
- Main part of IaaS
ZUN Containers Service
QINLING Functions Service
Bare Metal
IRONIC Bare Metal Provisioning Service
- Preboot eXecution Environment PXE
- Intelligent Platform Management Interface IPMI
- can extend with vendor specific plugin
CYBORG Accelerators resource management
Storage
SWIFT Object store
-scalable redundant storage system
* CINDER Block Storage
MANILA Shared filesystems
Networking
NEUTRON Networking
- old name Quantum
OCTAVIA Load balancer
DESIGNATE DNS service
- old name Moniker
Shared Services
* KEYSTONE Identity service
- common authentication system
- Can integrate with LDAP
* GLANCE Image service
- It can use SWIFT
- Heat and Nova interface with Glance
BARBICAN Key management
KARBOR Application Data Protection as a Service
SEARCHLIGHT Indexing and Search
- Integrated with Horizon and CLI
Orchestration
* HEAT Orchestration
- OpenStack-native REST API
- CloudFormation-compatible Query API
SENLIN Clustering service
MISTRAL Workflow service
ZAQAR Messaging Service
- Messages between various components of SaaS and mobile Apps.
- old name Marconi
BLAZAR Resource reservation service
AODH Alarming Service
- rule based
- defined rules against metric
- defined rules against event data
- metric and event data collected by Ceilometer or Gnocchi
MAGNUM Container Orchestration Engine Provisioning
- K8s
- Apache Mesos
- Docker Swarm
SAHARA Big Data Processing Framework Provisioning
- Elastic MapReduce
- To provision Hadoop cluster
- old name Savanna
TROVE Database as a Service
- Rational DB
- Non-rational DB
- old name RedDwarf
Application Lifecycle
MASAKARI Instances High Availability Service
MURANO Application Catalog
SOLUM Software Development Lifecycle Automation
FREEZER Backup, Restore, and Disaster Recovery
API Proxies
EC2API EC2 API proxy
Web Frontend
* HORIZON Dashboard
- native OpenStack API
- EC2 compatibility API.
Telemetry
Ceilometer
- Single Point of Contact for billing system
Gnocchi
RCA
Vitrage
- for organizing, analyzing and expanding OpenStack alarms & events, yielding insights regarding the root cause of problems and deducing their existence before they are directly detected
Services marked with * are main services
Distributions
- Bright Computing
- Canonical (Ubuntu)
- HPE (which was spin-merged to Micro Focus/Suse)
- IBM
- Mirantis
- Oracle OpenStack for Oracle Linux, or O3L
- Oracle OpenStack for Oracle Solaris
- Red Hat
- Sardina Systems
- Stratoscale
- SUSE
- VMware Integrated OpenStack (VIO)
Service Function Chaining
Network monitoring/measurement
Cloud native technologies include
that allow deployment in public, private and hybrid cloud environments through loosely coupled and automated systems
Various planes
Middleboxes are also interchangeably called
Example SFs includes
ETSI NFV uses the term "network function forwarding graph" (NF-FG)
IETF uses the term "service function chaining" (SFC)
Fundamentally SFC is the ability to cause network packet flows to route through a network via a path other than the one that would be chosen by routing table lookups on the packet’s destination IP address.
VNF Forwarding Graph (VNFFG)
The combination of
is described as the VNF Forwarding Graph (VNFFG).
It is described as YAML file as per TOSCA VNF Forwarding Graph Descriptor (VNFFGD). VNFFGD = Forwarding Path + VNFGG
NSD = VNFFGD + VNFD
Each node is really a logical port, which is defined in the path as a Connection Point (CP) belonging to a specific VNFD.
Tacker = OpenStack service addressing uses cases of
using standards based architecture
NFVO Renders VNF Forwarding Graphs using SDN Controller or a SFC API
Tacker allows for managing VNFs
Example CLI calls:
To create VNFFG
openstack vnf descriptor create --vnfd-file tosca-vnffg-vnfd1.yaml VNFD1
openstack vnf create --vnfd-name VNFD1 VNF1
openstack vnf descriptor create --vnfd-file tosca-vnffg-vnfd2.yaml VNFD2
openstack vnf create --vnfd-name VNFD2 VNF2
To create VNFFG SFC (where testVNF1, and testVNF2 are VNF instances):
tacker vnffg-create –name mychain –chain testVNF2,testVNF1 –symmetrical True
To create VNFFG SFC by abstract VNF types (ex. “firewall”, “nat”):
tacker vnffg-create –name mychain –chain firewall,nat –abstract-types
To create SFC Classifier for a VNFFG:
tacker vnffg-classifier-create –name myclass –chain mychain –match tcp_dest=80,ip_proto=6
vnffg, vnffg_classifier are schema. Can be represented as dictionary.
For classifier, one can use tenant_id attribute to implement
- sFlow RFC 3176
- Cisco's NetFlow
- IPFIX Protocol RFC 7011
Cloud native technologies include
- containers,
- service meshes,
- microservices,
- immutable infrastructure and
- declarative APIs
that allow deployment in public, private and hybrid cloud environments through loosely coupled and automated systems
Various planes
- infrastructure plane,
- virtual infrastructure plane,
- service plane,
- user plane,
SFC Path identification
* NSH Network Service Header
* VLAN SFC
* Ethernet MAC chaining
* SFC using MPLS - SPRING
NSH is new tunneling protocol. RFC 8300
Then service function forwarders (SFFs) will create the service function paths (SFPs) in the form of an overlay by forwarding packets based on their NSH header.
The NSH header is composed of
physical probe or virtual probe functionality deployed as
The term probe to designate any network node capable of reading and writing to a NSH header
Then service function forwarders (SFFs) will create the service function paths (SFPs) in the form of an overlay by forwarding packets based on their NSH header.
The NSH header is composed of
- service path identification,
- transport independent per-packet service metadata and
- optional variable type-length-value (TLV) metadata.
physical probe or virtual probe functionality deployed as
- switches,
- classifiers,
- SFs, or
- SFFs.
The term probe to designate any network node capable of reading and writing to a NSH header
Middleboxes are also interchangeably called
- services,
- inline services,
- appliances,
- network functions (NFs),
- virtual NFs
- (vNFs), or
- service functions (SFs)
Example SFs includes
- firewalls,
- content filters,
- virus scanners (VS),
- intrusion detection systems (IDS),
- deep packet inspection (DPI),
- network address translation (NAT),
- content caches,
- load-balancers,
- wide area network (WAN) accelerators,
- multimedia transcoders,
- multiservice proxies,
- application acceleration,
- Lawful Intercept (LI),
- HTTP header enrichment functions
- TCP Optimizer
- logging/metering/charging/advanced charging applications,
- or any other function that requires processing of packets
ETSI NFV uses the term "network function forwarding graph" (NF-FG)
IETF uses the term "service function chaining" (SFC)
Fundamentally SFC is the ability to cause network packet flows to route through a network via a path other than the one that would be chosen by routing table lookups on the packet’s destination IP address.
VNF Forwarding Graph (VNFFG)
The combination of
- VNFs,
- SFC, and
- the classification of traffic to flow through them
is described as the VNF Forwarding Graph (VNFFG).
It is described as YAML file as per TOSCA VNF Forwarding Graph Descriptor (VNFFGD). VNFFGD = Forwarding Path + VNFGG
NSD = VNFFGD + VNFD
Each node is really a logical port, which is defined in the path as a Connection Point (CP) belonging to a specific VNFD.
Tacker = OpenStack service addressing uses cases of
- NFV Orchestration and
- VNF Infrastructure Manager VIM ( Nova, Neutron, Cinder)
using standards based architecture
NFVO Renders VNF Forwarding Graphs using SDN Controller or a SFC API
Tacker allows for managing VNFs
Example CLI calls:
To create VNFFG
openstack vnf descriptor create --vnfd-file tosca-vnffg-vnfd1.yaml VNFD1
openstack vnf create --vnfd-name VNFD1 VNF1
openstack vnf descriptor create --vnfd-file tosca-vnffg-vnfd2.yaml VNFD2
openstack vnf create --vnfd-name VNFD2 VNF2
To create VNFFG SFC (where testVNF1, and testVNF2 are VNF instances):
tacker vnffg-create –name mychain –chain testVNF2,testVNF1 –symmetrical True
To create VNFFG SFC by abstract VNF types (ex. “firewall”, “nat”):
tacker vnffg-create –name mychain –chain firewall,nat –abstract-types
To create SFC Classifier for a VNFFG:
tacker vnffg-classifier-create –name myclass –chain mychain –match tcp_dest=80,ip_proto=6
vnffg, vnffg_classifier are schema. Can be represented as dictionary.
For classifier, one can use tenant_id attribute to implement
Reference
- Service function chaining (sfc) architecture RFC 7665,
- Network service header http://www.ietf.org/internet-drafts/draft-ietf-sfc-nsh-01.txt
