cancel
Showing results for 
Search instead for 
Did you mean: 
Create Post
Level 14

Anyone seen Symantec's anti-virus updates replace the NIC driver with their new TEEFER2 NIC driver?

Jump to solution

We're having issues with anti-virus updates where it replaces the local system's NIC driver with their own.

It generates this error into the Orion Events console and makes it look like the node has lost SNMP by putting it into an Unknown state:

Mynodename Broadcom NetXtreme Gigabit Ethernet- Interface Polling stopped. Could not remap interface. Check ifDescription change.

The fix turns out I have to Node Admin to the node, delete interfaces, re-discover, re-poll etc to get it back right.

Has anyone else been seeing this or have a 'permanent' fix they can offer?

 

It's called the TEEFER2

The Teefer2 driver is responsible for capturing all network traffic entering or leaving a particular interface so that the packets may be passed to the personal firewall component of the SEP 11.0 client for analysis.
The Teefer2 driver works, in tandem with its associated miniport driver.
The Teefer2 driver runs in kernel mode, and passes information over to the teefer.dll for user mode operations.
Since all in- and outbound traffic is filtered through this driver, firewall rules are applied to all traffic passing through it.

Please note that it is not possible to disable the Teefer2 driver without removing SEP 11's firewall component.

0 Kudos
1 Solution
Level 13

Hi,

This is a change we recently put in for 10.0.  What has happened is that your interface has changed both ifDescription and ifIndex.  Hence, when we go to try and remap the interface on the rediscovery interval we don't find a match in the database.  If an interface changes both its index and name, we consider this a new or different interface.  This new event is to tell you of this situation and have you take action.

Most likely your interface has gone into the Unknown status as we no longer are gathering statistics and status for it.

The quick work around is to remove the Unknown interface and add in the newly named/indexed interface.  But with that you lose your history.  To keep your history you have to be a little more brave and update the database directly.

Steps for this:

1. Be brave... backup your database.

2. Stop NetPerfMon service

3. Checking the interface index and interface description match:

a.       SELECT InterfaceID, NodeID, InterfaceName, InterfaceIndex FROM
Interfaces WHERE NodeID = <MyBadNode>

b.      Walk the IF MIB on the device using the SNMP MIB Browser.
Compare the ifIndex with the InterfaceIndex in the table.  Compare the ifDescription with the InterfaceName in the database.  Both should be an exact match.

4. Update your Interfaces table with the actual values

5. Restart your standard poller (NetPerfMon Service)

Let me know if you have any questions.

Thanks

View solution in original post

0 Kudos
13 Replies
Level 13

Hi,

This is a change we recently put in for 10.0.  What has happened is that your interface has changed both ifDescription and ifIndex.  Hence, when we go to try and remap the interface on the rediscovery interval we don't find a match in the database.  If an interface changes both its index and name, we consider this a new or different interface.  This new event is to tell you of this situation and have you take action.

Most likely your interface has gone into the Unknown status as we no longer are gathering statistics and status for it.

The quick work around is to remove the Unknown interface and add in the newly named/indexed interface.  But with that you lose your history.  To keep your history you have to be a little more brave and update the database directly.

Steps for this:

1. Be brave... backup your database.

2. Stop NetPerfMon service

3. Checking the interface index and interface description match:

a.       SELECT InterfaceID, NodeID, InterfaceName, InterfaceIndex FROM
Interfaces WHERE NodeID = <MyBadNode>

b.      Walk the IF MIB on the device using the SNMP MIB Browser.
Compare the ifIndex with the InterfaceIndex in the table.  Compare the ifDescription with the InterfaceName in the database.  Both should be an exact match.

4. Update your Interfaces table with the actual values

5. Restart your standard poller (NetPerfMon Service)

Let me know if you have any questions.

Thanks

View solution in original post

0 Kudos
Level 14

Karlo,

One question - I'm finding that the issue only generates an event after the system gets rebooted. Can this be done at the time of the change instead of waiting for a system reboot?

Why can't the re-discovery pick this up before a reboot?

 

Thanks,

Larry

0 Kudos
Level 13

Hi,

Let me clarify what I think you are saying...

Are you saying that you must restart the NetPerfMon service to get the event or you have to restart the device to get the event?

Thanks

0 Kudos
Level 14

A restart of the device. Thanks.

