search

RENCI-NRIG / orca5

ORCA5 Software
Eclipse Public License 1.0
2 stars 1 forks source link

Inter-rack slice with stitching port does not show manifest correctly in Flukes #133

Open YufengXin opened 7 years ago

YufengXin commented 7 years ago
  1. It shows correctly, if the VM ends are at the same rack as the stitching port is defined.
  2. inter-rack P2P (TS2-9) : one VM node at PSC, one stitching port on the bbnNet ----> shows disconnected links on the ION node. (RDF file: ts-2-9)
  3. inter-rack MP: one VM at Ciena, one VM at WSU, one sttichngport on the bonnet ---> shows a double link between the stitching port and the bonnet node. (RDF file: mp-st-2)

@ibaldin would you pls modify the attached manifest files to make them show correctly at Flukes, then I will try to generate the right RDF accordingly? I tried manually modifying the RDF, but could not make them work.

The inter-rack MP case maybe useful because the two VM branches show correctly.

ts-2-9.rdf.txt ts-2-9-manifest.rdf.txt mp-st-2.rdf.txt mp-st-2-manifest.rdf.txt

ibaldin commented 7 years ago

OK, I have to apologize - the Flukes version that supposedly had the NdlPath fix actually did not - I ignored POM version dependencies when rebuilding Flukes. Now that I'm using the actual test version, the ts-2-9 case displays correctly with no changes. So I can deploy this version of Flukes as production and things should work.

For mp-st-2 case above things aren't quite as rosy. It displays the following figure: screen shot 2017-05-18 at 1 51 04 pm

I'm investigating.

YufengXin commented 7 years ago

Thanks,

Please deploy it. I can play with it by manually modifying the manifest.

-Yufeng

On May 18, 2017, at 1:52 PM, Ilya Baldin notifications@github.com wrote:

OK, I have to apologize - the Flukes version that supposedly had the NdlPath fix actually did not - I ignored POM version dependencies when rebuilding Flukes. Now that I'm using the actual test version, the ts-2-9 case displays correctly with no changes. So I can deploy this version of Flukes as production and things should work.

For mp-st-2 case above things aren't quite as rosy. It displays the following figure: https://cloud.githubusercontent.com/assets/12304033/26216213/4493ae6a-3bd1-11e7-9b4d-228e9ad63674.png I'm investigating.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/RENCI-NRIG/orca5/issues/133#issuecomment-302489694, or mute the thread https://github.com/notifications/unsubscribe-auth/AHPA5hUP2tusj5KwDEvFprTRl2Xq0vcLks5r7IV2gaJpZM4Nbxqz.

ibaldin commented 7 years ago

Done (same location)

Try it on the ts-2-9 first. If it works for that, it's the right version.

ibaldin commented 7 years ago

Per discussion with @YufengXin we are going to leave the version of flukes in the 'new' configuration and Yufeng will work to get rid of unnecessary / interfaces on stitchport and VLAN entities that are confusing the pathfinding logic.

ibaldin commented 7 years ago

Should I update the 'production' version of Flukes to this as well, or not?

ibaldin commented 7 years ago

This has to do with extra / interfaces that provide an incorrect path from stitchport to node. @YufengXin is looking at possible solutions.

hinchliff commented 6 years ago

Some additional examples from Paul:

simple.stitchport.manifest.txt

simple stitchport screenshot

modify.stitchport.manifest.txt

modify stitchport screenshot

hinchliff commented 6 years ago

I'm not sure if this is relevant to the problem, but in the mp-st-2 manifest, the wsuNet/Domain/vlan and the cienaNet/Domain/vlan both have three hasInterface statements, while the bbnNet/Domain/vlan (connected to the stitchport) only has two hasInterface statements.

wsuNet:

  <rdf:Description rdf:about="http://geni-orca.renci.org/owl/wsuNet.rdf#wsuNet/Domain/vlan/726cbd9b-6438-48f8-94fb-2d4f4323d476/vlan">
    <rdf:type rdf:resource="http://geni-orca.renci.org/owl/topology.owl#CrossConnect"/>
    <j.8:inDomain rdf:resource="http://geni-orca.renci.org/owl/wsuNet.rdf#wsuNet/Domain/vlan"/>
    <j.8:message>Reservation 6ca34019-2a11-4834-8c06-faad3410d7f4 (Slice mp-st-2) is in state [Active,None]
