Проблемы с пропускной способностью канала

[alibek]

Есть канал L2VPN с пропускной способностью 2 Мбит/с.

На одной точке (A) установлен коммутатор QTECH QSW-2900-24T4, прошивка V100R001B01D003SP10, конфигурация порта следующая:

vlan 308
exit
internet ethernet 0/24
switchport mode access
switchport default vlan 308
bandwidth-control egress 2000
bandwidth-control ingress 2000
dhcp-snooping trust
exit
no dlf-forward l2-multicast
no dlf-forward l3-multicast
storm-control ratio 1/16
no storm-control type multicast
broadcast vlan 308

На второй точке (B) установлен коммутатор D-Link DES-3200, прошивка 1.80.B009/B1, конфигурация порта следующая:

config traffic control 1 broadcast enable multicast enable unicast disable
config traffic control 1 action drop threshold 1000 countdown 0 time_interval 5
config bandwidth_control 1 rx_rate 2000 tx_rate 2000
config per_queue bandwidth_control ports 1 0-3 max_rate no_limit
config traffic_segmentation 1 forward_list 17
config traffic_segmentation 17 forward_list 1
config ports 1 speed auto state enable clear_description
config ports 1 flow_control disable
config ports 1 learning enable
config ports 1 mdix auto
create vlan VLAN308 tag 308
config vlan VLAN308 add untagged 1
config gvrp 1 pvid 308
config bpdu_protection ports 1 state enable 
config safeguard_engine state enable utilization rising 60 falling 20 trap_log enable mode fuzzy
config filter dhcp_server ports 1 state disable

 

От клиента поступила жалоба на недостаточную пропускную способность канала (около 400 Кбит/с вместо 2 Мбит/с) и высокий процент потерь (до 5%).

Для тестов на обоих точках были подключены ноутбуки с установленным пакетом iperf и были произведены следующие тесты (во всех случаях время тестирования 10 минут, число потоков 10):

Т1 - на A запущен TCP-сервер, на B запущен клиент (TCP-трафик в направлении B->A)

Т2 - на A запущен UDP-сервер, на B запущен клиент (UDP-трафик в направлении B->A)

Т3 - на B запущен TCP-сервер, на A запущен клиент (TCP-трафик в направлении A->B)

Т4 - на B запущен UDP-сервер, на A запущен клиент (UDP-трафик в направлении A->B)

 

На тестах Т1, Т2, Т4 результаты соответствовали ожидаемым, пропускная способность была около 2 Мбит/с (1800-1900 Кбит/с, без учета l2 overhead).

В тесте Т3 (TCP-трафик в направлении от QSW-2900 к DES-3200) пропускная способность составила около 440 Кбит/с.

При проведении тестов я увеличивал вдвое (до 4 Мбит/с) bandwidth на портах (и на A, и на B), но результатом было только увеличение пропускной способности до 600 Кбит/с.

Также пробовал включать и выключать flow-control на портах, никакого эффекта это не дало.

 

Нет ли предположений, с чем связано проседание на TCP?

[Abram]

MTU пролазит?

[alibek]

Должен, на коммутаторах и на ноутбуках стандартный (1500).

Да и ведь в тесте Т1 все было в порядке. Была бы причина в MTU, от направления она бы не зависела.

[dmvy]

связано с дропами пакетов, от чего tcp window деградирует на скорость сильно меньшую, чем rate-limit. Попробуйте сделать policer при помощи ACL, с учетом burst. Возможно это улучшит ситуацию. Но ограничивать скорость на L2-коммутаторах доступа - это неправильно.

[alibek]

связано с дропами пакетов, от чего tcp window деградирует на скорость сильно меньшую, чем rate-limit.

Имеются ввиду дропы пакетов, превышающих rate-limit?

А почему тогда в обратном направлении это не проявляется?

Правда там другой коммутатор, т.е. либо на D-Link дефект полисера на ingress, либо на QTECH дефект на egress.

 

Попробуйте сделать policer при помощи ACL, с учетом burst.

QTECH так возможно и умеет, а вот DES-3200 в подобном не замечен.

 

Но ограничивать скорость на L2-коммутаторах доступа - это неправильно.

А как лучше? Это L2 VPN, он нигде на ядре не терминируется. А применять полисер на ядре для клиентских VPN — это как мне кажется лишняя нагрузка на ядро, которую лучше переместить на периферию.

[dmvy]

Смотрите, где у вас ближе к ядру есть оборудование способное на такое с бурстом. А вообще, если не жалко, то формально скжите, что режете, но не ограничивайте или напишите ratelimit 10мбит, чтобы с запасом и не жаловались.

[dsk]

А почему тогда в обратном направлении это не проявляется?

 

В таком случае, уберите вообще ingress. Один хрен, на egress зарежется. Или боитесь что клиент зафлудит?

[alibek]

В таком случае, уберите вообще ingress. Один хрен, на egress зарежется. Или боитесь что клиент зафлудит?

Клиент — это гос.контора, у которой в сети редкостный бардак и нет админа. Специально флудить не будет, но лучше от этого бардака максимально изолироваться.

 

Смотрите, где у вас ближе к ядру есть оборудование способное на такое с бурстом.

Понятно. Это не очень удобно будет в управлении.

Теперь понятно, зачем нужны демаркаторы. Раньше понять не мог, к чему они при управляемом коммутаторе.

[Ivan_83]

но не ограничивайте или напишите ratelimit 10мбит

Лучше порт перевести в 10 мегабит, более комфортно будет.

[Butch3r]

Не факт, если выставить руками 10full, то с другой стороны нужно его тоже выставлять. А далеко не все свичи умеют согласовывать на auto только 10 мбит

[Ivan_83]

Много вы видели таких которые не умеют 10 мегабит когда с другой стороны жёстко выставлено и линия исправна?

[dmvy]

Дуплекс может неверно определиться и будет half.

[Butch3r]

Много вы видели таких которые не умеют 10 мегабит когда с другой стороны жёстко выставлено и линия исправна?

Когда берут канал в аренду заказчик как правило вообще ничего с ним делать не хочет. Соответственно вы у себя на свиче поставите 10 фулл, а кто это сделать у абонента?