thr3ads.net - crossbow discuss - [crossbow-discuss] ?: stacktype: shares (for routing out of the box) [Aug 2006]

If this information is useful, please help other people find it:
Share via:

Steffen Weiberle

2006-Aug-30 21:49 UTC

[crossbow-discuss] ?: stacktype: shares (for routing out of the box)

One of the reasons I''m interested in the vnics is the ability to force 
traffic out of the system even if it is to another co-located zone.

I see there is an option to add a router entry for a zone. However, I 
get the following error:

zonecfg:zone1> add router
zonecfg:zone1:router> set address=10.1.14.129
zonecfg:zone1:router> end
zonecfg:zone1> verify
router: not allowed with a shared stack: address 10.1.14.129
zone1: Invalid argument
zonecfg:zone1> info
zonename: zone1
zonepath: /export/zones/zone1
autoboot: false
stacktype: shared
bootargs:
pool:
limitpriv:
inherit-pkg-dir:
         dir: /lib
inherit-pkg-dir:
         dir: /platform
inherit-pkg-dir:
         dir: /sbin
inherit-pkg-dir:
         dir: /usr
net:
         physical: vnic1
         address: 10.1.14.151/26
         af not specified
         restrict not specified
net:
         address: 10.1.14.129
zonecfg:zone1>


This is on an e1000g interface. Does this fail because of the same 
issue where I can''t set the MAC address? Which interfaces does this 
currently work on, besides bge? nge? hme? eri?

Thanks
Steffen

Nicolas Droux

2006-Aug-30 22:25 UTC

head link

[crossbow-discuss] ?: stacktype: shares (for routing out of the box)

Hi Steffen,

Steffen Weiberle wrote:> One of the reasons I''m interested in the vnics is the ability to
force
> traffic out of the system even if it is to another co-located zone.
> 
> I see there is an option to add a router entry for a zone. However, I 
> get the following error:
> 
> zonecfg:zone1> add router
> zonecfg:zone1:router> set address=10.1.14.129
> zonecfg:zone1:router> end
> zonecfg:zone1> verify
> router: not allowed with a shared stack: address 10.1.14.129
> zone1: Invalid argument
> zonecfg:zone1> info
> zonename: zone1
> zonepath: /export/zones/zone1
> autoboot: false
> stacktype: shared              ^^^^^^

It''s because the zone is sharing its stack with the global zone. Try 
setting stacktype=exclusive for that zone.

Nicolas.

-- 
Nicolas Droux, Solaris Kernel Networking
Sun Microsystems, Inc. http://blogs.sun.com/droux

Kais Belgaied

2006-Aug-30 22:39 UTC

head link

[crossbow-discuss] ?: stacktype: shares (for routing out of the box)

> > router: not allowed with a shared stack: address 10.1.14.129
> > zone1: Invalid argument
> > zonecfg:zone1> info
> > zonename: zone1
> > zonepath: /export/zones/zone1
> > autoboot: false
> > stacktype: shared
>               ^^^^^^
> 
> It''s because the zone is sharing its stack with the global zone.
Try
> setting stacktype=exclusive for that zone.
it may be worth mentioning for troubleshooting that zonenname -t
displays the type of zone (shared vs exclusive)

	Kais.

Kais Belgaied

2006-Aug-31 03:21 UTC

head link

[crossbow-discuss] ?: stacktype: shares (for routing out of the box)

>>
>> zonecfg:zone1> verify
>> router: not allowed with a shared stack: address 10.1.14.129
>> zone1: Invalid argument
>> zonecfg:zone1> info
>> zonename: zone1
>> zonepath: /export/zones/zone1
>> autoboot: false
>> stacktype: shared
>
>               ^^^^^^


it is also worth mentioning for ease of debugging here that zonenname -t 
can be used to display the
stack type (shared vs exclusive)

    Kais.

Steffen Weiberle

2006-Aug-31 17:09 UTC

head link

[crossbow-discuss] ?: stacktype: shared (for routing out of the box)

Ok, got that working. Thanks!

I found out that by having stacktype=exclusive, I must not ifconfig 
vnic1 or vnic2 in the GZ or the zones won''t boot. And once booted the 
vnics don''t show up in the GZ.

I am getting different results with my testing under difference 
circumstances.

So, first some questions on proper practice in bringing up the VNICs.

I have two interfaces. One (e1000g0) is on the public network, the 
other (e1000g3) is on a private network, and a Solaris 9 box is the 
router between the two, just in case.

Must I plumb e1000g3 to use VNICs? It doesn''t seem so, but should I? 
If so, must it have a valid address as well?

A zone reboot fails with:

Interface vnic2 is used by the non-global zone: zone2.
zoneadm: zone zone2 failed to verify

But I can halt the zone and then boot it.

Currently, e1000g3 is not plumbed.

I can not ping the router at .129 from either NGZ. I see arp requests 
and responses at the router on the proper interface, but neither NGZ 
gets them. I also see the request and reply via snoop in the GZ on the 
e1000g3 interface, so traffic is going out and coming back, just not 
getting delivered to the NGZs.

I can ping between NGZs, but traffic does not leave the system.

Below is some data, but I might be ending up with three different sets 
of datapoints, depending on whether the underlying interface is not 
plumbed, plumbed but not address, or plumbed and with address.


I do the following to bring up the VNICs

dladm create-vnic -d e1000g3 -i 10.1.14.151 -b 1000 1
dladm create-vnic -d e1000g3 -i 10.1.14.152 -b 1000 2

# zonecfg -z zone1 info
zonename: zone1
zonepath: /export/zones/zone1
autoboot: false
stacktype: exclusive
bootargs:
pool:
limitpriv:
inherit-pkg-dir:
         dir: /lib
inherit-pkg-dir:
         dir: /platform
inherit-pkg-dir:
         dir: /sbin
inherit-pkg-dir:
         dir: /usr
net:
         physical: vnic1
         address: 10.1.14.151/26
         af: inet
         restrict not specified
net:
         address: 10.1.14.129

Zone 2 is similar to zone 1 exect .152

Why the second ''net'', instead of ''router''?

Nicolas Droux

2006-Aug-31 18:26 UTC

head link

[crossbow-discuss] ?: stacktype: shared (for routing out of the box)

Hi Steffen,

