redirecting to crossbow-discuss... On 03/12/09 15:17, Andrew Gabriel wrote:> In snv_108, I''m playing with creating a vnic over an etherstub, and I > might not be doing it right, but the behaviour I''m seeing doesn''t look > right either. > > So this is what I did... > > # dladm create-etherstub estub0 > # dladm create-vnic -l estub0 vnic0 > # ifconfig vnic0 plumb > # ifconfig vnic0 192.168.128.1 netmask 255.255.255.0 broadcast + up > # > > That seems to work, and I had virtualbox also attach to vnic0 and > traffic passes through vnic0 OK. > > Then I reboot. I wasn''t expecting the interfaced to be plumbed > anymore, but I was expecting the vnic0 and estub0 to still be there. > They aren''t: > > # ifconfig vnic0 plumb > ifconfig: SIOCSLIFNAME for ip: vnic0: no such interface > # dladm show-etherstub > # dladm show-vnic > # > > Except maybe they are: > > # dladm create-etherstub estub0 > dladm: etherstub creation failed: object already exists > # dladm create-vnic -l estub0 vnic0 > dladm: vnic creation over estub0 failed: object already exists > # > > I can fortunately delete them and then recreate them. > > # dladm delete-etherstub estub0 > # dladm delete-vnic vnic0 > # > > (whereas if I try deleting estub1 or vnic1, neither of which I have > ever created, that gives an error as expected). > > So is this broken, or doesn''t it work like I think it should?it''s broken. everything that you did should work. i suspect that the #dladm up-vnic in the net-physical SMF service tried to create the vnic before the etherstub. there should probably be an error in the SMF log file. i can''t explain the missing entry in #dladm show-etherstub though. -mike
Michael Lim wrote:> redirecting to crossbow-discuss... > > On 03/12/09 15:17, Andrew Gabriel wrote: >> In snv_108, I''m playing with creating a vnic over an etherstub, and I >> might not be doing it right, but the behaviour I''m seeing doesn''t look >> right either. >> >> So this is what I did... >> >> # dladm create-etherstub estub0 >> # dladm create-vnic -l estub0 vnic0 >> # ifconfig vnic0 plumb >> # ifconfig vnic0 192.168.128.1 netmask 255.255.255.0 broadcast + up >> # >> >> That seems to work, and I had virtualbox also attach to vnic0 and >> traffic passes through vnic0 OK. >> >> Then I reboot. I wasn''t expecting the interfaced to be plumbed >> anymore, but I was expecting the vnic0 and estub0 to still be there. >> They aren''t: >> >> # ifconfig vnic0 plumb >> ifconfig: SIOCSLIFNAME for ip: vnic0: no such interface >> # dladm show-etherstub >> # dladm show-vnic >> # >> >> Except maybe they are: >> >> # dladm create-etherstub estub0 >> dladm: etherstub creation failed: object already exists >> # dladm create-vnic -l estub0 vnic0 >> dladm: vnic creation over estub0 failed: object already exists >> # >> >> I can fortunately delete them and then recreate them. >> >> # dladm delete-etherstub estub0 >> # dladm delete-vnic vnic0 >> # >> >> (whereas if I try deleting estub1 or vnic1, neither of which I have >> ever created, that gives an error as expected). >> >> So is this broken, or doesn''t it work like I think it should? > it''s broken. everything that you did should work. > > i suspect that the #dladm up-vnic in the net-physical SMF service tried to > create the vnic before the etherstub. there should probably be an error in > the SMF log file. > > i can''t explain the missing entry in #dladm show-etherstub though.To answer my own question, the fault is that if you are running NWAM, nothing during boot actually instantiates the persistent configuration for vnics and ethersubs (nor several other objects, by inspection of the start methods), so although the objects are in the persistent configuration, they never get loaded into the kernel. You can force the persistent configuration to be loaded by running # dladm up-vnic So I guess what I''m after is svc:/network/physical:nwam on some interfaces and svc:/network/physical:default on other interfaces. Would I be right in thinking NWAM is not configurable to this extent? -- Andrew
Sounds like CR 6798106 that we closed as we couldn''t reproduce? Andrew Gabriel wrote:> Michael Lim wrote: >> redirecting to crossbow-discuss... >> >> On 03/12/09 15:17, Andrew Gabriel wrote: >>> In snv_108, I''m playing with creating a vnic over an etherstub, and >>> I might not be doing it right, but the behaviour I''m seeing doesn''t >>> look right either. >>> >>> So this is what I did... >>> >>> # dladm create-etherstub estub0 >>> # dladm create-vnic -l estub0 vnic0 >>> # ifconfig vnic0 plumb >>> # ifconfig vnic0 192.168.128.1 netmask 255.255.255.0 broadcast + up >>> # >>> >>> That seems to work, and I had virtualbox also attach to vnic0 and >>> traffic passes through vnic0 OK. >>> >>> Then I reboot. I wasn''t expecting the interfaced to be plumbed >>> anymore, but I was expecting the vnic0 and estub0 to still be there. >>> They aren''t: >>> >>> # ifconfig vnic0 plumb >>> ifconfig: SIOCSLIFNAME for ip: vnic0: no such interface >>> # dladm show-etherstub >>> # dladm show-vnic >>> # >>> >>> Except maybe they are: >>> >>> # dladm create-etherstub estub0 >>> dladm: etherstub creation failed: object already exists >>> # dladm create-vnic -l estub0 vnic0 >>> dladm: vnic creation over estub0 failed: object already exists >>> # >>> >>> I can fortunately delete them and then recreate them. >>> >>> # dladm delete-etherstub estub0 >>> # dladm delete-vnic vnic0 >>> # >>> >>> (whereas if I try deleting estub1 or vnic1, neither of which I have >>> ever created, that gives an error as expected). >>> >>> So is this broken, or doesn''t it work like I think it should? >> it''s broken. everything that you did should work. >> >> i suspect that the #dladm up-vnic in the net-physical SMF service >> tried to >> create the vnic before the etherstub. there should probably be an >> error in >> the SMF log file. >> >> i can''t explain the missing entry in #dladm show-etherstub though. > > To answer my own question, the fault is that if you are running NWAM, > nothing during boot actually instantiates the persistent configuration > for vnics and ethersubs (nor several other objects, by inspection of > the start methods), so although the objects are in the persistent > configuration, they never get loaded into the kernel. > > You can force the persistent configuration to be loaded by running > > # dladm up-vnic > > So I guess what I''m after is svc:/network/physical:nwam on some > interfaces and svc:/network/physical:default on other interfaces. > Would I be right in thinking NWAM is not configurable to this extent? >
On Mar 12, 2009, at 5:10 PM, Shrikrishna Khare wrote:> > Sounds like CR 6798106 that we closed as we couldn''t reproduce?If the VNIC mentioned in that particular bug was previously created on an etherstub, and NWAM was enabled, then it could have been the same issue. But the bug didn''t mention anything about using etherstub, so it''s hard to tell for sure. Nicolas.> > > > Andrew Gabriel wrote: >> Michael Lim wrote: >>> redirecting to crossbow-discuss... >>> >>> On 03/12/09 15:17, Andrew Gabriel wrote: >>>> In snv_108, I''m playing with creating a vnic over an etherstub, >>>> and I might not be doing it right, but the behaviour I''m seeing >>>> doesn''t look right either. >>>> >>>> So this is what I did... >>>> >>>> # dladm create-etherstub estub0 >>>> # dladm create-vnic -l estub0 vnic0 >>>> # ifconfig vnic0 plumb >>>> # ifconfig vnic0 192.168.128.1 netmask 255.255.255.0 broadcast + up >>>> # >>>> >>>> That seems to work, and I had virtualbox also attach to vnic0 and >>>> traffic passes through vnic0 OK. >>>> >>>> Then I reboot. I wasn''t expecting the interfaced to be plumbed >>>> anymore, but I was expecting the vnic0 and estub0 to still be >>>> there. They aren''t: >>>> >>>> # ifconfig vnic0 plumb >>>> ifconfig: SIOCSLIFNAME for ip: vnic0: no such interface >>>> # dladm show-etherstub >>>> # dladm show-vnic >>>> # >>>> >>>> Except maybe they are: >>>> >>>> # dladm create-etherstub estub0 >>>> dladm: etherstub creation failed: object already exists >>>> # dladm create-vnic -l estub0 vnic0 >>>> dladm: vnic creation over estub0 failed: object already exists >>>> # >>>> >>>> I can fortunately delete them and then recreate them. >>>> >>>> # dladm delete-etherstub estub0 >>>> # dladm delete-vnic vnic0 >>>> # >>>> >>>> (whereas if I try deleting estub1 or vnic1, neither of which I >>>> have ever created, that gives an error as expected). >>>> >>>> So is this broken, or doesn''t it work like I think it should? >>> it''s broken. everything that you did should work. >>> >>> i suspect that the #dladm up-vnic in the net-physical SMF service >>> tried to >>> create the vnic before the etherstub. there should probably be an >>> error in >>> the SMF log file. >>> >>> i can''t explain the missing entry in #dladm show-etherstub though. >> >> To answer my own question, the fault is that if you are running >> NWAM, nothing during boot actually instantiates the persistent >> configuration for vnics and ethersubs (nor several other objects, >> by inspection of the start methods), so although the objects are in >> the persistent configuration, they never get loaded into the kernel. >> >> You can force the persistent configuration to be loaded by running >> >> # dladm up-vnic >> >> So I guess what I''m after is svc:/network/physical:nwam on some >> interfaces and svc:/network/physical:default on other interfaces. >> Would I be right in thinking NWAM is not configurable to this extent? >> > > _______________________________________________ > crossbow-discuss mailing list > crossbow-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/crossbow-discuss-- Nicolas Droux - Solaris Kernel Networking - Sun Microsystems, Inc. droux at sun.com - http://blogs.sun.com/droux
On Mar 12, 2009, at 4:56 PM, Andrew Gabriel wrote:> Michael Lim wrote: >> redirecting to crossbow-discuss... >> On 03/12/09 15:17, Andrew Gabriel wrote: >>> In snv_108, I''m playing with creating a vnic over an etherstub, >>> and I might not be doing it right, but the behaviour I''m seeing >>> doesn''t look right either. >>> >>> So this is what I did... >>> >>> # dladm create-etherstub estub0 >>> # dladm create-vnic -l estub0 vnic0 >>> # ifconfig vnic0 plumb >>> # ifconfig vnic0 192.168.128.1 netmask 255.255.255.0 broadcast + up >>> # >>> >>> That seems to work, and I had virtualbox also attach to vnic0 and >>> traffic passes through vnic0 OK. >>> >>> Then I reboot. I wasn''t expecting the interfaced to be plumbed >>> anymore, but I was expecting the vnic0 and estub0 to still be >>> there. They aren''t: >>> >>> # ifconfig vnic0 plumb >>> ifconfig: SIOCSLIFNAME for ip: vnic0: no such interface >>> # dladm show-etherstub >>> # dladm show-vnic >>> # >>> >>> Except maybe they are: >>> >>> # dladm create-etherstub estub0 >>> dladm: etherstub creation failed: object already exists >>> # dladm create-vnic -l estub0 vnic0 >>> dladm: vnic creation over estub0 failed: object already exists >>> # >>> >>> I can fortunately delete them and then recreate them. >>> >>> # dladm delete-etherstub estub0 >>> # dladm delete-vnic vnic0 >>> # >>> >>> (whereas if I try deleting estub1 or vnic1, neither of which I >>> have ever created, that gives an error as expected). >>> >>> So is this broken, or doesn''t it work like I think it should? >> it''s broken. everything that you did should work. >> i suspect that the #dladm up-vnic in the net-physical SMF service >> tried to >> create the vnic before the etherstub. there should probably be an >> error in >> the SMF log file. >> i can''t explain the missing entry in #dladm show-etherstub though. > > To answer my own question, the fault is that if you are running > NWAM, nothing during boot actually instantiates the persistent > configuration for vnics and ethersubs (nor several other objects, by > inspection of the start methods), so although the objects are in the > persistent configuration, they never get loaded into the kernel. > > You can force the persistent configuration to be loaded by running > > # dladm up-vnic > > So I guess what I''m after is svc:/network/physical:nwam on some > interfaces and svc:/network/physical:default on other interfaces. > Would I be right in thinking NWAM is not configurable to this extent?See 6776009 (nwam doesn''t bring up pseudo data-links at boot time.) Nicolas.> > > -- > Andrew > _______________________________________________ > crossbow-discuss mailing list > crossbow-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/crossbow-discuss-- Nicolas Droux - Solaris Kernel Networking - Sun Microsystems, Inc. droux at sun.com - http://blogs.sun.com/droux