Skip to content
  • Leigh B Stoller's avatar
    Bug Fix: Fix how we determine the set of ports to tag/untag. · ad8ed130
    Leigh B Stoller authored
    The basic problem is that when snmpit looks to see what ports it
    should trunk (or untrunk) the equation is more complicated then it
    used to be.
    
    Case 1: In the old days, before shared nodes and shared lans, a node
    and its interfaces were always one-to-one with an experiment. So the
    set of trunks was easily derivable from the reserved table joined with
    the interfaces table.
    
    Case 2: But when we added shared nodes (with vlan encap of course),
    the set of trunk ports is no longer associated with the experiments
    using those ports, but only with the underlying experiment. That is we
    do not mess with the trunking when swapping experiments on shared
    nodes, we only want to add and subtract vlans to those trunked
    ports. So, I added a check against the reserved table. Easy. The ports
    are trunked when the underlying "shared nodes" experiment is swapped
    in, and untrunked when it is swapped out.
    
    Case 3: Then we added shared vlans. Well this is almost the exact
    opposite case. The ports belong to nodes in other experiments, but now
    we *do* want to consider them when turning trunking on and off. The
    underlying experiment that owns the lan (emulab-ops,openflow-vlans)
    does not own any of the ports, but we do want to enable/disable the
    trunking as ports come and go.
    
    Case 4: Last but certainly not least, is a potential bad interaction
    between these #2 and #3! The instageni-connect port is a member of the
    1750 shared vlan (and thus trunking is enabled when the openflow lan
    is created or modified). But that same port is also used in the second
    case above when stitching to the rack; The instageni-connect node is a
    shared node, and we allocate fake VMs on it that serve simply as a
    place to associate the vlans that use that port; we just want to add
    and subtract vlans to the port. ÊThe gist of this is that if someone
    were to remove the port from the shared 1750 vlan, its trunk would get
    turned off, and all of the stitched vlans would stop working.
    
    This bug fix deals with the addition of #3, but I do not have anything
    for #4.  But I can commit this fix with the understanding that
    #4 is a real problem that has to be dealt with.
    ad8ed130