Re: [Testbed-admins] nodes with no control interface

[Mike Hibler <mike@flux.utah.edu>]

[ Whoops! I seem to have taken this discussion "off line" briefly! ]

The 1Gb trunk between your new nodes and the rest of your infrastructure
is the problem.  We do conservative allocation of bandwidth, so if you have
more than 1Gb of aggregate specified bandwidth between HAIPE nodes and others,
it will not map.
 
On Mon, Mar 09, 2009 at 12:44:32PM -0700, Harley S Green wrote:
> Hi Mike,
> No nothing secure about the environment.
> Just didn't want to bog down everyone with lots of extra data. But now I 
> will :)
> 
> In my modifying the duplex-link to a "lan" I inadvertently changed the 
> bandwidth from 1Gig to 100M. It turns out that what causes the problem is 
> the link speed being set to 1Gig.
> I re-ran the experiments as duplex-link and lan, at the 100M speed, and 
> both worked. But when set to 1Gig it did not.
> 
> I'm not exactly sure why its causing this problem since all the nodes have 
> 1Gig capability.
> 
> I created three versions of the experiment and have included them in this 
> tar file, each directory has the experiment.ns which is the NS file and 
> then the output of doing the 
> /usr/testbed/libexec/assign_wrapper -n -v $pid $eid
> 
> One has the goal scenario which is a control node with a 1Gig link to each 
> of the HAIPE nodes, which does NOT assign properly.
> The next is the same scenario using 100M links, which does assign 
> properly.
> To show that the HAIPE nodes do support 1Gig link I included another which 
> has the two HAIPE nodes directly connected at 1Gig, which does assign 
> properly.
> 
> One possible cause is that we currently only have a 1Gig trunk between our 
> experimental cisco switch (cisco3) where the HAIPEs are connected, and our 
> other experimental switches (cisco1,2,4) where the pc nodes are connected. 
> 
> So maybe it does not like having two 1 Gig links going across at the same 
> time? Our other experimental switched have 10gig trunks, so we have not 
> run into this issue before with nodes directly connected to them.
> 
> Thanks for your help!
> 
> 
> 
> 
> Harley Green
> Network Systems Department
> The Aerospace Corporation
> (310) 336-0772
> 
> 
> 
> Mike Hibler <mike@flux.utah.edu> 
> 03/09/2009 11:07 AM
> 
> To
> Harley S Green <Harley.S.Green@aero.org>
> cc
> 
> Subject
> Re: [Testbed-admins] nodes with no control interface
> 
> 
> 
> 
> 
> 
> So you have two nodes with a "link" between them and you just changed
> the "duplex-link" to a "lan" without altering the shaping attributes
> (bandwidth, delay, loss)?
> 
> If the link had shaping attributes before, then the lan would as well and
> it would still need a delay node.  Unless you went from a shaped link to 
> an
> unshaped lan, in which case you should see if it works for an unshaped 
> link.
> 
> Is this a secure facility where you cannot send us any files or outputs?
> Having the NS file and the outputs of the command below would make this
> easier on both of us :-)
> 
> On Mon, Mar 09, 2009 at 10:49:24AM -0700, Harley S Green wrote:
> > I was able to resolve this problem by specifying the link between the 
> > nodes as a lan rather than a duplex-link.
> > I'm assuming this means there is an issue with assigning delay nodes.
> > Any thoughts on why using a lan versus link between the nodes would fix 
> > the issue?
> > 
> > 
> > 
> > Harley Green
> > Network Systems Department
> > The Aerospace Corporation
> > (310) 336-0772
> > 
> > 
> > 
> > Mike Hibler <mike@flux.utah.edu> 
> > 03/06/2009 08:06 AM
> > 
> > To
> > Harley S Green <Harley.S.Green@aero.org>
> > cc
> > testbed-admins@flux.utah.edu
> > Subject
> > Re: [Testbed-admins] nodes with no control interface
> > 
> > 
> > 
> > 
> > 
> > 
> > On Thu, Mar 05, 2009 at 05:10:14PM -0800, Harley S Green wrote:
> > > Greetings,
> > > I'm trying to add several nodes that have no control interface. They 
> > > simply have two experimental interfaces. Does the current version of 
> > > emulab allow for this?
> > > In other words, I've added everything for these nodes like other 
> custom 
> > > hardware like routers that we have. Except I did not create a control 
> > > interface for them in the database.
> > > When I got to swap them in I get an error saying it could not map the 
> > > nodes.
> > > 
> > > Failed to find a set of physical testbed nodes to run your experiment
> > > on. This might mean that there are not enough nodes or switch 
> resources
> > > free, or your experiment might require certain hardware which is not
> > > available.  If you believe this message is in error, contact
> > > testbed-ops@users2.sntb.aero.org.
> > > 
> > > However, I verified that the hardware I fixed it to in the NS file is 
> > the 
> > > name of the node I want. So I suspect since the only thing different 
> > that 
> > > I can see is that these nodes don't have a control interface that 
> maybe 
> > > emulab is looking for that and since it can't find it, it (emulab swap 
> 
> > in 
> > > process) dies... Is that correct?
> > > 
> > > Thanks,
> > > Harley Green
> > > Network Systems Department
> > > The Aerospace Corporation
> > > (310) 336-0772
> > 
> > While I don't know of anything off-hand, it is completely believable 
> that
> > there is a problem with not having a control interface.
> > 
> > Can you run this command on your boss node:
> > 
> >                  /usr/testbed/libexec/assign_wrapper -n -v $pid $eid
> > 
> > and send us the output as well as the .top and .ptop files it generates
> > (in the directory where you run the command)?
> > 
> 
> 
>