Hi Mike and all,
Thanks for your previous replies. Sorry for the late reply.
I have run into problems with VLAN tagging now. Can you please check whether
its a config problem or limitation on IPMP on FAILED interfaces.
ss44bsdvzgza02# ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232
index 1
inet 127.0.0.1 netmask ff000000
bge604000: flags=211000803<UP,BROADCAST,MULTICAST,IPv4,FAILED,CoS> mtu 1500
index 2
inet 10.165.4.171 netmask fffffe00 broadcast 10.165.5.255
groupname global
ether 0:3:ba:c8:7d:35
bge604000:1:
flags=219040803<UP,BROADCAST,MULTICAST,DEPRECATED,IPv4,NOFAILOVER,FAILED,CoS>
mtu 1500 index 2
inet 10.165.4.172 netmask fffffe00 broadcast 10.165.5.255
bge604001:
flags=239040803<UP,BROADCAST,MULTICAST,DEPRECATED,IPv4,NOFAILOVER,FAILED,STANDBY,CoS>
mtu 1500 index 3
inet 10.165.4.173 netmask fffffe00 broadcast 10.165.5.255
groupname global
ether 0:3:ba:c8:7d:36
NOTE: Interfaces are in FAILED mode due to cables not plugged in yet. Also, no
default router.
Now trying to configure zone with VLAN tagged.
zonecfg:sz44bsdvapdqc02> create
zonecfg:sz44bsdvapdqc02> set autoboot=true
zonecfg:sz44bsdvapdqc02> set zonepath=/export/zone/dvapdqc02
zonecfg:sz44bsdvapdqc02> add net
zonecfg:sz44bsdvapdqc02:net> set physical=bge604000
zonecfg:sz44bsdvapdqc02:net> set address=10.165.20.35/23
zonecfg:sz44bsdvapdqc02:net> end
zonecfg:sz44bsdvapdqc02> info
ss44bsdvzgza02# zoneadm -z sz44bsdvapdqc02 boot
zoneadm: zone 'sz44bsdvapdqc02': bge604000:2: could not set default interface
for multicast: Invalid argument
zoneadm: zone 'sz44bsdvapdqc02': call to zoneadmd failed
Seen on Sunsolve if IPMP interfaces are on FAILED mode then none-global zones
may have trouble booting. Has this been fixed ?
Thanks
Roshan
----- Original Message -----
From: Mike Gerdts <[EMAIL PROTECTED]>
Date: Tuesday, October 17, 2006 6:59 pm
Subject: Re: [zones-discuss] Zones and VLAN tagging.
To: Roshan Perera <[EMAIL PROTECTED]>
Cc: [email protected]
> On 10/17/06, Roshan Perera <[EMAIL PROTECTED]> wrote:
> > Hi all,
> >
> > 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 separate NIC.
> >
> > 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.
>
> Mike
>
> --
> Mike Gerdts
> http://mgerdts.blogspot.com/
> _______________________________________________
> zones-discuss mailing list
> [email protected]
>
_______________________________________________
zones-discuss mailing list
[email protected]