</j.8:message>
    <j.8:hasReservationState rdf:resource="http://geni-orca.renci.org/owl/request.owl#Active"/>
    <j.13:hasURL>http://geni-orca.renci.org/owl/wsuNet.rdf#wsuNet/Domain/vlan/726cbd9b-6438-48f8-94fb-2d4f4323d476/vlan</j.13:hasURL>
    <j.13:hasInterface rdf:resource="http://geni-orca.renci.org/owl/6c952985-efad-46ad-a216-59a078f130a5#VLAN3-Node2/0/intf"/>
    <j.13:hasInterface rdf:resource="http://geni-orca.renci.org/owl/wsuNet.rdf#wsuNet/IBM/G8264/TenGigabitEthernet/ExoGeni/2/ethernet"/>
    <j.13:hasInterface rdf:resource="http://geni-orca.renci.org/owl/wsuNet.rdf#wsuNet/IBM/G8264/TenGigabitEthernet/1/0/ethernet"/>
    <j.6:bandwidth rdf:datatype="http://www.w3.org/2001/XMLSchema#integer">10000000</j.6:bandwidth>
    <j.10:hasResourceType rdf:resource="http://geni-orca.renci.org/owl/domain.owl#VLAN"/>
    <j.1:inRequestNetworkConnection rdf:resource="http://geni-orca.renci.org/owl/6c952985-efad-46ad-a216-59a078f130a5#VLAN3"/>
    <j.13:inConnection rdf:datatype="http://www.w3.org/2001/XMLSchema#boolean">true</j.13:inConnection>
    <rdfs:label>1821</rdfs:label>
  </rdf:Description>

bbnNet:

  <rdf:Description rdf:about="http://geni-orca.renci.org/owl/bbnNet.rdf#bbnNet/Domain/vlan/aa36c306-9b86-4135-919b-fb9a8a5f5aa4/vlan">
    <rdf:type rdf:resource="http://geni-orca.renci.org/owl/topology.owl#CrossConnect"/>
    <j.8:inDomain rdf:resource="http://geni-orca.renci.org/owl/bbnNet.rdf#bbnNet/Domain/vlan"/>
    <j.8:message>Reservation dcdf3fa5-8680-4f85-9f08-47cd218b0cdf (Slice mp-st-2) is in state [Active,None]
</j.8:message>
    <j.8:hasReservationState rdf:resource="http://geni-orca.renci.org/owl/request.owl#Active"/>
    <j.13:hasURL>http://geni-orca.renci.org/owl/bbnNet.rdf#bbnNet/Domain/vlan/aa36c306-9b86-4135-919b-fb9a8a5f5aa4/vlan</j.13:hasURL>
    <j.13:hasInterface rdf:resource="http://geni-orca.renci.org/owl/bbnNet.rdf#BbnNet/IBM/G8052/GigabitEthernet/1/1/ethernet/2400"/>
    <j.13:hasInterface rdf:resource="http://geni-orca.renci.org/owl/bbnNet.rdf#BbnNet/IBM/G8052/GigabitEthernet/1/0/ethernet"/>
    <j.6:bandwidth rdf:datatype="http://www.w3.org/2001/XMLSchema#integer">10000000</j.6:bandwidth>
    <j.10:hasResourceType rdf:resource="http://geni-orca.renci.org/owl/domain.owl#VLAN"/>
    <j.1:inRequestNetworkConnection rdf:resource="http://geni-orca.renci.org/owl/6c952985-efad-46ad-a216-59a078f130a5#VLAN3"/>
    <j.13:inConnection rdf:datatype="http://www.w3.org/2001/XMLSchema#boolean">true</j.13:inConnection>
    <rdfs:label>2400</rdfs:label>
  </rdf:Description>

The same potential discrepancy is exhibited in the simple.stitchport.manifest.txt file too.

Should VLANs connected to StitchPorts have three hasInterface statements?

hinchliff commented 6 years ago

There are two things that I have been looking at, the hasInterface statements on Net domain VLAN statements, like the comment above; and hasInterface statements in the Stitchport device topology statements. Making sure these extra hasInterface statements exist seem to improve the graph connectivity, but also seem to introduce 'doubled' links.

In the TS2-9 case, there is still the problem where it seems to be random whether or not the Stitchport will be connected to the rest of the graph.

