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

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

Reply via email to