Are you affected by CVE-2024-3400?

Your business relies on IT to deliver services to your customer. But what happens when there is a failure, can you afford downtime?

Whether or not you can afford it, you should ask yourself this question: how to manage network risk to maximise service availability?

In this blog post, we are going to identify some risks you may be facing today, so you can understand better how to tackle them.

1.    Baseline – complete visibility of the network

It is extremely important to have the full picture of your network. You cannot correctly manage devices or infrastructures you do not know about, or only have partial information.

1.1.                 Inventory

The inventory is often used as the source to define the list of devices you will have under maintenance. What happens if a device fails and is not under maintenance?
You will need to order a replacement, which could take days, weeks, or more to arrive before you are able to restore the service. In the best-case scenario, the service is resilient, so only resiliency is affected, but while waiting for the replacement to arrive, you would be in a situation where you cannot afford for anything to fail.
In the worst-case scenario, if the service is not resilient, the service will be unavailable until the replacement of the faulty device.

So, we understand that maintaining an accurate inventory is crucial, but it can be very challenging:

1.2.                 Documentation

We have a very similar problem with the documentation of the network and making sure it stays up to date. Otherwise, you are at risk of not being able to solve efficiently any issue arising on your network. A partially updated diagram could be very misleading for any change preparation or troubleshooting. This could cause unnecessary downtime which can be avoided.

Obviously, you may have processes in place to ensure diagrams and relevant documentation are accurate. But we all know that this is very time consuming, and let’s be honest, there are some more exciting projects you would rather be working on.

2.    Eliminate network inaccuracies

Monitoring tools are there to alert you of an issue, but what happens if there are some anomalies which are not considered as an issue, i.e., no SNMP traps are sent, nor syslog, and you have not experienced any symptoms because the problem is only on a backup link or device.

How do you detect these inaccuracies to fix them before they become service affecting?

2.1.                 MTU Misconfiguration

MTU can be the source of issues when the MTU is not configured consistently, for example, you have a primary path working as expected, but the backup is misconfigured. It means you will only notice the issue once the primary path fails.

It can be difficult to confirm MTU is correctly configured on all your devices: how long would it take you to collect the information for all the interfaces’ MTU, parse that data and analyze it so you know for each link how is the MTU configured on both end?

Having instant access to the links with inconsistent MTU, allows you to be proactive, so you can fix any links which could be causing issue on your network.

interfaces MTU
UPTIME is MONEY – Managing network risk to maximise service availability 1

2.2.                 BGP neighbors not receiving any prefixes

The second hidden issue I wanted to discuss here, has caused a major downtime in my previous experience: a BGP neighbor with no received-prefixes.

This is the situation we were in, two BGP neighbors to a service provider, but on the backup router, we were not receiving any prefixes. BGP session was still established, so no issue from our monitoring tools, everything “seemed fine”.

BGP no rec pref red
UPTIME is MONEY – Managing network risk to maximise service availability 2

And one day, it happened: we lose our primary connection, and here starts our massive downtime. We no longer have access to this service.

We knew the resilient path had been working in the past, but what we didn’t know is that it wasn’t working anymore. How can we detect this so we can resolve similar issues before they cause downtime?

For further information on this point, you can check the following blog post: BGP resiliency and received prefixes | IP Fabric | Network Assurance

Those examples show how you could be facing an issue on your network and be totally unaware of the situation.

3.    Restore services

We want to be proactive as much as possible to avoid any downtime, but there are situations when issues happen. So, we need to be reactive and work efficiently in order to restore the service.

3.1.                 End-to-end path for advanced troubleshooting

Using IP Fabric’s End-to-end path, will very quickly display all devices involved with passing traffic from a source to a destination. IP Fabric doesn’t just look at the network data, it includes firewalls in the path, so you can visualize any policies which may block the traffic.

With such a tool at disposition, it becomes easy to quickly pinpoint the source of the issue without having to connect to any devices, check the logs on different firewalls or spend time finding the latest diagram. Everything is available in one single and dynamic view:

E2E fw block
UPTIME is MONEY – Managing network risk to maximise service availability 3

3.2.                 Past representation of your network topology

When you are troubleshooting, you often lack the understanding of how it was working before. It would be very useful to have a view of a previous topology, for example, from the day before. Then, by comparing both topologies, you can observe and quickly identify what has changed:

E2E compare
UPTIME is MONEY – Managing network risk to maximise service availability 4