mp-st-2

I modified the provided mp-st-2-manifest to include the third hasInterface statement, as shown below in the diff output.

mp-st-2-manifest-modified

*** 1643,1661 ****
    <rdf:Description rdf:about="http://geni-orca.renci.org/owl/bbnNet.rdf#bbnNet/Domain/vlan/aa36c306-9b86-4135-919b-fb9a8a5f5aa4/vlan">
      <rdf:type rdf:resource="http://geni-orca.renci.org/owl/topology.owl#CrossConnect"/>
      <j.8:inDomain rdf:resource="http://geni-orca.renci.org/owl/bbnNet.rdf#bbnNet/Domain/vlan"/>
      <j.8:message>Reservation dcdf3fa5-8680-4f85-9f08-47cd218b0cdf (Slice mp-st-2) is in state [Active,None]
  </j.8:message>
      <j.8:hasReservationState rdf:resource="http://geni-orca.renci.org/owl/request.owl#Active"/>
      <j.13:hasURL>http://geni-orca.renci.org/owl/bbnNet.rdf#bbnNet/Domain/vlan/aa36c306-9b86-4135-919b-fb9a8a5f5aa4/vlan</j.13:hasURL>
      <j.13:hasInterface rdf:resource="http://geni-orca.renci.org/owl/bbnNet.rdf#BbnNet/IBM/G8052/GigabitEthernet/1/1/ethernet/2400"/>
      <j.13:hasInterface rdf:resource="http://geni-orca.renci.org/owl/bbnNet.rdf#BbnNet/IBM/G8052/GigabitEthernet/1/0/ethernet"/>
-     <j.13:hasInterface rdf:resource="http://geni-orca.renci.org/owl/orca.rdf#592972d7-67a7-4702-9f6a-5cfc783a24e7/Stitching/Domain/intf"/>
      <j.6:bandwidth rdf:datatype="http://www.w3.org/2001/XMLSchema#integer">10000000</j.6:bandwidth>
      <j.10:hasResourceType rdf:resource="http://geni-orca.renci.org/owl/domain.owl#VLAN"/>
      <j.1:inRequestNetworkConnection rdf:resource="http://geni-orca.renci.org/owl/6c952985-efad-46ad-a216-59a078f130a5#VLAN3"/>
      <j.13:inConnection rdf:datatype="http://www.w3.org/2001/XMLSchema#boolean">true</j.13:inConnection>
      <rdfs:label>2400</rdfs:label>
    </rdf:Description>

simple.stitchport

I modified the provided simple.stitchport.manifest to include the extra hasInterface statement for the Stitchport device, as shown below in the diff output.

simple stitchport manifest modified

*** 2057,2065 ****
    <rdf:Description rdf:about="http://geni-orca.renci.org/owl/7e263185-2a7b-4a42-93fd-ef5c72c6d496#StitchPort0">
      <rdf:type rdf:resource="http://geni-orca.renci.org/owl/topology.owl#Device"/>
      <j.3:inDomain rdf:resource="http://geni-orca.renci.org/owl/orca.rdf#f910c80f-24bc-49d8-89d1-60ed4f722186/Stitching/Domain"/>
      <j.16:hasInterface rdf:resource="http://geni-orca.renci.org/owl/ion.rdf#AL2S/Chameleon/Cisco/6509/GigabitEthernet/1/1/3299"/>
-     <j.16:hasInterface rdf:resource="http://geni-orca.renci.org/owl/orca.rdf#f910c80f-24bc-49d8-89d1-60ed4f722186/Stitching/Domain/intf"/>
      <j.16:hasGUID>03a3261d-f9ad-4b82-9137-809b4698ab05</j.16:hasGUID>
      <j.16:hasURL>http://geni-orca.renci.org/owl/orca.rdf#Stitching/Domain</j.16:hasURL>
      <j.11:inRequestNetworkConnection rdf:resource="http://geni-orca.renci.org/owl/7e263185-2a7b-4a42-93fd-ef5c72c6d496#Link0"/>
      <j.16:inConnection rdf:datatype="http://www.w3.org/2001/XMLSchema#boolean">true</j.16:inConnection>

TS2-9

I started writing a test case that looks at the manifest. I print out the manifest into temp files, so that I can review them in flukes. This is two consecutive runs of the test case, with the same code, producing manifest that are effectively the same, but with different random GUIDs, etc.

