On 10/17/06, Roshan Perera <[EMAIL PROTECTED]> wrote:
Appreciate if someone can help me with VLAN tagging on zones please.
Details below. Dummy example..
Global Zone IP address 10.10.10.5 (IPMP real)
ce0 10.10.10.6 (IPMP test)
ce1 10.10.10.7 (IPMP test)
ce0 and ce1 don't need to be plumbed/configured, unless you have
traffic on the native (untagged) vlan using the 10.10.10.0 network.
VLAN tagging to be used in zones preferably using the same nic's as above or
zone1 to use VLAN tagging with IP address 10.10.20.10/23
zone2 to use VLAN tagging with IP address 10.10.30.10/23
You need to set up an IPMP group for each of thee VLAN interfaces. As
Steffen said, you need to plumb the VLAN interfaces (e.g. ce753001).
In this case you would need to create an IPMP group between ce753000
and 753001. In establishing a configuration like this I ran into the
following problems using link-based IPMP (no test addresses):
1) If another default router is needed to service these other
networks, listing them in /etc/defaultrouter does not cause them to
come up because /etc/defaultrouter is processed before the zones are
brought up. As such, anything in the zones that requires network
resources that require routing will be broken. Workaround was to
create my on zones boot SMF service and disable the Solaris default.
2) Address failover and failback does not happen properly. This is
part of an ongoing (6+ month) escalation. Failure modes range from
not failing over and disabling interfaces to faliing back to a
non-virtual interface. Impact ranges from causing a network outage
for the zones to making it so that a zone gets stuck down in
"shutting_down". Workaround is to configure dummy IP addresses in a
down state on each VLAN interface.
I don' t think that the problems above happen if probe-based IPMP is
used. However, in some load situations in.mpathd introduces false
failures due to dropped ICMP packets and/or logic bugs in in.mpathd.
zones-discuss mailing list