lindberg16

Also for HP/Aruba chassis. Having this right now with v1 modules inside 5400zl's. For inventory purposes, I need to be able to note serial numbers and models of the modules/line cards also. Same with switch stacks. Same fix for both I'd thing (have a "container" type switch with constituents).

We have some fields that are pretty important to have data in, so this would be great. Drop down boxes help ensure data consistency (I use them a lot in NCM for identical fields). It would also be swell to have a little more logic for the fields (like a RegEx to require a certain pattern).

Nevermind, that looks like it's exactly what it does. Woot! Looks like that's my solution. Also thanks Mateusz O, you already told me how the blocks work with a screenshot and I apparently completely missed that point. Thanks all!

So, using the config block setup, does that mean it is locating the 2+ blocks VTY blocks as separate entities and actually running the config search regex on each found block individually? If so, that is totally, absolutely exactly the rule to pwn them all . .....And I get to go remodify my collection of VTY rules again.…

Based on a conversation with support. Even though the issue is transient instead of being all the way broken (or not), we seem to have a pretty high probability of resolution with: * Hotfix2 for UDT (due to a DB error showing up in C:\ProgramData\Solarwinds\Logs\Orion\UDT.BusinessLayer.log) * After testing out remote Event…

I've looked through the guides (though I may have missed or forgotten some salient point). Or read them too late in the day when my brain wasn't engaged anymore . How about this: When it applies a set of filters like: "Must Not Contain String X, AND Must Contain String Y" how is it evaluating those against the config file?…

Logically I think that sounds right, but it appears to be stopping the regex from finding anything whatsoever unless "line" is actually the first thing on the next line. In that case, it does not prevent it from continuing on to the next VTY block if transport input doesn't match in the first VTY block. If I stick with…

I am finding that the DCs occasionally self recover to a working state, but it's pretty rare. Had to set the polling rates down to the minimums to really see it happen though (5m).

Presumably you have a second rule for the second block of VTY? I'm currently looking at doing these two I think (which I think are equivalent to what you guys are suggesting, but without actually using Search Config Block piece). Plus the fleet of other stuff in the VTYs I have to match and a variant for the Con0 stuff.…

Wow... I completely and totally missed that entire "Search Config Block" setting in there. Now I want to see what regex that gets turned into on the back end . I bet it looks a lot like the workaround I eventually came up with last night, except that I wouldn't have spent hours trying to figure out a fancy way of doing…

Would I be accurate in thinking there's not a good way to filter that? ie: only show a single DNS zone, or conflicts in specific subnets, or such?

That works VERY well and is exactly what I was hoping to accomplish! Hooray! Seems to even catch multiple bad servers sprinkled about the list of logging hosts. Looks like making it a non-capture groups was extremely important and something I had not tried in my earlier flailing around with regex. I had been playing around…

You know, that's such a simple solution it might actually be the best one. If I am already reporting on having the correct logging servers, then any extras MUST be wrong. It would be interesting if one could make policies dependent on each other (if X is passed, then check Y, or vice versa).

Would this not require that the rogue server be at the end of the list? I cannot guarantee where in the list such a server might fall. I think that's where most of my trouble lies... That, plus I can't really say how many there might be . My network has grown over time and come to include a variety of gear previously run…

Round one: Used these settings for the config block. Start: ^logging host .* End: ^(logging|access-list|snmp|end) It appears to now reliably catch rogue servers at the end of the list of logging servers. It does not appear to catch anything anywhere else on the list. I will keep poking at it for a while, but if you have…

Say in a switch's config I had this: ------------------------------ ! logging host x.x.x.x logging host y.y.y.y logging host z.z.z.z logging host a.a.a.a ... ----------------------------- I have a policy that looks for logging hosts x, y, z. These are the current hosts that I want on there. I want to create a policy that…

I figured out part of it finally... The laziness had to go somewhere else... (.*\n)* becomes (.*\n)*? Now I'm left with this: While this now stops the search at the first "transport input ssh" like I wanted, it fails when that first one isn't in there (if the first VTY has "all," but the second has "ssh," the check still…

Did anyone ever get anywhere with this? I am experiencing the same issue with UDT 3.2 randomly failing to DCs. For my part I have noticed that manual polling via the UDT Job Status page seems to either: not do anything or is just failing immediately. If I kick one off by modifying a DCs polling interval, that seems to work…