As you can see, in one case the graph/Stitchport is fully connected, and in one case it is not. It is potentially interesting that there is no 'double' link in evidence, as there is in the simple-stitchport example.

TS2-9.rdf-manifest-6561746094323557689.rdf.txt ts2-9_1

  <rdf:Description rdf:about="http://geni-orca.renci.org/owl/5f4e1c51-acf8-4376-a4c6-840e115df525#StitchPort0">
    <rdf:type rdf:resource="http://geni-orca.renci.org/owl/topology.owl#Device"/>
    <j.2:inDomain rdf:resource="http://geni-orca.renci.org/owl/orca.rdf#858247f1-8554-457e-85e7-2fd7e5b63f73/Stitching/Domain"/>
    <j.13:hasInterface rdf:resource="http://geni-orca.renci.org/owl/ion.rdf#AL2S/Chameleon/Cisco/6509/GigabitEthernet/1/1/3292"/>
    <j.13:hasInterface rdf:resource="http://geni-orca.renci.org/owl/orca.rdf#858247f1-8554-457e-85e7-2fd7e5b63f73/Stitching/Domain/intf"/>
    <j.13:hasGUID>81034d72-b712-4204-85c0-592b0e0c4496</j.13:hasGUID>
    <j.13:hasURL>http://geni-orca.renci.org/owl/orca.rdf#Stitching/Domain</j.13:hasURL>
    <j.9:inRequestNetworkConnection rdf:resource="http://geni-orca.renci.org/owl/5f4e1c51-acf8-4376-a4c6-840e115df525#Link9"/>
    <j.13:inConnection rdf:datatype="http://www.w3.org/2001/XMLSchema#boolean">true</j.13:inConnection>
  </rdf:Description>

TS2-9.rdf-manifest-5450746101034930766.rdf.txt ts2-9_2

  <rdf:Description rdf:about="http://geni-orca.renci.org/owl/5f4e1c51-acf8-4376-a4c6-840e115df525#StitchPort0">
    <rdf:type rdf:resource="http://geni-orca.renci.org/owl/topology.owl#Device"/>
    <j.2:inDomain rdf:resource="http://geni-orca.renci.org/owl/orca.rdf#78cc0e36-719c-4cfc-b355-beca733a5632/Stitching/Domain"/>
    <j.13:hasInterface rdf:resource="http://geni-orca.renci.org/owl/ion.rdf#AL2S/Chameleon/Cisco/6509/GigabitEthernet/1/1/3292"/>
    <j.13:hasInterface rdf:resource="http://geni-orca.renci.org/owl/orca.rdf#78cc0e36-719c-4cfc-b355-beca733a5632/Stitching/Domain/intf"/>
    <j.13:hasGUID>81034d72-b712-4204-85c0-592b0e0c4496</j.13:hasGUID>
    <j.13:hasURL>http://geni-orca.renci.org/owl/orca.rdf#Stitching/Domain</j.13:hasURL>
    <j.9:inRequestNetworkConnection rdf:resource="http://geni-orca.renci.org/owl/5f4e1c51-acf8-4376-a4c6-840e115df525#Link9"/>
    <j.13:inConnection rdf:datatype="http://www.w3.org/2001/XMLSchema#boolean">true</j.13:inConnection>
  </rdf:Description>
ibaldin commented 6 years ago

Need to check by running Flukes in Eclipse to see how the structure of manifest can be changed to be properly connected [Ilya]

ibaldin commented 6 years ago

There are two cases - when stitchport is defined in XXXNet site vs when it is defined directly on ION.

ibaldin commented 6 years ago

So the issue appears to be the structure of a path to stitchport vs a structure of the path to regular node. It isn't wrong in either case, but it is different. I have code that after the path is reconstructed out of RDF entities (it includes, nodes and links) walks the sequence throwing away links and connecting the nodes). In the case of node-to-node path I can simply skip every other step without checking and it works. In the case of a stichport there seems to be an extra element that needs to be skipped. I need to look closer and talk to Yufeng to make sure my fix is correct, but this should be a straightforward fix within Flukes without messing with ORCA code.

ibaldin commented 6 years ago

Example node-to node path:

Path (len: 9) node - http://geni-orca.renci.org/owl/rciNet.rdf#rciNet/Domain/vlan/d8e192d7-ebae-4f92-a643-0cfb80344ddf/vlan link - http://geni-orca.renci.org/owl/rciNet.rdf#RciNet/IBM/G8264/TenGigabitEthernet/1/0/ethernet-Renci/Cisco/6509/TenGigabitEthernet/3/6/ethernet/ec3cd17c-01d4-4b8b-b4e2-f26bce1feee0 node - http://geni-orca.renci.org/owl/ben.rdf#ben/Domain/vlan/b23af89e-20ae-4117-9e4d-fdddb4f50fa1/vlan link - http://geni-orca.renci.org/owl/ben-6509.rdf#Renci/Cisco/6509/TenGigabitEthernet/3/2/fiber-NLR/DD/Juniper/QFX3500/xe/0/0/0/fiber/ab17e02a-e0ea-48ad-84f5-c12cfb966f70 node - http://geni-orca.renci.org/owl/nlr.rdf#nlr/Domain/vlan/e5445c94-ecf2-4a4b-9c43-3badb88c531a/vlan link - http://geni-orca.renci.org/owl/nlr.rdf#NLR/DD/Juniper/QFX3500/xe/0/0/1/ethernet-ION/DD/Cisco/6509/TenGigabitEthernet/1/2/ethernet/4bbadc34-2fa9-4314-99d6-8c49dd1ab4e0 node - http://geni-orca.renci.org/owl/ion.rdf#ion/Domain/vlan/bea2c0c7-0d05-49a4-8e2a-3a58f5223bce/vlan link - http://geni-orca.renci.org/owl/ion.rdf#AL2S/tamuNet/Cisco/6509/TengigabitEthernet/1/1/ethernet-tamuNet/IBM/G8264/TenGigabitEthernet/1/0/ethernet/8efa44b4-a2bc-4e36-9877-0268c1beecc7 node - http://geni-orca.renci.org/owl/tamuNet.rdf#tamuNet/Domain/vlan/9c28f4e8-6174-4b80-a571-c2084678b93c/vlan

Example node to stitchport path:

Path (len: 4)

node - http://geni-orca.renci.org/owl/7e263185-2a7b-4a42-93fd-ef5c72c6d496#StitchPort0 node - http://geni-orca.renci.org/owl/ion.rdf#ion/Domain/vlan/b3d08360-79f1-4682-8fa8-e7144401e4f9/vlan link - http://geni-orca.renci.org/owl/uflNet.rdf#UFLNet/IBM/G8052/TenGigabitEthernet/1/0/ethernet-ION/UFLNet/Cisco/6509/TenGigabitEthernet/1/1/ethernet/9ad15a79-c5ef-4f54-a173-9b038dc453a3 node - http://geni-orca.renci.org/owl/uflNet.rdf#uflNet/Domain/vlan/acd2c837-56a7-4d23-a6d6-1e4b871d0d12/vlan

hinchliff commented 6 years ago

This was fixed in RENCI-NRIG/flukes#15

ibaldin commented 6 years ago

For mp-st-2-manifest.rdf.txt Flukes fails to properly derive a path from VLAN3 to the stitchport:

DEBUG - Network Connection Path: http://geni-orca.renci.org/owl/6c952985-efad-46ad-a216-59a078f130a5#VLAN3
DEBUG - Printing roots
DEBUG - http://geni-orca.renci.org/owl/6c952985-efad-46ad-a216-59a078f130a5#VLAN3
DEBUG - Printing paths
DEBUG -    Path (len: 5) http://geni-orca.renci.org/owl/cienaNet.rdf#cienaNet/Domain/vlan/9012931d-400c-4211-8af3-2c115d524f20/vlan http://geni-orca.renci.org/owl/ion.rdf#AL2S/cienaNet/Cisco/6509/TenGigabitEthernet/1/1/ethernet-CIENANet/IBM/G8264/TenGigabitEthernet/1/0/ethernet/cbf7d50c-a8ae-4fb7-adf4-a6cb6773c653 http://geni-orca.renci.org/owl/ion.rdf#ion/Domain/vlan/8656151e-279e-4f09-9fb1-a82f37fdb61b/vlan http://geni-orca.renci.org/owl/nlr.rdf#NLR/DD/Juniper/QFX3500/xe/0/0/1/ethernet-ION/DD/Cisco/6509/TenGigabitEthernet/1/2/ethernet/6898da86-be34-42ed-b861-e907785858f0 http://geni-orca.renci.org/owl/6c952985-efad-46ad-a216-59a078f130a5#VLAN3 

