IP Fabric platform can be considered a Swiss Army knife for network engineers, providing one with trustworthy network verifications. One of IP Fabric's functionalities is here to help you continuously check if the network is configured properly or not.
Lets demonstrate this capability on one of the functionalities that would be typically configured by IP Fabric administrator, as it is one of those domain-specific configurations differing in every network — Authentication, Authorization, and Accounting, otherwise known as AAA, or Triple A.
Many individuals who have had to implement AAA on a router or a switch most likely have little knowledge regarding the commands that they copy to the router configuration. Most will simply utilize the AAA configurations from another functioning router or switch. Today, we are going to analyze the best AAA practices and how one can ensure its proper setting with our IP Fabric platform.
For those who are working with a larger network environment, you are most likely using a form of TACACS+ or ACS server running that is specifically designed for the management of logins to your devices. AAA works in unison with TACACS+ to provide efficient management of your logins’ security. In other words, this monitors who is able to log in (Authentication), what that user can do (Authorization), as well as track the commands that are used (Accounting). In the instance of server failure or reachability issues, it is recommended to have a backup local login user name and password that will allow access to your devices.
We shall now analyze what is considered the best practices for configuration.
aaa new-modeltacacs server ACS1
address ipv4 1.1.1.1
key 0 SECRET-KEY
tacacs server ACS2
address ipv4 2.2.2.2
key 0 SECRET-KEY
aaa group server tacacs+ ACS
server name ACS1
server name ACS2aaa authentication login default group ACS local
aaa authentication enable default group ACS enable
aaa authorization config-commands
aaa authorization exec default group ACS local if-authenticated
aaa authorization commands 1 default group ACS if-authenticated
aaa authorization commands 15 default group ACS local if-authenticated
aaa accounting exec default start-stop group ACS
aaa accounting commands 1 default start-stop group ACS
aaa accounting commands 15 default start-stop group ACS
Upon dissecting this model by line, we have:
This new-model essentially turns on the AAA functionality on the network device.
This addresses the setup of the TACACS server details, such as the IP address, shared key, and all other optional details.
This is intended for the grouping of specific servers into logical groups.
Here, we define how the device is authenticating the users who attempt to log into the device. First, there is the default authentication method with group of TACACS+ servers named “ACS”. Then, if it is unreachable, we shall implement the locally configured user account list.
This component explains that, for enable mode, the default authentication method with group of TACACS+ servers named “ACS” should be utilized.
This is regarding our goal to authorize each command that is being issued to the device.
This sets up the device and places the user directly into enable mode, upon his authentication (the if-authenticated keyword).
In this command, we are authorizing the level 1 user commands, which is similar to the non-enable mode.
Here, we are providing authorization for level 15 users against TACACS+. If TACACS+ is unavailable, then the local user account is used, instead. Upon authentication, the user will immediately be placed into exec/enable mode.
The logging in and access into the device is ensured by AAA Accounting
This provides the tracking of user activity on a given device for privilege 1 commands.
This provides the tracking of user activity on a given device for privilege 15 commands.
This provides tracking of user activity on a device, even if they have just logged in.
As you can see from this basic configuration, there is significant variability, resulting in complications of the verification of the proper function. This worsens with regular network operations, when the connectivity to the TACACS server fails, requiring a troubleshoot to determine the error. In such a situation, one would usually remove the TACACS configuration in attempt to resolve the issue. However, during the troubleshoot, it is common to forget about this change and leave the network open with local authentication or, perhaps, no authentication, whatsoever. Luckily, IP Fabric offers the newly released AAA verification, which can be used for the verification of the real live AAA settings.
Although our platform includes a few “out of the box” reports, we highly recommend adjusting these default reports in color with your custom verification checks, since the AAA settings differ between various companies. We recommend that you observe and spend time on the following:
Let us assume that we want to set up the verification report for the Authentication methods to verify this:
Which would be equivalent of the following piece of configuration
aaa authentication login default group ABACS localaaa authentication enable default group ABACS enableIt is generally recommended to have a single detection for all issues on the particular AAA method and to reveal the issue count on the dashboard.
This can be configured in the following manner:
Proceed to colorize the columns with specific details to green or orange, so that you will immediately see what is wrong from the dashboard counter created previously. In our case, we would need to setup additional rules as follows:
AAA Authentication Secondary method would look like this:
This will ensure the setup of the Authentication on all devices in the network. In regards to the remaining tabs (servers, lines, authorization, and accounting), you may follow the same logic to create similar specific rules that will configure IP Fabric to verify your specific AAA needs consistently in a matter of seconds.
In similar way, you can implement your custom verifications for any data table present in the system, to get complex view on your own network setting consistency!
If you have found this article resourceful, please follow our company’s LinkedIn or Blog, where there will be more content emerging. Furthermore, if you would like to test our platform to observe how it can assist you in more efficiently managing your network, please write us through our web page www.ipfabric.io
The wait is over, IP Fabric v3.0 is HERE! 🎉🙌
Quite often, when a company pushes out an update, it’s more about their developers squishing a few bugs than actually giving you shiny new toys - I mean, features.
This is not one of those updates.
In our quest to help you empower your network engineers, we’re rolling out an update that expands our platform’s capabilities in unprecedented ways.
In this update, we’re adding Network History functionalities that allow you to display the network state from any point in the past and compare it to the current state. This will enable you to do things like work on the platform while the discovery process is running, export any snapshot you’d like, and more!
Let’s go over the shiny new toys you’re getting in a little more detail so you can take full advantage of our platform.
Of all of our platform’s new features, this is the one we’re most excited about.
Unlike in previous versions where you could only see the latest network snapshot, our v3.0 update allows you to pull up any previous snapshots so that you can see how the network performed before. This new capability extends to all aspects of the platform, including technology verification tables and diagrams.
Thanks to IP Fabric’s newest update, you can now pre-load and instantly switch between up to five snapshots.
Now, instead of going through a lot of effort trying to figure out what changed in your network over the weekend, you can have an answer instantly.
Your days of waiting for IP Fabric’s platform to finish an operation before allowing you to use its other features are over.
The system now allows you to use all of IP Fabric’s features while simultaneously running other processes (like a network discovery), saving you even more time.
When the platform encounters a device that it isn’t able to log into, whether it’s due to misconfigured passwords, missing access control lists (ACL), or any other reasons that may arise, it no longer needs to scrap the current discovery process and start over again from scratch.
This update allows you to “discover” the missing devices manually by adding details like the username, password, IP address, or other pieces of information into the platform, saving you loads of time previously spent restarting discovery processes.
Thanks to the update, IP Fabric now allows you to run targeted partial discoveries on select devices. This can be useful in all sorts of scenarios. For example, if you’re using IP Fabric as part of the change management process.
In this scenario, to run a targeted discovery, select the devices affected by the network change. The process will automatically update their state data, saving you time and effort.
IP Fabric v3.0 comes with a snapshot management tool. That allows users to do all sorts of things with their network snapshots, including:
We’ve continued to improve our platform’s network discovery process, including improved platform detection.
Diagrams load even more quickly than before, especially in large network environments.
For those who want to take our platform’s automation to the next level, we’ve published our platform’s API documentation here.
Other various improvements and fixes that we haven’t outlined here can be found in the release notes here.
Interested in learning more about how IP Fabric’s platform can help you with analytics or intended network behavior reporting? Contact us through our website, request a demo, or follow this blog.
As the old saying goes, “the secret to getting ahead is to get started.” To help you start saving time with IP Fabric’s platform, I wanted to walk you through the initial setup process, step-by-step.
But before we get to the setup guide, we’re going to tackle the questions we hear the most from users when they’re setting up the IP Fabric platform for the first time:
IP Fabric’s platform is a plug-and-play OVA image that runs on VMware. Since it runs in a virtual environment as a standalone server, you don’t need any additional support services or licenses.
The discovery process is very similar to how administrator and network devices interact; the platform uses SSH or Telnet to connect to an active device and collects data using a predefined set of commands (which may vary between different hardware vendors and families).
No. Since there isn’t enough information included in SNMP, IP Fabric’s platform doesn’t use SNMP protocol to collect information. Now that we’ve covered all of that let’s move on to the initial setup process.
1. After you’ve successfully installed the platform in a VMware environment with the appropriate IP and default gateway properties, follow these steps:
2. Next, enter the “enable password,” which allows you to move from User EXEC mode to Privileged EXEC mode on some devices.
3. RECOMMENDED: Set the discovery starting point by entering the seed IP address (or addresses).
While this isn’t mandatory, we strongly recommend that you give the system at least one seed IP address to work with. Otherwise, the platform will try to discover IP networks by using traceroute over the gateway, which doesn’t necessarily produce the best results. In this example, I’ve used the management IP address of one of the routers in my virtual lab.
4. OPTIONAL: If you’d like, you can include/exclude networks from the discovery process. If you don’t create any predefined IP network boundaries in your discovery process, you can include any IP addresses (0.0.0.0/0).
5. The Command Line Interface (CLI) settings section is mainly for fine-tuning SSH or Telnet interactions between the platform and devices. Unless you encounter a significant amount of authentication retries or other errors during the discovery process, I recommend you stick with the default settings we’ve provided. For security reasons, we also give you the option to limit the maximum number of parallel sessions.
6. The Configuration Management settings section allows you to tell the system when you’d like to collect data from network devices, either through scheduling or when triggered by an SYSLOG event.
7. The Site Separation page has two boundary calculation options: the first is based on “Routing & Switching domain,” and the second is based on “Regular Expression.” (Note: the “Regular Expression” option is customizable.) I strongly recommend looking into both options to see which one best suits your needs. For this example, I’m using the “Routing & Switching domain” separation option.
8. STRONGLY RECOMMENDED: While this step isn’t mandatory, we strongly recommend configuring automated environment backups.
Congrats! Now that you’ve completed these steps, you’ve finished setting up your IP Fabric platform. Now, get out there and get discovering!
As the old saying goes, “the secret to getting ahead is to get started.” To help you start saving time with IP Fabric’s platform, I wanted to walk you through the initial setup process, step-by-step.
If you’re interested in learning more about how IP Fabric’s platform can help you with analytics or intended network behavior reporting, contact us through our website, request a demo, follow this blog or sign up for our webinars.
