kev

#stdbuf -o8K echo +192.168.1.1,192.168.1.2,192.168.1.3 > /proc/net/ipt_ratelimit/download

А какое кол-во IP можно добавлять? У меня при добавлении больше двух вываливается ошибка #echo +192.168.1.1,192.168.1.2,192.168.1.3 > /proc/net/ipt_ratelimit/download bash: echo: write error: Invalid argument

Протестировал на телевизоре Samsung 2014 года выпуска. Нумерация каналов работает. Единственное что влияет на это - параметр в терре "Спецификатор личных данных (hex)(Private data specifier)" Если стоит 0000233A, то нумерация работает. Если другой, то не работает. Изменение Номеров NetworkID и Original Network ID на LCN не влияют. Это относится конкретно к данному телевизору. PS: До этого тестировал на телевизорах Samsung 2008,2009 и 2011 г.в.

Подключал телевизор напрямую к терре. Толку ноль.

Ссылка на потоки https://yadi.sk/d/AyWM2VZSERxWYA

При помощи TSReader сохранил поток с триакса и терры. Открыл всё это в 4T Content Analyzer(Крутая прога кстати!). Сравнил NIT. Нашел отличие в таблицах Порядок дескрипторов в таблице NIT разный. На триаксе: DescriptorTag: 68 (0x44) "cable_delivery_system_descriptor" Descriptor 1 DescriptorTag: 65 (0x41) "service_list_descriptor" Descripot 2 DescriptorTag: 131 (0x83) "logical_channel_descriptor, EN62216-1 / NorDig Version 1" На терре: Descripor 0 DescriptorTag: 95 (0x5F) "private_data_specifier_descriptor" Descriptor 1 DescriptorTag: 131 (0x83) "logical_channel_descriptor, EN62216-1 / NorDig Version 1" Descriptor 2 DescriptorTag: 65 (0x41) "service_list_descriptor" DescriptorTag: 68 (0x44) "cable_delivery_system_descriptor"

Только что настроил Philips. Все каналы по порядку. Телику лет 10 не меньше.

Дополнительно скрины с LCN

Вот собственно все настройки NIT. Для Triax и для Terra. Возможно что ID сети не тот или Original ID. Этот параметр вообще стоял по умолчанию. Но на триаксе это работает, а на терре нет.   А не подскажете как снять поток Wiresharkom. Всегда думал что он для сетевого трафика. В качестве тюнера есть свисток Astrometa DVB-T2S905. TSReader его видит. ProgDVB видит. Wireshark не видит

Добрый всем привет. В качестве головы использовали до недавнего времени Triax TDX. Цифровое ТВ DVB-C пускали три потока Символьная скорость 6875, QAM128 LCN работает. Телевизоры каналы расставляют как надо Решили расширить кол-во каналов и приобрели модулятор IP-DVB-C Terra miq440. В настройках вроде бы всё просто и понятно. Запустили ещё два потока. Но LCN теликами Samsung не воспринимается совсем. Каналы расставляет по алфавиту. Попробовал принимать каналы через тюнер на ProgDVB. Всё в норме. Каналы с номерами. Как настроено. Решил посмотреть на NIT таблицу с помощью TSReader. Таблица есть и как бы там всё как надо. Сравнил с таблицей на Triax TDX. То же самое. Решил провести эксперимент и настроить Samsung только на Terr'у. На терре настроил нумерацию с 1 до 20. Вручную вбил частоты. Каналы находятся, но нумерация по алфавиту. Сбрасывал телевизор на заводские установки. Настраивал по разному. Автоматически полный поиск, быстрый поиск, по сети. Результат один и тот же. С триакса LCN воспринимает. С терры нет. Что-то Samsung'у не нравиться в терровской NIT таблице, но что не понятно. Есть у кого какие мысли.

Быстро растут encapsulation failed. Может в этом проблема? 4948#sh ip traffic IP statistics: Rcvd: 70543 total, 38976 local destination 0 format errors, 0 checksum errors, 6140 bad hop count 0 unknown protocol, 0 not a gateway 0 security failures, 0 bad options, 26508 with options Opts: 0 end, 0 nop, 0 basic security, 0 loose source route 0 timestamp, 0 extended security, 0 record route 0 stream ID, 0 strict source route, 26508 alert, 0 cipso, 0 ump 0 other Frags: 0 reassembled, 0 timeouts, 0 couldn't reassemble 0 fragmented, 0 couldn't fragment Bcast: 2484 received, 785 sent Mcast: 23482 received, 8296 sent Sent: 28907 generated, 753 forwarded Drop: 23902 encapsulation failed, 0 unresolved, 0 no adjacency 0 no route, 0 unicast RPF, 0 forced drop 0 options denied, 0 source IP address zero

А где нибудь можно ещё увидеть эти дропы. Может есть мануал по выяснению причин их возникновения.

Как я уже писал ранее ошибок переполнения буфера на 3550 не наблюдается. Путем тестирования выяснилось что потери идут на 4948. Причем только пакеты которые на ней маршрутизируются. Ошибок на интерфейсах 4948 тоже не наблюдается. Команда ниже показывает увеличивающиеся счетчики дропающихся пакетов. Но как диагностировать причину этих дропов не понятно. 4948#sh platform software drop-port Drop Port Software State Dequeue Enabled : True DropQueue Water mark Reg : 0x8000600038001D4C DropQueue Water mark Reg : 0x7FE32010 (Empty, PreEmpty, Head:0x1AD3, Tail:0x1AD3) DropActivityCount : 29673685024 DropOverrunCount : 0 Drop Event Reason Packets Dropped ----------------- --------------- SptDrop 231585735 InpL2AclDrop 1176372947 InpL3AclDrop 800703 UcastRpfDrop 165 BridgeToRxPortDrop 631980916575 rplErrDrop 49282223801 OutL3AclDrop 2941 OutPolicerDrop 239182969 TxQueFullDrop 71430653 DblDrop 5780140

так то оно так. Но это не объясняет потери внутри сети. Даже при минимальной загрузке канала. На 500 пингов 4-5 потерь. Не понятно только где идут потери. Все счетчики ошибок на транзитном оборудовании по нулям а потери есть. PS: когда стоял 6509 таких проблем не было. Поставили 4948. Появились

сейчас два линка по 1G. Загрузка в пике чуть больше 90%. Но на 3550 уже нет ошибок после того как разбили etherchannel. За несколько суток накопилась статистика на 4948E на 10G портах которые смотрят на SNR-2990-24FX Tx-Drops-Queue-8 Te1/49 0 0 0 25309 Te1/50 0 0 0 27654 но сейчас счетчик не растет.

все линки подключены на одинаковых скоростях. 1G к 1G 10G к 10G

проблему с переполнением output buffer получилось решить путем устранения etherchannel и распределения нагрузки путем PBR по получившимся в итоге отдельным гигабитным линкам. но дропы всё равно есть.   Да вы правы. Мы его выключали, потом снова включали. На примере он включен. Но на underruns и output buffer errors он никак не влиял. К тому же счетчики RxPause TxPause не росли.

flow control выключен. Проблема не в нем

Здравствуйте коллеги. Изменилась схема сети. Раньше домовые коммутаторы были подключены в Cisco 6509 по оптике 1G 6509 циску поменяли на C4948E + SNR-2990-24FX куда подключили домовые коммутаторы. После замены коммутатора Cisco 6509 SUP720 на Cisco C4948E возникли проблемы в виде output drops на коммутаторе 3550 на сети справа Так же output drops были на правой 6509 в сторону 4948. После того как 2Гбит/с поменяли на 10G дропы на этом линке исчезли. Причем все эти дропы ощущаются абонентами в виде потери пакетов, которые подключены к левой стороне сети где заменили оборудование . У Тех абонентов которые справа потерь пакетов нет. 3550#sh int Po2 Port-channel2 is up, line protocol is up (connected) Hardware is EtherChannel, address is 0017.e035.d483 (bia 0017.e035.d483) MTU 1500 bytes, BW 2000000 Kbit, DLY 10 usec, reliability 255/255, txload 177/255, rxload 35/255 Encapsulation ARPA, loopback not set Keepalive set (10 sec) Full-duplex, 1000Mb/s, media type is 1000BaseLX input flow-control is off, output flow-control is on Members in this channel: Gi0/3 Gi0/4 ARP type: ARPA, ARP Timeout 04:00:00 Last input never, output 00:00:00, output hang never Last clearing of "show interface" counters 05:27:25 Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/0 (size/max) 5 minute input rate 278868000 bits/sec, 88839 packets/sec 5 minute output rate 1388392000 bits/sec, 142156 packets/sec 1282873162 packets input, 2060179784 bytes, 0 no buffer Received 2293 broadcasts (0 multicasts) 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 watchdog, 1441 multicast, 0 pause input 0 input packets with dribble condition detected 2268995540 packets output, 994889212 bytes, 6925295 underruns 0 output errors, 0 collisions, 0 interface resets 0 babbles, 0 late collision, 0 deferred 0 lost carrier, 0 no carrier, 0 PAUSE output 6925295 output buffer failures, 0 output buffers swapped out Пакеты дропаются выборочно только для абонентов трафик которых маршрутизируется на Cisco 4948E. Такое ощущение что для для этих абонентов трафик летит в их сторону с большей скоростью и переполняется выходной буфер на 3550. Такое возможно? У кого нибудь есть мысли о причине подобного поведения.