|
Rob Clark from NetView Development asked me to post this as a follow-up to Michael's comments. Michael is right - to summarize: ITSA implements both active and passive methods for fault detection of connected ports. The passive method relies on NetView triggering ITSA to run the root cause algorithm to find the fault upstream. This was the only method available in v1.2.1. The active method (port status polling), new for v1.3, polls configured switches on a regular schedule. By default, both active and passive methods are working and can provide overlapped coverage for some switches. poll_all_ports=n Use this only if you want to optimize polling - it has no effect on what ports are being managed. All ports are managed - those not covered by the passive method will be actively polled - it simply removes the overlap. l2_polling.cfg port indicator 'C' Use this if you want to only manage ports connected to objects discovered in NetView (managed or unmanaged). Useful for concentrating on switch-switch and switch-router connections for instance. Michael mentioned the fact that all ports are shown in the Status Report even if only some are being managed due to the 'C' flag. This is under consideration for a future release. ----------------------------------------------------------------------------------------------- Becky Anderson Tivoli Business Automation Worldwide Sales Enablement Technical Evangelist: IBM TEC, NetView, Switch Analyzer andersrs@us.ibm.com Office: 630-568-7030 TL 994-7030 Cell: 630-240-2879 6302402879@mmode.com
Sorry for the confusion :( I will attempt to clear up part of that confusion in this append :) I will first address poll_all_ports and then will address the manage flag in the l2_polling.cfg file. But first let me answer a couple of questions. The Layer 2 Report (Discovery Report) will always show all ports that have anything connected. The poll_all_ports field and the port flag in the l2_polling.cfg file do not have anything to do with this. You will get root cause events (V) of switch ports attached to unmanaged devices with Port Status Monitoring. But the port flag in the l2_polling.cfg file should be set to A. The poll_all_ports field can be set to N or Y. POLL_ALL_PORTS I need to clear up the difference between POLLING and MANAGING. ITSA can NOT poll ports on a device and still manage the ports on that device. The following scenario will explain how. Let’s say poll_all_ports=n so that ITSA is not status polling all of the ports on a switch. The ports not status polled are the ones that ITSA has determined the physical connections for (I think sometimes referred to as L3 connections). The ports that are status polled are the ones I listed in the previous forum append, which are listed again here: 1. Switch ports in a redundant layer 2 path 2. Switch ports on switches that are in a remote campus 3. Switch ports where the connected device (downstream) to that port is unmanaged So ITSA is not status polling the connected ports, so-to-speak (the ports with devices attached to them according to the layer 2 report). Let’s say one of the connected ports has an outage. ITSA will not status poll this particular port during it status polling, so ITSA will not discover the problem on its own. However, NetView is status polling the region, and as a result, NetView can no longer reach a downstream device that is managed. So NetView issues an Interface Down Event for this downstream device. This triggers the ITSA correlation engine to query (or poll) devices in that region to determine the root cause. During this processing, ITSA will query (or poll) a port that was not initially being status polled in order to determine the root cause. So this is how a port that is NOT status polled by ITSA can still be MANAGED by ITSA. That is because during this correlation polling, this port will be polled in order to help determine the root cause. I hope that clears some things up. PORT FLAG in l2_polling.cfg Our ITSA v1.2.1 customers found that they did not want to receive root cause (V) events for certain switch ports that were attached to desktops. So they would simply configure NetView not to discover the downstream devices, or desktops. However, with Port Status Monitoring introduced in ITSA v1.3, all switch ports were capable of receiving root cause (V) events regardless of downstream devices not being discovered by NetView. So we needed a way to satisfy the v1.2.1 customers that did not want (V) events for certain switch ports attached to uninteresting devices. This is where the port flag in the l2_polling.cfg file comes in. This is as close as we could come to not allowing (V) events to flow for certain switch ports. Note that this port flag only applies to switch ports in the connected region (according to the DCR). Ports in a remote campus will be allowed to receive (V) events regardless of the port flag configuration. Now let’s look at the l2_polling.cfg file and the Admin Guide. They use words like poll and monitor when discussing the port field. Yes, this can be confusing. But please understand this. This port field does not determine which ports are status polled. The poll_all_ports field helps to reduce status polling, not the port flag. The port flag, on the other hand, helps to reduce which switches are capable of being polled during the correlation engine when determining the root cause of an outage. This will keep some switch ports from getting a root cause (V) event. Wheh! Did that help? STATUS REPORT Now, when you look at the Status Report, you will see more ports listed than you would expect when using the poll_all_ports and the port flag. There is probably some wording that needs to be worked out here. Should the Status Report show ports that are discovered by ITSA, or ports that are being status polled by ITSA, or ports that are capable of receiving (V) events? That is the question we need to discuss further over here. Once we investigate this further, then we can better decide on the wording in the output of the Status Report. Development may already have a better answer for the Status Report, so maybe you will get another append. Michael Webb, IBM Tivoli Q1CA NetView / ITSA SVT Email: mlwebb@us.ibm.com Ext: (919) 224-1410, T/L: 687-1410  Jane
Curry <jane.curry@skills-1st.co.uk>
Hi Michael, Sorry but I am now well confused. I have tried varying the poll_all_ports parameter in /usr/OV/ITSL2/conf/correlator.ini in collaboration with entries in /usr/OV/ITSL2/conf/files/l2_polling.cfg. I started with the default line in l2_polling.cfg which has the "ports" parameter set to "A", which I understand to mean "poll all ports of this switch". Modifying "poll_all_ports" in correlator.ini from y to n seemed to have no effect. Either way, a discovery report always shows all ports that have anything connected (whether the device hung off a port is in NetView's L3 database or not). From what you had said, I has expected setting poll_all_ports=n to poll only devices that are NOT in the L3 database. It looks like the l2_polling.cfg file with the ports field set to "A" overrides the poll_all_ports parameter??? Changing the l2_polling.cfg "ports" parameter to "C", which I understand to mean "only poll ports that NetView L3 is MANAGING", resulted as expected. I have a port with a device hung off that NetView doesn't know about and disconnecting it never produced any L2 events in NetView. Disconnecting a L3 discovered AND managed device results in both L3 and L2 Node events. Unmanaging the end device in NetView and repeating the disconnection test did not produce any events. Remanage it, and you get both L3 and L2 events. This is a switch on the same subnet as my NetView so there are no questions of Campus LAN confusions here. I guess my remaining question is how to get monitoring of L2 unmanaged ports as you describe below, as my testing seems to show the l2_polling.cfg ports flag always overriding poll_all_ports=n. Ny further guidance would be much appreciated. Thanks, Jane Michael Webb wrote: > Your comment on poll_all_ports happens to be opposite of the true > meaning. I have grabbed some information from the troubleshooting > guide and will place it here: > > File: /usr/OV/ITSL2/conf/correlator.ini > > From: > > [PortStatus] > poll_all_ports=y > > > To: > > [PortStatus] > poll_all_ports=n > > With this configuration (poll_all_ports=n), the PSM function only > status polls switch ports that do not have connections to them, which > are devices attached to switch ports as determined by IBM Tivoli > Switch Analyzer. The Layer 2 Discovery Report, as well as the Physical > View of a switch via the Web Console, will indicate which switch ports > have connections. These particular connected ports will be the ports > "not" actually monitored by PSM when the poll_all_ports value is set > to n. For these connected ports not monitored by PSM in this scenario, > the NetView Interface Down event will trigger the correlation engine > as before and result in the root cause event being generated for these > particular ports. > > In general, when poll_all_ports is set to n, PSM will only manage > (poll) switch ports that do not have connections to them, which > include the following ports: > > 1. Switch ports in a redundant layer 2 path > 2. Switch ports on switches that are in a remote campus > 3. Switch ports where the connected device (downstream) to that port > is unmanaged > > Hopefully item #3 above addresses your question about unmanaged devices. > > (Jane) Is there any way to look at a port (ideally in the physical > view but any mechanism would do) and say "stop port monitoring on > ports 1, 3 and 27", for example. Or," stop monitoring all ports whose > names start fa*". > > Answer: No. Not in this release. What you are referring to is what we > call the Port Table, which was not implemented in this release. > > Michael Webb, IBM Tivoli > Q1CA NetView / ITSA SVT > Email: mlwebb@us.ibm.com > Ext: (919) 224-1410, T/L: 687-1410 > Jane Curry <jane.curry@skills-1st.co.uk> > > > *Jane Curry <jane.curry@skills-1st.co.uk>* > Sent by: owner-nv-l@lists.us.ibm.com > > 06/29/2005 07:54 AM > Please respond to > nv-l > > > > To > > NetView mailing list <nv-l@lists.us.ibm.com> > > cc > > > Subject > > [nv-l] Switch Analyzer - manage / unmanage individual port status polling > > > > > Is it possible in ITSA to select specific ports on a switch to be status > polled? My understanding of poll_all_ports in correlator.ini is that if > you set it to no then it will only poll ports that have > NetView-discovered layer 3 devices attached, rather than polling all > ports? > > What happens if those attached devices are unmanaged? Does the switch > port still get polled? > > Is there any way to look at a port (ideally in the physical view but any > mechanism would do) and say "stop port monitoring on ports 1, 3 and 27", > for example. Or," stop monitoring all ports whose names start fa*". > > Thanks, > Jane > > -- > Tivoli Certified Consultant & Instructor > Skills 1st Limited, 2 Cedar Chase, Taplow, Bucks, SL6 0EU, UK > Tel: +44 (0)1628 782565 > Copyright (c) 2005 Jane Curry <jane.curry@skills-1st.co.uk>. All > rights reserved. > > -- Tivoli Certified Consultant & Instructor Skills 1st Limited, 2 Cedar Chase, Taplow, Bucks, SL6 0EU, UK Tel: +44 (0)1628 782565 Copyright (c) 2005 Jane Curry <jane.curry@skills-1st.co.uk>. All rights reserved. |