In the example above, you can see in the previous snapshot, there was only 1 link to the MPLS cloud, the 2nd one in red was not present, but is operational in the latest snapshot.

IP Fabric, as a network assurance platform, shines a torch on all those weaknesses and proactively inform you of potential issues existing in your network.

There is a lot more IP Fabric can help you with. To explore further, join our webinar on the 30th of June at 11am CEST: IP Fabric - FSI Webinar You can get in touch with us through www.ipfabric.io and follow our company’s LinkedIn or Blog, where more content will be emerging.

Transcript

Today we will go through a quick demonstration of the IP Fabric platform and its main features. The IP Fabric platform is the network management system that helps companies to empower network engineers and teams to discover, verify, and document large scale networks within minutes.

IP Fabric's lightning-quick processes intelligently discover over 3,000 network infrastructure nodes an hour and collect more than 2,000 configurational and operational state data per active network device.

The system then generates a digital model of the entire network with the switching/routing and security logic built-in. Since IP Fabric can identify both known and unknown devices, it eliminates the need for manual inventory processes in the company.

To initiate the IP Fabric platform successfully, it first needs to be installed on VMWare 5.0 or later and have an access to all infrastructure devices via SSH or Telnet with correct credentials.

Of course we can apply additional settings, such as IP subnets to include or exclude from discovery, limit the bandwidth or the number of concurrent sessions during and many other.

Once the discovery is finished we have a complete digital image of the entire network, which we call the snapshot. In every snapshot, we can run end to end path simulations, view all operational data about the network, analyze network topology maps or verify the network’s overal state with the Assurance Engine.

That is all for the introduction, now let’s get started with the demo.

We are currently in the Snapshot management area. We have 4 snapshots loaded in the RAM memory and they are available to be explored immediately. Historical ones are stored on the Hard drive and can be loaded to RAM anytime. We can decide to add more devices to currently active snapshot or reinitiate discovery on selected devices and get the newest data.

We have the Connectivity Report which contains all IPs that the platform interacted with during discovery process, which is great for troubleshooting purposes and it underlines complete transparency that the user has when using the platform.

With our current snapshot, we discovered almost 600 devices and it took us about 10 minutes. We have the list of sites that serve as a logical groups for network devices. The user has full control over the Site Separation mechanism, sites can be based on devices’ location or function, it’s up to administrator to decide.

Now we will examine the inventories. We have full and very detailed visibility into all types of inventories: Devices, Interfaces, End-points or End-Of-Life milestones, which are very important for lifecycle management.

In any inventory or technplogy tables Sorting and Filtering tools are available. For example, in case I want to find all Juniper SRX devices within the inventory, I will fill in the vendor and the platform field and I have results available in seconds.

I can choose which parameters will be visible or change the columns’ order. Any filtered output is easily exportable to a CSV document and can be shared with the team. By the way, all search or filter functions available in graphical user interface are obtainable via API as well, with full documentation available online or in the platform.

MTU

Because the platform is the tool not only for viewing static data but also for analyzing behaviour of variety of protocols. Addressing any inconsistent states is very easy. As an example we can explore data for the Maximum Transmission Unit (or MTU) on all links just by few clicks.

I will search for an MTU, where we have all the information available. To discover any issues, we’ll just click on available verficiation and we have results in seconds.

Detecting inconsistent MTUs on all transit links in large scale networks can be a really time consuming to get, there can be tens of thousands links to verify.

After discovery, we only export the data and send it to operations team immediately. This type of proactive network management will help us to decrease the number of network issues in the future.

If we desire to have a visual representation of MTU results in diagrams, we will click on the site button and check for MTU in there.

OSPF

Similar applies if for any other supported technology. In the platform we can research routing and switching protocols, stacks, clusters, 802.1X, PoE, Quality of service and many many more. The IP Fabric platform is a search engine for any network.

As an example may be OSPF protocol.

We are very quickly seeing all OSPF sessions with all details on the network. By a single click we can tell if there are any sessions down or in transition state and use it for documentation purposes or for troubleshooting.

In addition we can go back in time, switch the snapshot and see historical results, which makes it an amazing tool for root cause analysis.

Assurance Dashboard

Last feature we would like to delve into, before we move on to diagrams, is the IP Fabric’s Assurance Dashboard, where all these verifications are displayed in one place.

IP Fabric is supplied with dozens of predefined network verification checks. These checks can be altered based on your needs, or you can create your custom ones very easily.