Steffen Weiberle wrote:> Ok, got that working. Thanks!
> 
> I found out that by having stacktype=exclusive, I must not ifconfig 
> vnic1 or vnic2 in the GZ or the zones won''t boot. And once booted
the
> vnics don''t show up in the GZ.
Once the vnic is used by a non-global zone with an exclusive stack, it 
shouldn''t be used by the global zone. I''m not sure if all the
checks are
in place currently to enforce this.
> 
> I am getting different results with my testing under difference 
> circumstances.
> 
> So, first some questions on proper practice in bringing up the VNICs.
> 
> I have two interfaces. One (e1000g0) is on the public network, the other 
> (e1000g3) is on a private network, and a Solaris 9 box is the router 
> between the two, just in case.
> 
> Must I plumb e1000g3 to use VNICs? It doesn''t seem so, but should
I? If
> so, must it have a valid address as well?
Unfortunately at this point e1000g3 would have to be plumbed and 
configured as well. This is a known restriction and I''m looking into
it.
> 
> A zone reboot fails with:
> 
> Interface vnic2 is used by the non-global zone: zone2.
> zoneadm: zone zone2 failed to verify
Mmm, this is during a boot of zone2?
> 
> But I can halt the zone and then boot it.
> 
> Currently, e1000g3 is not plumbed.
> 
> I can not ping the router at .129 from either NGZ. I see arp requests 
> and responses at the router on the proper interface, but neither NGZ 
> gets them. I also see the request and reply via snoop in the GZ on the 
> e1000g3 interface, so traffic is going out and coming back, just not 
> getting delivered to the NGZs.
> 
> I can ping between NGZs, but traffic does not leave the system.
See above, try configuring the underlying interface.
> 
> Below is some data, but I might be ending up with three different sets 
> of datapoints, depending on whether the underlying interface is not 
> plumbed, plumbed but not address, or plumbed and with address.
> 
> 
> I do the following to bring up the VNICs
> 
> dladm create-vnic -d e1000g3 -i 10.1.14.151 -b 1000 1
> dladm create-vnic -d e1000g3 -i 10.1.14.152 -b 1000 2
> 
> # zonecfg -z zone1 info
> zonename: zone1
> zonepath: /export/zones/zone1
> autoboot: false
> stacktype: exclusive
> bootargs:
> pool:
> limitpriv:
> inherit-pkg-dir:
>         dir: /lib
> inherit-pkg-dir:
>         dir: /platform
> inherit-pkg-dir:
>         dir: /sbin
> inherit-pkg-dir:
>         dir: /usr
> net:
>         physical: vnic1
>         address: 10.1.14.151/26
>         af: inet
>         restrict not specified
> net:
>         address: 10.1.14.129
> 
> Zone 2 is similar to zone 1 exect .152
> 
> Why the second ''net'', instead of
''router''?
That looks like a bug.

Nicolas.

-- 
Nicolas Droux, Solaris Kernel Networking
Sun Microsystems, Inc. http://blogs.sun.com/droux

Kais Belgaied

2006-Aug-31 18:40 UTC

head link

[crossbow-discuss] ?: stacktype: shared (for routing out of the box)

Steffen Weiberle wrote:
>
> I do the following to bring up the VNICs
>
> dladm create-vnic -d e1000g3 -i 10.1.14.151 -b 1000 1
> dladm create-vnic -d e1000g3 -i 10.1.14.152 -b 1000 2

and what''s the output of ifconfig -a from the global zone?

    Kais.

Steffen Weiberle

2006-Aug-31 19:22 UTC

head link

[crossbow-discuss] ?: stacktype: shared (for routing out of the box)

Hi Kais,

Currently, with e1000g3 not plumbed, this is what it looks like. I 
will reboot and do this again with it configured per Nicolas'' 
suggestion (thanks Nicolas).

Steffen

tajmahal# ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 
8232 index 1
         inet 127.0.0.1 netmask ff000000
e1000g0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 
index 2
         inet 129.154.53.7 netmask ffffff00 broadcast 129.154.53.255
         ether 0:3:ba:d8:41:20
tajmahal# zlogin zone1 ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 
8232 index 1
         inet 127.0.0.1 netmask ff000000
vnic1: flags=1000803<UP,BROADCAST,MULTICAST,IPv4> mtu 1500 index 2
         inet 10.1.14.151 netmask ffffffc0 broadcast 10.1.14.191
         ether 0:3:ba:d8:41:1f
tajmahal# zlogin zone2 ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 
8232 index 1
         inet 127.0.0.1 netmask ff000000
vnic2: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
         inet 10.1.14.152 netmask ffffffc0 broadcast 10.1.14.191
         ether 0:3:ba:d8:41:1f
tajmahal#


Kais Belgaied wrote On 08/31/06 14:40,:> Steffen Weiberle wrote:
> 
>>
>> I do the following to bring up the VNICs
>>
>> dladm create-vnic -d e1000g3 -i 10.1.14.151 -b 1000 1
>> dladm create-vnic -d e1000g3 -i 10.1.14.152 -b 1000 2
> 
> 
> 
> and what''s the output of ifconfig -a from the global zone?
> 
>     Kais.
> 
> _______________________________________________
> crossbow-discuss mailing list
> crossbow-discuss at opensolaris.org
> http://opensolaris.org/mailman/listinfo/crossbow-discuss

Steffen Weiberle

2006-Aug-31 19:40 UTC

head link

[crossbow-discuss] ?: stacktype: shared (for routing out of the box)

Here it is after a reboot and setting up e1000g3 with an IP address. 
One thing I forgot to do was try ping()ing the router before setting 
up the VNICs.

Steffen

tajmahal# cat crossbow.sh
#!/bin/sh

ifconfig e1000g3 plumb
ifconfig e1000g3 10.1.14.150 netmask + broadcast + up

dladm create-vnic -d e1000g3 -i 10.1.14.151 -b 1000 1
dladm create-vnic -d e1000g3 -i 10.1.14.152 -b 1000 2
dladm show-vnic

zoneadm -z zone1 boot
zoneadm -z zone2 boot

tajmahal# ./crossbow.sh
Setting netmask of e1000g3 to 255.255.255.192
vnic1   dev: e1000g3    IP:  10.1.14.151
vnic0   dev:
tajmahal# ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 
8232 index 1
         inet 127.0.0.1 netmask ff000000
e1000g0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 
index 2
         inet 129.154.53.7 netmask ffffff00 broadcast 129.154.53.255
         ether 0:3:ba:d8:41:20
e1000g3: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 
index 3
         inet 10.1.14.150 netmask ffffffc0 broadcast 10.1.14.191
         ether 0:3:ba:d8:41:1f
tajmahal# zlogin zone1 ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 
8232 index 1
         inet 127.0.0.1 netmask ff000000
vnic1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
         inet 10.1.14.151 netmask ffffffc0 broadcast 10.1.14.191
         ether 0:3:ba:d8:41:1f
tajmahal# zlogin zone2 ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 
8232 index 1
         inet 127.0.0.1 netmask ff000000
vnic2: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
         inet 10.1.14.152 netmask ffffffc0 broadcast 10.1.14.191
         ether 0:3:ba:d8:41:1f
