snmp dot1dTpFdbPort with 5.1.1.1 ERS8600

[dekdek]

hi,

i've just found your site and i'm very impressed by your work and your desire to share your
work and knowledge. Great !
i use Nortel switch since a long time (old synoptics 5000/3000, baystack...).
Sorry in advance for my french accent .. i do my best with a dictionnary near me.

My issue concerns ERS8600. I've upgrade recently to 5.1.1.1.
Since the upgrade, i can't walk anymore the standart Oid 1.3.6.1.2.1.17.4.3.1.2 (dot1dTpFdbPort).
No return and i can see in device Manager (Security/ControlPath/General/SNMP) counter OutNoSuchNames increment
to 1 anytime i try to walk this OID.
What can i do ? it's too bad because i use snmp tools (like Nedi or cacti/mactrack) to discover mac adresses on my networK.... have you ever encounter this problem ?

another question : i've found in the forum that you talk about enable SystemMonitorEnable and Monitoringenable in Device Manager (Chassis/System Flags). Already enable to me. But what is the meaning of these 2 items (i've not found information on the web) ?

thanks in advance.

Cristophe DECOR
Network Technicien

[Michael McNamara]

Hi Cristophe and welcome to the forums!

The problem you are referring to is a known issue with the 5.1.x software release. Here are the known issues as of the 5.1.2.0 software release;

• Repeated HA-CPU failovers may result in R-modules going offline. (Q02053766)
• ERS8600 might show LANE lockup and COP may observe crash with an exception against tTimerTask. (Q02068289)
• A task exception within the I/O module co-processor has been reported very intermittently which will result in the I/O module resetting. (Q02113086)
• When an R or RS I/O module experiences SW instability, the port status at the far end of the connected links may not drop for up to 20 seconds. (Q02112285)
• On systems equipped with the 8692SF card with mezz, the LED status indicator for the mezz daughter board may not display the operational status properly. The status of the mezz card is properly displayed in the CLI and through JDM (Q02102364)
• Retrieval of an exact entry of dot1dTpFdbTable via an SNMP GET does not function properly. Retrieval of the dot1dTpFdbTable with SNMP Get Next works correctly (Q02113802)

Utilizing the NET-SNMP command line utilities I didn't have much success utilizing either snmpgetnext, snmpwalk, or snmpget.

I use the Nortel proprietary MIBS to get the same information in my home grown Perl scripts. Here are the MIBS;

my $vars = new SNMP::VarList(
                        ['rcBridgeFdbStatus', 0],
                        ['rcBridgeFdbAddress', 0],
                        ['rcBridgeFdbPort', 0],
                        ['rcBridgeFdbVlanId', 0] );

Thanks for the kind words and I hope this helps!

[John T]

I wonder why that issue hasn't been fixed... pretty much breaks all the management systems out there.

You can also use the ARP table if you have these switches performing the routing. You can poll the following SNMP OIDs for that information as well;

     ipNetToMediaIfIndex
     ipNetToMediaPhysAddress
     ipNetToMediaNetAddress
     ipNetToMediaType

[dekdek]

thanks to you.
- i'm very sad because this issue will not be solved in my case. Because i can't use the
incoming version 7 (i have old E module).
Maybe i can downgrade ? I just need a version to support R module (8648GTR).
- is R module supporting by the 8691SF ?
- please can you  answer my second question about enablesystemonitor in my first post ? i've read in your forum that when this option enable, cpu is around 10%. That's my case. In version 3 with 8691SF cpu was around 2/3% with exactly same config.

thanks in advance.

[Michael McNamara]

@dekdek - Sure, the "System Monitor" option is just a feature built into the switch to help it monitor the system itself. It has nothing to-do with network monitoring. It has more to-do with the switch monitoring itself including all the running process, etc.

You need an 8692SF to run an R/RS modules. I believe they will fix it in later 5.1.x software releases. Again there are going to be quite a few folks that won't make the jump to 7.x software.

The R modules are supported in 4.1.x software with 4.1.8.3 being the most stable to date.

The RS modules are supported in 5.x software with 5.0.5 and 5.1.1.1 being possible candidates.

The new IST/SMLT design (introduced in 4.1.8.x and 5.0.1 and later) puts a larger demand on the hardware. Hence if you had previous run around 2-3% CPU utilization you might now run around 10-13% CPU utilization.

If you have a large number of VLANs you might also want to consider changing the FDB aging timer as that will help cut down on a lot of overhead.

Good Luck!

[dekdek]

thanks for you help, i can't believe...

