The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Переформирование ip пакетов "
Вариант для распечатки  
Пред. тема | След. тема 
Форум Маршрутизаторы CISCO и др. оборудование. (Маршрутизация)
Изначальное сообщение [ Отслеживать ]

"Переформирование ip пакетов "  +/
Сообщение от Perchik (ok) on 07-Апр-13, 22:00 
Здравствуйте.
Не могу найти информацию.
Могут ли маршрутизаторы Cisco (IOS 15.1) перепаковывать более мелкие IP пакеты в пакеты покрупнее? То есть не дефрагментировать, а именно объединить целые.
Или TCP/IP этого не поддерживает?
Задача - приходящие на LAN1 пакеты переправить посредством LAN2, скорость которого крайне мала (меньше 64 kbps). Пакеты формируются небольшие, полезной информации получается всего 30%, остальное - заголовки.

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Переформирование ip пакетов "  +/
Сообщение от eek email(ok) on 08-Апр-13, 06:38 
WAAS

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "Переформирование ip пакетов "  +/
Сообщение от Perchik (ok) on 08-Апр-13, 11:13 
> WAAS

А чтобы активировать WAAS, нужно покупать лицензию?

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

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

4. "Переформирование ip пакетов "  +/
Сообщение от fantom (ok) on 08-Апр-13, 11:35 
>> WAAS
> А чтобы активировать WAAS, нужно покупать лицензию?
> Настройка такой конфигурации будет сложной? Если говорить не относительно квалификации,
> а об объеме работы.
> Может быть, есть примеры подобных настроек?

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

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

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

6. "Переформирование ip пакетов "  +/
Сообщение от Perchik (ok) on 08-Апр-13, 15:24 
> WAAS

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

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

3. "Переформирование ip пакетов "  +/
Сообщение от fantom (ok) on 08-Апр-13, 11:32 
> Здравствуйте.
> Не могу найти информацию.
> Могут ли маршрутизаторы Cisco (IOS 15.1) перепаковывать более мелкие IP пакеты в
> пакеты покрупнее? То есть не дефрагментировать, а именно объединить целые.
> Или TCP/IP этого не поддерживает?
> Задача - приходящие на LAN1 пакеты переправить посредством LAN2, скорость которого крайне
> мала (меньше 64 kbps). Пакеты формируются небольшие, полезной информации получается всего
> 30%, остальное - заголовки.

Как вы это вообще говоря себе представляете???
2 станции послали каждая по одному DNS запросу к 2-м разным DNS серверам... и как вы эти 2 пакета обьедините в один???

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

5. "Переформирование ip пакетов "  +/
Сообщение от Perchik (ok) on 08-Апр-13, 15:23 
> 2 станции послали каждая по одному DNS запросу к 2-м разным DNS
> серверам... и как вы эти 2 пакета обьедините в один???

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

> Как вы это вообще говоря себе представляете???

Я и не уверен. Поэтому и спрашиваю у знающих людей.

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

7. "Переформирование ip пакетов "  +/
Сообщение от pavlinux (ok) on 09-Апр-13, 18:51 
>> 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.

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

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

8. "Переформирование ip пакетов "  +/
Сообщение от Perchiik on 10-Апр-13, 02:52 
>[оверквотинг удален]
> 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.
> Короча, гиморра можно получить больше, чем пользы.

Я сразу об этом подумал, в принципе.  Но несколько мнений надежнее, чем одно :)
Спасибо

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

9. "Переформирование ip пакетов "  +/
Сообщение от pavlinux (ok) on 10-Апр-13, 18:38 
>>[оверквотинг удален]
>> Короча, гиморра можно получить больше, чем пользы.
> Я сразу об этом подумал, в принципе.  Но несколько мнений надежнее, чем одно :)

Потюнингуй лучше размеры TX/RX буферов


Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру