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? > 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 believe that having flow-related state in the middle of the network is inherently evil. 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. > 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. > Not sure if I got you right: > > A 3-way TCP handshake for an incoming TCP connection involves: > > 1. incoming SYN packet > 2. outgoing SYN-ACK packet > 3. incoming ACK packet Right. > With IPMP, the outbound interface is selected RR with packet 2, right? Yes. > Thus, packet 1 could come in e1000g2 and packet 2 could leave on e1000g0. Exactly. > Then, all subsequent outgoing packets would leave on e1000g0? Yes. At least until that cache IRE entry is flushed and recreated. > What about the subsequent incoming packets? The system cannot control those. They may arrive on any interface. They _may_ arrive on e1000g2, but there's no way to control where you get things _from_. > What I saw was this: > > Packet 1 on e1000g2, Packet 2 on e1000g0, Packet 3 and all subsequent > incoming/outgoing packet on e1000g2. But this was with no IPMP configured > and thus bogus anyway. That's also possible. If the network configuration is valid at all, then that should not matter. > If this is all correct, then I can understand why IPMP and stateful IPF > are incompatible. Right. > 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. 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. > - having multiple interfaces on the same link requires IPMP Basically, yes. > - IPMP alongside stateful IPF does not work Right. -- 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 _______________________________________________ zones-discuss mailing list email@example.com