Peter J. Cherny writes:
> Inter alia carlsonj wrote:
> >You can "stop" it by using IP Filter to discard the packet, but that's
> >unlikely to solve the problem you're facing.
>
> As I've just said in another thread "Policy Routing" should be considered.
> IPFilter can be coerced to do this, but the NW development team need
> to understand the issues.
It's a difficult configuration to manage, which is why I hesitated to
recommend it. It gets even more complex if you have multiple networks
behind the node in question, so there's no simple "just do this"
answer.
> It will/has all come to a head with Zones and multiple interfaces/default
> routes, a situation that is a total train wreck, esp. zone-zone pkt flow.
For what it's worth, and it may not be much, the original design
center for Zones was aggregation of services that are present on the
same collection of networks. The classic example is a farm of web
servers (for ISP-hosted services) on an Internet-facing subnet.
The design center explicitly did not include systems that were on
isolated (and possibly mutually-hostile) networks, or with complex
inter-dependencies (such as load balancers, NATs, or filters between
the zones).
This might seem like a "train wreck" (or even some worse metaphor) to
some users, but it was actually an intentional decision. The original
project team looked at the virtualization space and saw simple answers
at the low end (the usual "virtual server" feature in a web server and
chroot are examples) and full separation at the high end (Xen, VMware,
Domains, LPARs). There was nothing in the middle. Zones was aimed at
that middle ground, with a shared infrastructure and a controlled,
isolated space for each zone.
That "shared infrastructure" for Zones includes the kernel itself, the
machine hardware, and the network connectivity.
It's possible that a future project ("stack instances") will alter
this somewhat, but I think it's important to understand that Zones was
designed with a particular class of usage in mind. It's not all
things to all people, and likely cannot be.
--
James Carlson, KISS Network <[EMAIL PROTECTED]>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
_______________________________________________
networking-discuss mailing list
[email protected]
