Having identified where your paths are going and over which nodes they travel, the next step is to implement a greater level of control over the routes they take. After all, why send the Nebuchadnezzar down a tunnel that you know is crawling with Sentinels? We alluded to this functionality in the previous part of this series in the Path deviation – it’s gone the wrong way section.
This functionality is known as Required and Blacklist, and it enables you to specify which IP addresses must appear in a path, and which ones you do not want to appear in a path. Once these are specified and the path is run, you will be alerted by ENA events and incidents when nodes do not comply with the specified required or blacklist settings.
Why required and blacklist?
The ultimate concern is always the user’s experience. With ENA SurePath showing you so many potential routes that your paths can take and are taking, you need the ability to restrict and enforce the routes that will deliver the best performance.
- Avoid nodes or bottlenecks you know to be troubling.
- Ensure traffic uses your main fiber broadband paths, rather than through your backup ADSL gateways. Or check that your data centers are using the dedicated link that you are paying for.
- Confirm data goes over the expected path to help mitigate security concerns.
- Validate your network connectivity disaster recovery plans by proving paths can fail over from primary to secondary.
- Proactively prevent path deviations and reduce the impact of performance issues on end users.
- Be alerted when the ISP makes changes that affect your paths.
- Discover when configuration changes on the network cause paths to change route.
Specifying required and blacklisted objects can help you correlate path change and performance issues. For example, if you’ve visualized your path and see that it is afflicted with high latency, you can identify the node or nodes that are causing these issues. You can then add the node or nodes to the blacklist, meaning that if they appear in future, you will be notified and you can then try to fix it. Further, if your paths keep going through the same router that is causing high latency, then you might want to make a configuration change to that router.
Blacklisted functionality also helps you keep tabs on the configuration changes you and others make to your network. There might be a situation whereby you know one of the routers directing you into the Matrix has been playing up, and so you’ve made some config changes to it and blacklisted it. However, Cypher might later come along and change the config on that router, because that’s the sort of thing he would do (he even looks like a bad guy, come on), which means your path runs back through that router again. But because you’ve blacklisted that router for that particular path, you’ll be notified by an event that is raised when the path runs through it again (and thus possibly stopping the betrayal that sets up the last third of the movie).
Finally, requiring and blacklisting nodes is a central part of disaster recovery planning. Ensure the compliance of your business recovery plans by specifying the nodes through which you want your paths to go when network failover occurs. Save your business time and labor with automatic testing of recovery from primary to secondary paths when problems arise, preventing loss of service now and in case of any future issues.
How to specify required or blacklisted IP addresses
Specifying required or blacklisted IP addresses is simple. Navigate to your path’s Summary dashboard and click the Required/Blacklist button to open the Required and Blacklist form.
Required nodes and blacklisted nodes are each included to their own list, and each list is specific to a path, not global. Every created path will start with an empty required list and blacklist.
Click Add to add an IP V4 address and specify if it is to be required or blacklist, and then click Save. Because networks are dynamic, and Neo might finally scare Agent Smith away from one of your favorite telephone booths, you can then easily remove or change the required/blacklist status of these entries as needs be.
Paths that are going the wrong way
When running a business or fighting for humanity’s survival against the Machines, sometimes things just don’t work out the way you planned. Nodes can appear in a path when you don’t want them to, and another path might not use a node that you need it to. There are 3 ways in which you can discover deviations from your Required and Blacklisted nodes without waiting endlessly by a ringing phone that Neo hasn’t picked up:
- Via a raised event and incident:
Historical required and blacklist
It’s always important to keep audit documentation. As discussed in the part 2 of this series, ENA keeps a historical timeline of path discoveries for each traceroute patch that has run. To access a historical path, select the desired time period bar from the historical timeline at the bottom of the Path Discovery dashlet. When you display a historical path, the Required and Blacklist will be updated to reflect its relation to the displayed historical path. This is an invaluable tool to assist with historical accounting of network management and checking which strategies have been previously applied. Or just generally to see what Cypher has been up to, because you are starting to suspect him.
You access the historical Required and Blacklist in the same manner as you would with the current paths. As well as showing you the list for that path, you can see the following information:
- If a required/blacklisted node has been removed since the historical batch was run.
- If a required/blacklisted node still exists for this path.
- If a required/blacklisted node currently exists for this path but was added after the historical batch was run.
In the next part of this series we will look how you can utilize ENA v18’s extensive and enhanced Geographical and Topological Map functionality to better monitor and manage your network paths.