There are many focusing on Management protocols, Performance, Stability, Routing and Switching protocols, and we can go on..

All verifications are provided with explainers and all these results can be exported to the Network Analysis Report, which can be generated by the platfrom on demand.

Diagrams

And now the Diagrams. With the IP Fabric, you have full and detailed visibility on a protocol level. There are not only physical links between devices in the topology maps but all relations between devices. If it's OSPF or BGP session, Spanning-Tree or discovery protocols.

All views and layouts can be easily modified or built from the scratch with the amazing View Builder feature. All available in a multivendor environment.

The network devices can be repositioned freely and the layout can be saved for future analysis. And the same diagram appears in the Low-Level design document, which can be also generated by the platform.

What we can quickly explore in terms of layers is Discovery protocols, which can be considered as physical layer mapping, Spanning-Tree or Mac layer and Routing protocols, all separately or together at once in a diagram.

In case we desire, for example, to track a single VLAN in the topology, we will click on any trunk link, select the VLAN number and immediately analyze which ports are in forwarding or blocking state for any particular VLAN or examine where the root bridge is.

The same we can do for any previous snapshot, we may go back in time and analyze any topology from the past!

Now a quick look at routing protocols. In the current topology, we have OSPF and BGP present, apart from that we support all mayor routing protocols including EIGRP, RIP, IS-IS or Label Distribution protocol from the MPLS environment.

By interacting with any link or node we get more detailed data, we can add the cost on OSPF links if we want to and export the topologies.

In addition we are able to visualize connected servers, IP phones or PC or wireless access-points if they are present. Then visualize QoS, Access-Lists or First Hop Redundancy protocols, detect single points of failure or non-redundant links.

End-to-End

Now we will move on to the E2E path testing. The End to End path testing can be essential for root cause analysis, verifying the post-migration state of selected application paths across the network or any ad-hoc testing related to client’s portion of the network. The IP Fabric platform enables seamless and extremenly fast path testing on the created mathematical model.

It takes literally seconds to complete standard end to end simulations for switching, routing and security portion. It is also possible to test end-to-end in MPLS networks based on labels.

So let’s test on our own:

With the path check feature, selected paths can be saved and continuously verified by the platform with every new discovery automatically.

Documentation

Maintaining network documentation may be a tedious and difficult process, that requires a vast amount of time. Which is the main reason why many companies are necessarily hiring external resources to complete the task.

To simplify the process, IP Fabric platform automates network documentation. There are currently two types of automated documents. The first one is the LLD document, which provides a detailed network overview for each business location, including topology visualization.

The second one is the Network Analysis Report, which will give you an overall report of your network, including network state checks.

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.

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.


Best practices

We shall now analyze what is considered the best practices for configuration.

aaa new-model
tacacs 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 ACS2
aaa 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:

aaa new-model

This new-model essentially turns on the AAA functionality on the network device.

tacacs server <name>

This addresses the setup of the TACACS server details, such as the IP address, shared key, and all other optional details.

aaa group server tacacs+ <group_name>

This is intended for the grouping of specific servers into logical groups.

aaa authentication login default group ACS local

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.

aaa authentication enable default group ACS enable

This component explains that, for enable mode, the default authentication method with group of TACACS+ servers named “ACS” should be utilized.

aaa authorization config-commands

This is regarding our goal to authorize each command that is being issued to the device.

aaa authorization exec default group ACS local if-authenticated

This sets up the device and places the user directly into enable mode, upon his authentication (the if-authenticated keyword).

aaa authorization commands 1 default group ACS if-authenticated

In this command, we are authorizing the level 1 user commands, which is similar to the non-enable mode.

aaa authorization commands 15 default group ACS local if-authenticated

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.

aaa accounting exec default start-stop group ACS

The logging in and access into the device is ensured by AAA Accounting

aaa accounting commands 1 default start-stop group ACS

This provides the tracking of user activity on a given device for privilege 1 commands.

aaa accounting commands 15 default start-stop group ACS

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.


AAA intent network verification tables
AAA intent verification tables

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:

Example

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 enable

It 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:

For a more detailed overview of how to set this up, view the video below:

AAA Authentication catch-all-errors rule setting
AAA Authentication catch-all-errors rule setting

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:

Secondary method verification for AAA Authentication tab
Secondary method verification for AAA Authentication tab

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.


Snapshots 📸

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.

