[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: default route on other subnet
Quoting Brian Buhrow 30/09/2011 21:34,
Hello. So unless I'm really not understanding what's going on, I
wouldn't expect your example to work. A bridge is not a router. What I
mean by that is that a bridge cannot move a packet from one IP subnet, i.e.
10.1.1.0/24 to another, 10.2.2.0/24. Instead, what I suggest is something
I'm not sure on what you understood either. It's a long thread, you
probably didn't follow the first posts months ago. But I though I was
clear enough in my last briefings. If that's unclear, it's actually
possible to use a gateway outside the subnet when forcing the route. To
me, the bridge doesn't prevent that from happening either. I'm able to
make this work with Linux guests. And it's supposed to work with NetBSD
The example your give with other IPs doesn't correspond to my
configuration. I've got two public IPs which I can't change, one for
the dom0 and one for the guest. Whether it's routing or bridging
doesn't change the issue at all. The gateway is outside the subnet in
both cases (respectively dom0's ip or the real gateway).
I could try to attribute the wrong-subnet IP to the dom0 and give the
previous dom0 IP to the guest. That's not even a dirty workaround tho,
it's just plain leaking. But it could work in my situation as I only
got *one* ok-subnet IP and only need *one* netbsd guest for the time being.
I think it's a bug, which I should report. Is it netbsd's route, a
linux or xen-tools issue? Maybe it's just between the two (netbsd and
the latters). But it's like with pkgsrc. When linux distro's uname -p
decides to print the cpu model instead of the plateform, pkgsrc needs to
adapt, as an alternate package system for a foreign operating system.
Here I'm using a NetBSD guest on a foreign XEN/dom0 configuration. It's
almost working perfectly fine. Just ffs log and that
default-route-on-other-subnet tickles. And if one of NetBSD's
objectives is to work on linux dom0's too, I'm afraid we will have to
fix those on NetBSD's side, unless they are caused by real flaws in
linux, xen or xen-tools.
Main Index |
Thread Index |