Re: ifIndex

[David Hubbard]

I do that too, but I’m referring to XR when you use different speed optics in a 
multi-speed port; if you have a SFP+ port and 10gig SFP, you’ll get one 
ifindex.  New use case requires swapping to a gigE SFP and you’ll get a new 
ifindex.  Take the port out of service, remove the GigE SFP and the related 
config, yet both ifindexes remain; until the device is reloaded.  At that the 
gigE ifindex goes away leaving just the native-speed ifindex.

It’s a pain for management because we’re forced to make exclusions in our NMS 
for ifindex’s that may disappear at some point, because they show as down with 
no way to make that not the case.  Worse, if that port is put to use again at 
the non-native speed, and has such an exclusion in place, we don’t auto learn 
the new usage because of the exclusion.

I tried to argue with TAC that if the gigE SFP has been removed from the SFP+ 
port, and its config has been deleted, the corresponding ifindex and related 
counters should be gone; it no longer exists in any form.  If you reload, it 
will disappear, but that’s the only way.

From: Mel Beckman 
Date: Saturday, October 13, 2018 at 4:46 PM
To: David Hubbard 
Cc: "nanog@nanog.org" 
Subject: Re: ifIndex

David,

All you have to do is turn on IFindex persistence:

https://www.cisco.com/c/en/us/td/docs/routers/crs/software/crs_r4-2/system_management/command/reference/b_sysman_cr42crs/b_sysman_cr42crs_chapter_01101.html#wp2192797756

We do this on our XRs and it works perfectly.

-mel via cell

On Oct 13, 2018, at 9:20 AM, David Hubbard 
mailto:dhubb...@dino.hostasaurus.com>> wrote:
Cisco tries very hard to make such useless data occur in XR.  If you have a 
gigE SFP in an SFP+ port, a new ifindex will appear for the resulting 
GigabitEthernetX port, then it remains even if both the config and SFP have 
been removed.  Automated systems will keep querying it as if it were a downed 
port, but wait, reboot, and suddenly it vanishes.  I went back and forth with 
TAC for weeks explaining that SNMP interfaces should not disappear as a result 
of a reboot, I should either be able to remove it, or it's stuck there forever, 
but a reboot should not cause a change.  They didn't care; it is 'by design'.

On 10/13/18, 8:47 AM, "NANOG on behalf of Mel Beckman" 
mailto:nanog-boun...@nanog.org> on behalf of 
m...@beckman.org> wrote:

   Saku,

   The issue isn't that ifindexes change during operation. That would truly 
make SNMP useless. The issue is that they change across reboots. That's where 
features such as Cisco's Interface Index Persistence helps out.

   -mel via cell


On Oct 13, 2018, at 2:59 AM, Saku Ytti mailto:s...@ytti.fi>> 
wrote:

On Fri, 12 Oct 2018 at 21:40, Chris Adams 
mailto:c...@cmadams.net>> wrote:

Is there any good excuse that SNMP client software can't handle a basic
design of SNMP - indexed tables?  ifIndex is far from the only index in
SNMP, and many of them still change today at various times.

It isn't that hard to fetch the indexed field in a bulk get, rewalking
the table if you don't get what you expected.  Cricket did this in 1999.

It's never going to be provably correct, depending on what stability means.

You fetch relation at t0, then at t1 you fetch data. Was the relation
same at t0 and t1? You can gain some confidence by fetching relation
again at t2 and disregard data if t0 != t2. But this becomes polling
expensive quite fast, and still not provably correct. This may be
nitpicking, but I've always felt uneasy about the lack of guarantee.

I wonder if those who have stable indeces, have them for all cases,
all logical interfaces and virtual interfaces?

--
++ytti

Re: ifIndex

[Mel Beckman]

David,

All you have to do is turn on IFindex persistence:

https://www.cisco.com/c/en/us/td/docs/routers/crs/software/crs_r4-2/system_management/command/reference/b_sysman_cr42crs/b_sysman_cr42crs_chapter_01101.html#wp2192797756

We do this on our XRs and it works perfectly.

-mel via cell

On Oct 13, 2018, at 9:20 AM, David Hubbard 
mailto:dhubb...@dino.hostasaurus.com>> wrote:

Cisco tries very hard to make such useless data occur in XR.  If you have a 
gigE SFP in an SFP+ port, a new ifindex will appear for the resulting 
GigabitEthernetX port, then it remains even if both the config and SFP have 
been removed.  Automated systems will keep querying it as if it were a downed 
port, but wait, reboot, and suddenly it vanishes.  I went back and forth with 
TAC for weeks explaining that SNMP interfaces should not disappear as a result 
of a reboot, I should either be able to remove it, or it's stuck there forever, 
but a reboot should not cause a change.  They didn't care; it is 'by design'.

On 10/13/18, 8:47 AM, "NANOG on behalf of Mel Beckman" 
mailto:nanog-boun...@nanog.org> on behalf of 
m...@beckman.org> wrote:

   Saku,

   The issue isn't that ifindexes change during operation. That would truly 
make SNMP useless. The issue is that they change across reboots. That's where 
features such as Cisco's Interface Index Persistence helps out.

   -mel via cell

On Oct 13, 2018, at 2:59 AM, Saku Ytti mailto:s...@ytti.fi>> 
wrote:

On Fri, 12 Oct 2018 at 21:40, Chris Adams 
mailto:c...@cmadams.net>> wrote:

Is there any good excuse that SNMP client software can't handle a basic
design of SNMP - indexed tables?  ifIndex is far from the only index in
SNMP, and many of them still change today at various times.

It isn't that hard to fetch the indexed field in a bulk get, rewalking
the table if you don't get what you expected.  Cricket did this in 1999.

It's never going to be provably correct, depending on what stability means.

You fetch relation at t0, then at t1 you fetch data. Was the relation
same at t0 and t1? You can gain some confidence by fetching relation
again at t2 and disregard data if t0 != t2. But this becomes polling
expensive quite fast, and still not provably correct. This may be
nitpicking, but I've always felt uneasy about the lack of guarantee.

I wonder if those who have stable indeces, have them for all cases,
all logical interfaces and virtual interfaces?

--
++ytti

Re: Hulu / ESPN: Commercial IP Address

[Daniel Corbe]

I had a customer with a similar issue.   I statically assigned them a  
different IP and it didn’t resolve it.   The problem turned out to be tied  
to their Hulu account.


The customer is going to need to keep pressing the issue with Hulu’s  
technical support group.   Make sure they’re not using a VPN to connect to  
the Internet and have them keep calling Hulu back until they get someone  
clueful on the phone.


In my customer’s case, they eventually had to “re-home” them to resolve  
it.  I have no idea what that entails.


-Daniel

at 12:35 PM, Jason Canady  wrote:


Hello,

I have a customer that is using Hulu Live to stream ESPN, however it  
isn't showing up in their Channel list.  They reached out to Hulu and  
it's because their IP address is 'commercial'.  We have many customers  
using Hulu without problems, but it seems specific to ESPN.  Anyone else  
have this issue?  Do you reach out to ESPN or Hulu?


If anyone has any information, please share it.  Appreciate your help in  
advance!


Best Regards,

Jason Canady
Unlimited Net, LLC
Responsive, Reliable, Secure

Hulu / ESPN: Commercial IP Address

[Jason Canady]

Hello,

I have a customer that is using Hulu Live to stream ESPN, however it 
isn't showing up in their Channel list.  They reached out to Hulu and 
it's because their IP address is 'commercial'.  We have many customers 
using Hulu without problems, but it seems specific to ESPN.  Anyone else 
have this issue?  Do you reach out to ESPN or Hulu?


If anyone has any information, please share it.  Appreciate your help in 
advance!


Best Regards,

Jason Canady
Unlimited Net, LLC
Responsive, Reliable, Secure

Re: ifIndex

[David Hubbard]

Cisco tries very hard to make such useless data occur in XR.  If you have a 
gigE SFP in an SFP+ port, a new ifindex will appear for the resulting 
GigabitEthernetX port, then it remains even if both the config and SFP have 
been removed.  Automated systems will keep querying it as if it were a downed 
port, but wait, reboot, and suddenly it vanishes.  I went back and forth with 
TAC for weeks explaining that SNMP interfaces should not disappear as a result 
of a reboot, I should either be able to remove it, or it's stuck there forever, 
but a reboot should not cause a change.  They didn't care; it is 'by design'. 

On 10/13/18, 8:47 AM, "NANOG on behalf of Mel Beckman" 
 wrote:

Saku,

The issue isn't that ifindexes change during operation. That would truly 
make SNMP useless. The issue is that they change across reboots. That's where 
features such as Cisco's Interface Index Persistence helps out. 

-mel via cell

> On Oct 13, 2018, at 2:59 AM, Saku Ytti  wrote:
> 
>> On Fri, 12 Oct 2018 at 21:40, Chris Adams  wrote:
>> 
>> Is there any good excuse that SNMP client software can't handle a basic
>> design of SNMP - indexed tables?  ifIndex is far from the only index in
>> SNMP, and many of them still change today at various times.
>> 
>> It isn't that hard to fetch the indexed field in a bulk get, rewalking
>> the table if you don't get what you expected.  Cricket did this in 1999.
> 
> It's never going to be provably correct, depending on what stability 
means.
> 
> You fetch relation at t0, then at t1 you fetch data. Was the relation
> same at t0 and t1? You can gain some confidence by fetching relation
> again at t2 and disregard data if t0 != t2. But this becomes polling
> expensive quite fast, and still not provably correct. This may be
> nitpicking, but I've always felt uneasy about the lack of guarantee.
> 
> I wonder if those who have stable indeces, have them for all cases,
> all logical interfaces and virtual interfaces?
> 
> -- 
>  ++ytti

Re: Software installation tools retrieving ARIN TAL (was: Re: ARIN RPKI TAL deployment issues)

[Job Snijders]

Dear John,

I'd like to thank you and the ARIN team for these efforts - in doing so
I feel that ARIN recognises issues & concerns related to the
distribution of the ARIN RPKI TAL. Acknowledging a problem is the first
step to solving it!