here my fresh thinking (it's 8AM in south of France...) :
- i try snmpgetnext ... no success. oid 1.3.6.1.2.1.17.4.3.1.2 has no existance. so, i can say it's not really the same issue described by Nortel. And i'm in 5.1.1.1 not in 5.1.1.2 .
Yesterday before i write you, i thought it was just something to enable..maybe create a mib view.. an authorization to give...
- i try what you suggest : walk rcBridgeFdbAddress with oid 1.3.6.1.4.1.2272.1.14.1.1.2 ; no success (0 answer).
maybe i'm wrong with oid number.

- i don't use and don't need ist/smlt feature. can i disable these features ?
- i have just 3 VLANs : default, management (by IP) and a small one by port to isolate
a small group. No routing between VLAN. Our lan contains 2000 mac adresses. Do you think
i should read small,large or medium Campus Nortel recommandations ?
- in these conditions (simple configuration and simple requirements) , do you think it's a good idea to downgrade in 4.1.8.3 ?

i really appreciate your kindy help.
thanks.
Cristophe.

[dekdek]

maybe i found the good oid :
snmpwalk -v 1 -c public 10.10.x.x 1.3.6.1.4.1.2272.1.14.18.1.1
BUT the walk ends with error (i've never seen a such SNMP message in my life !!!)

SNMPv2-SMI::enterprises.2272.1.14.18.1.1.0.224.129.78.139.86.1 = INTEGER: 3
SNMPv2-SMI::enterprises.2272.1.14.18.1.1.0.224.216.10.77.39.1 = INTEGER: 3
SNMPv2-SMI::enterprises.2272.1.14.18.1.1.8.0.31.135.242.14.1 = INTEGER: 3
SNMPv2-SMI::enterprises.2272.1.14.18.1.1.8.0.32.177.99.209.1 = INTEGER: 3
SNMPv2-SMI::enterprises.2272.1.14.18.1.1.8.0.32.209.85.180.1 = INTEGER: 3
SNMPv2-SMI::enterprises.2272.1.14.18.1.1.8.0.55.62.240.82.1 = INTEGER: 3
SNMPv2-SMI::enterprises.2272.1.14.18.1.1.24.169.5.22.46.131.1 = INTEGER: 3
SNMPv2-SMI::enterprises.2272.1.14.18.1.1.82.84.0.235.42.44.1 = INTEGER: 3
SNMPv2-SMI::enterprises.2272.1.14.18.1.1.82.84.5.243.249.56.1 = INTEGER: 3
SNMPv2-SMI::enterprises.2272.1.14.18.1.1.100.185.232.187.202.182.1 = INTEGER: 3
SNMPv2-SMI::enterprises.2272.1.14.18.1.1.144.230.186.186.208.28.1 = INTEGER: 3
SNMPv2-SMI::enterprises.2272.1.14.18.1.1.144.230.186.186.208.31.1 = INTEGER: 3
SNMPv2-SMI::enterprises.2272.1.14.18.1.1.170.0.147.99.0.16.1 = INTEGER: 3
SNMPv2-SMI::enterprises.2272.1.14.18.1.1.170.0.147.99.0.18.1 = INTEGER: 3
SNMPv2-SMI::enterprises.2272.1.14.18.1.1.170.0.147.99.0.38.1 = INTEGER: 3
SNMPv2-SMI::enterprises.2272.1.14.18.1.1.170.0.147.99.0.40.1 = INTEGER: 3
SNMPv2-SMI::enterprises.2272.1.14.18.1.1.170.0.147.99.0.110.1 = INTEGER: 3
SNMPv2-SMI::enterprises.2272.1.14.18.1.1.170.0.147.99.0.124.1 = INTEGER: 3
SNMPv2-SMI::enterprises.2272.1.14.18.1.1.170.0.147.99.0.127.1 = INTEGER: 3
SNMPv2-SMI::enterprises.2272.1.14.18.1.1.170.0.147.99.0.132.1 = INTEGER: 3
SNMPv2-SMI::enterprises.2272.1.14.18.1.1.170.0.147.100.0.38.1 = INTEGER: 3
SNMPv2-SMI::enterprises.2272.1.14.18.1.1.0.3.75.188.24.96.2 = INTEGER: 3
Error: OID not increasing: SNMPv2-SMI::enterprises.2272.1.14.18.1.1.170.0.147.100.0.38.1
 >= SNMPv2-SMI::enterprises.2272.1.14.18.1.1.0.3.75.188.24.96.2

[qazzie]

running 5.x code with a 8691 is pretty stressfull, the code itself is more defensive compared to 4.1 and previous releases. The 4.1.8.3 works with the R-module and supports also the legacy modules (the E,M and non-E). That is ok, even in consideration that 4.1.x is manufacture discontinue. You've old modules yourselves so I wouldn't worry that much about it.

5.x code appearantly has undergo some reprogramming as we see many more issues regarding to the snmp features.

My best guess is that 99% of you clients are in the default lan, in fact you've no vlan segementation or whatsoever. Just keep it to the basics, the ist and smlt architecture ain't active if you're not configuring it.

q

[dekdek]

i'm agree with you ; downgrade into 4.1.8.3 seems to be the better way.
i have a 8692SF not a 8691SF (maybe it change your view ?) I needed it because of R modules. 8691SF is
now sleeping in a box...

thanks a lot.
Cristophe

[qazzie]

- please can you  answer my second question about enablesystemonitor in my first post ? i've read in your forum that when this option enable, cpu is around 10%. That's my case. In version 3 with 8691SF cpu was around 2/3% with exactly same config.

As Michael allready mentioned it is for monitoring it's own processes. When a switch fabrics goes fubar/crashes this feature "could" (it ain't a guarantee) create a wdtlog file (watchdog). Nortel/Avaya can do some deeper inspection in the root cause of the crash.

Regardless if it takes addiotional cpy cycles, you want this feature ON.

q

[Michael McNamara]

I believe this problem has been resolved in the 5.1.2.0 software release for the ERS 8600 switch;

SNMP GET/GET NEXT under certain conditions associated with the MAC (FDB) table was previously not working properly. These conditions lead to an issue that NetIQ PVQM would not function properly with an ERS 8600. This is now resolved. (Q02113802)

I just upgraded a single ERS 8600 switch and will test myself in the next few minutes.

Cheers!

[Michael McNamara]

I've confirmed that you can now walk dot1dTpFdbPort with 5.1.2.0 software (it was/is broken in 5.1.1.1 software).

Cheers!

[dekdek]

hi,
thanks Michael.
you're the best honestly.