Hands down one of the best presentations I've ever seen, easy to follow, just the right pace, focused on topic start-to-end. I wish I had come across your channel earlier..
It's David Mahler's ability to explain difficult concepts in a highly clear and practical manner. A semester or two worth of classes in under 30 minutes. The way the information is presented helps me retain that information. This is priceless. Thank you.
I am going thorough Red hat open stack administrator course where i did not understand concept of NS clear, but after watching your video i can say now i have more clarity , you have provided detailed knowledgeable which cleared all my doubts . you are doing marvelous job , a Big thank you .
Always clear, precise and concrete explanations as usual, David. This video was very useful. I like the incremental approach you take for explaining stuffs in neat organized way. Hats off to your efforts for clarity and precision. Cheers and You ROCK! I have one question. Why is that you connected DHCP namespaces to internal ports of OVS and not through VETH pairs (unlike Red/Green host namespace) ?
Great stuff! Thank you for putting this together. I wish you had added a section about connecting our 2 networks to the internet and not just keep them isolated but this is already great!
@sandeep Thanks for the detailed feedback! Really helps to hear what works. Just to show there is more than one way really. Also IIRC, that is how OpenStack does it (away from my lab atm, have to double check ;-) )
Thanks a lot. It made lot of things clear to me. I have one question. Do we need OVS to create the bridge or can we use the brctl to create the bridge ?
Thank you for your video. could you please help with this question: I encountered with a problem with the simplest lab: I created three cirros instances in openstack and through CLI I created 2 namespaces Red and Green. I chosen ovs's qvo interfaces of two cirros VM and apply them to RED namespace (I found them using Nova interface-list instance_id). I applied IP address 192.168.1.1 and .2 respectively on those VMs, but they cannot ping each other. I see only ARP request without ARP reply. How do you think what's the problem in such behavior? Why two instances being in the same namespace cannot reach each other?
I'm not sure about this - this sounds not simple actually to me. Since OpenStack spins up virtual network config like Linux bridges, the OVS instances assigns local VLANs and puts OVS ports in them, sets up security groups, etc. A lot of moving parts there due to OpenStack - I guess some conflict amongst all that. Maybe something as simple as security groups needs to be updated? Otherwise, I have little idea, sorry. Network namespaces in OpenStack are used with Neutron routers and DHCP usually, not VMs
I'm not sure about this - this sounds not simple actually to me. Since OpenStack spins up virtual network config like Linux bridges, the OVS instances assigns local VLANs and puts OVS ports in them, sets up security groups, etc. A lot of moving parts there due to OpenStack - I guess some conflict amongst all that. Maybe something as simple as security groups needs to be updated? Otherwise, I have little idea, sorry. Network namespaces in OpenStack are used with Neutron routers and DHCP usually, not VMs
I'm not sure about this - this sounds not simple actually to me. Since OpenStack spins up virtual network config like Linux bridges, the OVS instances assigns local VLANs and puts OVS ports in them, sets up security groups, etc. A lot of moving parts there due to OpenStack - I guess some conflict amongst all that. Maybe something as simple as security groups needs to be updated? Otherwise, I have little idea, sorry. Network namespaces in OpenStack are used with Neutron routers and DHCP usually, not VMs
when I type ip netns exec green dhclient eth0-g, there show dhclient is alreading running - exiting. I do this experiment step by step. Is there somebody has any ideas?
+peterphan92 Thanks for the comment! Ya, I know about the audio issues. I didn't really realize until after uploading and having it up for a few weeks. This vid. was I think my first attempt at recording and editing video and audio separately. I believe I fixed the problem now for future videos though. Learning to edit is its own challenge!
For assigning dynamic ip addresses to 2 clients (red and green) you created two DHCP processes in isolated namespaces, my question is why didn't you created two DHCP processes inside each of isolated client? why you created outside the clients?
Great video David. Very impressed with all your content so far, keep up the good work :-) Workaround for tap interface problem on later versions of OVS ---------------------------------------------------------------------------------------------------- Like others I've had issues with the tap interface in a later version of OVS. Simply adding the tap interface manually doesn't seem to connect it to the vswitch when you make it an internal interface, and the tap interface never comes up (NO_CARRIER) after being fully configured and moved into the dhcp-r namespace. I have a workaround, but its a little odd. Either there's a bug somewhere, or my understanding of OVS/tap interfaces is even more limited than I thought... Anyway, this works for some reason: 1) In the root namespace "ip tuntap add mode tap tap-r" (creates a tap interface) 2) ovs-vsctl add-port OVS1 tap-r (adds it to the vswitch) 3) ip link set tap-r netns dhcp-r (move the tap interface to the dhcp-r namespace, but *before changing the interface type / port tag*) Now things get weird... 4) ovs-vsctl set interface tap-r type=internal (sets the tap-r interface to internal *but actually creates a new tap-r interface in the root namespace.* Since there's a "tap-r" already listed OVS doesn't generate an error. However, this tap-r is actually connected and can be brought up later) 5) ovs-vsctl set port tap-r tag=100 6) ip netns exec dhcp-r ip tuntap del mode tap tap-r (delete the original tap interface that we moved to dhcp-r) 7) ip link set tap-r netns dhcp-r (move the new, connected tap-r to the dhcp-r namespace) 8) continue with the rest of the config (ie bringing the interfaces up, dnsmasq config and enabling the red namespace dhclient) The process can be repeated for the tap-g interface and dhcp-g namespace. Not sure what's going on here really, particularly why a new tap interface is created when you set the interface type to internal after moving it to a different namespace... but after a lot of trial and error this is the only way I got the tap interface to come up with OVS version 2.5.2 and Ubuntu 16.04.02.
Thanks for the video, and for the comments from Paul. I am having problems that I think have something to do with Paul comments, not exactly the same. I've tried his solution without success. I always get next error: "cannot find device "tap-r" after sending the command "ip link set tap-r netns dhcp-r" Wich is weird because tap-r device has been correctly created whith next commands: "ovs-vsctl add-port OVS1 tap-r" "ovs-vsctl set interface tap-r type=internal" "ovs-vsctl set port tap-r tap=100" May be the amount of time passed since the video was released, has come to changes in all or several sofware packages involved? I'm working with Ubuntu 14.04, Anyway, thanks for such a good video. I'll keep trying
Hi I got the following error root@mininet-vm:/home/mininet# ovs-vsctl add-port OVS1 tap-r ovs-vsctl: Error detected while setting up 'tap-r'. See ovs-vswitchd log for details. Any ideas?
I reproduced this thanks for pointing it out, something with later releases of OVS since I made this vid. where before it added a port that doesn't yet exist. Haven't gotten to a solution but can play around if I can get myself some free time :-)
How come you could move the tap ports into the network namespace while you had to use a veth pair for the other ports ? Could the eth0-r/g ports be connected to their respective namespaces without a veth pair ? I guess it is a feature of internal ports, but what are the differences ?
My understanding is that they're both virtual devices. But on the one hand, let's say we're using OVS in a standard openstack setup, then the tap device can obviously only be added to a single neutron bridge like br-int. But with a veth pair you can add one end to br-int and the other br-ext, so you interconnect multiple bridges, and the veth pairs are what you'd like to use to do intercommunication between the different network namespaces
on running this command: ovs-vsctl add-port ovs1 tap-r i get the following error: ovs-vsctl: Error detected while setting up 'tap-r'. See ovs-vswitchd log for details. Also somehow its still creating tap-r in the namespace but while running command: ip link set tap-r netns dhcp-g it shows following error: RTNETLINK answers: Invalid argument - i still see tap-r and tap-g in my root namespace WHY???? Please Help!
Beautiful! Thanks! Probably, I am not the first one, who is asking about your output highlighting trick. How do you turn some output in SecureCRT to red and other lines to green? I know, SecureCRT can highlight, but you are doing this on click (like in PowerPoint). How?? :-)
+Abhishek Pandey Ya, it's not up yet, still working on it. It's slow going to get them out - I think in under a month.....well I hope! It's actually pretty long already!
+David Mahler why don't you work for linuxacademy.com/ , they are looking for instructors like you , you can do it part time , they will definitely hire you , because you are a natural instructor.
I still cannot get the difference between tap and veth interfaces in their usefulness. Originally, I thought that OVS could not span several namespaces, so one had to use veth in order to have one side in the namespace and the other side in the root namespace part of the OVS bridge. But that also seems to be a common use case to have a tap interface in a namespace and to make it a port of a root namespace's OVS bridge. The conclusion would then be that OVS bridges can span namespaces. But what would be the real difference between tap and veth ? What are their specific use cases ? Or things you can/cannot do with each of them ?
NoSuchCommand A veth pair is effectively a virtual patch cable and the common use case for them is "patching" virtual bridges such as Linux bridges and OVS instances. A TAP devices is how a VM created by a hypervisor such as KVM implements it's vNIC. You can connect a TAP device to an OVS virtual bridge, however, OVS is not compatible with iptables rules applied directly to a TAP device connected directly to an OVS port. Often it's desirable to apply iptables rules directly to the TAP interface, as OpenStack does, so the usual connectivity method for a VM is TAP -> (traditional) Linux bridge -> veth pair -> OVS. When used as just a pipe between bridges, the veth pair does not need any IP addresses as it's purely a L2 forwarder. This is all explained really well in the OpenStack doco, docs.openstack.org/admin-guide-cloud/content/under_the_hood_openvswitch.html. Perhaps a mockup of this will be the subject of Mr Mahler's next video?
Barry the Cougar Thank you for your answer. Yes I knew all this filtering thing requiring Linux Bridges. But my question was more about this specific example in the video. Moreover, what I did not notice when I wrote my first comment is that, here, the tap~ interfaces are in fact just OVS internal ports that happen to be named tap~. So they are not proper kernel interface of type tap. And that seems to be the same method used by OpenStack Neutron according to the OpenStack Cloud Administrator Guide you mentioned. However, this document is a bit old - in fact, this part of the Cloud Admin Guide is not referenced anymore in the ToC; you can only access it through a search engine, although it is still a good and mostly accurate documentation - and I do not have the setup at hand to check it up on the latest Neutron version. In addition, Neutron's OVS mechanism, be it used standalone or through ML2, does not use veth pair to interconnect namespaces. It only uses them to interconnect the VMs' Linux Bridges to the integration virtual switch, which both are in the same namespace on the compute hosts. I can assume that the reason is you cannot make an OVS internal port also a port of a Linux Bridge. Namespaces in Neutron are only used by the L3 Agent (so only on the Network host if you do not use DVR) and each one of them is only populated by OVS internal ports My point, at first, was : in this video, there is no Linux Bridge. Couldn't we have done all this with ONLY either veth pairs or tap devices or OVS internal ports ?
NoSuchCommand The video probably would have been better served if I named those ports at the end OVSI-R and OVSI-G instead of TAP-R and TAP-G. Linux Kernel "tuntap" interfaces can't cross namespaces AFAIK. Also the mixing of VETH and OVS-INTERNAL ports in the 1 video was just because I smushed together 2 different scenarios into one - a bit artificial but just for lab/demo/exploring of namespaces. At some point I hope to do a OpenStack Neutron video but as you note as well it's a moving target with DVR etc. and I myself have much to research and learn still before I'm ready to do one. I'm also split on focusing on network automation as well at the moment so not sure when each will happen. Thanks for your comments!
@@DavidMahler You first need to assign a new subnet to one of your VLANs. You will surely run into issues trying to route between two VLANs operating within the same subnet. Most routers will not even let you place 2 different interfaces into the same subnet.
When it comes to clarity on tricky networking topics, you occupy an isolated namespace of your own. Nice video once again :)
Colum Gaynor That's awesome, can I put it on a plaque? Thanks!!
Absolutely!!!
Hands down one of the best presentations I've ever seen, easy to follow, just the right pace, focused on topic start-to-end. I wish I had come across your channel earlier..
Thanks!
It's David Mahler's ability to explain difficult concepts in a highly clear and practical manner. A semester or two worth of classes in under 30 minutes. The way the information is presented helps me retain that information. This is priceless. Thank you.
That's great, thanks for the kind detailed words!
You are the true teacher of my networking knowledge. I wasted money on uni classes..
Ha, thanks!
2021. This still is a huge GEM! Super valuable content!!! Thank you for making and sharing this!!!
Stop making me feel older, j/k, thanks for the comment!!!
@@DavidMahler 2024 and still a gem
Helped me getting my virtual network finally running without any mutual interference. Thanks David!
great!
Thank you David. I am preparing the COA exam, you're videos are simply invaluables
Awesome, I'm glad they are helping!
Thank you. This still a good video since 2015 ❤
Thanks! :-)
Still enjoying it in 2021 :)
still enjoying it in 2022))
I am going thorough Red hat open stack administrator course where i did not understand concept of NS clear, but after watching your video i can say now i have more clarity , you have provided detailed knowledgeable which cleared all my doubts . you are doing marvelous job , a Big thank you .
Thanks!
This video deserves a lot of clap. The best one I have came across. Brilliantly explained.
Thank you Brijesh!
man oh man, I can't express how helpful this video for me. Pls continue to do more topics on networking!!!
That is great, thanks for this!
Always clear, precise and concrete explanations as usual, David. This video was very useful. I like the incremental approach you take for explaining stuffs in neat organized way. Hats off to your efforts for clarity and precision. Cheers and You ROCK!
I have one question. Why is that you connected DHCP namespaces to internal ports of OVS and not through VETH pairs (unlike Red/Green host namespace) ?
I too have the same question
Thanks David for explaining the complex topics in very understandable manner. Makes learning new technology easier.
Thanks so much Ankit!
What a nice tutorial, now I understand the Nuage Network much better on those OVS and network namespaces!
Cool, I don't know anything about Nuage, but should.....
It was a pure joy to watch these videos. Very well explained. Thank you!
Wow, that's great to hear, you're welcome Satish!
What can I say - your videos are brain fodder for us networking types. Awesome... just awesome!
+akk2766 Ha! Thanks!
Awesome info David ....simple session but covers in-depth technical .Thank you for sharing your knowledge ... :) .
Thanks!
Awesome tutorial on network namespaces. Would love more networking tutorials like this
Thanks for the comment!
David Mahler is a really great guy
So are you!
This video is so much more than just linux namespaces.
Thanks for continuing to watch and comment Mike
Great stuff! Thank you for putting this together. I wish you had added a section about connecting our 2 networks to the internet and not just keep them isolated but this is already great!
Thanks! I believe I did talk about that in my OpenStack neutron videos
You are REALLY GOOD and you make these concepts so easy to understand. Can't thank you enough.
Thanks for commenting!
David Mahler May I please ask you to make some videos to explain the concepts of Dockers, Containers, Kubernetes, etc. Thanks 😊
David, thanks a lot for your video. The best way to explain something is to show how it works on a real system
Saferoom App You're welcome! That's the best way I learn too - have to be doing something actively or see it in action vs. power point alone.
@sandeep Thanks for the detailed feedback! Really helps to hear what works.
Just to show there is more than one way really. Also IIRC, that is how OpenStack does it (away from my lab atm, have to double check ;-) )
This was really well done. Thanks for producing it.
+Philip Garrett Thanks for the comment! You're welcome!
As always, your videos are good. Keep educating us. Thanks.
***** Thanks!
very clear and concise explanation, good stuff
thanks!
I wish to have seen this video earlier . Thank you so much for easy to understand and detailed description :)
You're very welcome!
Very helpful and simplified, as usual. Thanks, David.
+Raseel Bhagat You're welcome, thanks for commenting and watching !!
Awesome David ... Thank you for sharing your knowledge ... :)
Thanks for the comment, and you are welcome!
Nice video David, watched a couple of your videos, incremental explanation helps building up the concept. Cheers!👍🏻
TY, cheers!
Very nice. Thanks for putting this concise and informative video together. I will definitely be checking out your other videos!
+michaelmcz That's great to hear, thanks for the comments!
Excellent lecture. Exactly the info that I needed. Thank you very much!
You're welcome!!
This is so good... wish I had seen this years ago when starting my network-programming related job 🤣
Thanks!
I can't thank you enough :) You are a gem of a tutor :) Keep Educating us :)
+SACHIN S R You're welcome, and thanks for the comments. I'll try :-)
Checking in in 2020, and gotta say that video is super.
Thanks!
I wish I could thumbs this up twice! Bravo!
Thank you!!
Good video, thanks. Would be even cooler to see how the kernel info changes inside.
Noted!
this is very sharp and clean. thanks for sharing !
+simon lee You're very welcome!
Awesome!!!!. Thanks for making these videos. They are very helpful. Please do keep making these videos/sessions.
Hi, Rajesh - thanks for continuing to support the page!
Thank you David for this video.
Again a very nice video, which gives a good overview how Linux namespaces can be used in practice :-)
Marcus Lachmanez Thanks Marcus for watching and the kind comment!
Nice, so the built in linux namespace has dhcp component which is not part of openswitch?
Simply super. I Love your videos.
+Yugandhar Sarraju Thanks!
David Sir your lecture is too good. ..thanks sir. ..God bless you. ..
pls make more video
Thanks Ujjal! OK ty!
I love your videos. What tool you use to record those videos?
Thanks
Thanks, Camtasia Studio
very good presentation
thx a lot David
Thanks!
An awesome presentation & explanation . Thanks for this video :)
+shakti shwetanshu You're welcome! Thanks for the comments!
short and crisp! Thank you...
Mehul Vora yw!
Thank you so much for the excellent tutorial about netns.
+sai1gon You're welcome!
You helped me sooo much! I absolutely love your videos!
That's great, thanks!
Thanks a lot. It made lot of things clear to me. I have one question. Do we need OVS to create the bridge or can we use the brctl to create the bridge ?
thanks for the crystal clear explanation!
+koen van der rijt You're welcome!!
The presentation is really good....!
Thanks!!
great. I really like the way you presented!
Thank you!
thanks for great video. a lot of interesting information about network namespaces in a short time.
Actually demo is easy to follow in your terminal.
+Марк Лавриненко Great, you're welcome!
Thank you for your video. could you please help with this question: I encountered with a problem with the simplest lab: I created three cirros instances in openstack and through CLI I created 2 namespaces Red and Green. I chosen ovs's qvo interfaces of two cirros VM and apply them to RED namespace (I found them using Nova interface-list instance_id). I applied IP address 192.168.1.1 and .2 respectively on those VMs, but they cannot ping each other. I see only ARP request without ARP reply. How do you think what's the problem in such behavior? Why two instances being in the same namespace cannot reach each other?
I'm not sure about this - this sounds not simple actually to me. Since OpenStack spins up virtual network config like Linux bridges, the OVS instances assigns local VLANs and puts OVS ports in them, sets up security groups, etc. A lot of moving parts there due to OpenStack - I guess some conflict amongst all that. Maybe something as simple as security groups needs to be updated? Otherwise, I have little idea, sorry. Network namespaces in OpenStack are used with Neutron routers and DHCP usually, not VMs
I'm not sure about this - this sounds not simple actually to me. Since OpenStack spins up virtual network config like Linux bridges, the OVS instances assigns local VLANs and puts OVS ports in them, sets up security groups, etc. A lot of moving parts there due to OpenStack - I guess some conflict amongst all that. Maybe something as simple as security groups needs to be updated? Otherwise, I have little idea, sorry. Network namespaces in OpenStack are used with Neutron routers and DHCP usually, not VMs
I'm not sure about this - this sounds not simple actually to me. Since OpenStack spins up virtual network config like Linux bridges, the OVS instances assigns local VLANs and puts OVS ports in them, sets up security groups, etc. A lot of moving parts there due to OpenStack - I guess some conflict amongst all that. Maybe something as simple as security groups needs to be updated? Otherwise, I have little idea, sorry. Network namespaces in OpenStack are used with Neutron routers and DHCP usually, not VMs
very nice presentation!
Thanks!
when I type ip netns exec green dhclient eth0-g, there show dhclient is alreading running - exiting. I do this experiment step by step. Is there somebody has any ideas?
Amazing! thanks! What's up with the audio when you were showing the dhcp ps ids?
+peterphan92 Thanks for the comment! Ya, I know about the audio issues. I didn't really realize until after uploading and having it up for a few weeks. This vid. was I think my first attempt at recording and editing video and audio separately. I believe I fixed the problem now for future videos though. Learning to edit is its own challenge!
Awesome video..Thanks a lot for sharing the knowledge.
+Prasanta Kumar Behera You're welcome!
For assigning dynamic ip addresses to 2 clients (red and green) you created two DHCP processes in isolated namespaces, my question is why didn't you created two DHCP processes inside each of isolated client? why you created outside the clients?
Great video David. Very impressed with all your content so far, keep up the good work :-)
Workaround for tap interface problem on later versions of OVS
----------------------------------------------------------------------------------------------------
Like others I've had issues with the tap interface in a later version of OVS. Simply adding the tap interface manually doesn't seem to connect it to the vswitch when you make it an internal interface, and the tap interface never comes up (NO_CARRIER) after being fully configured and moved into the dhcp-r namespace.
I have a workaround, but its a little odd. Either there's a bug somewhere, or my understanding of OVS/tap interfaces is even more limited than I thought... Anyway, this works for some reason:
1) In the root namespace "ip tuntap add mode tap tap-r" (creates a tap interface)
2) ovs-vsctl add-port OVS1 tap-r (adds it to the vswitch)
3) ip link set tap-r netns dhcp-r (move the tap interface to the dhcp-r namespace, but *before changing the interface type / port tag*)
Now things get weird...
4) ovs-vsctl set interface tap-r type=internal (sets the tap-r interface to internal *but actually creates a new tap-r interface in the root namespace.* Since there's a "tap-r" already listed OVS doesn't generate an error. However, this tap-r is actually connected and can be brought up later)
5) ovs-vsctl set port tap-r tag=100
6) ip netns exec dhcp-r ip tuntap del mode tap tap-r (delete the original tap interface that we moved to dhcp-r)
7) ip link set tap-r netns dhcp-r (move the new, connected tap-r to the dhcp-r namespace)
8) continue with the rest of the config (ie bringing the interfaces up, dnsmasq config and enabling the red namespace dhclient)
The process can be repeated for the tap-g interface and dhcp-g namespace.
Not sure what's going on here really, particularly why a new tap interface is created when you set the interface type to internal after moving it to a different namespace... but after a lot of trial and error this is the only way I got the tap interface to come up with OVS version 2.5.2 and Ubuntu 16.04.02.
Thanks so much Paul for providing a solution on this, I haven't had cycles to dig into the issues yet
Thanks for the video, and for the comments from Paul. I am having problems that I think have something to do with Paul comments, not exactly the same. I've tried his solution without success. I always get next error:
"cannot find device "tap-r" after sending the command "ip link set tap-r netns dhcp-r"
Wich is weird because tap-r device has been correctly created whith next commands:
"ovs-vsctl add-port OVS1 tap-r"
"ovs-vsctl set interface tap-r type=internal"
"ovs-vsctl set port tap-r tap=100"
May be the amount of time passed since the video was released, has come to changes in all or several sofware packages involved?
I'm working with Ubuntu 14.04,
Anyway, thanks for such a good video. I'll keep trying
Hi
I got the following error
root@mininet-vm:/home/mininet# ovs-vsctl add-port OVS1 tap-r
ovs-vsctl: Error detected while setting up 'tap-r'. See ovs-vswitchd log for details.
Any ideas?
I reproduced this thanks for pointing it out, something with later releases of OVS since I made this vid. where before it added a port that doesn't yet exist. Haven't gotten to a solution but can play around if I can get myself some free time :-)
This is excellent tutorial! Thanks!
Thanks!
Really helpful Sir. Thank you very much.
+Kiran Devraaj You're very welcome!
Nice explanation !!! Thanks for the good tutorial
Govardhan Chintha You're welcome! Thanks for the comment.
How come you could move the tap ports into the network namespace while you had to use a veth pair for the other ports ?
Could the eth0-r/g ports be connected to their respective namespaces without a veth pair ?
I guess it is a feature of internal ports, but what are the differences ?
My understanding is that they're both virtual devices. But on the one hand, let's say we're using OVS in a standard openstack setup, then the tap device can obviously only be added to a single neutron bridge like br-int. But with a veth pair you can add one end to br-int and the other br-ext, so you interconnect multiple bridges, and the veth pairs are what you'd like to use to do intercommunication between the different network namespaces
How creation of a new network name space different from running lxc-create command?
wow nicely explained everything !! thanks
You're welcome, thanks for the comment!
Thanks a lot for your great videos.
You're very welcome!
Fantastic!Thank you.
Thank you too!
Awesome, good job. Thanks.
Thanks!
Thanks, That was helpful
You're welcome, glad it helped!
Great explanation!
Thanks!
on running this command:
ovs-vsctl add-port ovs1 tap-r
i get the following error:
ovs-vsctl: Error detected while setting up 'tap-r'. See ovs-vswitchd log for details.
Also somehow its still creating tap-r in the namespace but while running command:
ip link set tap-r netns dhcp-g
it shows following error:
RTNETLINK answers: Invalid argument
- i still see tap-r and tap-g in my root namespace
WHY???? Please Help!
Yes Jorge Humberto Gomez Velasquez below mentioned the same, I'll look into it when I can, its related to a newer version of OVS.
I have problems.
I can solve it by replacing dhcp-r to dhcp_r and tap-r to tap_r.
I think it's a special character problem.
Thanks David this is so greate.
Thanks Michael!
Beautiful! Thanks! Probably, I am not the first one, who is asking about your output highlighting trick. How do you turn some output in SecureCRT to red and other lines to green? I know, SecureCRT can highlight, but you are doing this on click (like in PowerPoint). How?? :-)
Thanks! You are actually ha. It's Camtasia Studio the video editing app I've been using, not SecureCRT.
Nice explanation...
Thanks!
Great video! I learnt a lot
+Lovoni Bognini Great!!
Looks very similar to vrf lite on Cisco routers
Great (y) efforts appreciated
+vishal sharma Thanks a lot!
Simply brillant!
Thank you sir!
Is it possible to run the ovswitch in a separate namespace as well?
I imagine so, I haven't tried though!
appreciated
I am unable to find your video of DVR
+Abhishek Pandey Ya, it's not up yet, still working on it. It's slow going to get them out - I think in under a month.....well I hope! It's actually pretty long already!
Very nice Video
wowowowow........awsome ...i love itttt , please post more on openstack neutron
+Ijaz Ahmad Ha! I do have one more I'm working on probably still a month out or so, unfortunately these dont pay the bills ;-)
+David Mahler why don't you work for linuxacademy.com/ , they are looking for instructors like you , you can do it part time , they will definitely hire you , because you are a natural instructor.
+David Mahler linuxacademy.workable.com/
+Ijaz Ahmad Thanks a lot for information about them, I'll take a look.
wow amazing. .thank you sir
Thanks!
very good work thank you
You're welcome!
Great video!
Glad you enjoyed it
I still cannot get the difference between tap and veth interfaces in their usefulness. Originally, I thought that OVS could not span several namespaces, so one had to use veth in order to have one side in the namespace and the other side in the root namespace part of the OVS bridge. But that also seems to be a common use case to have a tap interface in a namespace and to make it a port of a root namespace's OVS bridge.
The conclusion would then be that OVS bridges can span namespaces. But what would be the real difference between tap and veth ? What are their specific use cases ? Or things you can/cannot do with each of them ?
NoSuchCommand A veth pair is effectively a virtual patch cable and the common use case for them is "patching" virtual bridges such as Linux bridges and OVS instances. A TAP devices is how a VM created by a hypervisor such as KVM implements it's vNIC. You can connect a TAP device to an OVS virtual bridge, however, OVS is not compatible with iptables rules applied directly to a TAP device connected directly to an OVS port. Often it's desirable to apply iptables rules directly to the TAP interface, as OpenStack does, so the usual connectivity method for a VM is TAP -> (traditional) Linux bridge -> veth pair -> OVS. When used as just a pipe between bridges, the veth pair does not need any IP addresses as it's purely a L2 forwarder. This is all explained really well in the OpenStack doco, docs.openstack.org/admin-guide-cloud/content/under_the_hood_openvswitch.html. Perhaps a mockup of this will be the subject of Mr Mahler's next video?
Barry the Cougar
Thank you for your answer. Yes I knew all this filtering thing requiring Linux Bridges. But my question was more about this specific example in the video. Moreover, what I did not notice when I wrote my first comment is that, here, the tap~ interfaces are in fact just OVS internal ports that happen to be named tap~. So they are not proper kernel interface of type tap. And that seems to be the same method used by OpenStack Neutron according to the OpenStack Cloud Administrator Guide you mentioned. However, this document is a bit old - in fact, this part of the Cloud Admin Guide is not referenced anymore in the ToC; you can only access it through a search engine, although it is still a good and mostly accurate documentation - and I do not have the setup at hand to check it up on the latest Neutron version.
In addition, Neutron's OVS mechanism, be it used standalone or through ML2, does not use veth pair to interconnect namespaces. It only uses them to interconnect the VMs' Linux Bridges to the integration virtual switch, which both are in the same namespace on the compute hosts. I can assume that the reason is you cannot make an OVS internal port also a port of a Linux Bridge. Namespaces in Neutron are only used by the L3 Agent (so only on the Network host if you do not use DVR) and each one of them is only populated by OVS internal ports
My point, at first, was : in this video, there is no Linux Bridge. Couldn't we have done all this with ONLY either veth pairs or tap devices or OVS internal ports ?
NoSuchCommand The video probably would have been better served if I named those ports at the end OVSI-R and OVSI-G instead of TAP-R and TAP-G. Linux Kernel "tuntap" interfaces can't cross namespaces AFAIK. Also the mixing of VETH and OVS-INTERNAL ports in the 1 video was just because I smushed together 2 different scenarios into one - a bit artificial but just for lab/demo/exploring of namespaces. At some point I hope to do a OpenStack Neutron video but as you note as well it's a moving target with DVR etc. and I myself have much to research and learn still before I'm ready to do one. I'm also split on focusing on network automation as well at the moment so not sure when each will happen.
Thanks for your comments!
Barry the Cougar Thanks for your additional information about iptables/Linux Bridging. Some point I hope to get to it more yes ;-).
please share open vSwitch installation video(latest version)
Awesome explanation 👏🏻
I have a doubt...when I try to ping green(vlan 200) from red(vlan100), will it ping or not?
If not..how to connect two vlans?
A layer 3 device (router) is needed weather virtual or physical.
Thanks David Mahler
How to assign layer 3 switch virtually?
@@DavidMahler You first need to assign a new subnet to one of your VLANs. You will surely run into issues trying to route between two VLANs operating within the same subnet. Most routers will not even let you place 2 different interfaces into the same subnet.
Awesome !! Thank you :)
Thanks for commenting!!
@David Mahler Why don't you upload new videos, been waiting for quite some time now ?
I know, sorry, I've been to busy with work and family!
Really helpful video. thanks a ton !!!!!!!!!!!!!!!!!
+Antony Silvester You're very welcome Antony!
great stuff thumps up
Thanks Mandela!
Simply superb!!l
Thanks! Thanks for commenting!
Wonderful
Thank you
Awesome !!! Thks a lot
Thanks! You're welcome!