Verifying Quality of Service is a complex task when delivering applications across a large network. It involves a detailed understanding of the behaviour of many different devices, often from different vendors. This post shows how IP Fabric can help with this onerous task.
Network nodes, links and interfaces have a number of characteristics that can adversely affect application availability and performance. These include:
Quality of Service (QoS) tools are then used in the network to manage these characteristics and optimise packet delivery through the network. These mechanisms include:
The tools need to be configured consistently in order to achieve an acceptable level of service for end users.
The typical approach to this problem has three stages:
The first stage is initially a business activity - define a policy identifying which applications should have priority. It then becomes a technical problem, to work out how to give the application traffic the treatment it needs.
Once that is complete, the second stage is to configure all the entry points into the network with the logic to categorise the application traffic and mark it in some way. This will normally be a change to a value in a packet header to "colour" the traffic.
Following that, the third - and most complex - stage ensures that every interface on every device in the network is configured consistently. The goal is to handle the application traffic in line with policy. In order to achieve this, you configure a "per-hop behaviour" or PHB for each traffic class on each network node.
Classification of traffic will happen in one of two ways:
Then comes the tough part! Each network node is configured to handle each class of traffic with a specific PHB, for example priority queuing or controlled packet drop. Different vendors and families of products from a single vendor will have different configuration detail for the same behaviours. In order to understand an end-to-end traffic flow then, the network engineer needs to have a detailed configuration knowledge of all the platforms involved.
Acme Inc's product database is critical to their business. Every product and service that the company sells depends on the contents of that database. It is built on a highly-available, redundant on-premises server infrastructure. It needs to be available at all times, and so the network team have been asked to prioritise its availability over other services.
Jane is a network engineer in the support team. She is tasked with checking that the QoS policy deployed ensures a service level for https access to the database application. As a result, she comes up with a process to check that QoS is correctly configured:
Alternatively she could give the job to IP Fabric.
Jane selects Diagrams | End-to-end path, then enters the protocol, source, destination addressess and ports for the application:
After clicking Submit, IP Fabric presents Jane with the end-to-end path from source to destination. And by choosing the "Show QoS" option, Jane can see where QoS configuration is applied:
Jane can then click on the nodes and show the marking policy in use at the ingress switch:
and the queuing configuration deployed at the WAN edge:
and in so doing, has full visibility of the QoS along the application path.
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.
Verifying Quality of Service is a complex task when delivering applications across a large network. It involves a detailed understanding of the behaviour of many different devices, often from different vendors. This post shows how IP Fabric can help with this onerous task.
Network nodes, links and interfaces have a number of characteristics that can adversely affect application availability and performance. These include:
Quality of Service (QoS) tools are then used in the network to manage these characteristics and optimise packet delivery through the network. These mechanisms include:
The tools need to be configured consistently in order to achieve an acceptable level of service for end users.
The typical approach to this problem has three stages:
The first stage is initially a business activity - define a policy identifying which applications should have priority. It then becomes a technical problem, to work out how to give the application traffic the treatment it needs.
Once that is complete, the second stage is to configure all the entry points into the network with the logic to categorise the application traffic and mark it in some way. This will normally be a change to a value in a packet header to "colour" the traffic.
Following that, the third - and most complex - stage ensures that every interface on every device in the network is configured consistently. The goal is to handle the application traffic in line with policy. In order to achieve this, you configure a "per-hop behaviour" or PHB for each traffic class on each network node.
Classification of traffic will happen in one of two ways:
Then comes the tough part! Each network node is configured to handle each class of traffic with a specific PHB, for example priority queuing or controlled packet drop. Different vendors and families of products from a single vendor will have different configuration detail for the same behaviours. In order to understand an end-to-end traffic flow then, the network engineer needs to have a detailed configuration knowledge of all the platforms involved.
Acme Inc's product database is critical to their business. Every product and service that the company sells depends on the contents of that database. It is built on a highly-available, redundant on-premises server infrastructure. It needs to be available at all times, and so the network team have been asked to prioritise its availability over other services.
Jane is a network engineer in the support team. She is tasked with checking that the QoS policy deployed ensures a service level for https access to the database application. As a result, she comes up with a process to check that QoS is correctly configured:
Alternatively she could give the job to IP Fabric.
Jane selects Diagrams | End-to-end path, then enters the protocol, source, destination addressess and ports for the application:
After clicking Submit, IP Fabric presents Jane with the end-to-end path from source to destination. And by choosing the "Show QoS" option, Jane can see where QoS configuration is applied:
Jane can then click on the nodes and show the marking policy in use at the ingress switch:
and the queuing configuration deployed at the WAN edge:
and in so doing, has full visibility of the QoS along the application path.
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.