tajmahal# zlogin zone2 ping 10.1.14.151
10.1.14.151 is alive
tajmahal# zlogin zone1 ping 10.1.14.152
10.1.14.152 is alive
tajmahal# zlogin zone1 ping 10.1.14.129
no answer from 10.1.14.129
tajmahal# ping 10.1.14.129
no answer from 10.1.14.129
tajmahal# arp -a
Net to Media Table: IPv4
Device   IP Address               Mask      Flags   Phys Addr
------ -------------------- --------------- ----- ---------------
e1000g0 224.0.0.2            255.255.255.255       01:00:5e:00:00:02
e1000g3 224.0.0.2            255.255.255.255       01:00:5e:00:00:02
e1000g3 mtllab129.East.Sun.COM 255.255.255.255       08:00:20:1a:b7:b3
e1000g0 224.0.0.22           255.255.255.255       01:00:5e:00:00:16
e1000g3 224.0.0.22           255.255.255.255       01:00:5e:00:00:16
e1000g0 tajmahal             255.255.255.255 SP    00:03:ba:d8:41:20
e1000g3 mtllab150.East.Sun.COM 255.255.255.255 SP    00:03:ba:d8:41:1f
e1000g3 224.0.0.0            240.0.0.0       SM    01:00:5e:00:00:00
e1000g0 224.0.0.0            240.0.0.0       SM    01:00:5e:00:00:00
tajmahal#


Kais Belgaied wrote On 08/31/06 14:40,:> Steffen Weiberle wrote:
> 
>>
>> I do the following to bring up the VNICs
>>
>> dladm create-vnic -d e1000g3 -i 10.1.14.151 -b 1000 1
>> dladm create-vnic -d e1000g3 -i 10.1.14.152 -b 1000 2
> 
> 
> 
> and what''s the output of ifconfig -a from the global zone?
> 
>     Kais.
> 
> _______________________________________________
> crossbow-discuss mailing list
> crossbow-discuss at opensolaris.org
> http://opensolaris.org/mailman/listinfo/crossbow-discuss

Steffen Weiberle

2006-Aug-31 22:41 UTC

head link

[crossbow-discuss] ?: stacktype: shared (for routing out of the box)

I have verified that I can ping the router before adding the VNICs. 
Once in place, the GZ can not ping the router, and the router can not 
ping the GZ. I also can not ping between the GZ and a NGZ on the same 
subnet.

arp entries are not getting populated, and possibly the entry in the 
GZ for the router early on expires.

Steffen


Here it is after a reboot and setting up e1000g3 with an IP address.
One thing I forgot to do was try ping()ing the router before setting
up the VNICs.

Steffen

tajmahal# cat crossbow.sh
#!/bin/sh

ifconfig e1000g3 plumb
ifconfig e1000g3 10.1.14.150 netmask + broadcast + up

dladm create-vnic -d e1000g3 -i 10.1.14.151 -b 1000 1
dladm create-vnic -d e1000g3 -i 10.1.14.152 -b 1000 2
dladm show-vnic

zoneadm -z zone1 boot
zoneadm -z zone2 boot

tajmahal# ./crossbow.sh
Setting netmask of e1000g3 to 255.255.255.192
vnic1   dev: e1000g3    IP:  10.1.14.151
vnic0   dev:
tajmahal# ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu
8232 index 1
         inet 127.0.0.1 netmask ff000000
e1000g0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500
index 2
         inet 129.154.53.7 netmask ffffff00 broadcast 129.154.53.255
         ether 0:3:ba:d8:41:20
e1000g3: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500
index 3
         inet 10.1.14.150 netmask ffffffc0 broadcast 10.1.14.191
         ether 0:3:ba:d8:41:1f
tajmahal# zlogin zone1 ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu
8232 index 1
         inet 127.0.0.1 netmask ff000000
vnic1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
         inet 10.1.14.151 netmask ffffffc0 broadcast 10.1.14.191
         ether 0:3:ba:d8:41:1f
tajmahal# zlogin zone2 ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu
8232 index 1
         inet 127.0.0.1 netmask ff000000
vnic2: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
         inet 10.1.14.152 netmask ffffffc0 broadcast 10.1.14.191
         ether 0:3:ba:d8:41:1f
tajmahal# zlogin zone2 ping 10.1.14.151
10.1.14.151 is alive
tajmahal# zlogin zone1 ping 10.1.14.152
10.1.14.152 is alive
tajmahal# zlogin zone1 ping 10.1.14.129
no answer from 10.1.14.129
tajmahal# ping 10.1.14.129
no answer from 10.1.14.129
tajmahal# arp -a
Net to Media Table: IPv4
Device   IP Address               Mask      Flags   Phys Addr
------ -------------------- --------------- ----- ---------------
e1000g0 224.0.0.2            255.255.255.255       01:00:5e:00:00:02
e1000g3 224.0.0.2            255.255.255.255       01:00:5e:00:00:02
e1000g3 mtllab129.East.Sun.COM 255.255.255.255       08:00:20:1a:b7:b3
e1000g0 224.0.0.22           255.255.255.255       01:00:5e:00:00:16
e1000g3 224.0.0.22           255.255.255.255       01:00:5e:00:00:16
e1000g0 tajmahal             255.255.255.255 SP    00:03:ba:d8:41:20
e1000g3 mtllab150.East.Sun.COM 255.255.255.255 SP    00:03:ba:d8:41:1f
e1000g3 224.0.0.0            240.0.0.0       SM    01:00:5e:00:00:00
e1000g0 224.0.0.0            240.0.0.0       SM    01:00:5e:00:00:00
tajmahal#


Kais Belgaied wrote On 08/31/06 14:40,:> Steffen Weiberle wrote:
> 
>>
>> I do the following to bring up the VNICs
>>
>> dladm create-vnic -d e1000g3 -i 10.1.14.151 -b 1000 1
>> dladm create-vnic -d e1000g3 -i 10.1.14.152 -b 1000 2
> 
> 
> 
> and what''s the output of ifconfig -a from the global zone?
> 
>     Kais.
> 
> _______________________________________________
> crossbow-discuss mailing list
> crossbow-discuss at opensolaris.org
> http://opensolaris.org/mailman/listinfo/crossbow-discuss_______________________________________________
crossbow-discuss mailing list
crossbow-discuss at opensolaris.org
http://opensolaris.org/mailman/listinfo/crossbow-discuss

Nicolas Droux

2006-Sep-01 17:25 UTC

head link

[crossbow-discuss] ?: stacktype: shared (for routing out of the box)

Hi Steffen,

Steffen Weiberle wrote:> I have verified that I can ping the router before adding the VNICs. Once 
> in place, the GZ can not ping the router, and the router can not ping 
> the GZ. I also can not ping between the GZ and a NGZ on the same subnet.
If you want full connectivity between the GZ and the NGZ VNICs, you need 
to define a VNIC on e1000g3 and use it from the GZ.

So here''s what I''d suggest:

- configure a test address for e1000g3 instead of the current 10.1.14.150
- create a vnic3 interface, plumb it and configure it with address 
10.1.14.150 from the GZ
- now you should have connectivity between the GZ and the NGZ through 
the VNICs.

Let me know if that works better for you.

The VNICs based on IP addresses have gone through very minimal testing, 
and will see a significant rewack in the future. Our next code drop will 
make defining VNICs with their own MAC addresses possible even on NICs 
which don''t have multiple unicast MAC address support, which would help
for cases like this.

Nicolas.


> 
> arp entries are not getting populated, and possibly the entry in the GZ 
> for the router early on expires.
> 
> Steffen
> 
> 
> Here it is after a reboot and setting up e1000g3 with an IP address.
> One thing I forgot to do was try ping()ing the router before setting
> up the VNICs.
> 
> Steffen
> 
> tajmahal# cat crossbow.sh
> #!/bin/sh
> 
> ifconfig e1000g3 plumb
> ifconfig e1000g3 10.1.14.150 netmask + broadcast + up
> 
> dladm create-vnic -d e1000g3 -i 10.1.14.151 -b 1000 1
> dladm create-vnic -d e1000g3 -i 10.1.14.152 -b 1000 2
> dladm show-vnic
> 
> zoneadm -z zone1 boot
> zoneadm -z zone2 boot
> 
> tajmahal# ./crossbow.sh
> Setting netmask of e1000g3 to 255.255.255.192
> vnic1   dev: e1000g3    IP:  10.1.14.151
> vnic0   dev:
> tajmahal# ifconfig -a
> lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu
> 8232 index 1
>         inet 127.0.0.1 netmask ff000000
> e1000g0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500
> index 2
>         inet 129.154.53.7 netmask ffffff00 broadcast 129.154.53.255
>         ether 0:3:ba:d8:41:20
> e1000g3: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500
> index 3
>         inet 10.1.14.150 netmask ffffffc0 broadcast 10.1.14.191
>         ether 0:3:ba:d8:41:1f
> tajmahal# zlogin zone1 ifconfig -a
> lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu
> 8232 index 1
>         inet 127.0.0.1 netmask ff000000
> vnic1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500
index 2
>         inet 10.1.14.151 netmask ffffffc0 broadcast 10.1.14.191
>         ether 0:3:ba:d8:41:1f
> tajmahal# zlogin zone2 ifconfig -a
> lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu
> 8232 index 1
>         inet 127.0.0.1 netmask ff000000
> vnic2: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500
index 2
>         inet 10.1.14.152 netmask ffffffc0 broadcast 10.1.14.191
>         ether 0:3:ba:d8:41:1f
> tajmahal# zlogin zone2 ping 10.1.14.151
> 10.1.14.151 is alive
> tajmahal# zlogin zone1 ping 10.1.14.152
> 10.1.14.152 is alive
> tajmahal# zlogin zone1 ping 10.1.14.129
> no answer from 10.1.14.129
> tajmahal# ping 10.1.14.129
> no answer from 10.1.14.129
> tajmahal# arp -a
> Net to Media Table: IPv4
> Device   IP Address               Mask      Flags   Phys Addr
> ------ -------------------- --------------- ----- ---------------
> e1000g0 224.0.0.2            255.255.255.255       01:00:5e:00:00:02
> e1000g3 224.0.0.2            255.255.255.255       01:00:5e:00:00:02
> e1000g3 mtllab129.East.Sun.COM 255.255.255.255       08:00:20:1a:b7:b3
> e1000g0 224.0.0.22           255.255.255.255       01:00:5e:00:00:16
> e1000g3 224.0.0.22           255.255.255.255       01:00:5e:00:00:16
> e1000g0 tajmahal             255.255.255.255 SP    00:03:ba:d8:41:20
> e1000g3 mtllab150.East.Sun.COM 255.255.255.255 SP    00:03:ba:d8:41:1f
> e1000g3 224.0.0.0            240.0.0.0       SM    01:00:5e:00:00:00
> e1000g0 224.0.0.0            240.0.0.0       SM    01:00:5e:00:00:00
> tajmahal#
> 
> 
> Kais Belgaied wrote On 08/31/06 14:40,:
> 
>> Steffen Weiberle wrote:
>>
>>>
>>> I do the following to bring up the VNICs
>>>
>>> dladm create-vnic -d e1000g3 -i 10.1.14.151 -b 1000 1
>>> dladm create-vnic -d e1000g3 -i 10.1.14.152 -b 1000 2
>>
>>
>>
>>
>> and what''s the output of ifconfig -a from the global zone?
>>
>>     Kais.
>>
>> _______________________________________________
>> crossbow-discuss mailing list
>> crossbow-discuss at opensolaris.org
>> http://opensolaris.org/mailman/listinfo/crossbow-discuss
> 
> _______________________________________________
> crossbow-discuss mailing list
> crossbow-discuss at opensolaris.org
> http://opensolaris.org/mailman/listinfo/crossbow-discuss
> _______________________________________________
> crossbow-discuss mailing list
> crossbow-discuss at opensolaris.org
> http://opensolaris.org/mailman/listinfo/crossbow-discuss
-- 
Nicolas Droux, Solaris Kernel Networking
Sun Microsystems, Inc. http://blogs.sun.com/droux

Steffen Weiberle

2006-Sep-01 17:55 UTC

head link

[crossbow-discuss] ?: stacktype: shared (for routing out of the box)

Thanks, Nicolas, I will give this a try. Since my goal is to force 
inter-zone traffic out of the box, even if the zones are on the same 
subnet, will this be sufficient and work, or

1. the features to do that are not there yet,

2. need to use different NICs,

3. won''t work if they are on the same subnet, or

4. something else I haven''t thought of?

All the other features that come with virtualization are nice, but the 
short term issue for me is getting inter-zone traffic onto the wire. 
Reasons include snooping and firewalling, which I know will be 
addressed in other projects, but there is at least one case where the 
firewall must be external.

Thanks
Steffen

