So, you may know why network observability is becoming increasingly important for enterprises, but what could it look like within a large enterprise toolscape?
Could it be one tool, or is it a strategic combination? How are these tools integrated, and what could enhance an effective network observability practice? While the exact answer will differ across organizations, what's certain is that no matter what your observability platform looks like, it will benefit from automated network assurance data.
Whether you're trying to move beyond monitoring, or you already have a more mature observability practice in place, assurance is the final puzzle piece that injects trust and validation into network operations.
What you need to know in order to have a successful observability practice may seem subjective - but there are some elements that we posit are non-negotiable, with the knowledge of how central the network is to the success of modern enterprises.
A primary cornerstone of observability should be an understanding of the actual, observed, true state of the network, at a particular point in time. This knowledge is vital for observability, as you cannot continuously observe what you don't know exists.
Proper discovery, inventory-taking, and collection of device state data, as well as mapping this out in topologies and visualizing the data, is almost impossible to achieve manually in dynamic enterprise networks, as the result would continuously be out of date.
Regular snapshots of the network give operators a means for comparison from one point in time to another, a way to answer "what's in my network" and "what's changed?"
We've mentioned before that observability is less about the network on a device level (we can leave that for monitoring) and far more about the end user. With this front of mind, easy access to how an application behaves through your network from endpoint to endpoint is invaluable.
Without end-to-end visibility, troubleshooting requires network teams to spend valuable time on repetitive tasks, while said issue could be affecting the end user.
With this in place, teams can act proactively, lowering mean time to resolution thanks to an observable network.
Read: End-to-end path simulation with API
To easily leverage network data in a useful manner for observability, it must be normalized across vendors and environments and made consumable in technology tables, or rich and flexible network models.
It's not uncommon for teams to find a way to access the network data they need but then be stuck on how to actually get value out of the data. Should they invest the time to interpret the network data they have? How can they effectively use it for reporting? Can other teams, beyond the networking team, understand it easily?
Too much undigestible data could in fact hamper your observability, muddying the view of the network with unwanted information. For this reason, any assurance solution providing network data must prioritize flexibility if it is to be useful for observability; allowing the user to choose what they see, a simple and intuitive GUI, and clear presentation of this wealth of data are all imperative.
Automated network assurance provides this network inventory, configuration, and state information, visualized and normalized across vendors and environments, via simple API integration.
Contextualized data that is normally either very difficult or impossible to gather from traditional monitoring systems, such as the end-to-end path of a packet through your network, is automatically mapped and modeled. It's ready to be used wherever you need it most (and by whichever team needs it most!).
IP Fabric's integration ecosystem has already established some pairings that elevate network observability efforts.
Use insights from IP Fabric to make monitoring more contextualized and useful for your team. Avoid alert fatigue by focusing on what's important to your teams. IP Fabric can easily provide the PRTG monitoring platform with network topology analyses for a more comprehensive view of the network.
Download: Paessler PRTG Solution Brief
Splunk is a versatile tool that helps put network data into action; IP Fabric can bolster its usefulness by providing actual network state data easily via API.
Read: How to integrate IP Fabric with Splunk
Another monitoring and assurance match made in heaven, Centreon and IP Fabric work together to take advantage of IP Fabric's advanced discovery process to ensure all the information you could possibly need is being monitored, and nothing can be overlooked.
See Documentation: IP Fabric and Centreon or Read Centreon's Blog Post: Integrating Network Assurance and IT Infrastructure Monitoring for stronger networks
It's clear that whatever your observability strategy, whether still relying on traditional monitoring or already moving toward a more mature implementation, it needs network assurance to answer to those blind spots, and give you confidence through continuous validation of your actual network state.
The world of network automation is far from immune to buzzwords designed to lure you in with promises of the perfect solution to your network woes.
Some are very appropriate metaphors or powerful terms that effectively crystallize the offerings or services that would seem otherwise abstract. Others are all frosting and no cupcake. Often, these dazzling terms are presented as the function of an offered tool or service, rather than what they are – a goal, or ideal, that tools can help you get closer toward.
Let’s dig into the meaning behind the marketing – what are industry voices saying, and does it line up with what they deliver? Is it a buzzword, or is it brilliant – or both? Here’s our take.
Data democratization refers to making network data, or information about your network, freely accessible to anyone in an organization who might need it beyond just the team working directly with the network (e.g., security teams, cloud teams, C-suite). The benefits include reduction of bottlenecks in workflows through self-service processes, enabling asynchronous work, harmony across teams, and reduced MTTR.
We use this term proudly at IP Fabric – not only because alliteration is irresistible, but because it succinctly sums up the above-mentioned benefits without overstating what the concept refers to practically.
The ambition of a digital twin – that is, an exact virtual replica of your network you can use to simulate and test changes – is sound, in that having a true digital twin would be extremely useful. Real-time updating of this network representation to reflect your actual network state should mean it’s always accurate and behaving as your real-life network does. However, we know that reality is not so.
The issue here is not with the concept – if you can find a true digital twin, sign us up - but the term is often confidently applied to products and platforms that are not a digital twin at all. Generously, some may be a digital cousin, in the sense they share some DNA with your network but fundamentally, they won’t behave exactly the same under the same conditions (which is the whole point).
That’s what the term implies, right? You would expect a digital twin of your network to be a precise DNA match.
It's not really a digital twin if:
Claiming that a digital twin provides end-to-end security posture visibility creates a risk for network operators who believe that they are working with a true digital twin. They may be making decisions based on ultimately useless simulations that can lead to unintended consequences in the actual network.
A so-called digital twin is great when used as a tool for guidance – remember that real-world conditions can always introduce variables that your digital twin can’t account for. Nothing substitutes the insights of the actual network engineer, whose job can be made a lot easier with a digital twin. Their knowledge and observations are hugely augmented by tooling, but not always replaced.
Our network model, which achieves similar goals – test changes, see how data flows through your network – but is proudly of its own DNA; its point-in-time representation of your network normalizes output from different vendors to supply a flexible, sharable understanding of your network behavior. Assurance then ensures that you know exactly what your actual network state is.
This refers to decisions about - and changes to - the network being led by intent, or a defined set of business objectives that represent how you desire your network to operate.
By starting with intent, usually stored in a Source of Truth repository, like the open-source Netbox, and having every network operation be in service of aligning with that intent in an automated fashion, you are ever closer to having your actual network state match your dream network state.
Intent-based networking is largely attractive to enterprises because it can help manage the complexity inherent in a modern, dynamic network.
Anyone in the network automation space has likely seen this term a thousand times over – maybe the first few times, it elicited a vision of utopia – everything you could ever need to operate your network visible in one place. The ultimate consolidation of important information.
After the 999th time, however, it’s clear with so many products and platforms claiming to offer this, they can’t all be the single pane of glass that your organization needs.
If they were, you would only ever have one place to go to do anything in the network infrastructure:
Additionally, it would have to serve a myriad of different lenses that operators approach the network with – cloud teams, security teams, and leadership. The single pane of glass is an ideal to strive for, not a silver bullet that you can buy.
Platforms claiming that they are “it”, rather than showing how they can accelerate you toward this goal.
Tools that gather data from disparate places and present it in a single, consumable form, in an accessible manner, help move the needle toward a unified network view for all teams; as mentioned, it’s a useful metaphor for a goal to work toward.
A Single Source of Truth – that all teams can trust - is touted as a key element of network automation projects, especially so for intent-based networking.
By nature, IBN requires that you express a single, consistent intent against which you build, test, and validate your network state.
Your source of truth is the ultimate repository of your network desires that are determined by clear business goals, which your actual network state should be continuously validated against.
When any one tool claims to contain the entirety of your intent. Expecting enterprises with dynamically growing networks to contain their entire intent in a single system is unrealistic. That said, there are tools that consolidate the information from these systems – your sources of truth – to make them useful, consistent, and updated for network automation projects.
IP Fabric does the same for your actual network state so that you can validate it against your source of truth.
You likely have, as mentioned above, many sources of truth containing information about elements of your network.
A single source of truth can be a helpful data cleansing element to consolidate these repositories managed by different teams and smooth out duplicates, inconsistencies, and interdependencies to ensure that your “sources of truth” are as accurate and valid as possible.
WATCH: For the Journey 2: From Design to Source of Truth with Network to Code & BlueCat
In an industry that is constantly innovating, buzzwords ebb and flow in the zeitgeist. We’re certainly not above overusing some of our favorites to describe our offerings concisely and concretely when applicable – as discussed, buzzwords can be brilliant, if used honestly.
However, overuse can muddy the waters with regard to how these terms are applied. Before your eyes light up at the next promise to solve all your problems, tactically assess – is it a buzzword or brilliant (or both)?
Typically, an organization's network isn't a single thing. It's a collection, a network of networks if you will, which work together to deliver the connectivity from user to app, from sensor to data repository, which underpins application service for an organization.
There are networks of different types, using different technologies, connecting different domains, using multiple vendors; each must be interconnected and interoperable in order to deliver the packets which carry application data from application workload to user. The number and depth of these interactions bring complexity to the network of networks and with it being dynamic and alive, this complexity grows daily.
The biggest challenge that modern network teams face is managing that complexity, along with the scale that adoption of connected applications has brought to the modern IT landscape. And as network engineers, not only are we constantly reminded that the best way to cope is to automate, but we recognize the necessity.
The idea is to maintain a centralized management point for the network which can provision service and deploy change using as few touchpoints as possible. Typically, that might mean introducing:
These approaches all have pros and cons of course, but typically are very focused on delivering an outcome for a specific task, for a specific vendor's equipment, or in a specific network domain. As such, testing of success of automation tends to be focused and task-based too. And while this has a certain level of value in ensuring that tasks themselves aren't broken, it's hard to verify that the impact of change to the network isn't farther reaching, or that further change is required to enable the capability we’re trying to introduce.
Consider the case where you create a new subnet in your private Cloud instance – this is easily verified that it has happened through the API into your favorite Cloud provider. But does that mean it is available and usable? Not necessarily – we might need to make sure it is advertised into our on-prem network, redistributed over our SDWAN into our campus, and that policy is updated to allow traffic to pass to it.
Network Assurance has the goal of validating that the network is operating the way you intend it to and enabling corrective action when your dynamically changing network drifts too far from your intended state. Importantly, the scope for network assurance is the whole network end-to-end, not limited to a specific vendor or domain.
By using IP Fabric's automated network assurance platform, it's possible to validate:
IP Fabric uses snapshots of this model to build up a picture of changes across the network over time. Those snapshots can be of the complete network, scheduled regularly, or they can be ad hoc or partial views, depending on the desired effect (particularly useful before and after change implementation).
And this is the key. When changes are made in the network, it is not likely to be enough to simply test that the desired configuration has been pushed to the device. The impact of that change is likely to be felt further afield and so it is necessary to look more holistically at the outcome, as looking at the change in isolation can be misleading. Is a successful config push successful if it’s impacted your network elsewhere, and therefore your end-to-end service?
You can examine the state of the affected device and that may help but in reality, the best outcome is to validate that once tasks are completed, the overall change has had the desired impact on end-to-end service. And naturally, the only way to accurately verify that end-to-end behavior will be as expected is to not limit the scope but test against a model of the whole network.
And as IP Fabric's API allows snapshot creation and refresh, along with querying of those tests, it is the perfect tool to incorporate into an automated workflow to carry out that big picture validation.
Recently, the IP Fabric team was in Las Vegas, where we shared the stage with Itential at Tech Field Day Extra at Cisco Live 2022. We showcased what it means to integrate network assurance into real network automation processes, and how that turns Network Automation from a point solution to a small problem, into a key component of the complete Self-Driving Network.
Watch the Tech Field Day video below to see exactly how smart integrations can accelerate your network automation:
WATCH: Scaling Network Automation (with Itential)
WATCH: Closing the Loop with Network Assurance (with IP Fabric)
WATCH: Integrated Network Automation and Assurance Demo with Itential & IP Fabric
We're proud to share that IP Fabric earned top billing in Gartner's Cool Vendors in Network Automation list for 2022. Gartner members can access the report here.
While network automation garners a lot of interest from large enterprises with complex networks, its successful implementation lags behind. Fear of change, resource strain, and operational and organizational labyrinths to navigate are all factors that hold organizations back from fully embracing the inevitable.
That's where cool vendors come in. We're here to bridge that gap between understanding that network automation will bring agility, efficiency, and simplicity to your network, and actually making it happen by directly addressing the roadblocks in your way. Cool vendors aren't afraid of breaking new ground - we march forth, illuminating the road to innovation in your network.
We use automated network assurance to revolutionize how enterprises manage increasingly complex networks by bringing robust visibility and insight into network behavior.
We're not just giving back time and resources to our customers, but also changing how an entire industry approaches networking - taking it from reactive to proactive, and eventually, predictive - a self-driving network. On the road to this goal, we offer solutions to problems faced by network engineers in the spaces of network visibility, automation, security assurance, trouble resolution, and multi-cloud networking.
Our straightforward approach makes easily viewing inventory, ensuring configuration compliance, navigating topology
views, state information and analyzing end-to-end forwarding behavior staples in a network engineer's toolbox. Consolidating these functionalities in a single multivendor product that extends to the public cloud is a bit of magic we've spun up to help clear your path to innovation.
So, as the cool kid on the block, how have we mapped out this road to network automation adoption?
We've outlined the adoption of IP Fabric (and therefore, your confident approach to automating your network) in three clear phases:
Shine light into the dark corners of the multi-vendor network for a full picture of the inventory, configuration, topology, and state with automated discovery and documentation. Only when you have a trustworthy baseline can you truly know your network, which is an essential start to any automation project.
Rich data, path simulation, change validation, intent verification, data democratization - IP Fabric uses data from across your entire network to enhance your operational process. As your team experiences how intelligently sharing and leveraging data across your operational ecosystem elevates systems, workflows, and processes, the value becomes undeniable and resistance to change is quelled.
Start integrating with other technologies to put the data intelligence from IP Fabric to work, expanding the reach of your newfound operational bliss. For example, start asking your network questions and getting immediate answers (directly in Slack or Teams if you’d like) opening up a world of possibilities.
The insight IP Fabric provides empowers teams to think in cool ways about how to innovate your network while keeping the infrastructure secure and changes aligned with your intent.
Check out how IP Fabric & Nautobot ChatOps bring innovation to your network at Network Field Day 27.
To our delight, our friends over at Itential join us on the list of Cool Vendors. Together, IP Fabric and Itential work to design and deploy network automation workflows that are validated by measuring the end-to-end behavior of the resulting network, comparing it with its previous state and the desired outcome.
Another great example of how we enhance your network toolset.
If you want more insight into IP Fabric, or would like to see how it can revolutionize your network, get in touch with our team and request a demo.
Follow us over on LinkedIn for more updates.
After presenting IP Fabric at Networking Field Day 23, a number of Twitter threads started probing at the idea of Intent-Based Networking (IBN) - is it simply a marketing term that vendors use to sell more gear or does it have a deeper meaning? And what impact does it have on the network team? Does it automate them out of a job?
It’s safe to say that every modern business depends on its IT, and the network provides the underpinning to all the systems on which we rely. Business needs IT to just “be”. It should be permanently available, supporting business process with a minimal operational overhead. But it’s obvious to anyone in IT just how big a stretch that is due to many factors, not least:
Automating regularly occurring network tasks helps reduce the operational overhead of running the network, of course. You might use controllers or scripts, templates, zero-touch provisioning and automated change mechanisms. There are plenty of benefits in being able to treat a network domain as a macro entity and allow the micro tasks that are required to maintain the environment be taken care of by automated processes.
However, it's vital that we fully understand the networks we build. This ensures that the automation platform is deploying configuration with the expected outcome. Configuration still happens in a network domain on a box-by-box basis. The process uses configuration detail from a knowledgeable and experienced network engineer. In reality, the automation system functions like a fast, consistent network analyst. It makes and tests changes and fetches data about operations, based on rules defined by its "superiors"!
IBN takes the automation approach to the next level. Given the business intent for the network, you first translate it to a set of technical capabilities, then:
What we’re really doing here though is subtly evolving the roles of the network architect, designer and engineer.
The business intent may include such abstract ideas as “make sure that my critical applications are always available”. The traditional approach would involve a network architect in translating that intent to some design criteria: “always use High Availability, no SPOFs, converge my routing protocol within x seconds, define QoS across the network” and so on. A network designer will then take those principles, and looking at each network domain in turn, consider how to turn out specific bills of material, Layers 1, 2 and 3 topologies and designs using specific vendor platforms. The network engineer would finally deploy this. They would turn the designs into actual configuration, and then manage and maintain the resulting network.
IBN automates much of this process, taking business intent and delivering a self-regulating, self-healing network environment.
It centres on a “Source of Truth” (SoT) – a picture of the network as it is intended to look, developed from the business intent using logic defined by the network architects and designers. It is then used as a central reference point for all intended configuration data – often referring to other “Systems of Record” as definitive reference sources where necessary.
Updating intent in the SoT triggers orchestration workflows to render the configuration in the different network domains. These configurations might include organisational or industry Best Practice templates, security policy data or specific network domain detail to support the intent. And typically the orchestration workflows then kick off automation tasks in controllers or as scripts to interact with different sets of network devices, potentially from different families from different vendors. Subsequently, they might also update policy engines which devices are using to refer to without having to keep local copies of configuration or policy.
Assurance workflows are built first to harvest state information from the network devices and controllers. They then analyse that data to ensure that they are meeting the intent.
And if intent is not being met, the assurance element then triggers a feedback loop into the orchestration platform to update configuration through the automation layer.
There are of course a few words of caution.
And so you can see, the network architect, designer and engineer are still key - they simply demonstrate their knowledge and experience in different ways.
As we mentioned in our earlier post, IP Fabric is not well-positioned as the SSoT for intent, simply because the product focus is on being the informational reference for the actual network state.
IP Fabric can sit squarely at the heart of your intent-based networking ecosystem however. As it provides full inventory, configuration and state visibility of the entire network, it then becomes well-placed to serve as the System of Record for those elements. It would be used to carry out an initial population of the Source of Truth, and then as a regular source of true-up data to ensure that the SoT genuinely represents the active network.
As IP Fabric is already harvesting all the network data, it is in a great position to begin carrying out the assurance elements of the IBN system. We would define rules in IP Fabric that validate elements of configuration and state, which are checked at every snapshot. Rules are not only created through the UI but also through the API. This means that they can then be pushed to the platform from an agent acting for the Source of Truth. Webhooks can then be fired from IP Fabric at calculation of those intent verification rules, to provide a feedback mechanism to the orchestration platform should intent not be met.
The real beauty of using IP Fabric with its complete network database and open API is that it can then serve as a reference source for whoever else needs that network data. The same system operating as part of the IBN platform could thus be used to keep monitoring platforms up to date, feed data to ITSM tickets at creation time, and later be queried through slash commands in Slack.
And so, the network engineer already has all the detailed configuration and state data they need to maintain, troubleshoot and deploy the networks they run. The network designer has an understanding of inventory, and topology relatinships at all layers. And the network architect can then get a picture very quickly of the current state of the interoperation of the network domains to help plan for transformation.
If you have found this article helpful, please follow our company’s LinkedIn or Blog, where more content will be emerging. If you would like to test our solution to see for yourself how IP Fabric can help you manage your network more effectively, please contact us through www.ipfabric.io.
A lively debate sparked up after Networking Field Day 23, where we presented IP Fabric to a panel of delegates and hundreds of eager online viewers. Could we class our solution as a "Source of Truth" for the network? The conclusion was "Yes". And "No". So why the confusion and what did the question actually mean? I thought I'd try and get to the bottom of it ...!
Network automation has come a long way. Once, that meant CLI scripts that you created by "mail merge", then rolled into your network over a telnet session. Now we have sophisticated automation platforms which take desired state and through configuration templates, functions, modules and APIs, can push that state into network devices (and if you're really lucky, roll them back again if they didn't complete.) But where does that desired state come from? You need to decide and record which features and parameters you want to enable and push out to which devices ...
And so you create a database - a bunch of spreadsheets, SQL, DCIM (Data Center Infrastructure Manager) or IPAM (IP Address Management) system - containing those feature definitions and parameters. And your templates are rendered using the data from that system into intended config state. This is typically referred to as the "Source of Truth", SoT (or sometimes "Single Source of Truth", SSoT).
The idea is that there is only one place to store that data - the ultimate reference source of desired configuration. Update that and the implied intention is that the network config is required to be changed. Typically that information would be version controlled and tracked, often using git or a similar VCS (version control system).
... when it doesn't hold all the information in one place! A Single Source of Truth can simply be a placeholder or proxy for the collection of reference sources for individual pieces of the network data puzzle.
You may use an IPAM system to record the definitive IP addressing schema that you want to use. You may use a CMDB to track your network device inventory details. These would be referred to as Systems of Record. Ultimately your network automation needs to access information from both of these sources in order to render configurations. So an SSoT would zip that information together as required.
Within the accepted conventional definition, not really. As the inventory, configuration and state data in IP Fabric is harvested from network devices, it doesn't represent intended state. It isn't able to be changed or updated manually. IP Fabric builds a vendor-neutral snapshots of the state of the network as a whole. It reflects - in great detail - the state of the network as it is operating at a point in time. It is queried through Web UI or API , visually or in tabulated data. As such, it doesn't store intended state, but actual state.
But that's not the complete story. Because along with the data from the network, we can build a series of intent verification checks. We use filters and classifications on that data to verify that active network complies with an intended state. For a simple example, we can ensure that all network devices are configured to a specific set of management parameters. We verify that NTP, SNMP and syslog match a set of criteria at every snapshot, and present a compliance report.
The 100+ embedded verification checks that ship with the platofrm range from the simple (eg checking where VLAN 1 is in use) to the complex (eg ensuring Spanning Tree root and FHRP active gateways align) and everything in between (eg checking MTU sizes at either end of a link match).
Whilst there is a mechanism to store intent in IP Fabric, it isn't used to render the intent as configuration. Verification checks are run against every snapshot and provide us with a way of validating intent on an ongoing basis.
We also carry out simulated end-to-end path checks at each snapshot. This allows us to validate that paths are as you expect them, and firewall rules allow connections only as intended.
All of these intent verification checks are built both through either Web UI, or IP Fabric's extensive REST API. This provides us with the ability to update the intent verifications in IP Fabric while you render the configurations from the intended state data, thus confirming at each snapshot that the state is matching the original intent from the SoT.
IP Fabric's new webhooks feature which allows us to notify an external platform when verification checks are completed. This can be used to provide a feedback mechanism for when actual state has drifted from intended state.
In IP Fabric we compare the intent with the network state that is discovered at the time of the snapshot. If for some operational reason, a part of the network is down, or if a partial snapshot is run to validate a change in a particular area of the network, then we only have partial data. And that is not useful for expressing intent across the whole network.
It is more optimal to use IP Fabric in tandem with a dedicated SoT like the open-source project Netbox. IP Fabric would then be used to cross-validate that the data in the SoT is correct and up to date. This effectively treats IP Fabric as a System of Record for active network state. An automation platform like Ansible might then be used to render configurations.
Using the API, IP Fabric intent verification rules can be built from the data defined in the SoT to confirm that the network configuration and behaviours matches the intent expressed in the templates. If state doesn't match intent, webhooks can be used to notify the orchestration/automation platform that adjustments need to be made. So not only would we automate the network device configuration from the SoT but also IP Fabric configuration!
Based on current accepted definitions, IP Fabric would not be considered a "Single Source of Truth" for intended state. It would be more accurately considered a System of Record for existing network state. It would be used in conjunction with a SSoT to measure compliance with intent. And if required, it would then trigger activity to rectify any drift.
Look out for the next article, where we'll consider Intent-Based Networking in a little more detail!
If you have found this article helpful, please follow our company’s LinkedIn or Blog, where more content will be emerging. If you would like to test our solution to see for yourself how IP Fabric can help you manage your network more effectively, please contact us through www.ipfabric.io.
Multicast routing and related implementations can be a real pain. If you want to make a network engineer nervous (and it doesn’t matter whether managing enterprise or service provider networks), just whisper few evil words “PIM”, “distribution tree”, “IGMP”. And if it’s not enough and you want to continue with fatality combo, follow that up with “RPF”.
Joking aside, how can IP Fabric help you with multicast?
A good strategic overview is necessary to win a battle, here represented as a list of routers where a multicast routing table is present, with a number of entries for each router.
Thanks to our intelligent network model, we can detect not only sources with IP addresses from directly connected networks, but also not directly connected addresses (for example used for Anycast SSM).
What would be multicast sources without multicast clients? IGMP group table will show us all interfaces with connected clients, including the subscription to specific multicast groups.
Multicast flows through distribution trees, which are build by PIM protocol with different flavors. For verification, you can use a table.
Better yet, you can visualize protocol relationships in the diagrams.
If you want to check how multicast traffic flows, you have to go to the multicast routing table and find the correct entry and copy packet from an incoming interface to all outgoing interfaces. On every single router. You know the drill.
Or you can let IP Fabric do all the hard work for you. You can use the path lookup feature to simulate multicast traffic flow and visualize the whole distribution tree for a specific group. And it even works for shared trees and multiple sources in the same group.
You know that desperate feeling. You configured everything right, sources are sending traffic, receivers are joined to groups, trees are built, but it still doesn’t work. Meet RPF checks in multicast PIM routing, which solve one of the biggest nightmares with operating multicast networks - troubleshooting multicast routing and RPF.
If your trees are not correctly aligned with unicast routing (multicast loop prevention) then say goodbye to your multicast traffic. But routers tell you where the problem is, you just need to be lucky or pedantically look everywhere. Or have a platform with multicast intent verification capability, such as IP Fabric!
RPF issue can also be troubleshot directly from path lookup by applying intent verification, so you can see on which devices and interfaces RPF check fails.
"Hello. This is IT. Have you tried turning it off and on again?" With IP Fabric helping users with their IPTV or conference problems is much more deterministic. Why? Because you can go back in time and compare what was working before and compare with the state of the network right now. You can see missing sources, receivers or whole parts of the tree.
So far, we have covered all of the multicast routing. In the next release, we will focus on switched networks with IGMP snooping. Stay tuned.
If you have found this article helpful, please follow our company’s LinkedIn or Blog, where more content will be emerging. If you would like to test our solution to see for yourself how IP Fabric can help you manage your network more effectively, please contact us through www.ipfabric.io.
Good news everyone, another version of the IP Fabric platform is officially out. We have added more freedom to users in terms of platform configuration and above all, the intent-based network verifications can now be visually represented directly in the diagrams.
This greatly helps in many scenarios when specific part of the network is of interest. For example, one of the frequent scenarios in troubleshooting is finding an issue on the path. Now all paths between any two endpoints can be visually verified for a presence of an issue in an instant.
This includes paths with significant complexity, such as paths including Stack, FEX, vPCs, VXLANs, WAN accelerators, Lightweight Wireless and others.
Imagine troubleshooting a path for a performance issue, and trying to narrow down a problem, because it’s not feasible to check everything at once. Techniques such as resolving a balancing hash for a particular flow were utilized to know which link to focus troubleshooting on. These techniques were necessary to narrow down the issue, but not in finding the underlying cause. Well, now it is feasible to check all path elements at once, and see all affecting issues.
Now it’s even possible to “Check everything at once”. Not surprisingly there will be a lot of red.
Of course, any intent verification group can be displayed separately. For example here we want to see only specific routing table entries which have routing redundancy issues in our datacenter.
Or here we want to visually verify device security hardening for compliance checks, and suddenly see that one of our devices has AAA Authentication configured with method "none" allowing privileged access without any authentication.
Visualization is available for any type of Intent verification, and can be combined with visual snapshot comparison. Here we verify neighborship compliance, and once we see that there is an issue with OSPF neighbors, we compare Monday's network state with the network state at Sunday, to see if the network has changed.
This visual issue representation is available for any type of Intent-Based Verification which can be associated with a link or a device.
The intent-based networking (IBN) or intent-based verification (IBV) buzz word has been around quite some time. However, to this day, not every engineer from security or network operations is familiar with the concept. Apart from that, people with diverse backgrounds may have a different understanding of the approach.
The goal of any computer network is to transfer information based on multiple variables. The Intent-Based Networking (IBN) is focused on network automation and better aligning networks with operational goals or 'intent'. Intent is what we want networks to do. It differs from classical monitoring goals in that we can express advanced operational concepts or even business goals. In classic monitoring we might have checks such as "IP address X must be reachable" while 'operational intent' could be "Authorized users must be able to redundantly reach application servers".
Verifying reachability via ICMP from the monitoring center is one thing, but verifying specific path availability and parameters from a specific set of sources to specific set of destinations is significantly more complex and has usually required a lot of manual effort to complete. This is extremely important to understand, because 'intent' advanced next level of visibility and shifts operational notion from "up/down" to predictive analytics.
As networks move towards IBN, the IP Fabric platform is here to help automate a significant part of the process.
In the platform, we have already created the Assurance Engine that is capable of tracking protocol inconsistencies or providing feedback on network health. The IPF administrators have the power to create their own system-wide controlling mechanisms that fit their needs for IBN.
We decided to take this powerful feature to another level, and with version 3.3. we have introduced Intent-Based verification for the diagrams. Imagine you are viewing any available network topology or the end-to-end path, while you can apply any previously defined IBN rule directly.
In the new version, the platform collects and analyzes DHCP Snooping information for supported devices. The information includes normalized configuration and state, including trusted ports, option82 and the binding database amongst other parameters. You can find the new DHCP snooping tables at /technology/security/dhcp-snooping/configuration-v4 in the platform
The VLAN summary information is now compiled from the network specifically from VLAN point of view. Previously VLAN information was compiled and available only from point of view of the Spanning Tree Protocols, however VLANs without any STP association were not available in the platform. Now any VLAN that exists in the network can be found, analyzed, and visualized, even if it is suspended, broken, or exists on a single device without any STP capabilities. Definitive VLAN information can be found at /technology/vlans/device-detail in the platform
Detailed SSID radio information was already available for mapping each SSID on each wireless Access Point in the Network. This information was present for each unique AP-SSID pair, and therefore was inherently presented from the AP point of view. In this release we have added SSID summary table which provides information from the point of view of SSID, and should help in consistency verifications of SSID deployments in the network. The table is located at /technology/wireless/radios/ssid-summary in the platform
With a single double-click (all clap for an amazing self-contradiction) one can ungroup the links in diagrams. So far it was only available with the help of the 'group/ungroup' button in the protocols menu.
Every release we tend to update the vendor list per requests from our customers and IPF version 3.3 is not an exception. We’ve seen a somewhat surprising venture of Mikrotik platforms into enterprise environments, primarily for advanced routing and MPLS capabilities, so we have added support for the Mikrotik platform. Please keep in mind that Mikrotik routers require longer session timeout, otherwise they will be not discovered.
The Extreme routers and switches have been among supported vendors for some time but not the Enterasys devices which Extreme has acquired back in 2013. Starting with 3.3, the basic discovery has been added.
Discovery attempts to contact devices using Telnet or SSH, which is useful especially for very large networks or networks with significant history. There is always an occasional forgotten device with Telnet enabled which IPF platform could help to identify. However, not everyone is particularly happy by having Telnet sessions around with every discovery. In the new version, the Telnet can be disabled for discovery.
Transceivers on NX-OS platform are now available in the inventory, for the ASA the support for system-defined object groups was added and much more.
Big thanks to our supporting customers, who are constantly helping us to improve the platform. Full details of the release could be found in our Release Notes.
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 evaluate how it can assist you in managing your network more effectively, please let us know through www.ipfabric.io.
As networks become increasingly complex, the job of network administrators becomes more and more demanding. To understand the sheer amount of effort that the role takes, you only have to look at the task of analyzing the enormous amounts to status information within a network.
With the methods that most organizations are using, analyzing network status, preventing link capacity and node overloads, and having enough information to take immediate action within your network is virtually impossible.
If network admins were able to harness the power of network visualization and dynamic network mapping regularly, instead of it being a long, laborious process that takes months to create, they’d suddenly be able to visualize the relationships between network elements and have an accurate representation of the network’s graph structure.
Network visualization helps clarify and define the relationships between network nodes and the links between them and displays them either as an online (live) diagram or an offline diagram.
When dealing with network visualization, several rules need to be considered.
For this example, we’re going to use seven rules from Eugen Goldstein, the German physicist that is often credited with the discovery of the proton, and apply them to network visualization software.
Also, as another example, other basic rules which can be good to consider, are:
These rules were given by Ben Shneiderman (an American computer scientist).
Network visualization helps users connect the dots more quickly than just staring at a spreadsheet of data. With visualization, reports can be more straightforward and can be far more effective. These easy to follow reports provide network engineers the intelligence for monitoring, troubleshooting and gathering reports of the network, which helps them to analyze and understand the status of their networks nodes, links, and more.
Network visualization tools can also help network security engineers handle security issues and more easily observe the status of their systems.
The monitoring software helps network engineers visualize the patterns within their complexed network, which enables them to troubleshoot issues and make informed decisions much more quickly, minimizing downtime during outages. Visualizations can be used in offline mode, giving you the flexibility to view a static picture, or online mode, which lets you see changes as they’re discovered in real-time.
If they were armed with network visualizations, admins would soon find that troubleshooting, assessing, and planning out their networks would be a piece of cake! Unfortunately, features like these go far beyond what any legacy network tools are able to provide.
That’s where IP Fabric comes in.
IP Fabric’s platform uses visualization to provide users with detailed tech visibility and drill-downs on dynamic network maps. The system visualizes individual technology and protocols, which enables network engineers to plan changes, troubleshoot connectivity issues, and document the network.
Mapping out and verifying end-to-end paths, from switching through balancing to firewall and cluster policies, enables network engineers to troubleshoot issues much quicker, and to communicate with other engineers about the network.
Using visualization, IP Fabric maps out complete active network paths between any two endpoints. The map shows you the routing and switching forwarding decisions, including the results of all of the security decisions of all active path filters for the specific source-destination pair.
End to end path mapping
As a network engineer, it’s incredibly important to be able to see your site-to-site connectivity or your individual sites, including all of your managed and unmanaged devices (including wired/wireless users, or IP phones). IP Fabric visualizes the details of individual protocols or aggregate links and topologies into a representative view.
IP Fabric helps you delve into active QoS, applied Access Control Lists, or transmission issues on any of the diagrams. Use the platform to verify links and device redundancy, or visually analyze specific protocol topology.
Try IP Fabric for yourself and see just how useful network visualization and network dynamic diagrams can really be.
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