DEBUG -    Path (len: 3) http://geni-orca.renci.org/owl/6c952985-efad-46ad-a216-59a078f130a5#StitchPort0 http://geni-orca.renci.org/owl/bbnNet.rdf#BbnNet/IBM/G8052/GigabitEthernet/1/1/ethernet/2400-592972d7-67a7-4702-9f6a-5cfc783a24e7/Stitching/Domain/intf/b909e069-5d6d-46fd-a2f0-de82eac07b54 http://geni-orca.renci.org/owl/6c952985-efad-46ad-a216-59a078f130a5#VLAN3 

DEBUG -    Path (len: 5) http://geni-orca.renci.org/owl/wsuNet.rdf#wsuNet/Domain/vlan/726cbd9b-6438-48f8-94fb-2d4f4323d476/vlan http://geni-orca.renci.org/owl/ion.rdf#AL2S/wsuNet/Cisco/6509/TengigabitEthernet/1/1/ethernet-wsuNet/IBM/G8264/TenGigabitEthernet/1/0/ethernet/35a401cb-cfe9-4365-86c9-dd5e0c567ae8 http://geni-orca.renci.org/owl/ion.rdf#ion/Domain/vlan/1028b829-9920-4d76-83d1-73e75897e996/vlan http://geni-orca.renci.org/owl/nlr.rdf#NLR/DD/Juniper/QFX3500/xe/0/0/1/ethernet-ION/DD/Cisco/6509/TenGigabitEthernet/1/2/ethernet/6898da86-be34-42ed-b861-e907785858f0 http://geni-orca.renci.org/owl/6c952985-efad-46ad-a216-59a078f130a5#VLAN3

Notice path to Stitchport is only of length 3 and it skips the ion node completely. I'm looking at the path logic under orca.ndl to see if it can be fixed easily, but this is a model problem.

ibaldin commented 6 years ago

There are two problems with mp-st-2-manifest.rdf.txt (which is a request with three-way broadcast link, one of which is a StitchPort in a bbnNet domain)

If I remove that interface (comment out in the manifest), then the manifest can be displayed almost correctly, if I undo the change in RENCI-NRIG/flukes#15. The reason for that is, unlike the comment above showing a stitchport path being stitchport-node-link-node-link-node, in this case the path from stitchport is the proper sequence stitchport-link-node-link-node-link-node-link-node .

node - http://geni-orca.renci.org/owl/6c952985-efad-46ad-a216-59a078f130a5#StitchPort0 link - http://geni-orca.renci.org/owl/bbnNet.rdf#BbnNet/IBM/G8052/GigabitEthernet/1/1/ethernet/2400-592972d7-67a7-4702-9f6a-5cfc783a24e7/Stitching/Domain/intf/b909e069-5d6d-46fd-a2f0-de82eac07b54 node - http://geni-orca.renci.org/owl/bbnNet.rdf#bbnNet/Domain/vlan/aa36c306-9b86-4135-919b-fb9a8a5f5aa4/vlan link - http://geni-orca.renci.org/owl/ion.rdf#AL2S/BBN/Juniper/MX/TenGigabitEthernet/1/1/ethernet-BbnNet/IBM/G8052/GigabitEthernet/1/0/ethernet/049190e5-ed20-4bbd-ab18-c7b3b6709a72 node - http://geni-orca.renci.org/owl/ion.rdf#ion/Domain/vlan/55b3b3e1-ab12-4903-a8cb-0b4aa6bc4620/vlan link - http://geni-orca.renci.org/owl/nlr.rdf#NLR/DD/Juniper/QFX3500/xe/0/0/1/ethernet-ION/DD/Cisco/6509/TenGigabitEthernet/1/2/ethernet/6898da86-be34-42ed-b861-e907785858f0 node - http://geni-orca.renci.org/owl/6c952985-efad-46ad-a216-59a078f130a5#VLAN3

This requires a correction to the model for me to (a) be able to not use the interface that creates a shortcut from bbnNet to VLAN3 somehow and (b) make it consistent so paths from stitchport always have a link following it. Then I can undo the fix in RENCI-NRIG/flukes#15 and everything will 'just work'.

@YufengXin