Nicolas Droux wrote On 09/01/06 13:25,:> Hi Steffen,
> 
> Steffen Weiberle wrote:
> 
>> I have verified that I can ping the router before adding the VNICs. 
>> Once in place, the GZ can not ping the router, and the router can not 
>> ping the GZ. I also can not ping between the GZ and a NGZ on the same 
>> subnet.
> 
> 
> If you want full connectivity between the GZ and the NGZ VNICs, you need 
> to define a VNIC on e1000g3 and use it from the GZ.
> 
> So here''s what I''d suggest:
> 
> - configure a test address for e1000g3 instead of the current 10.1.14.150
> - create a vnic3 interface, plumb it and configure it with address 
> 10.1.14.150 from the GZ
> - now you should have connectivity between the GZ and the NGZ through 
> the VNICs.
> 
> Let me know if that works better for you.
> 
> The VNICs based on IP addresses have gone through very minimal testing, 
> and will see a significant rewack in the future. Our next code drop will 
> make defining VNICs with their own MAC addresses possible even on NICs 
> which don''t have multiple unicast MAC address support, which would
help
> for cases like this.
> 
> Nicolas.
> 
> 
> 
>>
>> arp entries are not getting populated, and possibly the entry in the 
>> GZ for the router early on expires.
>>
>> Steffen
>>
>>
>> Here it is after a reboot and setting up e1000g3 with an IP address.
>> One thing I forgot to do was try ping()ing the router before setting
>> up the VNICs.
>>
>> Steffen
>>
>> tajmahal# cat crossbow.sh
>> #!/bin/sh
>>
>> ifconfig e1000g3 plumb
>> ifconfig e1000g3 10.1.14.150 netmask + broadcast + up
>>
>> dladm create-vnic -d e1000g3 -i 10.1.14.151 -b 1000 1
>> dladm create-vnic -d e1000g3 -i 10.1.14.152 -b 1000 2
>> dladm show-vnic
>>
>> zoneadm -z zone1 boot
>> zoneadm -z zone2 boot
>>
>> tajmahal# ./crossbow.sh
>> Setting netmask of e1000g3 to 255.255.255.192
>> vnic1   dev: e1000g3    IP:  10.1.14.151
>> vnic0   dev:
>> tajmahal# ifconfig -a
>> lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL>
mtu
>> 8232 index 1
>>         inet 127.0.0.1 netmask ff000000
>> e1000g0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu
1500
>> index 2
>>         inet 129.154.53.7 netmask ffffff00 broadcast 129.154.53.255
>>         ether 0:3:ba:d8:41:20
>> e1000g3: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu
1500
>> index 3
>>         inet 10.1.14.150 netmask ffffffc0 broadcast 10.1.14.191
>>         ether 0:3:ba:d8:41:1f
>> tajmahal# zlogin zone1 ifconfig -a
>> lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL>
mtu
>> 8232 index 1
>>         inet 127.0.0.1 netmask ff000000
>> vnic1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu
1500
>> index 2
>>         inet 10.1.14.151 netmask ffffffc0 broadcast 10.1.14.191
>>         ether 0:3:ba:d8:41:1f
>> tajmahal# zlogin zone2 ifconfig -a
>> lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL>
mtu
>> 8232 index 1
>>         inet 127.0.0.1 netmask ff000000
>> vnic2: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu
1500
>> index 2
>>         inet 10.1.14.152 netmask ffffffc0 broadcast 10.1.14.191
>>         ether 0:3:ba:d8:41:1f
>> tajmahal# zlogin zone2 ping 10.1.14.151
>> 10.1.14.151 is alive
>> tajmahal# zlogin zone1 ping 10.1.14.152
>> 10.1.14.152 is alive
>> tajmahal# zlogin zone1 ping 10.1.14.129
>> no answer from 10.1.14.129
>> tajmahal# ping 10.1.14.129
>> no answer from 10.1.14.129
>> tajmahal# arp -a
>> Net to Media Table: IPv4
>> Device   IP Address               Mask      Flags   Phys Addr
>> ------ -------------------- --------------- ----- ---------------
>> e1000g0 224.0.0.2            255.255.255.255       01:00:5e:00:00:02
>> e1000g3 224.0.0.2            255.255.255.255       01:00:5e:00:00:02
>> e1000g3 mtllab129.East.Sun.COM 255.255.255.255       08:00:20:1a:b7:b3
>> e1000g0 224.0.0.22           255.255.255.255       01:00:5e:00:00:16
>> e1000g3 224.0.0.22           255.255.255.255       01:00:5e:00:00:16
>> e1000g0 tajmahal             255.255.255.255 SP    00:03:ba:d8:41:20
>> e1000g3 mtllab150.East.Sun.COM 255.255.255.255 SP    00:03:ba:d8:41:1f
>> e1000g3 224.0.0.0            240.0.0.0       SM    01:00:5e:00:00:00
>> e1000g0 224.0.0.0            240.0.0.0       SM    01:00:5e:00:00:00
>> tajmahal#
>>
>>
>> Kais Belgaied wrote On 08/31/06 14:40,:
>>
>>> Steffen Weiberle wrote:
>>>
>>>>
>>>> I do the following to bring up the VNICs
>>>>
>>>> dladm create-vnic -d e1000g3 -i 10.1.14.151 -b 1000 1
>>>> dladm create-vnic -d e1000g3 -i 10.1.14.152 -b 1000 2
>>>
>>>
>>>
>>>
>>>
>>> and what''s the output of ifconfig -a from the global zone?
>>>
>>>     Kais.
>>>
>>> _______________________________________________
>>> crossbow-discuss mailing list
>>> crossbow-discuss at opensolaris.org
>>> http://opensolaris.org/mailman/listinfo/crossbow-discuss
>>
>>
>> _______________________________________________
>> crossbow-discuss mailing list
>> crossbow-discuss at opensolaris.org
>> http://opensolaris.org/mailman/listinfo/crossbow-discuss
>> _______________________________________________
>> crossbow-discuss mailing list
>> crossbow-discuss at opensolaris.org
>> http://opensolaris.org/mailman/listinfo/crossbow-discuss
> 
>

Erik Nordmark

2006-Sep-01 21:56 UTC

head link

[crossbow-discuss] Re: ?: stacktype: shared (for routing out of the box)

> Thanks, Nicolas, I will give this a try. Since my goal is to force
> inter-zone traffic out of the box, even if the zones are on the same
> subnet, will this be sufficient and work, or
> 
> 1. the features to do that are not there yet,
> 
> 2. need to use different NICs,
> 
> 3. won''t work if they are on the same subnet, or
> 
> 4. something else I haven''t thought of?
> 
> All the other features that come with virtualization are nice, but the
> short term issue for me is getting inter-zone traffic onto the wire.
> Reasons include snooping and firewalling, which I know will be
> addressed in other projects, but there is at least one case where the
> firewall must be external.
Why do you need to have the zones on the same subnet?

What I know works is this (at least when using MAC address based VNICs - I
haven''t tried with IP address based VNICs.)
You use different IP subnets for the zones that need to go via the firewall.
Each zone has a default router in its subnet.
Thus when the zones try to communicate with each other they will send packets to
their firewall. Those packets will go out on the wire.

If you are going to use the same subnet number, and you are not going to use
different VLANs, then you would have to use different physical NICs. But in this
case the zones would ARP for each other, and the packets would go out on the
wire but the Ethernet switch/bridge would send them to the port on which is the
other NIC. Thus unless your firewall is in your Ethernet switch it
wouldn''t help.

    Erik
 
 
This message posted from opensolaris.org

Nicolas Droux

