Messages

My POC is willing to test on the PT network so I am hopeful we will see results this week or the next. Today was a crazy day of putting out fires so no progress.

Yes you can. On the KG configure your SNMP server as a GEM server. It only does SNMPv3. I don't remember for sure but I think it was using AES128/SHA for protocols. Also the MIBS can be found on one of the CDs either the KG firmware one or the GEM install one.

-Otanx

Can confirm in documentation it is AES128/SHA. No luck yet, but I've only been able to try polling the CT interface so far. Tomorrow I will ask my buddy to give it a shot from NAC on the PT side and see what happens. Unfortunately it's not my gear, so I have to be mindful about my demands 

Can you expand on the MIBS? All I've tried so far is a generic sysinfo poll but I do have an option to define OIDs under a different type of policy condition.

I feel a swell of pride as I understand every. single. term. used in this response.

It's true we have basically learned a second language 

Currently exploring whether I can pull information from a TACLANE with SNMP. Closest bit of info I can find is a 6-year old solarwinds forum post.

Knowing all TACLANE are a little different.. do they have the capability to host SNMP creds?

*edit*

For context, I am looking to pull this info into NAC using supplied SNMP creds on the device.

Just mentioning that I love GNS3. Haven't kept up with it but it's the reason I was able to pass CCNP back in the day.

Congrats for getting back in the saddle. We all go thru things, that's a fact, but getting back up after getting knocked down shows character.

I love it when a thread from the forum(s) helps me fix a problem

I'm moving current customer to that state. Although the latest best practice I read for Linux recommended SSH keys.

Btw used that analogy today and the previous lead got a kick out of it. I'm going to start doing that in meetings.

Is there a way to tune that behavior? There has to be a configuration file somewhere buried in the directory where the retries are set.

I'm stealing that analogy.

We pushed the agent to a few test machines 

So far it looks promising and gives me ammo for moving it to production quickly.

This is mostly just a rant to see if anyone has any ideas.

Our HBSS team has a trap set up to capture remote system login and it turns out our NAC solution is generating 1000+ logs on some hosts on a daily basis. I had them send me an example and it's what I would expect to see; vbs scripts and smb calls from NAC but a huge amount. It actually crashed their database server over a weekend.

Forescout inspects hosts on admission and whenever the policy recheck timers expire (usually 8-hours). There are exceptions to that which can be created thru policy but I am not currently running anything like that. Just discovery and interrogation and a few auto-remediation actions.

I suspect an issue with the vSphere integration or the VDI hosts themselves. When I look at the live host logs for the host entry I see a crazy amount of "host online" entries and noticed they are very slow to resolve LDAP info and populate host attributes in general.

In my mind NAC may be attempting to inspect but failing so just hammering it with retries.

Haven't had a chance to test it yet. NETOPS is done with upgrades for now so not a lot of switch reboots to replicate the issue.

We are thinking about implementing the call home post-boot script (or whatever it's called).. and just calling it a day.

Nice    my group and view names are all caps and I had (very) briefly considered at least lower-casing the views since that's the part that always breaks.

I am now deeply suspicious..

*Edit
NETOPS team is going to love me if this is the issue.. their Solarwinds SNMP groups are always breaking and wouldn't ya know it.. those views are all caps as well.

Possible. It's not consistent across the couple hundred switches, and only happens during a rare power outage, when NETOPS reboots for maintenance reasons, and more often on one of the enclaves that has a lot of reboots due to operational stuff and things.

Code Select Expand

show archive log config alltells me it always happens during or after the startup sequence. My best guess is a bug, because I can see the string in there and it's correct.

Right now it's only producing a minor effect on discovery, but when we start doing no shit NAC infrastructure actions it's potentially going to be an issue. For that reason I am going to ask them to open a TAC.

One of the guys mentioned we can add strings to the call home sequence that runs after startup so I may have them add the following and see if it helps:

Code Select Expand

no snmp-server group <group> v3 priv
no snmp-server group <group> v3 auth
snmp-server group <group> v3 auth read <view> write <view>
That will purge both the existing and duplicate group and then reconfigure it.

As the subject says. When the switches reboot they create a duplicate SNMP group that is missing the read and write views. I'm having to go in and delete the identical group on around 10 switches per day. Seems to only affect 9300 and 3850's.

Haven't been able to find anything other than a couple vague messages on Cisco support that trailed off on dead ends.

We sent a contingent but I wasn't on the list. Would have been great to chat!

While you are learning get familiar with the debug commands and why to use them. Break stuff in your lab and see what kind of logs it generates.

Good tip. This also reminded me to make sure I updated my email address here. I heard the other week that my old email provider is gone so even if I can remember my password for my old email account it no longer exists. Last year I had to get back into it to do a password reset on something.

Not the weekend, but I got my new Lego set delivered yesterday so time to put that together. It will take a few days, and then I need to figure out where I will display it. Has to stand up, and is 24" tall so it won't fit with the rest of em.

-Otanx

My recovery email wasn't working for some reason. Not even to spam or junk.

Bunch of guys at the office bought 1000+ piece lego sets to put together during an extended downtime