Opened 11 years ago

Closed 11 years ago

#1100 closed (fixed)

SCS picked same tag for 2 paths through same interface

Reported by: Aaron Helsinger Owned by: Aaron Helsinger
Priority: major Milestone:
Component: MAXSCS Version: SPIRAL5
Keywords: Cc: lnevers@bbn.com, xyang@maxgigapop.net
Dependencies:

Description

I had a request for 2 links from the same interface. The SCS seems to have picked the same VLAN tag for both.

Attachments (3)

ln-test-4links.xml (4.1 KB) - added by Aaron Helsinger 11 years ago.
scs-result.json (16.4 KB) - added by Aaron Helsinger 11 years ago.
scs-result-new.rspec.xml (11.9 KB) - added by xyang@maxgigapop.net 11 years ago.
Example SCS result rspec after fix.

Download all attachments as: .zip

Change History (11)

Changed 11 years ago by Aaron Helsinger

Attachment: ln-test-4links.xml added

Changed 11 years ago by Aaron Helsinger

Attachment: scs-result.json added

comment:1 Changed 11 years ago by xyang@maxgigapop.net

Cc: lnevers@bbn.com xyang@maxgigapop.net added
Owner: changed from xyang@maxgigapop.net to Aaron Helsinger

In SCS core code (mxtce), layer2 links have avaiableVlanRange, suggestedVlanRange and assignedVlanRange.

The original code only excluded assignedVlanRange from being dup provisioned.

A revision has been made to treat suggestedVlanRange the same as assignedVlanRange. This might not be the best solution but it should work for now.

Re-assign to Aaron and Luisa to test more.

comment:2 Changed 11 years ago by lnevers@bbn.com

Seems that all stitching attempts today are failing with the error below. May be related to changes in this ticket:

$ stitcher.py createsliver lnstitch ./stitch-ig-gpo-ig-utah.rspec
13:20:52 INFO     stitcher: Loading config file /home/lnevers/.gcf/omni_config
13:20:52 INFO     stitcher: Using control framework portal
13:20:52 INFO     stitcher: Checking that slice lnstitch is valid...
13:20:53 INFO     stitcher: Slice urn:publicid:IDN+ch.geni.net:ln-prj+slice+lnstitch expires on 2013-09-12 17:19:34 UTC
13:20:54 INFO     stitcher: <Aggregate urn:publicid:IDN+utah.geniracks.net+authority+cm> speaks AM API v3, but sticking with v2
13:20:54 INFO     stitcher: <Aggregate urn:publicid:IDN+instageni.gpolab.bbn.com+authority+cm> speaks AM API v3, but sticking with v2
13:20:54 INFO     stitcher: <Aggregate urn:publicid:IDN+emulab.net+authority+cm> speaks AM API v3, but sticking with v2
13:20:54 INFO     stitcher: Stitched reservation will include resources from these aggregates:
13:20:54 INFO     stitcher: <Aggregate urn:publicid:IDN+utah.geniracks.net+authority+cm>
13:20:54 INFO     stitcher: <Aggregate urn:publicid:IDN+instageni.gpolab.bbn.com+authority+cm>
13:20:54 INFO     stitcher: <Aggregate urn:publicid:IDN+emulab.net+authority+cm>
13:20:54 INFO     stitcher: <Aggregate urn:publicid:IDN+ion.internet2.edu+authority+am>
Traceback (most recent call last):
  File "/home/lnevers/gcf-2.4dev/src/stitcher.py", line 193, in <module>
    sys.exit(main())
  File "/home/lnevers/gcf-2.4dev/src/stitcher.py", line 174, in main
    text, item = call(argv)
  File "/home/lnevers/gcf-2.4dev/src/stitcher.py", line 165, in call
    return handler.doStitching(args)
  File "/home/lnevers/gcf-2.4dev/src/omnilib/stitchhandler.py", line 173, in doStitching
    lastAM = self.mainStitchingLoop(sliceurn, self.parsedUserRequest.dom)
  File "/home/lnevers/gcf-2.4dev/src/omnilib/stitchhandler.py", line 360, in mainStitchingLoop
    lastAM = launcher.launch(self.parsedSCSRSpec, self.scsCalls)
  File "/home/lnevers/gcf-2.4dev/src/omnilib/stitch/launcher.py", line 51, in launch
    agg.allocate(self.opts, self.slicename, rspec.dom, scsCallCount)
  File "/home/lnevers/gcf-2.4dev/src/omnilib/stitch/objects.py", line 387, in allocate
    self.requestDom = self.getEditedRSpecDom(rspecDom)
  File "/home/lnevers/gcf-2.4dev/src/omnilib/stitch/objects.py", line 671, in getEditedRSpecDom
    path.editChangesIntoDom(domNode)
  File "/home/lnevers/gcf-2.4dev/src/omnilib/stitch/objects.py", line 147, in editChangesIntoDom
    hop.editChangesIntoDom(domHopNode)
  File "/home/lnevers/gcf-2.4dev/src/omnilib/stitch/objects.py", line 2020, in editChangesIntoDom
    self._hop_link.editChangesIntoDom(child)
  File "/home/lnevers/gcf-2.4dev/src/omnilib/stitch/objects.py", line 2280, in editChangesIntoDom
    vlan_range[0].appendChild(Document.createTextNode(newVlanRangeString))
NameError: global name 'Document' is not defined
$ 

comment:3 Changed 11 years ago by xyang@maxgigapop.net

The fix has been reverted. There is no quick solution for this. In most cases, randomization help avoid contention. I will find a better solution for this.

Leave it open for now.

comment:4 Changed 11 years ago by lnevers@bbn.com

Hello Xi, Aaron said the latest error was actually a stitcher bug and that he would be providing a fix soon. So your fix may have brought up the error, but was not the problem.

comment:5 Changed 11 years ago by xyang@maxgigapop.net

The problem with my fix was that all <vlanRangeAvailability> elements became empty.

I think that element needs to be populated with originally advertised vlan range.

comment:6 Changed 11 years ago by xyang@maxgigapop.net

SCS has been updated with a new fix.

<vlanRangeAvailability> will not be empty now. Instead, any "suggested/assigned VLAN(s)" for prior paths in the same rspc will be excluded from <vlanRangeAvailability> in subsequent paths.

Re-assign to Aaron and Lusisa for testing.

Changed 11 years ago by xyang@maxgigapop.net

Attachment: scs-result-new.rspec.xml added

Example SCS result rspec after fix.

comment:7 Changed 11 years ago by Aaron Helsinger

I've tried a few times and haven't reproduced the bug today. And the sample result rspec you attached looks reasonable to me.

comment:8 Changed 11 years ago by Aaron Helsinger

Resolution: fixed
Status: newclosed

Still can't reproduce. Looks fixed.

Note: See TracTickets for help on using tickets.