1*S MO7jdRuzkmJP4V eBAWw
Snapshots in End-to-End view

Always-Available Platform 💻

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.

Platform snapshot availability during running discovery
Platform snapshot availability during running discovery

Include Additional Devices

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.

Adding new devices to already finished discovery
Adding new devices to already finished discovery

On-Demand Device Data Refresh 🔄

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.

On demand data refresh for a site with changed network configuration
On demand data refresh for a site with changed network configuration

Snapshot Management 📁

IP Fabric v3.0 comes with a snapshot management tool. That allows users to do all sorts of things with their network snapshots, including:

Demonstration of snapshot renaming, commenting, locking and downloading of the network snapshot data
Demonstration of snapshot renaming, commenting, locking and downloading of the network snapshot data

Additional Improvements

Discovery

We’ve continued to improve our platform’s network discovery process, including improved platform detection.

Diagram Performance

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 websiterequest a demo, or follow this blog.

Today, it is our pleasure to announce new version of our IP Fabric platform. Version 2.4 is in a general availability release that extends our product capability in technologies usually found in datacenter and network edge environments, namely VXLANs and Multi-protocol BGP address families.


Features — Protocols and Technology Support

VXLAN

For customers using Virtual eXtensible LAN overlays in their datacenters, we are adding support for this technology in both Diagrams and Technology Tables. The platform provides with information about Virtual Tunnel Endpoints (VTEP) in the network, their peers, configured interfaces and VXLAN VNI.

1*yPXywPUzbP2evUk68BsPtA
VXLAN Topology in Diagrams

Flow export

To support traffic recording efforts of our clients we are introducing support for global Flow Exporter overview and configuration verification. Regardless if the technology used is NetFlow, Flexible NetFlow, IPFIX or sFlow, we now provide you with detailed overview of the devices configured for traffic exporting. Additional details provide information about all the configured collectors and interfaces used for exporting traffic to them.

1*1nZAGNZUKF bBNJfi0FPSA
Flow Export Overview with drill-down details

Simple Network Management Protocol

Although the Simple Network Management Protocol is one of the oldest network protocols, it is still widely used in network management for network monitoring. However, there are some risks associated with use of this protocol. First, when this protocol was created in 1980's, the idea was, that it will be used also for network configuration and second, there are well known community names for both read-only and read-write access to the devices. Last issue is, that except the last version of the protocol — version 3, there is no way to ensure authentication and privacy of the messages. Our tool can help you to improve the security of your network in couple ways — within seconds you can identify devices that are still using well-known public/private communities, find the devices that are using some non-standard communities and get rid of legacy SNMP protocol versions 1 and 2 completely, replacing it with SNMPv3. Of course, if you are using SNMP traps, we provide you with overview of all the SNMP Trap hosts configured on your gear as well.

1*dzLSP5RKEKR6f37zawPWYA
Global SNMP community verification

Logging

All devices are generating amount of logging messages that can be stored locally on the device or, ideally sent to a central syslog servers or SIEM systems for correlation of events. Our tool again arms you with a visibility into what syslog servers are configured and where, so you can easily clean up the legacy servers configurations and ensure that the proper servers are in place, so that you don't miss any message your device wants to tell you.

1*tB3NeXSgLAJU2F7cL ZK6w
Syslog server IP verification

Further improvements

We have worked hard on network discovery, where we improved detection of various platforms. The Diagrams now load much faster then ever before, especially in big network environments. Last, but not least, we now support BGP address families, where we provide with a new Technology table with all address family sessions configured along with their state.

For those interested in serious automation with our platform, we have published documentation of our platforms' API. You can find it here.

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.

Companies are spending big money on defensive measures against the outside attackers — investing into Next-Generation Firewalls, Intrusion Prevention Systems and Proxies. The inner network, however, was considered safe place, where nothing bad can happen.

This understanding has thankfully changed in recent years, especially with rise of mobility technologies allowing employees to work anywhere and concepts like Bring Your Own Device (and some major incidents as well, of course). Today's network administrator has to think about various types of devices connecting to the internal network and policy, how to treat them to keep the internal network and business critical systems safe.


Solution

Solution to this problem is to deploy network wide 802.1 x protocol, that allows the user to access the network just if he is able to authenticate himself using a username and password, or a valid certificate issued by the company. Various options are available and listing all the details would be worth a book.

