Есть вопрос относительно скоростей на старых тарифных планах...
... не введены ли на них, совершенно случайно, несколько другие ограничения по скоростям, чем были на момент подключения. Прекрасно помню как получал на ресурсе скорость в 11 мегабайт в секунде, последние полгода грешил на то, что комутационная матрица на маршрутизаторе просто не могла разогнаться до сотни мегабит (типа как на определённых моделях свичей d-link и edge-core), но последние пару дней решил и вдоль и поперёк проверить эту догадку - нет, со скоростями у маршрутизатора оказалось всё в полном порядке.
Вот отсюда и вопрос: давным-давно, когда компьютеры были большими, а мы маленькими, я подключился к сети Lanet на тарифном пакете Flash-75, где в UA-IX обещали 100 мегабит в секунду и с тех самых пор ни разу не менял условий подключения. В те незапамятные времена я действительно получал свои 10-11 мегабайт в секунду, но настал момент когда скорость упорно не хочет подниматься выше 6-6.5 мегабайт/сек. Отсюда вопрос - что не так? Ваши внешние каналы, тарифные ограничения?
Предрекая вопросы: куда хожу и как проверяю?
Ресурсы 212.90.160.2 и 212.90.160.40. Бордер AS12593 не загружен (зуб даю! ;)) в канале на UA-IX достаточно ширины чтобы отдать 100 мегабит. Транспортное кольцо (3 уровень) АС тоже не загружено настолько чтобы создавать проблемы со скоростями.
Вчера вечером наблюдал "плавающую" скорость от 5 до 6.5 мегабайт в секунду, сегодня утром: wget http://..../ - 1.560.015.785 3,01M/s за 8 минут 13 секунд. Результаты iperf, состоянием на 5.10.2012 07:13, тоже не радуют:
~$ iperf -c 212.90.160.2 -p 33333
------------------------------------------------------------
Client connecting to 212.90.160.2, TCP port 33333
TCP window size: 21.0 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.1.3 port 41293 connected with 212.90.160.2 port 33333
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 22.5 MBytes 18.8 Mbits/sec
Если нужно будет проверить канал без домашнего маршрутизатора - не вопрос, я готов это сделать сегодня же вечером, но сдаётся мне, что собачка порылась где-то глубже.
В общем всецело готов сотрудничать в решении этого маленького вопроса ;)
ps: о маршрутизаторе D-Link DIR-300, прошивка DD-WRT v24-sp2 (08/07/10) std.
трейс с клиента:
~$ sudo traceroute -nI 212.90.160.2
traceroute to 212.90.160.2 (212.90.160.2), 30 hops max, 60 byte packets
1 192.168.1.1 0.436 ms 0.794 ms 1.163 ms
2 176.36.108.1 6.210 ms 6.467 ms 9.705 ms
3 194.33.189.193 5.138 ms 5.265 ms 5.396 ms
4 194.33.189.150 5.518 ms 5.651 ms 5.773 ms
5 195.35.65.17 5.908 ms 6.027 ms 6.287 ms
6 94.125.120.135 9.260 ms 8.985 ms 8.745 ms
7 94.125.120.189 8.808 ms 5.104 ms 5.094 ms
8 212.90.160.2 5.082 ms 5.070 ms 7.018 ms
download тест на клиенте:
$ iperf -c 212.90.160.2 -p 33333
------------------------------------------------------------
Client connecting to 212.90.160.2, TCP port 33333
TCP window size: 23.8 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.1.111 port 35834 connected with 212.90.160.2 port 33333
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.1 sec 43.0 MBytes 35.8 Mbits/sec
bgp маршруты с as12593 на as39608:
#sh ip bg reg _39608$
BGP table version is 102347163, local router ID is 94.125.120.65
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, x best-external
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
* 5.57.64.0/21 93.178.204.253 190 0 12883 21011 39608 i
* 80.93.115.225 190 0 35320 15645 39608 i
* 195.35.65.92 210 0 15645 39608 i
*> 195.35.65.92 210 0 15645 39608 i
* 46.250.96.0/20 93.178.204.253 190 0 12883 39608 i
* 80.93.115.225 190 0 35320 15645 39608 i
* 195.35.65.92 210 0 15645 39608 i
*> 195.35.65.92 210 0 15645 39608 i
* 46.250.96.0/19 93.178.204.253 190 0 12883 13249 39608 i
* 80.93.115.225 190 0 35320 15645 39608 i
* 195.35.65.92 210 0 15645 39608 i
*> 195.35.65.92 210 0 15645 39608 i
* 46.250.112.0/20 93.178.204.253 190 0 12883 39608 i
* 80.93.115.225 190 0 35320 15645 39608 i
* 195.35.65.92 210 0 15645 39608 i
*> 195.35.65.92 210 0 15645 39608 i
* 77.87.32.0/23 93.178.204.253 190 0 12883 39608 i
* 80.93.115.225 190 0 35320 15645 39608 i
* 195.35.65.92 210 0 15645 39608 i
*> 195.35.65.92 210 0 15645 39608 i
* 77.87.32.0/22 93.178.204.253 190 0 12883 13249 39608 i
* 80.93.115.225 190 0 35320 15645 39608 i
* 195.35.65.92 210 0 15645 39608 i
*> 195.35.65.92 210 0 15645 39608 i
* 77.87.34.0/23 93.178.204.253 190 0 12883 39608 i
* 80.93.115.225 190 0 35320 15645 39608 i
* 195.35.65.92 210 0 15645 39608 i
*> 195.35.65.92 210 0 15645 39608 i
* 77.87.36.0/23 93.178.204.253 190 0 12883 39608 i
* 80.93.115.225 190 0 35320 15645 39608 i
* 195.35.65.92 210 0 15645 39608 i
*> 195.35.65.92 210 0 15645 39608 i
* 77.87.36.0/22 93.178.204.253 190 0 12883 13249 39608 i
* 80.93.115.225 190 0 35320 15645 39608 i
* 195.35.65.92 210 0 15645 39608 i
*> 195.35.65.92 210 0 15645 39608 i
* 77.87.38.0/23 93.178.204.253 190 0 12883 39608 i
* 80.93.115.225 190 0 35320 15645 39608 i
* 195.35.65.92 210 0 15645 39608 i
*> 195.35.65.92 210 0 15645 39608 i
* 86.111.64.0/20 93.178.204.253 190 0 12883 39608 i
* 80.93.115.225 190 0 35320 15645 39608 i
* 195.35.65.92 210 0 15645 39608 i
*> 195.35.65.92 210 0 15645 39608 i
Network Next Hop Metric LocPrf Weight Path
* 86.111.64.0/19 93.178.204.253 190 0 12883 13249 39608 i
* 80.93.115.225 190 0 35320 15645 39608 i
* 195.35.65.92 210 0 15645 39608 i
*> 195.35.65.92 210 0 15645 39608 i
* 86.111.80.0/20 93.178.204.253 190 0 12883 39608 i
* 80.93.115.225 190 0 35320 15645 39608 i
* 195.35.65.92 210 0 15645 39608 i
*> 195.35.65.92 210 0 15645 39608 i
* 176.32.0.0/21 93.178.204.253 190 0 12883 13249 39608 i
* 80.93.115.225 190 0 35320 15645 39608 i
* 195.35.65.92 210 0 15645 39608 i
*> 195.35.65.92 210 0 15645 39608 i
* 176.36.0.0 93.178.204.253 190 0 12883 39608 i
* 80.93.115.225 190 0 35320 15645 39608 i
* 195.35.65.92 210 0 15645 39608 i
*> 195.35.65.92 210 0 15645 39608 i
* 176.36.0.0/14 93.178.204.253 190 0 12883 13249 39608 i
* 80.93.115.225 190 0 35320 15645 39608 i
* 195.35.65.92 210 0 15645 39608 i
*> 195.35.65.92 210 0 15645 39608 i
* 176.37.0.0 93.178.204.253 190 0 12883 39608 i
* 80.93.115.225 190 0 35320 15645 39608 i
* 195.35.65.92 210 0 15645 39608 i
*> 195.35.65.92 210 0 15645 39608 i
* 194.33.189.0 93.178.204.253 190 0 12883 13249 39608 i
* 80.93.115.225 190 0 35320 15645 39608 i
* 195.35.65.92 210 0 15645 39608 i
*> 195.35.65.92 210 0 15645 39608 i
* 194.50.85.0 93.178.204.253 190 0 12883 13249 39608 i
* 80.93.115.225 190 0 35320 15645 39608 i
* 195.35.65.92 210 0 15645 39608 i
*> 195.35.65.92 210 0 15645 39608 i
загрузка интерйфейса на UA-IX:
TenGigabitEthernet4/3 is up, line protocol is up (connected)
Hardware is C7600 10Gb 802.3, address is 001d.7172.1f00 (bia 001d.7172.1f00)
Description: UA-IX
Internet address is 195.35.65.17/24
MTU 2000 bytes, BW 10000000 Kbit/sec, DLY 10 usec,
reliability 255/255, txload 3/255, rxload 3/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 10Gb/s
Transport mode LAN (10GBASE-R, 10.3125Gb/s)
input flow-control is off, output flow-control is off
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:00, output 00:00:00, output hang never
Last clearing of "show interface" counters 7w2d
Input queue: 0/75/118/114 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 151781000 bits/sec, 23580 packets/sec
5 minute output rate 132489000 bits/sec, 42488 packets/sec
L2 Switched: ucast: 11964747 pkt, 2871898665 bytes - mcast: 60518751 pkt, 3873202363 bytes
L3 in Switched: ucast: 65939442990 pkt, 50393712529759 bytes - mcast: 0 pkt, 0 bytes mcast
L3 out Switched: ucast: 106612636947 pkt, 45157854900104 bytes mcast: 0 pkt, 0 bytes
66015856782 packets input, 50400626995136 bytes, 0 no buffer
Received 60575140 broadcasts (0 IP multicasts)
0 runts, 13405 giants, 1 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 0 multicast, 0 pause input
0 input packets with dribble condition detected
106631412885 packets output, 45247779001070 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 pause output
0 output buffer failures, 0 output buffers swapped out
загрузка сабинтерфейса на 212.90.160.2:
GigabitEthernet0/2.16 ATS201 SERVERS
Input
matches: all traffic
params: 1000000000 bps, 187500000 limit, 375000000 extended limit
conformed 57183 packets, 12157050 bytes; action: transmit
exceeded 0 packets, 0 bytes; action: drop
last packet: 4ms ago, current burst: 626 bytes
last cleared 00:00:42 ago, conformed 2265781 bps, exceeded 0 bps
Output
matches: all traffic
params: 1000000000 bps, 187500000 limit, 375000000 extended limit
conformed 73603 packets, 63647038 bytes; action: transmit
exceeded 0 packets, 0 bytes; action: drop
last packet: 0ms ago, current burst: 0 bytes
last cleared 00:00:42 ago, conformed 11873455 bps, exceeded 0 bps
Ну и где "плюшки", где заявленная скорость 100 мегабит в Украину /UA-IX/?
Так не понятно проверяли ли вы без маршрутизатора или нет ?
Если собачка порылась где-то глубже, то нужно будет сделать заявку на вызов мастера, для диагностики соединения.
Потому что никаких явных проблем которые могут как то ограничивать скорость нету.
Кстати у dir-300 реально не очень быстрый процессор, по крайней мере на родной прошивке wan->lan он больше чем 8 мегабайт через себя не пропускает.
Так не понятно проверяли ли вы без маршрутизатора или нет ?
Если собачка порылась где-то глубже, то нужно будет сделать заявку на вызов мастера, для диагностики соединения.
Потому что никаких явных проблем которые могут как то ограничивать скорость нету.
Кстати у dir-300 реально не очень быстрый процессор, по крайней мере на родной прошивке wan->lan он больше чем 8 мегабайт через себя не пропускает.
Нет, только лишь вечером проверю без маршрутизатора. Если бы было хотя бы 8 мегабайт в секунду - то слова бы не сказал. Но 3 - 5 это никак не 8. Да и, кстати, пробовал не только DIR-300, но и Asus стоял (модель сейчас не скажу, не помню).
Вызов мастера? Да не вопрос, если потребуется то так и будет. Другой момент, а увидит ли тот мальчик-монтажник который придёт на вызов возможные ошибки на порту коммутатора или же можно пообщаться напрямую с кем-либо более компетентным чем девочка/мальчик в колл-центре? Поверьте на слово, что провести диагностику своего подключения, со своих устройств, я как бы и сам смогу. Меня больше бы интересовала обратная информация, то состояние порта и счётчики, которые видны со стороны провайдера. Но даже если вызвать мастера то будет огромная просьба не присылать специалиста который умеет лишь кликать мышкой по иконкам "форточек", так как их нет, т.е. совсем, ни на одном компьютере.
Кстати, если не секрет, то какая модель коммутатора на уровне доступа стоит по адресу Гетьмана 25?
В общем, оставляю вопрос открытым до вечера.
Относительно же DIR-300, буквально вчера, на том маршрутизаторе который сейчас стоит дома, проверяли скорость его соединения через 802.11 в N стандарте - 70 мегабит получили за милую душу, правда в пределах одной AS, максимум на четырёх хопах.
Вы кстати можете сами видеть счетчики своего порта в своем личном кабинете.
компьютеры - интенсивность потребления.
С нашей стороны никаких ошибок и потерь мы не наблюдаем.
Модель коммутатора Edge-Core 3528M
Из своего опыта скажу, что мы реально потратим меньше времени если вы проверите без роутера, и если он не причем то оформим заявку.
Потому что действительно нет смысла дискутировать о высоких технологиях, схема маршрутизации довольна проста, относительно проста ;)
А все проблемы в основном появляются на последней миле.
Компьютеры - интенсивность потребления вряд ли мне покажут что-то наподобие:
Ethernet 1/ 1
Iftable Stats:
Octets Input: 3158362402, Octets Output: 1684594476
Unicast Input: 56559762, Unicast Output: 66652708
Discard Input: 0, Discard Output: 0
Error Input: 0, Error Output: 0
Unknown Protos Input: 0, QLen Output: 0
Extended Iftable Stats:
Multi-cast Input: 2, Multi-cast Output: 2701736
Broadcast Input: 5363, Broadcast Output: 9667
Ether-like Stats:
Alignment Errors: 0, FCS Errors: 0
Single Collision Frames: 0, Multiple Collision Frames: 0
SQE Test Errors: 0, Deferred Transmissions: 0
Late Collisions: 0, Excessive Collisions: 0
Internal Mac Transmit Errors: 0, Internal Mac Receive Errors: 0
Frames Too Long: 0, Carrier Sense Errors: 0
Symbol Errors: 0
RMON Stats:
Drop Events: 0, Octets: 3158367011, Packets: 56565184
Broadcast PKTS: 5363, Multi-cast PKTS: 2
Undersize PKTS: 0, Oversize PKTS: 0
Fragments: 0, Jabbers: 0
CRC Align Errors: 0, Collisions: 0
Packet Size
В догонку...
Кстати, если не страшная военная тайна: в UA-IX вы включаетесь на Леонтовича или на Гайдара 50?
Не может ли проблема крыться в этом моменте? Если что то мы (as12593) включены на Леонтовича, хотя на Гайдара тоже присутствуем, но несколько в другом амплуа...
На Куренёвской же, вроде бы, пока точки присутсвия у UA-IX-а нет... хотя не уверен.
Ну далеко не сродни 3510, такие мы использовать отказались в самом начале, а ES3528M и ES3552M это золотая середина. Скажем честно, получше всех делинков и прочих по таким же характеристикам, тем более мы дистрибьюторы, мы сами находим баги, сами запрашиваем у разработчиков новый функционал.
Мак колизии мы не допустим не в коем случае, у нас очень мелкие бродкаст домены, на свитч максимум по два /24 префикса, все веланируется.
Агрегация агрегируем мы так же в поле, и совсем не далеко до доступа.
У нас на самом деле очень продуманная топология, наработки и усовершенствования шли годами, тут беспокоится не о чем.
Что касается статистики, вот с вашего порта, в принципе небольшое количество ошибок присутствует, но снова же, нужно узнать что их вызывает.
Vty-0#show interfaces counters ethernet 1/24
Ethernet 1/24
Iftable Stats:
Octets Input: 16425580677, Octets Output: 606981694014
Unicast Input: 148573824, Unicast Output: 405315585
Discard Input: 0, Discard Output: 0
Error Input: 851, Error Output: 0
Unknown Protos Input: 0, QLen Output: 0
Extended Iftable Stats:
Multi-cast Input: 6680, Multi-cast Output: 32852624
Broadcast Input: 2384, Broadcast Output: 80442795
Ether-like Stats:
Alignment Errors: 0, FCS Errors: 4
Single Collision Frames: 0, Multiple Collision Frames: 0
SQE Test Errors: 0, Deferred Transmissions: 0
Late Collisions: 0, Excessive Collisions: 0
Internal Mac Transmit Errors: 0, Internal Mac Receive Errors: 641
Frames Too Long: 0, Carrier Sense Errors: 0
Symbol Errors: 0
RMON Stats:
Drop Events: 0, Octets: 623407266612, Packets: 667193951
Broadcast PKTS: 80445228, Multi-cast PKTS: 32859320
Undersize PKTS: 0, Oversize PKTS: 0
Fragments: 206, Jabbers: 0
CRC Align Errors: 4, Collisions: 0
Packet Size
[quote]В догонку...
Кстати, если не страшная военная тайна: в UA-IX вы включаетесь на Леонтовича или на Гайдара 50?
Не может ли проблема крыться в этом моменте? Если что то мы (as12593) включены на Леонтовича, хотя на Гайдара тоже присутствуем, но несколько в другом амплуа...
На Куренёвской же, вроде бы, пока точки присутсвия у UA-IX-а нет... хотя не уверен.[/quote]
Вряд ли.
Мы включены на гайдара 50.
Кстати в ua-ix недавно был плановый тотальный апгрейд, проблем быть не должно.
Да, в курсе, читал в рассылке Полищука.
Просто на всякий случай спросил. Случаи они ведь разные бывают.
К счастью это была ошибочная мысль.
Протестировал скорость без маршрутизаторов (D-Link DIR-300 и Asus WL-520gC) - понял, что пора их отправлять на заслуженный отдых.
Если с D-Link'ом картина совсем печальная то с Asus'ом всё немного лучше:
# iperf -c 212.90.160.2 -p 33333 | tee iperf3.txt
------------------------------------------------------------
Client connecting to 212.90.160.2, TCP port 33333
TCP window size: 21.0 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.1.4 port 59068 connected with 212.90.160.2 port 33333
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 59.4 MBytes 49.7 Mbits/sec
Ну, а без этих soho-маршрутизаторов, при прямом включении порта нетбука, всё вообще просто великолепно:
------------------------------------------------------------
Server listening on TCP port 33333
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
------------------------------------------------------------
Client connecting to 212.90.160.2, TCP port 33333
TCP window size: 54.5 KByte (default)
------------------------------------------------------------
[ 5] local 176.36.108.106 port 41420 connected with 212.90.160.2 port 33333
[ ID] Interval Transfer Bandwidth
[ 5] 0.0-10.0 sec 111 MBytes 92.7 Mbits/sec
[ 4] local 176.36.108.106 port 33333 connected with 212.90.160.2 port 48929
[ 4] 0.0-10.0 sec 112 MBytes 94.1 Mbits/sec
Так, что спасибо за терпение и понимание. Мой вопрос можно считать снятым с повестки дня. Есть мнение, что MikroTik RB751G-2HnD будет вести себя несколько лучше. :)
ps: Кстати, количество ошибок не так уж и велико, даже так, на общем фоне их скорее стоит проигнорировать чем морочить голову над при каком неблагоприятном соотношении звёзд они образовались. В любом случае спасибо за статистику.
Есть мнение, что на длинке "подгорел" wan-порт: в тестовой пачкорд был короткий, не более полутора метров, а дома от порта маршрутизатора к вашему свичу расстояние куда как больше.
Что ж, отрицательный результат тоже результат.
Чудненько.
Вопрос на засыпку, а это так и задумано чтобы клиент видел STP?
2012-10-16 10:35:16.724805 70:72:cf:1d:d7:38 -> 01:80:c2:00:00:00 STP RST. Root = 32768/0/70:72:cf:1d:d7:20 Cost = 0 Port = 0x8018
2012-10-16 10:35:18.727608 70:72:cf:1d:d7:38 -> 01:80:c2:00:00:00 STP RST. Root = 32768/0/70:72:cf:1d:d7:20 Cost = 0 Port = 0x8018
2012-10-16 10:35:20.723749 70:72:cf:1d:d7:38 -> 01:80:c2:00:00:00 STP RST. Root = 32768/0/70:72:cf:1d:d7:20 Cost = 0 Port = 0x8018
2012-10-16 10:35:22.725949 70:72:cf:1d:d7:38 -> 01:80:c2:00:00:00 STP RST. Root = 32768/0/70:72:cf:1d:d7:20 Cost = 0 Port = 0x8018
А если вдруг, случайно, клиент станет рутом в выборах?
Не моё это дело, конечно, но не логичней ли на клиентских портах, свича уровня доступа, сделать?
spanning-tree spanning-disabled
spanning-tree bpdu-filter
[quote]А если вдруг, случайно, клиент станет рутом в выборах?
Не моё это дело, конечно, но не логичней ли на клиентских портах, свича уровня доступа, сделать?
spanning-tree spanning-disabled
spanning-tree bpdu-filter[/quote]
Не то что бы так задумано, просто такая особенность.
Spanning Tree мы на клиентских портах не отключаем, так как на коммутаторах Edge-core с помощью этого протокола у работает функционал Loopback Detection.
Но клиент не сможет влиять на перестройку топологии, так и рутом никогда не станет, так как на всех клиентских портах включен BPDU Guard.
Кстати на данный момент мы только тестируем кольца, а в продакте у нас классические звезды, как бы не хотелось, выборов все равно никаких нет.
Кстати интересный mac 70:72:cf:1d:d7:38, в биллинге не нашел коммутатора с таким маком.
Коментувати
Коментарі на даній сторінці заблоковані!