I have a question, do you really need a bridge ip? I mean can you just forward a packet using iptables to the corresponding veth interface of the pod? Another thing is, lets say a pod send a packet, it is received in the bridge, and in the bridge what goes first? ARP resolution, or iptables filtering?
In your 4th and final scenario, containers are in different IP subnets. This does not play well as the idea of an overlay is that the containers can move between hosts and retain their IP address.
Answering my own question: So let's say your container is interacting with another container using a TCP connection, and has to use the TUN device to get there. The connection’s reliability is already guaranteed by the upper layer protocol. Since our TUN device is using a UDP tunnel to load a website. Your browser would use TCP to connect to the port 80 of the server hosting the website. The browser has no idea your connection is going through a UDP tunnel and neither does the said TCP protocol. The TCP connection gets established and you get full advantage of all the features it has to offer. If the lower layer (The UDP stream) drops a packet, the TCP connection established inside it would notice and re-request it.
Really very nice, neat and informative presentation. I tried to follow a similar approach for one of my session but stuck at some points as I mentioned below - What is the 9000 port at 25:23min? I cant see any rule that could route traffic to tun0 interface in 25:23. But you mentioned the same in 21:17. Am I missing something?
I think `$TUNNEL_IP/16` in `socat TUN:$TUNNEL_IP/16,iff-up UDP:$TO_NODE_UP:9000,bind=$NODE_IP:9000` do the trick. All IP in range of `$TUNNEL_IP/16` would go through the tunnel.
Question! Secnario 2: You've shown veth and bridge, and it's also mentioned veth forwards traffic to other pod's veth by means of the bridge inbetween. I understand a Linux bridge operates at layer 2 of the TCP/IP which transports data as frames (as against packets in layer 3), and knows the destination to send the frames to by means of a MAC address (as against IP address used in layer 3) stored in a database in the bridge . I also understand veth interfaces have MAC addressses. So in this case, when traffic flows from one pod to another there's no need for using destination IP address. Is my assumption correct? Someone somewhere mentioned ARP comes in-between in here (which basically does the job of translating MAC to IP). I'm not sure if it is true that ARP is used here. Could someone clarify on this please? Refer: wiki.openvz.org/Virtual_Ethernet_device
For routing from one pod to another we communicate using the concept of using IP addresses. Because from pod to pod there's no need of network address translation needed. Here the packets transfer between pods is based on tcp/ip purely and uses the udp protocol. Only when the packet is meant for a pod running on in a different namespace does it require a tcp model of packet transfer which is handled by the cloud or the external network routing.
I think you're right. Somebody correct me if I'm wrong, but from my understanding, when you have a layer 2 switch (which the linux virtual bridge acts like), it routes data based solely on the ethernet frame. Meaning the bridge won't unwrap the frame any further to look for an IP header or anything. The bridge would route the packets to the container correctly, but beyond that you'd have to figure out how to get the data to the process running in the container. The linux kernel has code that associates tcp/udp ports to different processes (layer 4). I'm not sure what mechanism there is to associate raw layer 2 data with a process. Maybe using dftables.
![CNCF [Cloud Native Computing Foundation]](http://yt3.ggpht.com/93B7ElGi-TMF2lISQD79p1MVhUf4jVfE8KMyAmVAVUEMp8jvARqS0TtQxelj_odxgmJ_SAYsjg=s48-c-k-c0x00ffffff-no-rj)
![Life of a Packet [I] - Michael Rubin, Google](http://i.ytimg.com/vi/0Omvgd7Hg1I/mqdefault.jpg)
![Life of a Packet [I] - Michael Rubin, Google](/img/tr.png)
Loving the Bristol accent. Cheers drive, lush networking stack mind!
It's really a great presentation. Everything suddenly became crystal clear.
Kris has to be the best you can learn anything cloud from. Had the privilege to learn as a part of his team at oracle.
Great presentation, thank you! I also like your humbleness and approach from 0:20 - 0:35.
Someone give this guy an award!
What a genius way of explaining the topic! Thanks
Excellent!!! Amazed at how you can explain this complicated stuff simply. Thanks!
seeing this for free is a blessing. Thanks!
Great presentation, explains the missing chapters in many kubernetes guides
Great Video! The demo is very practical and illustrative for network newbees like me!
I have a question, do you really need a bridge ip? I mean can you just forward a packet using iptables to the corresponding veth interface of the pod? Another thing is, lets say a pod send a packet, it is received in the bridge, and in the bridge what goes first? ARP resolution, or iptables filtering?
YES, iptables could do it too, I think.
Thank you. You did an awesome job and helped me understand how to set this up on bare metal. Hats off to you sir.
Amazing presentation! Thanks a lot!
Very insightful presentation! Thanks for all the hard work.
In your 4th and final scenario, containers are in different IP subnets. This does not play well as the idea of an overlay is that the containers can move between hosts and retain their IP address.
Great presentation.... it’s the missing chapter in many Kubernetes books
Great presentation to understand overlay network
Wonderful Presentation.
Great presentation, perfect demos ! Kudos
Great packaging overview.
excellent explanation, well structured
Thank you, i cleared a lot of stuff here.
It was amazing. I was in very trouble to understand this stuff by my own, but couldn't link things with each other. Now I can. Thanks
Great thanks Awesome presentation !
Excellent!!! Very detailed presentation
Thanks, very helpful talk Kristen
Amazing Stuff !!
Can someone help me understand his answer to the UDP question around 23:00 , I don't understand where the reliability is coming from?
Answering my own question:
So let's say your container is interacting with another container using a TCP connection, and has to use the TUN device to get there. The connection’s reliability is already guaranteed by the upper layer protocol. Since our TUN device is using a UDP tunnel to load a website. Your browser would use TCP to connect to the port 80 of the server hosting the website. The browser has no idea your connection is going through a UDP tunnel and neither does the said TCP protocol. The TCP connection gets established and you get full advantage of all the features it has to offer. If the lower layer (The UDP stream) drops a packet, the TCP connection established inside it would notice and re-request it.
Very well presented. Thank you.
Clear to the goal , Thanks Kristen
Great, very well explained, thank you.
Clear !
Thanks!
Awesome stuff!
Very clear explanation! Can I find the scripts used in the video on GitHub?
Really very nice, neat and informative presentation. I tried to follow a similar approach for one of my session but stuck at some points as I mentioned below -
What is the 9000 port at 25:23min?
I cant see any rule that could route traffic to tun0 interface in 25:23. But you mentioned the same in 21:17. Am I missing something?
socat adds the route automatically. Any packet destined for 172.16.0.0/16 will be directed to tun0.
@@bandisandeep Not really sure if it adds that route automatically. In my case, I have to explicitly add that route to make that work
I think `$TUNNEL_IP/16` in `socat TUN:$TUNNEL_IP/16,iff-up UDP:$TO_NODE_UP:9000,bind=$NODE_IP:9000` do the trick. All IP in range of `$TUNNEL_IP/16` would go through the tunnel.
AWESOME
great talk
Great talk! When you say multiple nodes (Case 3)... do you mean multiple Servers like could be CIsco UCS? Thanks!
Yes, we can setup multiple such nodes.
Excellent
Immense thanks for this
Awesome!
Why no NAT?
Question!
Secnario 2:
You've shown veth and bridge, and it's also mentioned veth forwards traffic to other pod's veth by means of the bridge inbetween.
I understand a Linux bridge operates at layer 2 of the TCP/IP which transports data as frames (as against packets in layer 3), and knows the destination to send the frames to by means of a MAC address (as against IP address used in layer 3) stored in a database in the bridge . I also understand veth interfaces have MAC addressses. So in this case, when traffic flows from one pod to another there's no need for using destination IP address. Is my assumption correct? Someone somewhere mentioned ARP comes in-between in here (which basically does the job of translating MAC to IP). I'm not sure if it is true that ARP is used here. Could someone clarify on this please?
Refer: wiki.openvz.org/Virtual_Ethernet_device
For routing from one pod to another we communicate using the concept of using IP addresses. Because from pod to pod there's no need of network address translation needed.
Here the packets transfer between pods is based on tcp/ip purely and uses the udp protocol.
Only when the packet is meant for a pod running on in a different namespace does it require a tcp model of packet transfer which is handled by the cloud or the external network routing.
I think you're right. Somebody correct me if I'm wrong, but from my understanding, when you have a layer 2 switch (which the linux virtual bridge acts like), it routes data based solely on the ethernet frame. Meaning the bridge won't unwrap the frame any further to look for an IP header or anything. The bridge would route the packets to the container correctly, but beyond that you'd have to figure out how to get the data to the process running in the container. The linux kernel has code that associates tcp/udp ports to different processes (layer 4). I'm not sure what mechanism there is to associate raw layer 2 data with a process. Maybe using dftables.
Route not Root!!!!!!!
Awesome!