Wired Intelligent Edge

Hi,

Does anybody has an idea why there is sometimes negative uptime value there in listing resulted "sh ip igmp" command?

Today there was value of -128days in 5406R stack and previously I have saw such values also in 2960, 25xx and 6100 series too.

There was problem there in system but I cannot say that reason was that value.. I did "no ip igmp" and "ip igmp" which resetted the igmp there in 5406 (and ofcourse rebooted problematic video player too at same time) and result was working system.

Hi,

Sounds like a signed integer overflow... Do you see this output in the CLI or you get it by SNMP? If CLI is the issue, do you have that terminal session recorded in the text file to illustrate the issue? If you do, consider opening a case with Aruba TAC.

Hi Ivan,

I get information via CLI and I have saw this previously many times with many different systems and firmware versions.

From data below:

Partial capture is from 5406R stack running fw 16.11.0004 which is working in production environment and cannot be debugged that much. 

Vid111's igmp is resetted yesterday by doing "no ip igmp" (global "igmp reload" did not do anything to this one).
Vid150 & 200 is in non-touched mode and having negative uptime value. 

I'm not fully sure that this "issue" has negative impact but every time I see this, there is usually some issues in different systems using multicast for discovery or transport media streams etc...

I have thought about to open case about this but I can see there is not enough "evidence" to go through first couple levels of support to reach proper instances which can dig deep enough.

------------------

  VLAN ID : 111
  VLAN Name : DigitalSignage
  IGMP version : 2
  Querier Address [this switch] : 10.1.101.2
  Filter Unknown Multicast Packets : Disabled
  Querier Port :
  Querier UpTime : 19h 3m 34s
  Querier Expiration Time : 0h 2m 0s

  Active Group Addresses Type       Expires         Ports      Reports Queries
  ---------------------- ---------- --------------- ---------- ------- -------
  224.2.127.254          Filter     0h 2m 10s       Trk3       546     0
  239.10.10.11           Filter     0h 4m 19s       Trk5,Trk7  12582   0
  239.10.100.100         Filter     0h 4m 17s       Trk7       72      0
  239.255.255.250        Filter     0h 4m 20s       1/D3,Tr... 14261   0
  239.255.255.255        Filter     0h 4m 16s       Trk3       547     0

  VLAN ID : 150
  VLAN Name : VLAN150
  IGMP version : 2
  Querier Address [this switch] : 10.199.200.2
  Filter Unknown Multicast Packets : Disabled
  Querier Port :
  Querier UpTime : -192d -1h -1m -9s
  Querier Expiration Time : 0h 0m 45s

  Active Group Addresses Type       Expires         Ports      Reports Queries
  ---------------------- ---------- --------------- ---------- ------- -------
  239.255.255.250        Filter     0h 3m 2s        Trk8       1051    0

  VLAN ID : 200
  VLAN Name : AudioCTRL-ERKKO
  IGMP version : 2
  Querier Address [this switch] : 10.2.0.2
  Filter Unknown Multicast Packets : Disabled
  Querier Port :
  Querier UpTime : -192d -1h -1m -9s
  Querier Expiration Time : 0h 0m 44s

  Active Group Addresses Type       Expires         Ports      Reports Queries
  ---------------------- ---------- --------------- ---------- ------- -------
  224.0.1.129            Filter     0h 3m 4s        Trk4,Tr... 626986  0
  224.0.23.175           Filter     0h 3m 8s        Trk4,Tr... 1515951 0
  239.192.0.64           Static     0h 0m 0s                   0       0
  239.255.254.253        Static     0h 0m 0s                   0       0
  239.255.254.255        Filter     0h 3m 1s        Trk15      14229   0
  239.255.255.250        Filter     0h 3m 6s        Trk4,Trk9  32292   0
  239.255.255.255        Filter     0h 3m 8s        Trk4,Tr... 555575  0

We need to catch the issue while it's in place, of course you can always open a case as RCA (root cause analysis) for the issue that happened once and has already gone, but it doesn't always lead to the resolution, from my experience. If you see that issue once again on AOS-based switch, take a "show tech all" before resetting the IGMP, if that will be AOS-CX, 'copy support-files all ...' And if it's not a problem, refrain from resetting the counter, so TAC can analyze live system with the incorrect counter value in place.