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.
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..
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 .
@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 ;-) )
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!
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
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 ?
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?
+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!
+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.
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
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
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?? :-)
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?
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 :-)
@@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.
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!
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!
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!!!
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!
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!
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!
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. This still a good video since 2015 ❤
Thanks! :-)
Still enjoying it in 2021 :)
still enjoying it in 2022))
Thank you David. I am preparing the COA exam, you're videos are simply invaluables
Awesome, I'm glad they are helping!
@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 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!
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!
Thanks David for explaining the complex topics in very understandable manner. Makes learning new technology easier.
Thanks so much Ankit!
Awesome info David ....simple session but covers in-depth technical .Thank you for sharing your knowledge ... :) .
Thanks!
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.....
Awesome tutorial on network namespaces. Would love more networking tutorials like this
Thanks for the comment!
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.
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
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 😊
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 :-)
As always, your videos are good. Keep educating us. Thanks.
***** Thanks!
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
This was really well done. Thanks for producing it.
+Philip Garrett Thanks for the comment! You're welcome!
This video is so much more than just linux namespaces.
Thanks for continuing to watch and comment Mike
David Mahler is a really great guy
So are you!
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!
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!
Nice video David, watched a couple of your videos, incremental explanation helps building up the concept. Cheers!👍🏻
TY, cheers!
Excellent lecture. Exactly the info that I needed. Thank you very much!
You're welcome!!
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!
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!
This is so good... wish I had seen this years ago when starting my network-programming related job 🤣
Thanks!
very clear and concise explanation, good stuff
thanks!
I wish I could thumbs this up twice! Bravo!
Thank you!!
An awesome presentation & explanation . Thanks for this video :)
+shakti shwetanshu You're welcome! Thanks for the comments!
David Sir your lecture is too good. ..thanks sir. ..God bless you. ..
pls make more video
Thanks Ujjal! OK ty!
this is very sharp and clean. thanks for sharing !
+simon lee You're very welcome!
Checking in in 2020, and gotta say that video is super.
Thanks!
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!
Simply super. I Love your videos.
+Yugandhar Sarraju Thanks!
You helped me sooo much! I absolutely love your videos!
That's great, thanks!
Thank you so much for the excellent tutorial about netns.
+sai1gon You're welcome!
Good video, thanks. Would be even cooler to see how the kernel info changes inside.
Noted!
The presentation is really good....!
Thanks!!
short and crisp! Thank you...
Mehul Vora yw!
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
thanks for the crystal clear explanation!
+koen van der rijt You're welcome!!
very good presentation
thx a lot David
Thanks!
great. I really like the way you presented!
Thank you!
Awesome video..Thanks a lot for sharing the knowledge.
+Prasanta Kumar Behera You're welcome!
Nice explanation !!! Thanks for the good tutorial
Govardhan Chintha You're welcome! Thanks for the comment.
very nice presentation!
Thanks!
This is excellent tutorial! Thanks!
Thanks!
Really helpful Sir. Thank you very much.
+Kiran Devraaj You're very welcome!
I love your videos. What tool you use to record those videos?
Thanks
Thanks, Camtasia Studio
wow nicely explained everything !! thanks
You're welcome, thanks for the comment!
Nice, so the built in linux namespace has dhcp component which is not part of openswitch?
Simply brillant!
Thank you sir!
Great video! I learnt a lot
+Lovoni Bognini Great!!
Great explanation!
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 ?
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?
appreciated
Thanks a lot for your great videos.
You're very welcome!
Thanks David this is so greate.
Thanks Michael!
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!
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.
Great video!
Glad you enjoyed it
Nice explanation...
Thanks!
Thanks, That was helpful
You're welcome, glad it helped!
Awesome, good job. Thanks.
Thanks!
Fantastic!Thank you.
Thank you too!
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
Looks very similar to vrf lite on Cisco routers
Great (y) efforts appreciated
+vishal sharma Thanks a lot!
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
Really helpful video. thanks a ton !!!!!!!!!!!!!!!!!
+Antony Silvester You're very welcome Antony!
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.
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?
wow amazing. .thank you sir
Thanks!
How creation of a new network name space different from running lxc-create command?
great stuff thumps up
Thanks Mandela!
very good work thank you
You're welcome!
Awesome !! Thank you :)
Thanks for commenting!!
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 :-)
@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!
please share open vSwitch installation video(latest version)
Wonderful
Thank you
Simply superb!!l
Thanks! Thanks for commenting!
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.
Is it possible to run the ovswitch in a separate namespace as well?
I imagine so, I haven't tried though!
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 ;-).
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.
Awesome !!! Thks a lot
Thanks! You're welcome!
helpful video
TY!