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 (http://www.netbsd.org/docs/network/#nonsubnetgateway).
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.
Thanks, Pierre-Philipp