05-03-2011 10:11 AM
How does an ace determine/define the bandwidth rate
for licensing and resource allocation purposes?
It would seem natural to use input octets per second,
or output octets per second, or perhaps the average of
those two numbers. Perhaps some specfic overhead
is included or excluded. Anyone know the specifics?
I couldn't find it in the manuals.
If the number used is the sum of the input and output
octets per second, I'd really want to know that.
Solved! Go to Solution.
05-25-2011 11:36 AM
Hello John-
Bandwidth is devided up into 2 different pieces - Management traffic and everything else.
Management traffic includes any traffic either destine to or sourced by an IP address on an ACE context. Including but not limited to the following:
1.) Probes sent by ACE to the servers. (The more complicated the probe, the more bandwidth that is consumed generally. ICMP vs. HTTP probe.. very different)
2.) Fault Tolerance traffic (Ace uses the management bandwidth on the Admin context to communicate about which context are active, heartbeats, and configuration sync. Each individual context uses its own management bandwidth to sync connection state, and sticky state.)
3.) Telnet/HTTP GUI traffic, SNMP, XML API, etc. connections inboud to the ACE (Telnet/SSH don't generally consume much bandwidth, but the XML API and HTTP/HTTPS GUI's can transfer quite a bit of data by design.)
4.) Logging, Copying files to/from the ACE.
5.) ARP (You wouldn't think that this is a big deal... but when you have something like a /16 subnet, the bandwidth for ARP on the wire is huge.)
All of the rest of the traffic would basically be anything routed into or out of a context, VIP traffic, etc.
In terms of how we account for the number - what shows up when you type "Show resource usage" is in bytes per second, which you can multiply by 8 to get bits per second. There is a comment about that in the virtualization configuration guide for each version of code, here is what the 4.X guide says:
"All values are in bytes per second; to convert to bits per second, multiply each value by 8."
Anything that traverses the ACE counts twoards the bandwidth - even if you have an ACL that drops XYZ traffic, it still counts as inbound traffic at minimum since we have to look at it and figure out what action to take.
There is quite a bit of confusion about where/how a packet that traverses the ACE is counted against the licensed amount. ACE only counts bandwith as a packet is physically headed inbound to the interface. Here is a day in the life of a packet as pertains to counting bandwidth:
Client == 1G (in) ==> ACE == 1G (out) ==> Server (Client GET reqeust)
Client <== 3G (out) == ACE <== 3G (in) == Server (Server 200OK response)
The total bandwidth counted twoards the licensing:: 1GB/s in from the client + 3 GB/s in from the server = 4Gb/s
Another thing that many people question is that you can license up to 1GB/s of management traffic at the same time as 4GB/s of all other traffic for the appliance. The appliance only has 4 1gb/s interfaces - so how does ACE account for licensing 5Gb/s? Under normal usage, you are not using 1Gb/s of management traffic nominally, but you would expect spikes every now and then. If we limited the managment to 1Gb/s and all other traffic to 3GB/s - You would be constantly wasting bandwidth space due to the lack of nominal usage on the management limits. *If* you were using a full 4GB/s of normal traffic and a 1GB/s spike comes in over management, the packets are likely going to drop prior to ACE being able to process the packet (i.e. the switch connected to your ACE's 4 1Gb interfaces won't be able to send the packet, so it will drop before it is sent over the physical link.)
With /24 subnets, FT, and a standard setup, ACE is likely going to see about .25Gb/s for arp and ft and 3.75Gb/s of VIP/routed traffic through the appliance.
All of this is still the same for the ACE10 and ACE20 modules, just in higher numbers. You also start approaching theoretical backplane limits on the switch fabric at 16Gb/s. Those limits depend on the Supervisor's abilites, how utilized the fabric is by other modules, etc.
I hope this is what you were looking for and more, let me know if you have any furthur questions!
Regards,
Chris Higgins
05-25-2011 11:36 AM
Hello John-
Bandwidth is devided up into 2 different pieces - Management traffic and everything else.
Management traffic includes any traffic either destine to or sourced by an IP address on an ACE context. Including but not limited to the following:
1.) Probes sent by ACE to the servers. (The more complicated the probe, the more bandwidth that is consumed generally. ICMP vs. HTTP probe.. very different)
2.) Fault Tolerance traffic (Ace uses the management bandwidth on the Admin context to communicate about which context are active, heartbeats, and configuration sync. Each individual context uses its own management bandwidth to sync connection state, and sticky state.)
3.) Telnet/HTTP GUI traffic, SNMP, XML API, etc. connections inboud to the ACE (Telnet/SSH don't generally consume much bandwidth, but the XML API and HTTP/HTTPS GUI's can transfer quite a bit of data by design.)
4.) Logging, Copying files to/from the ACE.
5.) ARP (You wouldn't think that this is a big deal... but when you have something like a /16 subnet, the bandwidth for ARP on the wire is huge.)
All of the rest of the traffic would basically be anything routed into or out of a context, VIP traffic, etc.
In terms of how we account for the number - what shows up when you type "Show resource usage" is in bytes per second, which you can multiply by 8 to get bits per second. There is a comment about that in the virtualization configuration guide for each version of code, here is what the 4.X guide says:
"All values are in bytes per second; to convert to bits per second, multiply each value by 8."
Anything that traverses the ACE counts twoards the bandwidth - even if you have an ACL that drops XYZ traffic, it still counts as inbound traffic at minimum since we have to look at it and figure out what action to take.
There is quite a bit of confusion about where/how a packet that traverses the ACE is counted against the licensed amount. ACE only counts bandwith as a packet is physically headed inbound to the interface. Here is a day in the life of a packet as pertains to counting bandwidth:
Client == 1G (in) ==> ACE == 1G (out) ==> Server (Client GET reqeust)
Client <== 3G (out) == ACE <== 3G (in) == Server (Server 200OK response)
The total bandwidth counted twoards the licensing:: 1GB/s in from the client + 3 GB/s in from the server = 4Gb/s
Another thing that many people question is that you can license up to 1GB/s of management traffic at the same time as 4GB/s of all other traffic for the appliance. The appliance only has 4 1gb/s interfaces - so how does ACE account for licensing 5Gb/s? Under normal usage, you are not using 1Gb/s of management traffic nominally, but you would expect spikes every now and then. If we limited the managment to 1Gb/s and all other traffic to 3GB/s - You would be constantly wasting bandwidth space due to the lack of nominal usage on the management limits. *If* you were using a full 4GB/s of normal traffic and a 1GB/s spike comes in over management, the packets are likely going to drop prior to ACE being able to process the packet (i.e. the switch connected to your ACE's 4 1Gb interfaces won't be able to send the packet, so it will drop before it is sent over the physical link.)
With /24 subnets, FT, and a standard setup, ACE is likely going to see about .25Gb/s for arp and ft and 3.75Gb/s of VIP/routed traffic through the appliance.
All of this is still the same for the ACE10 and ACE20 modules, just in higher numbers. You also start approaching theoretical backplane limits on the switch fabric at 16Gb/s. Those limits depend on the Supervisor's abilites, how utilized the fabric is by other modules, etc.
I hope this is what you were looking for and more, let me know if you have any furthur questions!
Regards,
Chris Higgins
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide