Set static IP address on eth2 interface

[sachja]

The vxlan tests need the TEP addresses.

[jainvipin]

LGTM
@sachja - with this are you able to fire up the system tests and regression tests without any problems?

[sachja]

Tried a few manually and they seem to be working. Working on automating running the system test in this mode.

[sachja]

Btw - For vagrant setup we set the 192.xx IP address on eth1 on the host which is used by etcd. Shouldnt we set this on the eth2 interface? Otherwise data path and control path uses the same interface?

sachin

[jainvipin]

@sachja - Well for Vagrant setup we reserve eth2 for extending vlans, and for the data network. As in the configuration files (e.g. examples/two_hosts_multiple_vlans_nets.json). But etcd and vxlan traffic used the standard eth1 interface with 192.xx IP. The problem (read - more code to be added!) with using this on eth2 is that we need to reserve a control-vlan on eth2 and manage as vlan-interface on the host.

Why? Is it resulting into a problem in your setup? Ideally user can specify whatever underlay interface is the right one for the overlay traffic, however for extending vlans, a host ethernet interface must be specified and in that case entire interface would be controlled by the netplugin (i.e. vlans on it, etc.)

ping @mapuri

[mapuri]

The problem (read - more code to be added!) with using this on eth2 is that we need to reserve a control-vlan on eth2 and manage as vlan-interface on the host.
...
Ideally user can specify whatever underlay interface is the right one for the overlay traffic

I remember this came up when @sachja was experimenting with vxlan configuration. I might be getting confused, then I was under the impression that at some point netplugin would manage the underlay as well i.e. assign vtep-ip etc. In that case it might be more reasonable to let it manage the data traffic interface (eth2) than the control interface (eth1). And in absence of IP address management for vteps right now may be we can have static IPs on eth2 and use that instead at Vtep-IPs.

However, I am not sure if I understand the problem that @jainvipin is trying to bringup. @jainvipin, are you referring the vlan loop problem (issue #38) when you mention more code to be added!. I was thinking it only affects mix vlan and vxlan networks. Is that related?

[jainvipin]

@mapuri - no I wasn't referring to #38, which exists only in mix vlan/vxlan configuration. Unrelated to that, more code to be added is if we use one of the vlan on eth2 as our vxlan backend interface for all data communication. Today we use eth1's IP for vxlan backend communication between vagrant VMs, and eth2 (as per the configuration) is completely controlled for extending vlans.

[mapuri]

ok, yeah I remember having the discussion about control vlan but I thought it was only needed in ACI kind of setup where the outer vlan needs to match the infra-vlan.

BTW I just tried a two-host-vxlan example (examples/two_host_vxlan.json) with vtep ip address being the one configured on eth2 (I modified VagrantFile to configure it statically) and a basic ping test seems to work. Not sure if it was expected to fail 😄

In general, I feel it might be better to keep data traffic separate from control/management traffic and it might be good for our examples to reflect the same. For vlan traffic we found it the hard way as adding eth1 to ovs earlier caused etcd to stop working and we had to move to a separate data-network interface.