James,
first off, thanks alot for your comments and clarifications ..
James Carlson schrieb:
Tobias Oberstein writes:
So, from your reply, I guess having e1000g0-2 on the same link
without having them in one IPMP group is evil.
At least in theory, you could have them on the same link but using
different (non-overlapping) subnets.
But that'd very likely be pointless. The configuration you're
describing screams out for IPMP.
What if I replaced the 10/100 MBit Miniswitch with a VLAN capable and
configured ports 2-4 so that they each be on their own virtual LAN?
Whould this still require having e1000g0-2 in one IPMP group?
It'd be good to take a step back and describe what you're trying to
accomplish, rather than describing the wires involved.
What do you need?
Currently, I got one 10/100MBit port on my ISPs data center switch.
The uplink is throttled well below 100MBit anyway, so connecting
the X4200 using multiple interfaces buys me nothing wrt speed.
However, binding different non-global zones to different interfaces
might ease (make less error prone) the goals of tight, cleanly separated
net security (IPF) and net resource consumption of zones.
I.e. bind all mass data services zones to ifc 1 and QoS ifc 1 accordingly.
Bind all interactive services zones to ifc 2 and do alike.
Or bind all non-encrypted/privately authenticated services zones to
ifc 3.
At least those were my thoughts.
I minor issue (which led me to binding the global zone multiple times)
was redundancy. If one ifc failed, I still could reach the global zone
over another. Ok, I didn't know anything about IPMP and it's probably
naive to assume the probability of a failing ifc is a real issue. More
likely perhaps is a failing ISP switch or uplink.
On the other hand, I might upgrade my ISP service package to 2 uplink
ports on different ISP switches .. then effective redundancy would be
a goal.
Anyway: my main objectives are net security and net resource control (QoS)
of non-global zones.
The reason I'm asking: I would really like to have IPMP, but I can't
have it together with stateful packet filtering:
It depends on how you use it. Stateful packet filtering, by design,
must be implemented at a choke point in your network. If you want
stateful _anything_ in the middle of your network, you must give up
the idea of redundancy. This is one of the reasons why many of us
Do you say stateful filtering doesn't go along _redundancy_ or/and
_load balancing_?
Either I don't get you or I don't think so. A pair of clustered
firewalls sharing one IP (see: CARP in the link below) with coherent
state sharing (see: pfsync in the link below) and crosslinked IN/OUT
connects (link failures) does the job of redundancy + stateful filtering.
+----| WAN/Internet |----+
| |
em2| |em2
+-----+ +-----+
| fw1 |-em1----------em1-| fw2 |
+-----+ +-----+
em0| |em0
| |
---+-------Shared LAN-------+---
See:
http://www.openbsd.org/faq/pf/carp.html
Google for
pfsync "stateful failover"
I think Cisco's PIX Firewall failover does similar things ..
believe that having flow-related state in the middle of the network is
inherently evil.
IMHO, stateless filtering is a security issue .. why would I want to
open whole ranges of TCP high ports for outgoing packets to random client
sockets? It's just not as tight as it can be. An PHP App Server getting
trojanized / botted isn't supposed to be allowed to phone home / distribute
spam .. at least not so easily. A User Login zone allowing user to make
outgoing connections isn't secure when I have to open high port ranges
for incoming packets. A silly user running his crap app on 8080 inviting
being hacked by someone isn't nice.
So, if you're implementing stateful packet filtering on this system,
you can't use IPMP there. If you're implementing it elsewhere in your
network -- some place where there's just a single link in and another
one out -- you should be able to use it without trouble.
Well, if I'd be ready to pay the additional fee for 2 more units rack space
plus two 1U low end boxes, I'd use OpenBSD. OBSD does a really great job here -
it's even possible to make the firewall invisible altogether ("transparent
bridge mode"). This would solve above issues and leave me with the missing
ability to filter inter-non-global zone traffic ..
http://docs.sun.com/app/docs/doc/816-4554/6maoq0245?a=view
I NEED stateful filtering. So I can't eat the cake;(
It sounds like an overconstrained problem to me.
Overconstrained under the restrictions of the platform implementation;)
<snip>
The design of RR on the first outgoing packet with IPMP is understandable:
balance load. Perhaps Solaris IPF could be modified to build it's state
entry from the 2nd packet .. the outoing SYN-ACK?
That's an interesting question, but I think it's actually pointless.
IPMP can switch from interface to interface when necessary (e.g.,
after an interface failure), so even if we did that, it wouldn't be a
complete solution. IPF would still fall over when IPMP does normal
failure recovery, and I don't think that's acceptable. It'd just be
an incomplete hack.
Ah, right. Didn't thought about the failing case.
The real solution is either for IP Filter to learn about IPMP groups
so that it can treat all packets within a group as being on the same
interface (the rest of the TCP/IP stack, incidentally, does this by
treating the group name as the interface) or somehow redesigning IPMP
and IP Filter together so that IP Filter actually sees only one
interface.
Or giving ipf a startup option to ignore interface info when building state
entries? Probably a cheap hack?
Of course, your first solution would be the real deal;)
Thanks again,
Tobias
_______________________________________________
zones-discuss mailing list
zones-discuss@opensolaris.org
