Custom Query (138 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (1 - 3 of 138)

1 2 3 4 5 6 7 8 9 10 11
Ticket Resolution Summary Owner Reporter
#198 fixed No adminstative/privileged access for ExoGENI rack switches somebody lnevers@bbn.com
Description

This was missed in testing the GPO and RENCI racks administrative access.

Having administrative access to the head node allows user to login to the management and dataplane switches, but does not allows "enable" access (Turn on privileged commands):

lnevers@uh-hn ~]$ id
uid=2107(lnevers) gid=2000(nonrenci) groups=2000(nonrenci),2501(uhadmins),9510(bbnadmins)

[lnevers@uh-hn ~]$ ssh lnevers@uh-8264.uh.xo
Enter radius password: 

IBM Networking Operating System RackSwitch G8264.

uh-8264.uh.xo>ena

Enable access using (oper) credentials restricted to admin accounts only.
uh-8264.uh.xo>exit

...

[lnevers@uh-hn ~]$ ssh lnevers@uh-8052.uh.xo
Enter radius password: 

IBM Networking Operating System RackSwitch G8052.

uh-8052.uh.xo>ena

Enable access using (oper) credentials restricted to admin accounts only.
uh-8052.uh.xo>

#197 fixed ExoSM paths TCP traffic inconsistencies somebody lnevers@bbn.com
Description

Finding TCP traffic results are inconsistent for site to site connection set up by the ExoSM stitching between the GPO and Houston rack.

The following TCP performance was found from GPO EG to Houston EG (repeatable):

   1 TCP client = 20.4 Mbits/sec 
  5 TCP clients = 3.02 Mbits/sec
 10 TCP clients = 2.98 Mbits/sec

Why does throughput drop from 20 Mbits/sec as more client are added?

These are the results for the same requests in the opposite direction from Houston EG to GPO EG:

   1 TCP client = 7.95 Mbits/sec
  5 TCP clients = 8.81 Mbits/sec
 10 TCP clients = 8.66 Mbits/sec

Why such low throughput for an ExoSM VLAN?

The results above are inconsistent compared to other sites.

From GPO EG to UFL EG:                         
   1 TCP client = 27.5 Mbits/sec
  5 TCP clients = 139 Mbits/sec
 10 TCP clients = 278 Mbits/sec

From UFL EG to GPO EG:
   1 TCP client = 27.5 Mbits/sec
  5 TCP clients = 129 Mbits/sec
 10 TCP clients = 201 Mbits/sec
#195 fixed GENI Network Stitching to Bare Metal nodes does not work. somebody lnevers@bbn.com
Description

This issue was first reported on Dec 6, 2013. Writing ticket to track to resolution.

I just checked to verify the state of this issue and to capture output for this ticket and found that there is now a different failure:

Result Summary: Failed CreateSliver for slice IG-ST-4-2pc at 
https://geni.renci.org:11443/orca/xmlrpc.  Error from Aggregate: code 2: ERROR: 
Exception encountered: java.lang.IndexOutOfBoundsException: Index: 1, Size: 1. 

Originally, attempts to stitch to bare metal nodes resulted in the following error:

11:16:46 INFO     stitch.Aggregate: Stitcher doing createsliver at https://bbn-hn.exogeni.net:11443/orca/xmlrpc
11:16:49 ERROR    omni:  {'output': 'Embedding workflow ERROR: 4:No Edge Domain Exist:
http://geni-orca.renci.org/owl/c5099b69-099a-4dfa-b89f-11955bce0419#eg-gpo:
http://geni-orca.renci.org/owl/c5099b69-099a-4dfa-b89f-11955bce0419#StitchNode0.\n
Please see https://geni-orca.renci.org/trac/wiki/orca-errors for possible solutions.', 'code': {'geni_code': 2}}
11:16:49 INFO     stitch.Aggregate: Got AMAPIError doing createsliver IG-ST-4-2pc at <Aggregate
urn:publicid:IDN+exogeni.net:bbnvmsite+authority+am>: AMAPIError: Error from Aggregate: code 2:
Embedding workflow ERROR: 4:No Edge Domain Exist:
http://geni-orca.renci.org/owl/c5099b69-099a-4dfa-b89f-11955bce0419#eg-gpo:
http://geni-orca.renci.org/owl/c5099b69-099a-4dfa-b89f-11955bce0419#StitchNode0.
 Please see https://geni-orca.renci.org/trac/wiki/orca-errors for possible solutions..
1 2 3 4 5 6 7 8 9 10 11
Note: See TracQuery for help on using queries.