It is not always straightforward deployment, as these types of projects tend to be slow and need proper user testing, because otherwise the users won't be able to work at all. Usually there are user machine issues that need to be rectified temporarily by disabling the 802.1 x protocol authentication on the switchport of the affected user and after couple days, no one knows, where the security is applied and where it is not.


Verification

With IP Fabric's platform, finding information about the ports secured by 802.1 x protocol is easy, and you can specify verification to tell you which network edge ports, connecting to end stations, are open and which are secured properly. For example, simple verification could do this:

Setup is actually trivial, with the most complicated part being the selection of what is physical and what is virtual interface. Good news is, that we've configured this already for you. The actual outcome of this verification looks like this:

802.1 x protocol Interfaces Verification
802.1x Interfaces Verification

Instead of manually verifying every interface or developing custom script for every platform out there, hundreds of hours of engineering time can be saved using this continuous verification instead. Also, it can be used as an evidence of how the 802.1 x protocol rollout project is proceeding and that the network is properly secured and there are no open interfaces, that would render your network insecure.

This will ensure the setup of the Interfaces on all devices in the network. In regards to the other part — RADIUS server configuration — this was covered in one of the recent articles, so you may check it out to create similar specific rules that will configure IP Fabric to verify your specific AAA needs consistently in a matter of seconds.

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.

Today, we are pleased to release the new version 2.3.0 of IP Fabric platform. This release assists engineers in having a more complete overview of their network by adding support for additional technologies that are especially seen in Internet Service Provider and enterprise Internet Edge environments — Multiprotocol Label Switching (MPLS), Port Mirroring and Network Address Translation (NAT). We have again improved usability of graphs, that now support site renaming directly in graphs and also support visual separation of site interconnects from the general transit clouds.


Features — Protocols and Technology Support

Multiprotocol Label Switching (MPLS)

Frequent feature request from Internet Service Providers and Enterprise customers as well was Multiprotocol Label Switching (MPLS) support. In this release we are adding full support for Label Distribution Protocol (LDP), where we provide the network operator with detail about configured interfaces and what are the LDP neighbor relations, and we also provide with global network MPLS Forwarding Table that is very similar in function to a global routing table we have already. The MPLS is of course supported in graphs as well.

1*wuUSSiRK4oB4kymQYYw5jQ
MPLS support in Diagrams

Network Address Translation (NAT)

Network Address Translation is pretty common in the enterprise Internet Edge service block and particularly in ISP networks to “sort out” their IPv4 address exhaustion issue. Today we are releasing support for Network Address Translation rules, to give you full End-to-End visibility and packet behaviour.

1*DGoqeJLHDbVHpreFkcaEyw
Network Address Translation Tables

Port Mirroring (SPAN)

To support traffic recording efforts of our clients we are introducing support for port mirroring overview and configuration verification. Regardless if the technology used is Switched Port Analyzer (SPAN), RSPAN (Remote SPAN) or ERSPAN (Encapsulated Remote SPAN), we are supporting the overview tables including all the low level details like ACLs applied to the monitoring session or QoS used for the mirrored traffic.

1*1FZ0ilyLRgXubB4O5ynqPg
Switch Port Analyzer (SPAN) Interfaces Tables

Diagrams Improvements

Easier site renaming

The graphs are definitely one of the most used functionalities of our product. Many of our clients inquired for the functionality to be able to rename sites in easier way and we are now supporting renaming of site directly in the site diagram.

1*JMJlmYTYDcEgIAgtSeiEsQ
Site Renaming in Graphs

Multiple transit separation

To get better overview about how the specific sites are interconnected, we are now introducing the separated transits for other sites in the diagrams. This way you will be able to find out what is connected to what much faster than before.

Easier diagram orientation

When the graph is opened through the hostname link in any table, it will zoom automatically to that specific device.

Device Graph Detail Auto-Zoom

Discovery

OUI setting

There are couple vendors out there that are using for their devices Organizationally Unique Identifier (first half of MAC address specific to vendor) that are belonging to other companies. This was causing issues during device discovery as our platform is connecting to well-known vendor OUIs, because we don’t want to log onto everything in the network, but just the network devices. However if you happen to have a device with special OUI portion in its MAC address, this is no longer an issue and you can override the default behaviour and select the MAC addresses, that are relevant to your environment.


Further improvements

We have worked hard on improvements in datacenter portfolio, where we improved support for Cisco Nexus Fabric Extenders (FEX) modules and their environmental parameters. For the memory hungry devices we have added a support for memory consumption overview — this can be used to verify if your network will support further IPv4 BGP routing table growth or it is running already at its' limits.

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.

