Comments for blog.scottlowe.org http://blog.scottlowe.org The weblog of an IT pro specializing in virtualization, storage, and servers Wed, 15 May 2013 20:31:23 +0000 hourly 1 http://wordpress.org/?v= Comment on Examining Open vSwitch Traffic Patterns by Sascha http://feeds.scottlowe.org/~r/slowe/comments/feed/~3/WoOTAhfurXc/ Sascha Wed, 15 May 2013 20:31:23 +0000 http://blog.scottlowe.org/?p=3185#comment-72011 Thanks Lennie, I got it. :) Thanks Lennie, I got it. :)

]]> http://blog.scottlowe.org/2013/05/15/examining-open-vswitch-traffic-patterns/comment-page-1/#comment-72011 Comment on Using pf on OS X Mountain Lion by Lennie http://feeds.scottlowe.org/~r/slowe/comments/feed/~3/k49G1k3c4Lo/ Lennie Wed, 15 May 2013 19:22:19 +0000 http://blog.scottlowe.org/?p=3183#comment-72010 Scott, My experiences with Macs are limited, but I do have experience with pf on OpenBSD. It is interresting how they use the anchor, normally you'd just use an include. Anchors are usually used to dynamically add/remove rules from for example a userspace program. The name of the anchor would for example be the name of the program, relayd is an example of such a program: http://www.openbsd.org/cgi-bin/man.cgi?query=relayd&sektion=8&arch=&apropos=0&manpath=OpenBSD+Current I wouldn't be surprised if on the Mac they are actually dynamically adding rules as well. You can probably see that if you use these commands when pf is enabled: pfctl -vvsr # to see the current rules pfctl -vvss # to see the current state entries Scott,

My experiences with Macs are limited, but I do have experience with pf on OpenBSD.

It is interresting how they use the anchor, normally you’d just use an include.

Anchors are usually used to dynamically add/remove rules from for example a userspace program. The name of the anchor would for example be the name of the program, relayd is an example of such a program: http://www.openbsd.org/cgi-bin/man.cgi?query=relayd&sektion=8&arch=&apropos=0&manpath=OpenBSD+Current

I wouldn’t be surprised if on the Mac they are actually dynamically adding rules as well.

You can probably see that if you use these commands when pf is enabled:

pfctl -vvsr # to see the current rules
pfctl -vvss # to see the current state entries

]]> http://blog.scottlowe.org/2013/05/15/using-pf-on-os-x-mountain-lion/comment-page-1/#comment-72010 Comment on Examining Open vSwitch Traffic Patterns by Sascha http://feeds.scottlowe.org/~r/slowe/comments/feed/~3/yJUTVxx3Y_k/ Sascha Wed, 15 May 2013 18:57:25 +0000 http://blog.scottlowe.org/?p=3185#comment-72007 No need to apologize Scott. I was just confused, plus I am not a native english speaker :) It makes more sense now to me, thanks. So the gre0 tunnel interface is actually the one connecting to the host's IP stack, not the bridge per se. Exciting stuff. And looking forward to the more complicated stuff :D Also, I think it's time to setup an OpenStack lab. No need to apologize Scott. I was just confused, plus I am not a native english speaker :) It makes more sense now to me, thanks. So the gre0 tunnel interface is actually the one connecting to the host’s IP stack, not the bridge per se.

Exciting stuff. And looking forward to the more complicated stuff :D

Also, I think it’s time to setup an OpenStack lab.

]]> http://blog.scottlowe.org/2013/05/15/examining-open-vswitch-traffic-patterns/comment-page-1/#comment-72007 Comment on Examining Open vSwitch Traffic Patterns by Lennie http://feeds.scottlowe.org/~r/slowe/comments/feed/~3/rM9VfVWU7-A/ Lennie Wed, 15 May 2013 18:37:05 +0000 http://blog.scottlowe.org/?p=3185#comment-72006 @Sascha I think this might make it clear: Let's say the guest has a port called vnet0 which connected to an OVS bridge br-int. And a GRE-tunnel is created called gre0 and it is also connected to br-int. As you know a switch and a bridge is pretty much the same thing. The OVS/bridge uses MAC-learning like a normal swich. When traffic comes onto the bridge from the guest through vnet0, the bridge will look at the forwarding table and might decide that the MAC-address of the destination is on gre0. In that case the traffic is forwarded to gre0. At gre0 it gets encapsulated with a GRE-header. The GRE-tunnel is handled by the host. The host just routes the GRE-tunnel packets to the remote_ip, where it gets unpacked and delivered on an other bridge which will hopefully know what to do with it and deliver it at the right port, which is probably connected to a VM. @Sascha I think this might make it clear:

Let’s say the guest has a port called vnet0 which connected to an OVS bridge br-int. And a GRE-tunnel is created called gre0 and it is also connected to br-int.

As you know a switch and a bridge is pretty much the same thing.

The OVS/bridge uses MAC-learning like a normal swich.

When traffic comes onto the bridge from the guest through vnet0, the bridge will look at the forwarding table and might decide that the MAC-address of the destination is on gre0. In that case the traffic is forwarded to gre0.

At gre0 it gets encapsulated with a GRE-header. The GRE-tunnel is handled by the host.

The host just routes the GRE-tunnel packets to the remote_ip, where it gets unpacked and delivered on an other bridge which will hopefully know what to do with it and deliver it at the right port, which is probably connected to a VM.

]]> http://blog.scottlowe.org/2013/05/15/examining-open-vswitch-traffic-patterns/comment-page-1/#comment-72006 Comment on Examining Open vSwitch Traffic Patterns by slowe http://feeds.scottlowe.org/~r/slowe/comments/feed/~3/7Ymc-K6Gn1I/ slowe Wed, 15 May 2013 18:26:56 +0000 http://blog.scottlowe.org/?p=3185#comment-72005 Sascha, I'm the one that called it an isolated bridge, and that's because it has no physical interfaces associated with it. I apologize if my wording threw you off. The reason the traffic hits the host's IP stack is because of the tunnel interface. Without the tunnel interface, the bridge would truly be isolated---not able to communicate outside the host at all. The purpose of the tep0 interface is simply to control which NICs the tunnel endpoint uses. Because tep0 is utilized by the host's IP stack, and because the tunnel interface connects the bridge to the host's IP stack, that's what allows the traffic to flow from the isolated bridge through tep0. You could just as easily have used a physical interface for the tunnel endpoint instead of an OVS internal interface. Lennie, more "complicated" configurations are on the way. First, though, I need to establish the correct base understanding upon which I can build more in-depth configurations that leverage things like VLANs, network namespaces, source routing, and similar. Patience, my friend...patience. :-) Sascha, I’m the one that called it an isolated bridge, and that’s because it has no physical interfaces associated with it. I apologize if my wording threw you off. The reason the traffic hits the host’s IP stack is because of the tunnel interface. Without the tunnel interface, the bridge would truly be isolated—not able to communicate outside the host at all. The purpose of the tep0 interface is simply to control which NICs the tunnel endpoint uses. Because tep0 is utilized by the host’s IP stack, and because the tunnel interface connects the bridge to the host’s IP stack, that’s what allows the traffic to flow from the isolated bridge through tep0. You could just as easily have used a physical interface for the tunnel endpoint instead of an OVS internal interface.

Lennie, more “complicated” configurations are on the way. First, though, I need to establish the correct base understanding upon which I can build more in-depth configurations that leverage things like VLANs, network namespaces, source routing, and similar. Patience, my friend…patience. :-)

]]> http://blog.scottlowe.org/2013/05/15/examining-open-vswitch-traffic-patterns/comment-page-1/#comment-72005 Comment on Examining Open vSwitch Traffic Patterns by Lennie http://feeds.scottlowe.org/~r/slowe/comments/feed/~3/zbZhrop-tSk/ Lennie Wed, 15 May 2013 16:41:46 +0000 http://blog.scottlowe.org/?p=3185#comment-72002 It is very good you are explaining this to people. But for the people that found this to easy, maybe you can add some network-namespaces, VM to VM routing, iptables, firewalling, NAT and VLAN as well. Mix it up a little. :-) Or just try these things and see if you come across any strange things you might not have expected and make a quiz out of it. So the commenters can try and figure out what is going on. What is on my todo list is to see what is possible in OpenStack, which configurations are supported. And making a choice which one I want to use. What I'm hoping to do is use some of the DOVE extensions of VXLAN to prevent broadcasts, the extensions are available in Linux 3.8, like on Ubuntu 13.04, but I don't know if there are any existing open source components that can use them. I doubt I'll have time to write any code for that myself. Haven't looked at the security groups support in OpenStack either. So much still left to do, so little time, but at least it's fun stuff. :-) It is very good you are explaining this to people.

But for the people that found this to easy, maybe you can add some network-namespaces, VM to VM routing, iptables, firewalling, NAT and VLAN as well. Mix it up a little. :-)

Or just try these things and see if you come across any strange things you might not have expected and make a quiz out of it. So the commenters can try and figure out what is going on.

What is on my todo list is to see what is possible in OpenStack, which configurations are supported. And making a choice which one I want to use.

What I’m hoping to do is use some of the DOVE extensions of VXLAN to prevent broadcasts, the extensions are available in Linux 3.8, like on Ubuntu 13.04, but I don’t know if there are any existing open source components that can use them. I doubt I’ll have time to write any code for that myself.