2006-Sep-02 00:00 UTC

head link

[crossbow-discuss] ?: stacktype: shared (for routing out of the box)

Hi Steffen,

Steffen Weiberle wrote:> Thanks, Nicolas, I will give this a try. Since my goal is to force 
> inter-zone traffic out of the box, even if the zones are on the same 
> subnet, will this be sufficient and work, or
It should allow the zones to communicate to the rest of the network.
> 
> 1. the features to do that are not there yet,
> 
> 2. need to use different NICs,
> 
> 3. won''t work if they are on the same subnet, or
> 
> 4. something else I haven''t thought of?
If it still doesn''t work, it''s most likely due to a problem
with the
IP-based VNICs, which were not fully tested and will undergo major 
changes in the future.

The ideal, for now, would be to use a bge interface which will allow you 
to configure VNICs with their own MAC address. Our next release will 
make that possible for e1000g NICs as well.

I fixed the remaining problems with VNICs just last week to enable the 
scenario you are interested in, i.e. communication between zones using 
VNICs, as well as communication to the outside of the box from these VNICs.

Nicolas.
> 
> All the other features that come with virtualization are nice, but the 
> short term issue for me is getting inter-zone traffic onto the wire. 
> Reasons include snooping and firewalling, which I know will be addressed 
> in other projects, but there is at least one case where the firewall 
> must be external.
> 
> Thanks
> Steffen
> 
> Nicolas Droux wrote On 09/01/06 13:25,:
> 
>> Hi Steffen,
>>
>> Steffen Weiberle wrote:
>>
>>> I have verified that I can ping the router before adding the VNICs.
>>> Once in place, the GZ can not ping the router, and the router can
not
>>> ping the GZ. I also can not ping between the GZ and a NGZ on the
same
>>> subnet.
>>
>>
>>
>> If you want full connectivity between the GZ and the NGZ VNICs, you 
>> need to define a VNIC on e1000g3 and use it from the GZ.
>>
>> So here''s what I''d suggest:
>>
>> - configure a test address for e1000g3 instead of the current
10.1.14.150
>> - create a vnic3 interface, plumb it and configure it with address 
>> 10.1.14.150 from the GZ
>> - now you should have connectivity between the GZ and the NGZ through 
>> the VNICs.
>>
>> Let me know if that works better for you.
>>
>> The VNICs based on IP addresses have gone through very minimal 
>> testing, and will see a significant rewack in the future. Our next 
>> code drop will make defining VNICs with their own MAC addresses 
>> possible even on NICs which don''t have multiple unicast MAC
address
>> support, which would help for cases like this.
>>
>> Nicolas.
>>
>>
>>
>>>
>>> arp entries are not getting populated, and possibly the entry in
the
>>> GZ for the router early on expires.
>>>
>>> Steffen
>>>
>>>
>>> Here it is after a reboot and setting up e1000g3 with an IP
address.
>>> One thing I forgot to do was try ping()ing the router before
setting
>>> up the VNICs.
>>>
>>> Steffen
>>>
>>> tajmahal# cat crossbow.sh
>>> #!/bin/sh
>>>
>>> ifconfig e1000g3 plumb
>>> ifconfig e1000g3 10.1.14.150 netmask + broadcast + up
>>>
>>> dladm create-vnic -d e1000g3 -i 10.1.14.151 -b 1000 1
>>> dladm create-vnic -d e1000g3 -i 10.1.14.152 -b 1000 2
>>> dladm show-vnic
>>>
>>> zoneadm -z zone1 boot
>>> zoneadm -z zone2 boot
>>>
>>> tajmahal# ./crossbow.sh
>>> Setting netmask of e1000g3 to 255.255.255.192
>>> vnic1   dev: e1000g3    IP:  10.1.14.151
>>> vnic0   dev:
>>> tajmahal# ifconfig -a
>>> lo0:
flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu
>>> 8232 index 1
>>>         inet 127.0.0.1 netmask ff000000
>>> e1000g0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4>
mtu 1500
>>> index 2
>>>         inet 129.154.53.7 netmask ffffff00 broadcast 129.154.53.255
>>>         ether 0:3:ba:d8:41:20
>>> e1000g3: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4>
mtu 1500
>>> index 3
>>>         inet 10.1.14.150 netmask ffffffc0 broadcast 10.1.14.191
>>>         ether 0:3:ba:d8:41:1f
>>> tajmahal# zlogin zone1 ifconfig -a
>>> lo0:
flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu
>>> 8232 index 1
>>>         inet 127.0.0.1 netmask ff000000
>>> vnic1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu
1500
>>> index 2
>>>         inet 10.1.14.151 netmask ffffffc0 broadcast 10.1.14.191
>>>         ether 0:3:ba:d8:41:1f
>>> tajmahal# zlogin zone2 ifconfig -a
>>> lo0:
flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu
>>> 8232 index 1
>>>         inet 127.0.0.1 netmask ff000000
>>> vnic2: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu
1500
>>> index 2
>>>         inet 10.1.14.152 netmask ffffffc0 broadcast 10.1.14.191
>>>         ether 0:3:ba:d8:41:1f
>>> tajmahal# zlogin zone2 ping 10.1.14.151
>>> 10.1.14.151 is alive
>>> tajmahal# zlogin zone1 ping 10.1.14.152
>>> 10.1.14.152 is alive
>>> tajmahal# zlogin zone1 ping 10.1.14.129
>>> no answer from 10.1.14.129
>>> tajmahal# ping 10.1.14.129
>>> no answer from 10.1.14.129
>>> tajmahal# arp -a
>>> Net to Media Table: IPv4
>>> Device   IP Address               Mask      Flags   Phys Addr
>>> ------ -------------------- --------------- ----- ---------------
>>> e1000g0 224.0.0.2            255.255.255.255      
01:00:5e:00:00:02
>>> e1000g3 224.0.0.2            255.255.255.255      
01:00:5e:00:00:02
>>> e1000g3 mtllab129.East.Sun.COM 255.255.255.255      
08:00:20:1a:b7:b3
>>> e1000g0 224.0.0.22           255.255.255.255      
01:00:5e:00:00:16
>>> e1000g3 224.0.0.22           255.255.255.255      
01:00:5e:00:00:16
>>> e1000g0 tajmahal             255.255.255.255 SP   
00:03:ba:d8:41:20
>>> e1000g3 mtllab150.East.Sun.COM 255.255.255.255 SP   
00:03:ba:d8:41:1f
>>> e1000g3 224.0.0.0            240.0.0.0       SM   
01:00:5e:00:00:00
>>> e1000g0 224.0.0.0            240.0.0.0       SM   
01:00:5e:00:00:00
>>> tajmahal#
>>>
>>>
>>> Kais Belgaied wrote On 08/31/06 14:40,:
>>>
>>>> Steffen Weiberle wrote:
>>>>
>>>>>
>>>>> I do the following to bring up the VNICs
>>>>>
>>>>> dladm create-vnic -d e1000g3 -i 10.1.14.151 -b 1000 1
>>>>> dladm create-vnic -d e1000g3 -i 10.1.14.152 -b 1000 2
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> and what''s the output of ifconfig -a from the global
zone?
>>>>
>>>>     Kais.
>>>>
>>>> _______________________________________________
>>>> crossbow-discuss mailing list
>>>> crossbow-discuss at opensolaris.org
>>>> http://opensolaris.org/mailman/listinfo/crossbow-discuss
>>>
>>>
>>>
>>> _______________________________________________
>>> crossbow-discuss mailing list
>>> crossbow-discuss at opensolaris.org
>>> http://opensolaris.org/mailman/listinfo/crossbow-discuss
>>> _______________________________________________
>>> crossbow-discuss mailing list
>>> crossbow-discuss at opensolaris.org
>>> http://opensolaris.org/mailman/listinfo/crossbow-discuss
>>
>>
>>
> _______________________________________________
> crossbow-discuss mailing list
> crossbow-discuss at opensolaris.org
> http://opensolaris.org/mailman/listinfo/crossbow-discuss
-- 
Nicolas Droux, Solaris Kernel Networking
Sun Microsystems, Inc. http://blogs.sun.com/droux

