Hi AJ,
On 5/27/2015 7:54 AM, Andrew Ragusa wrote:
Hi Azher
I hope to send out the OESS 1.1.6 documentation, and change log to
the
list later on today.
Excellent.
This ticket is not included in 1.1.6, it came in too late in the
development cycle to make it into the release.
Is there a date you need this by?
Our current tools written to use Internet2 simply fail due to the
fact that each of these two OSCARS domains are dual peered (AL2S,
ESnet). These are the key testbeds for ANSE project software
development and other experimentation.
So if you ask me, I need this support today. In the times of Dragon,
when we were creating the topology files manually, it was very easy
to play with traffic engineering metric and choose the routes, but
not in the OESS at the moment.
Thanks
-Azher
Thanks
A.J.
On 5/27/15 9:39 AM, Azher Mughal wrote:
> Hi AJ,
> Can you please update if OESS release 1.1.6 will include this
> ticket ?
> Thanks -Azher
> On 5/1/2015 7:25 AM, Andrew Ragusa wrote:
>> Ok ticket 11044 is tracking that feature, it is currently
queued
>> for a future OESS release.
>>
>> Thanks A.J.
>>
>>
>> On 5/1/15 10:19 AM, Azher Mughal wrote:
>>> Hi AJ,
>>
>>> On 5/1/2015 7:13 AM, Andrew Ragusa wrote: Hi Azher
>>
>>> I'm not sure about what you are asking. Are you
asking for
>>> the AL2S topology to be changed.
>>>> No.
>>
>>> Or are you asking for the ability to tune the
>>> trafficEngineeringMetric value for each remoteLink in
an OESS
>>> instance?
>>>> Yes, Tune the traffic engineering in the site
OESS instance
>>>> so that OSCARS will take that path specifically.
>>
>>> I can put a ticket in for the OESS feature if you
want.
>>>> That will be great.
>>
>>>> Thanks -Azher
>>
>>
>>> Thanks A.J.
>>
>>
>>> On 4/30/15 5:57 PM, Azher Mughal wrote:
>>>>>> Hello,
>>>>>>
>>>>>> Caltech and UMich have multiple peerings
(AL2S and
>>>>>> ESnet). Both domains are getting error
"Unable to find
>>>>>> IDC", details below. When any other
domain creates a path
>>>>>> to them, path works. ESnet is only used
for NSI
>>>>>> aggregator.
>>>>>>
>>>>>> Is there a way in OESS to change the
traffic engineering
>>>>>> value so that AL2S is always prefferred ?
>>>>>>
>>>>>> E.g. Caltech:
>>>>>>
https://ndb7.net.internet2.edu/TopologyViewer/?domain=caltech.edu
&t
>>
>>>>>>
s_i
>>
>>>>>>
>>
nstance=http%3A%2F%2Fdcn-ts.internet2.edu%3A8012%2FperfSONAR_PS%2Fser
vic
>>
>>
> es%2Ftopology
>>>>>> -Azher
>>>>>>
>>>>>>
>>>>>> -------- Forwarded Message --------
Subject: Re:
>>>>>> [oscars-support] Circuit Fail: Unable to
find IDC ?
>>>>>> Date: Tue, 28 Apr 2015 12:08:53 -0400
From: Andrew
>>>>>> Lake Reply-To:
To:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Hi Azher,
>>>>>>
>>>>>> I see that UMich has a peering with al2s
and es.net
>>>>>> <http://es.net>. I wonder if it’s
preferring the es.net
>>>>>> <http://es.net> path, and there is
no entry in the
>>>>>> lookup module for that domain so it
complains it can’t
>>>>>> find the IDC. You could try running
oscars-idcadd to
>>>>>> point at es.net <http://es.net> or
specifying al2s in the
>>>>>> middle of the path so it uses that
instead.
>>>>>>
>>>>>> Andy
>>>>>>
>>>>>>
>>>>>>> On Apr 28, 2015, at 10:20 AM, Azher
Mughal
>>>>>>> <
>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Andy, Any suggestions ?
>>>>>>>
>>>>>>> Thanks -Azher
>>>>>>>
>>>>>>> On 4/27/2015 9:08 AM, Azher Mughal
wrote:
>>>>>>>> Hi Andy,
>>>>>>>>
>>>>>>>> I have the following in the IDC
domains list. Both
>>>>>>>> of these domains talk with ESnet
aggregator using the
>>>>>>>> NSI aggregator.
>>>>>>>>
>>>>>>>> Caltech:
>>>>>>>>
>>>>>>>> [root@idc-v6 oscars]#
>>>>>>>>
/opt/oscars/lookup/bin/oscars-idclist Loading
>>>>>>>> manifest from
>>>>>>>>
/etc/oscars/LookupService/conf/manifest.yaml
>>>>>>>>
>>>>>>>> ID: 2 Type: IDC Expiration: NEVER
Protocols: Type:
>>>>>>>> http://oscars.es.net/OSCARS/06
Location:
>>>>>>>>
https://al2s.net.internet2.edu:9001/OSCARS
>>>>>>>> Relationships: [controls]
>>>>>>>>
urn:ogf:network:domain=al2s.net.internet2.edu
>>>>>>>>
<http://al2s.net.internet2.edu>
>>>>>>>>
>>>>>>>> UMich: [root@oess ~]#
>>>>>>>>
/opt/oscars/lookup/bin/oscars-idclist Loading
>>>>>>>> manifest from
>>>>>>>>
/etc/oscars/LookupService/conf/manifest.yaml
>>>>>>>>
>>>>>>>> ID: 3 Type: IDC Expiration: NEVER
Protocols: Type:
>>>>>>>> http://oscars.es.net/OSCARS/06
Location:
>>>>>>>>
https://al2s.net.internet2.edu:9001/OSCARS
>>>>>>>> Relationships: [controls]
>>>>>>>>
urn:ogf:network:domain=al2s.net.internet2.edu
>>>>>>>>
<http://al2s.net.internet2.edu>
>>>>>>>>
>>>>>>>> Thanks -Azher
>>>>>>>>
>>>>>>>> On 4/27/2015 8:04 AM, Andrew Lake
wrote:
>>>>>>>>> Hi Azher,
>>>>>>>>>
>>>>>>>>> I’ve been out the past couple
weeks, so sorry for
>>>>>>>>> the delay. Did you find your
answer to this? It is
>>>>>>>>> usually caused because a
domain’s IDC has not been
>>>>>>>>> added to the OSCARS lookup
module. I can help with
>>>>>>>>> commands if this is still an
issue.
>>>>>>>>>
>>>>>>>>> Thanks, Andy
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> On Apr 14, 2015, at 12:24
PM, Azher Mughal
>>>>>>>>>> <
>>>>>>>>>>
> wrote:
>>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> What caused this error ?
I restarted OSCARS and
>>>>>>>>>> then kicked a new
reservation, but same error.
>>>>>>>>>>
>>>>>>>>>> OSCARSService.log: WARN
>>>>>>>>>>
ts=2015-04-14T03:07:06.165000Z
>>>>>>>>>>
event=OSCARSInternal-API.invoke-client.end
>>>>>>>>>>
guid=oess.dcn.umnet.umich.edu
>>>>>>>>>>
<http://oess.dcn.umnet.umich.edu>-V05-f1b776c9-a3f5-4134-b12c
-f
>>
>>>>>>>>>>
0a6
>>
>>>>>>>>>>
>> 946c00a3
>>>>>>>>>>
>>> gri=oess.dcn.umnet.umich.edu
>>> <http://oess.dcn.umnet.umich.edu>-2745
>>>>>>>>>> errSeverity=MINOR
status=-1
>>>>>>>>>>
msg="OSCARSSoapService.invoke:Exception
>>>>>>>>>> connecting to lookup on
>>>>>>>>>>
https://localhost:9014/lookup Message is: Unable
>>>>>>>>>> to find IDC"
>>>>>>>>>>
>>>>>>>>>> Since this is localhost,
so iptables should not
>>>>>>>>>> be an issue. I have the
following in the
>>>>>>>>>> iptables config.
>>>>>>>>>>
>>>>>>>>>> -A INPUT -i lo -j ACCEPT
>>>>>>>>>>
>>>>>>>>>> Thanks -Azher
>>>>>>>>>>
>>>>>>
>>>>>> -- This message has been scanned for
viruses and
>>>>>> dangerous content by *MailScanner*
>>>>>> <http://www.mailscanner.info/>, and
is believed to be
>>>>>> clean.
>>>>>>
>>>>
>>
>
|