On Sat, Oct 13, 2018 at 09:35:36AM -0400, John Curran wrote:
> On 25 Sep 2018, at 3:34 PM, Job Snijders  wrote:
> > ...
> > What I'm hoping for is that there is a way for the ARIN TAL to be
> > included in software distributions, without compromising ARIN's
> > legal position.
> > 
> > Perhaps an exception for software distributors would already go a
> > long way?
> 
> While not exactly what you seek, we can get a bit closer to the goal –
> i.e. by eliminating the need for the user installing a software
> package to first go get the ARIN TAL and put it in the right place
> prior to running the installation software. 
> 
> To that end, the ARIN TAL page
> https://www.arin.net/resources/rpki/tal.html has been revised with
> specific guidance –
> 
>   Software Installation Tools
> 
>   Software installation tools may download the ARIN TAL on behalf of a
>   user after the user has confirmed their acceptance of the ARIN
>   Relying Party Agreement (RPA) on the ARIN website.  This acceptance
>   must require "agreement to the ARIN Relying Party Agreement
>   (https://www.arin.net/resources/rpki/rpa.pdf)" and obtain a
>   non-ambiguous affirmative action by clicking on, or the entry of, a
>   word of agreement (such as  "yes" or "accept")
> 
> Example: Attention: This package requires the download of the ARIN TAL
> and agreement to the ARIN Relying Party Agreement (RPA)
> (https://www.arin.net/resources/rpki/rpa.pdf). Type "yes" to agree,
> and you can proceed with the ARIN TAL download: yes

In this approach I still observe an institutional barrier. If we take
DNSSEC as analogous concept, when installing & starting BIND, unbound,
NSD, knot, Microsoft DNS, or PowerDNS, no affirmative actions are
required.

It is also not clear to me how in context of fully automated
installation & deployment the paradigm of 'non-ambiguous affirmative
action' can exist. If we instruct orchastration software to say 'yes' to
whatever questions pop up what does that actually mean? It certainly no
longer adheres to the spirit of whatever it is that ARIN seeks.

Lastly - having to download a file ('requiring specific network
connectivity') in context of installation & deployment is always
inferior compared to bundling all required pieces into coherent software
packages.

> We will continue to explore mechanisms for making ARIN’s RPKI
> repository more accessible to the community, but felt that this
> interim step could be accomplished promptly and was worth noting in a
> timely manner to those distributing RPKI software.

Yes - please do. Providing guidance to software distributors does not
change some of the challenging contents of the RPA, nor does it address
the fundamental institutional barrier that separates the ARIN TAL from
the other RIR TALs.

Kind regards,

Job

Software installation tools retrieving ARIN TAL (was: Re: ARIN RPKI TAL deployment issues)

[John Curran]

On 25 Sep 2018, at 3:34 PM, Job Snijders  wrote:
> ...
> What I'm hoping for is that there is a way for the ARIN TAL to be
> included in software distributions, without compromising ARIN's legal
> position.
> 
> Perhaps an exception for software distributors would already go a long
> way?
> 
>"You can include the ARIN TAL in your software distribution as long
>as you also include an unmodified copy of the
>https://www.arin.net/resources/rpki/rpa.pdf 
>  file alongside it."
> 
> Kind regards,

Job - 

While not exactly what you seek, we can get a bit closer to the goal – i.e. by 
eliminating the need for the user installing a software package to first go get 
the ARIN TAL and put it in the right place prior to running the installation 
software. 

To that end, the ARIN TAL page > has been revised with specific 
guidance –

Software Installation Tools

Software installation tools may download the ARIN TAL on behalf of a 
user after the user has confirmed their acceptance of the ARIN Relying Party 
Agreement (RPA) on the ARIN website.  This acceptance must require "agreement 
to the ARIN Relying Party Agreement 
(https://www.arin.net/resources/rpki/rpa.pdf)" and obtain a non-ambiguous 
affirmative action by clicking on, or the entry of, a word of agreement (such 
as  "yes" or "accept")

Example:
Attention: This package requires the download of the ARIN TAL and agreement to 
the ARIN Relying Party Agreement (RPA) 
(https://www.arin.net/resources/rpki/rpa.pdf).
Type "yes" to agree, and you can proceed with the ARIN TAL download: yes


We will continue to explore mechanisms for making ARIN’s RPKI repository more 
accessible to the community, but felt that this interim step could be 
accomplished promptly and was worth noting in a timely manner to those 
distributing RPKI software. 

Thanks!
/John

John Curran
President and CEO
American Registry for Internet Numbers

Re: ifIndex

[Mel Beckman]

Saku,

The issue isn't that ifindexes change during operation. That would truly make 
SNMP useless. The issue is that they change across reboots. That's where 
features such as Cisco's Interface Index Persistence helps out. 

-mel via cell

> On Oct 13, 2018, at 2:59 AM, Saku Ytti  wrote:
> 
>> On Fri, 12 Oct 2018 at 21:40, Chris Adams  wrote:
>> 
>> Is there any good excuse that SNMP client software can't handle a basic
>> design of SNMP - indexed tables?  ifIndex is far from the only index in
>> SNMP, and many of them still change today at various times.
>> 
>> It isn't that hard to fetch the indexed field in a bulk get, rewalking
>> the table if you don't get what you expected.  Cricket did this in 1999.
> 
> It's never going to be provably correct, depending on what stability means.
> 
> You fetch relation at t0, then at t1 you fetch data. Was the relation
> same at t0 and t1? You can gain some confidence by fetching relation
> again at t2 and disregard data if t0 != t2. But this becomes polling
> expensive quite fast, and still not provably correct. This may be
> nitpicking, but I've always felt uneasy about the lack of guarantee.
> 
> I wonder if those who have stable indeces, have them for all cases,
> all logical interfaces and virtual interfaces?
> 
> -- 
>  ++ytti

Re: ifIndex

[Saku Ytti]

On Fri, 12 Oct 2018 at 21:40, Chris Adams  wrote:

> Is there any good excuse that SNMP client software can't handle a basic
> design of SNMP - indexed tables?  ifIndex is far from the only index in
> SNMP, and many of them still change today at various times.
>
> It isn't that hard to fetch the indexed field in a bulk get, rewalking
> the table if you don't get what you expected.  Cricket did this in 1999.

It's never going to be provably correct, depending on what stability means.

You fetch relation at t0, then at t1 you fetch data. Was the relation
same at t0 and t1? You can gain some confidence by fetching relation
again at t2 and disregard data if t0 != t2. But this becomes polling
expensive quite fast, and still not provably correct. This may be
nitpicking, but I've always felt uneasy about the lack of guarantee.

I wonder if those who have stable indeces, have them for all cases,
all logical interfaces and virtual interfaces?

-- 
  ++ytti