Haven’t looked at the security groups support in OpenStack either.

So much still left to do, so little time, but at least it’s fun stuff. :-)

]]> http://blog.scottlowe.org/2013/05/15/examining-open-vswitch-traffic-patterns/comment-page-1/#comment-72002 Comment on Examining Open vSwitch Traffic Patterns by Sascha http://feeds.scottlowe.org/~r/slowe/comments/feed/~3/VgXEknEn9o4/ Sascha Wed, 15 May 2013 16:14:00 +0000 http://blog.scottlowe.org/?p=3185#comment-72000 Good post, thanks. So to iterate on my question from your previous post, if you have an isolated bridge, it is not really isolated but does eventually hit the host's IP stack and all of it's routing.... right? Otherwise gre0 traffic wouldn't be able to reach the tep0 interface. I don't see why they call this an "isolated" bridge then. Or is it hitting tep0 because that belongs to another OVS instance? Good post, thanks. So to iterate on my question from your previous post, if you have an isolated bridge, it is not really isolated but does eventually hit the host’s IP stack and all of it’s routing…. right? Otherwise gre0 traffic wouldn’t be able to reach the tep0 interface. I don’t see why they call this an “isolated” bridge then.

Or is it hitting tep0 because that belongs to another OVS instance?

]]> http://blog.scottlowe.org/2013/05/15/examining-open-vswitch-traffic-patterns/comment-page-1/#comment-72000 Comment on Using pf on OS X Mountain Lion by slowe http://feeds.scottlowe.org/~r/slowe/comments/feed/~3/vf0pA-J8AMk/ slowe Wed, 15 May 2013 15:58:59 +0000 http://blog.scottlowe.org/?p=3183#comment-71997 Tim, the advantage here is that pf offers much greater granularity than the firewall in System Preferences. For example, with pf I can allow traffic used by iTunes, but only from specific network addresses. In System Preferences, the traffic is either allowed or denied. However, keep in mind that this additional flexibility also means additional complexity, and that might deter the use of pf for more "casual" OS X users. I hope this helps! Tim, the advantage here is that pf offers much greater granularity than the firewall in System Preferences. For example, with pf I can allow traffic used by iTunes, but only from specific network addresses. In System Preferences, the traffic is either allowed or denied.

However, keep in mind that this additional flexibility also means additional complexity, and that might deter the use of pf for more “casual” OS X users.

I hope this helps!

]]> http://blog.scottlowe.org/2013/05/15/using-pf-on-os-x-mountain-lion/comment-page-1/#comment-71997 Comment on Using GRE Tunnels with Open vSwitch by slowe http://feeds.scottlowe.org/~r/slowe/comments/feed/~3/3FZnN1yZ6z8/ slowe Wed, 15 May 2013 15:56:52 +0000 http://blog.scottlowe.org/?p=3175#comment-71996 Sean, Sascha, I've written a new post on how various Open vSwitch (OVS) configurations affect traffic. Hopefully this will help clear up some of your questions. Have a look at the article here: http://blog.scottlowe.org/2013/05/15/examining-open-vswitch-traffic-patterns/ Thanks! Sean, Sascha, I’ve written a new post on how various Open vSwitch (OVS) configurations affect traffic. Hopefully this will help clear up some of your questions. Have a look at the article here:

http://blog.scottlowe.org/2013/05/15/examining-open-vswitch-traffic-patterns/

Thanks!

]]> http://blog.scottlowe.org/2013/05/07/using-gre-tunnels-with-open-vswitch/comment-page-1/#comment-71996 Comment on Using GRE Tunnels with Open vSwitch by Examining Open vSwitch Traffic Patterns - blog.scottlowe.org - The weblog of an IT pro specializing in virtualization, storage, and servers http://feeds.scottlowe.org/~r/slowe/comments/feed/~3/Z7_UtyyEZ9Q/ Examining Open vSwitch Traffic Patterns - blog.scottlowe.org - The weblog of an IT pro specializing in virtualization, storage, and servers Wed, 15 May 2013 15:52:24 +0000 http://blog.scottlowe.org/?p=3175#comment-71995 [...] Let’s look at another OVS configuration, the so-called “isolated bridge”. This is a configuration that is commonly found in implementations using NVP, OpenStack, and others, and it’s a configuration that I recently discussed in my post on GRE tunnels and OVS. [...] [...] Let’s look at another OVS configuration, the so-called “isolated bridge”. This is a configuration that is commonly found in implementations using NVP, OpenStack, and others, and it’s a configuration that I recently discussed in my post on GRE tunnels and OVS. [...]

]]> http://blog.scottlowe.org/2013/05/07/using-gre-tunnels-with-open-vswitch/comment-page-1/#comment-71995