Steffen Weiberle

2006-Sep-02 14:57 UTC

head link

[crossbow-discuss] Re: ?: stacktype: shared (for routing out of the box)

Erik Nordmark wrote On 09/01/06 17:56,:>>Thanks, Nicolas, I will give this a try. Since my goal is to force
>>inter-zone traffic out of the box, even if the zones are on the same
>>subnet, will this be sufficient and work, or
>>
>>1. the features to do that are not there yet,
>>
>>2. need to use different NICs,
>>
>>3. won''t work if they are on the same subnet, or
>>
>>4. something else I haven''t thought of?
>>
>>All the other features that come with virtualization are nice, but the
>>short term issue for me is getting inter-zone traffic onto the wire.
>>Reasons include snooping and firewalling, which I know will be
>>addressed in other projects, but there is at least one case where the
>>firewall must be external.
> 
> 
> Why do you need to have the zones on the same subnet?
1. I am able to test with only one, besides the office network (OK, 
not a really good reason :) )

2. This is how at least some customers do multiple tiers, especially 
on internal networks. Seriously. I am trying to simulate one 
customer''s configuration that has been deployed with the understanding 
that the current networking setup would send traffic out of the box. Ouch!
> 
> What I know works is this (at least when using MAC address based VNICs - I
haven''t tried with IP address based VNICs.)
> You use different IP subnets for the zones that need to go via the
firewall. Each zone has a default router in its subnet.
> Thus when the zones try to communicate with each other they will send
packets to their firewall. Those packets will go out on the wire.
> 
> If you are going to use the same subnet number, and you are not going to
use different VLANs, then you would have to use different physical NICs. But in
this case the zones would ARP for each other, and the packets would go out on
the wire but the Ethernet switch/bridge would send them to the port on which is
the other NIC. Thus unless your firewall is in your Ethernet switch it
wouldn''t help.
Some good points. This shows the need for some best practices and 
setting of expectation of what virtual NICs will and will not be able 
to provide.

Thanks
Steffen
> 
>     Erik
>  
>  
> This message posted from opensolaris.org
> _______________________________________________
> crossbow-discuss mailing list
> crossbow-discuss at opensolaris.org
> http://opensolaris.org/mailman/listinfo/crossbow-discuss

Steffen Weiberle

2006-Sep-02 14:58 UTC

head link

[crossbow-discuss] ?: stacktype: shared (for routing out of the box)

Nicolas Droux wrote On 09/01/06 20:00,:> Hi Steffen,
> 
> Steffen Weiberle wrote:
> 
>> Thanks, Nicolas, I will give this a try. Since my goal is to force 
>> inter-zone traffic out of the box, even if the zones are on the same 
>> subnet, will this be sufficient and work, or
> 
> It should allow the zones to communicate to the rest of the network.
> 
>> 1. the features to do that are not there yet,
>>
>> 2. need to use different NICs,
>>
>> 3. won''t work if they are on the same subnet, or
>>
>> 4. something else I haven''t thought of?
> 
> If it still doesn''t work, it''s most likely due to a
problem with the
> IP-based VNICs, which were not fully tested and will undergo major 
> changes in the future.
> 
> The ideal, for now, would be to use a bge interface which will allow you 
> to configure VNICs with their own MAC address. Our next release will 
> make that possible for e1000g NICs as well.
> 
> I fixed the remaining problems with VNICs just last week to enable the 
> scenario you are interested in, i.e. communication between zones using 
> VNICs, as well as communication to the outside of the box from these VNICs.
Thanks. I am definitely going to have to find a system with a bge 
interface in the meantime!

