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
zones-discuss@opensolaris.org

Reply via email to