I ran into a situation where the NuGet credentials I entered into Visual Studio were not in my Credential Manager. Deleting the package source in Visual Studio, closing Visual Studio, reopening Visual Studio, and recreating the package source allowed me to re-enter my credentials.
Hence, if the credentials don't exist in the Credential Manager, it appears deleting the package source and closing Visual Studio may be sufficient to cause Visual Studio to forget the saved credentials.
You can also try looking in %AppData%\..\Local\NuGet\v3-cache. Some credentials (or configuration pointing to the credentials) are stored in a subfolder that starts with a guid, then a dollar sign, then the feed address. In my case I needed to reset my credentials for the Telerik feed, and the folder was named:
You can delete your credentials from the Credential Manager or force update the package reference by executing the following command in the Package Manager Console: dotnet nuget update source "your package name" -s "your package source/url" -u "your username" -p "your password/token"
At least for Visual studio 2017 besides cleaning up credential cache - it does makes sense to wipe up nuget cache folder, as it keeps nuget packages downloaded locally - and then will not try any remote connection while restoring.
The dotnet version of the tool shortens versions from 1.0.1.0 to 1.0.1, but NuGet still treats them as equivalent. We had 1.0.1.0 coming from our old feed and 1.0.1 coming from the Github feed. This confused NuGet and we had lots of issues besides being prompted for the credentials, as I'm sure you can imagine.
For the most part, SNMP v2 was little more than a feature pack upgrade to version 1. With SNMP version 2, SNMP was made more efficient, better at management, and had more monitoring capabilities. Its downside was that it lacked any kind of authentication or encryption mechanism.
The one thing it did have in that regard was community value. A community value is essentially a pre-shared key on the device that you're managing. That community value gave whoever had access permission to read all the sensors there. You could even read/write all of the sensors on there without any encryption or authentication mechanism.
For those of you who are security-minded, you'll know that's not a great arrangement. It's not ideal to only have two options, particularly those: not giving a user any access at all, or giving them full read/write access. And that's where SNMP version 3 improved on its predecessors.
Object Identifiers and Management Information Bases (OID/MIB) are pivotal to understanding SNMP. An Object Identifier (OID) is the identifier that SNMP devices use to manage each entity within a network. One object on a network can produce a lot of data, much of it unrelated to other data from the same device.
The Management Information Base (MIB) is the database that manages and stores all of those objects. The OID names and points to an object listed within the MIB hierarchy. To help explain the OID and MIB, imagine that you're an inventor and built a network-enabled coffee pot.
Being the good inventor that you are, you realize that the key to a good network-enabled coffee pot is sensors that can be monitored with SNMP. For instance, maybe you want to be able to tell if it's in a brewing cycle or not.
That way, you could have a monitoring system set up on your computer that tells you when your coffee is done brewing. Maybe you also configure a monitor for the temperature, so you know how hot the coffee is. Or, you want to install a toggle that indicates if somebody brewed caf or decaf. Or maybe a sensor to indicate how full the coffee pot is. That way, you'll never be the one who gets the dregs of the pot.
Each of these sensors and data flows can be assigned its own object identifier (OID), which in SNMP is a numeric string. An example might be "1.3.6.1.2.1.2.2.1.1." They're formatted like that because the MIB is like a catalog. You go to different sections of the catalog to find the right thing for the job. You categorize the sensors so that the similar jobs are all grouped together.
Just having an MIB isn't enough, though. You also need a monitoring system, such as PRTG. The monitoring system uses the MIB to understand your device, its sensors, and the data coming off of it. It also monitors all the other devices on the network.
Cisco has a robust MIB, which we'll use to explain this. Accessing their SNMP Object Navigator used to be as simple as a Google search, but now you need an account to do so. Nevertheless, we'll use their MIB.
We'll start by searching Cisco's SNMP Object Navigator for "ifindex." This will show us the entry for interface indexes on Cisco devices. We learn from their documentation that the OID for their interface index is "1.3.6.1.2.1.2.2.1.1." On the same page, we can see what that number signifies: the whole tree of how it's categorized inside the MIB.
Traps are asynchronous notifications that SNMP agents send to the SNMP manager when specific events happen. Think of these like push notifications on your phone. Essentially, the SNMP is letting you know that some event you decided was important has occurred. These events can be anything from a critical system error to a significant change in system status.
Traps play a crucial role in network monitoring and management by allowing the SNMP manager to receive real-time notifications about events or conditions. SNMPv3 traps provide secure communication between agents and managers, ensuring notifications are reliable and tamper-proof.
When configuring SNMPv3, you'll define which traps the SNMP agent should generate and send to the manager. This involves specifying the type of events or conditions that trigger a trap and the destination (i.e., the IP address of the SNMP manager).
Three new elements were introduced with SNMP v3: SNMP View, SNMP Group, and SNMP User. These new elements work together to provide authentication and encryption to every interaction with devices on a network and help make sure no one is reading, writing, or accessing data they shouldn't be.
Additionally, SNMPv3 introduced the concept of inform notifications, which are similar to traps, but provide a confirmation mechanism. With informs, the SNMP manager acknowledges receipt of the notification, providing greater reliability in communication between the agent and the manager.
The SNMP View defines what you're able to see on a Cisco device. Using SNMP gives someone a lot of access to network devices. If you know what you're doing, you can even pull device passwords. An SNMP View can secure your network management by restricting that.
So, you might create a View that says, "I want people to only see the interfaces of this device." Or, "I want people to only see the statistics of that interface." You could even go further and say, "I want people to only see the statistics of one, specific interface of the device."
That last View would be helpful if we imagined a partner company that connects to a device on that interface because they want to see the statistics of how much traffic is being sent. You can create a view that restricts it to just that. In that case, the partner company gets the data they need but doesn't have full read/write access to the entire device.
An SNMP View must be associated with an SNMP Group. The SNMP Group defines the type of access: read-only or read/write. It also specifies what kind of security is enabled during the interaction with the device in question.
An SNMP Group is then associated with an SNMP User. An SNMP User is added to SNMP Groups to limit their accesses and views. While associating the User to the Group, the username, password, and level of encryption and authentication are defined.
To explain how to configure SNMP, we're going to configure it on a Cisco router. That's not the only thing that SNMP can be configured on, but it's a good template, and Cisco has an excellent MIB. To start configuring SNMP v3, we'll begin with configuring an SNMP View. SNMP Views restrict what people have access to on the network device.
Remember: directly copying and pasting the OID from the MIB is one way to add it. Equally valid is to type the OID name. But be warned: it's very case-sensitive. "ifindex" wouldn't work where "ifIndex" is expected.
But now that we think of it, that's a pretty lame sensor, isn't it? We named it "all-access", but as it stands, this only allows people to see the interface index and anything that's below it in the hierarchy. If we really wanted to create an all-access View, this would be more appropriate:
You probably shouldn't give every View access to everything below the iso, which is why we also walked through the interface index configuration. If you wanted to further restrict it to one interface, you would head back to your MIB, work out which interface index you wanted to give access to, and drill down from there. Because it's a hierarchy, you can be increasingly specific about what sensors your users will have access to.
Let's also create a different View, one that isn't so permissive. We'll create one for people to monitor the interface. If you find the Interface entry in the OID tree, you'll see that it allows someone to monitor all the interfaces, all the indexes, and everything below that:
Now that we've created the View, the Group will be created and associated with that View with the following command. Just like in creating our View, to explain how to configure an SNMP Group, we'll start with the complete line of code and then break it down section-by-section:
Now, big question: what sort of authentication/encryption? There are three options. First, no authentication or encryption (noauth). Second, authentication only but no encryption (auth). Third, authentication and encryption (priv). Obviously, "priv" is probably what most people are going to want if they're using SNMPv3:
With that line of code, you've created a Group. You created GROUP1. It's going to use SNMPv3, require those looking to access it to authenticate and have encryption, and allow anyone on it to have read-only access to ALL sensors on this device.
b37509886e