And if you are interested more how it is built you can take a look here:
https://github.com/mininet/mininet/wiki/Introduction-to-Mininet
http://mininet.org/overview/
Tuesday, December 31, 2013
OpenvSwitch SDN simulator with mininet
Mininet is a network simulator for openvswitch and openflow. It allows you to build network typologies that emulate hosts, switches and routers. It is very easy to set up by following the instalation guide. All what you have to do is to download the VM file, import the downloaded image and create your minint VM. After that you can follow this other guide and start playing with it.
And if you are interested more how it is built you can take a look here:
https://github.com/mininet/mininet/wiki/Introduction-to-Mininet
http://mininet.org/overview/
And if you are interested more how it is built you can take a look here:
https://github.com/mininet/mininet/wiki/Introduction-to-Mininet
http://mininet.org/overview/
The successful architecture for a top-of-rack switch for data center
TOR switch architecture
We wrote before about Arista switches and about the Arista EOS architecture (network OS). A company with a name Pica8 is another example that follows a very similar technological model. They use the best out of the Linux and butter this up with some more hardware (ASIC) dependent software to achieve maximal performance.
What is interesting for Pica8 is that they take a very liberal approach to the hardware itself. They say they could use any plain switching chip or motherboard blades and turn it into a fully operational switch. The secret is once again a well design Pica8 network OS they built.
In comparison to Arista CLI (that is very alike the Cisco one) Pica8 uses a rather different syntax: http://pica8.org/blogs/?p=399. At first glance it has some similarities to what you typie on Juniper boxes :).
More info about them and products can be found here:
http://www.networkworld.com/news/2010/102810-pica8-opensource-switching.html?page=1
http://www.pica8.com/open-switching/1-gbe-10gbe-open-switches.php
We wrote before about Arista switches and about the Arista EOS architecture (network OS). A company with a name Pica8 is another example that follows a very similar technological model. They use the best out of the Linux and butter this up with some more hardware (ASIC) dependent software to achieve maximal performance.
What is interesting for Pica8 is that they take a very liberal approach to the hardware itself. They say they could use any plain switching chip or motherboard blades and turn it into a fully operational switch. The secret is once again a well design Pica8 network OS they built.
In comparison to Arista CLI (that is very alike the Cisco one) Pica8 uses a rather different syntax: http://pica8.org/blogs/?p=399. At first glance it has some similarities to what you typie on Juniper boxes :).
More info about them and products can be found here:
http://www.networkworld.com/news/2010/102810-pica8-opensource-switching.html?page=1
http://www.pica8.com/open-switching/1-gbe-10gbe-open-switches.php
Monday, December 30, 2013
How to use GridFS to store big files in MongoDB
Important note: This article is in relation to online MongoDB course. For more information about the course and other posts describing its content please check my main page here: M101P: MongoDB for Developers course.
Mongo supports document that are up to 16MB in size. To store bigger files you need to use the GridFs feature.
The file we are going to insert.
mongo shell
Python
This little program reads the file from the disk and insets it into the gridfs like collection in Mongo
Logging back to shell we can confirm that the file was saved.
References
http://docs.mongodb.org/manual/core/gridfs/
http://docs.mongodb.org/manual/reference/gridfs/
http://docs.mongodb.org/manual/reference/program/mongofiles/
Mongo supports document that are up to 16MB in size. To store bigger files you need to use the GridFs feature.
The file we are going to insert.
server# ls -lah mongodb-linux-x86_64-2.4.8.tgz -rw-r--r-- 1 root root 91M Oct 31 22:25 mongodb-linux-x86_64-2.4.8.tgz server:~/mongo-course/M101P/week2# ls -lah $HOME/my-big-files.img lrwxrwxrwx 1 root root 30 Dec 30 17:55 /root/my-big-files.img -> mongodb-linux-x86_64-2.4.8.tgz
mongo shell
server# mongofiles -d grid-cli-examle put mongodb-linux-x86_64-2.4.8.tgz
connected to: 127.0.0.1
added file: { _id: ObjectId('52c1b104232188a316e51d61'), filename: "mongodb-linux-x86_64-2.4.8.tgz", chunkSize: 262144, uploadDate: new Date(1388425483792), md5: "4954765464dc4d97870ddc5de147e05d", length: 95015187 }
done!
server# mongo grid-cli-examle
MongoDB shell version: 2.4.8
connecting to: grid-cli-examle
> show collections
fs.chunks
fs.files
system.indexes
> db.fs.files.find()
{ "_id" : ObjectId("52c1b104232188a316e51d61"), "filename" : "mongodb-linux-x86_64-2.4.8.tgz", "chunkSize" : 262144, "uploadDate" : ISODate("2013-12-30T17:44:43.792Z"), "md5" : "4954765464dc4d97870ddc5de147e05d", "length" : 95015187 }
> db.fs.chunks.find().count()
363
Python
This little program reads the file from the disk and insets it into the gridfs like collection in Mongo
import pymongo
import gridfs
import sys
import os
connection = pymongo.Connection("mongodb://localhost", safe=True)
db = connection.grid_python_example
c = db.bigfiles
grid = gridfs.GridFS(db, "myfile")
f = open( os.environ['HOME'] + "/my-big-files.img")
_id = grid.put(f)
f.close()
c.insert( {'grid_id':_id, "filename":"my-big-files.img"} )
Logging back to shell we can confirm that the file was saved.
server# mongo grid_python_example
MongoDB shell version: 2.4.8
connecting to: grid_python_example
> show collections
bigfiles
myfile.chunks
myfile.files
system.indexes
> db.bigfiles.find()
{ "_id" : ObjectId("52c1b9d55f4cb27cabe6e650"), "filename" : "my-big-files.img", "grid_id" : ObjectId("52c1b97e5f4cb27cabe6e4e4") }
> db.myfile.chunks.find().count()
363
References
http://docs.mongodb.org/manual/core/gridfs/
http://docs.mongodb.org/manual/reference/gridfs/
http://docs.mongodb.org/manual/reference/program/mongofiles/
Multi key indexes
Important note: This article is in relation to online MongoDB course. For more information about the course and other posts describing its content please check my main page here: M101P: MongoDB for Developers course.
Indexes
Insert some test data into db.
That way you create an index on the array attribute.
The usage of the index should be transparent when using the find method but you can always she the execution plan.
Indexes
Insert some test data into db.
> db.students.insert( { name : "rado" , teachers: [0,1]} )
> db.students.insert( { name : "adam" , teachers: [0,1,3]} )
> db.students.find()
{ "_id" : ObjectId("52c186421fdaf7a8e42b43b8"), "name" : "rado", "teachers" : [ 0, 1 ] }
{ "_id" : ObjectId("52c186531fdaf7a8e42b43b9"), "name" : "adam", "teachers" : [ 0, 1, 3 ] }
That way you create an index on the array attribute.
> db.students.ensureIndex( { teachers:1 } )
> db.system.indexes.find()
{ "v" : 1, "key" : { "teachers" : 1 }, "ns" : "school.students", "name" : "teachers_1" }
The usage of the index should be transparent when using the find method but you can always she the execution plan.
> db.students.find()
{ "_id" : ObjectId("52c186421fdaf7a8e42b43b8"), "name" : "rado", "teachers" : [ 0, 1 ] }
{ "_id" : ObjectId("52c186531fdaf7a8e42b43b9"), "name" : "adam", "teachers" : [ 0, 1, 3 ] }
{ "_id" : ObjectId("52c187621fdaf7a8e42b43bb"), "name" : "jon", "teachers" : [ 2, 3 ] }
>
> db.students.find( { teachers : { $all : [0,1]} } )
{ "_id" : ObjectId("52c186421fdaf7a8e42b43b8"), "name" : "rado", "teachers" : [ 0, 1 ] }
{ "_id" : ObjectId("52c186531fdaf7a8e42b43b9"), "name" : "adam", "teachers" : [ 0, 1, 3 ] }
> db.students.find( { teachers : { $all : [0,1]} } ).explain()
{
"cursor" : "BtreeCursor teachers_1", ------ this proves that we use the index
"isMultiKey" : true,
"n" : 2,
"nscannedObjects" : 2,
"nscanned" : 2,
"nscannedObjectsAllPlans" : 2,
"nscannedAllPlans" : 2,
"scanAndOrder" : false,
"indexOnly" : false,
"nYields" : 0,
"nChunkSkips" : 0,
"millis" : 11,
"indexBounds" : {
"teachers" : [
[
0,
0
]
]
},
"server" : "mongo2:27017"
}
Physical network diagram generated from dot config language
Is there a good and easy solution to automatically generate logical or physical network diagrams? Trying answer this question I've been playing today with the dot configuration language to test it in the field.
Automatically generated diagram
The DOT config file
Results discussion
It took me a good couple of hours to write this config. Even after that I still have only a very basic understanding of how flexible the dot language is. The coding was very laborious. It required a lot of trying and testing if the new generated graph is what you are looking for.
Often the options I was trying didn't have any effect.
The documentation I found and read wasn't explaining all the details so trying and intuition was often your only friend.
References
http://sandbox.kidstrythisathome.com/erdos/
http://graphviz-dev.appspot.com/
http://www.graphviz.org/
http://rtomaszewski.blogspot.co.uk/search/label/diagram
Automatically generated diagram
The DOT config file
graph physical_net_topology {
legend [ label="{ legend | {red | public} |{blue| v1002 inside} | {green | v105 dmz} }", shape=record];
subgraph cluster_sp {
label="pub switch";
graph [ fillcolor="burlywood", style="filled"]
node [shape=record,fillcolor="white", style="filled"]
edge[style=invis];
node [label="3"] p3 ;
node [label="2"] p2 ;
node [label="1"] p1 ;
{ rank=same; p1; p2; p3}
p1 -- p2 -- p3;
}
subgraph cluster_si {
label="Internal switch";
edge[style=invis];
node [shape=record ];
node [label="1"] e1 ;
node [label="2"] e2 ;
node [label="3"] e3 ;
node [label="4"] e4 ;
node [label="5"] e5 ;
node [label="6"] e6 ;
{ rank=same; e1; e2; e3; e4; e5; e6;}
e1 -- e2 -- e3 -- e4 -- e5 -- e6;
}
subgraph cluster_fw1 {
label="FW1 ports";
graph = [ style = rounded]
edge[style=invis]
node [shape=record ];
node [label="1"] f1 ;
node [label="2"] f2 ;
node [label="3"] f3 ;
node [label="4"] f4 ;
{ rank=same; f1; f2; f3; f4; }
f1 -- f2 -- f3 -- f4'
}
p2 -- f1 [color="red"]
f2 -- e1 [color="blue"]
f3 -- e2 [color="green"]
e3 -- server1 [color="green"]
e4 -- server2 [color="green"]
e6 -- server3 [color="blue"]
}
Results discussion
It took me a good couple of hours to write this config. Even after that I still have only a very basic understanding of how flexible the dot language is. The coding was very laborious. It required a lot of trying and testing if the new generated graph is what you are looking for.
Often the options I was trying didn't have any effect.
The documentation I found and read wasn't explaining all the details so trying and intuition was often your only friend.
References
http://sandbox.kidstrythisathome.com/erdos/
http://graphviz-dev.appspot.com/
http://www.graphviz.org/
http://rtomaszewski.blogspot.co.uk/search/label/diagram
Sunday, December 29, 2013
Cisco ASA connection table state description and examples
On ASA in the connection table you can find protocol sessions (TCP, UDP, ICMP and others) that describe the state of the session (like TCP/IP) when the command was run.
In the session you can find all currently managed sessions by the ASA. From this output you can understand as well as from what IPs your clients are coming from and to what services they connect.
Session statutes
Example flags meaning from the session entities
Example flow you can find in the ASA firewall connection table
Usually a lot entries with these state.
Common but less frequent state
You can specify additional parameters to filter output for specific connection entries state.
In the session you can find all currently managed sessions by the ASA. From this output you can understand as well as from what IPs your clients are coming from and to what services they connect.
Session statutes
fw-asa# sh conn
Flags: A - awaiting inside ACK to SYN, a - awaiting outside ACK to SYN,
B - initial SYN from outside, C - CTIQBE media, D - DNS, d - dump,
E - outside back connection, F - outside FIN, f - inside FIN,
G - group, g - MGCP, H - H.323, h - H.225.0, I - inbound data,
i - incomplete, J - GTP, j - GTP data, K - GTP t3-response
k - Skinny media, M - SMTP data, m - SIP media, n - GUP
O - outbound data, P - inside back connection, p - Phone-proxy TFTP connection,
q - SQL*Net data, R - outside acknowledged FIN,
R - UDP SUNRPC, r - inside acknowledged FIN, S - awaiting inside SYN,
s - awaiting outside SYN, T - SIP, t - SIP transient, U - up,
V - VPN orphan, W - WAAS,
X - inspected by service module
Example flags meaning from the session entities
UB U - up, B - initial SYN from outside, UO U - up, O - outbound data, UIB U - up, I - inbound data, B - initial SYN from outside, UIOB U - up, I - inbound data, O - outbound data, B - initial SYN from outside, UfIB U - up, f - inside FIN, I - inbound data, B - initial SYN from outside, UfrO U - up, f - inside FIN, r - inside acknowledged FIN, O - outbound data, UfIOB U - up, f - inside FIN, I - inbound data, O - outbound data, B - initial SYN from outside, UfFIOB the same like UfIOB F - outside FIN, UfFRIOB the same like UfFIOB R - UDP SUNRPC, UfrIOB U - up, f - inside FIN, r - inside acknowledged FIN I - inbound data, O - outbound data, B - initial SYN from outside, SaAB S - awaiting inside SYN, a - awaiting outside ACK to SYN, A - awaiting inside ACK to SYN, B - initial SYN from outside, aB a - awaiting outside ACK to SYN, B - initial SYN from outside,
Example flow you can find in the ASA firewall connection table
Usually a lot entries with these state.
fw-asa# sh conn detail long flags UfIOB TCP outside:1.165.177.125/1965 (1.165.177.125/1965) inside:192.168.55.172/4567 (1.2.157.172/4567), flags UfIOB, idle 52m38s, uptime 54m21s, timeout 1h0m, bytes 3063 flags UfIOB TCP outside:1.172.130.64/1485 (1.172.130.64/1485) inside:192.168.55.172/4567 (1.2.157.172/4567), flags UfIOB, idle 41m38s, uptime 43m12s, timeout 1h0m, bytes 3063 flags UB TCP outside:1.189.22.195/16208 (1.189.22.195/16208) inside:192.168.55.172/4567 (1.2.157.172/4567), flags UB, idle 45m6s, uptime 48m17s, timeout 1h0m, bytes 0 flags UB TCP outside:1.56.45.22/24654 (1.56.45.22/24654) inside:192.168.55.172/4567 (1.2.157.172/4567), flags UB, idle 45m54s, uptime 49m4s, timeout 1h0m, bytes 0
Common but less frequent state
flags UfFIOB TCP outside:1.55.216.14/14104 (1.55.216.14/14104) inside:192.168.55.172/4567 (1.2.157.172/4567), flags UfFIOB, idle 41m51s, uptime 43m24s, timeout 1h0m, bytes 3002 flags UfFIOB TCP outside:110.81.84.50/20230 (110.81.84.50/20230) inside:192.168.55.172/4567 (1.2.157.172/4567), flags UfFIOB, idle 52m55s, uptime 54m28s, timeout 1h0m, bytes 3063 flags UfFRIOB TCP outside:109.109.38.148/4760 (109.109.38.148/4760) inside:192.168.55.172/4567 (1.2.157.172/4567), flags UfFRIOB, idle 3s, uptime 15s, timeout 5m0s, bytes 2261 flags UfFRIOB TCP outside:112.12.221.155/3753 (112.12.221.155/3753) inside:192.168.55.172/4567 (1.2.157.172/4567), flags UfFRIOB, idle 0s, uptime 0s, timeout 5m0s, bytes 1008 flags UfIB TCP outside:121.35.47.128/1481 (121.35.47.128/1481) inside:192.168.55.172/4567 (1.2.157.172/4567), flags UfIB, idle 23m54s, uptime 26m28s, timeout 1h0m, bytes 1106 flags UfIB TCP outside:183.11.2.56/4589 (183.11.2.56/4589) inside:192.168.55.172/4567 (1.2.157.172/4567), flags UfIB, idle 47m15s, uptime 49m48s, timeout 1h0m, bytes 1106 flags SaAB TCP outside:112.72.135.224/7494 (112.72.135.224/7494) inside:192.168.55.172/4567 (1.2.157.172/4567), flags SaAB, idle 0s, uptime 0s, timeout 1m0s, bytes 0 flags SaAB TCP outside:113.170.107.218/4472 (113.170.107.218/4472) inside:192.168.55.172/4567 (1.2.157.172/4567), flags SaAB, idle 0s, uptime 0s, timeout 1m0s, bytes 0 flags UfrO TCP outside:202.168.215.226/80 (202.168.215.226/80) inside:192.168.55.172/3845 (1.2.157.172/3845), flags UfrO, idle 6s, uptime 8s, timeout 10m0s, bytes 1182 flags UIOB TCP outside:61.187.244.179/9571 (61.187.244.179/9571) inside:192.168.55.172/4567 (1.2.157.172/4567), flags UIOB, idle 38m13s, uptime 39m46s, timeout 1h0m, bytes 2897 flags UIOB TCP outside:67.47.251.34/14921 (67.47.251.34/14921) inside:192.168.55.172/4567 (1.2.157.172/4567), flags UIOB, idle 48m14s, uptime 49m50s, timeout 1h0m, bytes 3348 TCP outside:1.2.27.69/49856 (1.2.27.69/49856) FW-INSIDE:192.168.100.112/80 (11.22.192.112/80), flags UIB, idle 0s, uptime 0s, timeout 1h0m, bytes 581 flags UO TCP outside:202.168.215.226/80 (202.168.215.226/80) inside:192.168.55.172/3848 (1.2.157.172/3848), flags UO, idle 7s, uptime 7s, timeout 1h0m, bytes 1182 TCP outside:220.135.240.219/61139 (220.135.240.219/61139) inside:192.168.55.172/4567 (1.2.157.172/4567), flags aB, idle 0s, uptime 0s, timeout 1m0s, bytes 0 TCP outside:220.135.240.219/61138 (220.135.240.219/61138) inside:192.168.55.172/4567 (1.2.157.172/4567), flags aB, idle 0s, uptime 0s, timeout 1m0s, bytes 0 # without the 'long' parameter TCP outside 94.5.94.11:59458 FW-DMZ-LB 192.168.67.79:80, idle 0:04:31, bytes 19424, flags UfrIOB TCP outside 94.5.94.11:59463 FW-DMZ-LB 192.168.67.72:80, idle 0:04:05, bytes 7181, flags UfrIOB
You can specify additional parameters to filter output for specific connection entries state.
fw-asa# sh conn detail long state tcp_embryonic all TCP outside:220.135.240.219/61139 (220.135.240.219/61139) inside:192.168.55.172/4567 (1.2.157.172/4567), flags aB, idle 0s, uptime 0s, timeout 1m0s, bytes 0 TCP outside:220.135.240.219/61138 (220.135.240.219/61138) inside:192.168.55.172/4567 (1.2.157.172/4567), flags aB, idle 0s, uptime 0s, timeout 1m0s, bytes 0 fw-asa# sh conn long state data_out TCP outside:112.65.211.244/6680 (112.65.211.244/6680) inside:192.168.55.172/4567 (1.2.157.172/4567), flags UIOB, idle 0s, uptime 3m48s, timeout 1h0m, bytes 72509 TCP outside:113.247.3.129/3253 (113.247.3.129/3253) inside:192.168.55.172/4567 (1.2.157.172/4567), flags UIOB, idle 1s, uptime 6m12s, timeout 1h0m, bytes 139249 TCP outside:2.176.137.197/1950 (2.176.137.197/1950) inside:192.168.55.172/4567 (1.2.157.172/4567), flags UfIOB, idle 5m37s, uptime 7m14s, timeout 1h0m, bytes 3002 TCP outside:171.118.104.53/64054 (171.118.104.53/64054) inside:192.168.55.172/80 (1.2.157.172/80), flags UIOB, idle 8s, uptime 7m27s, timeout 1h0m, bytes 98878 TCP outside:219.139.32.90/4141 (219.139.32.90/4141) inside:192.168.55.172/80 (1.2.157.172/80), flags UIOB, idle 7s, uptime 7m32s, timeout 1h0m, bytes 94113 fw-asa# sh conn long state data_in TCP outside:112.65.211.244/6680 (112.65.211.244/6680) inside:192.168.55.172/4567 (1.2.157.172/4567), flags UIOB, idle 4s, uptime 3m37s, timeout 1h0m, bytes 44907 TCP outside:113.247.3.129/3253 (113.247.3.129/3253) inside:192.168.55.172/4567 (1.2.157.172/4567), flags UIOB, idle 1s, uptime 6m1s, timeout 1h0m, bytes 137801 fw-asa# sh conn long state finin TCP outside:138.91.170.208/1264 (138.91.170.208/1264) inside:192.168.55.172/80 (1.2.157.172/80), flags UfFRIOB, idle 0s, uptime 0s, timeout 5m0s, bytes 5052 TCP outside:2.176.137.197/1950 (2.176.137.197/1950) inside:192.168.55.172/4567 (1.2.157.172/4567), flags UfIOB, idle 4m45s, uptime 6m21s, timeout 1h0m, bytes 3002 TCP outside:2.176.137.197/1653 (2.176.137.197/1653) inside:192.168.55.172/4567 (1.2.157.172/4567), flags UfIOB, idle 5m6s, uptime 6m43s, timeout 1h0m, bytes 3002 fw-asa# sh conn long state up TCP outside:112.65.211.244/6680 (112.65.211.244/6680) inside:192.168.55.172/4567 (1.2.157.172/4567), flags UIOB, idle 0s, uptime 2m50s, timeout 1h0m, bytes 37914 TCP outside:113.247.3.129/3253 (113.247.3.129/3253) inside:192.168.55.172/4567 (1.2.157.172/4567), flags UIOB, idle 4s, uptime 5m14s, timeout 1h0m, bytes 78789 TCP outside:2.176.137.197/1950 (2.176.137.197/1950) inside:192.168.55.172/4567 (1.2.157.172/4567), flags UfIOB, idle 4m39s, uptime 6m16s, timeout 1h0m, bytes 3002 TCP outside:171.118.104.53/64054 (171.118.104.53/64054) inside:192.168.55.172/80 (1.2.157.172/80), flags UIOB, idle 0s, uptime 6m29s, timeout 1h0m, bytes 89118 TCP outside:219.139.32.90/4141 (219.139.32.90/4141) inside:192.168.55.172/80 (1.2.157.172/80), flags UIOB, idle 9s, uptime 6m35s, timeout 1h0m, bytes 82689 TCP outside:2.176.137.197/1653 (2.176.137.197/1653) inside:192.168.55.172/4567 (1.2.157.172/4567), flags UfIOB, idle 5m1s, uptime 6m38s, timeout 1h0m, bytes 3002 TCP outside:2.176.137.197/1589 (2.176.137.197/1589) inside:192.168.55.172/4567 (1.2.157.172/4567), flags UfIOB, idle 5m13s, uptime 6m49s, timeout 1h0m, bytes 3002
Status and maturity of the Neutron in Openstack Havana release
Randy Bias from Cloudscaling organized a meetup and brought together 4 engineers who work on cloud network and Openstack Neutron:
http://www.meetup.com/openstack/events/152128692/
http://cloudscaling.com/blog/cloud-computing/neutron-in-production-work-in-progress-or-ready-for-prime-time/
http://www.slideshare.net/randybias/sfbay-openstack-meetup-neutron-and-sdn-in-production-20131203
Below are some of my notes I took when watching the video.
Key SDN components
Neutron is an abstraction layer. It separates your physical network from the direct "tenant network"/virtual network topology. It allows you pragmatically (through a reach API and cli) create virtual routers, lb, firewall. That way it allows you to emulate/virtualize physical devices in cloud.
The main idea is to keep the physical layer as simple and minimal as possible but reach enough so you can create more complex configuration on top of it. That way you can think about Neutron in term of configuration management, orchestration or network vitalization management.
Neutron
This question was asked at about 41.50. There were different answers.
There aren't many good troubleshooting tools.
It is difficult to see and track a specific VM to VM traffic.
- Juniper, Rudra Rugee
- Midokura, Ryu Ishimoto
- VMware, Aaron Rosen
- PLUMgrid, Edgar Magana
http://www.meetup.com/openstack/events/152128692/
http://cloudscaling.com/blog/cloud-computing/neutron-in-production-work-in-progress-or-ready-for-prime-time/
http://www.slideshare.net/randybias/sfbay-openstack-meetup-neutron-and-sdn-in-production-20131203
Below are some of my notes I took when watching the video.
- Network programmability (API)
- Network vitalization (responsible for creating overlay network, multi-tenancy, managing flows, gateways, virtual routers ...)
Neutron is an abstraction layer. It separates your physical network from the direct "tenant network"/virtual network topology. It allows you pragmatically (through a reach API and cli) create virtual routers, lb, firewall. That way it allows you to emulate/virtualize physical devices in cloud.
The main idea is to keep the physical layer as simple and minimal as possible but reach enough so you can create more complex configuration on top of it. That way you can think about Neutron in term of configuration management, orchestration or network vitalization management.
Neutron
- It defines a clear public API how to interact with Openstack to create network objects.
- Provide Network as a Service (NaaS) to tenants to enable more advance deployments and configuration options.
- Initially the goal was to remove the Nova Network from Openstack and create its won project to allow more flexibility and expand functionality (Nova network does support only a limited number of topologies: flat, flat DHCP and VLANs).
- Platform for new future network development in Openstack.
- Neutron is promising a scalable and highly available infrastructure for tenants.
- There are some single point of failures (SPOF) in the current vanilla Havana release. This is one of the differences between the open source vanilla Neutron and vendor specific plugins.
- It provides a choice of technology and no vendor lock-in for network in Openstack. One way of looking at it is that the customer have a choice of what technology/vendor he would like to use to build up the network infrastructure. The there benefit is access to an public open API that is independent of the actual backed technology. But it is important to understand that various backed drivers may provide different and more reach functionality than the Openstack one. In this case you can always get access to this through API extension that Neutron exposes as well. In this sense you can gain additional way of interacting and using your new technology and still remain open and interoperable with feature versions.
- It allows for vendor specific extension for more advance networking features that may not be present in current Neutron API.
- It is the platform to integrate all network functionality in cloud. Although its main focus is on the most common cases and what users demand.
- Openstack wants to be the the reference model for the next generation cloud data center and Neutron aims to provide support for the networking part. By providing a common and widely acceptable platform it opens and allows multi network vendors integration.
- Every vendor can have its own differentiate factors. In the current state of networking industry it is impossible to have a single API in Openstack to address every use case needs. It looks like there will be always space for vendor extension in Neutron for these infrastructure providers or customer who demand more specific and unique features that are not present yet.
- Exposes network abstraction to developers, operation and devops teams who don't need to worry about the implemented details.
This question was asked at about 41.50. There were different answers.
- If you want to run the vanilla Neutron configuration it is not recommend to run it in production without good knowledge of how all Openstack components work and interact together.
- You can run Neutron with vendor plugin in production. By choosing a vendor plugin instead of the vanilla open source solution you get additional level of confidence and support.
- Maybe for private cloud depending on feature requirements and scalability but no for public cloud and enterprise network deployments.
- What level of (technical) support is required before and after implementation.
- How much expertise do you have in your company.
- What scalability do we talk about.
- What application do you want to run.
- What features do you require.
There aren't many good troubleshooting tools.
It is difficult to see and track a specific VM to VM traffic.
Subscribe to:
Posts (Atom)
Posts
