Assigning an IP address to an Open vSwitch bridge at boot time.

Good morning all.

I've been trying to give an Open vSwitch bridge a persistent IP address, but the the interface (bridge0) doesn't exist until ovs-vswitchd and ovsdb-server are started. This presents me with the problem that, as far as rcorder is concerned, netif comes before any Open vSwitch services, which means that ifconfig_* entries in rc.conf fail, and this failure cascades as services that depend on the bridge don't start. Is there a "right" way I should be going about giving the Open vSwitch bridge interface an IP address?

Thomas
 
I'm not sure if it's going to work with this but you can create the interface in /etc/rc.conf like this:
Code:
cloned_interfaces="bridge0"
With that you can use
Code:
ifconfig_bridge0="inet 1.2.3.4 netmask 255.255.255.0"

That's assuming the Open vSwitch software uses the "standard" bridge(4) interfaces.
 
I'm in the process of testing out your suggestion, but it's not looking good so far. Open vSwitch (in FreeBSD at least) appears to be using tap devices for internal ports. When it initializes the virtual switch, it creates its tap devices, then renames it to whatever name is appropriate (tap1 -> bridge0, in my case). The way it handles existing interfaces with the same name seems to be silently failing and taking the tap device back down. I'm going to poke at it for a while, but I haven't seen an obvious way to pass it a pre-configured tap device yet.

Edit: Now that I think about it, is this how they intend to leave Open vSwitch implemented, or is the kernel part of it still in the works? Maybe I'm jumping the gun and trying to use this too early?
 
Got the exact same problem 9 years later ! I can't find a way to assign a persistent IP to the OVS bridge (internal) interface.
What kaori.hinata describes is exactly what's happen (internal bridge interface is creating a tap interface then it renames it).
I also tried the suggestion from SirDice but it doesn't work. I can't find a way to do it...

I also realize that if I do it manually this is causing DUP packets to occurs..
 
Back
Top