To: | nv-l@lists.us.ibm.com |
---|---|
Subject: | RE: [nv-l] HSRP interface gets deleted and recreated every minute |
From: | James Shanks <jshanks@us.ibm.com> |
Date: | Fri, 19 Mar 2004 16:58:28 -0500 |
Delivery-date: | Fri, 19 Mar 2004 22:15:37 +0000 |
Envelope-to: | nv-l-archive@lists.skills-1st.co.uk |
In-reply-to: | <OF31B7B1CC.F1AF05BE-ON85256E5C.0076241C-85256E5C.0076A4E0@ca.ibm.com> |
Reply-to: | nv-l@lists.us.ibm.com |
Sender: | owner-nv-l@lists.us.ibm.com |
Not forwarding Log Only events was a design decision made by development some time back so that people could run their TEC rulesets in the Event Browser and see what would be forwarded. And it is simply not true that all other NetView events get forwarded. Look at TEC_ITS.rs as we ship it. It picks out only specific events, but as you noted, those can still be suppressed by making them "Log Only". Most of the time there is little reason to forward "Interface Deleted". These events do get processed by the nvcorrd but the TEC adapter code in nvserverd does not forward them. You can see that they are processed if you turn on the nvcorrd trace (nvcdebug). In 7.1.4 you can also turn on the nvserverd.log to see what is actually being forwarded by nvserverd. See the Release Notes about setting the proper environment variable for that before you start the daemons. If you want to suppress an event from the Browser, I suggest an alternate ruleset in the browser or a filter. Your choice. There is no law that says operators have to use forwardall.rs. You can copy /usr/OV/app-defaults/Nvevents to the user's $HOME directory and set a new default ruleset in there. You can also create filters and have them applied automatically too, as explained in the Admin Guide. I have seen some customers with a filter file of quite literally over a hundred filters, so I know this works. James Shanks Level 3 Support for Tivoli NetView for UNIX and Windows Tivoli Software / IBM Software Group
Is it normal that event configured as "Log Only Events" in trapd.conf don't get processed by the rulesets and therefore don't get forwarded to TEC ? I was searching for the "interface deleted" event on TEC but it seams that it doesn't get forwarded by TEC_ITS.rs. All other events are forwarded and received by TEC. I also tried opening TEC_ITS.rs in an event browser and I get the same result (even after changing the filter so that I can see Log Only events). As soon as I changed the event to "Status Event" it started to be forwarded. If that is so, how can we handle events that we don't want Netview operator to see in the event browser but that we want TEC to receive ? Thanks, Salutations, / Regards, Francois Le Hir Network Projects & Consulting Services IBM Global Services Phone: (514) 205 6695 Francois Le Hir/Quebec/IBM@IB MCA To Sent by: nv-l@lists.us.ibm.com owner-nv-l@lists. cc us.ibm.com Subject RE: [nv-l] HSRP interface gets 03/19/2004 09:31 deleted and recreated every minute AM Please respond to nv-l Leslie, I agree: this is the only solution I found and I guess we will have to do it. But do you see all the additional work in maintaining a seed file with entries (i.e. loopback for example) for every device with HSRP interfaces on a big network ? I was hopping there would be an other way .... Also would you have an answer to this question ? Q1: why is netview sending an interface down event when it detect an HSRP switch over ? Salutations, / Regards, Francois Le Hir Network Projects & Consulting Services IBM Global Services Phone: (514) 205 6695 Pager: (514) 854 5709 Leslie Clark <lclark@us.ibm.co m> To Sent by: nv-l@lists.us.ibm.com owner-nv-l@lists. cc us.ibm.com Subject RE: [nv-l] HSRP interface gets 03/19/2004 09:07 deleted and recreated every minute AM Please respond to nv-l It is best to make sure that you do NOT discover things by their HSRP interfaces. Discover them by something permanent, and then let the hsrp interfaces get added. Also add the % entry to the seedfile to make sure they are handled as HSRP. If they have to have names, make sure they are not the same name as the routers are given. Cordially, Leslie A. Clark IBM Global Services - Systems Mgmt & Networking Detroit "Barr, Scott" <Scott_Barr@csgsystems.com> Sent by: To owner-nv-l@lists.us.ibm.com <nv-l@lists.us.ibm.com> cc 03/18/2004 11:55 AM Subject RE: [nv-l] HSRP interface gets deleted and recreated every minute Please respond to nv-l It is not possible to discover two routers specifying only the HRSP name. You will find one router only. -----Original Message----- From: owner-nv-l@lists.us.ibm.com [mailto:owner-nv-l@lists.us.ibm.com]On Behalf Of Francois Le Hir Sent: Thursday, March 18, 2004 10:49 AM To: nv-l@lists.us.ibm.com Subject: RE: [nv-l] HSRP interface gets deleted and recreated every minute I am already using the -S flag for netmon. I think it is necessary to give a name to the HSRP interfaces: when the device is discovered in the first place, it is done most of the time by the HSRP interface. If this interface doesn't resolve to anything, the whole device will be discovered without a name and we don't want routers without a name. I tested changing the resolution of the interface to something else than the name of the router but again this lead to devices being discovered with the name of the HSRP interface instead of the name of the device itself. I think I will open a ticket with Tivoli to see what they recommend to do for this issue. Thanks, Salutations, / Regards, Francois Le Hir Network Projects & Consulting Services IBM Global Services Phone: (514) 205 6695 Oliver Bruchhaeuser <oliver.bruchhaeu To ser@de.ibm.com> nv-l@lists.us.ibm.com Sent by: cc owner-nv-l@lists. us.ibm.com Subject RE: [nv-l] HSRP interface gets deleted and recreated every minute 03/18/2004 10:00 AM Please respond to nv-l I would not give the hsrp interface a name. NetView can also assign the interface to a router because the hsrp ip address can be found the routers arp cache. Oliver "Barr, Scott" <Scott_Barr@csgsystems.com> To: <nv-l@lists.us.ibm.com> cc: Sent by: Subject: RE: [nv-l] HSRP owner-nv-l@lists.us.ibm.com interface gets deleted and recreated every minute 18.03.2004 15:33 Please respond to nv-l Make sure -S is on your netmon in /usr/OV/conf/ovsuf -----Original Message----- From: owner-nv-l@lists.us.ibm.com [mailto:owner-nv-l@lists.us.ibm.com]On Behalf Of Francois Le Hir Sent: Wednesday, March 17, 2004 12:25 PM To: nv-l@lists.us.ibm.com Subject: [nv-l] HSRP interface gets deleted and recreated every minute Netview 7.1.4 and TEC 3.9 on AIX 5.1 I integrated Netview with TEC and found out that I was receiving a high number of interface down for a few interfaces (always the same and about every minute). After searching the logs on netview I saw that theses interfaces are HSRP interfaces. Netview detect a HSRP switch over of the interface, send an interface down interface and proceed with the deletion of the interface. Q1: why is netview sending an interface down event when it detect an HSRP switch over ? Q2: why is the deletion of the interface in netview not seen by TEC as a closing event ? (I use the standard TEC_ITS.rs and netview.rls) Probably this should be part of the logic in netview.rls on the TEC side. After searching further in the netview log, I saw in netmon.trace that the interface is always recreated in the same switch: Netview see the HSRP switch over, send a down event and delete the interface 15:09:26 : .//nl_snmper.c[319] : sending SNMP to 10.4.6.2 op = HSRP req = SysName reqid = 1334547 15:09:26 : .//nl_snmper.c[1146] : recv_snmp: from aclcyul02ci412.aircanada.ca (10.4.6.2) op = HSRP req = SysName reqid = 1334547 15:09:26 : .//nl_snmpstate.c[3651] : actonHsrpSysName: Node aclcyul02ci412.aircanada.ca snmp addr 10.4.6.2 old sysName (ACLCYUL02CI412.aircanada.ca) new sysName (ACLCYUL02CI411.aircanada.ca) 15:09:26 : .//nl_snmpstate.c[3686] : HSRP Switch: Node aclcyul02ci412.aircanada.ca snmp addr 10.4.6.2 old sysName (ACLCYUL02CI412.aircanada.ca) new sysName (ACLCYUL02CI411.aircanada.ca) 15:09:26 : .//nl_event.c[333] : DOWN event: 10.4.6.2 (aclcyul02ci412.aircanada.ca) 15:09:26 : .//nl_event.c[632] : HSRP interface 10.4.6.2 is deleted from aclcyul02ci412.aircanada.ca 15:09:26 : .//nl_fixup.c[137] : fixupIfaceSnmpConf() for 10.4.6.2 15:09:26 : .//nl_snmpstate.c[2752] : endSnmpOperation HSRP_POLL: Node aclcyul02ci412.aircanada.ca: polling next HSRP interface 10.4.11.2 Netview rediscover the HSRP interface: 15:09:38 : .//nl_pinger.c[375] : sending ping to 10.4.6.2 seqnum = 41472 ident = 57482 timeout = 2 15:09:39 : .//nl_pinger.c[1505] : -> received ping, ident=57482 seq=41472, from 10.4.6.2 () 15:09:39 : .//nl_pinger.c[1079] : calling allocIfObjectId() : ifaddr=10.4.6.2 15:09:39 : DEBUG: Get Unique Name For: Interface:10.4.6.2 15:09:39 : DEBUG: Create Object: 10.4.6.2 15:09:40 : .//nl_pinger.c[1992] : addNode: 10.4.6.2 (aclcyul02ci412.aircanada.ca) 15:09:40 : .//nl_pinger.c[2156] : Merging interface 10.4.6.2 with node aclcyul02ci412.aircanada.ca 15:10:11 : .//nl_fixup.c[476] : fixupNmNodeSnmpConfEx() for aclcyul02ci412.aircanada.ca 15:10:12 : .//nl_fixup.c[476] : fixupNmNodeSnmpConfEx() for aclcyul02ci412.aircanada.ca 15:10:14 : .//nl_snmpstate.c[4741] : ### atNetAddress = 10.4.6.2, atPhysAddress = 0x00000C07AC02, atIfIndex = 3 15:10:14 : .//nl_snmpstate.c[4810] : actonSecondaryIf: Found HSRP 10.4.6.2, best guess so far on aclcyul02ci412.aircanada.ca, physaddr 0x00000C07AC02 15:10:15 : .//nl_event.c[144] : changeIfEvent: node 10.4.6.2 eventnum ip Mask Change Node 'aclcyul02ci412.aircanada.ca' is in correct network 15:10:15 : .//nl_event.c[144] : changeIfEvent: node 10.4.6.2 eventnum if type Change 15:10:15 : .//nl_event.c[144] : changeIfEvent: node 10.4.6.2 eventnum if descr Change 15:10:15 : .//nl_snmpstate.c[7301] : endIfTable: Node aclcyul02ci412.aircanada.ca: updating HSRP interface 10.4.6.2 15:10:15 : .//nl_event.c[611] : HSRP interface 10.4.6.2 is added to node aclcyul02ci412.aircanada.ca 15:10:15 : .//nl_event.c[144] : changeIfEvent: node 10.4.6.2 eventnum if Alias Change I see the lines 15:09:39 : DEBUG: Get Unique Name For: Interface:10.4.6.2 15:09:39 : DEBUG: Create Object: 10.4.6.2 15:09:40 : .//nl_pinger.c[1992] : addNode: 10.4.6.2 (aclcyul02ci412.aircanada.ca) Q3: does it means that because the name resolution for 10.4.6.2 is aclcyul02ci412.aircanada.ca, then the interface is going to be recreated in the same switch as the one from where it was just deleted ? It should be recreated in the other switch (aclcyul02ci411) Q4: What is supposed to be the name resolution for an HSRP interface ? By default presently I resolve it to the name of the switch that is primary for HSRP. If I were to resolve it to an uniq name (deferent than the name of the primary or secondary HSRP switch), I would get device in the netview database that would get discovered by netview with the name of the HSRP interface (ie most often the first interface seen by netview when discovering a device) and this would be even worst a problem because a lot of my correlation logic rely on the selection name of a device. Thanks, Salutations, / Regards, Francois Le Hir Network Projects & Consulting Services IBM Global Services Phone: (514) 205 6695 |
<Prev in Thread] | Current Thread | [Next in Thread> |
---|---|---|
|
Previous by Date: | RE: [nv-l] HSRP interface gets deleted and recreated every minute, Francois Le Hir |
---|---|
Next by Date: | RE: [nv-l] Sun snmp daemon and netview, Qureshi, Fawad |
Previous by Thread: | RE: [nv-l] HSRP interface gets deleted and recreated every minute, Francois Le Hir |
Next by Thread: | [nv-l] Cisco-products.mib, Christopher J Petrina |
Indexes: | [Date] [Thread] [Top] [All Lists] |
Archive operated by Skills 1st Ltd
See also: The NetView Web