Today, we are delighted to release the new version 2.2.9 of IP Fabric platform. This release assists engineers in having a more complete overview of their network by adding support for additional vendors, such as Arista, HP Aruba, Huawei and F5 loadbalancers. It also provides support for new routing protocol IS-IS and improves End-to-end Path Lookup, which is now more intuitive — we now allow you to save and continuously verify specific path forwarding results, as well as display them on the dashboard.


Diagrams Improvements

Continuous End to End Path Forwarding Verification

E2E Path Lookup is one of the most useful features of our platform, allowing you to test and visualize the forwarding of the packet through the network. This will allow you to verify if the traffic is being forwarded as it is intended. Many of you have inquired regarding the possibility to be able to continuously verify specific traffic patterns, such as reachability of the CRM systems from branches. The verification now also extends to verifying if forward and return traffic are symmetric and if the traffic is being flooded somewhere within the network.

1*6lK
End to End Path Verification Setup and View

Improved End to End Drill-Downs

In order to receive the detailed information more efficiently regarding End to End path forwarding decision, we have implemented a new tab, which aggregates all the information found during the examining of the specific packet flow.

1*Q2Cxx9LWchPPXq kXzvLJw
New End to End Verification Detailed Tab

Hide Unnecessary Diagram Detail

There are situations when you may wish to only see the edge devices, whether it be for troubleshooting or to see how the WAN works without distractions from the LAN devices and links. Therefore, we are introducing a function that allows for this.

1* npMV58JPRdGcYKm8ONhig
Hiding Non-Edge Devices

New Vendors Support

As a committed vendor independent software company, we are always working towards implementing additional support for more widespread networking equipment, so that our software may analyze and verify any network. Therefore, we are providing discovery support for Arista, Hewlett-Packard Aruba, and Huawei networking equipment and loadbalancers from F5.

New Routing Protocol — IS-IS

While we support general routing verifications regardless of the protocol or the route source, with version 2.2.8 we have expanded detailed routing protocol support and added EIGRP and RIP. Today, we are proud to announce that our platform supports all of the most important routing protocols, as we have implemented IS-IS.

Other Improvements

Last but not least, based on the feedback that we have received, we have decided to add DNS resolve support for the Discovery Error reports, making it far easier to identify the devices that have not been properly discovered. We are also adding a graphical historical overview of the number of discovered devices.

1*TSLX HAl2NapzkVYRQAkeg
Snapshot History — Number of Devices Discovered

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.

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's 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-model
tacacs 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 ACS2
aaa 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:

aaa new-model

This new-model essentially turns on the AAA functionality on the network device.

tacacs server <name>

This addresses the setup of the TACACS server details, such as the IP address, shared key, and all other optional details.

aaa group server tacacs+ <group_name>

This is intended for the grouping of specific servers into logical groups.

aaa authentication login default group ACS local

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.

aaa authentication enable default group ACS enable

This component explains that, for enable mode, the default authentication method with group of TACACS+ servers named “ACS” should be utilized.

aaa authorization config-commands

This is regarding our goal to authorize each command that is being issued to the device.

aaa authorization exec default group ACS local if-authenticated

This sets up the device and places the user directly into enable mode, upon his authentication (the if-authenticated keyword).

aaa authorization commands 1 default group ACS if-authenticated

In this command, we are authorizing the level 1 user commands, which is similar to the non-enable mode.

aaa authorization commands 15 default group ACS local if-authenticated

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.

aaa accounting exec default start-stop group ACS

AAA Accounting ensures the logging in and access into the device.

aaa accounting commands 1 default start-stop group ACS

This provides the tracking of user activity on a given device for privilege 1 commands.

aaa accounting commands 15 default start-stop group ACS

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.

AAA intent verification tables
AAA intent verification tables

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:

For example, 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 enable

It 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:

For a more detailed overview of how to set this up, view the video below:

AAA Authentication catch-all-errors rule setting
AAA Authentication catch-all-errors rule setting

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:

Secondary method verification for AAA Authentication tab
Secondary method verification for AAA Authentication tab

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.

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.