Thanks
Steffen
> 
> Nicolas.
> 
>>
>> All the other features that come with virtualization are nice, but the 
>> short term issue for me is getting inter-zone traffic onto the wire. 
>> Reasons include snooping and firewalling, which I know will be 
>> addressed in other projects, but there is at least one case where the 
>> firewall must be external.
>>
>> Thanks
>> Steffen
>>
>> Nicolas Droux wrote On 09/01/06 13:25,:
>>
>>> Hi Steffen,
>>>
>>> Steffen Weiberle wrote:
>>>
>>>> I have verified that I can ping the router before adding the
VNICs.
>>>> Once in place, the GZ can not ping the router, and the router
can
>>>> not ping the GZ. I also can not ping between the GZ and a NGZ
on the
>>>> same subnet.
>>>
>>>
>>>
>>>
>>> If you want full connectivity between the GZ and the NGZ VNICs, you
>>> need to define a VNIC on e1000g3 and use it from the GZ.
>>>
>>> So here''s what I''d suggest:
>>>
>>> - configure a test address for e1000g3 instead of the current 
>>> 10.1.14.150
>>> - create a vnic3 interface, plumb it and configure it with address 
>>> 10.1.14.150 from the GZ
>>> - now you should have connectivity between the GZ and the NGZ
through
>>> the VNICs.
>>>
>>> Let me know if that works better for you.
>>>
>>> The VNICs based on IP addresses have gone through very minimal 
>>> testing, and will see a significant rewack in the future. Our next 
>>> code drop will make defining VNICs with their own MAC addresses 
>>> possible even on NICs which don''t have multiple unicast
MAC address
>>> support, which would help for cases like this.
>>>
>>> Nicolas.
>>>
>>>
>>>
>>>>
>>>> arp entries are not getting populated, and possibly the entry
in the
>>>> GZ for the router early on expires.
>>>>
>>>> Steffen
>>>>
>>>>
>>>> Here it is after a reboot and setting up e1000g3 with an IP
address.
>>>> One thing I forgot to do was try ping()ing the router before
setting
>>>> up the VNICs.
>>>>
>>>> Steffen
>>>>
>>>> tajmahal# cat crossbow.sh
>>>> #!/bin/sh
>>>>
>>>> ifconfig e1000g3 plumb
>>>> ifconfig e1000g3 10.1.14.150 netmask + broadcast + up
>>>>
>>>> dladm create-vnic -d e1000g3 -i 10.1.14.151 -b 1000 1
>>>> dladm create-vnic -d e1000g3 -i 10.1.14.152 -b 1000 2
>>>> dladm show-vnic
>>>>
>>>> zoneadm -z zone1 boot
>>>> zoneadm -z zone2 boot
>>>>
>>>> tajmahal# ./crossbow.sh
>>>> Setting netmask of e1000g3 to 255.255.255.192
>>>> vnic1   dev: e1000g3    IP:  10.1.14.151
>>>> vnic0   dev:
>>>> tajmahal# ifconfig -a
>>>> lo0:
flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu
>>>> 8232 index 1
>>>>         inet 127.0.0.1 netmask ff000000
>>>> e1000g0:
flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500
>>>> index 2
>>>>         inet 129.154.53.7 netmask ffffff00 broadcast
129.154.53.255
>>>>         ether 0:3:ba:d8:41:20
>>>> e1000g3:
flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500
>>>> index 3
>>>>         inet 10.1.14.150 netmask ffffffc0 broadcast 10.1.14.191
>>>>         ether 0:3:ba:d8:41:1f
>>>> tajmahal# zlogin zone1 ifconfig -a
>>>> lo0:
flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu
>>>> 8232 index 1
>>>>         inet 127.0.0.1 netmask ff000000
>>>> vnic1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4>
mtu 1500
>>>> index 2
>>>>         inet 10.1.14.151 netmask ffffffc0 broadcast 10.1.14.191
>>>>         ether 0:3:ba:d8:41:1f
>>>> tajmahal# zlogin zone2 ifconfig -a
>>>> lo0:
flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu
>>>> 8232 index 1
>>>>         inet 127.0.0.1 netmask ff000000
>>>> vnic2: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4>
mtu 1500
>>>> index 2
>>>>         inet 10.1.14.152 netmask ffffffc0 broadcast 10.1.14.191
>>>>         ether 0:3:ba:d8:41:1f
>>>> tajmahal# zlogin zone2 ping 10.1.14.151
>>>> 10.1.14.151 is alive
>>>> tajmahal# zlogin zone1 ping 10.1.14.152
>>>> 10.1.14.152 is alive
>>>> tajmahal# zlogin zone1 ping 10.1.14.129
>>>> no answer from 10.1.14.129
>>>> tajmahal# ping 10.1.14.129
>>>> no answer from 10.1.14.129
>>>> tajmahal# arp -a
>>>> Net to Media Table: IPv4
>>>> Device   IP Address               Mask      Flags   Phys Addr
>>>> ------ -------------------- --------------- -----
---------------
>>>> e1000g0 224.0.0.2            255.255.255.255      
01:00:5e:00:00:02
>>>> e1000g3 224.0.0.2            255.255.255.255      
01:00:5e:00:00:02
>>>> e1000g3 mtllab129.East.Sun.COM 255.255.255.255      
08:00:20:1a:b7:b3
>>>> e1000g0 224.0.0.22           255.255.255.255      
01:00:5e:00:00:16
>>>> e1000g3 224.0.0.22           255.255.255.255      
01:00:5e:00:00:16
>>>> e1000g0 tajmahal             255.255.255.255 SP   
00:03:ba:d8:41:20
>>>> e1000g3 mtllab150.East.Sun.COM 255.255.255.255 SP   
00:03:ba:d8:41:1f
>>>> e1000g3 224.0.0.0            240.0.0.0       SM   
01:00:5e:00:00:00
>>>> e1000g0 224.0.0.0            240.0.0.0       SM   
01:00:5e:00:00:00
>>>> tajmahal#
>>>>
>>>>
>>>> Kais Belgaied wrote On 08/31/06 14:40,:
>>>>
>>>>> Steffen Weiberle wrote:
>>>>>
>>>>>>
>>>>>> I do the following to bring up the VNICs
>>>>>>
>>>>>> dladm create-vnic -d e1000g3 -i 10.1.14.151 -b 1000 1
>>>>>> dladm create-vnic -d e1000g3 -i 10.1.14.152 -b 1000 2
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> and what''s the output of ifconfig -a from the
global zone?
>>>>>
>>>>>     Kais.
>>>>>
>>>>> _______________________________________________
>>>>> crossbow-discuss mailing list
>>>>> crossbow-discuss at opensolaris.org
>>>>> http://opensolaris.org/mailman/listinfo/crossbow-discuss
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> crossbow-discuss mailing list
>>>> crossbow-discuss at opensolaris.org
>>>> http://opensolaris.org/mailman/listinfo/crossbow-discuss
>>>> _______________________________________________
>>>> crossbow-discuss mailing list
>>>> crossbow-discuss at opensolaris.org
>>>> http://opensolaris.org/mailman/listinfo/crossbow-discuss
>>>
>>>
>>>
>>>
>> _______________________________________________
>> crossbow-discuss mailing list
>> crossbow-discuss at opensolaris.org
>> http://opensolaris.org/mailman/listinfo/crossbow-discuss
> 
>

crossbow discuss - Aug 2006 - ?: stacktype: shares (for routing out of the box)

[crossbow-discuss] ?: stacktype: shares (for routing out of the box)

[crossbow-discuss] ?: stacktype: shares (for routing out of the box)

[crossbow-discuss] ?: stacktype: shares (for routing out of the box)

[crossbow-discuss] ?: stacktype: shares (for routing out of the box)

[crossbow-discuss] ?: stacktype: shared (for routing out of the box)

[crossbow-discuss] ?: stacktype: shared (for routing out of the box)

[crossbow-discuss] ?: stacktype: shared (for routing out of the box)

[crossbow-discuss] ?: stacktype: shared (for routing out of the box)

[crossbow-discuss] ?: stacktype: shared (for routing out of the box)

[crossbow-discuss] ?: stacktype: shared (for routing out of the box)

[crossbow-discuss] ?: stacktype: shared (for routing out of the box)

[crossbow-discuss] ?: stacktype: shared (for routing out of the box)

[crossbow-discuss] Re: ?: stacktype: shared (for routing out of the box)

[crossbow-discuss] ?: stacktype: shared (for routing out of the box)

[crossbow-discuss] Re: ?: stacktype: shared (for routing out of the box)

[crossbow-discuss] ?: stacktype: shared (for routing out of the box)