In Part 3, we discussed using the python-ipfabric SDK to interact with IP Fabric's API - did you know that you can also create diagrams using the API? Today we will be using the python-ipfabric-diagrams SDK. Since diagramming is a coding heavy topic, I am also working on a webinar to show live examples and more advanced features such as turning layers off and ungrouping links.
Find a coding example on GitLab at 2022-05-20-api-programmability-part-4-diagramming.
There are four options for returning data in the IPFDiagram class.
Each of these methods has five input parameters, and only the first one is required:
This is the most basic diagram as it takes a single IP address. The imports will differ depending on the type of graph.
# 1_host2gateway.py
from ipfabric_diagrams import IPFDiagram, Host2GW
if __name__ == '__main__':
diagram = IPFDiagram(base_url='https://demo3.ipfabric.io/', token='token', verify=False)
with open('1_host2gateway.png', 'wb') as f:
f.write(diagram.diagram_png(Host2GW(startingPoint='10.241.1.108')))
The Network class accepts 3 input parameters. If no parameters are defined, this will create a graph similar to going to the UI and Diagrams > Network.
site name or a List of site names.# 2_network.py
from ipfabric_diagrams import IPFDiagram, Network, Layout
if __name__ == '__main__':
diagram = IPFDiagram(base_url='https://demo3.ipfabric.io/', token='token', verify=False)
with open('2_1_network.png', 'wb') as f:
f.write(diagram.diagram_png(Network(sites='MPLS', all_network=True)))
with open('2_2_network.png', 'wb') as f:
f.write(diagram.diagram_png(Network(sites=['LAB01', 'HWLAB'], all_network=False)))
with open('2_3_network.png', 'wb') as f:
f.write(diagram.diagram_png(
Network(sites='L71', all_network=False, layouts=[Layout(path='L71', layout='upwardTree')])
))
Before moving on to Unicast and Multicast let's take a look at how to overlay a snapshot comparison or specific intent rule onto your graph. You can apply this to any type of graph.
# 3_network_overlay.py
from ipfabric_diagrams import IPFDiagram, Network, Overlay
if __name__ == '__main__':
diagram = IPFDiagram(base_url='https://demo3.ipfabric.io/', token='token', verify=False)
with open('3_1_network_snap_overlay.png', 'wb') as f:
f.write(diagram.diagram_png(Network(sites='MPLS', all_network=False),
overlay=Overlay(snapshotToCompare='$prev')))
To overlay an Intent Rule you must first get the ID of the rule to submit. In this example, we are using the ipfabric package to load the intents and get a rule by name. Find more examples of extracting intent rule IDs here.
# 3_network_overlay.py
from ipfabric import IPFClient
from ipfabric_diagrams import IPFDiagram, Network, Overlay
if __name__ == '__main__':
diagram = IPFDiagram(base_url='https://demo3.ipfabric.io/', token='token', verify=False)
# Get intent rule ID
ipf = IPFClient(base_url='https://demo3.ipfabric.io/', token='token', verify=False)
ipf.intent.load_intent()
intent_rule_id = ipf.intent.intent_by_name['NTP Reachable Sources'].intent_id
with open('3_2_network_intent_overlay.png', 'wb') as f:
f.write(diagram.diagram_png(Network(sites=['L71'], all_network=False),
overlay=Overlay(intentRuleId=intent_rule_id)))
The next two examples make it a bit clearer why we first create a python object and then pass it into the diagramming functions. The amount of options required are quite lengthy, and this keeps your code cleaner and provides great type hints (see below). Additionally, it has many built-in checks to ensure you provide the correct data before submitting the payload to IP Fabric and returning an error.
For all valid ICMP types please refer to icmp.py.
# 5_unicast_path_lookup.py
from ipfabric_diagrams import IPFDiagram, Unicast
from ipfabric_diagrams import icmp
if __name__ == '__main__':
diagram = IPFDiagram(base_url='https://demo3.ipfabric.io/', token='token', verify=False)
unicast_icmp = Unicast(
startingPoint='10.47.117.112',
destinationPoint='10.66.123.117',
protocol='icmp',
icmp=icmp.ECHO_REQUEST, # Dict is also valid: {'type': 0, 'code': 0}
ttl=64,
securedPath=False # UI Option 'Security Rules'; True == 'Drop'; False == 'Continue'
)
with open('5_1_unicast_icmp.png', 'wb') as f:
f.write(diagram.diagram_png(unicast_icmp))
TCP and UDP accept srcPorts and dstPorts which can be a single port number, a comma-separated list, a range of ports separated by a -, or any combination of them. The applications, srcRegions, and dstRegions arguments are used for Zone Firewall rule checks and these default to any (.*).
# 5_unicast_path_lookup.py
from ipfabric_diagrams import IPFDiagram, Unicast, OtherOptions, Algorithm, EntryPoint
if __name__ == '__main__':
diagram = IPFDiagram(base_url='https://demo3.ipfabric.io/', token='token', verify=False)
unicast_tcp = Unicast(
startingPoint='10.47.117.112',
destinationPoint='10.66.123.117',
protocol='tcp',
srcPorts='1024,2048-4096',
dstPorts='80,443',
otherOptions=OtherOptions(applications='(web|http|https)', tracked=False),
srcRegions='US',
dstRegions='CZ',
ttl=64,
securedPath=False
)
with open(path.join('path_lookup', '5_2_unicast_tcp.png'), 'wb') as f:
f.write(diagram.diagram_png(unicast_tcp))
with open(path.join('path_lookup', '5_3_unicast_tcp_swap_src_dst.png'), 'wb') as f:
f.write(diagram.diagram_png(unicast_tcp, unicast_swap_src_dst=True))
# Subnet Example
unicast_subnet = Unicast(
startingPoint='10.38.115.0/24',
destinationPoint='10.66.126.0/24',
protocol='tcp',
srcPorts='1025',
dstPorts='22',
securedPath=False
)
with open(path.join('path_lookup', '5_4_unicast_subnet.png'), 'wb') as f:
f.write(diagram.diagram_png(unicast_subnet))
This is a new graphing feature in version 4.3 and above that allows you to specify a device and interface a packet enters your network. Perhaps you have a firewall rule to allow a certain IP address or subnet and want to verify that this is functioning correctly. The sn value is the IP Fabric unique serial number, iface is the intName or Interface column (not to be confused with Original Name), and the hostname is also required. The easiest way to collect this information is from the Inventory > Interfaces table. The sn is not a visible column in the UI, but is available from the API.
# Example pulling Interface Inventory table
from ipfabric import IPFClient
ipf = IPFClient(base_url='https://demo3.ipfabric.io/', token='token', verify=False)
interfaces = ipf.inventory.interfaces.all(columns=['sn', 'hostname', 'intName'])# 5_unicast_path_lookup.py
from ipfabric_diagrams import IPFDiagram, Unicast, Algorithm, EntryPoint
if __name__ == '__main__':
diagram = IPFDiagram(base_url='https://demo3.ipfabric.io/', token='token', verify=False)
# User Defined Entry Point Example
unicast_entry_point = Unicast(
startingPoint='1.0.0.1',
destinationPoint='10.66.126.0/24',
protocol='tcp',
srcPorts='1025',
dstPorts='22',
securedPath=True,
firstHopAlgorithm=Algorithm(entryPoints=[
EntryPoint(sn='test', iface='eth0', hostname='test'),
dict(sn='test', iface='eth0', hostname='test') # You can also use a dictionary
])
)Multicast is very similar to Unicast except some of the parameter names have changed. You can also specify a receiver IP address but this is optional.
# 7_multicast.py
from ipfabric_diagrams import IPFDiagram, Multicast
if __name__ == '__main__':
diagram = IPFDiagram(base_url='https://demo3.ipfabric.io/', token='token', verify=False)
multicast = Multicast(
source='10.33.230.2',
group='233.1.1.1',
receiver='10.33.244.200', # Optional
protocol='tcp',
srcPorts='1024,2048-4096',
dstPorts='80,443',
)
with open('7_multicast.png', 'wb') as f:
f.write(diagram.diagram_png(multicast))
One of the great advantages of using this package is returning a Python object instead of returning the raw JSON. This allows a user to more easily understand the complex textual data returned by IP Fabric that represents how the edges (links) connect to the nodes (devices, clouds, etc.) and the decisions a packet may take. You can accomplish this via the JSON output but returning an object provides type hints along with the ability to export the model as a JSON schema. Please note that the model is not the exact same as the JSON output and some structure has been changed for ease of use. It also dynamically links some internal objects to eliminate the need to do extra lookups and references.
# 6_json_vs_model.py
from ipfabric_diagrams.output_models.graph_result import GraphResult
if __name__ == '__main__':
print(GraphResult.schema_json(indent=2))
"""
{
"title": "GraphResult",
"type": "object",
"properties": {
"nodes": {
"title": "Nodes",
"type": "object",
"additionalProperties": {
"$ref": "#/definitions/Node"
}
},
"edges": {
"title": "Edges",
"type": "object",
"additionalProperties": {
"anyOf": [
{
"$ref": "#/definitions/NetworkEdge"
},
{
"$ref": "#/definitions/PathLookupEdge"
}
]
}
},
...
"""The ability to create diagrams using the API allows for greater automation and integration into other applications. Many of our customers use this feature to create chatbots to speed up troubleshooting, as shown below. This example is from the Network to Code nautobot-plugin-chatops-ipfabric plugin.
Another useful feature is performing a Path Lookup and parsing the JSON output to ensure traffic is flowing apart of a review process. We have partnered with Itential to demonstrate how using their low-code automation platform can automate ServiceNow requests and ensure that a newly deployed IP has access to correct network services during a Change Control review. Keep an eye out for a video of this exciting demonstration!
If you have any questions, comments, or bug requests please send an email to [email protected] or open an issue request on the GitLab repository.
To address Cobit 2019 certification we need to make sure we have an understanding of what Cobit stands for, "Control Objectives for Information and Related Technology". First of all, it was mainly focused on auditing, specifically helping financial auditors navigate IT environments. Now it is the leading framework for the governance and management of enterprise IT. It includes breadth of tools, resources and guidance. Its main value is leveraging proven practices to inspire IT innovation and fuel business success.
The network infrastructure is the most critical underlay for any applications running in enterprise environments. In addition, data security is critical to any organization. That's the reason why at least some information security standard must be incorporated. This applies to anyone who aims to keep the data well protected.
Any value created in the digital world automatically attracts those who intend to capture its value. Of course without any necessary permission. It can be a hacker or medium-skilled student with malicious intent. But it's not important who desires to access your data or why. Without following any security best practices, you are out in the open.
Moreover, in our previous post related to security audits automation, other relevant information related to Cobit can be found. In this article, we will focus on how the IP Fabric platform can assist with network security management. Further, bringing benefits to everyday operations.
At first, the IT domain needs to be perfectly specified and well-aligned with the business goals. The starting point for further security practices development in any certification is to be aware of all its infrastructure elements.
The infrastructure elements may include all active network devices (routers, switches, firewalls, load-balancers, etc.), a full inventory of end-points (virtual or physical servers) communicating on the network or entry points to the network (available physical interfaces, wireless access points and more). All in all, an up-to-date detailed inventory is the most important factor for any enablement.
For the IP Fabric platform, the full and up-to-date inventory of any elements on the network is an easy task. It provides its users with complete visibility. Moreover with multiple views and end-of-life information, with automated protocol level diagrams fresh every day. Apart from that, all data is easily exportable manually or by any integrated system via API.
The definition above relates to mapping existing information flows across routed or switched networks with clear security objectives. Firewalls with properly configured security policies are the key components in building secure networks and preventing unwanted access.
However as the network grows in complexity, more teams participate in network security policies administration. Hence, the restrictive rules may be violated with unauthorized or temporary changes on firewalls or access-lists.
The best approach to a stable security environment that meets the high standards is continuous security policies and end-to-end path verification. In addition, with the IP Fabric platform, users are provided with the tool that can help with both. The platform reads and stores all security policies from selected vendors. As well as, immediately detecting changes and providing historical data. Besides, with the end-to-end path testing feature available, it can store hundreds of defined path checks, that are being continuously verified with every new network snapshot.
The network management misconfigurations are maybe one of the most discovered with the IP Fabric tool at the first run. What we often detect with automated verifications is legacy Simple Network Management Protocol (SNMP) configurations, old TACACS+ or RADIUS servers left in or outdated access-lists (ACL) applied to management interfaces.
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
Network documentation is a very complex and thorough topic - there are many guidelines, theories and even books that can help us with the process of creating and maintaining proper documents describing the network. The concept and execution may vary, but the purpose of the documentation should be unique - to represent the current state and settings of the network and all of the respective components. Let’s skip the document’s life cycle stages, like where to store the documents, how long the information should be stored for, how to track the changes etc., as there is much to cover on this topic. What is most important, is knowing what to document from a networking point of view, and how to represent the data.
Ideally, the network documentation should enable reconstructing the network from scratch. In case a change is being planned, state information is necessary to plan the change correctly. In the event that the active network device goes down due to an unforeseen event, it is crucial that the network can be reverted to its previous state. And if elements of a new network should incorporate elements from the network, being able to accurately document the corresponding detail levels is particularly important.
It goes without saying that the network engineer should be able to understand the documentation corresponding to their network without unnecessary complications. Being able to fetch the device list, understanding how they are interconnected and configured, and being able to verify all of this information is essential. Although the structure of the individual documents may vary, the common approach should be adhered to – describing the network based on the Open Systems Interconnection (OSI) model.
This chapter should cover the device list, including the hardware modules, the software versions, applied patches and other hardware/software details. Documenting the device location, rack plan and physical access details is optional. The core of this section is to document the physical cabling – interface names, transceiver and cable types. IP Fabric provides all information under the Inventory section – Device list, OS versions, List of interfaces with many details.
1 - Device Inventory
The second OSI layer describes the logical rather than physical connections. It means that segmentation can follow the physical cabling but it can extend the connection by using Virtual-LANs (VLANs), the port aggregation (EtherChannel, Port-Channel, Aggregated interfaces), different types of Spanning-Tree (STP) or use proprietary concept like Fabric Path etc. All this information are important to be able to understand how the network is functional from the logical point of view. If desired, it may document the logical settings of the devices like stacks - Virtual Switching System or Stack-Wise Virtual, VDC or vPC. The format of the documented data has to be carefully considered - there are plenty of methods such as network diagrams, tables, lists or configuration snippets.
IP Fabric collects lot of details and all the data are presented in a standardized and comprehensible way. Network diagram (per site) is showing protocol-level connections and technology section provides table overview of L2 specific topics.
2 - Network L1/L2/L3 diagram
Describing the network layer should be the most critical and most extensive aspect of the network documentation, as it should cover the elements such as:
IP addressing is a subject of a separate document and specific IP Address Management (IPAM) tool may be used (free or paid) - it should cover all the network subnets configured within the network. It depends on the capabilities of the IPAM to store all the details, but from the best practice approach it should list the network subnet, the configured IP address, device and interface name. Ideally, IPAM should track the history of the changes to see when and what changes have occurred. However, most of the tools available on the market require manual database maintenance.
Routing can be simplified using few static routes within one flat routing domain, but also can be very complex and structured by using several dynamic routing protocols like EIGRP, OSPF or BGP with complex redistribution on several places within the routing domain. Therefore, it should be documented to an appropriate detail level to in order to provide network behavior insight, and enable the possibility of building the website from network documentation alone.
IP Fabric excels in this area by collecting all the data mentioned above automatically, and more; IP addresses are listed in Managed IP overview and any IP can be verified against the device/interface name, including DNS name or other few additional settings. It can be also used as an initial input to the IPAM tool - just to export all the data to the CSV format and import the values to the IPAM. Collecting the list of IP addresses and IP networks is not the core of the IP addressing management - that’s only a list of values that are being used across the whole network. That said, proper comprehension and routine updates will serve the IPAM as needed.
The fourth layer of OSI model helps securing the traffic. The control plane security means securing the data needed to establish the network functionality - routing protocols, FHRP, device management etc. It should be covered in the appropriate part based on the control protocol, e.g. securing the dynamic routing protocol or FHRP should be covered in the previous chapter, securing the device management in the chapter covering the accessing the device (Telnet, SSH, SNMP) and so on.
Data plane filtering is the core of this section - it refers to the core concept of how the production data (user data) is being filtered, and should be documented first; it can then extend to the details and provide a very detailed view of the individual access-lists statements. Another concern is, how far need you dig into the details? It depends on the complexity of the implementation as well as the corresponding security policies that can limit the amount of information that may be presented.
IP Fabric provides a coherent Access-List (ACL) overview, which also serves the ability to check the A-B path verification for specific traffic. Just enter the source and destination IP address in the network, then the traffic type - Internet Control Message Protocol (ICMP) or TCP/UDP and source/destination port in the second case.
3 - Vieving Access-Lists in the tolopolgy
The application layer is often excluded from the network documentation, but the process is changing and applications are more and more often a focal point of the new network principles and approaches. For this article and this chapter especially, the application layer description should include all the application we need to control, manage and monitor the network. Standard tools for device management are still Telnet/SSH with some corporate identity management (TACACS or Radius), and specific tools based on GUI front-end are more popular nowadays.
The network documentation process should incorporate the previous examples, but not be limited to them. There are many technologies, concepts, and network functions and it is very difficult to maintain an up-to-date overview of all such documents, especially when it comes to vast enterprise networks. Therefore, automating the process of collecting network data and subsequently creating the corresponding documents has proven to be a substantial advantage. IP Fabric eliminates the need for manual low-level design documentation; IP Fabric provides a detailed network overview for each business location, including topology visualization. Automatically generated, always available & up-to-date.
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.
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.
International standard or ISO 27001 certification is helping organizations to better understand network and security area administration. It also defines models for increasing network and security resilience and other features.
To begin with, the network infrastructure has become more and more important for many organizations. Hence, nothing is more valuable than data being transferred between the systems or stored within the secured perimeter. That's why the information security standard should be incorporated by anyone who aims to keep the data well protected.
Furthermore, any value created in the digital world automatically attracts those who intend capturing the value without any necessary permission. It can be a hacker or medium-skilled student with malicious intent. But it's not important who desires to access your data or why. Without following any security best practices, you are out in the open.
In addition, our previous post related to security audits automation, provides other relevant information to ISO 27001 certification . Further, in this article we will focus on how the IP Fabric platform can assist with network security management. Hence, bringing benefits to everyday operations.
"ISO/IEC 27001 formally specifies an Information Security Management System (ISMS), a suite of activities concerning the management of information risks (called ‘information security risks’ in the standard). The ISMS is an overarching management framework through which the organization identifies, analyzes and addresses its information risks."
From https://www.iso27001security.com/html/27001.html
The definition above perfectly describes the starting point for further security practices development in ISO 27001 certification. However, to proceed with the next steps of the standardization, the company needs to be aware of all infrastructure elements.
The infrastructure elements may include all active network devices (routers, switches, firewalls, load-balancers, etc.). Furthermore, a full inventory of end-points (virtual or physical servers) communicating on the network or entry points to the network. These are available physical interfaces, wireless access points and more. To summarize the point, an up-to-date detailed inventory is the most important factor for any enablement.
For the IP Fabric platform, the full and up-to-date inventory of any elements on the network is an easy task. It provides its users with complete visibility with multiple views and end-of-life information, with automated protocol level diagrams fresh every day. Apart from that, all data is easily exportable manually or by any integrated system via API.
"It recommends information security controls addressing information security control objectives arising from risks to the confidentiality, integrity, and availability of information. Organizations that adopt ISO/IEC 27002 must assess their own information risks, clarify their control objectives and apply suitable controls (or indeed other forms of risk treatment) using the standard for guidance."
From https://www.iso27001security.com/html/27002.html
The definition above relates to mapping existing information flows across routed or switched networks with clear security objectives. Firewalls with properly configured security policies are the key components in building secure networks and preventing unwanted access.
However as the network grows in complexity, more teams participate in network security policies administration. As a result, the restrictive rules may be violated with unauthorized or temporary changes on firewalls or access-lists.
The best approach to a stable security environment that meets the high standards is continuous security policies and end-to-end path verifications. With the IP Fabric platform, users are provided with the tool that can help with both. The platform reads and stores all security policies from selected vendors, it can immediately detect changes and provide historical data. Besides with the end-to-end path testing feature available, it can store hundreds of defined path checks, that are being continuously verified with every new network snapshot.
The network management misconfigurations are maybe one of the most discovered with the IP Fabric tool at the first run. What we often detect with automated verifications is legacy Simple Network Management Protocol (SNMP) configurations, old TACACS+ or RADIUS servers left in or outdated access-lists (ACL) applied to management interfaces.
The operations security is clearly described in Section 12 in ISO 27002 and is essential to any environment compliant with the standard.
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
Documentation is a critical part of any project or technical environment. If we don’t jot down some important information along the way, we end up repeatedly asking the same basic questions over and over again, completely draining our team members. We’ve heard from many team members that have admitted that the most annoying part of their day is answering those same repetitive questions day after day.
To begin with, when it comes to documenting computer networks (or other similar systems) we tend to use programs like draw.io or Visio. These programs are fantastic for outline ideas during the creative process of designing a new network. Furthermore, tools like these help us visualize our concepts, present them to others, then easily update those ideas as they evolve into a more cohesive plan.
For these tasks, these tools are great, but when the environment goes live… we quickly discover that we need something more.
Content updates to documentation can be a pain to maintain, especially for some of the more extensive networks — and the larger the network, the more changes an organization seems to want to make per day.
One solution to this issue is to appoint a dedicated team member (or, depending on the size of the network, an entire team) with the task of maintaining documentation. Whether they’re frequently updating the documentation themselves, or pushing the engineers to update the documentation after each update, this becomes quite the labor-intensive task.
Before we built the IP Fabric platform, we knew that there had to be some way to save time during time-consuming network operations processes. After simplifying that process through automation, we then took that same logic and turned our sights on the documentation process. Hence, we added a feature to the platform that gathers more than 1000 parameters from a single network device.
Now, on top of generating breathtaking interactive network diagrams, the platform can generate low level design documents. After every discovery snapshot, the platform creates a report that includes all the information needed for an audit, including device inventory details, physical layer, data-link layer details, routing and switching details.
These documents full of fancy diagrams can be generated whenever needed, and can easily be modified or compared to previous versions. This feature is an excellent timesaver for any Network Engineer or Network Engineering Manager, which helps them become a much more productive team member. Instead of wasting time working on mundane tasks, they can focus on tasks that create value. For example, examining overall network architecture, increasing stability, or having some spare time to enjoy their cup of coffee.
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.
The IP Fabric platform 2.0 is a major new version of the network engineer’s best friend. A number of big changes and customer feedback have made it into the release. From tracking all changes in the network to supporting more networking technologies, and going deeper into the technology stack than any other product.
A single button now discovers the network and takes a thorough snapshot at the same time. Large networks are undergoing constant change. Analyzing partial network does not provide a full picture, while discovery alone was not sufficient to provide valuable insight about the network. Discovery of new devices, new connectivity, and new protocols, is now combined with an in-depth network analysis and assessment, user location mapping, and efficiency and risk metrics.
The IP Fabric platform now allows tracking of dynamic changes across the whole of network infrastructure, not just administrative changes in configuration. See whether someone reconnected a device, added a new device, swapped an SFP module, or standby router became an active one. Historical data from any of the two previous network state snapshots can be compared to find dynamic changes in the network, such as:
Administrative changes, or Configuration Management, is also available and shows when the last change on the device has occurred, allows to view most recent or historical configuration, or use the configuration to restore a failed device.
Diagrams have been significantly improved, enabling to zoom in from site overview to individual user. Diagrams allow to display or hide topology and protocols, collapse or expand links and layers, show wired and wireless users, and much more. One of the more important aspects is that topology can be saved, and that element position is unchanged throughout network changes.
While routers and switches are the backbone of any large network, it was clear that network engineers are interested in more than wired infrastructure. Support for Routers, Switches, and Firewalls was expanded with support for Wireless Controllers, Access Points, and IP Phones.
In a continuous quest to support all major enterprise networking technologies, the analytics support for Routing, Spanning Tree, Aggregation links, Link Layer, ACL, and Gateway redundancy have been expanded with QoS, StackWise, and Power Over Ethernet.
New driver system enables to add support for more vendors more easily. In addition to the Cisco IOS, IOS-XE, NX-OS, IOS-XR support, we have added:
To facilitate integration, we’ve transitioned to a single API which we use internally, and which can be used by users. The new version also features more granular TACACS controls, robust user management, encrypted channel for offline tech-support file handling, JumpHost support, and more.
We’re taking user feedback to heart. When it was clear, that IP awareness is needed for routing and host lookups, we’ve added it right away. We're continuing the trend of incremental improvements, and adding routing protocol overview, ACL entry port lookups, ACL options lookup and hit count, Interface rate to supplement rolling over counters, and many others.
The feature I’ve been waiting for since the beginning of my Network Engineering career is finally here: Dynamic Change Monitoring. It’s finally possible to know the answer to the age-old question “What has changed in the network since yesterday?” and actually get a definitive response instead of the usual “Nothing has changed”. And not just the configuration change management, but I’m happy that we’re the first in the market to offer the overall network state change management — whenever a network path changes, if somebody plugs in a new SFP, if a network port goes up or down, or if IP address is starts being served by a new gateway due to a convergence event, the IP Fabric platform will report the change. It’s great for performing the changes as well because I can now perform a pre-change scan, in-flight scan, and post-change scan, and verify that pre-change and post-change do not differ or that they contain only the desired differences, validating change goal.
Dynamic change monitoring is not the only big improvement in version 2.0. Having had a number of large scale production deployments we’ve had a chance to listen to insightful feedback and significantly improve usability, add highly desired features, all the while simplifying product architecture to be able to deliver features more quickly. So here are some of the highlights from the big 2.0 release:
Now a single action discovers, analyzes, and calculates changes in the network. Based on a schedule or on demand, network insight is as current as you need it to be. The single combined action greatly simplifies usability, as it eliminates guesswork if a new discovery is necessary or not. From experience, we’ve found out that networks are so dynamic, that they need rediscovering every single time the network state is collected.
We strive to support all enterprise network infrastructure managed devices, model years from 1997 or 2017 and made by Cisco or anyone else. For version 2.0 we’ve added a driver system, where each vendor family only has to have a family driver for the IP Fabric platform to be able to talk to the whole family. We’ve also added support for HPE Comware v5 and v7 based switches such as 55xx and 59xx, Riverbed WAN accelerators running RiOS, and Cisco SG300-series SMB switches. Paradoxically, the Cisco SG300 had the most complex driver, because a number of key pieces of information are missing from the basic outputs, and multiple detailed outputs have to be painstakingly combined for a meaningful result.
While we started with Routers and Switches, our ultimate goal is to cover the end-to-end transmission path from the source to destination, which includes additional types of forwarding equipment. Wireless is omnipresent, so we’ve added WLC and AP support, so now wireless users connected to lightweight APs can be traced just as easily as wired users. We’ve also added firewalls and WAN accelerators. And because many users are connected through IP Phones, and IP phones are an important part of network infrastructure, we’ve added those as well.
We strive to support all major Enterprise networking technologies and protocols, and although we have some road ahead of us, we’ve expanded VDC, vPC, and FEX support with StackWise, PoE, and Optical Attenuation, added support for QoS classes and applied service policies, improved ACL workflows, and added many smaller improvements, like support for DMVPN tunnels.
Networks follow graph theory, and graphs are naturally visual, so it is not a surprise that diagramming and visualization capabilities are a big draw, for both the customers and internal teams alike. In version 2.0 we’ve moved from simple diagrams to a fully-fledged diagramming UI, which enables to display protocols or features on demand and show network topology from highest overview to the deepest. One of the great additions is persistent diagram saving feature, which stores the diagram layout even across multiple discoveries runs.
This one is my favorite. Network protocols create topological neighborship to form a forwarding domain and networks paths. Changes in protocol neighborships signify changes in the network topology. Changes in network topology connectivity may inadvertently affect network behavior and can affect a number of users. Tracking connection changes enables to quickly pinpoint non-administrative and administrative changes affecting topology and network paths, user connectivity, and performance, redundancy, resiliency and service availability. Along with configuration management changes, four types of changes are currently tracked: devices, network neighborships (CEF, ARP, RIB, STP, CDP/LLDP), modules and part numbers, and IP addresses. Changes can be displayed for any time interval for which the platform has collected network state information. Changes between last month and last week can be displayed just as easily for last week vs today.
Many other improvements have made it into the big 2.0 release, and although not all are polished, they are functional and can provide value out of the box. User interface now has integrated search, Live Support VPN option, and a status page. Users can now change their password, and we’ve added the enterprise-grade user management system with roles. We’ve added more granularity for CLI interaction, such as a hard limit on a maximum number of parallel sessions. There are also Jumphost, and REST API, and actually much more than can be covered in one post. We’ll be coming back introducing each major feature in more detail, but if you can’t wait, you can always contact us or requests a trial.
Discovery of existing IP network devices and links is essential to proper network management and control. How can you perform the discovery with the minimal initial information required?
While you are approaching an existing network that you know very little of, you usually spend a lot of time getting as much information as possible before you even look at and touch the network itself. You can study the documentation (if any), get the inventory lists, try to understand the topology and design, downloading configurations, gather IP ranges, ask for administrator privileges, etc. This can be a cumbersome process even if all involved people cooperate. And usually, the responsible people will not be happy about granting full access to the network for the discovery.
You can apply brute force reconnaissance methods as well — such as blindly scanning whole private IP ranges or trying to contact any IP address that goes around in your packet scanner. However, this is not something that you would like to see in a business critical network.
With the IP Fabric platform, you can start the network discovery right away without wasting any time or threatening your network by using a single set of read-only network access credentials only.
You do not need to define any seed devices or scanning ranges in most networks. You do not even need the full privileges as you are gathering operational data for the discovery only.
Discovery algorithms of the IP Fabric platform can use as little of initial information as available and still produce valid and useful results to support the proper network management and control.
If you have found this article resourceful, please follow our company’s LinkedIn or Blog. 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
Not only network documentation takes a lot of time and effort to create, but it also becomes outdated as soon as you hit save and seems to always require an update at the time you need it most. So how can you document your network effectively?
Every change in the network, either intended or unintended, usually requires documentation update. A good approach is to split the documentation into several documents according to sites that the network is organized into. The changes then affect only the site-related document. Having the history of design documents enables to track the network changes in time.
When the network is larger and the administration is delegated to multiple teams it may not be easy to keep the documentation updated according to the same standards in all sites. There may be network operation tasks with higher priority than documentation and there are definitely more favorite tasks for administrators than routine documentation.
IP Fabric provides an easy way how to keep the per-site Low-Level Design Documents updated with all of the detailed information, and always current even if the network changes rapidly. A generic document template keeps documentation look and feels consistent, while dynamic tags populate all of the required information from each of the network state snapshot, including overview site diagrams, physical layer information, information about switching and routing, management, and security.
A fully prepared document is generated with a click of a button at the time when it is required, for the current or historic state. No routine manual activity is required to create the documents as those are generated automatically according to pre-defined templates. Diagrams, tables, and explanatory text are included, just like in any manually created Low-Level Design document.
If you’re interested to see how the IP Fabric platform can help you with your documentation needs, contact us for an online demo or a trial in your network. Also, we’re hiring!