Today, we are delighted to announce a new feature loaded release 2.2.8 of our IP Fabric Network Infrastructure Management Platform — Engineering Edition. This release is full of new exciting features and improvements, ranging from a new routing protocol support — EIGRP and RIP, through additional technology verification for Authentication, Authorization, and Accounting (AAA) to improvements for the existing tables and verification checks. We have listened to your feedback closely and implemented major improvements for the diagrams, so that you can display more information both visually and in the related popup windows.


Diagram improvements

Many of you have asked for ability to display additional information directly in the diagrams and we are delivering it today. Now you can display or hide additional network detail without going to the Technology Tables.

Enhanced link labels and styles

There is a number of options to display detailed information for various layers and technologies:

1*wfed v43ptcgB69UwiCVqQ
New diagram labels for L3 links, EIGRP and OSPF sessions
1*RwaTJuSNzq99HP5jLAaFQg
New diagram labels for BGP

These new options, however, created an issue — the diagrams became overloaded with information. Therefore, we created a new straight link style that works better than the default Bezier curves, especially if you need to display more details on multiple parallel links.

1*mJ1E67cehYvQBqN8o3LnCg
Enhanced link labels and style options

Rethinking link style calculation proved very popular, because straight links can represent more information more clearly, especially when displaying multiple paths or protocols.

End to end path lookup with failure indication

One of the awesome features of IP Fabric is its End to End path lookup. It allows you to test whether the traffic will be allowed through the whole infrastructure or not and why. However, in complex networks it was not very easy to find what is wrong with the path as there were only arrows to signify the resulting decision, and no clear indication of the problematic devices. To improve visual interpretation of the path lookup result we implemented highlighting of the devices which are causing a problem or are prohibiting traffic to pass, be it either because of ACL, Zone Based Firewall, Routing or Switching. Forwarding verification result has also been added to the device popup windows to provide detail from routing and switching perspective.

1*Lro5LvnpReeRkubeiC5rDA
End to End path forwarding verification

The path lookup is truly end to end, meaning we do not stop at the first device denying the traffic but finish the path simulation, so that we can highlight all the issues on that particular path.

1*rDLuCn2NVezbqD6uDb7 A
End to End path with problematic devices highlighting

This enables you to prepare all the necessary changes at once, instead of moving hop by hop.


Support for new protocols and other improvements

Authentication, Authorization and Accounting (AAA)

IP Fabric now provides detailed information about configured Authentication, Authorization and Accounting (AAA) servers, policies and how they are applied through your network infrastructure. This can be used for validation that all devices are hardened properly, that the users logging in are being properly authenticated and authorized, and that all their activities on the device are logged and accounted for.

1*LztCEU0si38GxpSB1r3m A
Authentication, Authorization and Accounting (AAA) verifications

This is an example of how intent-based verification is much more robust than text-based golden config checks. With IP Fabric's platform you can ensure that general AAA rules are followed throughout your network, and that operational state complies with your intent of how the network is supposed to operate, regardless what OS device is running or if the device is HP, Juniper or Cisco.

Addition of routing protocol support for EIGRP and RIP

While we support general routing verifications regardless of the protocol or the route source, with 2.2.8 we’re expanding detailed routing protocol support from BGP and OSPF to EIGRP and RIP. As always, the data is presented in the structured technology tables, the knowledge base, as well as in Diagrams.

1*dYp9 2b4lAIhYqNb7SXNIQ
EIGRP visualization in tables and diagrams

BGP support was also improved, providing out-of-the box information about internal and external peering as well as details on BGP session uptime. This is very helpful for troubleshooting flapping or recently converged BGP sessions.

Other improvements

Last but not least, based on the feedback, we improved out-of-the-box verification reports to be more accurate and useful. In addition, we added DNS resolve support for the Connectivity report, which makes it easier identify the devices that have not been discovered properly.

1*Wkt87hCTGev2Z SsAOT zQ

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.

We're Hiring!
Join the Team and be part of the Future of Network Automation
Available Positions
98 North Washington Street
Suite 407
Boston, MA 02114
United States
This is a block of text. Double-click this text to edit it.
Phone : +1 617-821-3639
IP Fabric s.r.o.
Kateřinská 466/40
Praha 2 - Nové Město, 120 00
Czech Republic
This is a block of text. Double-click this text to edit it.
Phone : +420 720 022 997
IP Fabric UK Limited
Gateley Legal, 1 Paternoster Square, London,
England EC4M 7DX
This is a block of text. Double-click this text to edit it.
Phone : +420 720 022 997
IP Fabric, Inc. © 2024 All Rights Reserved