0 Kudos
Level 13

Thanks for the clarification.

Let's dig into this deeper.  Are you saying that your interfaces change index and description while the device is running, the interfaces go into Unknown status, but then on a restart of the device we fire the interfaces disappeared events?

OR

Everything is fine, interfaces are polling, you restart your device and the indices and ifDescriptions have changed so we fire these events?

In the second case the device might be remapping ifIndex and ifDescription on a restart.  Usually just the indices get remapped.  What sort of device is this?

Thanks for the help.  If you want to get on a GotoMeeting, let me know and I can see this first hand.

0 Kudos
Level 14

It seems to be your Second Case...Here's the sequence I'm seeing:

 

1) Symantec Endpoint Protection v11 updates a Windows server (we have over 200 servers with various vendor's NICs.)

2) This anti-virus update is replacing the NIC driver with their new Teefer2-MiniPort NIC driver

3) Later - maybe hours or days this Windows server may be rebooted

4) Immediately after it reboots these events begin to show up about Remapping the Interface - they look something like this:

Broadcom NetXtreme Gigabit Ethernet- Interface Polling stopped.  Could not remap interface.  Check ifDescription change. Interface Disappeared

Broadcom NetXtreme Gigabit Ethernet- Interface no longer exists. Data collection terminated. Interface Disappeared

 

I had one Windows server reboot this morning and it took me probably an hour of time just getting the NIC corrected from 'Unknown' after that reboot.

This is why I asked if the normal Default rediscovery interval should be picking up on this Interface change.

I'm fine with a GotoMeeting...just let me know. Thanks.

0 Kudos
Level 13

Hi Larry,

My first guess as to why it is not being detected until after the device reboots is because the renaming and reindexing of the interface is not happening until the reboot of the Windows box.

Regular polling is happening until the reboot, when the anti-virus interface name change takes effect, then you are alerted to this change in Orion.

Is this the case?

0 Kudos
Level 14

Yes it is.

0 Kudos
Level 12

Hi,

Can I butt in with another problem here?it's almost the same issue..our gigabit and serial interfaces suddenly stopped polling, while fast-ethernet and non-cisco interfaces are showing tx and rx data..is the deletion of interfaces necessary here?

Thanks.

Paulo

0 Kudos
Level 13

Hi Larry,

Thanks for this observation.  The rediscovery should pick this up without a reboot.  I will add a bug to our tracking system for us to look at this.

0 Kudos
Level 7

Hi Karlo:

Yesterday, I upgraded my ORION NPM from version 9.5 SP4 to latest version 10.0. After that, I experienced the same issue with almost every Cisco device in my network. I have over 400 nodes and almost all are giving the same message under events: - Interface Polling stopped. Could not remap interface. Check ifDescription change.

How did this information change all of a sudden after the version change. I cannot go and delete and rediscover each and every interface as the count is around 8000. If this is a bug in version 10, shall I revert and go back to 9.5. I am not sure what is causing this behavior. I also did Microsoft patch upgrade and anti-virus update too along with this upgrade.

 

Please suggest.

0 Kudos
Level 7

For Cisco devices, you can ensure it will maintain the same ifIndex by putting in the global command:

snmp-server ifindex persist

Without this command Cisco devices (especially routers and module-based switches) will change ifIndexes everytime you add a module, or when you look at the router the wrong way...

~Everest MacDonald

0 Kudos
Level 13

Hi,

This is not a bug in 10.0.  In 9.5 and previous versions when an interface would get into the state where we could not remap it in rediscovery, then the interface would just go into the unknown state.  In 10.0 we added code to do even more checks to try and map the interface and then if all else fails, fire this event (Interface Disappeared).

Reverting to 9.5 will not help you.  Your interfaces have changed names and indices and will go into the Unknown status in 9.5 and you will be in the same situation.  10.0 is just telling you that you have the problem more obviously than just putting your interfaces into the Unknown status.

Please confirm that the interfaces that are giving you this error are indeed in the Unknown state and that the interface index and ifDescription have changed.  Even just a small sampling.

In order to check when these interfaces went into the Unknown status you could check your history tables to see when the last time we gathered statistics was. 

If you are getting this event in error (meaning the interfaces are still the same index and description), then we need to investigate more deeply on a GotoMeeting.

Let me know how I can help with the next steps.

Thanks

0 Kudos