There should be minimal changes in the layer 2 switching operations — the switching topology should be constant and the number of MAC address moves minimally.

How do you know that the switching domain is not re-converging every minute or two due to STP issues?

Many problems in the current Ethernet layer 2 switched networks can come as a result of the behavior of the Spanning Tree Protocol and its derivatives. Its fail-open nature can render large parts of the network belonging to the same switching domain unusable. There are hints in STP operation before the major disruption happens which could be used as early warnings.

A number of topology changes, number of MAC address moves, STP diameter size, per VLAN root switch assignment, virtual port numbers and other operational values — if those will find a way to network engineer, they can mitigate the issue before the switching domain goes down completely. However, it is not exactly easy to routinely gather and process detailed Spanning Tree Protocol outputs to see if something out of ordinary is starting to happen.

The IP Fabric platform collects STP data and processes those into various statistics which provide immediate guidance to network engineers, such as that the network is re-converging too frequently, or that the root bridge uses default priority value, or that the STP topology includes more switches than recommended by best practices.

Detailed Spanning Tree analytics in the IP Fabric platform help engineers to investigate what could be wrong with the L2 switching domain, what could be fixed or changed, and help with the change procedure, such as switching to a newer derivative of the Spanning Tree protocol.

If you’re interested to see how the IP Fabric platform can help you to keep L2 switching domain stable, contact us for an online demo or a trial in your network. Also, we’re hiring!

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!

Network loss is one of the key performance indicators and is used throughout the networking industry for performance evaluations. But how do you evaluate loss network-wide?

Monitoring loss in a specific flow or service is precise but has a number of inherent disadvantages, such as that it must be explicitly provisioned, that the resulting measurement only tells information about a single service path, and that there is no specific information of where the loss occurred or what caused it.

Interface packet counters can provide this information, as they already record every single packet loss, including the specific reason for the loss. However, counters report a loss for a specific element, and high dropping element might be a mirroring port or a port connecting a misbehaving printer, with little impact to production. Surely you’ll want to know about those issues as well, but a significant loss on an uplink interface serving thousands of users is going to have much higher business productivity impact.

The IP Fabric platform combines these approaches, providing loss impact visibility at every point in the network from deltas of the packet counters, and then determining the significance of each issue by calculating the number of affected users.

This approach enables to quickly prioritize issues affecting business productivity the most, and at the same time pinpoint the exact location and cause of the issue, providing a clear path to remediation.

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