>> WAAS
> А чтобы активировать WAAS, нужно покупать лицензию?
> Настройка такой конфигурации будет сложной? Если говорить не относительно квалификации,
> а об объеме работы.
> Может быть, есть примеры подобных настроек?

на cisco.com все расписано, только штука это довольно дорогая...
Может творчески подумать над тем, откуда такой поток пакетов и как с оным действовать?

Если это VoIP то можно попробовать увеличить буферизацию или еще чего подумать..

> WAAS

По идее WAAS позволяет использовать и компрессию заголовков.

>> 2 станции послали каждая по одному DNS запросу к 2-м разным DNS
>> серверам... и как вы эти 2 пакета обьедините в один???
> Нет, все проще. Общаются только 2 станции с разных концов. Так что
> пакеты все в одном направлении.

Issues with IP Fragmentation

There are several issues that make IP fragmentation undesirable. There is a small increase in CPU and memory overhead to
fragment an IP datagram. This holds true for the sender as well as for a router in the path between a sender and a receiver.
Creating fragments simply involves creating fragment headers and copying the original datagram into the fragments. This
can be done fairly efficiently because all the information needed to create the fragments is immediately available.

Fragmentation causes more overhead for the receiver when reassembling the fragments because the receiver must allocate memory
for the arriving fragments and coalesce them back into one datagram after all of the fragments are received. Reassembly on a
host is not considered a problem because the host has the time and memory resources to devote to this task.

But, reassembly is very inefficient on a router whose primary job is to forward packets as quickly as possible. A router is not
designed to hold on to packets for any length of time. Also a router doing reassembly chooses the largest buffer available (18K)
with which to work because it has no way of knowing the size of the original IP packet until the last fragment is received.

Another fragmentation issue involves handling dropped fragments. If one fragment of an IP datagram is dropped, then the entire
original IP datagram must be resent, and it will also be fragmented. You see an example of this with Network File System (NFS).
NFS, by default, has a read and write block size of 8192, so a NFS IP/UDP datagram will be approximately 8500 bytes (including
NFS, UDP, and IP headers). A sending station connected to an Ethernet (MTU 1500) will have to fragment the 8500 byte datagram
into six pieces; five 1500 byte fragments and one 1100 byte fragment. If any of the six fragments is dropped because of a congested
link, the complete original datagram will have to be retransmitted, which means that six more fragments will have to be created.
If this link drops one in six packets, then the odds are low that any NFS data can be transferred over this link, since at least
one IP fragment would be dropped from each NFS 8500 byte original IP datagram.

Firewalls that filter or manipulate packets based on Layer 4 (L4) through Layer 7 (L7) information in the packet may have trouble
processing IP fragments correctly. If the IP fragments are out of order, a firewall may block the non-initial fragments because
they do not carry the information that would match the packet filter. This would mean that the original IP datagram could not be
reassembled by the receiving host. If the firewall is configured to allow non-initial fragments with insufficient information to
properly match the filter, then a non-initial fragment attack through the firewall could occur. Also, some network devices (such
as Content Switch Engines) direct packets based on L4 through L7 information, and if a packet spans multiple fragments, then the
device may have trouble enforcing its policies.

Короча, гиморра можно получить больше, чем пользы.