SummaryWhen first installing an Exinda device, configuring the circuits and virtual circuits is crucial in order to
OverviewWhen first installing an Exinda device in a network position, after testing the interfaces and ensuring the device is in an operational state, if the device is to shape traffic, the next concern is to properly set up the optimizer so that traffic can be subject to QoS as expected.
When setting up the initial configuration of devices, there are many things to consider, such as circuit size, virtual circuits and policies. While these are important to be amended in the future if necessity calls for it, an initial set up to get a baseline for operations is important in many environments. Knowing the basic QoS goals before the installation of the system is paramount:
- What are the critical applications?
- What are disallowed applications?
- Are certain subnets / groups of users allowed to have different rules?
- Is there extensive VLAN use the Exinda is in the middle of?
While a 'best practices' guide will change for each individual environment based on the needs of the network and the type of traffic that is going to be shaped, there are some high level concepts to be aware of:
- A circuit's bandwidth must equal the bandwidth of the physical link. If a circuit's bandwidth is less than the physical link, the optimizer will shape all traffic combined to be that circuit size, leaving unused bandwidth in the link; an inefficiency that can cause throughput problems. If a circuit's bandwidth is more than the physical link, the optimizer will shape all traffic to that circuit size, which will saturate the pipe before all data is transmitted. This can lead to packet drops on other devices on the network.
- The virtual circuits' bandwidth can not exceed the circuit bandwidth. If a number of virtual circuits' guaranteed bandwidths exceed the total circuit bandwidth, an error will be generated.
- At least one inbound and one outbound virtual circuit is needed per circuit. At least one VC for inbound and outbound traffic is needed for full shaping. These can be combined into one bidirectional Virtual Circuit, or can be 2 separate virtual circuits - one for inbound, one for outbound. Not shaping one of the directions will leave that direction of traffic completely free of any type of control. Some items such as edge cache require specific policies in certain directions.
- If inbound / outbound bandwidths differ, do not use a bidirectional virtual circuit. Inbound bandwidth (download) can be larger than outbound bandwidth (upload). A bidirectional virtual circuit will use the same policies for both directions. If the policies are mostly tailored to the inbound direction, any policy 'guaranteed' bandwidth might exceed or take up most of an outbound link's bandwidth. In this case, ensure separation of the virtual circuits by direction. Note that it is possible to separate it at a policy level (have certain policies only apply in certain directions) but it is best practices to separate it at the VC level so all policies can be tailored accordingly.
- Multiple Circuits are Independent Without Global QoS. With multiple circuits on different bridges, each has their own link capability and bandwidth. Their circuit bandwidths should reflect this (ie, if both links are 1Gbps, each circuit should be 1Gbps. If one link is 500Mbps and the other is 1Gbps, both should reflect that as well). If Global QoS is enabled (Configuration > System > Setup, "Control" tab), this will logically combine multiple bridges to act as one bridge with the sum of bandwidths - this is used for etherchannel / NIC teaming / link aggregation situations.