The thing is, that at least in my installation(the default on ubuntu 16.04), it does not learn the new location. It just drops any package when it comes in on a port where it's not expected. I have to wait until the old cached mac disappears (seems to be something like 300 seconds), as shown when running "ovs-appctl fdb/show".
Carp works by sending a multicast packet once every second(by default). Once an interface has established itself as a slave it will stop sending packets until the master stops sending. So it's not very often. I expect VRRP works in a similar manner, but I don't have much experience with it. More info on carp:https://www.openbsd.org/faq/pf/carp.html On Tue, Sep 6, 2016 at 4:55 PM, Ben Pfaff <b...@ovn.org> wrote: > On Tue, Sep 06, 2016 at 11:50:13AM +0200, Fredrik Dahlberg wrote: > > On Mon, Sep 5, 2016 at 5:33 AM Ben Pfaff <b...@ovn.org> wrote: > > > > > On Sun, Sep 04, 2016 at 07:12:43PM +0000, Fredrik Dahlberg wrote: > > > > I am trying to get carp to work with ovs(2.5.0, ubuntu 16.04). > > > > > > > > Carp is set up with the same mac address on the carp interfaces, > trying > > > to > > > > determine who is master like this: > > > > 20:55:56.326841 00:00:5e:00:01:19 (oui Unknown) > 01:00:5e:00:00:12 > (oui > > > > Unknown), ethertype IPv4 (0x0800), length 70: 192.168.43.2 > > > > vrrp.mcast.net: > > > > CARPv2-advertise 36: vhid=25 advbase=1 advskew=50 authlen=7 > > > > counter=4581652178833997382 > > > > 20:55:56.382550 00:00:5e:00:01:19 (oui Unknown) > 01:00:5e:00:00:12 > (oui > > > > Unknown), ethertype IPv4 (0x0800), length 70: 192.168.43.4 > > > > vrrp.mcast.net: > > > > CARPv2-advertise 36: vhid=25 advbase=1 advskew=100 authlen=7 > > > > counter=11630556296063315122 > > > > (The difference in advskew here shows they are different sources.) > > > > > > > > However, ovs won't let any frames through if they arrive on the > "wrong" > > > > port according to the fdb. When sniffing on the bridge I can only see > > > > packets from the source that started first. This easily leads to a > > > > situation where I end up with multiple carp masters, and even if it > > > didn't, > > > > we have to wait for the entry in the fdb to time out before the new > > > master > > > > is visible to the network. > > > > > > > > Any suggestions on how to solve this? Any way to allow frames on the > > > > "wrong" port to update the fdb? > > > > > > I don't understand what you mean by the "wrong" port. Open vSwitch > > > implements a conventional MAC learning algorithm. What's carp trying > to > > > do, and why doesn't it work with MAC learning? > > > > > > > As far as I have learned, normally a switch will behave like this: If it > > receives a packet on a certain port, it will learn that the source mac > > address resides on that port, and send packets destined for that mac out > > only on that port. If it receives a packet from the same mac address on a > > different port, it will update what it has learned and start sending out > > packets destined for that mac address on the new port. Ovs however, at > > least in my installation, will not update the mac address table when it > > receives a packet from a mac address it has already learn, instead > dropping > > that packet. > > > > Since carp uses the same mac address on different hosts, I can't get it > to > > work over ovs. The host that starts announcing itself first will get > > learned by ovs, and the other one will just have it's packets dropped, > > leading to a situation where one of them can't see the other. One > solution > > would be if it was possible to make ovs behave more like a normal switch > > and update the mac addresses instead of dropping the packets. > > OVS should learn changes in MAC address locations in the same way as any > other switch. > > How frequently does carp move MAC addresses? If it's moving a single > MAC address multiple times per second, OVS might have some trouble with > that; it's never been a use case that we've looked into. >
_______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
