On Mon, Dec 7, 2015 at 7:31 AM, Martin Millnert <martin@xxxxxxxxxxx> wrote: > On Mon, 2015-12-07 at 06:48 -0800, Gregory Farnum wrote: > <snip> >> >> I'm probably just being dense here, but I don't quite understand what >> >> all this is trying to accomplish. It looks like it's essentially >> >> trying to set up VLANs (with different rules) over a single physical >> >> network interface, that is still represented to userspace as a single >> >> device with a single IP. Is that right? >> > >> > That's almost what it is, with two differences: >> > 1) there are separated route tables per VLAN, >> > 2) Each VLAN interface (public, cluster) has its own address. >> >> Okay, but if each interface has its own interface, why do you need >> Ceph to do anything at all? You can specify the public and cluster >> addresses, they'll bind to the appropriate interface, and then you can >> do stuff based on the interface/VLAN it's part of. Right? >> -Greg > > Yes. And in the generic case: almost good enough. > > In the case I'm discussing, with also separate Linux kernel routing > tables, we need to steer the route lookups that happens once the tcp > stack has performed its packetization, into the correct table. > > Depending on how Ceph behaves with interface/IP binding for outbound > connections, this may be easy! > I.e. if Ceph binds to the specific address, not only on the listening > socket, but also when creating outbound sockets, we can create "ip > rule"'s that uses the source address and AFAIU "we're home" - at this > level. > Do you know if this is how Ceph manages the sockets in this case? > > But if we instead end up with the kernel trying to figure which address > to use ( https://tools.ietf.org/html/rfc6724 ), it gets a whole lot > trickier. Mmm, yeah, I think it makes the kernel pick each time. But if you've got the same IP on both I would hope that's not a problem. I haven't dug into it though. :/ -Greg > > For monitors that live only on the public network (as per > documentation), the situation is simpler; we can mark traffic outside of > Ceph using e.g. iptables. > > /Martin > -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
